Subscribe to Taiko Labs
>54K subscribers
Taiko is building a Type 1 (Ethereum-equivalent) ZK-EVM. What benefits come from using a Type 1 ZK-EVM? To answer this, we need to understand the changes a ZK-EVM can make at various levels and the tradeoffs they incur. Let’s learn together.
This post makes a few assumptions about your understanding of Ethereum. We are going to suggest that you first understand the following:
What a ZK-EVM (EVM-compatible ZK-Rollup) is at a high level
How Ethereum stores data in the form of a Merkle Patricia Tree and uses Merkle proofs
How smart contracts price their execution with a concept of gas
With that out of the way, here are the five questions we’ll be exploring:
What is a Type 1 ZK-EVM?
What does a Type 2+ ZK-EVM change?
What are the impacts of these changes?
Why does proof generation cost matter?
Why use a Type 1 ZK-EVM?
One way to think of the different types of ZK-EVMs is by their proximity to Ethereum’s architecture at the base layer, such as:
The usage of a Merkle Patricia Tree for the various state trees
The different types of ZK-EVMs make tradeoffs between compatibility and proof generation cost. A Type 1 ZK-EVM prioritizes compatibility over proof generation cost.
Another term for Type 1 ZK-EVMs is “Ethereum-equivalent”. This term comes from the fact that Type 1 ZK-EVMs make no changes to the Ethereum architecture, whether it be the hash function, state trees, or gas costs. This equivalency allows us to reuse execution clients with minimal modification.
In this post, when we say Type 2+, we are referring to Type 2/2.5 ZK-EVMs. Type 3/4 ZK-EVMs are not quite EVM-equivalent, so we’ll put them aside for the discussions of this post.
Type 2+ ZK-EVMs change parts of the Ethereum stack which are complex to prove. The changes might include:
Changing gas costs for ZK-unfriendly operations
Changing the Keccak hash function to a more ZK-friendly one
These changes result in lower proof generation costs while maintaining bytecode level compatibility, but they could also have some other impacts.
Let’s break this down via examples to paint a clearer picture of how these changes could impact you as a smart contract developer.
A classic example of using gas as a security mechanism is setting a fixed gas limit for an ETH transfer so that state changes are not possible in the destination address. Smart contracts that rely on this for security will no longer be secure if gas costs are changed, which would allow state changes to occur. Another scenario arises if Keccak hashes get super expensive, and the security of the smart contract depends on a minimum number of hashes to be possible (like for a fraud-proof).
If your smart contract is optimized for gas costs as specified on Ethereum L1, changing these gas costs could cause the contract to use more gas than intended. You also might be using tools to fine-tune the gas usage in your contract, and changing gas costs could break those tools. Additionally, increasing gas costs could cause the contract to exceed the block gas limit. For example, if the contract frequently uses the Keccak opcode, the developer might need to find more gas-efficient ways to get things done or change the hash function.
A Type 2+ ZK-EVM might use a different hash function — and produce different state roots. This change could break compatibility for smart contracts that rely on the block hash. For example, a bridge contract might use a Merkle proof for verification, and changing the hash function from Keccak to something else would break these proofs. Relying on the block hash this way would also break with the introduction of Verkle trees. Hopefully, we can have an abstracted precompile to use in the future.
The Keccak hash function is widely accepted as a battle-tested and secure hash function, so changing it for an alternative could be risky. Additionally, Keccak has much faster native performance and lower gas fees when compared to some more ZK-friendly hash functions, such as Poseidon.
A higher proof generation cost can be seen as a negative for a few reasons:
A potentially longer time to finality
Imbalances the ratio between gas cost and proof generation cost
More expensive transactions
We are not concerned about the longer time to finality because we achieve instant finality through our protocol design, by circumventing the need to wait for a proof when on the rollup (proposed blocks have the same finality as the enclosing Ethereum L1 block, see: Layer 2 Finality). In the case where a proof is needed, such as moving assets to another layer, we are optimistic about new methods for bridging that don’t require a full proof.
The ratio between gas cost and proof generation cost matters because a malicious actor could submit blocks that are cheap in gas but expensive to generate a proof for (DOS attack). Mitigating this attack vector is a more extended topic, so we’ll go deeper into our proposed solution in a subsequent post.
In general, we are looking forward to future improvements in proof generation costs, which will decrease the cost of transactions:
Prover-level optimizations like Hyperplonk and Caulk
ZKP-specific hardware
The main advantage of using a Type 1 ZK-EVM is that you can give it a try without any upfront costs — you don’t need to make any changes to your code or development environment. You can prototype, develop, test, audit, and deploy on Ethereum L1 first and migrate to Taiko later. Alternatively, you can develop on Taiko and then migrate to L1 or another EVM-equivalent chain at any time.
A Type 1 ZK-EVM is a continual development process. It means not only being Ethereum-equivalent now but continuing to inherit future Ethereum upgrades. Staying Type 1 restrains us from adding features that would break our Ethereum-equivalence. It also encourages us to contribute upstream improvements to Ethereum L1.
Thank you for reading! 🥁
Website (with whitepaper): https://taiko.xyz
GitHub: https://github.com/taikoxyz
Twitter: https://twitter.com/taikoxyz
22.3K
No comments yet