Introduction

Layer 2 (L2) scaling solutions have become indispensable to Ethereum, addressing issues of transaction congestion and high fees while preserving decentralization and not compromising the network’s core principles.

As Ethereum continues to grow, L2s are critical in ensuring the scalability of applications and protocols. However, not all L2 solutions achieve scalability in the same manner. Each comes with its own trade-offs in terms of efficiency, security, and decentralization.

L2 solutions try to balance scalability gains with security and decentralization, which are vital to maintaining the system's integrity and trustworthiness.

Rollups are classified into three maturity stages: Stage 0, Stage 1, or Stage 2. This framework was initially proposed by Vitalik Buterin, Ethereum’s co-founder, and later refined by L2Beat, a public good platform tracking the development of L2s.

This framework provides a structured approach to understanding the evolution of rollups and sets expectations for their gradual transition toward greater decentralization and security.

Most L2s launch at Stage 0, relying on centralized mechanisms for dispute resolution and security, before progressing toward more decentralized models. A notable exception was Arbitrum, which launched with fraud proofs live since its inception. This was instrumental in positioning Arbitrum as a leading L2, setting itself apart from other rollups by prioritizing security and decentralization from the outset.

Recently, Arbitrum has taken a significant step forward by introducing the Bounded Liquidity Delay Protocol (BoLD). This new dispute resolution mechanism enhances security and improves validator participation, pushing Arbitrum closer than ever to becoming a fully permissionless Stage 2 rollup.

With BoLD, Arbitrum enhances its decentralization and minimizes validation and dispute resolution risks.

This report examines the innovations brought by BoLD, focusing on three key areas:

1. Dispute resolution improvements

2. Broader validator participation

3. Security enhancements

We begin by introducing L2Beat’s rollup categorization framework before diving into how BoLD resolves existing issues, positioning Arbitrum on the verge of complete decentralization and closer to the ambitious goal of becoming a Stage 2 rollup.

BoLD and its Role in Enhancing Security and Dispute Resolution

Bold is designed to replace the original Arbitrum dispute resolution protocol.

Bold aims to unlock permissionless validation by ensuring that disputes are executed within a fixed period. It wishes to accomplish this by allowing anyone to “validate, propose, and defend an Arbitrum chain’s state without requiring permission to do so.” 

The introduction of BoLD marks a pivotal change in Arbitrum's dispute resolution process, significantly enhancing security and decentralization.

To highlight the improvements introduced by Bold, it is essential first to explain how dispute resolution works in Arbitrum’s previous model:

1. Validators post claims about the correct outcome

2. These claims are backed by staked (bonds), posted by the ones claiming. 

3. In the case of multiple competing claims, the protocol must select the correct one.

4. When the smart contract declares a winner, the losing bond is confiscated, and the other is returned to the respective party.

This mechanism has, however, some limitations, particularly in terms of:

• Centralization: Due to the validator set being whitelisted, there is no possibility for broader participation from the community

• Costs: The necessary coordination among validators to defend in case of competing claims increases costs for dispute resolution.

• Security and Delays: The system was prone to delay attacks, in which malicious actors could slow down the network by targeting withdrawals and validation. 

In turn, Bold improves dispute resolution by tackling these issues:

• Centralization: BoLD opens up access to permissionless validation, removing the previous reliance on a centralized set of whitelisted validators. This significantly increases the participation pool, encouraging a more decentralized system.

• Costs: BoLD ensures trustless cooperation among validators, meaning they do not need to coordinate directly.

  

  Validators can pool resources to defend a correct assertion, sharing defense costs.  Bonds confiscated from attackers can be redistributed among defendants.

• Security: BoLD allows claims to be executed in parallel, reducing the computation costs. A single honest validator can now defend against any number of malicious actors. 

Furthermore, thanks to a "resource ratio," attackers must spend more resources than defendants through their bonds, which are confiscated even if only a single honest validator can successfully challenge their claim.

“Bonds put up by honest parties will always be refunded while malicious actors always stand to lose 100% of their bond”.

• Delays: BoLD introduces time-bound dispute resolution, setting a limit to the maximum withdrawal delay, which is capped at two challenge periods (roughly 12.8 days). This protection ensures that delay attacks, such as preventing withdrawals for malicious purposes, are significantly mitigated.

Combined, these features will considerably increase the cost of attacking Arbitrum.

The system is also designed to be deterministic (thanks to the deterministic nature of the L2 state), meaning that as long as an honest party participates, they will win. Anyone who agrees on a state can defend it until a “single point of disagreement is found”.

This is because malicious actors cannot fake the proofs of transaction execution, ensuring higher security and integrity. 

Increasing Validators: How BoLD supports broader validator participation.

Transitioning from one stage to another is clear proof of the maturity of rollups.

Arbitrum’s transition from Stage 1 to Stage 2 represents the evolution of a system moving from a relatively controlled, permissioned validator model to a more decentralized and open validator set.

In the current architecture, L2 withdrawals from Arbitrum to Ethereum are handled by a select group of validators. This design protects the dispute protocol from possible denial-of-service attacks, also known as “delay attacks”, where malicious validators could spend funds to prevent the confirmation of claims, stalling withdrawals from Arbitrum to Ethereum as long as they have money to stand. 

