Vitalik: Discuss the various "built-in ZK-EVM" version types and design challenges

Words: Vitalik Buterin

Compilation: 1912212.eth, Foresight News

Layer 2 EVM protocols on top of ETH, including optimistic rollups and ZK rollups, rely on EVM validation. However, this requires them to trust a huge codebase, and if there are bugs in that codebase, these VMs are at risk of being hacked. In addition, this means that even ZK-EVMs, which want to be fully equivalent to the L1 EVM, need some form of governance to replicate the changes to the L1 EVM into their own EVM practices.

This situation is not ideal, as these projects are replicating functionality that already exists in the ETH Workshop protocol, and ETH Governance is already responsible for upgrading and fixing bugs: ZK-EVM is essentially the same job as validating Layer 1 ETH Workshop blocks!In addition, in the coming years, we expect light clients to become more and more powerful, and soon reach the point where ZK-SNARKs are used to fully validate Layer 1 EVM execution. At that point, the ETH network will effectively construct the built-in ZK-EVM. So, the question arises: why not make the ZK-EVM itself suitable for rollups as well?

In this article, we’ll look at a few of the “built-in ZK-EVM” versions that can be implemented, and discuss the trade-offs and design challenges, as well as the reasons for not going in a particular direction. The benefits of implementing protocol features should be weighed against the benefits of leaving things to the ecosystem and keeping the underlying protocol simple.

What key features do we want from the built-in ZK-EVM?

• Basic function: Validate ETH blocks. The protocol function (which is not yet clear whether it is opcode, precompilation, or other mechanism) should accept at least one pre-state root, one block, and one post-state root as input, and verify that the post-state root is actually the result of the execution of the block.
• Compatible with multiple clients of ETH Square. This means that we want to avoid just one attestation system and instead allow different clients to use different attestation systems. This leads to the following points:
• Data availability requirements: For any EVM execution that uses the built-in ZK-EVM for proofs, we want to guarantee the availability of the underlying data so that provers using a different attestation system can re-attest the execution and allow clients who rely on that attestation system to validate the newly generated proofs.
• Proofs exist outside of the EVM and chunk data structures: The built-in ZK-EVM feature does not take SNARKs as input within the EVM, as different clients will expect different types of SNARKs. Instead, it might be similar to blob validation: a transaction can include (pre-state, block body, post-state) claims that need to be attestated, the contents of which can be accessed by an opcode or precompiler, and the client-side consensus rules will check the data availability and proof of existence for each claim separately.
• Auditability. If any execution is proven, we want the underlying data to be usable so that in the event of a problem, users and developers can examine it. In fact, this adds another reason why data availability requirements are so important.
• Upgradeability. If a ZK-EVM solution is found to have a bug, we want to be able to fix it quickly. This means that there is no need for a hard fork to fix. This adds to why proofs exist outside of the EVM and block data structures.
• Supports almost all EVMs. One of the attractions of L2 is to innovate at the execution layer and scale the EVM. If the VM for a given L2 is only a little bit different from the EVM, then it would be nice if L2 could still use the ZK-EVM within the native protocol in the same parts as the EVM, and rely only on its own code in different parts. This can be achieved by designing a ZK-EVM function that allows the caller to specify bit fields or opcode lists or addresses that are handled by externally provided tables rather than the EVM itself. We can also make the gas cost open to editing to some extent.

“Open” and “closed” multi-client systems

The “multi-client philosophy” is probably the most subjective requirement on this list. There is an option to abandon it and focus on the ZK-SNARK scheme, which will simplify the design, but at the cost of being a bigger “philosophical turning point” for ETH Workshop (since it is effectively abandoning ETH Workshop’s long-standing multiclient philosophy) and introducing greater risks. In the future, when formal verification technology becomes better, it may be better to choose this path, but now it seems that the risk is too great.

Another option is a closed multiclient system where a fixed set of attestation systems is known in the protocol. For example, we might decide to use three ZK-EVM: PSE ZK-EVM, Polygon ZK-EVM, and Kakarot. A block requires proof provided by two of these three to be valid. This is better than a single proof system, but it makes the system less adaptable because users have to maintain validators for each proof system that exists, and there will inevitably be political governance processes to incorporate new proof systems, etc.

This motivates me to prefer an open multiclient system, where proofs are placed “outside the block” and verified by the client individually. Individual users can use any client they want to validate blocks, as long as at least one prover creates a proof for that attestation system. The attestation system will gain influence by convincing users to run them, not by convincing the protocol governance process. However, this approach does have a higher cost of complexity, as we will see.

What key properties do we want to gain from the ZK-EVM implementation?

In addition to the basic functional correctness and safety guarantees, the most important attribute is speed. While we can design the ZK-EVM feature within the protocol, which is asynchronous and only returns each declared answer after a delay of N slots, the problem becomes much easier if we can reliably guarantee that a proof will be generated in a matter of seconds, no matter what happens in each block is self-contained.

While it takes many minutes or hours today to generate proofs for ETH blocks, we know that there is no theoretical reason to prevent mass parallelization: we can always combine enough GPUs to prove the individual parts of a block’s execution separately and then put the proofs together using recursive SNARKs. In addition, hardware acceleration through FPGAs and ASICs can help further optimize proofs. However, getting to this point is a huge engineering challenge that should not be underestimated.

What might the ZK-EVM feature look like within the protocol?

Similar to EIP-4844 blob transactions, we have introduced a new transaction type that contains ZK-EVM claims:

It’s important to note that in practice, we might want to split the sideload into two separate sideloads, one for blobs and one for proofs, and set up a separate subnet for each type of proof (and an additional subnet for blobs).

At the consensus layer, we added a validation rule that only accepts a block if the client sees a valid proof of each claim in the block. The proof must be a ZK-SNARK, prove that the concatenation of transaction_and_witness_blobs is the serialization of the (Block, Witness) pair, and that the block is executed with pre_state_root on the Witness

(i) is valid, and

(ii) Output the correct post_state_root. Possibly, the client can choose to wait for multiple types of proof of M-of-N.

It is important to note here that the block execution itself can simply be thought of as one of the triples that need to be checked along with the triples provided in the ZKEVMClaimTransaction object (σpre, σpost, Proof). As a result, the user’s ZK-EVM implementation can replace its execution client; the execution client will still be executed

(i) Provers and Block Builders and:

and (ii) nodes that care about indexing and storing data for local use.

In addition, because this architecture separates execution from validation, it may provide more flexibility and efficiency for different roles in the ETH ecosystem. For example, a prover can focus on generating proofs without worrying about the specifics of execution, while execution clients can be optimized to meet the needs of specific users, such as fast synchronization or advanced indexing capabilities.

Verification and re-attestation

Suppose there are two ETH clients, one using the PSE ZK-EVM and the other using the Polygon ZK-EVM, at this point, both implementations have evolved to the point where they can prove the execution of ETH block in less than 5 seconds, and for each proof system, there are enough independent volunteers running the hardware to generate proofs.

Unfortunately, because individual proof-of-the-box systems are not formalized, they cannot be incentivized in the protocol, however, we anticipate that the cost of running proofs will be lower compared to research and development, so we can easily fund provers through institutions funded for public goods.

Let’s say someone publishes a ZKEvmClaimNetworkTransaction, but they only publish a proof of the PSE ZK-EVM version. The Proof Node of the Polygon ZK-EVM sees this, calculates and republishes the object, along with the Proof of the Polygon ZK-EVM.

This will increase the total maximum delay between the earliest honest node accepting a block and the latest honest node accepting the same block from δ to 2δ+Tprove (assuming Tprove<5s here).

The good news, however, is that if we adopt single slot finality, we can almost certainly “pipeline” this additional delay along with the multi-round consensus latency inherent in SSF. For example, in this 4-slot proposal, the “head vote” step might only need to check the validity of the base block, but the “freeze and confirm” step would require the presence of a proof.

Extension: Support for “almost-EVMs”

The desirable goal for the ZK-EVM feature is to support “almost-EVMs”: EVMs with additional features. This could include new precompilation, new opcodes, contracts that can be EVM or completely different VMs (e.g. in 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 ZKEVMClaimTransaction to pass the full description of the modified EVM rule. This can be used in the following situations:

1. Customized gas cost table (users are not allowed to reduce gas costs, but they can increase them)
2. Disable certain opcodes
3. Set the block number (this will mean that there are different rules depending on the hard fork)
4. Set the flag to activate the full set of EVM changes that are already standardized for L2 but not for L1 use, or other simpler changes

In order to allow users to add new functionality in a more open way, for example by introducing a new precompiled (or opcode), we can add a way to include the precompiled input/output records in the blob section of ZKEVMClaimNetworkTransaction:

class PrecompileInputOutputTran(Container):used_precompile_addresses: List[Address][VersionedHash]inputs_commitments: List[Bytes]outputs: List

The EVM execution will be modified as follows. An array called inputs will be initialized as empty. Whenever the address in used_precompile_addresses is called, we add an InputsRecord(callee_address, Gas, input_calldata) object to inputs and set the called RETURNDATA to outputs[i]。 Finally, we check that used_precompile_addresses was called len(outputs) a total of times, and that inputs_commitments matches the result of the resulting blob’s commitment to SSZ serialization of inputs. The purpose of exposing inputs_commitments is to enable the external SNARK to prove the relationship between inputs and outputs.

Note the asymmetry between inputs and outputs, where inputs are stored in hashes and outputs are stored in bytes that must be provided. This is because the execution needs to be performed by a client that only sees the input and understands the EVM. EVM executions have already generated inputs for them, so they only need to check if the generated input matches the declared input, which only requires hash checking. However, the output must be fully provided to them, so data availability must be available.

Another useful feature might be to allow “privileged transactions” to be invoked from any sender account. These transactions can be run between two other transactions, or within another (and possibly privileged) transaction, while calling the precompilation. This can be used to allow non-EVM mechanisms to call back to the EVM.

The design can be modified to support new or modified opcodes, in addition to new or modified precompilations. Even with only precompilation, the design is very powerful. For example:

Functionality like Arbitrum Stylus can be supported by setting used_precompile_addresses to include a list of regular account addresses with a certain flag set in their account object in the state, and generating SNARKs that prove that they are built correctly, where a contract can write its code in an EVM or WASM (or other VM). Privileged transactions can be used to allow WASM accounts to call back EVM.

By adding an external check to ensure that the input/output records and privileged transactions performed by multiple EVMs are matched in the correct way, a parallel system of multiple EVMs communicating with each other over a synchronization channel can be demonstrated.

A ZK-EVM of type 4 can work by having multiple implementations: one that converts Solidity or another higher-level language directly into an SNARK-friendly VM, and another that compiles it into EVM code and executes it in the prescribed ZK-EVM. The second (and inevitably slower) implementation can only run if the failure prover sends a transaction claiming to have an error, and if they are able to offer that the two handle different transactions, the bounty can be collected.

You can implement a pure asynchronous VM by returning zero to all calls and mapping the calls to privileged transactions that are added to the end of the block.

Extension: Support for Proof of State

The challenge with the above design is that it is completely stateless, which makes it poor in terms of data efficiency. With ideal data compression, stateful compression can make ERC20 sends more space-efficient by up to 3x compared to stateless compression alone.

In addition to this, stateful EVMs are not required to provide witness data. In both cases, the principle is the same: it is a waste to ask for data to be available when we already know that the data is available because it was input or produced by a previous execution of the EVM. **

If we want to make the ZK-EVM feature stateful, we have two options:

Requires σpre to be either null, or a pre-declared list of keys and values for which data is available, or some previously executed σpost.

Add a blob commitment to the (σpre, σpost, proof) tuple for the receipt R generated by the block. Any previously generated or used blob commitments that can be referenced in ZKEVMClaimTransaction and accessed during their execution, including commitments representing blocks, witnesses, receipts, or even regular EIP-4844 blob transactions (there may be some time limits, which can be referenced by a series of instructions: "Insert byte N of commitment i at position j of block + witness data… N+k-1”）

(1) The basic meaning is: instead of establishing stateless EVM verification, we will establish an EVM child chain.

and (2) essentially creates a minimal built-in stateful compression algorithm that uses a previously used or generated blob as a dictionary. Both of these place a burden on the prover node, and only the prover node to store more information;

In case (2), it is easier to time limit this burden, while in case (1) it is more difficult.

Arguments for closed multi-prover systems and off-chain data

A closed multi-prover system, in which there is a fixed number of proofs in the M-of-N structure, avoids much of the complexity described above. In particular, a closed multi-attester system does not need to worry about ensuring that the data exists on-chain. In addition, a closed multi-attester system will allow ZK-EVM proofs to be executed off-chain, making them compatible with EVM plasma solutions.

However, closed multi-attester systems increase governance complexity and weaken auditability, which is a high cost that needs to be weighed against these advantages.

If we build in ZK-EVM and make it a protocol feature, what is the ongoing role of the L2 project?

The EVM validation functions that are currently implemented by the L2 team themselves will be handled by the protocol, but the L2 project will still be responsible for a number of important functions:

• Fast pre-confirmation: Single-slot finality can slow down L1 slots, whereas L2 already provides users with a pre-confirmation-backed service with its own security, with latency much less than one slot. This service will continue to be the sole responsibility of L2.
• MEV mitigation strategies: This may include features such as encrypted mempools, reputation-based sequential selection, etc., which L1 is reluctant to implement.
• Extensions to the EVM: Tier 2 projects can introduce significant extensions to the EVM that provide significant value to their users. This includes “almost-EVMs” and completely different approaches, such as Arbitrum Stylus’ WASM support and SNARK’s friendly Cairo language.
• Convenience for users and developers: Tier 2 teams put a lot of effort into attracting users and projects into their ecosystem and making them feel welcome; they get paid by capturing MEV and congestion fees within their network. This relationship is here to stay.