We’re considering adding a feature to the sequencer that allows clients to submit a bundle of transactions, that is, a set of multiple transactions, in a single submission. The sequencer would promise to include those transactions consecutively in its ordering, with no other transactions interleaved among them.
The sequencer already sequences transactions in the order they arrived at the sequencer, so the result would be as if all of the transactions in the bundle arrived consecutively. The bundles wouldn’t get earlier or later position in the sequence by virtue of being bundles. We wouldn’t guarantee that the transactions in a bundle will end up in the same block, only that no other user transactions will be between them.
We think this bundle functionality is useful for some use cases, for example to carry out a sequence of DeFi transactions that rely on an assumption that no other transactions intervene. It also makes some kinds of account abstraction approaches easier to implement.
Of course we would limit the total size of bundles, or the total gas consumed by a bundle, to some reasonable limit.
We’re interested in hearing thoughts on this. Would you use it? Are there any constraints we should take into consideration?
77 Likes
I like it! Could be useful for gasless transactions, in which one tx in the bundle pays gas for all of the other transactions. In addition, it would be cool to create programmability into the bundle submission for condition reversion of other transactions in the bundle revert and perhaps other powerful controls.
Are you planning to include a way for transactions to figure out the contents of the bundle they are in (block.bundlehash)? If this was possible, along with the conditional reversion, you may be able to implement cross transaction flashloans! Just submit a bundle [flashLoan(), doStuff(), repay()], and the flashLoan() tx would have functionality to revert in case the repay() tx failed.
One concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.
28 Likes
We weren’t looking to change the semantics of execution on the chain, only how transactions are submitted. The transactions would still execute normally, without any additional affordances, so the only difference from normal submission would be that transactions in a bundle would run consecutively without any others interleaved between them (assuming an honest sequencer).
Stronger notions of bundling that change the execution model could accomplish more, but are a much heavier lift in terms of implementation, and would introduce incompatibilities with Ethereum.
19 Likes
A really common use case for this would be bundling an approval and an action together, e.g. approving a router and making a swap, or approving a vault and depositing funds into it. In my opinion this is a really useful abstraction.
One thing that you should be mindful of is that this could change the security model of DeFi protocols. In particular, some contracts rely on the (bad) assumption that EOAs cannot atomically make many transactions in a row. If that assumption is broken then it might open up protocols to economic vulnerabilities. Many protocols with this assumption use require(msg.sender == tx.origin) to ensure that only EOAs are interacting with certain functions.
As far as I can tell DeFi protocols have moved away from this assumption because it’s never been a sound one to make in the long run. But opening up the space for atomic EOA execution does change the security model for some contracts, so you should make sure to communicate that if you make this change.
13 Likes
We would not guarantee that the transactions in a bundle execute as a single atomic unit. We would only guarantee that no other transactions come between them. It would still be possible for some transactions in the bundle to revert while others succeed.
16 Likes
Would all transactions in a bundle be required to share the same sender address, or can clients indiscriminately reorder bundles of arbitrary transactions before submitting them to the sequencer? Would submitting sequencer bundles be permissionless? How do we define client in this context, is it any transaction signer or is it only a specific piece of Arbitrum infrastructure? Considering that the policy of the sequencer is “first come, first serve,” it’s important to understand if a third party service can violate that policy within a bundle, for better or for worse.
There might be an engineering hurdle for composing sequencer bundles from regular user wallets, because I think there isn’t a universal method that wallets use to handle setting a transaction’s nonce or a universal method for when to broadcast a signed transaction.
It seems like if an average user wanted to submit a bundle, they would require an intermediary that intercepts their signed transactions until they submit their entire bundle, because I think the default behavior of e.g. Metamask is to submit a transaction to the rpc endpoint as soon as it is signed.
In theory, a static webpage could allow users to aggregate signed transactions into a bundle using the eth_sign rpc method to sign raw transaction hashes, but that would be a downgrade to the user’s experience and would empower phishing scams.
Overall, I’m curious if access to submitting transaction bundles would be offered exclusively to some restricted definition of “clients,” or if this also is meant to provide access directly to individuals who might want to submit an approve and deposit bundle. Arbitrum is designed to offer a seamless experience to Ethereum users, and the approach to integrating sequencer bundles into existing wallets will be important if users are given direct access to this service.
20 Likes
The version of this that seems the most useful and straightforward to implement is to (1) not restrict which transactions can be submitted in the same bundle (except for limits on total bundle size), and (2) not restrict who can submit bundles. That is, a bundle is just another way to submit a set of multiple transactions, with the same result as if you submitted the transactions one at a time and it turned out that no other transactions arrived in between yours.
If you route your transactions through a third party, it could reorder them within a bundle. That’s basically the same issue you have now if you submit multiple transactions through a third party–it can reorder them if it wants.
Also, a dishonest sequencer could reorder or drop the transactions within your bundle. Again, that’s basically what it can already do to transactions submitted one at a time.
11 Likes
Seems like a nobrainer to support a feature like this. I wouldn’t optimise for making it trustless since you are already trusting the sequencer.
15 Likes
@stonecoldpat What do you mean? Could you clarify your statement pls
6 Likes
Hi!
I wanted to check if the idea of bundles transactions is implemented or not, and if yes is there a document on how to use it?
nice
One concern is how trustless this is. Is the bundle not being broken up somehow ensured via changes to the fraud proof mechanism or is it based off of trust in the sequencer? There are scenarios in which it is detrimental to break up the bundle.
1 Like
The easiest way to do this would be to trust the sequencer to not separate the transactions in the bundle. This is straightforward to implement because one would just need to add an RPC to submit a set of transactions that are meant to be a bundle. Nothing on-chain would need to change.
Enforcing bundling is more difficult because it would need to be the case that the sequencer cannot (say) extract one transaction from the bundle and just post that one. And that, in turn, seems to require that the transactions in the bundle can’t be separable from each other. That means, for example, that it won’t work to include each transaction’s data in encodable format along with a signature on that one transaction. Instead, the transactions in the bundle would somehow need to be entangled so that each one is invalid unless attached to the others.
One way to build non-separable transactions is to use a facility like ERC-4337 account abstraction, which is currently on Arbitrum’s testnet at the moment.
1 Like