While this arrangement is secure to an extent, it limits the degree of decentralization, as only a tiny group of validators are responsible for validating transactions and handling withdrawals, exposing the system to centralization risks.

BoLD implements permissionless validation with a new dispute resolution protocol that is “maximally resistant against delay attacks”, increasing the number of validators significantly. This makes the system safer by establishing a maximum delay on withdrawals and ensuring malicious actors cannot manipulate the system as easily.

In turn, this makes withdrawals from Arbitrum to Ethereum safer by eliminating the surface for delay attacks, thanks to establishing a maximum withdrawal delay.

Bold is a new approach to L2 validation in a permissionless manner by allowing Arbitrum to:

• Guarantee the safety and liveliness of the chain

• Minimize latency to settle states

• Prevent dishonest parties from raising the cost for honest ones.

Bold will launch with a trustless bonding pool contract where anyone (provided they meet the requirements) can pool their funds to challenge dishonest proposers, making it easier to participate in securing the network and improving decentralization.

BoLD also facilitates a more inclusive and decentralized model by allowing anyone (provided they meet the bond requirements) to pool their funds into a trustless bonding pool contract to challenge dishonest proposers. This opens up participation for a broader range of individuals and helps secure the network. Arbitrum's resilience improves as more validators participate, and the network becomes better equipped to handle attacks and disruptions.

A focus on aligning incentives between honest validators is key to BoLD’s success. Failed attackers lose their bonds, which are then confiscated and distributed:

• 1% as a Defender bounty across the entities who have put the bonds to defend Arbitrum. 

• The rest is sent to the DAO treasury, which can decide whether to redistribute an additional % among defenders or use the funds to refund gas costs to the honest validators, burn them, or keep them in the treasury.

This ensures that validators are incentivized and rewarded to act honestly and protect the network.

To further reduce costs, Bold employs a multi-level refinement process that optimizes the computation required for dispute resolution. By refining the process in stages, Bold ensures that resources are utilized efficiently without compromising security.

Last but not least, Bold requires no additional hardware from validators. 

The Road to Stage 2 Rollup: BOLD’s importance in moving to permissionless, decentralized validation.

The emergence of many L2 networks has raised issues in terms of standardization, which allows for a comparison between them. 

Vitalik Buterin’s original proposal for the rollup stages provided a framework for the gradual decentralization of L2 networks:

1. Stage 0: Full training wheels. Open source software. Operators control the system with centralized dispute resolution.

2. Stage 1: There are limited training wheels. Smart contracts and decentralized proof systems are implemented. This includes implementing proof systems, decentralizing proof submission, and allowing for an exit window without coordination. There is still a Security Council that addresses bugs as a safety net.

3. Stage 2: No training wheels. Full permissionless fraud proofs, extended exit windows (30+ days) for users to exit in case of unwanted upgrades, and no room for governance attacks. The role of the security council is restricted to specific onchain errors. 

L2Beat refined and implemented this framework with clear and distinct progression criteria. Currently, the L2Beat framework serves as a roadmap for rollups, which aspire to evolve from a controlled Stage 1 to a fully decentralized Stage 2 rollup.

However, it is important to highlight that those metrics do not provide a proxy for rollup security but rather assess the “maturity” of rollups, with the ultimate goal of being entirely decentralized. 

Stage 0 requirements

Projects at this stage are in the nascent development phase. While functional, they rely on relatively centralized dispute resolution and validation mechanisms, reflecting their early experimental phase. Base, Scroll, and Blast are all examples of Stage 0 rollups.

1. Self-identify as a rollup.

2. Post state roots on a Layer 1 (L1) to allow withdrawals.

3. Provide Data Availability (DA) on L1, ensuring all data to reconstruct the L2 is available.

4. The software can reconstruct the rollup from L1 data, allowing anyone to review and audit the software.

Stage 1 requirements

Projects at this stage implement more sophisticated security measures. These systems incorporate a fraud-proof system to verify the correctness of state roots from a minimum number of whitelisted validators and enforce an exit window of at least seven days for users to withdraw in the event of unwanted upgrades. Additionally, a Security Council—a group of trusted participants, partially external to the rollup’s operational team—serves as a fallback for bugs. Arbitrum prior to Bold is an exemplar of a Stage 1 rollup, leveraging fraud proofs and a centralized safety net for dispute resolution.

1. Proper proof system to verify the correctness of state roots.

2. At least five minimum whitelisted participants can submit fraud proofs.

3. Exit window without coordination: The rollup operators cannot block withdrawals. 

4. Users should have at least 7 days for an exit window of unwanted upgrades.

5. The security council should be adequately set up: at least 8 participants in a multi-sig, with 50% consensus required. At least 50% should be external to the organization running the rollup, including 2 outsiders. Identities should be publicly disclosed.

Stage 2 requirements

These are intended as fully decentralized rollups. The transition to Stage 2 requires a robust framework that secures state transitions and incentivizes permissionless validator participation. In this phase, fraud proofs are permissionless—anyone can submit them—and the exit window is extended to 30 days. The Security Council’s role is dramatically reduced, and it is restricted to addressing soundness errors onchain. 

