Original title: "In-depth analysis of Arbitrum's security mechanism"
Source | Hackernoon
Author | DeGate
The Layer 2 expansion solution is a hot topic in the current Ethereum community, and it is also a hot topic being discussed in the entire blockchain technology community. Arbitrum based on Optimistic Rollups is currently one of the most attractive Layer 2 expansion solutions. It was the first to deploy a beta version of the mainnet and has gained support from core DeFi projects such as Uniswap and Compound.
secondary title
Rooted in the security of Ethereum
As we all know, the biggest advantage of Layer 2 solutions compared with other expansion solutions is that its security depends on the security of the Ethereum mainnet. However, most people probably know this truth, but they don't know why. So how is Arbitrum rooted in Ethereum's security?
Let's first review the main features of the Optimistic Rollup solution:
In a Rollup solution, transactions (as calldata) are written on L1, but the actual computation and contract storage is done on L2 for scaling.
The verifier publishes an assertion on L1, which can be understood as packaging all transactions and results into a Rollup block, and then sending it to the L1 transaction.
Optimistic Rollup is called an "optimistic" rollup solution because when an assertion is issued, it does not contain an accompanying proof that guarantees its validity, that is, the assertion is valid by default. Instead, there will be a window of time within which anyone can challenge the assertion. If the challenge is successful, all transactions within this assertion will be reversed, and the person making the assertion loses their deposit. If the challenge period expires and no one succeeds, the assertion is finalized.
data availability
data availability
All transactions executed on L2 are first submitted to the Inbox smart contract running on L1, and then written into L1 as calldata. Anyone can use this data to retrieve all transactions on L2 and restore L2 to its original state. The availability of these data is guaranteed through L1, and users don't have to worry about losing assets on L2 due to failure of L2.
AnyTrust
emergency exit mechanism
emergency exit mechanism
Arbitrum currently does not have a specific emergency exit mechanism, but has a series of safety mechanisms to ensure that users can exit safely.
First, data availability ensures that users' assets and data stored 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 an exit.
Finally, the AnyTrust mechanism ensures that users can force L2 to properly handle exit transactions.
secondary title
Why the challenge period is seven days
Arbitrum is a multi-round interactive Rollup solution. This solution first optimistically believes that the assertion made by the verifier is valid, and other verifiers may question and challenge it during the challenge period. In most cases, there are no challenges and the overall system can be more efficient and less expensive.
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 users need to wait until the challenge period is over before they can log out). So how do we determine the best challenge period?
The Arbitrum team proposes this model to calculate the optimal challenge period:
Assume that a challenge period is equal to the length of C blocks, and the maximum value that an attacker can obtain on L2 is V.
Then the expected value obtained by the attacker is V exp(-AC).
Note: exp is the exponential function "e", A is a certain constant A, and the "-" symbol before AC indicates that C is inversely proportional to the expected return.
Assertors need to guarantee that their assets far exceed the asset value of the attack to deal with the attack. Let's assume that over 10 times, the cost of the assertor is 10V exp(-AC)I. I refers to the capital rate.
We assume that the withdrawal asset locked by an exiting user during the challenge period is CWV (W is a decimal, WV is a part of the total assets on L2, and there will be C unfinished challenge blocks at each time point) and the user's asset cost for CWVI.
The optimal challenge period should be set when the total asset cost of the asserter and the withdrawing user is the lowest. That is, when the value of C is taken, 10V exp(-AC)I+CWVI is the smallest. Both V and I appear in both terms, it does not affect the minimum point and can be ignored. We simply differentiate with respect to C, set the resulting derivative to 0, and get C = ln(10A / W) / A.
Now we plug some reasonable numbers into the above equation to get an approximate optimal challenge period.
Assume that the success rate of continuous review within one block time is as high as 99.99%, that is, A = -ln(0.99) = 0.01.
Further assume that the daily withdrawal is 1% of the total value, and the withdrawal percentage of each block is about W=0.000002, based on the premise that the block generation time is 15 seconds.
secondary title
How to defend against censorship attacks
In this part, we discuss how Arbitrum defends against 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 containing normal challenges in order to accept alternative chains that do not contain challenges.
First of all, due to the existence of challengers, once a fork attack occurs, it will inevitably be discovered by a challenger. And when it is discovered that the monopoly of mining power in the blockchain (which is a prerequisite for a fork attack) is brazenly violating the rules for profit, the blockchain itself is destroyed. At this time, it is debatable whether Arbitrum adopted the challenge period design model.
Shunning attacks: Miners conspire (or are bribed) to ignore common challenges in the blocks they produce.
We assume that the monopoly controls 90% of the mining power and has a deadline of 50 blocks. Then the monopolist needs to pack 50 consecutive blocks to complete the attack. This probability is 0.9 to the 50th power, or 0.5%. The actual challenge period is far more than 50 blocks, so the probability of a successful attack is extremely small. In Arbitrum's design, the attacker pays a large fine if the attack fails, so it is very uneconomical for a monopolist to launch an evasive attack.
Jamming attacks: The attacker launches an "old-fashioned denial of service attack (DoS)" to prevent any party from issuing any transactions (transactions containing challenges cannot be issued).
Since the attack fails as long as there is a single honest challenger, the attacker must block all possible challengers. If there are many such challengers, the attack will be difficult to complete. Worse, any interested party may hire a silent watchdog as a backup plan. They only step in if the main players post the challenge too late or have trouble posting the challenge. The attacker does not know whether there are silent supervisors in the network, or even though they know they exist, they do not know who they are, so the attacker cannot launch a DoS attack against these supervisors before they take actual actions.
Speed demon attacks: The attacker generates on-chain assertions so fast that other parties cannot check and challenge all assertions before the time expires.
Arbtirum responds by limiting the rate at which assertions are created to ensure that the total amount of work required to check pending assertions and challenge one at any time can be done within the deadline of the agreement. Specifically, a speed limit is imposed on the progress of smart contract operations in the Rollup chain, so even if someone is able to generate a large number of assertions quickly, it must eventually slow down.
In conclusion, we don't need to worry too much about forking attacks. If there is a monopoly of malicious mining computing power, then it can be said that this blockchain has basically become unattractive. Arbitrum can defend against the other three censorship attacks through proper design or practice.
Advantages and Risks of Sequencer Mode
Sequencer mode is an optional feature of Arbitrum, and Offchain Labs runs the only Sequencer node on the release version of the mainnet.
Sequencer is given limited power to control the ordering of each transaction in the inbox to ensure that the user's transaction result can be determined immediately, without waiting five minutes for the block to be confirmed on Ethereum, or even requiring Also wait for 15 seconds for the block time.
Meanwhile, a well-behaved sequencer can effectively defend against front-running attacks.
Therefore, a centralized and well-behaved Sequencer node operated by Offchain Labs is very beneficial to the early development of the project and saves it a lot of trouble. But the security risks are also obvious (although it is hard to imagine that Offchain Labs will do evil, it does not rule out such a possibility). Offchain Labs promises to switch to a decentralized, multi-Sequencer node solution as soon as the technology matures.
In addition, the inbox will also be split into two, one accepting transactions submitted by Sequencer, and the other accepting transactions submitted by regular aggregators or users, which also provides another way for users who do not trust the centralized Sequencer choose.
Links to this article:https://www.8btc.com/article/6655971
Reprint please indicate the source of the article
