A critical discussion on the path to blockchain maturity is how to decentralize, how much, and when. This blog post shares a bit more about how we are thinking about this process at OP Labs as we support the ecosystem engineers building out a fault proof system for the OP Stack and the Optimism Collective as it establishes its first security council.

In an insightful article on the Ethereum Magicians forum, Vitalik Buterin lays out the roadmap for achieving Stage 2 Decentralization, a critical milestone for any layer 2 network looking to decentralize. This post has informed much of the conversation around technical decentralization in the Optimism Collective over the last two years. We firmly believe all Layer 2 blockchains should prioritize reaching this stage of decentralization as swiftly (and safely!) as possible, to ensure a more robust, secure, and truly decentralized ecosystem.

To remind everyone what is required for rollups to reach Stage 2, here are the criteria outlined in Vitalik Buterin’s original post:

Requirements:- In the event that code does not have bugs, there must not be any group of actors that can, even unanimously, post a state root other than the output of the code.This somewhat awkward phrasing (“IF the code does not have bugs, THEN no one can override it”) is meant to permit use of security councils in ways that are clearly limited to adjudicating undeniable bugs, such as the following:- The rollup uses two or more independent implementations of its state transition function (eg. two distinct fraud provers, two distinct validity provers, or one of each), and the security council can adjudicate only if they disagree - which would only happen if there is a bug.- If someone submits a transaction or series of transactions that contains two valid proofs for two distinct state roots after processing the same data (ie. “the prover disagrees with itself”), control temporarily turns over to the security council.- If no valid proof is submitted for >= 7 days (ie. “the prover is stuck”), control temporarily turns over to the security council.- Upgrades are allowed, but must have a delay of >= 30 days

In summary, to take off their “training wheels” and achieve Stage 2 decentralization, rollups must have a trustless fault proof system, multiple functioning proving mechanisms, and rollups that have a security council or a similar entity must meet specific criteria.

Why is it so important to reach Stage 2?

What Stage 2 does that Stage 1 does not is ensure there’s no one group of actors that can “even unanimously, post a state root other than the output of the code.” Stage 1 L2s still have some version of a multisig or security council that could hypothetically (although not without costs) alter a chain’s state root to censor or initiate invalid withdrawals. It’s not entirely trustless. Removing this ability further decentralizes networks and ensures users possess an unalienable ability to exit the system.

This type of flexibility is critical to the Superchain because it balances interoperability—everyone using the same fault proof will be on the same protocol version—without sacrificing user freedom and protections. The right to exit should always be preserved, and not impact the way a Chain or an app functions.

Why is it taking so long for Optimism to reach Stage 1 decentralization?

Projects might take a “depth first” approach while moving towards Stage 2: get to Stage 1 with a single fault proof as fast as possible, and then work out how to make a multiproof fault proof system to reach Stage 2 status. Optimism, by contrast, took a “breadth first” approach that aims to make a functional, fast-growing multiproof network. Ecosystem engineers are building the first implementation of the fault proof system in a way that enables that approach. Meanwhile, because this is all being built in the open, with an open source stack, other developers in the ecosystem were able to start building many other implementations in parallel with the work on the first fault proof implementation.

We know how important it is to get this right on the first try. Today, OP Stack engineers have laid the groundwork for rapid multiproof expansion, and they are working towards achieving Stage 1 status according to L2Beat’s risk analysis metrics, a respected standard in the industry. But Bedrock was built from the ground up with Stage 2 decentralization in mind. We are uninterested in reaching Stage 1 simply for the sake of saying we did so. From day one, it has been just one part of our pragmatic plan to reach Stage 2 as quickly and safely as possible.

Stage 2 is endgame. Here’s what that looks like in practice:

First came Bedrock and the OP Stack

In order to prioritize achieving Stage 2, we knew we needed to design a codebase that would make it easier to get there. We needed the modularity introduced by the Bedrock upgrade to make sure that once a functioning, trustless fault proof system was designed for the OP Stack, ecosystem developers could leverage its modular superpowers to help us design not just one or two, but many, alternate proving mechanisms.

At the same time we needed to make sure that even unforeseeable technological developments would not make the OP Stack obsolete. The current design of the OP Stack ensures that developers can swap proving components to include ZK technology, something that once threatened the growth of Optimistic rollups. Chains in the Optimism ecosystem are not forever bound to using optimistic proving mechanisms. We expect they will be able to leverage advancements in ZK technology and the resurgence of plasma, or a combination of all three mechanisms, in their Chain’s fault proof system.

It took time to design the OP Stack and execute the Bedrock upgrade, but the result of this investment has put the entire ecosystem in a position to rapidly accelerate our development progress in the coming months and beyond. This means it was time well and strategically spent.

Next comes a multiproof ecosystem

So far this approach has paid off tremendously. The evidence is in how quickly alternative clients have taken off since the Bedrock launch, and how many teams in the ecosystem are currently working on alternative fault proof implementations as well. In addition to OP Labs and all of the alternative client maintainers (Test in Prod, the reth team and Base, Nethermind, a16z crypto, and Kai Chen and the Hildr team), which are used as critical dependencies in the OP Stack, teams currently working on alternative fault proofs include the State Channels team, RISCZero, O(1) Labs, AltLayer, Protolambda (at OP Labs), and engineers Willem Olding and Eric Tu, along with geohotz and his initial work on Cannon.

Here’s what this is shaping up to look like:

The OP Stack is a triple threat. It is modular and open source, which means that the full power of the Stack can find its way into the hands of the third “threat,” its tremendously creative and brilliant developer community. It would take years for OP Labs engineers to develop, test, and implement the multiple proof schemes required for Stage 2 decentralization. By putting the best tools in the hands of the superstar core developers and engineers in our ecosystem, anyone with an interest in Optimism’s success can design the components that will help reach our goal.

Security council

To reach Stage 1 decentralization and progress to Stage 2, networks need something akin to a security council—a multisig with which to manage protocol upgrades that is maintained by a minimum of 8 independent individuals with a signing threshold of 75% or greater.

In the fall of 2023, rollout began in earnest to establish the Optimism ecosystem’s first security council, comprised of individuals outside of the Foundation. The first 14 members of the Optimism ecosystem’s security council were ratified by a governance vote in December 2023, and another governance vote on whether or not to share upgrade keys with the security council in an interim ‘Phase 0’ was also successful.

One of Optimism’s prized values is open source technology. Just as ecosystem engineers are building the MIT licensed open source OP Stack in the open, the security council will be built in the open, such as the public charter, an open source implementation, and transparent operations. This is in keeping with the two of the three guiding principles that have inspired the structure of the security council: transparency, and community.

The third principle, safety over liveness, informs the design the security council, and of security in the Optimism ecosystem overall. Prioritizing safety over liveness means it’s more important for the system to avoid errors and invalid states, especially ones that would result in a loss of funds, even if it results in temporarily halting operations.

All L2s should aim for Stage 2.

That’s it. That’s the meme.

It’s not enough for L2s to reach Stage 1 and limit the use of training wheels, while still relying on a single proving mechanism to secure a nascent fault proof system. Further, a single fault proof system is only as good as the strength of the security council that can steward it. For the first phase, a 14-person security council has been ratified by Optimism Governance to govern the security of the Superchain, and a key goal in 2024 is to have this security council managing the upgrade keys of the ecosystem at the direction of Optimism Governance, and independently from the Optimism Foundation.