Vitalik: How will Ethereum's multi-client philosophy interact with ZK-EVM?

How will Ethereum's multi-client philosophy interact with ZK-EVMs?

Original article by Vitalik

Marsbit

One under-discussed but very important way Ethereum maintains its security and decentralization is its multi-client concept. Ethereum intentionally does not have a "reference client" that everyone runs by default: instead, there is a collaboratively managed specification (now written in highly readable but very slow Python), and multiple teams are implementing the specification (also known as the "client"), which is what users actually run.

Each Ethereum node runs a consensus client and an execution client. As of now, no consensus or execution client accounts for more than 2/3 of the network. If a client's share in its category is less than 1/3, the network continues to function normally. If a client with a 1/3 to 2/3 share in its category (Prysm, Lighthouse, or Geth, for example) has a bug, the chain continues to add blocks but stops completing them, giving the developer time to intervene.

One under-discussed, but still very important, coming major shift in the way the Ethereum chain is verified is the rise of ZK-EVM. SNARKs that demonstrate EVM execution have been in development for many years and the technology is being actively used under the L2 protocol known as ZK rollup. Some of these ZK rollups are currently active on the main net, with more coming soon. But in the long run, Zk-EVMs won't just be used for rollup, we also want to use them to verify L1 execution (see: the Verge).

Once this happens, ZK-EVM will effectively become a third type of Ethereum client, as important to network security as execution clients and consensus clients are today. This naturally raises the question: How will ZK-EVM interact with multiple clients?

One of the hard parts is done: we already have multiple ZK-EVM implementations under active development. But other difficulties remain: how do we create a "multi-client" ecosystem for ZK to prove the correctness of Ethereum blocks? The issue presents some interesting technical challenges -- and, of course, the immediate question of whether such trade-offs are worth it.

What was the original motivation behind the Ethereum multi-client concept?

Ethereum's multi-client philosophy is one of decentralization, and like decentralization in general, one can focus on the technical benefits of architectural decentralization as well as the social benefits of political decentralization. Ultimately, the multi-client concept is driven by and for both.

The case for decentralization of technology

The main benefit of technology decentralization is simple: it reduces the risk of a single error in one piece of software causing a catastrophic collapse of the entire network. The Bitcoin spill bug of 2010 is a prime example of this risk. At the time, the Bitcoin client code didn't check that the sum of the transaction output was overflowing (returning it to zero by summing over the maximum integer 264-1), so someone made a transaction that gave themselves billions of bitcoins.

The bug was discovered within hours, the fix was quickly completed and quickly deployed across the network, but if there had been a mature ecosystem, the coins would have been accepted by exchanges, Bridges and other structures, and the attackers would have walked away with a lot of money. If there are five different Bitcoin clients, they are unlikely to all have the same error and will therefore fork immediately, and the party with the error in the fork may lose.

Using a multi-client approach to minimize the risk of catastrophic errors comes at a cost: instead, you get consensus failure errors. That is, if you have two clients, there is a risk that the client will have slightly different interpretations of some protocol rules, and while both interpretations are reasonable and do not allow money to be stolen, the disagreement will cause the chain to split in half. A severe fork of this type has occurred once before in Ethereum's history (there have been other, smaller splits in which very small portions of the network running older versions of the code have been forked).

Defenders of the single-client approach argue that consensus failure is the reason not to adopt multiple client implementations: if there is only one client, then that client will not disagree. Their model for how customer volume translates into risk might look something like this:

Of course, I disagree with this analysis. The key thing i disagree with is that (I) the catastrophic error of 2010 is also important, and (ii) you never actually have only one client. This latter point was most evident in the 2013 Bitcoin fork, when a disagreement between two versions of the Bitcoin client led to a fork in the chain, with one version accidentally limiting the number of objects that could be modified in a single block.

As a result, one client in theory is often actually two clients, and five clients in theory can actually be six or seven clients - so we should take a risk and be on the right side of the risk curve with at least a few different clients.

The case for political decentralization

Monopoly client developers are in a position of great political power. If the client developer proposes a change and the user disagrees, in theory they can refuse to download the updated version or create a branch without it, but in practice this is often difficult for the user to do. What if an unsatisfactory protocol change is bundled with necessary security updates? What if the main team threatens to quit if they don't get their way?

Or, more simply, if the monopoly client team ends up being the single team with the greatest protocol expertise, leaving the rest of the ecosystem at a disadvantage in judging the technical arguments made by the client team and leaving the client team with a lot of room to push their own specific goals and values, And what about goals and values that may not match the broader community?

