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).

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.

Allow only 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.

Next steps

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

I developed a new strategy for reducing the cost of gas relaying. It use a payment channel limited by a nonce which is incremented on each call relayed by a particular gas relayer.

When newChannel is called, it transfer the selected amount of tokens right after creating the channel, and allows the payment signature be delivered before the channel deployed. (might have some issues with concurrent transactions to same factory, but Constantinople CREATE2 opcode should allow to create a better factory and simplify contracts).

After a channel is created it can be used in callGasChannel, which will increment the nonce after the call is done. _gasLimit is still needed to prevent bad calls from relayer.
Channel signer (owner) and gas relayer will agree on a fee offchain, which will allow withdraw after a certain nonce. Account owner will deliver 2 signatures for gas relayer, one is for allow call on account, and other for allow payout on channel.
Account owner can be sure gas relayer will do the call, otherwise they wont be able to use the withdraw, and gas relayer can be safe that the payout will be available because of logic.

This lends itself perfectly to being integrated in Status, and Status can have gasless transactions with this today. What’s more, Status can relay transactions for others with an implementation of this, as described in the “Status Modes” idea.

We have here an opportunity to support an excellent new project, to multi-incentivize people to run Status desktop, and to run gasless transactions all in one.

Thanks for sharing. The solution by tabookey seems to dont solve the “etherless transactions” , it can gas relay just after you become part of the RelayHub.
This could be solved by allowing RelayHub to operate as an authority in StatusNetwork (MiniMeToken controller) that would change balances in SNT itself, not inside relayhub account balances.
The solution seems robust but basically its a way of punishing users that try to attack gas relayers by sending duplicated nonces to multiple nodes, and they require that receiving contracts implement their specific interface (and trust RelayHub address)
I think they are overestimating their own solution, that works, but have several limitations and nonces that makes it not universally interoperable or truly a gas abstraction solution.

Status solution is interoperable as regular externally accounts, being the only limitation that the “account contract” itself cannot sign a message because its address is not derived from a public key, instead its storage and code defines the signer address, so thats something to take account when developing future web3 applications and contracts: don’t force users to use externally owned accounts, if a signature is needed and account is codesize > 0, read the key from Identity or allow account contract to set the message signer address.