Status and Gas Abstraction
While Ethereum PoS is not running in mainnet the network effect can be unknown due the possibly of front running inner transactions and no cheap/convenient/fair/decentralized way of selecting gas relay nodes.
What is Gas Abstraction
Status Gas Relayers create Full Gas Abstraction, that means it allows accounts to pay gas fees in any valued token.
This is possible through the use of smart contracts that represents user accounts, like Identity and Multisig, and including on this contracts functions to execute based on an ethereum signed message (ecrecover message inside contract) by the account owner, rather on the transaction signer (
msg.sender from ethereum transactions).
Past research and history
Oct 2016: A similar early concept was developed by @iurimatias https://github.com/iurimatias/TransactionRelay
Jan 2018: The discussion restarted here https://ethresear.ch/t/pos-and-economic-abstraction-stakers-would-be-able-to-accept-gas-price-in-any-erc20-token/721
The first version of it was commited on https://github.com/status-im/contracts/commit/d12683b9b4b5226220c0527d7008c332cf19b6b3#diff-ec62ab6e924043df74988b0fc4d11d0d
and Status Foundation showed interest due its UX improvements over SNT usage so the research begun.
This first implementation of gas relaying was not real gas abstraction because it didn’t allowed any type of transaction call. Described here https://github.com/status-im/ideas/issues/73
Feb 2018: Ropsten tests begun https://ropsten.etherscan.io/tx/0x52a886755876e7f88fed90cae3f58ee8e00cdcaa2dac24382202d0e37ed14059
that used this contract https://ropsten.etherscan.io/address/0x9787564e1bd7da95ee9dcdf17cc57a7225084632 (verified on etherscan)
The mechanics of this first implementation can be studied by this inner transaction execution example in Ropsten.
Mar 2018 While on Thailand, more interest was shown from Status, and a new version bringing real gas abstraction was commited https://github.com/status-im/contracts/commit/1f9ad9b135e1a0710132799b0cd73e165bc2dc35
“Alex Van de Sande” created the concept of Universal Logins powered by Gas Abstraction https://github.com/status-im/ideas/issues/73#issuecomment-375770604
Apr 2018 A new swarm was started https://github.com/status-im/ideas/pull/150
and our first “gas relayer client” was commited by @rramos https://github.com/status-im/snt-gas-relay/commit/7bae020fa8476455ba3f948ce2b43797bfd5d2fc
Current implementation and research
The current contract we are using is based on https://github.com/status-im/contracts/blob/150-gas-abstraction/contracts/identity/IdentityGasRelay.sol
This was created in order to make possible any type of transaction, but different from the first version, it requires an account contract.
To remove this limitation Status Gas Abstraction ended up being using both methods, but the first version being used only to call the contract factory (due security reasons) and allow users to don’t ever need ETH.
There is still research about race conditions and the support of any contract.
Preventing front running of inner transactions
This specific version would work best together with Ethereum PoS, meaning that status nodes that stake on PoS would have the best front running protection, actually no front running would not be possible if block validators include the inner transactions (aka “meta-transactions”.)
While PoS is not available we have 4 options:
Don’t prevent front running.
This means that some gas relayers would have their transactions failing for natural competition on broadcasted inner transactions. Front run is possible upon a limit, because the higher the outer transaction (aka “ethereum transaction” ) gas price is, the less profitable that gas relaying would be.
block.coinbase(aka miner or validator as PoS) to include inner transactions.
This would be the best case for preventing front run of transactions. However while we are on PoW we could not get the network effect we want as it depends on mining pools to start running Gas Relayer with the tokens the mining pool operator chooses to accept.
- Inner transactions must select what address can relay it,
This would be a good solution in exchange of more gas used in outer transaction and calculation of inner transaction hash.
Use state channels to payout only when certain transaction hashes are executed.
This would be better for accounts contracts that send many transactions, as the token payment can be bundled in a single transaction, however it would be more expansive for a single payout, and also require the opening of the channel.
Gas relayers would receive this other message together with the inner transaction message that certifies that gas relayers would get the reward, “Account contract” would include in storage a list of txhashes that were included. Anyone would be able to include the inner transaction but only gas relayer that also have the signature of payout would be able to receive reward.
Current PoC is not preventing competition of inner transactions, however another PoC having this other types of mechanisms could be developed if needed.
Deciding if a transaction worth including
There are 3 things that should be considered before attempting to include an inner transaction:
- Prevent hard failing transactions
Status Gas Relayer currently forks the current state of network and simulates the transaction, in case of assertion fails or other invalid opcodes in the execution the node would ignore the transaction.
- Prevent contracts that don’t actually pay the gas
In order to Gas Relayers don’t need to curate the bytecode of “account contracts” (such as IdentityGasRelay) to see if they payout the promised inner transaction token gas, they can use the simulation as well.
Another safer option is to only allow certain bytecodes, that, or are chosen by the gas relayer itself, or from a inchain list that is curated by a democracy.
- Calculating the profit from the gas price of inner transactions.
This should mimic how Ethereum Miners do now for Ether. They choose one or more sources of token price, and decide based on a minimum profit margin.
Current PoC uses a combination of this techniques to decide if the transaction worth including.
Enabling the account contract deploy to be paid in SNT
While other actions can be done with any valued token that is accepted by gas relayers, the deploy of the contract that enables gas relay would be only possible using SNT
This is possible because the SNTController contract enables restricted types of calls to the “Account Contract Factory”, which for our PoC is called IdentityFactory, that spawns IdentityGasRelay contracts, and also enables the move of SNT to this newly generated contract.
The contract that can do it can be seen here https://github.com/status-im/contracts/blob/150-gas-abstraction/contracts/status/SNTController.sol#L75
The UX from this transition from externally owned account to contract account should be carefully done to prevent confusion on the address change.
- Ship gas relayer as a single application.
- Create Status node and adapt current gas relayer to become a plugin of it.
- Support Identity on Status with Gas Abstraction
- Change contracts to only allow PoS block validator to include the transactions