Last month, we announced the most significant upgrade in Optimistic Ethereum history-OVM 2.0. Recently, we have migrated Optimistic Kovan to make it truly capable of one-click deployment and improve its stability. And, the mainnet will be launched in the next three weeks,
But this article is not about one-click deployment or incremental improvement.
This article mainly introduces how EVM Equivalence (completely consistent with the Ethereum virtual machine specification) will become the next common standard in the L2 field.
A brief history of Optimistic dispute agreements
First, let’s review the history of rollup.
The beginning of Rollup
Optimistic L2 solutions are all related to disputes. If you think that Ethereum is an all-powerful and decentralized court, then the core point of L2 expansion is: “Don’t go to court to cash the check-if the check is returned, go back.”
In fact, the research on scalability in the past six years can be boiled down to one thing: what kind of “refusal checks” can be enforced. First, only a set of pre-agreed participants can trade with each other (state channel). The next thing is that anyone can trade, but it may also be censored (plasma). Finally, we also solved the review problem (rollups).
Before rollup, we already knew how to run smart contracts on all these models-it just didn’t make any sense. After all, who wants to run Uniswap among a few friends or be censored for a week? And rollup can promise to provide us with a real L2 interactive experience similar to Ethereum.
Of course, just “promising” to provide a real L2 interactive experience similar to Ethereum does not mean that it can be created and realized. When building the first L2 AMM Unipig, we had to recreate Uniswap with custom code compatible with the rollup dispute contract – instead of using the EVM itself to build it.
Due to the relatively simple design of Uniswap, the above construction method is feasible. However, even something as basic as Solidity can no longer be used, which is really not a good sign. For non-developers, Uniswap is currently one of the simplest DeFi smart contracts. It is really not a good phenomenon if even Uniswap has to be changed a lot to easily achieve compatible rollup.
So far, the rapid development of Ethereum has already exceeded the escape velocity. The exponentially growing Ethereum ecosystem cannot be re-architected around non-EVM interfaces at all. Therefore, in addition to providing the “raw” scale, L2 must also ensure that the difference between L1’s court system and EVM is minimized. This forces rollup to pioneer in the following two aspects at the same time:
- Build a scalable, product-level rollup infrastructure
- Solve the long-term unacceptable EVM-in-EVM (building EVM in EVM) problem.
The Turing-completeness of Ethereum means that it can indeed solve these problems, but in the process of our research, we found that if we want to migrate Ethereum to L2 within a reasonable time frame, we Need to sacrifice something and make a compromise.
This compromise is what we later call EVM compatibility (EVM “Compatibility”).
The argument for EVM compatibility is simple: as long as Ethereum applications can be reasonably ported to run on rollup-no matter how this is done behind the scenes-we can catch up with Ethereum’s escape speed.
“Is this compatibility?”
Ride the wind and waves
At first, this compromise achieved some success. In 2020, as many users have moved from Ethereum to other L1 competing chains (these chains are ignoring security and value under the guise of “low cost”), we are racing to launch OVM. In January this year, Optimism went live on the mainnet. 10 months later, we have processed millions of transactions, saving users hundreds of millions of dollars in transaction fees.
However, the escape speed generated by the Ethereum network effect has many forms, and from the phenomenon of the soaring transaction activity of Ethereum L1, it can be seen that what other L1 chains and L2 lack is: the infrastructure owned by Ethereum L1. In the past six years, members of the Ethereum community all over the world have worked together to transform Ethereum from a simplified prototype to a more complete system:
- Thousands of development tools have been deeply integrated into the EVM.
- The emergence of multi-billion dollar companies is only to provide services and improve the operation of Ethereum’s node software.
- The transaction processing speed of 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 these great victories to also happen on L2.
However, it did not meet everyone’s expectations.
There is a difference between EVM compatibility and EVM equivalence. Just being satisfied with compatibility means that you are forced to modify (or even need to be completely re-implemented) the low-level code that the Ethereum infrastructure also relies on. If L2 wants to benefit from the wave of Ethereum infrastructure network effects, they must have EVM equivalence.
After Optimistic Ethereum went online and started to develop, we found that more and more Ethereum tools were difficult to deploy on the Optimistic Ethereum system. This was due to our old EVM compatibility design concept.
We know we can do better. In order for the public to use OE, we need more than just compatibility with the EVM contract; on the contrary, we need to be fundamentally equivalent to the EVM itself.
EVM equivalence can help fill the gap between the infrastructure network effect of Ethereum L1 and the execution environment of Ethereum L2.
EVM Equivalence: With the help of Ethereum’s EVM application wave
What is EVM equivalence?
In short: EVM equivalence is exactly in line with the specifications of the Ethereum Yellow Book (the official definition of the protocol). By definition, L1 Ethereum software must comply with this specification.
In the most essential way, this means that the existing Ethereum stack will also be integrated with the L2 system. Every debugger, every tool chain, and every node implementation must be integrated with L2. We believe that any L2 that provides any EVM development experience must meet this standard-it is not acceptable to fail to meet the standard at all.
Why is EVM equivalence needed?
From the very beginning, we have built our software on top of Ethereum’s most robust and common implementation “Geth”-this is the only feasible way for us to achieve product-level Ethereum L2. OVM v1 introduces a containerization system, which is built on Geth’s EVM to help avoid the tedious re-implementation of the entire EVM on L1.
This combination achieved some early wins, but since EVM does not natively support containerization, it is not free. Even for our Geth-centric team, these changes are beginning to accumulate. With the development of Optimistic Ethereum, the power of EVM equivalence cannot be ignored:
- Projects like Solidity, Vyper, and Hardhat are selflessly committed to developing OVM versions of development tools, but we do so at the risk of dispersing these resource-constrained teams. This taught us a lesson that the team needs to invest considerable manpower to maintain a non-EVM equivalent code base.
- As each line of code changes, it becomes more difficult to adopt experimental implementations like Erigon. In other words, we always need to spend manpower to be responsible for integrating future client implementations
- Compared with the existing super-optimized version, re-implementing part of the EVM brings some gas overhead. This tells us that minimizing the gas cost requires an EVM equivalent design solution.
It’s time to find a better solution, although it requires tedious work.
How to achieve EVM equivalence?
Fortunately, we have found a better way than tediously re-implementing EVM in EVM. This is what you have to do.
Separate block generation and execution
In practice, we do need to make some changes to the L2 Ethereum: especially how to generate blocks. On L1, nodes determine blocks through the PoW consensus mechanism; on L2, these transactions are applied by sending batches of batch transactions to the “parent chain” (L1 Ethereum). If an L2 uses its own PoW, it will become an L1! Therefore, from this level, this “equivalence” is meaningless.
A core model of block chain modularization is to separate consensus from execution-that is, the process of determining and executing the next block is different. We can borrow this model and use it in L2. Basically, we only need to define a function: receive the L1 block, process the rollup transaction in it, and then generate the L2 block-exactly the same format as the L1 block. After that, the execution of L2 can be defined as equivalent to L1.
Eth2 Merge API
So, what is the current status of consensus/execution modularity in existing L1 client implementations? Well: it is about to be standardized in all Ethereum implementations.
Facts have proved that the ETH 2 merger and rollup with EVM equivalence require the same abstraction: the “parent chain” role of the beacon chain to the PoW chain is exactly the same as the role of L1 to rollup. This will make it very easy to use the L1 client in L2.
Well, we have introduced why EVM equivalence allows us to implement a powerful, modular concept and complete an extremely simple client implementation. But how do we perform this operation on the chain? First of all, the power of this modularity lies in its flexibility-as long as a solution is equivalent to EVM, we can use it. This means that whether it is an improvement to the fraud proof or the EVM equivalent zero-knowledge proof (if feasible), it can be easily embedded in the existing off-chain stack.
However, in the short term, we currently need some feasible solutions-we have found them. There is a scheme like this, to achieve a perfect EVM equivalent implementation in Solidity, but EVM is very complicated and contains many VM instructions, so this is a very huge task. In addition, future updates to the EVM must also be re-implemented in Solidity.
Our solution is not to implement EVM in Solidity, but to implement a VM with a smaller and simpler instruction set, and run EVM in the 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.
Too long to read: We allow Geth itself to operate in a controversial-friendly environment. Since Geth has EVM equivalence, so does its environment. In this case, we don’t need to re-implement EVM on the chain and perform future verification of the system for future upgrades of EVM.
We are working with our favorite compiler expert George Hotz to build the first EVM-equivalent proof system. The progress is exciting-since the London hard fork, the system has been able to run all L1 blocks. Running an L1 block via fraud proof is an interesting and counter-intuitive idea – but it is required for formal EVM equivalence!
Wow-there are a lot of exciting things to say about this solution, but we have to leave the rest for future posts!
Looking forward to the future of Ethereum
If Ethereum is to realize its rollup-centric vision, then rollup must be Ethereum-centric.
This is what EVM equivalence provides.
Fraud proves immortal
This Geth-centric modular design is not only an elegant implementation for us to use-it will be a big step towards the goal of mass fraud proof infrastructure. At present, if you want to safely design and launch a rollup, you need to have an in-depth understanding of the L2 dispute game design and how they work with node software. This greatly limits everyone’s room for innovation-imagine that if every web developer had to become an expert in IP networks, system management, and microchip manufacturing, it would be very frustrating.
The future rollup will be so simple that it does not require L2 experts to deploy. This means that L2 will no longer compete on the “how” or “whether” to provide security, but on the security content they provide. The content of the competition includes:
- Performance, stability and uptime
- Network effects, ecosystem specialization and communities
- Resistance to MEV and sequencing tools
All in all, this means that rollups with EVM equivalence will compete for their degree of decentralization. This is a huge victory for the democratization of the entire ecosystem, which will also make the entire industry more anti-fragile and anti-censorship.
This also means that our team can finally focus on our core competence-and this is the most important part-to build the fastest, most reliable and safest L2 Geth in the world.
The constraints of Ethereum compatibility have been lifted.
Make Ethereum the standard
The power of EVM equivalence in the final analysis is that it helps us achieve standardization.
In a multi-chain world, “a copy of the code goes the world” becomes especially critical. Once the code is written once, it can be deployed on any chain. Doesn’t that sound attractive?
Having many “compatible” chains, each of which is slightly different, can lead to fragmentation: from the need for a single EVM expert team to handle a single code base, to the need to form an EVM expert team for each code base of each chain.
Web3 is about harmonization and open-source standards, and equivalence makes EVM hopeful to become a standard-to avoid repeating past mistakes.
Even if this standard continues to evolve, our L2 can develop collaboratively effortlessly. L1 and L2 move forward hand in hand, locked up.
This benefit is two-way-almost all Ethereum EIP can be applied on L2, and rollup will become an exciting new and innovative real-time testing environment. Imagine a rollup between the incentive test network and the main network, verifying new transaction types, precompilations and EOFs in a natural environment, and testing for unforeseen results before they are broadcast to L1.
One of the biggest obstacles to DeFi is that you can test as you want. There is no substitute for DeFi’s real-time environment. You cannot “recreate” DeFi on a testnet, so when you want to test changes, you always need to “test in production”.
EVM equivalence allows us to test EIP in a real-time environment and make more secure and long-term improvements to the overall Ethereum environment without the need for a “hard fork.”
Ethereum is our eternal focus
We recently launched the first experiment on retroactive public goods fundraising mechanisms. The agreement income of USD 1 million will soon be allocated to public goods that are conducive to the ecological development of Ethereum! Some people ask us why this money will be allocated to the entire Ethereum system instead of just the Optimistic Ethereum ecosystem.
I hope that after understanding the EVM equivalence through this article, everyone can understand why: we come from the same ecosystem.
Layer2 has long promised to promote Ethereum as a multi-chain system, and vibrant cities are deeply exploring the boundaries of this new cyberspace. Although we can expect these chains to be diversified and rich, the EVM equivalence brings new connections between these chains and Ethereum-not just as a settlement layer, but as the deepest part of its composition.
Posted by:CoinYuppie，Reprinted with attribution to:https://coinyuppie.com/making-ethereum-the-standard-introduction-to-evm-equivalence/
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.