Partnered With:

Vitalik’s new article: What will the future “ZK-EVM” look like?

Read this article in 28 Minutes

Over the next few years, light clients will become increasingly powerful, and the Ethereum network will effectively have a built-in ZK-EVM. So why not make that ZK-EVM natively available to rollup projects?

Original title: "What might an "enshrined ZK-EVM" look like?"

Original author: Vitalik

Original translation: Lucy, BlockBeats

Editor's note:

On December 13, Ethereum co-founder Vitalik Buterin published an article in which he discussed in depth the possible implementation forms of "ZK-EVM" (Zero-Knowledge Ethereum Virtual Machine) and the design of different versions of ZK-EVM.

The ZK-EVM concept proposed by Vitalik aims to reduce the duplication of Ethereum protocol functions by Layer-2 projects and improve their efficiency in verifying Layer-1 Ethereum blocks. The article points out that current Layer-2 EVM protocols (such as Optimistic Rollups and ZK Rollups) need to rely on EVM's verification mechanism, but this also means that they must trust a huge code base. Once there is a vulnerability in the code base, these virtual machines may be at risk of being attacked.

In addition, he also mentioned support for "almost-EVM", which allows L2's VM to use ZK-EVM within the protocol with only minor differences from EVM, while also providing flexibility for partial customization of EVM.

Layer-2 EVM protocols on Ethereum, including op rollup and ZK rollup, rely on EVM verification. However, this requires them to trust a huge code base, and if there are vulnerabilities in the code base, these virtual machines are at risk of being hacked. In addition, even ZK-EVM, which hopes to be completely equivalent to L1 EVM, requires a certain form of governance to copy changes to L1 EVM to their own EVM implementation.

This situation is not ideal, as these projects are duplicating functionality that already exists in the Ethereum protocol, and Ethereum governance is already responsible for upgrading and fixing bugs: the ZK-EVM performs essentially the same job as validating L1 Ethereum blocks! Furthermore, over the next few years, we expect light clients to become increasingly powerful, and soon fully validate L1 Ethereum executions using ZK-SNARKs. At this point, the Ethereum network will effectively have a built-in ZK-EVM. Therefore, the question arises: why not make this ZK-EVM natively available to rollup projects?

This post will describe several possible implementations of the “canonical ZK-EVM” and explore the tradeoffs and design challenges, as well as reasons for not choosing a particular direction. The advantages of implementing these protocol features should be weighed against the benefits left to the ecosystem and the interests of keeping the base protocol simple.

What key properties do we expect from the canonical ZK-EVM?

Basic functionality:Verify Ethereum blocks. This protocol feature (it is still undecided whether it will be an opcode, a precompile, or some other mechanism) should accept at least a pre-state root, a block, and a post-state root as input, and verify that the post-state root is indeed the result of executing the block on top of the pre-state root.

Compatibility with Ethereum’s multi-client philosophy. This means that we want to avoid enforcing a single proof system, and instead allow different clients to use different proof systems. This in turn implies a few key points:

· Data availability requirement: For any EVM execution that uses a canonical ZK-EVM proof, we want to be able to guarantee that the underlying data is available so that a prover using a different proof system can re-prove the execution, and clients relying on that proof system can verify these newly generated proofs.

· Proofs exist outside of the EVM and block data structures: The ZK-EVM feature will not directly take SNARKs as input within the EVM, because different clients expect different types of SNARKs. Instead, it will likely be something like blob verification: transactions can contain statements that need to be proved (pre-state, block body, post-state), opcodes or precompiles can access the contents of these statements, and client consensus rules will check data availability and the existence of proofs for each statement made in a block separately.

Auditability. If any execution is proven, we want the underlying data to be available so that users and developers can inspect it if anything goes wrong. In practice, this adds another reason why the data availability requirement is important.

Upgradeability. If a vulnerability is found in a particular ZK-EVM scheme, we want it to be fixed quickly. This means that a hard fork should not be required to make the fix. This adds another reason why it is important that the proofs exist outside of the EVM and block data structures.

Almost-EVM-enabled networks. Part of the appeal of L2s is the ability to innovate execution layers and extend the EVM. If a given L2's virtual machine (VM) is only slightly different from the EVM, it would be nice if the L2 could still use the same native in-protocol ZK-EVM as the EVM, relying only on its own code for the parts that are the same as the EVM, and only on its own code for the parts that are different. This can be achieved by designing ZK-EVM features in a way that allows the caller to specify that some opcodes, addresses, or bitfields be handled by externally provided tables instead of by the EVM itself. We can also make gas costs open to customization to a limited extent.

Open vs. Closed Multi-Client Systems

The “multi-client philosophy” is probably the most assertive requirement on this list. There is the option of abandoning this philosophy and focusing on a ZK-SNARK solution, which would simplify the design but at the cost of a bigger “philosophical shift” for Ethereum (since it would effectively be an abandonment of Ethereum’s long-term multi-client philosophy) and introducing greater risk. In the long term, for example if formal verification techniques get better, this path may be better chosen, but for now the risk seems too great.

