Building a Fault Proof System worthy of the Superchain

Bedrock has shipped, the Superchain ecosystem is growing, and now developers at OP Labs, Base, and across the Optimism Collective broadly are laser-focused on decentralizing the OP Stack! I’m excited to share more about the design of the OP Stack’s first Fault Proof System, how it will allow the Collective to make significant progress towards technical decentralization, and the next-level customizability available for the Fault Proof System thanks to the OP Stack.

Progress on Technical Decentralization

In February, I outlined the OP Stack and Optimism’s path to technical decentralization. The plan includes baseline decentralization milestones like Permissionless Output Proposals and Bridge Decentralization. These milestones were included in the plan so we could make progress on decentralization even if iterating on Fault Proofs took some time.

Now that Bedrock has shipped, we are really stoked to report that significant progress has been made on the OP Stack’s Fault Proof System. This means shipping Fault Proofs is the next major milestone to look forward to in the Optimism ecosystem!

Here’s a rundown of the components of the Fault Proof System:

Fault Proof Program (FPP)

The FPP, or "op-program" acts as a deterministic program that's seeded from data on L1. It fetches required data checks for any faults. It can also define the host that pre-fetches information.

Fault Proof Virtual Machine (FPVM)

The FPVM, aka "Cannon," runs the op-program. Cannon is written in Go, and emulates a MIPS machine, which runs the L2 Ethereum Virtual Machine (EVM) as defined by the op-program, while itself being provable in the L1 EVM. This level of abstraction allows the system to maintain a precise control and tracking of each instruction step. It can fetch necessary data (pre-images) or run with pre-loaded data.

Dispute Game

A Dispute Game resolves disagreements over the output of the op-program. The aim is to narrow down the disagreement to the exact point in the instruction trace. The resolution of the dispute game relies on identifying the first uncontested claim, based on which the validity of the root claim can be determined.

The first Dispute Game that will be integrated to dispute traces generated by Cannon and the op-program is a Bisection game (but many other Dispute Game designs are possible!)

To OP Goerli and Beyond!

We’re eager to bring an alpha of the Fault Proof System to Testnet, so ecosystem developers can test and try to break the MVP, and start thinking about building alt-fault proofs or other modular components. 👀 👀 👀

That’s right! The Fault Proof System was designed to showcase the power of the OP Stack’s modularity. This way it’s easy for ecosystem builders to design custom OP Stack Fault Proof components, from proving schemes to virtual machines, and even unique dispute games. By modularizing the Fault Proof Program (FPP) and the Fault Proof Virtual Machine (FPVM) it becomes possible to improve each component in parallel, enhancing system performance and innovation. We expect this to help lay the foundation for a vibrant ecosystem of open source EVM proving systems.

Prioritizing decentralization and scalability

The Fault Proof System is key to enabling protocol decentralization. Technically, it will enable secure bridging without centralized fallback. Vitally, its open-source nature and standard, minimal implementation diff makes it easy for multiple implementations of the protocol. These multiple implementations enable security and are a requirement before reaching Stage 2 technical decentralization.

But beyond this, having multiple implementations maintained by distinct community members is critical for social decentralization. Social decentralization is an underrated, but vital strategy for any blockchain. The more clients, proving mechanisms, dispute games, and other infrastructure that are built and maintained by different contributors, the more decentralized the protocol. Making modularity a key part of the Fault Proof System design creates more opportunities for developers across the Collective to take part in creating and maintaining OP Mainnet and the Superchain.

Setting the stage for validity proofs

Another benefit of the modular proof design is that it creates a clear path to add zero-knowledge proofs (ZKPs) to the OP Stack. The separation of FPP and FPVM means that the same op-program can run in both an FPVM but also a ZKVM. This way as long as ZKP developers target a compatible VM specification, they don’t need to understand the inner workings of the FPP.

Similarly, developers optimizing the FPP don’t need to understand the inner workings of the ZKVM. This reduction in complexity and separation of concerns is key to the OP Stack’s rapid ZKP development. Follow this RFP for fun OP Stack ZKP developments! These OP Stack ZKPs will enable ZK-based validity proofs and power low latency bridges between chains. These bridges are critical to unlocking Superchain composability and therefore key to realizing the goal of enabling a unified and interconnected Superchain.

A fault proof system for our Superchain future

The OP Stack is the key to ensuring that Superchain infrastructure, including the Fault Proof System, is composable, versatile, and future-proof. The Fault Proof System represents a major step towards a more decentralized and efficient Superchain. This system will make it easier for developers to customize their work, and for users across the ecosystem to benefit from improved security and performance.

It’s never too early to start thinking about how you might contribute to the OP Stack and help secure the Superchain. The Optimism Ecosystem’s Contributions Dashboard is full of inspiration and guides for how to start contributing to the Collective.