Extended Transactions
Recently, I wrote about transaction in blockchains: Free transactions in RSK, and Composite Transactions. I think that a pattern emerged from those proposals: a transaction could have additional arguments and meaning.
So, in this post, I propose the Extended Transaction:
It’s like an envelope: a pattern used in messaging, and even in RSK code (read the RSKMessage class). Inside a transaction there is another transaction (the inner transaction) but adorned with additional arguments.
In this way, a free transaction with sponsor, could be represented as:
A transaction that requires multiple signatures could be implemented as:
(I don’t know the use cases for such transaction, but ii is needed, it could covered using an extender/envelope transaction).
At the end, we could support THREE kinds of transactions:
And a inner transaction could be of any of these three kinds. Ie, a composite transaction (many transactions with the same sender) could be sponsored by another account:
It’s like a “russian doll”/”matryoshka doll” of transactions.
Implementation
My first thought was that the support of different transactions would require many changes to the inner code of a node (Ethereum or RSK). But thanks to an original idea from NPS (RSL core development team member), I could implement all this in this simple way. Take as an example the sponsored transaction.
The transaction to send to the node is one with the original sender, but having as receiver a reserved address (like a precompiled contract address) designed to sponsored transactions. AND the transaction data (the field reserved usuallu for smart contract invocation) containing the RLP of:
- The original transaction to be sponsored (the inner transaction)
- The sponsor signature of the inner transaction, declaring the acceptance of covering the gas cost of the inner transaction
In this way, no change to the inner format of the transaction is needed: only a bit of work from the DApp side to build such envelope transaction. The same “trick” could be applied to composite transaction, Or to any future extended transaction that could be defined: the receiver dedicated address indicates the kind of transaction, and the data payload contains the inner transaction and additional arguments. And the transaction could be relayed to other nodes WITHOUT changing the original wire protocol: it is a normal transaction, at least from the RLP encoding point of view.
Angel “Java” Lopez