Advertisement
Ethereum co-founder Vitalik Buterin shared his thoughts on a “little discussed, but nonetheless very important” aspect of the Ethereum ecosystem in a recent blog post this weekend.
The post titled “How will Ethereum’s multi-client philosophy interact with ZK-EVMs?” focused on the technical challenges, tradeoffs, and possible solutions to create a multi-tenant ecosystem for ZK-EVM.
The multi-tenant problem with Zk-EVMs
Vitalik believes that ZK-EVMs will evolve to become an essential part of Ethereum’s Layer 1 security and verification process in the future. Zero Knowledge (ZK) technology allows developers to prove the authenticity of a transaction or message without revealing any additional information. Thus, it allows one party to convince another that a message is true without revealing any knowledge beyond the validity of the message.
However, the privacy-enforcement nature of ZK technology could disrupt the larger EVM landscape, as Ethereum clients differ subtly in implementing the protocol’s rules, according to the Ethereum co-founder.
Layer 2 protocols in ZK rollups have successfully used ZK tests and helped scale Ethereum by bundling multiple transactions into a single test. However, as ZK-EVMs evolve to verify execution on the Mainnet, “ZK-EVMs become a de facto third type of Ethereum client, just as important to network security as Ethereum clients are today.” Execution and Consensus Clients”.
Seeing ZK-EVM as a third type of Ethereum client raises the following question from Vitalik:
“How would we actually do a ‘multi-client’ ecosystem for ZK to test the correctness of Ethereum blocks?”
As the ecosystem scales, Vitalik wants to maintain the benefits of the “multi-tenancy philosophy” while leveraging the capabilities of ZK-EVM to improve the scalability, security, and decentralization of the Ethereum network.
The main technical challenges of using ZK technology with multiple clients relate to latency and data inefficiency, according to Vitalik. Also, individual Ethereum clients handle zero-knowledge proofs differently due to specific interpretations of the protocol rules or ZK-EVM implementations.
ZK-EVM multi-client solutions
Despite these challenges, Vitalik believes that creating an open multi-client ZK-EVM ecosystem is feasible and beneficial for the security and decentralization of Ethereum.
Below is a visual representation of the various clients used in the consensus and execution layers of the Ethereum ecosystem.
Vitalik argued that having multiple clients increases network security and decentralization by reducing the risk of a single catastrophic failure in a deployment, which could cause the entire network to fail. In addition, a multi-client philosophy helps prevent the concentration of power within a development team or organization, promoting political decentralization.
Vitalik presented three possible solutions to the problem, as shown below.
- “Single ZK-EVM – Ditch the multi-client paradigm and choose a single ZK-EVM that we use to verify blocks.
- Multiple Closed ZK-EVMs: Agree and enshrine a specific set of multiple ZK-EVMs in consensus, and have a consensus layer protocol rule that a block needs evidence from more than half of the ZK-EVMs in that set to be considered valid.
- Open multi ZK-EVM: Different clients have different implementations of ZK-EVM, and each client waits for a proof that is compatible with its own implementation before accepting a block as valid.
In the context of ZK-EVM, Vitalik supports the idea of an open, multi-client ZK-EVM ecosystem. Different clients have different implementations of ZK-EVM, and each client waits for a proof compatible with its own before accepting a block as valid.
“To me, (3) seems ideal, at least until our technology improves to the point where we can formally prove that all ZK-EVM implementations are equivalent to each other…”
However, once the technology has improved to the point where ZK-EVM implementations are somewhat standardized, Vitalik argued that the solution will be to choose the most efficient option. He believes that the “challenges (for option 3) seem less than the challenges of the other two options, at least for now.”
Vitalik also agreed with the recent rapid advancement in AI, stating that progress in AI could “overload” the development of test implementations of ZK-EVM.
“In the longer-term future, of course anything could happen. Perhaps the AI overloads the formal verification to the point where it can easily demonstrate that the ZK-EVM implementations are equivalent and identify all the errors that cause differences between them.”
