Title: Announcing Zeth: the first Type Zero zkEVM

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

Translation: bayemon.eth, ChainCatcher

On August 25th, the open-source ZK block validator Zeth, based on RISC Zero zkVM, was released. Zeth completes all the work required to construct a new block in 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 is capable of implementing Rust support based on zkVM and powerful modules including revm, etherthers, and alloy within 4 weeks. With support for continuity and Bonsai proof services in zkVM, Zeth can generate these proofs in 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 introduce more details. If you want to delve into the code, please check the source code and visit the RISC Zero developer portal website.

Abstract

About a year ago, Vitalik outlined 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 fully replicate Ethereum, so it cannot alleviate these inefficiencies. Currently, proof of Ethereum blocks takes 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 have released the open-source ZK block validator Zeth 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 completes all the work required to generate a new block in zkVM, including:

• Verify transaction signatures
• Verify account and storage state based on the parent block's state root
• Apply transactions
• Pay fees to the block author
• Update state root
• Other work required to generate a block

After generating a new block, Zeth will calculate and output its hash value. By running this process in zkVM, we can obtain a valid ZK proof for the new block.

By leveraging RISC Zero's zkVM and popular Rust crates (such as revm, ether, and alloy), we wrote the first version of Zeth in less than 4 weeks. With support for continuity and Bonsai proof services in 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.

Because Zeth constructs standard Ethereum blocks, it can be considered a Type 1 zkEVM. But its significance goes far beyond that: because Zeth is built using standard Rust code modules (the same as popular full nodes like Reth), we prefer to consider it as Type 0 zkEVM: full protocol compatibility and extensive code reuse.

This milestone represents a significant 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 few weeks, its performance, how it works, and what this means for ZK projects.

RISC Zero Makes Building zk rollup, zkEVM, Light Clients, and Bridges Easier

We wrote Zeth for two reasons:

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

zk rollup and zkEVM

As a Type 0 zkEVM, Zeth enables developers to build zk rollups with fully native EVM and Ethereum compatibility. With Zeth's 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 for developers 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 as needed.

Zeth is open-source based on 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 also 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. It's worth noting that ZK-driven L2 solutions previously required years of research and development and over $100 million, which most projects could not afford.

Light Clients and Bridges

Undoubtedly, the introduction of the beacon chain is a boon for light clients and bridges. These technologies build on the mature PoS model of Ethereum, allowing light clients and bridges to easily verify recent blocks without reconstructing them, provided everyone follows the rules.

Of course, the full meaning of staking lies in providing economic incentives for rule-abiding 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—and designing a light client or bridge that can handle these malicious behaviors correctly is difficult.

With tools like Zeth, the risk of node malfeasance is greatly reduced. Light clients can easily integrate with Zeth by adding a few call interfaces to zkVM; on-chain applications such as bridges can integrate with our on-chain proof verification contract and Zeth.

In the near future, we can imagine light clients and bridges using ZK proofs to determine the validity of a given block. This approach will significantly reduce risk without significantly increasing the cost of verifying blocks.

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 Ethereum's large full node community.

A Solid Foundation Simplifies Project Development

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

This hybrid approach (combination of a general-purpose CPU core and acceleration circuits) provides us with the best of both worlds:

• Support for mainstream programming languages.
• Uncompromised performance of critical cryptographic operations.

Therefore, 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 impossible to achieve in a less mature ecosystem.

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

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

Performance

We will introduce the performance of the Zeth block generator. Zeth is still a new product, so this data may change; however, we hope to provide some specific data as a baseline for future work.

When it comes to performance, several factors need to be considered:

• Computational resources required to generate proofs.
• "Wall time" required to generate proofs (i.e., how long users need to wait to obtain proofs).
• Total cost (in USD) to generate proofs.

Continuations

Zeth's zkVM can adjust performance by using continuations. Therefore, we need to pause and discuss how "continuations" work.

We perform the necessary computations in a non-proof simulator. During this process, we calculate the number of loops executed so far. At configurable intervals, we take snapshots of the program's state. This effectively divides the execution process into multiple segments. Each segment is small, typically representing 1 million or fewer cycles.

These segments are assigned to a group of proof workers. They generate ZK proofs for their assigned program segments. Importantly, they can work in parallel. With enough workers, all program segments can be proven within the time required to prove a single program segment. Since the segments 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 the program transitioned from state A to state C. With enough workers, this can be completed in log(N) time, where N is the number of segments.

As we delve into these numbers, we will see the practical effects of these stages.

How Difficult Is It to Build an Ethereum Block?

First, let's 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 produced 2131 segments. Each segment represents up to 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 was designed for regular execution, not for ZK proofs).

With continuity, this scale becomes easily manageable. Based on this data, a peer-to-peer network with 10,000 nodes running zkVM validators is sufficient to achieve maximum parallel verification performance for the largest blocks, and this is only a small fraction of the 700,000 validators Ethereum currently has.

How Long Does Proof Generation Take?

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

To generate the proof, zkVM must first segment the execution. In the screenshot below, the Executor task captures this process, which took 10 minutes to run (most of the time was spent on AWS tasks, such as writing to network storage). The same task on a local machine takes less than 6 minutes to complete. We hope to significantly reduce this time in the coming year.

