Author: Tommy Hang
[01.24.24] This article is an introduction to the research conducted by Blockchain at Berkeley to build out a novel mechanism. The Arbitrum Bypasser is a tool that allows users to submit transactions to Arbitrum from the underlying Ethereum chain, bypassing centralized sequencers as an alternative to submitting transactions.
Introduction
A pressing issue within the blockchain space is the reliability and trust of nodes on a network. These nodes in many cases have censorship capabilities that can prevent transactions from being executed, namely on prominent Layer 1 chains. In fact, network reliability for a blockchain could be compromised at any point, whether through censorship by an RPC node, or even something as simple as sequencer downtime. Furthermore, bridging and switching between chain-specific applications represent a large portion of this issue that needs to be addressed.
As the industry is designed and predicated on the mission to minimize censorship and increase accessibility, creating tools and infrastructure to handle potential threats to these pillars of the space is essential. It is advantageous for chains to implement user-friendly and censorship resistant architecture, such as seamless bridging and viable cross-chain executions. An initial step towards this prospective future is to develop cross-chain execution mechanisms that can execute transactions on an L2 from an L1. But before we can derive a solution, let’s pick a specific chain and study how transactions are processed and included.
Arbitrum One Architecture
Arbitrum is the popular Ethereum Layer 2 chain which has dominated the L2 race in regards to TVL for the past months. In particular, Arbitrum One is an optimisic rollup chain built on their Nitro technology stack, which provides us with a good look at how transactions are organized and validated.
As denoted from the image below, we see that there exists a sequencer at the intersection of submission and execution. This sequencer is offchain and centralized, which poses risks to sequencer downtime events that can uphold blocks for upwards of 10 hours. Such had happened on December 15th, 2023 as we faced an outage on the Arbitrum chain due to high traffic of transactions.
Let’s view this from a transaction perspective. Typically, Ethereum users interact with protocols on an L2 such as Arbitrum via the respective chain. Users call from the L2, interact from the L2, and sign into L2 dapps. On Arbitrum, all of these aforementioned transactions are sent towards an ‘L2 inbox’ which functions similarly to that of a mempool. Here, the sequencer can pull, order, and batch transactions to finally submit back onchain. Given an event of high inflows of transactions, a centralized offchain sequencer is bound to run into issues when sequentially reviewing and batching transactions.
Fortunately, Arbitrum offers an alternative called the ‘delayed inbox’ which allows for intakes submitted from the underlying L1 via L1–to-L2 messaging. In this case, borrowing the upkeep and security of a stronger asset like Ethereum allows for a bypass in the submission process of the Arbitrum transaction lifecycle. This ‘delayed inbox’ also inherits a unique feature where transactions become eligible to be force included if they have been within the inbox for over 24 hours. With this architecture in mind, users should be able to seamlessly execute transactions on Arbitrum from their Ethereum accounts as a solution.
Our Solution
Allowing a user to bypass the Arbitrum centralized sequencer is simply a matter of pre-signing an L2 transaction on an L1, bridging the transaction from L1 to L2, submitting to the ‘delayed inbox’, and calling forceInclude given that the requirements are met.
Although pretty straightforward, there are minor technicalities that must be accounted for in order for a seamless integration of said approach.
-
Pre-signing a transaction requires custodied knowledge of a private key or the usage of a deprecated function called
eth_signin order to sign a transaction without broadcasting. -
Once this pre-signed transaction is settled, the contract bridges over this transaction object to the delayed inbox on Arbitrum where the user now awaits their transaction.
-
If after 15 minutes and then a subsequent 24 hours passes, the transaction is eligible for a force inclusion which a user can execute to ensure with complete fault tolerance that their transaction settles on Arbitrum.
-
In the logic signature, the user will be sending a default gas buffer of 20% (adjustable by the user’s need) to account for the time delay between the initial transaction submission and the foreseen transaction inclusion. This will ensure that if the price of the gas fee increases, there will be a sufficient amount to satisfy the criteria.
Caveats and Usages
Malicious Sequencer Concerns:
-
Scenario: Users want to withdraw their ETH on the Arbitrum Network but are concerned about the sequencer’s integrity.
-
Use Case: If there are suspicions or evidence that the sequencer is acting maliciously, manipulating transaction orders, or censoring certain transactions, users can use the bypass tool to execute their withdrawals directly, ensuring their transactions are processed fairly and without tampering.
Sequencer Downtime:
-
Scenario: Users need to execute urgent transactions on the Arbitrum Network, but the sequencer is down, rendering them unable to access their funds.
-
Use Case: In such a scenario, the bypass tool becomes a critical alternative, allowing users to carry out transactions like fund withdrawals or time-sensitive trades, ensuring access to their assets even when the primary sequencer system fails.
High Transaction Fees:
-
Scenario: The sequencer on the Arbitrum Network is operational but is charging exorbitant transaction fees due to high demand.
-
Use Case: Users could use the bypass tool to execute their transactions at potentially lower costs, providing a cost-effective alternative to the main sequencer during peak times.
Transaction Censorship:
-
Scenario: A user wants to participate in a decentralized finance (DeFi) platform but finds their transactions consistently blocked or delayed by the sequencer due to unknown reasons.
-
Use Case: The bypass tool allows the user to circumvent such censorship, ensuring that their participation in DeFi platforms is not hindered by external control.
Network Congestion:
-
Scenario: Users are trying to take advantage of a fleeting opportunity in a token swap on the Arbitrum Network, but the network is congested, leading to slow transaction processing by the sequencer.
-
Use Case: The bypass tool enables users to quickly execute their transactions, such as token swaps, without having to wait in the sequencer’s backlog, allowing them to capitalize on time-sensitive trading opportunities.
Security Redundancy:
-
Scenario: Rumors or indications emerge about a potential security threat to the sequencer, causing users to worry about the safety of their transactions.
-
Use Case: The bypass tool provides an alternative, more secure pathway for users to execute their transactions, offering peace of mind and enhancing the overall security of the network.
Conclusion
Traditionally, Ethereum users could only interact with protocols on an L2 such as Arbitrum through its L2 inbox and centralized sequencer. But now, our tool allows Ethereum users to execute transactions on Arbitrum One directly from their Ethereum wallet.
Firstly, transaction submission is bypassed by sending their presigned L2 transaction to a contract on Ethereum which then bridges the presigned L2 transaction to a delayed inbox on Arbitrum One. Secondly, users are then given the option to force include their transaction if it is never picked up by the sequencer from this secondary inbox, thereby circumventing the L2 sequencer in transaction inclusion.
This tool and front-end address user experience challenges and reduce censorship risks associated with previously necessary bridge operators, providing a solution to downtimes from centralized L2 sequencers. You can access the live prototype here.
Team & Contributors
Team: Jay Tiperneti, Tommy Hang, Dhruv Gautam, Arjun Patrawala, Vardhan Shorewala, Jessica Situ, Rishi Thakar
Special thanks to Mehdi Salehi, Hunter Brea for technical support throughout the process.