Our Pragmatic Path to Decentralization
Uh Oh: Every L2 Has Upgrade Keys 😱
There’s a difficult truth which often doesn’t come up when discussing layer 2 (L2) protocols: Every major L2 project has a trusted party which can execute protocol upgrades. Currently, this is the primary point of centralization for just about everybody, including us. If upgrade keys were to be compromised, all deposited assets in the L2 protocol would be at risk.
Alternative L1s with bridged assets on Ethereum are vulnerable to similarly devastating attacks. Relying on the security guaranties of L1 in order to avoid this is a key part of the L2 vision. But we’re not quite there yet — in some sense, everyone is still selling a dream.
Let’s talk about the dangers which cause L2 projects to maintain upgrade keys, how Ethereum itself has avoided those pitfalls, and how we can follow suit.
State of Layer 2 Centralization
Your security is only as strong as your weakest link. The best encryption techniques cannot save you if your password is passwordpasswordpassword. So what’s the weakest link in the L2 space?
You guessed it: upgrade keys. Every major L2 has some form of instant upgradability on their L1 contracts. This is good because it allows the projects to ship improvements and bugfixes, but it also ultimately means that a trusted third party has unilateral say over what the L2 balances are.
This begs the question: what’s the point of having fault or validity proofs in place if at the end of the day that security can simply be overridden by upgrades?
We don’t mean to take away from the incredible work by layer 2 teams to push the state of the art in decentralized scalability technology. We’ve been making big strides — just take a look at our recently launched first ever bug bounty for next-gen fault proofs! Instead, this is a reminder that no major L2s have production ready fault/validity proofs today.
Having this intermediate phase is needed — productionizing these complex protocols is non-trivial — but we also need to talk about the realistic path to relinquishing keys and realizing the truly decentralized L2 vision.
Why L2 is not Decentralized
A Necessary Evil
Before jumping into the solution, let’s first establish the problem: The reason all L2s have upgrade keys is because writing complex, bug-free code is incredibly difficult. Every new line of code written is a new chance to introduce a bug.
In crypto, where a single critical vulnerability can cripple a project, we must be extremely careful. This means succinct, simple code. Code reduction sits at the core of Optimism’s philosophy, and was a primary motivator for our EVM equivalence upgrade. (Even then, bugs can still slip through the cracks.)
The truth is, any critical bug in a decentralized L2 would be catastrophic: by design, smart contracts would enforce it with the full “security” of L1. Without upgrade keys as a measure of last resort, there would simply be no recourse. This sets an incredibly high bar.
Look to Ethereum
Ethereum itself is a great case study in decentralized security, and we can use it to judge the difficulty of writing a bug free L2. Throughout its history, Ethereum has had lots of bugs which were introduced, caught, fixed, sometimes triggering unintentional hard forks (trust us, it’s not fun).
Despite multiple critical bugs, Ethereum has remained highly available throughout its lifespan. At just 2 years old, Ethereum came closest to having a true outage during the Shanghai DoS attacks. Given how commonplace blockchain outages still are today, this is an impressive feat.
At this point, we can be extremely confident that Ethereum L1 will not go down or be compromised. We need to reach the same level of confidence in L2 to be able to relinquish upgrade keys. So what’s Ethereum’s secret? Can we follow in its footsteps as we work to properly secure L2?
Find out next time on Dragonba… Jk jk we got you, just keep reading👇
Pragmatic Path to Decentralization
Ethereum’s success in minimizing security and maximizing uptime has not been dumb luck — it’s owing to the fact that Ethereum strategically created a multi-client ecosystem with multiple distinct implementations that interoperate.
This approach to security relies on the fact that bugs are uncorrelated between implementations. In other words: if one implementation has a specific bug, another implementation probably doesn’t suffer from the exact same one.
That way, even when there’s a failure, you can weed out the buggy client in favor of the properly functioning clients. This redundancy is key to Ethereum’s high availability guarantees.
We can follow in Ethereum’s footsteps and use this very same approach in layer 2. Instead of implementing one client, one fault proof, or one ZK Proof, we can create a multi-client ecosystem for L2 just like we have in L1. This ensures that critical vulnerabilities won’t take down the whole network, even if present in some optimistic clients.
Decentralizing Optimism with a Multi-Client Architecture
We design Optimism to hold true to Ethereum’s philosophy, not just from a social impact perspective, but also a technical one. Since day 1 writing our Optimism: Bedrock designs, we’ve architected it to use the ETH2 merge API, which enables easy integration with multiple clients.
In fact, we’re targeting a footprint of less than 1,000 lines of code required to turn a standard Ethereum client into an Optimism client. With EVM equivalence, we’ve also modularized the fault proof and rollup client implementations into separate pieces of software. Together, these approaches will allow us to mix and match both the proofs and the clients, maximizing redundancy!
ZK Rollups: An Extra Layer of Security
We often get asked “will you adopt zero knowledge proof technology”? The answer is that it is possible, but not in the way you might think. There’s a long road ahead, but if ZK technology becomes powerful enough to support EVM Equivalence, it is possible to add it as another client in this multi-client ecosystem. This doesn’t mean moving away from our current architecture or core functionality, but it does mean another layer of security.
So — while ZK tech is exciting, we don’t need to wait to get a low-cost, highly secure, EVM equivalent L2. That’s here in the form of Optimism right now, and once ZK matures, it can slot right into our architecture.
The Rollout
Currently, we’re deep in the developmental heart of Bedrock. This will result in a detailed specification for our EVM Equivalent rollup, along with the first rollup client and the MIPS fault proof, Cannon. At that point, the multi-client journey begins.
Our goal is to work with and incentivize external teams to create the other clients. It won’t be a fast process, but the Bedrock (😉) will have already been established, and code minimization is the name of the game. To integrate these together in a multi-client proof system requires following the Hydra framework. By this point, we will have gained the necessary confidence to remove upgrade keys.
In summary:
- Form a fellowship of Optimists.
- Release Bedrock, enabling a multi-client architecture.
- Incentivize/support the creation of alternative Optimism clients.
- Ship the multi-client proof contracts.
- Drop our upgrade keys into Mount Doom.
We’re Decentralized Now
Congrats! You made it to the end of this post which means L2 is fully decentralized and we have achieved the full L2 vision. You now live in crypto nirvana.
CAREFUL — hopefully we didn’t fool you! It takes time to write production software — so stay alert and stay suspicious. Balance your unbridled optimism with a healthy dose of skepticism. Though we aren’t in crypto nirvana yet, we’re all gonna make it there.
L2 will bring decentralized computing to a global scale. We’re not there yet, but be patient — the fact that we’re not at the end of the journey is an opportunity!
THAT MEANS YOU CAN GET INVOLVED AND REINVENT REALITY!
We’re hiring! Join our community! Have fun! Enjoy life! Don’t worry so much! Brush your teeth! Eat apples! Eat bacon! Research the origins of public relations! Give back to your community! Tweet things you don’t actually believe! Download free music using your library card! Don’t download a car! Don’t listen to anyone except for your parents, and even then, with a grain of salt!
Last — we’d like to give a very special thanks to Yoav Weiss for helping us come up with this pragmatic path to decentralizing fault proofs!
