Ad
Ethereum Co-Founder Vitalik Buterin shared his musing on an “underdiscussed, but nevertheless very important” aspect of the Ethereum ecosystem in a recent blog post this weekend.
The post entitled “How will Ethereum’s multi-client philosophy interact with ZK-EVMs?” focused on the technical challenges, trade-offs, and potential solutions for creating a multi-client ecosystem for ZK-EVMs.
The multi-client problem with Zk-EVMs
Vitalik believes 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 disclosing any knowledge beyond the message’s validity.
However, the privacy-enforcing nature of ZK technology could disrupt the broader EVM landscape as Ethereum clients differ subtly in implementing protocol rules, according to the Ethereum Co-Founder.
Layer 2 protocols in ZK rollups have successfully used ZK proofs and helped scale Ethereum by bundling multiple transactions into a single proof. However, as ZK-EVMs evolve to verify execution on Mainnet, “ZK-EVMs de-facto become a third type of Ethereum client, just as important to the network’s security as execution clients and consensus clients are today.”
Viewing ZK-EVMs as a third type of Ethereum client raises the following question from Vitalik,
“How would we actually make a “multi-client” ecosystem for ZK-proving correctness of Ethereum blocks?”
As the ecosystem scales, Vitalik wants to maintain the benefits of the “multi-client philosophy” while also leveraging the capabilities of ZK-EVMs 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. In addition, individual Ethereum clients handle zero-knowledge proofs differently due to specific interpretations of 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 Ethereum’s security and decentralization.
Below is a visual representation of the various clients used across the consensus and execution layers of the Ethereum ecosystem.
Source: vitalik.eth.limo
Vitalik argued that having multiple clients increases the security and decentralization of the network by reducing the risk of a single catastrophic bug in one implementation, which could lead to a breakdown of the entire network. Additionally, a multi-client philosophy helps to prevent the concentration of power within one development team or organization, promoting political decentralization.
Vitalik presented three potential solutions to the issue, as shown below.
“Single ZK-EVM: abandon the multi-client paradigm, and choose a single ZK-EVM that we use to verify blocks.Closed multi ZK-EVM: agree on and enshrine in consensus a specific set of multiple ZK-EVMs, and have a consensus-layer protocol rule that a block needs proofs from more than half of the ZK-EVMs in that set to be considered valid.Open multi ZK-EVM: different clients have different ZK-EVM implementations, 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-EVMs, Vitalik supports the idea of an open multi-client ZK-EVM ecosystem. Different clients have different ZK-EVM implementations, and each client waits for proof compatible with its own before accepting a block as valid.
“To me, (3) seems ideal, at least until and unless our technology improves to the point where we can formally prove that all of the 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 the “challenges [for option 3] seem smaller than the challenges of the other two options, at least for now.”
Vitalik also nodded to the recent rapid advancement in AI, stating that progress in AI could “super-charge” the development of proving ZK-EVM implementations.
“In the longer-term future, of course anything could happen. Perhaps AI will super-charge formal verification to the point where it can easily prove ZK-EVM implementations equivalent and identify all the bugs that cause differences between them.”
