Optimistic Rollups and Ethereum's Layer-2 Solutions: Examining Arbitrum's Security Mechanism

Layer 2 scaling solutions are the hottest topic in the current Ethereum discourse, and also amongst the entire blockchain technology community. Arbitrum, the Layer 2 scaling solution based on Optimistic Rollups, has become the most compelling Layer 2 solution at the present time, after being the first to deploy the beta version of its mainnet, and gaining support from core DeFi projects such as Uniswap and Compound.

The security mechanism of the Layer 2 solution is one of the most important concerns for users who intend to migrate from the Ethereum mainnet to Layer 2. In this article, we will do a deep dive into the Arbitrum security mechanism, including how Arbitrum is rooted in the security of Ethereum, why the challenge period is 7 days, and how to defend against censorship attacks.

Rooted in the security of Ethereum

We all know that one of the biggest advantages of Layer 2 over other scaling solutions is that it fully is rooted in the security of Ethereum, most people probably know this, but don't know why. How is Arbitrum rooted in the security of Ethereum?

Let’s review the main features of the Optimistic Rollup solution first:

1. In a Rollup solution, transactions are written on L1 (as calldata), but the actual computation and storage of the contract are done on L2, as a way to achieve scaling.

2. A validator posts an assertion on L1, which can be understood as packaging all transactions and results in a Rollup block into a transaction on L1.

3. Optimistic Rollup refers to a type of rollup that is optimistic in the sense that when an assertion is posted, it does not contain an accompanying proof guaranteeing its validity. Instead, there is a time window in which anyone can challenge the assertion. If the challenge is successful, all transactions contained in this assertion will be withdrawn and asserters will lose their bond. If the challenge period expires with no successful challenges, the assertion is accepted and becomes final.

After understanding the specific solution, let's consider how Arbitrum is rooted in the security of Ethereum from several perspectives.

Data availability

All transactions executed on L2 are first submitted to the Inbox smart contract running on L1, and written on L1 as calldata. Anyone can use this data to retrieve all transactions on L2 and recover L2 to its original state. The availability of this data is guaranteed through L1 and users do not have to worry about L2 failures that will incur losses for their assets on L2.

AnyTrust

AnyTrust is a key security feature of the Rollup protocol. This feature means that any honest verifier can forcefully ensure the correct execution of transactions on L2. No matter how many malicious people try to stop the transactions, you or someone you hire can forcefully ensure that transactions are carried out correctly, with no need to trust any third party.

Emergency exit mechanism

Arbitrum does not specifically define the emergency exit mechanism currently, but a series of security mechanisms are in place to ensure that users have recourse to an emergency exit.

First of all, data availability ensures that users' assets and data on L2 can be recovered from L1 at any time and are never lost.

Secondly, any user can send a transaction request to the Inbox contract on L1 to force a withdrawal.

Finally, the AnyTrust mechanism ensures that users can force L2 to process the withdrawal transaction correctly.

For all the above three points, users do not need to trust any third party, which fully demonstrates that Arbitrum is rooted in the security of Ethereum and is trustless.

Why the challenge period is 7 days

Arbitrum is a multi-round interactive Rollup solution. The solution will first optimistically believe that the assertion made by the verifier is correct until it is challenged or refuted by other verifiers during the challenge period. In most cases, there are no challenges and the entire system can make progress faster and at a lower cost.

Obviously, the longer the challenge period is, the safer the entire system is, but at the same time the user experience would be worse (because users need to wait until the challenge period ends when withdrawing). So how do we find the optimal challenge period?

The Arbitrum team proposed such a model to calculate the optimal challenge period:

1. Assuming that a challenge period is the length of C blocks and the maximum value that an attacker could get on L2 is V,

then the expected value got by the attacker is V exp(-AC).

Note: exp is the exponential function "e", A is some constant A, the "-" sign before AC means that C is inversely proportional to the expected return.

2.The asserter needs to pledge assets far greater than the value of the attack to respond to the attack. We assume that it is 10 times, and the cost of the asserter is 10V exp(-AC)I. I is the capital interest rate.

3. We assume that the withdrawal assets of the withdrawal user locked in the challenge period are CWV (where W is a small decimal, WV is part of the total assets on L2, each time point will have C blocks that have not ended the challenge) and the cost of assets for users is CWVI.

4. The length of the optimal challenge period is at the lowest total cost of assets of asserters and withdrawal users. That is, when the value of C is taken, 10V exp(-AC)I+CWVI is at a minimum. V and I occurs in both terms, it won’t affect the minimum point and can be ignored. We just need to take the derivative of C, setting the resulting derivative equal to 0, and get C = ln(10A / W) / A.

