In the multi-chain world, “code once, deploy anywhere” has become extremely important.
Last month, we announced Optimistic Ethernet Square in the history of the most significant upgrade. Recently, we migrated Optimistic Kovan to a true one-click deployment and improved its stability. The mainnet will follow up in less than three weeks.
But this article is not about one-click deployment or incremental improvement. The main point we expressed in this article is that we believe that EVM Equivalence (EVM Equivalence, that is, fully compliant with the specifications of the Ethereum Contract Virtual Machine EVM), will become the next common standard for L2.
History of Optimistic Dispute Resolution Agreement
First, let’s review the path taken by the previous generation of Rollups solutions.
Dawn of Rollups
The core of adopting Optimistic Rollups’ L2 solution is all about resolving disputes. If you think of Ethereum as an all-purpose, decentralized court, then the core point of the L2 expansion solution is: “Don’t go to the court to cash the check every time-only go when the check bounces.”
In fact, the expansion research of the past 6 years can be boiled down to one thing: what kind of “bounced checks” should be enforced.
The original solution was that only a set of pre-agreed parties could trade with each other (state channels!). Then it becomes that anyone can trade, but it may also be censored (plasma!). In the end, we solved the review problem (Rollups!).
Before Rollups’ expansion solution, we already knew how to run smart contracts on all these models—but it didn’t make much sense. Who wants to run Uniswap among a few friends , or in a way that needs to be reviewed for a week? Rollups promises to provide a real Ethereum-style L2 experience.
Of course, just “promising” a real Ethereum-style L2 experience can’t really create a wide range of deployments. For Unipig (the first L2 AMM), we must recreate Uniswap with custom code compatible with Rollup dispute contracts, not the EVM itself.
Due to the relatively simple design of Uniswap, this is feasible, but when basic things like Solidity variables can no longer be used, this is not a good sign. For non-developers, the difficulty is too high; Uniswap is already one of the simplest DeFi smart contracts, even if Uniswap needs to be overhauled to be “compatible with Rollup” out of the box, this is not a good sign!
So far, the development speed of Ethereum has far exceeded the speed of escape. An exponentially growing ecosystem simply cannot be rebuilt around non-EVM interfaces. Therefore, in addition to providing “primitive” expansion, L2 has the responsibility to ensure that the L1 court system maintains a minimum difference with the EVM. This forces the Rollups solution to create a precedent in two aspects at the same time:
- Build a rollup infrastructure that is scalable and ready for production. *Solve the long-standing and poorly-reputed embarrassing problem of “Re-deploy EVM in EVM” (EVM-in-EVM).
The Turing completeness of Ethereum means that we know it can be achieved, but in the research process we learned that we need to sacrifice something to transplant Ethereum applications to the L2 field within a reasonable time frame.
This sacrifice is called EVM “compatibility”.
The argument is simple: as long as the Ethereum application can be reasonably ported to the rollup solution to run, no matter how this is done behind the scenes, we can capture the speed of Ethereum’s escape.
“This is compatibility?”
Initially, this compromise paid off. In 2020, we launched OVM because users fled Ethereum and moved to other underlying public chain (L1) competitors under the guise of “cheap fees”, giving up security and value. We launched the mainnet in January, and in the past 10 months, we have saved users hundreds of millions of dollars through millions of transactions.
However, the escape speed generated by the Ethereum network effect has many forms, but our soaring usage highlights that other L1 and L2, compared with Ethereum, lack a core component: infrastructure. In the past 6 years, the global community of Ethereum has transformed it from a barebones prototype to a very powerful infrastructure:
- Thousands of development tools have been deeply integrated into the EVM.
- Companies worth billions of dollars have emerged in the field of purely serving and improving node software.
- Ethereum itself is getting faster and faster.
The wave of Ethereum network effects will only get bigger and bigger. Since everything is open source, one might expect that Ethereum L2 can also apply the great results mentioned above. But so far, little effect has been achieved.
EVM compatibility is different from EVM equivalence. Just being satisfied with compatibility means that you are forced to modify or even completely re-implement the lower-level code. The Ethereum support infrastructure also relies on these codes. If L2 solutions want to take full advantage of the network effects of Ethereum’s infrastructure, they must become EVMs.
With the development and growth of Optimistic Ethereum, we continue to find that more and more Ethereum tools cannot be used. The main reason is our old EVM compatibility design concept. We know that we still have a lot of room for improvement. In order to truly support public use, we need not only to be compatible with the EVM contract, but also to be fundamentally equivalent to the EVM itself.
EVM equivalence is mainly related to how we bridge the gap between the network effect of the Ethereum L1 infrastructure and the execution environment of the Ethereum L2.
EVM Equivalence: Taking advantage of the widespread adoption of Ethereum
What is EVM equivalence?
Simply put: EVM equivalence is in full compliance with the Ethereum Yellow Paper, which is the formal definition of the protocol. By definition, L1 Ethereum software must comply with this specification. This means—at the most fundamental level, the existing Ethereum stack will now also be integrated with the L2 system—every debugger. Every tool chain. Each node is implemented. We believe that any L2 that provides an EVM experience must meet this standard-any deficiency is unacceptable.
Why is EVM equivalence a good solution?
From day 0, we have built our software on Geth (Ethereum’s most powerful and popular deployment)-this is the only viable path to a production-ready Ethereum L2 solution. OVM v1 introduces a containerized system on top of Geth’s EVM, helping to avoid the cumbersome re-implementation of the entire EVM on L1.
This combination achieved a certain degree of success in the early days, but since EVM itself does not support containerization, it is not free. Even for our team focused on Geth, these changes are starting to accumulate. With the development and growth of Optimistic Ethereum, equivalence has incredible power:
- Projects such as Solidity, Vyper, and Hardhat are selflessly committed to the development of their OVM version of the development tools, but the risk we create is to allow these teams with limited resources to further diversify their resources. This teaches us that teams always need to invest in manpower to maintain non-equivalent code bases.
- As each line of code changes, it becomes more difficult to adopt experimental deployments like Ergon. This teaches us that we will always need to be committed to integrating future customer deployments.
- Compared with the existing ultra-optimized version, re-implementing part of the EVM will incur gas overhead. This teaches us that to minimize gas cost, we need an EVM equivalent design concept.
It’s time to find a better solution, even if the solution may be a bit tedious.
How to achieve EVM equivalence?
Fortunately, we have found a better way without the cumbersome redeployment of EVM in EVM. The following steps are all you need to do.
Realize the separation of block production and execution
In practice, we do have to make some changes to Ethereum’s L2: especially how to generate blocks. On L1, nodes use a proof-of-work (PoW) consensus mechanism to determine blocks; on L2, batch transactions are realized by sending batch transactions to the “parent chain” (L1 Ethereum). If L2 uses its own PoW consensus, it will be L1! So “equivalence” is basically absurd at this level.
One of the core features of blockchain modularization is the separation of consensus and execution-that is, the determination and execution of the next block are completed through different processes. We can borrow this model and use it in L2. Simply put, we just defined a function that receives L1 blocks, processes them for rollup transactions, and outputs L2 blocks in exactly the same format as L1 blocks. Therefore, L2 execution can be defined as equivalent to L1.
Ethereum 2.0 merged API
What is the status of consensus/implementation modularity in existing L1 client deployments? Hmm: It will be standardized in all Ethereum deployment scenarios.
It turns out that the Ethereum 2.0 merger requires exactly the same abstraction as the EVM equivalent of Rollup: the beacon chain is equivalent to the exact same “parent chain” role L1 does for Rollup. This will make it very easy to use the L1 client in L2.
Standards are implemented
Okay, we’ve covered why equivalence opens the door to powerful modular abstraction and extremely simple client deployment. But how do we actually perform this operation on the chain?
First, the power of this modularity lies in its flexibility-as long as the solution is equivalent to the EVM, we can use it. And when they become feasible, it means that improvements to anti-fraud proofs, even zero-knowledge proofs equivalent to EVM, can be easily inserted into existing off-chain stacks.
But in the short term, we currently need some feasible methods-we have found this. One solution is to achieve a perfect EVM equivalent deployment in Solidity, but EVM is a complex beast with many VM instructions, so this is a difficult task. In addition, future updates to the EVM must also be redeployed in Solidity.
Our solution is not to deploy EVM in Solidity, but to deploy a VM with a smaller and simpler instruction set, and run EVM in this VM during the fraud proof period. To do this, we must simply compile an existing EVM compiler, such as geth, to run in a simpler VM.
To summarize briefly: we allow Geth itself to operate in a controversial environment. Since Geth is equivalent to EVM, so is this environment. We are therefore able to bypass the difficulty of redeploying EVM on the chain, and at the same time get rid of the heavy work of dealing with future upgrades of EVM, so that this solution will not be out of date soon.
We are working with our favorite compiler expert George Hotz to build the first EVM equivalent proof system. The progress is exciting-the system has been able to run all L1 blocks since the London hard fork. Running the L1 block with a fraud proof proof is an interesting and counterintuitive idea-but it is exactly what is needed for equivalence!
Wow-there are many exciting things to say about this method, but we must leave the rest for future posts!
If Ethereum is to achieve a Rollups-centric future, Rollups must become Ethereum-centric.
Equivalence is to solve this problem.
The fraud prevention evidence is dead. Proof of fraud prevention, rest in peace
This Geth-centric modular design is not only the elegant deployment we use, it is a big step towards the commoditization of anti-fraud infrastructure. Today, safely designing and launching rollup requires an in-depth understanding of L2 dispute resolution mechanisms and how they work with node software. This severely limits innovation-imagine that in this world, every Web developer must also be an expert in IP networking, system management, and microchip manufacturing.
Rollups in the future will be very simple, so simple that no dedicated L2 experts are required to deploy. This means that L2 will no longer compete in how or whether to provide security, but instead compete for the content it provides security. This includes competition in the following areas:
- Performance, stability and uptime
- Network effects, ecosystem specialization and communities
- Tools to prevent miners extractable value (MEV) and sorting
All in all, this means that the rollup equivalent to EVM is competing in terms of decentralization. This is a huge victory on the road to democratization of the entire ecosystem, and an important step for our entire industry in eliminating vulnerabilities and censorship.
This also means that our team can finally focus on our core competence (the most important part): building the fastest, most reliable, and safest L2 Geth in the world.
The constraints of Ethereum compatibility have been lifted.
The great power of EVM equivalence can be attributed to standardization.
In a multi-chain world, “code once, deploy anywhere” becomes crucial.
Having many “compatible” chains, each of which is slightly different, can lead to fragmentation: from requiring a team of EVM experts to deal with a single code base, to a large team of EVM experts dealing with each code base of each chain.
The core of Web3 is about harmonization and open source standards, and equivalence provides a development path for the EVM, which is clearly developed as a standard, to avoid repeating past mistakes.
Even if this standard continues to evolve, our anti-fraud proof method also means that L2 can be coordinated and developed effortlessly. L1 and L2 go hand in hand and move forward together.
This is a two-way benefit-almost all Ethereum EIP can be adopted on L2, and rollup has become an exciting and innovative real-time testing environment. Imagine a rollup project located between the incentive test network and the main network. It is another way to prove new transaction types, pre-compilation and EOF, and test for unforeseen consequences before they are successfully upgraded to L1.
One of the biggest obstacles to DeFi is that you cannot test as you want, because there is no live environment that can replace DeFi. DeFi cannot be “recreated” on the testnet, so when you want to test changes, you always “test in production”.
EVM equivalence allows us to test EIP in a real-time environment and make safer and long-term improvements to the overall Ethereum environment without the need for a “frightening hard fork.”
Ethereum consolidates into the future
We recently launched the first experiment to trace back public product funding. The agreement income of 1 million USD will soon be rewarded to public products that benefit Ethereum! Some people ask us why this money will flow to the entire Ethereum, not just limited to the Optimistic Ethereum ecosystem.
Hope that through a new understanding of EVM equivalence, you can understand the truth: we are the same ecosystem.
L2 has a long-term commitment to promote the multi-chain future of Ethereum, with dynamic projects reaching the forefront of this new cyberspace. We can expect that these chains will be diversified and abundant, but following the EVM equivalence, a new connection interface with Ethereum was born-not only as the settlement layer, but also at the bottom of its composition.
Ethereum will consolidate along the way, and it has always been.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/optimism-why-does-the-evm-equivalent-have-to-become-the-l2-common-standard/
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.