Analysis of the BOLD verification protocol: how to make Arbitrum more decentralized?

Author: @francescoweb3 / Source:

Translation: Huohuo/Blockchain in Vernacular

**Arbitrum is becoming more decentralized: using BOLD for permissionless verification. **While this might not be a week with a name like BALD, this is a major update to Arbitrum’s design ⬇️

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 you need BOLD?

In simple terms, all optimistic Rollups settle their state on Ethereum. **How do they ensure the transaction is valid? Through the so-called fraud proof system. **

In practice, this happens through a set of entities called validators. These validators issue statements about the state of L2 and confirm through smart contracts that these statements are true.

Then, there is a 7-day challenge period (or cool-down period) during which other validators can actually challenge these claims, and if there is a discrepancy, the dispute resolution process is initiated.

If a claim is confirmed, the L2 state is considered correct and settlement is complete on Ethereum.

It is the verification process through the fraud proof that causes a ~7-day delay in natively bridging between Arbitrum and Ethereum ⏰.

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

**What is the problem? Currently, verification via fraud proofs is permission-required on both Arbitrum One and Nova. **

The reason for this is to protect the dispute protocol from denial of service attacks. If a malicious validator keeps spending funds to prevent claims from being confirmed, L2 withdrawals to Ethereum will be blocked, and while they have enough funds, this process can continue for almost a long time.

This is called a delay attack, and it attempts to stop the progress of the Rollup protocol by “attempting to prevent or delay confirmation of any results.” This attack is designed to prevent validators from submitting fraudulent proofs, so that the L2 state cannot be confirmed and settled to Ethereum.

Indeed, moving to permissionless verification requires a protocol that is resistant to delay attacks, like BOLD.

BOLD is a new permissionless L2 verification method.

It enables Arbitrum to:

• 💓 Guarantee the safety and liveness of the chain
• 🛰️ Minimize the delay of state settlement
• ✋ Prevent dishonest parties from increasing costs to honest parties.

In fact, BOLD can help decentralize the Arbitrum chain by providing a “fixed, 7-day additional delayed confirmation” that is immune to delay attacks.

It achieves this by enabling efficient “all-to-all disputes”, where even a single honest validator can win a dispute with 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 asks all parties supporting a particular statement to fight together “as a team”.

Therefore, any disputes in BOLD are related to the “deterministic” execution of the L2 state, not to a specific staker or entity.

This means that anyone who agrees with a state can justify it before finding a single point of inconsistency.

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

The deterministic nature of a correct L2 state means that honest parties will always win if they participate, since malicious parties cannot forge proofs of transaction execution

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

In-depth understanding of BOLD⬇️

Rather than being viewed as a challenge protocol between different parties, the BOLD protocol should be understood as a competition among “edges” where the goal of the participants is to select 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 corresponding to correct calculations and prevent any incorrect edges from being confirmed.
3. BOLD tracks the state of an edge, but does not tie an edge to any particular party.
4. Edges are classified according to their relationship to correct execution.
5. The protocol does not know which category the edge belongs to, but honest participants can tell.
6. An edge has a “Start History Commitment” and “End History Commitment”.
7. An edge is provable if both its start and end are true; it is deviant if only its start is true; and it is irrelevant if both are false.
8. To justify the protocol: 8.1 Security Theorem: No deviation from any margin can be confirmed. 8.2 Completion Time Theorem: Honest edges can be confirmed before some deadline.

BOLD Infrastructure

2. Conclusion

BOLD achieves an optimal latency bound on confirming results, and also linearly limits the work required by honest parties in terms of the benefits confiscated by the adversarial party.