Analyzing the major update designed by Arbitrum Unpermissioned verification using BOLD

Analyzing Arbitrum's major update using BOLD for unpermissioned verification.

Author: @francescoweb3; Translator: Huohuo/Baihua Blockchain

Arbitrum is becoming more decentralized: using BOLD for permissionless verification. Despite not being a week suitable for names like BALD, this is a major update in the design of Arbitrum.

BOLD stands for Bounded Liquidity Delay, as the name suggests, it is a “dispute protocol” that provides Arbitrum with permissionless verification capabilities.

• Exciting Changes in the Inventory of DeFi Stablecoins
• Opinion From the perspective of musicians, NFT is the best medium for creators in the new era to practice the 1000 true fans theory.
• Interpreting Polkadot 2.0 What are the impacts of the new parachain leasing mechanism on the demand and value of DOT?

1. Why do we need BOLD?

In simple terms, all optimistic rollups settle their states on Ethereum. How do they ensure that transactions are valid? Through a system called fraud proofs.

In practice, this is done by a group of entities called validators. These validators make statements about the L2 state and confirm these statements through smart contracts.

Then, there is a 7-day challenge period (or cooling-off period) during which other validators can actually question these statements, and if there are discrepancies, the process of resolving disputes is initiated.

If a statement is confirmed, the L2 state is considered correct and settlement on Ethereum is completed.

It is through the process of fraud proof verification that a delay of approximately 7 days is required for local bridging between Arbitrum and Ethereum.

The dispute protocol involves various parties submitting fraud proofs to Ethereum to determine the validity of L2 transactions.

What is the problem? Currently, permission is required for fraud proof verification on Arbitrum One and Nova.

This is done to protect the dispute protocol from denial-of-service attacks. If a malicious validator continuously spends funds to prevent statements from being confirmed, the withdrawal from L2 to Ethereum will be blocked, and they have enough funds to sustain this process for a long time.

This is called a delay attack, which attempts to hinder the progress of the Rollup protocol by “attempting to prevent or delay the confirmation of any result”. This attack aims to prevent validators from submitting fraud proofs, thereby preventing the confirmation and settlement of the L2 state on Ethereum.

In practice, transitioning to permissionless verification requires a protocol that can withstand delay attacks, just like BOLD.

BOLD is a new permissionless L2 verification method.

It enables Arbitrum to:

Ensure the security and liveliness of the chain

Minimize the delay in settling the state

Prevent dishonest participants from increasing the costs of honest participants.

In fact, BOLD can provide “fixed, up to 7 days of additional delay confirmation” without being affected by delay attacks, which helps to achieve decentralization of the Arbitrum chain.

It achieves this goal by supporting efficient “all-to-all dispute resolution”, which means that even with only one honest validator, it can win disputes against any number of malicious claims.

Therefore, BOLD can efficiently resolve disputes between multiple parties in one process without relying on previous one-on-one challenges.

BOLD requires all parties supporting a specific claim to “act as a team” together to fight against it.

Therefore, any dispute in BOLD is related to the “deterministic” execution of the L2 state, not to specific validators or entities.

This means that anyone who agrees on a state can defend it before finding a single point of disagreement.

Therefore, since disputes in BOLD are conducted as part of the entire team, any protocol action taken on behalf of the team is supported by every honest team member.

The deterministic nature of the correct L2 state means that if honest participants are involved, they will always win because malicious actors cannot forge proof of transaction execution. This design is more efficient because each participant can “implicitly rely on others to represent their position without worrying that the party will intentionally fail the challenge”.

In-depth understanding of BOLD

Rather than being seen as a challenge protocol between different participants, the BOLD protocol should be understood as competition between “edges”, with the goal of selecting the correct edge as the winner.

How does this process work in the background?

1. “Edges” are the main data structure in the challenge protocol.

2. The goal of BOLD is to confirm the edges that correspond to the correct computation and prevent confirmation of any incorrect edges.

3. BOLD tracks the state of edges but does not associate them with any specific participant.

4. Edges are classified based on their relationship with correct execution.

5. The protocol does not know which category an edge belongs to, but honest participants can determine it.

6. Edges have “initial history commitment” and “final history commitment”.

7. If an edge has both correct start and end, it is provable; if only the start is correct, the edge is deviating; if both are incorrect, the edge is irrelevant.

8. To prove that the protocol is correct: 8.1 Security theorem: No deviating edges can be confirmed. 8.2 Completion time theorem: Honest edges can be confirmed before a certain deadline.

BOLD Infrastructure

2. Conclusion

BOLD achieves the best latency boundary in confirming results and linearly limits the work required by honest parties to counteract the interests confiscated by adversaries.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!