Now we plug in some plausible numbers into the above equation to get a rough optimal challenge period.

Assuming that the success rate of continuous censorship for one block time is as high as 99.99%, which amounts to A = -ln(0.99) = 0.01.

Further assuming that 1% of the total value is withdrawn each day and that the percentage of withdrawals per block is approximately W=0.000002, based on 1 block in 15 seconds.

Plugging these into the formula, we get an optimal challenge delay of C = 62146 blocks, which is 10.79 days, which is very close to the 7-day optimal challenge period finally chosen by the Arbitrum team.

How to defend against censorship attacks

In this section we discuss how Arbitrum defends against the four main types of censorship attacks: forking attacks, shunning attacks, jamming attacks, and speed demon attacks.

Forking attacks: miners conspire (or are bribed) to discard blocks that contain normal challenges so that an alternative chain not containing a challenge is accepted.

First of all, due to the existence of challengers, once a forking attack occurs, it will inevitably be discovered by a certain challenger. And when everyone finds out mining power monopolists in the blockchain (which is a prerequisite for a forking attack) are breaking the rules without constraint for profit, the blockchain in itself has been devastated. At this time, the point is moot whether Arbitrum adopts the challenge period design model or not.

Shunning attacks: miners conspire (or are bribed) to omit normal challenges from the blocks they make.

We assume that the monopolist controls 90% of the mining power and the deadline is 50 blocks. 50 consecutive blocks are required to be packaged by the monopolist to complete the attack. The probability is 0.9 to the 50th power, which is only 0.5%. And the actual challenge period is far more than 50 blocks, so the probability of a successful attack is extremely small. In the design of Arbitrum, the attacker will pay a large fine when an attack fails, and it is quite uneconomical for the monopolist to launch a shunning attack.

Jamming attacks: the attacker launches an 'old-fashioned denial of service attack' (DoS) to prevent that party from posting any transactions (not able to post transactions containing challenges).

Since the attack will fail as long as there is a virtuous challenger, the attacker must jam all possible challengers. If there are many such challengers, the attack will already be difficult to accomplish. Worse yet, any interested party might have hired a silent watcher as a backup plan. They only step in when the primary participants seem too late or have difficulty in posting challenges. The attacker would not know whether there are silent watchers, or who they are if they exist, so there would not be a practical way to DoS attack them before they act.

Speed demon attack: the attacker generates on-chain assertions so rapidly that other parties don’t have time to check and challenge them all before their deadlines.

The method of Arbitrum to defend against the speed demon attack is to rate-limit the creation of assertions to ensure that at any time the total work required to check the pending assertions and challenge one if necessary will fit comfortably within the protocol’s deadline. Specifically, a speed limit will be imposed on the progress of the smart contracts in a Rollup chain, so that even if there is someone who can quickly crank out a large number of assertions, it will eventually have to slow down.

In summary, we don’t need to worry too much about forking attacks. In the event of malicious mining power monopoly, this blockchain is already rendered unattractive fundamentally. Arbitrum can defend against the other three censorship attacks by proper design or practices.

Advantages and risks of Sequencer Mode

Sequencer Mode is an optional feature of Arbitrum, where Offchain Labs operates the only Sequencer node on mainnet launch.

Sequencer is given limited power to control the ordering of each transaction in Inbox to guarantee the results of user transactions immediately, without needing to wait five minutes for block confirmations on Ethereum and even wait 15 seconds for Ethereum to make a block.

At the same time, a well-behaved sequencer can effectively defend against Front-Running Attacks.

Therefore, a centralized and well-behaved Sequencer node operated by Offchain Labs could be very beneficial to the early development of the project and reduce a lot of trouble, but the security risks are also obvious (although it is hard to imagine that Offchain Labs will be malicious). Offchain Labs promises to switch to a decentralized multi-Sequencer node solution as soon as the technology matures.

In addition, Inbox will be split into two, one accepts transactions submitted by Sequencer, and the other accepts transactions submitted by regular Aggregator or users, which also provides another choice for users who do not trust a centralized Sequencer.

Outlook for the future

As DeGate is a decentralized exchange that focuses on Ethereum Layer 2, the security of users' assets is our primary consideration. From a comprehensive study of Arbitrum Security Mechanism, it can be seen that the Arbitrum team has put a great deal of effort into security and that all aspects of security have been thoroughly considered with corresponding documents that explain the concepts underlying their security.

DeGate will actively study the construction and deployment of related products on Arbitrum. As a next step, we will soon launch the DeGate Bridge service to provide users with a convenient and fast cross-chain asset bridge between Arbitrum and Ethereum.