Concerns about protocol politics, particularly in the context of the 2013-14 Bitcoin OP_RETURN wars, in which some participants spoke out against specific uses of the blockchain, were an important factor in Ethereum's early adoption of the multi-client idea, with the aim of making such decisions harder for a small group of people. Concerns specific to the Ethereum ecosystem -- to avoid the concentration of power in the Ethereum Foundation itself -- provide further support in this direction. In 2018, the foundation made a decision to deliberately not implement the Ethereum PoS protocol (now known as a "consensus client"), leaving the task entirely to an outside team.

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

Today, ZK-EVM is used for Rollup. This increases scalability by allowing expensive EVM execution to occur only a few times down the chain, while others only have to verify the SNARKs published on the chain to prove that the EVM performed the calculations correctly. It also allows some data (especially signatures) not to be included on the chain, thus saving gas costs. This gives us a lot of scalability benefits, and combining scalable computing with ZK-EVM and scalable data with data availability sampling allows us to scale even further.

However, today's Ethereum network also has a different problem, one that no amount of Layer2 expansion can solve on its own: Layer1 is so hard to verify that not many users are running their own nodes. Instead, most users simply trust third-party providers. Light clients like Helios and Succinct were taking steps to address the issue, but the light client was far from being a full verification node: The light client only verified the signature of a random subset of validators called the synchronization committee and did not verify that the chain actually followed protocol rules. In order for the user to actually verify that the chain is following the rules, we have to do something different.

Option 1: Compress Layer 1 and force almost all activities to move to Layer 2

Over time, we can reduce the gas target per Layer 1 block from 15 million to 1 million, enough for a block to contain a single SNARK and some deposit and withdrawal operations, but not much else, thus forcing almost all user activity to shift to the Layer 2 protocol. Such a design could still support many rollups per block: we could use an off-chain aggregation protocol run by a custom builder to collect Snarks from multiple Layer 2 protocols and combine them into a single SNARK. In such a world, the only function of Layer 1 is to be a clearing house for Layer 2 protocols, validating their proofs and occasionally facilitating large-scale money transfers between them.

This approach works, but it has several important weaknesses:

• It is actually backward incompatible because many existing L1-based applications become economically unviable. Hundreds or thousands of dollars in user funds can be stranded as fees become exorbitant, exceeding the cost of emptying these accounts. This problem can be solved by having users sign messages to opt in to a mass migration to L2 of their choice within the protocol (see here for some early implementation ideas), but this adds to the complexity of the transition, and to make it really cheap enough, you need some sort of SNARK at Layer 1 anyway. I usually like to break backward compatibility when it comes to things like SELFDESTRUCT opcodes, but in this case, the trade-off seems less favorable.

• It may still not make verification cheap enough. Ideally, the Ethereum protocol should be easy to verify, not only on laptops, but also on mobile phones, browser extensions, and even in other chains. It should also be easy to sync a chain for the first time, or after being offline for a long time. A laptop node can validate a million gas in about 20 milliseconds, but even that means it takes 54 seconds to sync after a day offline (assuming the end result of a single slot increases slot time to 32 seconds), whereas for a phone or browser extension it takes a few hundred milliseconds per block, And may still be a non-negligible battery drain. These numbers are manageable, but not ideal.

• Even in L2-first ecosystems, L1 is at least partly affordable. If users can withdraw their funds when they notice that new state data is no longer available, then Validiums could benefit from a stronger security model. If the minimum size of an economically viable direct transfer across L2 is smaller, arbitrage becomes more efficient, especially for smaller tokens.

Therefore, it seems more reasonable to try to find a way to verify Layer 1 itself using ZK-SNARKs.

Option 2: SNARK - Verify Layer 1

Type 1(exactly equivalent to Ethereum)ZK-EVM can be used to verify (Layer 1) EVM execution of an Ethereum block. We can write more SNARK code to verify the consensus side of the block. This will be a challenging engineering problem: Today, ZK-EVMs take a few minutes to a few hours to validate Ethereum blocks, and real-time generation proofs will require one or more (i) improvements to Ethereum itself to remove Snark-unfriendly components, (ii) significant efficiencies through dedicated hardware, and (iii) architectural improvements with more parallelization. However, there is no fundamental technical reason why this cannot be done - so I expect it will be done, if it takes many years.

Here we see an intersection with the multi-client paradigm: If we use ZK-EVM to validate Layer 1, which ZK-EVM do we use?

I have three options:

1. Single ZK-EVM: Abandon the multi-client paradigm and select a single ZK-EVM to authenticate the block.

2. Closed multiple Zk-EVMs: A consensus is reached on a specific set of multiple ZK-EVMs and sealed in the consensus layer protocol rules, that is, a block requires proof of more than half of the ZK-EVMs in the set in order to be considered valid.

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

