Altfury a remote wallet provider (GSaaS*) design document - Work In Progress
Motivationale⌗
With around 2000 DApps and more than 60.000 users, the promise of 27.000 tx/s with Ethereum 2.0 and people arguing for Infura centralizing the public Ethereum world there is call for alternative! Altfury aims to provide to anyone the ability to interact with DApps and any smart contract without the need of paying gas.
Your user don’t have a wallet?
You can let us take care of your keys and the burden to not forget and secure them while enjoying the DeFi space faster than ever. DApp developers, the Ethereum world to your users with only the change of your endpoint URL address. Users, hassle free access to the DeFi world
No burden to use a new SDK in your DApps, work with standard Wallet Connect (Uniswap & al)! Peepz, just to go the website (optional install browser extension) pair up and go!
*Gas Station As A Service (GSAAS)
Intro⌗
The goal of this document is to provide a design of a high-available service providing Ethereum JSON RPC endpoints over HTTP and HTTP WebSocket and other related services such as fee (tx) management to act as a drop-in repleacement (or plugin to existing wallet connectors).
Technical note⌗
In addition, the endpoint SHOULD allow:
- For unfunded Ethereum account to pass transaction on the blockchain under certain condition Withhold transaction then
- Guaranteed transaction inclusion with low gas price fee For this specific feature, there is multiple ways to achieve this Pass transaction off-band to a partner miner pool that would accept transaction with a gasPrice set at 0 or fund the account via a faucet to the gasLimit x gasPrice while withholding the transaction until funding is done and then propagate it.
Definition⌗
A remote wallet provider is a service that aims to help distant services to execute(read calls), sign(key control) and transmit transaction(write calls)
It integrate seamlessly by emulating a blockchain state with a balance corresponding for the credit of each account creating an ephemeral blockchain network (next_view(state, account_balances)->fork_view, a fork of the mainnet displaying accounts as if they have the corresponding amount making the experience seamless as
Customers⌗
- Bots
- NoCode users
- User that click on interface (browser extension, https://twitter.com/P3b7_/status/1361345964259352580?s=19)
- User willing to invest to rely on this for automation
- User that do their on smart contract automation
Todo do market research to describe personas
Future of work⌗
- Provide services about key usage (defi liquidity mining, …)
Architecture⌗
SHOULD be as minimal as possible to have a low footprint/cost (front-end requests (administration, user management, …)). Use go-ethereum as library to avoid technical debt as much as possible.
-> Wondering if serverless could be a benefit if it were handling execution read calls, this might be costly if not self-hosted
-> Browser extention to change the RPC endpoint easily -> Ledger device with dedicated credit app -> Website where account can be toped-up by XXX means
Security⌗
Per ethereum account (extracted from transaction signature) whitelisting. Per application(what), per logged user (who) Anonymous user SHOULD be limited by IP(Handle IPv6 per /64 block?):
- Rate in second
- Total number of concurrent connection
- Time limit on connection
USER_TYPE:
- LOW_GASER
- TO_FUND_ACCOUNT
- ANONYMOUS
New usages possible out of that⌗
- Send NFT anonymously via TornadoCash integration
Allowed usage pattern⌗
- Authorize (max amount?)
- Trade
- Trade
- … max amount before security callbacks?
Regulatory limits⌗
Is this such a thing for DeFi? Tax?
Fraud prevention / whitelisting system⌗
Smart-contract based?
Providing an ephemeral ethereum state⌗
- Modify https://github.com/ledgerwatch/turbo-geth/blob/master/consensus/ethash/sealer.go#L166 to wait on a channel instead of searching for the nonce and set a MAGIC MixDigest to permit identification of a special block to be included on the canonical chain without verification
- Prevent MAGIC block propagation throught
Transaction payment to miner⌗
The payment is distributed to the block.coinbase each block containing private transaction (and potentially a lower than usual gas price)
Todo expand idea of private transaction via on-chain payment -> find a settlement cost minimal (ticket+payment channel)
Transaction flow⌗
Write flows⌗
sequenceDiagram
participant User
participant EVM Service
participant Eth node
activate EVM Service
User->>EVM Service: eth_sendRawTransaction
EVM Service->>EVM Service: Classify user type
EVM Service->EVM Service: Apply rate limit
opt if user is TO_FUND_ACCOUNT type
EVM Service->EVM Service: Apply funding TX to txpool
end
opt if user is LOW_GASER
EVM Service->EVM Service: Disable gasPrice limit
end
EVM Service->EVM Service: Verify TX against txpool
activate Eth node
EVM Service-->>Eth node: Propagate funding transaction for TO_FUND_ACCOUNT user
EVM Service-->>EVM Service: Wait for funding settlement for TO_FUND_ACCOUNT user
alt Private or public transaction
EVM Service->>Eth node: Propagate user transaction
deactivate Eth node
else
EVM Service-->>Miner pool: Dispatch transaction for LOW_GASER user
end
deactivate EVM Service
Read flows⌗
Todo
Documentation⌗
Pricing https://github.com/ethereum/wiki/wiki/JSON-RPC https://www.stateofthedapps.com/stats
Ethereum RPC⌗
Modified RPC⌗
eth_call due to gasPrice
parameter
eth_estimateGas due to gasPrice
parameter
eth_gasPrice⌗
Should reflect the gasPrice we want either low or high depending of the kind of transaction we expect to see either through a miner pool or pre-funding.
eth_sendRawTransaction⌗
Custom implementation of this RPC, depending on USER_TYPE
Non stream RPC⌗
-
eth_accounts
-
eth_blockNumber
-
eth_call
-
eth_chainId
-
eth_getBalance
-
eth_getBlockByHash
-
eth_getBlockByNumber
-
eth_getBlockTransactionCountByHash
-
eth_getBlockTransactionCountByNumber
-
eth_getCode
-
eth_getLogs
-
eth_getStorageAt
-
eth_getTransactionByBlockHashAndIndex
-
eth_getTransactionByBlockNumberAndIndex
-
eth_getTransactionByHash
-
eth_getTransactionCount
-
eth_getTransactionReceipt
-
eth_getUncleByBlockHashAndIndex
-
eth_getUncleByBlockNumberAndIndex
-
eth_getUncleCountByBlockHash
-
eth_getUncleCountByBlockNumber
-
eth_getWork
-
eth_hashrate
-
eth_mining
-
eth_protocolVersion
-
eth_submitWork
-
eth_syncing
-
net_listening
-
net_peerCount
-
net_version
-
web3_clientVersion
Streams RPC⌗
- eth_newFilter
- eth_newPendingTransactionFilter
- eth_getFilterChanges
- eth_getFilterLogs
- eth_uninstallFilter
- eth_subscribe
- eth_unsubscribe
Notes⌗
- Fast Transaction Pool, low latency viewer / transaction sender
- Connect to peers, fetch memory pool, behave as light relay node
- Provide transaction mempool view and fast transaction dispatching
- Populate a central database for constant time access via API (paid access ?)
- Monitor transaction to addresses, on update
- Callback to backend customers through a fast protocol (GRPC?REST?…?)
- Trigger registered function (e.g: send transaction)
- World infrastructure required (node in each world, potentially costly + dev ops)
- Dashboard with world view of ethereum compatible blockchain
- Speed transaction sending for quick transaction dispatching
- Would require ethereum node modification