EVM: Deciphering EVM Compatibility
Complaining about crazy ways the Web3 industry deals with naming issues and the way a tweet or a single blog post quickly gets labeled as a standard has been my guilty pleasure for a while now.
While I enjoy to be given the ability to build and break things without rules in order to create something new I also love having standards, as without them operational excellence is impossible.
Standardization is a crucial element in ensuring consistency, quality, and interoperability across various sectors and processes. By establishing clear standards, organizations can ensure that their products or services maintain a certain level of quality, which in turn builds trust with consumers.
Additionally, standardization facilitates communication and cooperation between different entities, making it easier to achieve common goals or comply with international regulations.
Standards help in reducing errors, improving efficiency, and promoting innovation by creating a common language and set of expectations.
Projects usually love to declare that they fit a known standards, even if they do not, so Web3 as an early stage industry, where marketing teams often like to make bold statements, has the tendency to be full of declarations of creating a new standard or belonging to a group of projects that fit a certain standard that is highly marketable. (yes, word standard will be used many many times in this post)
So, in 2022. with a number of projects declaring themselves ZK EVMs and Ethereum or EVM equivalents, Vitalik decided he had to step in and declare what a true EVM is and how these new projects fit into Ethereum by ZK EVM type.
I believe that most of the things Vitalik posts are not a guide but his own opinions that are shaped by his view of what is best for Ethereum and I do believe that he wants what is best for Ethereum to be what is best for Web3. These posts are also created to serve as talking points rather than step by step tutorials. (This is a tendency also noticed in his latest article about enshrining things into the protocol).
However many people do view these as guides and step-by-step tutorials.
If all projects to transition to Type 1 or Type 2 that Vitalik proposes we would indeed probably have no problems (or very few problems) with tooling and infrastructure portability, but I am unsure that this is actually possible.
The article stated that various projects have recently been announced, focusing on the use of ZK-SNARK technology.
Their primary objective was to use ZK-SNARKs to create cryptographic proofs for the execution of Ethereum-like transactions. This approach can either simplify Ethereum chain verification or develop ZK-rollups that offer similar functionality as Ethereum but with enhanced scalability.
While these projects share a core aim, they differ in their specific implementations and the trade-offs they choose between speed and practicality.
The article was written in order to classify the various forms of EVM equivalence and analyze the pros and cons associated with each type.
The classification that happened was as follows:
Type 1 ZK-EVM (Fully Ethereum-equivalent)
Type 1 ZK-EVMs aim for full Ethereum equivalence to simplify proof generation, retaining all of its original components which are crucial for verifying current Ethereum blocks, thus enhancing scalability at layer 1, especially focusing on transaction execution and smart contract logic.
They are particularly advantageous for rollups as they enable reuse of existing Ethereum infrastructure, allowing current execution clients to process rollup blocks seamlessly.
However, a notable downside is the extensive computation required for ZK-proof due to Ethereum's original design, making ZK-proofs for Ethereum blocks time-consuming to generate, although innovative engineering or future use of ZK-SNARK ASICs could potentially mitigate this issue.
Type 2 ZK-EVM (Fully EVM-equivalent)
Type 2 ZK-EVMs strive for full EVM equivalence but not entire Ethereum equivalence, differing mainly in external data structures like block structures and state trees, while maintaining compatibility with current applications and requiring minor tweaks to Ethereum to facilitate development and proof generation.
The modifications in Type 2 ZK-EVMs, which are focused on enhancing prover speeds, include adjusting data structures, possibly replacing Ethereum’s Keccak and RLP-based Merkle Patricia tree, and introducing other hash functions like Poseidon, which although streamlines certain aspects, still presents challenges in proving the EVM due to its inherent inefficiencies.
Despite improved but still slow prover time, most of the developer infrastructure remains usable albeit with some modifications, and potential incompatibilities may arise.
Type 2.5 ZK-EVM (EVM-equivalent, Except for Gas Costs)
Type 2.5 ZK-EVMs aim to improve worst-case prover times by proposing an increase in the gas costs of certain EVM operations that are hard to ZK-prove.
While this modification in gas costs could lead to reduced compatibility with developer tools and impact some applications, it is viewed as a safer adjustment compared to making deeper changes in the EVM, although developers are advised to be cautious of block gas limits and avoid fixed gas amount calls.
Alternatively, setting absolute limits on operation execution frequency is suggested as a simpler approach in circuits, but this conflicts with EVM's security assumptions and would be more aligned with a Type 3 designation than Type 2.5.
Type 3 ZK-EVM (Almost EVM-equivalent)
Type 3 ZK-EVMs aim to optimize prover times and simplify EVM development by implementing specific changes, while still resembling EVM-equivalent systems.
Although these alterations, such as excluding complex features like precompiles, lead to simplified development and faster prover times, they result in higher incompatibility with some existing applications.
While the goal is to maintain compatibility with a majority of applications, some apps might require minor modifications due to the exclusion of certain features or slight differences in the VM's handling of specific scenarios.
Presently, no ZK-EVM team aspires to remain a Type 3. This is viewed as a temporary phase before incorporating precompiles and transitioning to Type 2.5.
Future Type 1 or Type 2 ZK-EVMs might willingly become Type 3 ZK-EVMs by integrating new ZK-SNARK-friendly precompiles, offering valuable features for developers with efficient prover times and gas expenses.
Type 4 ZK-EVM (High-level-language Equivalent)
Type 4 systems are designed to process smart contract source code, written in high-level languages like Solidity or Vyper, and compile it into a language optimized for ZK-SNARK compatibility, which significantly minimizes overheads by bypassing the need to ZK-prove individual EVM execution steps, leading to swift prover times and reduced costs, hence promoting decentralization.
However, a notable disadvantage is the greater incompatibility; while standard applications may compile seamlessly, many don't strictly adhere to these standards, and issues could arise such as address discrepancies where contract addresses in Type 4 may not match those in the EVM, affecting applications reliant on precise bytecode.
Besides, while numerous applications employ handwritten EVM bytecode for efficiency, Type 4 might not fully support it, and the debugging infrastructure tailored for EVM bytecode isn't directly transferrable to Type 4, although this limitation can be mitigated by utilizing debugging tools designed for conventional high-level or intermediary languages.
Vitalik concludes his article by urging developers to maintain Ethereum equivalence wherever possible, asserting that deviating from Ethereum equivalence carries numerous drawbacks. I find myself in agreement with Vitalik; developers should exercise caution and be on the lookout for potential pitfalls concerning these EVMs. Nonetheless, the article doesn't quite elucidate what these pitfalls are. In my estimation, the primary detriment lies in veering away from standardization, which significantly impacts developer tooling. Over time, developer tools and infrastructure have evolved in a manner that largely hinges on the operations of an Ethereum-based node. A common misconception is equating EVM compatibility with RPC compatibility.
The discussion extends to most EVM-based projects, not solely ZK EVMs, as many are tweaking their EVM implementations to gain a competitive edge in terms of speed and user-friendliness within their respective environments. The overarching objective is to facilitate the migration of Solidity code to their networks or rollups, as opposed to running them on the Ethereum mainnet. Initially, many, myself included, perceived this as Ethereum interoperability given the EVM's standing as the current industry standard. The notion was that adopting the EVM signified Ethereum compatibility. However, the reality is often different. The challenge of Ethereum compatibility frequently stems not from the ability to migrate Solidity code, but from the requisite access tooling and infrastructure vendors need to the EVM for operational purposes.
They rely not just on Json RPC but also on opcodes and sometimes even on types of file storage, state trees, transaction trees, precompiles or any other in-consensus logic, no matter how peripheral it may seem to someone writing a new EVM just to get Solidity to execute.
It is not.
This is where my problem with the naming conventions starts.
Outside of the naming debate - which pretty much revolves around who implemented EVM in line with Ethereum's Yellow Paper - the main premise of the article revolves around how much of the architecture the projects are changing compared to Ethereum in order to reach faster proving times.
The article resonates well from an Ethereum community standpoint, yet the introduced naming debate unveils a couple of complex notions. The first concern revolves around the term "Type." Vitalik delineates that Type 1 EVMs are authentic EVM equivalents since they emulate Ethereum’s EVM implementation without operational divergences. However, post Type 1, the waters become muddied as these classifications don’t standardize how opcodes, states, precompiles, or storage are addressed, rendering the categorization from Vitalik's piece slightly contentious.
Indeed, a Type 1 ZK EVM should be regarded as Ethereum equivalent, allowing seamless operation of existing tooling on it without substantial modifications. All Type 1 ZK EVMs should exhibit uniformity. This notion holds true to an extent for Type 2, but for Types 2.5, 3, and 4, the comparison becomes unfeasible when assessing projects categorized similarly by this classification. The proposed naming convention is predicated on Ethereum's EVM implementation, not on a parity among implementations within the same category.
From the vantage point of tooling and vendor implementation, the effort required might be more pronounced for a Type 2 than for Types 3 or 4, making the classification, although elucidative in articulating Vitalik and the Ethereum community’s stance towards these projects, less pragmatic for infrastructure and tooling development to support these projects. The principal objective of these solutions is scalability, which casts doubt on the likelihood of projects transitioning to Type 1, especially if proof generation continues to be a time-intensive endeavor.
That leads right into the second issue that I have with the article and that is that, while agreeing that different types are not unambiguously "better" or "worse" than other types, Vitalik hopes everyone transitions to Type 1.
However, considering that the main value of these projects is scaling Ethereum, and that the currently popular transition of many projects into an Ethereum Layer 2 is happening because of that, it is hard to believe projects will actually follow this route as they cannot sacrifice execution times.
As stated at the end of the article the main reason for all of this is code redundancy. I would argue that code redundancy is not important if you do not have access to the same tools and vendors that the apps are relying on to run and to be developed, deployed and monitored.
To attain portability and redundancy, the key is not to transition different types into the same type, but to establish clear standards for each type from an EVM architecture standpoint. This standardization would enable better tooling support for these projects, with the expectation that these tools would function consistently across similar types of EVMs.
Practically, it's more advantageous to create a pathway for all Type 3 EVMs to standardize around tooling, code redundancy, and execution, and to extend similar standardization to other types as well. A Type 3 EVM should be thoroughly comparable to another Type 3 in terms of code execution and tooling redundancy, rather than to a Type 1.
The current scenario significantly complicates the development of L2 tooling. Vendors now face three core challenges:
1) The obligation to maintain and support versions of their tools and infrastructure for an expanding array of non-standardized EVMs, with each update posing a potential system breakage and affecting Service Level Agreements (SLAs).
2) The deployment procedures and infrastructure requisites of most robust tools are not tailored for smaller networks, as they are designed for L1s where comprehensive indexing is essential and a wide variety of dApps can be deployed.
3) Given the above, the business models of most robust tools are ill-suited to accommodate price-sensitive L2 and appchain solutions.
For Ethereum tooling to evolve and robustly support the multichain future of the internet, invoking standards is imperative, and EVM standardization ranks high among these necessities. Naming conventions like EVM types are crucial, representing just one dimension where industry fragmentation transpires, further compounding existing industry fragmentations and leading to misunderstanding and unpredictable outcomes.
This does mean that tools might need to support 5 different implementations to complement 5 different standards, but at the same time this seems more realistic than supporting every different project individually without standards, or all projects being built in the same way to be fully EVM equivalent.
While fostering a "build and innovate freely" environment is vital for innovation, the capacity to standardize and repurpose existing tools is even more crucial for broader adoption.
While I appreciate the central thesis of the article addressing the issue inherent in altering the EVM's functionality, I contend that it falls short of proposing a tangible solution for categorization and standardization.
Vitalik wrote the article about ZK EVM types to clear some confusion on how different certain projects are from Ethereum in terms of EVM implementation. It was a blog post that was needed at that moment and never even meant to be regarded as an industry-wide standard,
In my view, a more expansive and well-structured endeavor to standardize EVM types is imperative to simplify the comprehension for individuals regarding the platform they are building upon, the tools and vendors accessible to them, and the trade-offs entailed.
Such an initiative would significantly enhance the value of the entire Web3 and Blockchain ecosystem.