Arbitrum is getting more Decentralized: Permissionless Validation with BOLD

Arbitrum just announced the release of BOLD.

While probably the wrong week to name anything similarly to BALD, this is a major update in their tech design.

BOLD stands for Bounded Liquidity Delay, and as the name itself goes, it is a “dispute protocol” that enables permissionless validation for Arbitrum.

Why is BOLD needed?

To sum it up, all Optimistic Rollups settle their state on Ethereum.

How do they make sure that transactions are valid?

Through a so-called system of fraud-proofs.

The way this works in practice is that a set of entities, called validators, are posting claims about the L2 state, that are confirmed to be true to a smart contract.

Then, there is a 7-day challenge (or cooldown period), where other validators can actually challenge these claims, and in case of discrepancies a process to resolve the dispute occurs.

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

The validation process through fraud proofs is exactly why bridging natively between Arbitrum and Ethereum takes about a 7-day delay.

A dispute protocol (like BOLD) involves each party submitting fraud proofs to Ethereum so as to determine the valid result of the L2 transactions.

What is the issue though?

Currently, validation via fraud proofs is permissioned both on Arbitrum One and Nova. The reason for this is to protect dispute protocols from denial-of-service attacks, where a malicious validator could repeatedly spend funds to prevent claims to be confirmed, thus stalling withdrawals from L2 to Ethereum — pretty much as long as they have money to spend.

This is referred to as a Delay Attack, which tries to prevent a rollup protocol from making progress by “trying to prevent or delay confirmation of any results at all”.

Moving to permissionless validation requires in fact, a protocol that is resistant to delay attacks, like BOLD.

BOLD

BOLD is a new approach to L2 validation in a permissionless manner.

It allows Arbitrum to:

1. Guarantee the safety and liveness of their chain
2. Minimize latency to settle states
3. Prevent dishonest parties from raising the cost for honest ones

In fact, BOLD is able to provide a “fixed, upper bound 7 days of additional delay on confirmations” and doesn’t suffer from Delay Attacks — contributing to decentralizing the Arbitrum chains.

It does so, by supporting efficient “all-versus-all-disputes”, where even a single honest validator can win disputes against any number of malicious claims.

As such, BOLD can resolve disputes among multiple parties efficiently in a single procedure rather than relying on the previous one-vs-one challenges.

BOLD requires all parties supporting a specific claim to “fight as a single team”.

Any dispute in BOLD is therefore tied to a “deterministic” execution of the L2 state and not to a particular staker or entity.

This means anyone who agrees with a state can defend it until a single point of disagreement is found.

As a consequence, any protocol action taken “on behalf of the team” is one that every honest team member would support.

The deterministic nature of the correct L2 state means that honest parties will always win if participating — as malicious ones can’t really fake the proofs of transaction execution.

This design is more efficient as every party can “silently rely on someone else representing its position, without being concerned that the party could intentionally lose the challenges”.

Rather than being a protocol for challenges among different parties, BOLD protocol has to be intended as a contest between “edges”, where participants aim to choose the right ones as winners.

How does the process work in the background?

1. Edges are the main data structures in the challenge protocol
2. The goal of BOLD is to confirm edges that correspond to correct computation and prevent the confirmation of any non-correct edge
3. BOLD tracks the edge status but doesn’t identify an edge with any particular party
4. Edges are classified according to their relationship to the correct execution
5. The protocol is not aware of which category an edge is, but honest participants can determine so
6. Edges have “start history commitments” and “end history commitments”
7. An edge is justifiable if both the start and end are correct, deviating if only the start is correct, and irrelevant if both are wrong.
8. To prove the protocol is correct:

8.1 Safety theorem: no deviating edge can be confirmed

8.2 Completion-time theorem: the honest hedge can be confirmed by some deadline

More details on the process:

When a level-zero edge is confirmed, the challenge ends.

BOLD achieves the best delay bound for confirming results and also limits the work required by honest parties linearly on the adversary stakes confiscated.

It represents a big improvement to allow permissionless validation in the Arbitrum ecosystem and make it more decentralized.

Furthermore, BOLD is implemented with a modular architecture, that can be adapted to Orbit chains, One or Nova.

I have purposely skipped the most technical aspects and focused on the key value proposition of BOLD in an understandable fashion.

If you are interested in a more technical read please refer to the BOLD docs:

https://github.com/OffchainLabs/bold/blob/main/docs/research-specs/BOLDChallengeProtocol.pdf

The Arbitrum team is already at work to make sure BOLD is ready for production. Some of these updates include:

1. Sharing instructions for running an Arbitrum Nitro devnet with BOLD challenges enabled in the coming weeks
2. Publishing our formal proofs code for BOLD, written in the Isabelle programming language along with our full, academic-style paper
3. A public testnet environment (a new one will be provisioned for BOLD) for the community to participate in challenge games
4. …and if there is positive community feedback, we plan to prepare an AIP so the DAO can decide whether to adopt this new challenge protocol in Arbitrum One and Nova