Progressing towards decentralization: highlights from the Keys in Mordor summit
In February, OP Labs engineers and core developers from the Optimism Collective gathered in person for the Keys in Mordor summit. The goal for this summit? Figure out how to take Optimism’s upgrade keys to Mordor and safely throw them into Mount Doom, rendering the protocol technically decentralized.
Attendees spent several days examining OP Mainnet and mapping out a secure and pragmatic path to decentralizing key components the network’s architecture. This path was outlined in an earlier blog post that describes OP Labs’ strategic approach to technical decentralization, and defines five key milestones along this path. These milestones are Permissionless Output Proposals, Bridge Decentralization, Cannon Fault Proof Program, Cannon Fault Proof VM, and Dispute Game Integration.
The summit also included several research-intensive presentations that dug into more granular details of our technical decentralization milestones, including Withdrawal Claims, Cannon, and Dispute Games.
Focus of the Summit
Prepping the OP Stack for Bridge Decentralization
Mark Tyneway delivered a presentation on Withdrawal Claims. In the presentation, he outlined the plans for Withdrawal Claims architecture that will enable the decentralization of OP Mainnet’s bridge.
What is a Withdrawal Claim? Essentially, a user will submit a claim to L1 that they can withdraw, and an arbitrary proving system can dispute or validate that claim. A claim is valid if there is no dispute through the fault proof window, or, in the future, instant validation when the OP Stack has validity proofs. The process requires a bond. Instead of using gas on a lot of compute and storage, users place a bond along with their claim, which they get back after the finalization period.
The existing architecture of the bridge includes the following properties: two-step withdrawals, message replayability, 1:1 mapping between domains, single storage proof, similar code paths on L1 and L2, and compatibility with Ether, ERC20, and ERC721 tokens. Withdrawal Claims aim to improve the existing architecture of the bridge by removing the proof validation code path, making withdrawals cheaper, and eliminating the need for output submission (this is crucial for the first Technical Decentralization milestone, Permissionless Output Proposals 👀).
Mark noted this new architecture requires minimal changes: one new contract, one removed contract, and one modified contract. The design also adheres to the all-important principle of minimal diff from the L1.
Importantly, the architecture does not rely on Cannon being ready, as a multisig-based `ThresholdAttestationDispute.sol` can be used for short-term implementation, while also allowing for Dispute Games when that component of Cannon is ready to be implemented.
As a result of discussion at the Summit, Withdrawal Claims was split into a two-part project: the implementation of Permissionless Output Proposals, which allow users to withdraw without relying on the sequencer or any other centralized infrastructure. Part two will be the full implementation of Withdrawal Claims and bridge decentralization.
Cannon
Now it’s time for the big one, the one we’ve all been waiting for. At the summit, Protolambda shared how the Cannon VM internals are put together and how programs can be fault-proven. The program will permissionlessly verify blocks and run OP Mainnet’s rollup state transition function to produce L2 outputs from L1 inputs.
Cannon consists of three main components: the fault-proof program, the fault-proof VM, and the Dispute Game. The program is designed to ensure the correctness of offchain computations, whereas the virtual machine (VM) is responsible for executing the fault-proof programs in Cannon's system. It supports the instruction set MIPS and ensures the correctness of the L2 outputs by resolving the execution of individual fault-proof program steps during the dispute game. Finally, the Dispute Game is the mechanism employed by Cannon to narrow down disagreements between parties regarding the correctness of off-chain computations.
In his presentation, Proto outlined some implementation risks, such as differences between the onchain MIPs implementation and the offchain Unicorn MIPS emulator, memory and register overlaps, limited memory space, instruction implementation bugs, unexpected Go runtime behavior, and the usage of MPT proofs for VM memory.
Finally, Proto discussed what it would take to update Cannon for production usage, including getting the fault-proof program to successfully verify blocks, improving onchain MIPS execution, and integrating Cannon with an onchain dispute game. He also outlined his progress on developing an additional fault-proof VM, Asterisc, which supports RISC-V 👀
Dispute Games
In the last presentation of the summit, Clabby educated attendees on Dispute Games, and how he envisions them enabling Cannon implementation.
Dispute games are mechanisms for finding the correct truth among many conflicting claims. Players make claims about their views of the truth, and the game's goal is to identify the single, correct truth among this set of claims.
Implementing Cannon on OP Mainnet will involve two nested dispute games: the block hash bisection game and the execution trace bisection game. The block hash bisection game aims to find the exact block hash at which multiple L2 chain histories diverge, while the execution trace bisection game aims to find the exact instruction within the state transition where multiple VM states diverge. These games work together to find and resolve disagreements within the system, ensuring the integrity and correctness of the layer 2 chain history.
In this system, the Dispute Game is being designed to be generic, meaning we can re-use all of the same generic dispute game infrastructure to create the block hash bisection game and the execution trace bisection game. There is also potential for future dispute game types to be developed, such as one backed by validity proofs, or an attestation proof game.
Dispute Games allow Cannon to take a set of conflicting claims, narrow in to the most granular point of fault that the parties disagree on, and secure a resolution to maintain the security and reliability of the network.
Summit Outcomes, and What’s Next
A very important result of the Keys in Mordor summit was devising a strategy for progressing towards the technical decentralization of the OP Stack. The milestones that were set can be completed in tandem, so progress is made towards baseline decentralization milestones like permissionless output proposals and bridge decentralization while we iterate on fault proofs.
The summit was also an opportunity to get some of the leading engineers in the Optimism ecosystem on the same page about all the architecture that needs to come together so that we feel confident tossing those upgrade keys in Mordor.
In the coming weeks you can look forward to more detailed technical explainers on how OP Labs developers are thinking through each milestone in our decentralization strategy. Until then, you can check out our docs if you feel inspired to contribute to the OP Stack.