The "zkEVM multi-client problem" that V God is most worried about finally has a solution

This article comes fromcryptoslate, by Liam 'Akiba' Wright

Odaily Translator |

Odaily Translator |

Next, let's unpack the key takeaways from this article.

secondary title

The multi-client problem of Zk-EVM

Vitalik Buterin believes that ZK-EVM will develop into an important part of the Ethereum Layer 1 security and verification process in the future, and zero-knowledge (ZK) technology will also allow developers to prove the authenticity of transactions or messages without revealing any additional information sex.

This means that one party to a transaction can convince the other party that the message it sends is genuine and valid without revealing any knowledge other than the validity of the message. However, according to Vitalik Buterin's analysis, the privacy-preserving nature of zero-knowledge proof technology could disrupt the broader EVM landscape due to nuances in how Ethereum clients implement the protocol's rules.

At this stage, the second-layer protocol in ZK Rollups has successfully used zero-knowledge proof technology and helped expand the Ethereum blockchain by bundling multiple transactions into one proof. However, with the development of ZK-EVM to verify the execution of transactions on the main network, Vitalik Buterin believes that "ZK-EVM actually becomes the third kind of Ethereum client. The security of the network is paramount."

However, once ZK-EVM is considered as a third type of Ethereum client, Vitalik Buterin raises the following question:

"In practice, how do we create a "multi-client" ecosystem for zero-knowledge proofs of the correctness of Ethereum blocks?"

As the Ethereum ecosystem continues to expand, Vitalik Buterin hopes to maintain the advantages of the "multi-client philosophy" while leveraging the capabilities of ZK-EVM to improve the scalability, security, and decentralization of the Ethereum network.

So, how to solve these problems? Vitalik Buterin gave a solution -

secondary title

Despite the above-mentioned challenges in the Ethereum ecosystem, Vitalik Buterin believes that creating an open multi-client ZK-EVM ecosystem is completely feasible and conducive to the security and decentralization of Ethereum. The following figure is the Ethereum ecosystem Visual representations of various clients used in the consensus and execution layers of .

image description

Source: vitalik.eth.limo

Vitalik Buterin believes that having multiple clients increases the security and decentralization of the network by reducing the risk of a single catastrophic error in one implementation that could bring down the entire Ethereum network. In addition, the multi-client concept also helps prevent the concentration of power within one development team or organization, which in turn better decentralizes the network.

For the ZK-EVm multi-client problem mentioned above, Vitalik Buterin proposed three possible solutions:

1. Single ZK-EVM: Abandon the multi-client paradigm and choose a single ZK-EVM for validating blocks.

2. Closed multiple ZK-EVMs: agree and reach a consensus on a specific set of multiple ZK-EVMs, and have a consensus layer protocol rule that a block needs to come from more than half of the ZK-EVMs in the set proof to be considered valid.

3. Open multiple ZK-EVM: Different clients have different ZK-EVM implementations, and each client waits for a proof of compatibility with its own implementation before accepting a block as valid. "

In the context of ZK-EVM, Vitalik Buterin supports the third solution, which is an open multi-client ZK-EVM ecosystem solution. He believes that different clients have different ZK-EVM implementations, and each client Wait for proof of compatibility with itself before accepting a block as valid.

"To me, the third solution seems ideal, at least until and unless our technology improves to the point where it can be formally proven that all ZK-EVM implementations are equivalent to each other..."

• Not only that, but once the technology improves to the point where ZK-EVM achieves some standardization, Vitalik Buterin believes that the solution will be to choose the most efficient option, while he also feels that "the challenge of the third solution seems to be smaller than that of the other two options. At least for now.” However, Vitalik Buterin suggested that open multiple ZK-EVMs may face two major challenges:

• Data inefficiency: One benefit of ZK-SNARKs is that data relevant only to validation (sometimes called "witness data") can be removed from blocks. For example, once you verify a signature, instead of storing the signature in a block, you can just store a bit that indicates the signature is valid, and a single proof in the block that confirms all the signatures. However, if you want to be able to generate multiple types of proofs for a block, you need to actually publish the original signature.

secondary title

How will ZK-EVM enter Layer 1 in the future?

Option 1: Restrict Layer 1, forcing almost all activity to move to Layer 2

Over time, Vitalik Buterin suggested that the layer 1 gas target per block could be reduced from 15 million to 1 million, enough for a block to contain a SNARK and some deposits and withdrawals, but not much else, This forces almost all user activity to move to the Layer 2 protocol.

secondary title

Summarize

Summarize

Vitalik Buterin concluded that promoting an open multi-client ZK-EVM ecosystem to work well requires a lot of work. But the good news is that most of the work to achieve this goal is happening, or will happen anyway, because:

1. Ethereum already has multiple powerful ZK-EVM implementations.

2. Work on light clients such as Helios and Succinct may eventually turn into a more comprehensive SNARK verification of the PoS consensus side of the Ethereum chain.

3. The client may start to try to use ZK-EVM to prove its own Ethereum block execution, especially when there is no state client and there is no technical need to directly re-execute each block to maintain the state, it may be possible from the client Ends verify Ethereum blocks by re-executing them, and transition to most clients verifying Ethereum blocks by checking SNARK proofs.

4. ERC-4337 and PBS ecosystems may soon start using technologies such as BLS and proof aggregation, which can save a lot of gas costs.