To me, (3) seems ideal, at least until our technology advances to the point where it can be formally proven that all ZK-EVMs implement equivalent to each other, we can choose the most efficient one. (1) It will sacrifice the benefits of the multi-client model and (2) it will close off the possibility of developing new clients and lead to a more centralized ecosystem. (3) There are challenges, but they appear to be smaller than those of the other two options, at least for now.

Implementing (3) shouldn't be too difficult: each type of proof has a p2p subnetwork, and clients using one type of proof listen on the corresponding subnetwork and wait until they receive a proof that the verifier deems valid.

(3) The two main challenges are likely to be as follows:

• Delay challengeA malicious attacker may delay publishing blocks, as well as proof of validity to a client. It actually takes a long time (even if, say, 15 seconds) to generate proofs that are valid for other clients. This is long enough to create a temporary fork and break the chain of several slots.

• Low data efficiency: A benefit of ZK-SNARKs is that data that is only relevant to validation (sometimes called "witness data") can be removed from the block. For example, once a signature has been validated, instead of saving the signature in a block, you can store a bit that indicates that the signature is valid, and store a proof in the block to confirm that all valid signatures exist. However, if we want to be able to generate multiple types of proofs for a block, the original signature needs to be actually published.

The latency problem can be solved by careful handling when designing the single-slot terminal protocol. Single-slot final agreements may require more than two rounds of consensus per slot, so you can require that the first round include blocks and only require nodes to verify proof before the third (or final) round is signed. This ensures that there is always a significant window of time between the release block's deadline and the expected time of proof of availability.

The data efficiency problem must be solved by using a separate protocol to aggregate validating related data. For signatures, we can use the BLS aggregation already supported by ERC-4337. Another major category of data related to validation is ZK-SNARKs for privacy. Fortunately, these protocols usually have their own aggregation protocol.

It is worth mentioning that SNARK Validation Layer 1 has another important benefit: EVM execution on the chain no longer requires validation at every node, which allows the number of EVM executions to be greatly increased. This can be done by substantially raising the Layer 1 gas cap, introducing enshrined rollups, or both.

conclusion

It takes a lot of work to make an open multi-client ZK-EVM ecosystem work well. But the really good news is that much of the work is underway or about to be:

• We already have several powerful implementations of ZK-EVM. These implementations are not yet Type 1(the exact equivalent of Ethereum), but many of them are actively moving in that direction.

• Work on light clients such as Helios and Succinct could eventually turn into fuller SNARK verification on the PoS consensus side of the Ethereum chain.

• Clients may start trying ZK-EVM to prove execution of Ethereum blocks, especially when we have stateless clients where it is technically not necessary to re-execute each block directly to maintain state. It will likely be a slow and gradual transition from clients verifying Ethereum blocks by re-executing to most clients verifying Ethereum blocks by checking SNARK proofs.

•ERC-4337 and PBS ecosystems may soon start using aggregation technologies such as BLS and Proof polymerization to save on gas costs. On BLS aggregation, work has already begun.

With these technologies, the future looks very good. Ethereum blocks will be smaller than they are today, and anyone will be able to run a fully verified node on their laptop, or even their phone or in a browser extension, all while preserving Ethereum's multi-client concept.

In the long run, of course, anything can happen. Perhaps artificial intelligence will enhance formal validation so that it can easily prove that ZK-EVM implementations are equivalent and identify all the errors that cause them to differ. Such a project might even be something to start working on now. If this verification based formal approach is successful, different mechanisms will need to be put in place to ensure the continued decentralized implementation of the protocol politically. Perhaps by then the agreement will be considered "complete" and the immutability specification will be stronger. But even if that's the longer term future, the open multi-client ZK-EVM world seems like a natural stepping stone that could happen anyway.

In the near term, it is still a long way off. Zk-evms are already here, but for zk-evMs to be truly viable at Layer 1, they need to be type 1 and prove fast enough that it can happen in real time. With enough parallelization, this is doable, but it still takes a lot of work to get there. Consensus changes like raising the cost of gas precompiled for KECCAK, SHA256, and other hash functions will also be an important part of the picture.

That said, the first step in the transition may happen sooner than we expect: once we switch to Verkle trees and stateless clients, clients can start gradually using ZK-EVM, and the transition to an "open multi-Zk-evm" world may begin on its own.

Original link

Welcome to join the official BlockBeats community:

Telegram Subscription Group: https://t.me/theblockbeats

Telegram Discussion Group: https://t.me/BlockBeats_App

Official Twitter Account: https://twitter.com/BlockBeatsAsia