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

Disclaimer: This article aims to convey more market information and does not constitute any investment advice. The article only represents the author's viewpoint and does not represent the official stance of MarsBit

Disclaimer: This article aims to convey more market information and does not constitute any investment advice. The article only represents the author's viewpoint and does not represent the official stance of MarsBit.

Editor: Remember to follow me

Source: MarsBit

Special thanks to JustinDrake for feedback and review

One way for Ethereum to maintain its security and decentralization, which has not been fully discussed but is very important, is through itsMulti client concept Ethereum intentionally does not have a "reference client" that everyone runs by default: instead, there is a collaborative management specification (now written in highly readable but very slow Python), and multiple teams are implementing this specification (also known as the "client"), which is actually run by users.

Each Ethereum node runs a consensus client and an execution client. As of now, there is no consensus or execution client accounts for more than two-thirds of the network. If a client's share in its category is less than 1/3, the network will continue to operate normally. If there is a bug in a client (such as Prysm, Lighthouse, or Geth) that has a 1/3 to 2/3 share in its category, the chain will continue to add blocks but stop completing them, providing developers with time to intervene.

A major shift in the upcoming Ethereum chain validation approach, which has not been fully discussed but is still very important, is the rise of ZK-EVM. The SNARKs implemented by EVM have been developed for many years, and this technology is actively being used in the L2 protocol known as ZKroll up. Some of these ZKrollups are currently active on the main network and will soon have more releases. But in the long run, ZK-EVM will not only be used for roll ups, we also want to use them to verify the execution of L1 (reference: the Verge).

Once this happens, ZK-EVM will actually become the third type of Ethereum client, as important for network security as today's execution and consensus clients. This naturally raises a question: How will ZK-EVM interact with multiple clients? One of the difficult parts has been completed: we already have multiple ZK-EVM implementations under active development. But other challenges still exist: How can we create a "multi client" ecosystem for ZK to prove the correctness of Ethereum blocks? This issue brings some interesting technical challenges - and of course, there is an urgent question of whether such trade-offs are worth it.

Multi client concept

Multi client concept

Reasons for technological decentralization

The main benefit of technological decentralization is simple: it reduces the risk of a catastrophic network crash caused by an error in a particular software. The 2010 Bitcoin overflow vulnerability is a typical example of this risk. At that time, the Bitcoin client code did not check whether the sum of the transaction output overflowed (by summing up to exceed the maximum integer of 264-1 to zero), so someone made a transaction and gave themselves billions of Bitcoins. This vulnerability was discovered within a few hours, and the repair work was quickly completed and quickly deployed throughout the entire network. However, if there were a mature ecosystem at that time, these coins would have been accepted by exchanges, bridges, and other structures, and the attacker might have taken away a lot of money. If there are five different Bitcoin clients, they are unlikely to all have the same error, so they will immediately fork, and the one with the error in the fork may fail.

Using a multi client approach to minimize the risk of catastrophic errors comes at a cost: on the contrary, you will encounter consensus failure errors. That is to say, if you have two clients, there is a risk that the client may have slightly different interpretations of certain protocol rules, although both interpretations are reasonable and do not allow for theft, the divergence will result in the chain splitting into two halves. In the history of Ethereum, this type of severe bifurcation has occurred once (and there are other smaller divisions where a small portion of the network running older versions of code has been forked). Defenders of the single client approach believe that consensus failure is the reason for not implementing multiple clients: if there is only one client, then that client will not have different opinions. Their model on how the number of customers is converted into risk may be as follows:

Of course, I disagree with this analysis. The key point that I disagree with is that (i) the catastrophic mistakes of 2010 are also important, and (ii)You will never actually have only one client The latter point was most evident in the 2013 Bitcoin fork: due to differences between two different versions of Bitcoin clients, the chain forked, with one version unexpectedly limiting modifications to the number of objects in a single block. Therefore, in theory, one client often has two clients, and in theory, five clients may actually have six or seven clients - so we should take a risk and walk on the right side of the risk curve, with at least a few different clients.

Reasons for political decentralization