1. Permissionless fraud system: Anyone can submit fraud proofs.

2.  30 Days Exit Window.

3. Security council power is restricted to serious flaws identified onchain (soundness errors).

These requirements were eventually adapted once L2Beat updated their definitions.

In particular, changes have been introduced about the requirements of the Security Council and how it should be set up:

• 8 members.

• At least 75% threshold.

• Subjective evaluation of members.

• Publicly announced.

Since its launch, Arbitrum has been one of the first Stage 1 rollups with functioning fraud proofs. In comparison, most of the rollups in the L2Beat top 10 are all at stage 0, except for Optimism, which only recently introduced fraud proofs.

Arbitrum is currently the closest rollup to Stage 2. With the development of Bold, another slice of the pie is now green as state validation transitions from a permissioned to a permissionless system.

Nonetheless, even with the implementation of Bold, there are still two main issues to be fixed before Arbitrum can transition to a Stage 2 rollup:

• Restricting Security Council Powers: it is necessary to restrict their authority further to intervene only in case of soundness errors. 

• Increasing the Exit Window: to be considered a Stage 2, the exit window should be reaching at least 30 days to exit in case of unwanted upgrades. 

• Strengthen Community Engagement: educating stakeholders on governance processes and encouraging active participation will be critical to maintaining decentralization.

Conclusion & Food for Thought:
Why BoLD is vital for Arbitrum’s evolution

Arbitrum’s journey toward becoming a Stage 2 rollup highlights the importance of decentralization, security, and scalability for L2s. BoLD represents a crucial step in this evolution, enabling permissionless validation and enhancing Arbitrum’s security and resilience.

Arbitrum has always prided itself as one of the most credibly neutral blockchain networks.

Credible neutrality refers to the concept of a provably fair network that treats all actors equally and has mechanisms that anyone can read and verify. 

For a mechanism to actually be able to serve as this kind of common substrate, everyone participating must be able to see that the mechanism is fair, and everyone participating must be able to see that everyone else is able to see that the mechanism is fair, because everyone participating wants to be sure that everyone else will not abandon the mechanism the next day.

This has benefited the Arbitrum network incredibly:

• Chosen as a bridge for Hyperliquid: all USDC onboarding on Hyperliquid is deposited through Arbitrum, which led to over $2.5b in volume and $2.75b in TVL.

• Chosen to claim LayerZero airdrop and to implement Omnichain Functional Tokens (OFT)

• Chosen for USDT0 Layer Mesh: Arbitrum is one of the infrastructure providers selected for USDT0 (together with Ethereum, Tron and TON), the new interoperable version of USDT. 

Moving towards a Stage 2 rollup ensures Arbitrum removes any centralized safety net and transitions to a fully decentralized rollup, improving its neutral stance. Bold replaces the previous dispute resolution mechanisms and opens the network to permissionless validation.

With Bold, anyone can now help secure the Arbitrum network, removing the need for a permissionless set of validators as a centralized safety net and embracing decentralization. 

By strengthening the dispute resolution mechanisms, Bold makes Arbitrum more secure and resilient against possible attacks while decentralizing the validator set to protect the network.

Even a single honest party can now secure the network against malicious actors.

Participating in Bold is permissionless. We encourage developers and validators alike to do so and contribute to Arbitrum’s decentralized future. 

We expect that fixing the remaining issues to become a Stage 2 rollups will be the next main focus of the Arbitrum Foundation and Offchain Labs.

A big enough exit window and limited risks from the Security Council are pivotal measures to give anyone operating on Arbitrum peace of mind.

Compared to other rollups, Arbitrum is leading the way to becoming a Stage 2 rollup, a testament to its security-first approach to scaling Ethereum. 

Bold’s enhancements are not just technical upgrades but strategic developments that significantly lower the barriers to participating in decentralized ecosystem security.

These innovations will benefit Arbitrum and impact broader trends across Defi and rollups selecting their dispute resolution and validation mechanisms.  

• Enhancing credible neutrality of Arbitrum

• Enhancing network adoption

• Enhancing community participation 

• Enhancing security through permissionless validation.

Arbitrum’s pioneering work, particularly with the Bold protocol, demonstrates a clear commitment to decentralization and robust security principles. As the network matures, the anticipated transition to a Stage 2 rollup will likely position it as the gold standard for L2 solutions, fostering a more secure, efficient, and inclusive Ethereum ecosystem.

As Arbitrum matures, the successful transition to a Stage 2 rollup will set a benchmark for what constitutes a secure, efficient, and decentralized L2 system. This will likely have significant implications for the broader Ethereum ecosystem, influencing how other L2 solutions develop and interact with the Ethereum mainnet.

For this reason, we hope the following report will reflect this completed transition. 

Brace yourself, Stage 2 rollups are coming! 

Brought to you by Francesco.

Thanks for reading!

If you enjoyed it, please follow us on Twitter at @Castle_Labs and visit our website for more research and to learn more about our services and get in touch.

Virtually yours,

The Castle