Another option is a closed multi-client system, with a fixed set of proof systems known within the protocol. For example, we might decide to use three ZK-EVMs: PSE ZK-EVM, Polygon ZK-EVM, and Kakarot. A block would need to carry proofs for two of these three to be considered valid. This is better than a single proof system, but it makes the system less adaptable, since users must maintain validators for every known proof system, there must be a political governance process to incorporate new proof systems, and so on.

This leads me to prefer an open multi-client system, where proofs are placed "outside the block" and verified individually by clients. Individual users can verify blocks using whichever client they want, as long as there is at least one attestor that generated a proof for that proof system. Proof systems will gain influence by convincing users to run them, rather than by convincing the protocol governance process. However, this approach does have more complexity costs, as we will see.

What key properties do we want in a ZK-EVM implementation?

Besides basic correct functionality and safety guarantees, the most important property is speed. While it is possible to design an in-protocol ZK-EVM feature that is asynchronous and only returns an answer for each assertion after a delay of N time slots, the problem of everything that happens in each block being self-contained becomes much easier if we can reliably guarantee that proofs are generated within seconds.

While generating proofs for Ethereum blocks today takes many minutes or hours, we know of no theoretical reason that prevents massive parallelization: we can always combine enough GPUs to separately prove different parts of the block execution, and then combine these proofs together using recursive SNARKs. Additionally, hardware acceleration via FPGAs and ASICs may help optimize proofs further. However, actually getting to this point is a significant engineering challenge that should not be underestimated.

What might an in-protocol ZK-EVM feature look like specifically?

Similar to EIP-4844 Blob transactions, we introduce a new transaction type that contains ZK-EVM claims:

Similar to EIP-4844, the object passed in the mempool will be a modified version of the transaction:

The latter can be converted to the former, but not vice versa. We also extend the block sidecar object (introduced in EIP-4844) to contain a list of proofs for the claims made in the block.

Note that in practice we would probably want to split the sidecar into two separate sidecars, one for blobs and one for proofs, and have a separate subnet for each proof type (with an additional subnet for blobs).

At the consensus layer, we add a validation rule that a block is accepted only if the client has seen a valid proof for every claim in the block. The proof must be a ZK-SNARK proof that the concatenation of transaction_and_witness_blobs is a serialization of a (Block, Witness) pair, that executing the block (i) is valid using the Witness on the pre_state_root, and (ii) outputs the correct post_state_root. Potentially, clients can choose to wait for M-of-N of multiple proof types.

A philosophical note here is that block execution itself can be viewed as something that only needs to be checked with one of the (σpre,σpost,Proof) triplets provided in the ZKEVMClaimTransaction object. Thus, a user's ZK-EVM implementation can replace its execution client; the execution client will still be used by (i) provers and block builders, and (ii) nodes that care about indexing and storing data for local use.

Verification and Re-Proofing

Suppose there are two Ethereum clients, one using the PSE ZK-EVM and the other using the Polygon ZK-EVM. Assume that by the time we get to this point, both implementations have evolved to the point where they can prove Ethereum block executions in under 5 seconds, and that for each proof system there are enough independent volunteers running hardware to generate proofs.

Unfortunately, since individual proving systems are not formally established, they cannot be incentivized in the protocol; however, we expect the cost of running a proving node to be low compared to the cost of research and development, so we can simply fund proving nodes through a general-purpose institution for public goods funding.

Suppose someone publishes a ZKEvmClaimNetworkTransaction, except they only publish the PSE ZK-EVM version of the proof. The Polygon ZK-EVM proving node sees this, computes and republishes the object with the Polygon ZK-EVM proof attached.

This increases the total maximum delay between the earliest honest node to accept a block and the latest honest node to accept the same block from δ to 2δ+Tprove (assuming Tprove <5 seconds here).

However, the good news is that if we adopt single-slot finality, we can almost certainly "pipeline" this additional latency along with the multi-round consensus latency inherent to SSF. For example, in this 4-subslot proposal, the "head vote" step might only need to check basic block validity, but the "freeze and confirm" step will require a proof of existence.

Extensions: Support for "almost-EVM"

A desirable goal for the ZK-EVM feature is to support "almost-EVM": EVMs with some additional features. This might include new precompiles, new opcodes, allowing contracts to be written in the EVM or an entirely different VM (e.g., in the Arbitrum Stylus), or even multiple parallel EVMs with synchronous cross-communication.

Some modifications can be supported in a simple way: we can define a language that allows a ZKEVMClaimTransaction to pass a full description of the modified EVM rules. This can be used to: · Customize the gas cost table (users are not allowed to decrease gas costs, but can increase them) · Disable certain opcodes · Set block numbers (this will mean different rules depending on the hard fork) · Set a flag that activates a whole set of EVM changes that have been standardized for L2 use instead of L1 use, or other simpler changes

To allow users to add new functionality by introducing new precompiles (or opcodes) in a more open way, we can add a section of the blob of the ZKEVMClaimNetworkTransaction that contains the transcription of the precompile inputs/outputs:

