Analysis of the BOLD Verification Protocol How to Make Arbitrum More Decentralized?

BOLD Verification Protocol Analysis Enhancing Decentralization in Arbitrum

Author: @francescoweb3 / Source: https://twitter.com/francescoweb3/status/1687764742339981312

Translation: Huohuo / Blockchain in Plain Language

Arbitrum is becoming more decentralized: using BOLD for permissionless verification. Despite this not being a week suitable for naming something similar to “BALD”, this is a major update in Arbitrum’s design⬇️

• Assessing the Impact of EIP-4844 on Layer2 Protocol Costs and Profits
• Why is no one talking about ‘blockchain’ now?
• Decoding Intent Revolutionizing the Web3 User Experience and Blockchain Order Flow

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

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 dispute resolution process is initiated.

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

It is the verification process through fraud proofs that causes a delay of about 7 days in bridging between Arbitrum and Ethereum⏰.

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

What is the problem? Currently, verification through fraud proofs is permissioned in Arbitrum One and Nova.

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

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

In practice, transitioning to permissionless verification requires a protocol that can resist delay attacks, 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 states
• ✋ Prevent dishonest participants from increasing the cost for honest participants.

In fact, BOLD can provide “fixed, up to 7-day additional delay confirmation” and is not affected by delay attacks, which helps to achieve decentralization of the Arbitrum chain.

It achieves this goal by supporting efficient “full-to-full disputes”, 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 “fight as a team” together.

Therefore, any disputes in BOLD are related to the “deterministic” execution of the L2 state, rather than to specific stakers or entities.

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

Therefore, because disputes in BOLD are conducted as part of the whole team, any protocol action taken by 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 the malicious party cannot forge proofs of transaction execution.

This design is more efficient because each participant can “quietly rely on others to represent their position without worrying that the party will intentionally fail the challenge”.

Learn more about BOLD ⬇️

Instead of being seen as a challenge protocol between different participants, the BOLD protocol should be understood as competition between “edges”, where the goal for participants is to choose the correct edge as the winner.

How does this process work in the background?

1. “Edge” is the main data structure in the challenge protocol.

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

3. BOLD tracks the state of edges, but does not associate edges with any specific participants.

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

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

6. Edges have “start history commitments” and “end history commitments”.

7. If an edge has both correct start and end, it is provable; if only the start is correct, it is deviating; if both are incorrect, it 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 optimal latency boundary in confirming results and linearly restricts the work required by the honest party in countering the interest confiscated by the adversary.

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