The Layer 2 scaling solution is currently the hottest topic discussed on Ethereum, and it is also the hottest topic in the entire blockchain technology community. Arbitrum is a layer-2 scaling solution based on Optimistic Rollups. It took the lead in deploying the beta version of its mainnet and gained support from core DeFi projects such as Uniswap and Compound, becoming the most eye-catching layer-2 solution at present.

The security mechanism of migrating from the Ethereum mainnet to the second-layer solution is one of the most concerned issues for users. In this post, we'll take a deep dive into Arbitrum's security mechanisms, including how Arbitrum is rooted in Ethereum security, why the challenge period is 7 days, and how to defend against censorship attacks.

Rooted in Ethereum Security

Compared with other scaling solutions, the biggest advantage of Layer 2 is that it completely relies on the security of Ethereum. Most people probably know this, but they don't know why. How is Arbitrum rooted in Ethereum security?

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

1. In the Rollup solution, the transaction is written in L1 (as calldata), but the calculation and storage of the contract are completed on L2 to achieve expansion.

2. The verifier issues an assertion on L1, which can be understood as packaging all transactions into a Rollup block and sending it to the L1 transaction.

3. When an assertion is issued, the system assumes that the assertion is correct. But there will be a window of time during which anyone can challenge the assertion. If the challenge is successful, all transactions contained in that assertion will be reversed and the assertor will lose their bond. If no challenge succeeds after the challenge period, the assertion is accepted and becomes final.

data availability

data availability

All transactions executed on L2 will first be 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 restore L2 to its original state. The availability of this data is guaranteed through L1, and users do not have to worry about L2 failures causing losses to their assets on L2.

AnyTrust

AnyTrust is a key security feature of the Rollup protocol. This feature means that any honest validator can ensure the correct execution of transactions on L2. No matter how many malicious people try to block the transaction, you or someone you hire can ensure that the transaction is executed correctly without trusting any third party.

emergency exit mechanism

Arbitrum currently does not have a dedicated emergency exit mechanism, but there are a series of security mechanisms to ensure that users can exit in an emergency.

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

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

Finally, the AnyTrust mechanism ensures that users can force L2 to properly handle exit transactions.

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

Why the challenge period is 7 days

Arbitrum is a multi-round interactive Rollup solution. The solution starts by optimistically believing that the assertion made by a validator is correct until it is challenged or refuted by other validators during the challenge period. In most cases, there are no challenges and the overall system can progress faster and at lower cost.

Obviously, the longer the challenge period, the more secure the system as a whole, but at the same time the user experience will be worse (because the user needs to wait until the challenge period ends when logging out). 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, the maximum value that the attacker can obtain on L2 is V. Then the expected value obtained by the attacker is V exp(-AC).

Note: exp is an exponential function"e", A is a certain constant A, AC in front of"-"The sign means that C is inversely proportional to expected return.

2. The asserter needs to pledge assets far greater than the attack value to deal with the attack. Let's assume a factor of 10, and the cost of the assertor is 10V exp(-AC)I. I is the capital rate.

3. We assume that the withdrawal assets of the withdrawal users locked in the challenge period are CWV (where W is a decimal, WV is a part of the total assets on L2, and there will be C blocks of unfinished challenges at each time point), the user's asset cost for CWVI.

4. The length of the optimal challenge period is when the total asset cost of the asserter and the exiting user is the lowest. That is to say, when taking the value of C, 10V exp(-AC)I+CWVI is at the minimum. V and I occur in two terms, it does not affect the nadir and can be ignored. We just need to take the derivative of C and set the resulting derivative to 0 to get C=ln(10A/W)/A.

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

Assume that the success rate of continuous review of a block time is as high as 99.99%, which is equivalent to A=-ln(0.99)=0.01.

It is further assumed that 1% of the total value is withdrawn every day, calculated as a block of 15 seconds, and the withdrawal ratio of each block is about W=0.000002.

Plugging these into the formula, we get an optimal challenge delay of C = 62146 blocks, or 10.79 days, which is very close to the optimal challenge period of 7 days that the Arbitrrum team finally chose.

How to Defend Against Censorship Attacks

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

Fork attack: Miners conspire (or are bribed) to discard blocks containing a normal challenge in order to accept an alternate chain that does not contain a challenge.

First of all, due to the existence of challengers, once a fork attack occurs, it will inevitably be discovered by a challenger. And when everyone finds that the mining monopoly in the blockchain (which is a prerequisite for a fork attack) breaks the rules unfettered for profit, the blockchain itself has been broken. At this point, it doesn't matter at all whether Arbitrum adopts the challenge-period design pattern or not.

Evasion Attack: Miners conspire (or are bribed) to omit normal challenges from the blocks they produce.

We assume that the monopoly controls 90% of the mining power and the deadline is 50 blocks. The monopolist needs to pack 50 blocks in a row to complete the attack. The probability is 0.9 to the 50th power, which is only 0.5%. The actual challenge period is far more than 50 blocks, so the probability of a successful attack is very small. In Arbitrum's design, when the attack fails, the attacker will pay a huge fine, and it is quite uneconomical for a monopolist to launch an evasive attack.

Jamming attack: The attacker launches an 'old-fashioned denial of service attack' (DoS), preventing other parties from publishing any transactions (transactions containing challenges cannot be published).

Since the attack fails as long as there is a single honest challenger, the attacker must interfere with all possible challengers. If there are many such challengers, the attack is already difficult to complete. Worse, any interested party may have hired a silent observer as backup. They only step in when it's too late or difficult for major players to post challenges. The attacker won't know if there are silent observers, or if they exist, who they are, so there's no practical way to launch a DoS attack until they act.

Speed ​​demon attack: The attacker generates on-chain assertions so fast that other parties do not have time to check and challenge all assertions before the deadline.

Arbitrum's defense against speed demon attacks is to limit the speed at which assertions are created to ensure that at any point, the total work required to check pending assertions and challenge an assertion can be successfully completed within the deadline of the agreement. Specifically, a speed limit is imposed on the progress of smart contracts in the Rollup chain, so that even if someone is able to produce a large number of assertions quickly, it will eventually have to slow down.

To sum up, we don't need to worry too much about forking attacks. In the case of malicious mining monopolies, such blockchains have fundamentally lost their appeal. Arbitrum can defend against the other three censorship attacks through proper design or practice.

Advantages and risks of the Sequencer model

Sequencer mode is an optional feature of Arbitrum, and Offchain Labs operates the only Sequencer node at mainnet launch.

Sequencer is given limited power to control the ordering of each transaction in Inbox to ensure that the results of user transactions take effect immediately, without waiting for 5 minutes to confirm the block on Ethereum, or even 15 minutes like in Ethereum. second block time.

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

Therefore, a centralized, well-behaved Sequencer node operated by Offchain Labs is very beneficial to the early development of the project and can reduce a lot of trouble, but the security risk is also obvious (although it is difficult to imagine that Offchain Labs would have malicious intentions). Offchain Labs promises that once the technology matures, it will switch to a decentralized multi-Sequencer node solution.

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

Original: hackernoon

Compilation: Bibabu