owned this note
owned this note
Published
Linked with GitHub
# Bundle imitation on Arbitrum
# Introduction
On EVM-based chains, a transaction is considered an atomic unit, meaning it is indivisible and irreducible. Its execution is an all-or-nothing affair: either the entire transaction is executed, or none of it is. This atomic behaviour does not extend to a set of transactions, which can be freely reordered or cherry-picked. On Ethereum, the block producer has the final say on the ordering and inclusion of transactions. Before the "merge," this role was filled by miners; after the merge, it is the validators or block-builders under PBS. Block producers have the power to extend the atomic behaviour of an individual transaction to a set of transactions. In 2021, Flashbots introduced the concept of bundles, making such behaviour available to all participants, as long as they trust the block producer to whom the bundles are sent. In a bundle, any transaction is committed to the chain only if all transactions in the bundle are committed, and in the specified order. This extension of atomic behaviour has made existing value extraction strategies that depend on order flow less risky and has unlocked new ones.
At the time of writing, Arbitrum receives and orders all transactions through a centralised sequencer and lacks the composability required for the introduction of bundles from third parties, as was the case for Ethereum. This poses unique challenges for transaction management and limits the strategies participants can execute. The need for such features is especially pronounced given the increasing prevalence of exclusive order flow sales.
To bridge this gap, we began a study a month ago focusing on how Arbitrum handles the order of sequential transactions within a single block. Although there's no worry about Arbitrum's central sequencer selectively choosing individual transactions, there is ambiguity concerning how transactions sent close together in time are ordered, particularly given Arbitrum's First-In-First-Out (FIFO) system. The main goal of our study was to investigate whether transactions submitted in quick succession or via BatchRPC end up positioned next to each other within the same block, while also preserving their original order of submission.
# **Methodology**
We conducted series of tests in which two transactions were sent out simultaneously or in succession. We refer to the set of these two transactions as a transaction-pair. The aim was to find out the prevalence of placement of transaction-pair that mimicked placement of a bundle, we refer to this placement as desired-placement.
The testing tool used custom Arbitrum sequence-feeder to listen for new sequence(future block), waited for random time between 0 and 200ms and then transactions were simultaneously dispatched to Arbitrum sequencer’s RPC endpoint (https://arb1-sequencer.arbitrum.io/rpc) and Arbitrum’s public node (https://arb1.arbitrum.io/rpc). The test was conducted every 10th block.
The data was analysed using in-house Arbitrum ETL.
### Submission modes
The tests were conducted in different modes of submission, namely:
- **Asynchronous Mode**
Futures for transaction requests are initiated together in a specified order.
- **Delayed Submission**
Implemented a time delay between the dispatch of individual requests.
- **Batch RPC**
Both transactions were sent as a single RPC call using batch requests. For more information on JSON-RPC batch requests, see [here](https://sajya.github.io/docs/batch/).
### **Data Labeling**
Transactions were labeled with the following metadata:
- `block_number`: The block height at which the transactions were submitted.
- `tx_index`: The transaction ID specific to the block.
- `provider_id`: The provider to which the transaction was sent.
- `wait_time`: What was the delay between receiving the notification of a new block and submitting the transactions. In milliseconds.
# Tests
1. First two tests were conducted in async submission mode, one from Lisbon and one from Oregon.
2. First two tests were conducted from Lisbon, one in BatchRPC and the other in Async submission mode.
3. The tests from two modes were repeated in Oregon.
4. Results from the Async mode indicated that the sequencer of transactions was incorrect in half of the transaction-pairs. Thus test with Delay mode was conducted from Oregon.
5. Results from the Batch mode showed significant variance in the first transaction in the transaction-pair landing last in the block. It was suspected that transaction volume influenced the results, so another BatchRPC test was run in Oregon at part of the day with different transaction frequency to challenge this assumption.
6. Two more tests were run in Delay mode, one from Lisbon and the other one from Oregon
# Findings
## Async and Delayed mode
In both Async and Delayed mode the transactions within transaction-pair are submitted one after the other. In Async mode this is done almost instantaneously, while for Delayed mode some delay is introduced.
### Placement Qualities
Transaction-pair placement will be compared to how a bundle would be placed - as if pair was an atomic unit. Transactions in a bundle are placed in the same block, in order they were sent and adjacent to each other. The presence of these three qualities is judged separately as well as combination of three. Transaction-pair placement that satisfies all three qualities is referred as “Desired placement”.
![](https://hackmd.io/_uploads/SktMRc4-T.png)
All the pairs were submitted to two providers at the same time. The rate of transactions from the same pair being processed by different providers was also considered.
### Results
| | Lisbon Async | Oregon Async | Oregon Delayed (10ms) | Oregon Delayed (5ms) | Lisbon Delayed (5ms) |
| --- | --- | --- | --- | --- | --- |
| Pairs | 1323 | 1193 | 348 | 1443 | 1422 |
| DifferentProvider¹ | 46% | 36% | 38% | 47% | 49% |
| DifferentBlock² | 21% | 8% | 15% | 11% | 9% |
| SameBlock & Disjoint³ | 1.8% | 2% | 8% | 5% | 5% |
| SameBlock & WrongOrder⁴ | 37% | 47% | 1% | 5% | 21% |
| DesiredPlacement⁵ | 41% | 44% | 76% | 79% | 64% |
*¹ Transactions were processed by two different providers.
² Transactions landed in two different blocks.
³ Transactions were not adjacent to each other.
⁴ Transactions were not placed in order they were submitted in.
⁵ Transactions were placed in the same block in the order they were submitted in, adjacent to each other.*
Below are proportions adjusted only for pairs placed in the same block.
| | Lisbon Async | Oregon Async | Oregon Delayed (10ms) | Oregon Delayed (5ms) | Lisbon Delayed (5ms) |
| --- | --- | --- | --- | --- | --- |
| Disjoint | 2% | 2% | 9% | 6% | 6% |
| WrongOrder | 47% | 51% | 1% | 6% | 23% |
| DesiredPlacement | 52% | 48% | 89% | 89% | 70% |
### Key findings
- **The rate of transactions landing in different blocks ranged from 8% to 21%. Our analysis found no significant correlation between this rate and either the location or the mode of submission.**
The rate of transaction-pair landing in two different blocks varied between 8% and 21% overall. Location-wise it was 8-15% for Oregon and 9-21% for Lisbon. Mode-wise it was 8-21% for Async-mode and 9-15% for Delayed-mode.
There is no significant relation between between rate of missed-block and considered factors. This could indicate there are other, unknown, factors influencing the result.
- **Delayed submission slightly increased the rate of disjoint placements.**
With Async modes from both Lisbon and Oregon, approximately 2% of the transaction-pairs were placed disjoint. This rate jumped to 8% for a 10ms delay and 5% for 5ms delay between submissions.
The result is expected as the bigger the delay, the bigger should be the chance of an external transaction being placed in-between transactions.
- **Delay submission increases the rate of correct ordering**
With Async mode the rate of incorrect ordering was 37-47%. For Delayed mode the rate decreased to 21% for Lisbon and 1-5% for Oregon.
The results is expected as the bigger the delay the smaller should be a chance of mismatched ordering of transactions.
- **Delayed submission increases rate of desired placements**
Combining all factors, with Async mode the rate of desired placement was 41-44% and with Delayed mode 64-79%. Results show that using delay between transaction submission significantly increases the chance of bundle-like placement of transaction-pair.
- **Geographical proximity to the sequencer increased the rate of desired placements for Delay submission mode**
Our tests showed the rate of desired placement for Oregon to be 76-79% and 64% for Lisbon. The biggest factor affecting this was transaction ordering.
To our current knowledge the Cloudflare datacenter with latest ping to the Arbitrum sequencer and public node is in Oregon.
- **Almost half of the transaction-pairs were handled by two different RPC providers**
Across all tests there were between 36% and 49% pairs where two transactions were handled by two different RPC providers.
## Batch mode
Arbitrum public node and Sequencer RPC both support BatchRPC calls, which can deliver multiple RPC calls in single request.
Initially, we assumed that transmitting multiple transactions in this format would prompt the sequencer to place them adjacently. However, our findings contradicted this: sending multiple transactions via a single batch RPC call results in each transaction being placed in its own separate block.
These findings showed that the BatchRPC call doesn’t imitate features of a bundle in a single block. Nevertheless, certain inter-block ordering can imitate the effects of bundle. That is transaction-pair that lands in two adjacent block, where the first transaction lands on the bottom of the first block and the second transaction on the top of the second block. Note that such scenario imitates a bundle containing maximum two transactions.
![](https://hackmd.io/_uploads/HknNpKVZT.png)
### Placement Qualities
We investigated the possibility of BatchRPC submission imitating the effect of a bundle. For that we looked into:
- correct block ordering;
- the block difference between two transactions;
- proportion of first transactions landing on the bottom of the block;
- proportion of second transaction landing on top of the block;
- combination of above factors.
### Results
| | Lisbon | Oregon 1 | Oregon 2 |
| --- | --- | --- | --- |
| Pairs | 1171 | 979 | 1293 |
| CorrectBlockOrder¹ | 100% | 100% | 100% |
| OneBlockDifference² | 99.9% | 99.6% | 99.9% |
| FirstTxOnBottom³ | 84% | 41% | 76% |
| SecondTxOnTop⁴ | 96% | 88% | 95% |
| ScndTxOnTopInNextBlock⁵ | 96% | 88% | 95% |
| DesiredPlacement⁶ | 81% | 36% | 72% |
*¹ First transaction in block N and second one in block M, where M > N.
² First transaction in block N and second one in block N+1.
³ First transaction is the last one in the block.
⁴ Transaction-index of the second transaction is zero (First one in the block).
⁵ OneBlockDifference & SecondTxOnTop.
⁶ OneBlockDifference & FirstTxOnBottom & SecondTxOnTop.*
### **Key Observations**
- **Transaction-pairs submitted via Batch-RPC consistently resulted in correctly ordered placement in 100% of the cases.**
- **In almost all cases transaction-pair was placed in adjacent blocks.**
No pair was placed in the same block and for 99% of the cases blocks, transactions were placed in, were adjacent.
- **The rate for transaction-pairs having first transaction on the bottom of the block varied between 41% and 84%**
- **The rate for transaction-pairs having second transaction on the top of the block varied between 88% and 96%.**
- **Desired placement varied between 36% and 81%**
Such variance indicates there are other factors, not yet considered, affecting the results.
- **Geolocation does not significantly influence the results**
### **Factors Influencing Variation**
There was 43% variation for placement of first transaction on the bottom of the block and 8% variation for placement of second transaction on the top of the block. Both could be explained by transaction volume at the time of the testing.
The greater the transaction volume at the time of submission, the higher the likelihood that an external transaction will be inserted after your transaction is accepted by the sequencer but before the block sequence is finalised.
Below is transaction volume for the period particular test was performed in (expressed as number of transactions per block) accompanied by FirstTxOnBottom and SecondTxOnTop columns from the Results table.
| Test | Txs/Block | FirstTxOnBottom | SecondTxOnTop |
| --- | --- | --- | --- |
| Lisbon | 2.7 | 84% | 96% |
| Oregon 1 | 3.4 | 41% | 88% |
| Oregon 2 | 2.5 | 76% | 95% |
The results seem to confirm our assumption that transaction volume and the proportion of the transactions placed on top or bottom of the block are inversely related.
![](https://hackmd.io/_uploads/r16IaYNWp.png)
The transaction volume diagram for the last two weeks of September indicates that the fluctuations in transactions per block could exceed those recorded during our tests. This could cause even greater fluctuation in the rate of desired placement.
# Conclusion
## **Summary and Key Findings**
This study aimed to address the gap in transaction management on the Arbitrum network by investigating how sequential transactions are processed within an Arbitrum block. Utilising a series of tests including Asynchronous, Delayed, and Batch RPC modes, we found varying degrees of success in achieving bundle-like placements of transaction-pairs.
- **Async and Delayed Mode**: The tests indicated that Delayed submission modes outperformed Asynchronous modes in achieving desired placements. The success rate for correct transaction ordering ranged from 1% to 5%. Proximity to the sequencer improved the desired placement rate, making it 76% and 79% for submissions from Oregon.
- **Batch Mode**: While it offers a 100% guarantee for correct transaction ordering, it shows inconsistent desired placement rates, ranging between 36% and 81% in our tests. Moreover, our data suggests that the actual variance could be even higher. Geolocation didn’t play any significant role.
## **Interpretation and Implications**
Our results suggest that while perfect emulation of bundle features is currently not possible on Arbitrum with the methods we tested for, there are methodologies that can increase the likelihood of desired transaction placements. These insights are particularly valuable for teams who rely on specific transaction placements for their strategies.
## **Future Research Directions**
### **Enhancing Accuracy**
For more robust and reliable results, future studies should consider increasing the sample size and extending the block periods for less biased data. Additionally, the effect of transaction volume on Async and Delayed mode should be explored.
### ****Exploring Conditional Transactions****
Arbitrum’s conditional transaction feature allows transaction to execute only if certain block-number or storage-slot conditions are met. For more details, see [eth_sendRawTransactionConditional](https://notes.ethereum.org/@yoav/SkaX2lS9j). This offers alternative strategies for achieving desired placement.
1. **Phantom Flow**
Send two simultaneous batch-RPC requests, each containing a phantom conditional transaction that cannot execute first, followed by a real transaction. These real transactions are scheduled for the subsequent block. It will be worth investigating whether adding more phantom transactions in each batch-RPC request improves the desired placement rate.
2. **Fill Or Kill**
Submit two Delayed Mode transactions with the precondition that both must be executed in the following block. Our current data suggests that 90% of Delayed Mode transactions placed in the same block achieve the desired placement.
## Arbitrum bundle support
[At SBC 2023 OffchainLabs(Arbitrum team) mentioned Arbitrum will support bundles in the near future.](https://youtu.be/dZfSbtBOGAQ?si=NjiuhpJrzo5OVpF0&t=986) There is an open discussion about bundle support on Arbitrum's [research forum](https://research.arbitrum.io/t/submitting-transaction-bundles/75/18).
---
We encourage you to repeat the tests and challenge our methods and assumptions.
Miha Lotric ([TG](https://t.me/themiha)/[X](https://twitter.com/MihaLotric))