Gas Relayer for Status Nodes

gas-abstraction

#1

Status and Gas Abstraction

We can start status node with first utility as gas relayer, and later add other features on it.
Status already have a PoC on gas relayer. Idea #150: https://ideas.status.im/ideas/150-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:

  1. 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.
  2. 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.
  3. 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.
  4. 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

  1. Ship gas relayer as a single application.
  2. Create Status node and adapt current gas relayer to become a plugin of it.
  3. Support Identity on Status with Gas Abstraction
  4. Change contracts to only allow PoS block validator to include the transactions

Chat & Wallet Integration for 3rd Party Apps
#2

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.

Implementation:

Abstract contract:

Abstract payment channel: