Explaining Zeth, the Ethereum Block Validator The First Type 0 zkEVM

Zeth, the Ethereum Block Validator, is the first Type 0 zkEVM.

Original Title: Announcing Zeth: the first Type Zero zkEVM

Author: Tim Cartens, Victor Graf, Rami Khalil, Steven Li, LianGuairker Thompson, Wolfgang Welz, Zeth Collaboration

Compiled by: bayemon.eth, ChainCatcher

On August 25th, Zeth, an open-source ZK block validator based on the RISC Zero zkVM for Ethereum, was released. Zeth is able to perform all the necessary work for constructing new blocks within the zkVM without relying on validators or sync committees. Zeth has been validated on multiple real blocks on the Ethereum mainnet and has passed all relevant tests in the Ethereum official test suite. Zeth can achieve Rust support based on zkVM and powerful modules including revm, etherthers, and alloy within four weeks. With support for continuity and Bonsai proof services through zkVM, Zeth can generate these proofs within minutes. With Zeth’s support for on-chain verification, anyone can verify these proofs on-chain at a low cost. In this article, we will provide more details. If you want to delve into the code, please check the source code and visit the RISC Zero developer portal website.

• No matter how much emphasis is placed on it (1) 10 steps to ensure the security of encrypted assets
• From now on, will OP and Base become ‘family’? Maybe not, discussing the variables and prospects of superchain cooperation.
• Binance Research In-depth Study of Decentralized Sorters

Summary

About a year ago, Vitalik explained the different types of zkEVM:

Ethereum was not initially designed around ZK-friendliness, so there are many parts of the Ethereum protocol that require a lot of computation to ZK-verify. Type 1 EVM aims to be a faithful reproduction of Ethereum and therefore does not mitigate these inefficiencies. Currently, proofs for Ethereum blocks take hours to complete.

Although there have been cases in the history of Ethereum development that can achieve this, today we are pleased to announce that Ethereum block proofs using RISC Zero’s zkVM and Bonsai service take only minutes instead of hours.

Zeth: Verifiable Ethereum Block Generation

Today, we are releasing Zeth, an open-source ZK block validator for Ethereum on RISC Zero zkVM.

Zeth can prove that a given Ethereum block is valid without relying on validators or sync committees. This is because Zeth performs all the necessary work for generating new blocks within the zkVM, including:

• Verifying transaction signatures
• Verifying account and storage states based on the parent block’s state root
• Applying transactions
• Paying fees to the block author
• Updating the state root
• Other work required for block generation

After generating a new block, Zeth calculates and outputs its hash value. By running this process in the zkVM, we obtain a ZK proof that the new block is valid.

By leveraging RISC Zero’s zkVM and popular Rust crates like revm, ether, and alloy, we developed the first version of Zeth in less than 4 weeks. With support for continuity and Bonsai proof services through zkVM, proof generation can be completed in just a few minutes. With support for on-chain verification, we can verify these proofs on-chain at a low cost.

Zeth has been validated on multiple real blocks on the Ethereum mainnet and has passed all relevant tests in the Ethereum official test suite.

Due to the fact that Zeth builds standard Ethereum blocks, it can be regarded as a type 1 zkEVM. But its significance goes far beyond this: because Zeth is built using standard Rust code base (the same code base used by popular full nodes like Reth), we prefer to think of it as a type 0 zkEVM: complete protocol compatibility and extensive code reuse.

This milestone represents a big step forward for ZK technology and the Ethereum ecosystem. In this article, we will discuss how we wrote the first version of Zeth in a matter of weeks, its performance, how it works, and what it means for the ZK project.

RISC Zero makes it easier to build zk rollups, zkEVM, lightweight clients, and bridges

We wrote Zeth for the following two reasons:

1. To make it easier for other teams to build their own ZK-driven infrastructures: ZK rollups, zkEVM, ZK lightweight clients, ZK bridges, etc. Zeth provides everything needed to generate ZK proofs for EVM-based blocks. This is a crucial component for any zkEVM or bridge. Zeth is based on the open-source revm, so project developers can easily modify or use it. Proofs can be verified on-chain (great for bridges and L2) or locally in applications (great for full nodes and lightweight clients).
2. To conduct performance-related research on EVM in Zeth’s zkVM, especially tasks related to Ethereum. (See analysis of survey results below).

zk rollup and zkEVM

As a type 0 zkEVM, Zeth enables developers to build zk rollups with full native EVM and Ethereum compatibility. Combined with support for on-chain proof verification, building ZK-driven L2 scaling solutions will become incredibly simple.

Existing ZK rollups and zkEVM circuits are designed as monolithic, making it impossible to upgrade without a high level of understanding of ZK cryptography. In contrast, the zkVM-based Zeth approach allows any developer to customize and modify according to their needs.

Zeth is based on the open-source revm, making it relatively easy to adjust to support other zkEVM and EVM-compatible chains. Therefore, Zeth will have a relatively faster response to future EIP updates. In addition, Zeth provides modular functionality, allowing developers to build their own block construction logic within it.

We hope that Zeth’s efforts will democratize zk rollups and zkEVMs, as it is worth noting that zk-driven L2 solutions previously required years of research and development and over $100 million in funding, which most projects cannot afford.

Lightweight clients and bridges

There is no doubt that the introduction of the beacon chain is a blessing for lightweight clients and bridges. These technologies are built on top of Ethereum’s mature PoS model, allowing lightweight clients and bridges to easily verify the latest blocks without having to rebuild them, provided that everyone follows the rules.

Of course, the whole point of staking is to provide economic incentives for compliant nodes. However, the threat of slashing imposed on nodes cannot completely prevent malicious behavior. External incentive factors will always tilt the “balance” of interests towards malicious actors. It is difficult to design a lightweight client or bridge that can handle these malicious behaviors correctly.

With tools like Zeth, the risk of node maliciousness is greatly reduced. Lightweight clients only need to add a few interface calls to zkVM to integrate with Zeth; on-chain applications like bridges can use our on-chain proof verification contract to integrate with Zeth.

In the near future, we can imagine lightweight clients and bridges using ZK proofs to determine if a given block is valid. This approach will significantly reduce risk without significantly increasing the cost of block verification.

This is particularly important for application chains, modular ecosystems, and new chains, as they do not yet have the same level of security provided by the large Ethereum full node community.

A solid foundation simplifies project development processes

Zeth is based on RISC Zero zkVM, powered by the RISC-V instruction set architecture, providing developers with a familiar programming experience. But our zkVM is not just a RISC-V kernel. We also have dedicated circuits for common cryptographic tasks such as hashing algorithms and signature verification.

This hybrid approach (combining a general CPU kernel with dedicated circuits) offers us the best of both worlds:

• Support for mainstream programming languages.
• No compromise on the performance of critical cryptographic operations.

As a result, we were able to quickly build Zeth using existing Rust code packages from revm, ether, and alloy. By reusing existing modules, we completed the first version of Zeth in less than 4 weeks. This speed is not achievable in less mature ecosystems.

In terms of performance, Zeth leverages our accelerator circuit for ECDSA signature verification and continuations – a new feature of our ZK framework that allows easy proof generation for large computations using parallel GPU clusters (using nVidia CUDA or Apple Metal). Continuations are easy to use: they are seamlessly provided to all guest programs running in zkVM without any code modifications, and they run normally.

With our zkVM, we can generate ZK proofs of Ethereum block validity in minutes instead of hours.

Performance

We will now introduce the performance of the Zeth block generator. Zeth is still a new product, so these data may change. However, we hope to provide some specific data as a benchmark for future work.

When it comes to performance, there are several factors to consider:

• The computational resources required to generate proofs.
• The “wall time” required to generate proofs (i.e., how long users have to wait to obtain proofs).
• The total cost (in USD) of generating proofs.

Continuity

Zeth’s zkVM can adjust performance by using continuous execution. Therefore, we need to pause and discuss how “continuous execution” works.

Our zkVM implements a standard RISC-V processor. Therefore, execution is performed in cycles. (In our circuit, most RISC-V instructions require only 1 cycle to execute, although there are exceptions). Simple programs usually require hundreds of thousands of cycles to execute, but more complex programs may require billions of cycles.

In typical ZK systems, these execution cycles are aggregated into a proof; as the number of cycles increases, the time and memory required to generate the proof also increase. But our zkVM does not follow these conventions. Earlier this year, we introduced a new feature called “continuity” that improves the drawbacks of traditional proof generation.

In terms of continuity, the proof process is divided into three stages:

We perform the necessary calculations in a non-proof simulator. During this process, we calculate the number of loops executed so far. At configurable intervals, we take a snapshot of the program’s state. This effectively divides the execution process into multiple fragments. Each fragment is small and typically represents one million or fewer cycles.

These fragments are assigned to a group of proof generation workers. They generate ZK proofs for their assigned program segments. Importantly, they can perform this work in parallel. With enough workers, all program segments can be proven within the time it takes to prove one program segment. Since the fragments are small, the required time is usually short (a few tens of seconds).

When generating segmented proofs, they are eventually rolled up. Each “rollup” operation takes a pair of consecutive segmented proofs and generates a new proof for the combination of these segments. For example, if segment 1 proves the program transitioned from state A to state B, and segment 2 proves the program transitioned from state B to state C, the rollup proves that the program transitioned from state A to state C. With enough workers, this can be done in log(N) time, where N is the number of segments.

When we delve into these numbers, we will see the actual effects of these stages.

How difficult is it to build an Ethereum block?

First, let’s take a look at the complexity of building an Ethereum block. In the table below, we selected some real-world Ethereum blocks and reconstructed them using Zeth in zkVM.

For example, block 17606771 consists of 2131 segments. Each segment represents a maximum of 2^20 execution cycles, so the entire computation requires a maximum of 2,234,515,456 execution cycles.

In general, we see that a typical Ethereum block requires 200-400 million cycles to build, but sometimes as many as 9.5 billion cycles. (Initially, we were surprised to find that these differences were not reflected in the Gas of the transactions. But upon further thought, it makes sense: the Gas system is designed for regular execution, not ZK proofs).

With continuity, this scale is easy to manage. According to this data, a peer-to-peer network running zkVM validators with 10,000 nodes is sufficient to achieve the highest parallel verification performance for maximum blocks, and this is only a small part of the 700,000 validators currently owned by Ethereum.

How long does it take to generate a proof?

To gather some basic performance data, we launched a Bonsai test instance with 64 GPU workers. Then we asked it to use Zeth proof block 17735424 (182 transactions, 3242 segments, or about 3.4 billion cycles).

To generate a proof, zkVM must first divide the execution into multiple segments. In the screenshot below, the Executor task captures this process, which takes 10 minutes to run. (Most of the time is spent on AWS tasks, such as writing to network storage.) On a local machine, the same task takes less than 6 minutes to complete. We hope to significantly reduce this time in the next year.

The Executor eventually divides the execution into 3242 fragments. For only 64 GPUs, this is a large segmentation. Therefore, each worker node must generate 50 segment proofs. As shown in the figure below, this takes 35 minutes. If we have 50 times more worker nodes, it only takes 42 seconds.

After the segment proofs are completed, rollup begins. Since there are 3242 segments, we need to perform rollup process for log_2(3242) = 12 rounds. In the early stages of rollup, there is more work than workers; therefore, the first stage takes 1 minute, the second stage takes 35 seconds, the third stage takes 25 seconds, and so on. By the seventh stage, the time stabilizes at a little over 5 seconds. Similarly, if we have more workers, each stage only takes 5 seconds.

After rollup is completed, the result is finalized, which takes another minute.

Therefore, in the case of insufficient cluster scale, we can generate proofs in about 50 minutes (with an effective speed of 1.1 MHz). If the cluster scale is appropriate, we estimate that the speed of generating proofs will be faster:

In fully parallel cases, the proof steps can be completed in 42 + 12 * 5 + 60 seconds, or 2 minutes and 42 seconds.

If we conservatively round and include the executor time, the time is approximately between 9 and 12 minutes (with an effective speed of 4.7 MHz – 6.3 MHz).

With continuous improvements to the executor and proof framework, we are optimistic that this time will be greatly reduced in the next year.

Resource consumption for generating proofs

The above test cluster has been deployed to AWS. It consists of 64 g5.xlarge proof nodes and 1 m5zn.xlarge execution node. According to Amazon, each g5.xlarge node has:

• 1 GPU with 24 GiB GPU memory
• 4 vCPUs with 16 GiB memory capacity

At the time of writing this article, the on-demand price for these instances is $1.006 per hour, and the reserved instance price is $0.402 per hour. Meanwhile, Amazon’s specification table shows that our m5zn.xlarge node has:

• 4 vCPUs, 16 GB of memory

At the time of writing this article, the on-demand price for this instance is $0.3303 per hour.

We can use these numbers to roughly estimate the proof-of-work cost for block 17735424 described above.

Recall that we deployed 64 proof-of-work nodes, and under this deployment, generating a proof requires 50 minutes (end-to-end). Ignoring idle worker time, the cost of 64 proof-of-work nodes plus one execution node for 50 minutes is 50/60 * (64 * 0.402 + 0.3303) = $21.72. This is an overestimate because it assumes we are paying for idle workers. If we don’t consider the cost of idle workers (e.g., shutting them down or having them do other work), the cost is approximately $19.61.

• This block has 182 transactions, i.e., $0.11 per transaction.
• The total value of the transactions is 1.125045057 Eth, approximately $2137.59. Therefore, for every $1 of proof, $109.01 of user funds can be obtained.
• The reward paid for the same block is 0.117623263003047027 Eth (excluding transaction fees). At the time of writing this article, this is approximately $223.48. Therefore, our proof costs approximately 8.7% of the block reward.
• The transaction fees add up to 0.03277635 Eth, i.e., $62.28, which is more than 3 times the cost of our proof.

It is worth noting that these dollar estimates are independent of the scale of the cluster! What matters is the number of segments. This is because the cost of one machine sequentially completing 2 tasks is the same as the cost of 2 machines parallelly completing 1 task. Therefore, if the cluster size is larger, the speed of generating proofs will be faster, but the cost will not be higher.

There are several ways to further reduce costs. In addition to continuing to improve the performance of zkVM, perhaps by adding a Keccak accelerator, we can also look for cheaper instances elsewhere. Importantly, given the lower machine specifications we are using (and the fact that our zkVM supports nVidia Cuda and Apple Metal), this work can be easily done by a p2p network composed of ordinary consumer PCs and Macs.

On-chain Verification

As mentioned above, we use a RISC Zero Groth16 verifier to verify the Zeth proof on Sepolia. This is a relatively new part of the RISC Zero protocol stack, which was released earlier this month. It works by using Bonsai to convert the native STARK proof of zkVM into an equivalent SNARK proof and submit that proof to an on-chain SNARK verifier.

If we treat the transaction input as UTF-8 data, we will see that this proof corresponds to block 17735424.

Using Bonsai, the conversion from STARK to SNARK takes about 40 seconds. Verifying SNARK on the chain consumed 245,129 gas (approximately $5.90 at the time of writing).

Of course, one advantage of zkVM is that it can merge multiple proofs into one. With this feature, a whole set of proofs can be verified on the chain without using any extra gas. In this way, the cost of on-chain verification can be distributed among the entire set of proofs, reducing the cost for each individual.

What does this mean for Ethereum?

As mentioned earlier, Ethereum was not designed with ZK-friendliness in mind. As demonstrated by zkEVMs, many things can be done in different ways, especially in terms of opcodes, digital signatures, and hash functions.

Although these modifications do improve performance, we can still achieve stable performance without using these modifications. In Vitalik’s article introducing different types of zkEVM last year, it took several hours to prove the validity of an Ethereum block, but now we can do it in minutes. ZK performance is rapidly improving, and we have reason to believe that this trend will continue in the coming years.

Appendix: How Zeth Works

This section is for developers.

In a nutshell, Zeth constructs blocks in the same way as a full node: starting with a parent block, a list of transactions, and a block author, then performing a lot of calculations (verifying signatures, running transactions, updating global state, etc.) and finally returning the hash value of the new block.

But unlike a full node, we do this work in zkVM. This means we obtain a ZK proof that proves the validity of a block with a given hash value.

Of course, this is not without its challenges. In this section, we will introduce these challenges and how we address them.

Cryptography

The first challenge is cryptography. Building an Ethereum block involves a lot of work, the most important of which is hashing (Keccak-256) and signature verification (ECDSA with secp256k1).

Our zkVM has accelerated support for elliptic curves, so ECDSA signature verification is not difficult.

But when it comes to hashing, we’re not so lucky. Our zkVM provides accelerated support for Sha2-256, but (at the time of writing) does not support Keccak-256. Therefore, currently we only use the Keccak implementation in the sha3 Rust crate. Through profiling, we know that this takes a significant amount of cycles. It’s not the optimal solution, but our zkVM can handle it, and we can also reuse it and add a Keccak accelerator in the future.

Accounts and Storage: Performance and Security

In Ethereum, accounts and storage are tracked by the global Merkle Patricia Trie (MPT).

According to Etherscan’s data, at the time of writing, this tree contains the state of nearly 250,000,000 unique Ethereum addresses. Overall, this is not a very large amount of data, but it is enough to make us cautious about its storage and usage. In particular, the performance of MPT is crucial.

However, performance is not the only factor, we must also consider security.

The block generator of Zeth runs in zkVM as a client. This means it cannot directly access the Ethereum p2p network or other RPC providers. Instead, it relies on data provided by independent programs running outside of zkVM.

When analyzing the security of ZK applications, we must assume that the external programs are malicious and may provide malicious data. To prevent this, ZK applications must verify the validity of the data provided to them.

For the Zeth block generator, this means verifying the state of all relevant accounts and storages (i.e., the accounts and storages required to execute the given list of transactions).

Fortunately, EIP-1186 provides a mechanism that defines a standard way to prove the state of given accounts (and their storages) through Merkle inclusion.

In principle, the Zeth block generator can verify the state of accounts and storages by validating a set of EIP-1186 inclusion proofs. However, this approach is not ideal.

Instead, it is better to use the data in the EIP-1186 inclusion proofs to construct a partial MPT. This is an MPT that only includes the nodes relevant to the given list of transactions; unrelated branches are represented by their corresponding hash values. You can think of a partial MPT as a “union” of Merkle inclusion proofs, or if you prefer, as a subset proof of Merkle.

The process of verifying a partial MPT is similar to verifying a regular EIP-1186 proof: calculate the root hash and compare it with the state root of the parent block. If they are equal, the integrity of the accounts and storages can be trusted.

Once the partial MPT is verified, transactions can be applied and the partial MPT can be updated. The new state root can be obtained by calculating the new root hash of the partial MPT.

1. Before running the Zeth block generator, we first run the transaction list in a sandbox to determine which accounts and storages are relevant. (This process also allows us to determine the oldest relevant ancestor blocks, which is necessary to support the blockhash() query).
2. We obtain EIP-1186 inclusion proofs for each relevant account and storage. (We also obtain the relevant ancestor blocks).
3. We use these inclusion proofs to construct a partial MPT that includes all relevant data.
4. We start zkVM, let it run the Zeth block generator, and provide the partial MPT and other inputs (parent block, transaction list, etc.).

In zkVM, the Zeth block generator:

1. Verifies if the root of the partial MPT matches the state root of the parent block.
2. Verifies the hash chain of ancestor blocks until the parent block.
3. Applies transactions.
4. Updates the partial MPT.
5. Uses the new root hash of the partial MPT as the state root of the new block.

After the Zeth block generator is finished, it outputs the hash value of the new block.

This hash value includes a commitment to the parent block, and therefore, it includes the state root of the parent block (used to verify the original partial MPT). This means that malicious validators cannot provide invalid data for accounts and storages unless they provide an invalid parent block.

In other words, if the parent block is valid, then the new block generated by Zeth is also valid.

Therefore, if someone gives you a new block and a ZK proof generated by Zeth, you can check the validity of the block by verifying the following three points:

1. Make sure the ZK proof is valid and from Zeth. For off-chain applications, you can use the functions provided by the zkVM Rust crate for verification. For on-chain applications, you can use our on-chain proof verifier for verification.
2. Make sure the ZK proof commits to the hash of the new block.
3. Make sure the parent block has the expected hash.

If all of these checks pass, then the new block is valid.

Limitations and Future Improvements

The goal of our project is to study the performance of block construction. For this reason, we decided to limit the scope to post-merge blocks.

In addition, although Zeth is able to prove that a given block is valid, it currently cannot prove consensus (i.e., that the block is indeed included in the canonical chain). This may change in the future, perhaps by adding checks for validator or synchronous committee signatures in zkVM.

Finally, Zeth is a new software. While we have conducted some tests (including Ethereum test suites and various real-world blocks), Zeth may still contain some bugs. At the time of writing this article, it should be considered experimental software.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!