Rust Pre-mortem Why? Base is running op-reth in production and will transition their sequencer to op-reth. If op-reth has a chain split with op-geth due to some unknown or introduced bug, the consequences are dire - the chain would need to be rolled back. This is a pre-mortem document to asses why this happened and how OP Labs can evolve as an organization to prevent this going forward. Background op-reth was initially built from Eth Denver 2023 (February) - Paradigm Frontiers 2023 (August) by @refcell and @clabby - two OP Labs engineers. Afterwards, support by OP Labs was not given so the burden fell on reth core contributors to maintain as well as Base engineers (Brian). As Base has scaled, they've adopted op-reth as a solution to op-geth's poor scaling. OP Labs never committed to running internally. We are just now beginning to run op-reth in our infrastructure as a reactionary measure to Base productionizing the client.

Kona ExEx Goals Fully sync Kona ExEx to tip and follow the safe head. Why What this gets us is a validation client running on top of a reth node. Effectively a single L1 reth node can have multiple Kona ExEx's installed, validating multiple L2 chains. On top of these light consensus clients following the safe head, you could then support zk proofs. Out of Scope

Quick Stage 1.4 Notes We want to build confidence in kona as a fault proof program. What does building confidence in kona mean? We need to build tests around kona. Concretely, this means building a high coverage test suite around the fault proof program. We keep the execution extension in scope because it's really valuable to throw real traffic at the software to tease out issues. It should also be a low lift. We will have the ExEx just follow the safe head.

The OP Stack is the standardized, shared, and open-source development stack that powers Optimism, maintained by the Optimism Collective. - stack.optimism.io When external builders come to the Optimism Collective, we greet them with the premise that there is an open-source, standardized, and shared development stack. The first is clear-cut; for as long as Optimism has been around, the collective has delivered on the promise of being open-source. That is the monorepo. A reference implementation for OP Stack components, the monorepo well serves the measure of being standardized. Especially as it is the core deliverable of OP Labs. This leaves the third attribute of being shared. Only recently has a great influx of external contributors including Test in Prod, Base, and other incredible individuals, surfaced the question of how shared is the OP Stack. Introspecting into the recent experiences with external developers building on the OP Stack, we can gauge how well we've delivered on this promise. This starts with a few key questions. How and what have folks been building on and contributing to the OP Stack? What are frequently recurring challenges faced by external developers?