The Executor eventually divided the execution into 3242 segments. This is a large number of segments for only 64 GPUs. Therefore, each worker node must generate proofs for 50 segments. As shown in the screenshot, this took 35 minutes. If we had 50 times more worker nodes, it would only take 42 seconds.

After the segmented proofs are completed, the rollup process begins. With 3242 segments, we need to perform 12 rounds of rollup. In the early stages of rollup, there is more work than workers; so the first stage took 1 minute, the second stage took 35 seconds, the third stage took 25 seconds, and so on. By the seventh stage, the time stabilized at just over 5 seconds. Similarly, with more workers, each stage would only take 5 seconds.

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

Therefore, with an insufficient cluster size, we can generate the proof in approximately 50 minutes (effective speed of 1.1 MHz). If the cluster size is appropriate, we estimate that the proof generation speed will be faster:

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

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

As we continue to improve the executor and proof framework, we are optimistic that this time will be significantly reduced in the coming year.

Resource Consumption for Proof Generation

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

• 1 GPU with 24 GiB of GPU memory
• 4 vCPUs and 16 GiB of memory

At the time of writing, the on-demand price for these instances is $1.006 per hour, and the reserved instance discounted price is $0.402 per hour. Meanwhile, the m5zn.xlarge node has:

• 4 vCPUs and 16 GB of memory

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

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

Recalling that we deployed 64 proof nodes, in this deployment, proof generation takes 50 minutes (end-to-end). Ignoring idle worker time, the cost for 64 proof nodes plus one executor 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 do not consider the cost of idle workers (e.g., shutting them down or assigning them other tasks), the cost is approximately $19.61.

• This block has 182 transactions, approximately $0.11 per transaction.
• The total value of the transactions is 1.125045057 Eth, approximately $2137.59. Therefore, each $1 of proof can secure $109.01 of user funds.
• The block's reward is 0.117623263003047027 Eth (excluding transaction fees). At the time of writing, 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, or $62.28, more than 3 times our proof cost.

It is worth noting that these dollar estimates are independent of the cluster's size! The number of segments is what matters. This is because the cost of one machine completing two tasks in sequence is the same as two machines completing one task in parallel. Therefore, if the cluster size is larger, the proof generation speed will be faster, but the cost will not be higher.

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

On-Chain Verification

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

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

Using Bonsai, the conversion from STARK to SNARK takes approximately 40 seconds. Verifying the SNARK on-chain consumes 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-chain without using any additional gas. This way, the cost of on-chain verification can be spread across the entire set of proofs, reducing the cost for everyone.

What Does This Mean for Ethereum

As mentioned earlier, Ethereum was not designed with ZK-friendliness in mind. As the case of zkEVMs shows, many things can be done differently, especially in terms of opcodes, digital signatures, and hash functions.

While these changes do improve performance, we are still able to achieve stable performance without using these changes. When Vitalik introduced the different types of zkEVM last year, proving the validity of an Ethereum block took several hours; now, we can do it in minutes. ZK performance is rapidly improving, and we have reason to believe that this trend will continue over the next few years.

Appendix: How Zeth Works

This section is for developers.

In a nutshell, the way Zeth builds blocks is the same as a full node: we start with the parent block, transaction list, and block author, then perform a lot of computations (verify signatures, run transactions, update global state, etc.), and finally return the hash of the new block.

But unlike a full node, we are doing this work in zkVM. This means we get a ZK proof proving that a block with a given hash is valid.

Certainly, this is not without its challenges. In this section, we will introduce these challenges and how we have addressed them.

Cryptography

The first challenge is cryptography. Building an Ethereum block requires a lot of work, with the most significant being 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 are not as fortunate. 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 from the sha3 Rust crate. Through profiling, we know that this requires a significant number of cycles. This is not the best solution, but our zkVM can handle it, and we can 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 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.

But performance is not the only factor; we also have to consider security.

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

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

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

Fortunately, EIP-1186 provides a mechanism for this, defining a standard way to prove the state of given accounts (and their storage) through Merkle inclusion.

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

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

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

After verification, the partial MPT can be used to apply transactions and update the partial MPT. 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 run the transaction list in a sandbox to determine which accounts and storage are relevant. (This process also allows us to determine the oldest relevant ancestor block, which is necessary to support the blockhash() query).
2. We obtain EIP-1186 inclusion proofs for each relevant account and storage. (We also obtain relevant ancestor blocks).
3. We use these inclusion proofs to construct a partial MPT containing all relevant data.
4. We start zkVM and run the Zeth block generator, providing 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 parent block's state root.
2. Verifies the hash chain of ancestor blocks up to the parent block.
3. Applies transactions.
4. Updates the partial MPT.
5. Uses the new root hash of the partial MPT as the new block's state root.

After the Zeth block generator is completed in zkVM, it outputs the hash of the new block.

This hash includes a commitment to the parent block, and therefore includes the parent block's state root (used to verify the original partial MPT). This means that a malicious validator cannot provide invalid data for accounts and storage without providing 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 checking the following three points:

1. Ensure the ZK proof is valid and comes from Zeth. For off-chain applications, you can use functions provided by the zkVM Rust crate for verification. For on-chain applications, you can use our on-chain proof verifier for verification.
2. Ensure the ZK proof submits the hash of the new block.
3. Ensure 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 research the performance of block construction. To achieve this, we have decided to limit the scope to merged blocks.

Additionally, while Zeth is able to prove the validity of a given block, 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 sync committee signatures in zkVM.

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

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。