The EVM execution will be modified as follows. The array inputs will be initialized to be empty. Each time an address in used_precompile_addresses is called, we append an InputsRecord(callee_address, gas, input_calldata) object to inputs and set the RETURNDATA of the call to outputs[i]. Finally, we check that used_precompile_addresses has been called a total of len(outputs) times and that inputs_commitments matches the result of the generated blob commitments to the SSZ serialization of inputs. The purpose of exposing inputs_commitments is to facilitate external SNARKs proving the relationship between inputs and outputs.

Note the asymmetry between inputs and outputs, where the inputs are stored in the hash, while the outputs are stored in the bytes that must be provided. This is because the execution needs to be done by a client that only sees the inputs and understands the EVM. The EVM execution has already generated the inputs for them, so they only need to check that the generated inputs match the declared inputs, which only requires a hash check. However, the outputs must be provided to them in full form, so they must be data-available.

Another useful feature might be to allow "privileged transactions", transactions that are called from arbitrary sender accounts. These transactions can be run between two other transactions, or when a precompile is called from another (possibly also privileged) transaction. This can be used to allow non-EVM mechanisms to call back into the EVM.

This design can be modified to support new or modified opcodes in addition to new or modified precompiles. Even with just precompiles, this design is very powerful. For example:

· By setting used_precompile_addresses to include a list of regular account addresses that have certain flags set in their account objects in the state, and making a SNARK to prove that it was constructed correctly, you can support Arbitrum Stylus-style functionality where the contract's code can be written in EVM or WASM (or other VM). Privileged transactions can be used to allow WASM accounts to call back into the EVM.

· By adding an external check that ensures that the input/output transcriptions and privileged transactions of multiple EVM executions match up in the right way, you can prove a parallel system of multiple EVMs communicating with each other over synchronous channels.

· A fourth type of ZK-EVM can work by having multiple implementations: one that translates Solidity or other high-level languages directly into a SNARK-friendly VM, and another that compiles it to EVM code and executes it in the canonical ZK-EVM. The second (inevitably slower) implementation only runs if the bug prover sends a transaction claiming there is a bug, and gets a reward if they can provide a transaction that the two handle differently.

· A purely asynchronous VM can be implemented by having all calls return zero, and mapping calls to privileged transactions added to the end of a block.

Extensions: Support for Stateful Provers

One challenge with the above design is that it is completely stateless, which makes it inefficient in terms of data utilization. By supporting stateful compression, ERC20 sends can be more space efficient, using ideal data compression, than when using stateless compression alone, up to 3 times the space savings.

In addition, a stateful EVM does not require witness data to be provided. In both cases, the principle is the same: requiring data to be available is a waste because we already know that data is available because it was input or produced by a previous execution of the EVM.

If we want to make ZK-EVM functionality stateful, then we have two options:

1. Require σpre to be either empty, a pre-declared list of key-value pairs with data available, or some previously executed σpost.

2. Add a blob commitment to a receipt R generated by the block to the (σpre,σpost,Proof) tuple. Any previously generated or used blob commitment, including those representing blocks, witnesses, receipts, or even regular EIP-4844 blob transactions, possibly with some time constraints, can be referenced in a ZKEVMClaimTransaction and accessed during its execution (perhaps via a sequence of instructions: “insert bytes N...N+k−1 of commitment i at position j of the block+witness data”).

(1) is basically saying: instead of hardening the stateless EVM proof, we harden the EVM child chain. (2) essentially creates a built-in minimal stateful compression algorithm that uses previously used or generated blobs as dictionaries. Both of these add the burden of storing more information to the proving nodes, just the proving nodes; in case (2), it is easier to limit this burden to a certain amount of time than in case (1).

Closed Multi-Proving Systems and the Off-Chain Data Argument

Closed multi-prover systems fix a certain number of proving systems in an M-of-N structure, avoiding many of the complexities described above. In particular, closed multi-prover systems do not need to worry about ensuring that data is on-chain. In addition, closed multi-prover systems will allow ZK-EVM proofs to be executed off-chain; this makes them compatible with EVM Plasma solutions.

However, closed multi-prover systems increase governance complexity and reduce auditability, which are high costs that need to be weighed against these benefits.

If we establish ZK-EVM as a protocol feature, what will be the ongoing role of "L2 projects"?

The protocol will handle EVM verification functions that L2 teams currently implement themselves, but L2 projects will still be responsible for many important functions:

Fast pre-confirmations:Single-slot finality may slow down L1 slots, and L2 projects are already providing their users with "pre-confirmations" backed by L2's own security with latency far lower than a slot. This service will continue to be a purely L2 responsibility.

MEV mitigation strategies:This may include encrypted memory pools, reputation-based order selection, and other features that L1 is reluctant to implement.

Extensions to the EVM:L2 projects can integrate substantial extensions to the EVM that provide significant value to their users. This includes both “almost-EVMs” and fundamentally different approaches like Arbitrum Stylus’ WASM support and the SNARK-friendly Cairo language.

Convenience for Users and Developers:L2 teams have done a great job of attracting users and projects to their ecosystems and making them feel welcome; they are compensated by earning MEV and congestion fees within their networks. This relationship will continue.