When discussing Layer2 protocols, there is a hard truth that is often not realized: every major Layer2 project needs a trusted party responsible for performing protocol upgrades.
Right now, this is a major centralization issue for pretty much all of Layer2, including us.
If there is a problem with the Upgrade Keys, all deposited assets in the Layer2 protocol will be at risk.
An alternative underlying public chain (Layer1) with Ethereum cross-chain assets is vulnerable to similarly damaging attacks, and relying on Layer1’s security to avoid this is a key point of Layer2’s vision.
But we’re not quite there yet, and in a sense, everyone is still selling dreams.
Let’s talk about the risks that led to the Layer2 project in terms of “upgrade keys,” how Ethereum itself avoided these pitfalls, and how we can follow suit.
Centralization of Layer 2
Your security is only as strong as the weakest link.
If your password is “pass word pass word pass word”, no amount of encryption can save you.
So, what is the weakest link in the Layer 2 field?
You guessed it, the “upgrade key”.
Every major Layer 2 has some form of instant upgrade capability on their Layer 1 contract, which is good because it allows for improvements and bug fixes to the project, but it also ultimately means a trusted third party for Layer 2 The balance has a unilateral say.
But this begs the question: what’s the point of having a fault proof or a validity proof if in the end the importance of upgrades can simply trump security?
Discuss the multi-client architecture of Ethereum Layer2 Optimism, and solve the Layer2 centralization problem through a pragmatic decentralization path. No matter how strong it is built, the weak foundation of the castle may still collapse.
We’re not saying to ignore the efforts of the Layer2 team to push the boundaries of decentralized scalability technology, we’ve made huge strides, just look at our recent launch of the first-ever proof of fault tolerance for the next generation The bug bounty will be known.
Rather, it’s a reminder that none of the major Layer 2 products today have complete fault tolerance/validity proofs.
This transition phase is needed, and producing these complex protocols is not easy, but we also need to discuss a pragmatic path to abandoning keys and realizing the vision of a truly decentralized Layer2.
Why is Layer2 not decentralized?
- a necessary evil
Before we start exploring the solution, let’s identify the problem: the reason all Layer2s have upgrade keys is that writing complex, bug-free code is very difficult, and every new line of code written increases the chance of a bug.
In the field of cryptography, a critical vulnerability can cripple a project, and we have to be very careful.
This means clean and simple code requirements, and reducing code is the core of Optimism’s philosophy and the main driving force behind our upgrade of EVM (Ethereum Virtual Machine). (Even so, vulnerabilities are missed).
The truth is that any critical vulnerability in decentralized Layer 2 is catastrophic: by design, smart contracts will be executed based on all the “security” of Layer 1, and without key upgrades as a last resort, there will generally be no follow-up Claim, which is designed to an incredibly high standard.
- Research Ethereum
Ethereum itself is a good case study of decentralized security, and we can use it to judge the difficulty of writing a layer2 without vulnerabilities.
Throughout history, Ethereum has had many bugs that have been written, found, fixed, and sometimes inadvertently caused hard forks.
Despite multiple critical vulnerabilities, Ethereum has remained highly available throughout its lifetime.
During the Shanghai DoS attack, Ethereum, which was only running for two years at the time, was the closest it came to truly shutting down.
Given that blockchain disruptions are still common today, this is an impressive feat.
At this point, we can be very confident that Ethereum Layer 1 will not be paralyzed or destroyed.
We need to achieve the same level of confidence in Layer 2 to be able to drop the upgrade key.
So what is the secret of Ethereum? As we work to secure Layer2, can we follow in its footsteps?
A pragmatic path to decentralization
Ethereum’s success in minimizing security and maximizing uptime is not just luck, it’s due to Ethereum’s strategic creation of a multi-client ecosystem with multiple different implementations of interoperability .
The way to achieve this security is based on the fact that the vulnerability and the implementation are uncorrelated, in other words: if one implementation suffers from a particular vulnerability, another implementation may not suffer from the exact same vulnerability.
In this way, even if there is an execution failure, you can eliminate the vulnerable client and choose the client that is working properly. This redundancy (Redundancy) is the key to the high availability guarantee of Ethereum.
We can follow in Ethereum’s footsteps and use a very similar approach at Layer 2.
Instead of a single implementation client, a fault-tolerant proof, or a zero-knowledge proof, we can create a multi-client ecosystem for Layer 2, as we did in Layer 1.
This ensures that critical vulnerabilities do not bring down the entire network.
Decentralized Optimism with Multi-Client Architecture
Optimism is designed to adhere to the philosophy of Ethereum, not only in terms of social impact, but also in terms of technology.
From writing Optimism:
The Bedrock release has been built from day one for Ethereum 2.0 to incorporate API usage, which allows us to easily integrate with multiple clients.
In fact, our goal is to reduce the code required to turn a standard Ethereum client into an Optimism client to less than 1000 lines of code, through EVM equivalence (full compliance with the Ethereum Virtual Machine specification) .
We also modularized the implementation of fault-tolerant proofs and Rollup clients into separate pieces of software. Combining these approaches allows us to mix and match proofs and clients, maximizing redundancy!
ZK Rollups: an extra layer of security
We are often asked a question: “Will you adopt zero-knowledge proof technology?”
The answer is possible, but not in the way you might think.
There is still a long way to go, but if the ZK technology becomes powerful enough to support EVM equivalence, it will be possible to add it as another client in the multi-client ecosystem, which does not mean abandoning us Current architecture or core functionality, but it does mean another layer of security.
So while ZK technology is exciting, we don’t need to wait to get a low-cost, high-security, EVM-equivalent Layer 2.
Now operating in the form of Optimism, once the ZK technology matures, it can be integrated directly into our architecture.
We are currently diving into the development core of Bedrock, which will yield detailed specifications of our EVM equivalence Rollup, as well as the first Rollup client and MIPS fault-tolerant proof “Cannon”.
At that point, the multi-client journey begins.
Our goal is to work with external teams and incentivize them to create other clients , it won’t be a quick process, but Redrock is already built and code minimization is the most important part.
To integrate these into a multi-client proof system, one needs to follow the Hydra framework. At that point, we will have the necessary confidence to remove the upgrade key.
Chain Gold Researcher Summary
1. Form a committee of Optimists.
2. Release Bedrock to realize multi-client architecture.
3. Incentivize/support alternative Optimism clients.
4. Send a multi-client proof contract.
5. Completely abandon this way of upgrading keys.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/explore-the-multi-client-architecture-of-ethereum-layer2-optimism/
Coinyuppie is an open information publishing platform, all information provided is not related to the views and positions of coinyuppie, and does not constitute any investment and financial advice. Users are expected to carefully screen and prevent risks.