Monopoly client developers are in a position of great political power. If client developers propose changes and users do not agree, theoretically they can refuse to download the updated version or create a branch without it, but in practice, users often find it difficult to do so. What if an unsatisfactory protocol change is bundled with necessary security updates? What if the main team threatens to withdraw if they don't follow their way? Or, more simply, what if a monopolistic client team ultimately becomes the only team with the greatest protocol expertise, putting other members of the ecosystem at a disadvantage in judging the technical arguments proposed by the client team, giving the client team ample room to push their own specific goals and values that may not match the broader community?

2013-14OP_RETURNMulti client concept2018PoS()

How will ZK-EVM enter Layer1 in the future?

Nowadays, ZK-EVM is used for Rollup. This increases scalability by allowing expensive EVM execution to occur only a few times off the chain, while others only need to verify the SNARKs published on the chain to prove the correctness of EVM execution calculations. It also allows some data (especially signatures) to be excluded from the chain, thereby saving gas costs. This provides us with many scalability benefits, combining scalable computing with ZK-EVM and scalable data and data availability sampling can allow us to scale 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 difficult to verify, so few users are running their own nodes. On the contrary, most users only trust third-party providers. Light clients such as Helios and Succinct are taking measures to address this issue, but the light client is far from being a fully verified node: the light client only verifies the signature of a random subset of validators called the synchronization committee, without verifying whether the chain actually follows protocol rules. In order for users to truly verify whether the chain follows the rules, we must do some different things.

Option 1: Compress Layer1 and force almost all activities to move to Layer2

Over time, we can reduce the gas target for each block in Layer1 from 15 million to 1 million, which is enough to include a single SNARK and some access operations in a block, but not too many other operations, forcing almost all user activity to be transferred to the Layer2 protocol. This design can still support submitting many rolls in each block: we can use an off chain aggregation protocol run by a custom builder to collect SNARKs from multiple Layer2 protocols and combine them into a single SNARK. In such a world, the only function of Layer1 is to become a clearing house for Layer2 protocols, verify their proofs, and occasionally facilitate large-scale fund transfers between them.

This method is feasible, but it has several important weaknesses:

It is actually backwards incompatibleBecause many existing L1 based applications have become economically infeasible. As fees become too high, exceeding the cost of clearing these accounts, user funds of hundreds or thousands of dollars may be in trouble. This issue can be solved by having users sign messages to choose to migrate on a large scale to their chosen L2 within the protocol (see some early implementation ideas here), but this increases the complexity of the transition, and to make it truly cheap enough, some form of SNARK needs to be done in Layer1 anyway. When it comes to things like SELFDESTRUCT opcodes, I usually like to break backward compatibility, but in this case, this trade-off seems less advantageous.

It may still not make validation 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 synchronize the chain for the first time, or after being offline for a long time. Laptop nodes can verify 1 million gas in approximately 20 milliseconds, but even so, it means that synchronization takes 54 seconds after a day offline (assuming the final result of a single slot increases the slot time to 32 seconds), while for mobile phones or browser extensions, each block takes several hundred milliseconds and may still be a significant battery consumption. These numbers are controllable, but not ideal.

Even in L2 priority ecosystems, L1 is at least to some extent affordable.If users can extract their funds when they notice that new status data is no longer available, then Validiums can benefit from a stronger security model. If the minimum scale of economically feasible cross L2 direct transfer is smaller, arbitrage will become more effective, especially for smaller tokens.

Therefore, it seems more reasonable to try to find a method to validate Layer1 itself using ZK-SNARKs.

Option 2: SNARK - Verify Layer1

Type 1 (completely equivalent to Ethereum) ZK-EVM can be used to validate the EVM execution of (Layer1) Ethereum blocks. We can write more SNARK code to verify the consensus side of the block. This will be a challenging engineering issue: Today, ZK-EVMs require several minutes to several hours to validate Ethereum blocks, and real-time generation of proofs will require one or more (i) improvements to the Ethereum itself to remove SNARK unfriendly components, (ii) significant efficiency improvements through dedicated hardware, and (iii) architecture improvements with more parallelism. However, this cannot be achieved without fundamental technical reasons - therefore, I anticipate that even if it takes many years, it will still be achieved.

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

I have three choices:

1. Single ZK-EVM: Discard the multi client example and choose a single ZK-EVM to validate the block.

2. Closed Multiple ZK-EVM: Reaching consensus on a specific set of multiple ZK-EVM and encapsulating it in the consensus layer protocol rules, that is, a block requires proof from more than half of the ZK-EVM in the set to be considered valid.

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

