Gas Relayer for Status Nodes

ricardo3 · October 31, 2018, 10:43pm

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 GitHub - iurimatias/TransactionRelay: Transaction Relay enables transaction fees of Ethereum contracts and transactions to be paid by any Currency
Jan 2018: The discussion restarted here POS and economic abstraction: stakers would be able to accept gas price in any ERC20 token? - Economics - Ethereum Research
The first version of it was commited on presigned token · status-im/contracts@d12683b · GitHub
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 Gas economic abstraction in top of smart contracts · Issue #73 · status-im/swarms · GitHub

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 add economic abstraction property to Identities · status-im/contracts@1f9ad9b · GitHub
“Alex Van de Sande” created the concept of Universal Logins powered by Gas Abstraction Gas economic abstraction in top of smart contracts · Issue #73 · status-im/swarms · GitHub

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 Adding gas-relayer source · status-im/snt-gas-relay@7bae020 · GitHub

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

ricardo3 · December 9, 2018, 7:20am

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:

github.com

status-im/snt-gas-relay/blob/b1dd800e1e2395c758b33292e5dfddcd97df24b6/test-dapp/contracts/gasrelay/SimpleGasChannel.sol

pragma solidity >=0.5.0 <0.6.0;

import "./GasChannel.sol";
import "../payment/NonceChannelFactory.sol";
import "../common/Account.sol";
import "../common/Controlled.sol";
import "../common/MessageSigned.sol";

/**
 * @title SimpleGasRelay
 * @author Ricardo Guilherme Schmidt (Status Research & Development GmbH) 
 * @notice enables economic abstraction for Controlled
 */
contract AccountGasChannel is Account, Controlled, GasChannel, MessageSigned {
        
    /**
     * @notice creates a new channel and pay gas in the newly created channel 
     * @param _channelFactory address of trusted factory
     * @param _signer address signing the gas agreement
     * @param _gasRelayer beneficiary of channel

This file has been truncated. show original

Abstract contract:

github.com

status-im/snt-gas-relay/blob/b1dd800e1e2395c758b33292e5dfddcd97df24b6/test-dapp/contracts/gasrelay/GasChannel.sol

pragma solidity >=0.5.0 <0.6.0;

import "../token/ERC20Token.sol";
import "../payment/NonceChannel.sol";
import "../payment/NonceChannelFactory.sol";

/**
 * @title GasChannel
 * @author Ricardo Guilherme Schmidt (Status Research & Development GmbH) 
 * @notice abstract gas channel
 */
contract GasChannel {

    bytes4 public constant MSG_NEWCHANNEL_PREFIX = bytes4(
        keccak256("newChannel(address,address,address,address,uint256,uint256,uint256)")
    );

    bytes4 public constant MSG_CALL_GASCHANNEL_PREFIX = bytes4(
        keccak256("callGasChannel(address,uint256,bytes32,uint256,address)")
    );

This file has been truncated. show original

Abstract payment channel:

github.com

status-im/snt-gas-relay/blob/improvements/test-dapp/contracts/payment/NonceChannel.sol

pragma solidity >=0.5.0 <0.6.0;

import "../deploy/InstanceAbstract.sol";
import "../common/Controlled.sol";
import "../common/MessageSigned.sol";
import "../token/ERC20Token.sol";

/**
 * @title NonceChannel
 * @author Ricardo Guilherme Schmidt (Status Research & Development GmbH) 
 * @notice enables offchain payment agreements with payout limited by a nonce.
 */
contract NonceChannel is InstanceAbstract, Controlled, MessageSigned {
    address payable public recipient; 
    address public signer; 
    uint256 public expiration; 
    uint256 public nonce;
    uint256 public paid;

    /**

This file has been truncated. show original

Bruno · January 12, 2019, 11:26pm

Superb new generically-applicable solution has appeared: https://medium.com/tabookey/1-800-ethereum-gas-stations-network-for-toll-free-transactions-4bbfc03a0a56

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.

ricardo3 · January 15, 2019, 4:22am

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.

Bruno · January 15, 2019, 6:40am

Nice, thanks for clarifying! I’ll give it some thought and review.