Composite Transactions
In blockains like Ethereum and RSK, there are scenarios where a user wants to execute two or more transactions, as an atomic transaction. The classic example is the ERC29 approvecombined with an invocation to a smart contract that use the transferFrom method (read Ethereum smart service payment with tokens).
Another recent use case is to do something similar to a flash loan, using DeFi smart contracts.
There is an Ethereum Improvement Proposal to allow such calls: Rich Transactions Draft. But it requires to send bytecodes in the transaction data, and those bytecodes should be generated, a task that could not be easy with current tools. I like the proposal, but I was thinking another approach: having a composita transaction:
Such transaction contains two or more transactions, that should be valid (nonce, sender signature, balances, etc). But when such transaction is included in a block, it should be FULLY included. And the execution should be atomic: if one of the contained transaction reverts, all the storage and changes should be reverted.
Usuallu the dapp should build the composite transaction. One option is to build an RLP encoding with a short field indicating that is a composite transaction, and then, a list of transactions. The message could be send to a node using the classical eth_sendRawTransactin
If the composite transaction is valid, the node will relay it, in the same format: the message should contain the composite transaction, so, when the miner select the transaction to be included in a block, the original association should not be lost.
It is easy to add such functionality in current RSK code. So, after this enhancement, there will be TWO kind of transactions:
Notably, a composite transaction could contain a transaction that is also composite, like in the composite pattern.
To support more kinds of transactions and use cases, I was thinking on envelop transactions, a generalization of sponsored transactions that I described in my post Free Transactions in RSK. I will describe them in an upcoming post. Having single, composite and envelop transaction, I think that many current use cases, and even some future ones, could be implemented using these ideas.
Angel “Java” Lopez