I already described a free transaction proposal, that could be implemented in an Ethereum-like blockchain. There is also a more polished version, oriented to pay the gas consumption using tokens. They are based on composite transactions and extended transactions. The new transaction types could allow more use cases. They can be implemented with low effort.
But you know: I pursue simplicity. So, after discussing with JR, from RSK Team, a new simpler idea emerged.
One of the problems of Ethereum metatransactions (and Gas Station) is that the original sender is lost when the intended action is executed. Let’s be A the sender, that has no balance. It declares his/her intention of doing the action X in the game G (smart contract). A relayer or sponsor R could execute the intended action as a blockchain transaction, but the game will see that the sender of such transaction is the relayer account. A game should be written in advance to detect the original sender, according to Gas Station specification, it cannot use the ubiquitous
Also, it is hard for the sender A, without balance, to execute token transfers to R, in order to pay for his/her work.
The proposal in this blog post is oriented to allow a clearer use of original sender, and also to allow the token transfer to relayer/sponsor.
The sender A, having no balance, wants to invoke the contract C, using a determined data and value. Then, he/she sends that info to the relayer R (possibly to a public API site exposed by the relayer). My name for such information is intention:
In this proposal, the sender could declare MANY intentions in the same sponsored transaction. To validate those intentions, the sender signs a message composed by the list of intentions and its sender nonce. Sending a list, allows the sender to EXECUTE many steps in one transaction, ie: pay the relayer in tokens, call a game, call another contract, etc. The sender nonce is included to be checked when the final transaction were executed: the sender account nonce should match this nonce value. The motivation for this additional field is to avoid the sender could spam the network with sponsored transactions: they should obey a nonce sequence order.
The relayer R then validates that data, and if it is correct and he/she agree with the intention, builds a normal transaction with:
- Sender is relayer R
- Receiver is a dedicated new precompiled contract
- Gas limit as gas price, according to the intentions and relayer checks
- Relayer nonce provided by relayer
- Value (only if the intention declares that a value transfer is needed, ie, to buy an item in a game)
- Data: the intention list, sender A nonce and sender A signature
When the precompiled contract executes this transaction, validates the signature of the intention list, check the original sender nonce, and then it start to call each intention (receiver, value, data), using the signer (original sender) as the sender. Here is the trick: only this precompiled contract can do this (use another sender)
The sender S want to play the game G. The game DApp creates the sender account, without balance. Each move in the game, is encoded in a blockchain transaction. S builds the intention (G as receiver, data to send, value), send it to the relayer R. The relayer validates the intention and sends a blockchain transaction with receiver the special precompiled contract that will execute the signed intention. The relayer interest is to promote the game, so it is not interested in have a payment for its services.
Another use case: a social network gives tokens to its users, according to their activities. In this case, the available relayer wants to receive payment in tokens for sending the blockchain transaction. The sender sends to the relayer a list of TWO intention: first, declaring a token transfer to the relayer account; second, declaring the transaction that he/she wants to execute. The relayer review the data, and decides if it sends or not a real transaction to the dedicated precompiled contract.
An alternative to the above use case (paymemt with tokens): a third intention could be generated by the precompiled contrat, to return tokens to the original sender, if at the end of the execution of the sponsored transaction, the consumed gas was less than the declared gas limit. My suggestion: the first and last intention (representing token transfers) should be subsidized, if the use case is important.
It’s out of the scope of this solution to consider how the relayer interacts with the sender, and also is out of scope the analysis of any attack via a rogue relayer or sender. I think those issues could be covered but with more context, describing in detail the real use cases. That analysis is not part of the current solution. We could leverage existing knowledge from Gas Station Network experience, or others. And in many cases, the relayer is only one, and under our control (no rogue relayer).
With the help of JR, I just wrote a RSK Improvement proposal: https://github.com/rsksmart/RSKIPs/issues/166
Alea jacta est
Angel “Java” Lopez