Paying Transactions using Tokens
In Ethereum and Ehtereum-like blockchains (like RSK, Celo…) the sender of a transaction should pay the cost of the invocation using their balance. But there are scenarios where the user is a new one, and still don’t have any ether. Example: there is a new game running in the blockchain. The new users arrives to the game website, where there is a graphics interface to play the game (ie an space ships battle). At the end, the user moves are implemented in blockchain transactions. The game website and browser code creates an account to each new user. But it has no balance. How to play the game?
Yes, the game company could provide the initial balance, but not sure if such balance will be used for the game. So, an alternative is: the user pay the game transaction using a token, the game token provided by the game company.
Having single transactions, sponsored transactions, composite transactions and extended transactions proposals, in this blog post I will describe two possible solutions.
Using Sponsored Transactions
The first solution is based on having a composite transaction, to be sponsored by a game sponsor. The composite transaction declares the user intentions of:
- Pay the sponsor in tokens
- Invoke the game
This is the final transaction:
The game dapp workflow could be:
1- The DApp makes and sends the composite transaction to an sponsor public API.
2- The sponsor logic validates the composite transaction, checks the availability of user tokens, checks that the sender nonce is not too advanced, etc. If it is all OK, it returns the sponsor signature
3- The DApp builds the raw transaction representing the sponsored transaction with the composite transaction inside, and sends it to RSK node, as an usual transaction
Using Extended Transactions
But there is another way: to pay the miner in tokens. This way could be used in more general scenarios, not limited to a game and a game sponsor. Ie, you want that the token owners could find value in the tokens they have, using them to pay any transaction.
I could use an extended transaction: having an inner transaction and additional arguments:
The executor of this extended transaction (probably a precompiled smart contract, or specialized logic) should be declared as a manager of the token, allowing it to transfer tokens from one account to another. The miner could accept or reject the proposed extended transaction, depending on the token and amount offered (as usual with gas limit and gas price). A difference with the previous proposal (based on sponsored transactions): the validation of this extended transaction is executed in each node that receives and relays this transaction. Instead, in the sponsored transaction, that validation is executed by the sponsor API logic. Another difference: this proposal is decentralized, but the previous one requires the presence and availability of an sponsor public API.