For me, (3) seems ideal, at least until our technology advances to the point where we can formally prove that all ZK-EVM implementations are equivalent to each other, we can choose the most effective one. (1) The benefits of the multi client model will be sacrificed, and (2) the possibility of developing new clients will be closed, leading to a more centralized ecosystem. (3) There are challenges, but these challenges seem smaller than the other two options, at least for now.

Implementation (3) is not too difficult: each type of proof has a P2P subnet, and clients using a type of proof will listen and wait on the corresponding subnet until they receive a proof that the verifier deems valid.

(3) The two main challenges may be as follows:

Delay ChallengeMalicious attackers may delay the release of blocks and provide valid proof to a client. Generating valid proofs for other clients actually takes a long time (even if for example, 15 seconds). This time is long enough to create a temporary fork and interrupt the chain of several slots.

Low data efficiencyOne advantage of ZK-SNARKs is that only validation related data (sometimes referred to as "witness data") can be removed from the block. For example, once the signature is verified, there is no need to save the signature in a block. Instead, a bit representing the validity of the signature needs to be stored, and a proof is stored in the block to confirm the existence of all valid signatures. However, if we want to generate multiple types of proofs for a block, the original signature needs to be actually published.

The delay issue can be addressed with caution when designing a single slot terminal protocol. The final agreement for a single slot may require more than two rounds of consensus for each slot, so the first round can include blocks and only require nodes to verify proof before signing in the third (or final) round. This ensures that there is always an important time window between the deadline for publishing blocks and the expected time when proof of availability is expected.

The issue of data efficiency must be addressed by using separate protocols to aggregate and validate relevant data. For signatures, we can use the BLS aggregation already supported by ERC-4337. Another main category of validation related data is ZK-SNARKs for privacy purposes. Fortunately, these protocols typically have their own aggregation protocols.

It is worth mentioning that SNARK validation of Layer1 also has an important benefit: EVM execution on the chain no longer requires verification from each node, which greatly increases the number of EVM executions. This can be achieved by significantly increasing the Layer1Gas upper limit, introducing enshrinedrolls, or both.

conclusion

To make an open multi client ZK-EVM ecosystem run well, a lot of work needs to be done. But the real good news is that most of the work is ongoing or about to take place:

We already have multiple powerful ZK-EVM implementations. These implementations are not yet Type 1 (completely equivalent to Ethereum), but many of them are actively moving in this direction.

The work on lightweight clients such as Helios and Succinct may eventually become a more complete SNARK verification on the PoS consensus side of the Ethereum chain.

The client may start trying ZK-EVM to prove the execution of Ethereum blocks, especially when we have stateless clients, which technically do not require directly re executing each block to maintain state. We may transition from verifying Ethereum blocks through re execution on the client side to verifying Ethereum blocks through checking SNARK proofs on most clients, which will be a slow and gradual transition.

ERC-4337 and PBS ecosystems may soon begin using aggregation technologies such as BLS and proof of aggregation to save gas costs. Work has started on BLS aggregation.

Multi client concept

In the long run, of course, anything can happen. Perhaps AI will strengthen formal verification so that it can easily prove that the ZK-EVM implementation is equivalent and identify all errors that lead to differences between them. Such a project may even be something that starts working now. If this verification based formal approach is successful, different mechanisms need to be established to ensure the continued decentralized implementation of the protocol politically. Perhaps by then, the protocol will be considered 'complete' and the immutability specification will be stronger. But even if this is the longer term future, the open multi client ZK-EVM world seems like a natural stepping stone that could happen anyway.

In the near future, this is still a long journey. ZK-EVM is already here, but in order for ZK-EVM to be truly feasible in Layer1, they need to become Type 1 and prove quickly enough that it can occur in real time. With sufficient parallelism, this is feasible, but much work still needs to be done to achieve this goal. Consensus changes such as increasing the cost of gas precompiled by KECCAK, SHA256 and other hash function will also be an important part of the picture. That is to say, the first step of the transition may occur faster than we expected: once we switch to the Verkle tree and the stateless client, the client can gradually start using ZK-EVM, and the transition to the "open multi ZK-EVM" world may begin on its own.