Building Magi: A new rollup client for Optimism
Decentralization is crypto’s defining promise: Networks that have no single point of failure are more secure and more resilient than their centralized counterparts. In practice, we often see emerging points of centralization as potentially vulnerable – their failures can compromise an entire network. Ethereum’s switch to Proof of Stake, for example, drew attention to the potential risk of relying on a single client at any layer. And fortunately, the openness of the ecosystem, along with a push for greater client diversity, has resulted in more clients and an increasingly more secure network.
This effort isn’t limited to Ethereum L1. Just as client diversity is important for Ethereum; it’s critically important for rollups. Multiple independent client implementations can help ensure the safety and liveliness of the network. They’re also a whole lot of fun to work on (thanks to some very detailed specifications).
That’s why we’re excited to take our very first step into the Optimism Collective by releasing Magi, a blazing fast OP Stack rollup client written in Rust. Magi acts as the consensus client (often called a rollup client in the context of the OP Stack) in the traditional execution/consensus split of Ethereum – it feeds new blocks to the execution client in order to advance the chain. Magi performs the same core functionality as the reference implementation (op-node) and works alongside an execution node (such as op-geth) to sync to any OP Stack chain, including Optimism and Base.
In this post, we share why we built Magi, and what’s in store for the future. Magi is still in its very early stages, so we welcome your ideas, feedback, and contributions, as we shape it into a production-ready client.
Bringing diversity to rollup clients
Client diversity is needed on both the execution and consensus sides, but most of the development has so far been focused on execution clients.
Any existing Ethereum execution client can be compatible with Optimism by implementing a modest set of changes, and several new projects are already adapting these clients to help achieve client diversity. OP Labs modified Geth to build op-geth; and other groups are currently building op-erigon and op-reth.
This is tougher on the rollup client side, since the rollup client is a brand new piece of software. So far, just one implementation exists: op-node, which is maintained by OP Labs and written in Go. Magi aims to be an independently developed, drop-in replacement for op-node, adding to the rollup’s client diversity. We hope that building out this new, Rust-based client will encourage greater safety and liveliness throughout the OP Stack, and bring more contributors into the ecosystem.
What’s next: Welcoming contributors for new features, fixes, and more
Magi is very new, and likely months of development away from being a feasible alternative to op-node. Some of the features and improvements we plan to add in the near future:
- Tracking the unsafe head (unconfirmed blocks) to lower latency.
- New sync mechanisms to improve initial sync speed.
- Alternative data availability layer support.
- Better frameworks for testing Magi, op-node, and any future clients.
There’s a long way to go, but we’re committed to getting there. We would greatly appreciate contributors, so check out the client or reach out with your ideas, feedback, and code – we’re excited to work together to keep moving Magi and the OP Stack ecosystem forward.
Acknowledgments
None of this would be possible without the hard work of the OP Labs team: I want to thank Refcell, who’s been contributing to Magi since nearly the beginning, as well as Protolambda, Joshua, and Vex who have provided valuable help in understanding some of the complexities of the Bedrock specification.