Learn about Ethereum’s security and decentralization through its multi-client philosophy and the upcoming transition to ZK-EVMs. Find out more in this informative article.

Introduction

Overview of Ethereum as a blockchain network

Ethereum is one of the most popular blockchain networks in the world, known for its smart contract functionality and decentralized applications (dApps). One of the ways Ethereum maintains its security and decentralization is through its multi-client philosophy.

Unlike other blockchain networks, Ethereum does not have a default “reference client” that everyone runs by default. Instead, there is a collaboratively-managed specification, written in the very human-readable but very slow Python language, and multiple teams making implementations of the specification, called “clients,” which is what users actually run.

Explanation of Ethereum’s multi-client philosophy

Each Ethereum node runs a consensus client and an execution client. Currently, no consensus or execution client makes up more than 2/3 of the network. This means that if a client with less than 1/3 share in its category has a bug, the network will continue as normal. If a client with between 1/3 and 2/3 share in its category has a bug, the chain would continue adding blocks, but it would stop finalizing blocks, giving time for developers to intervene.

Overview of ZK-EVMs

A major upcoming transition in how the Ethereum chain gets validated is the rise of ZK-EVMs. SNARKs proving EVM (Ethereum Virtual Machine) execution have been under development for years already, and the technology is actively being used by layer 2 protocols called ZK rollups. These ZK rollups are active on the mainnet today, with more coming soon. In the longer term, ZK-EVMs are not just going to be for rollups; they will also be used to verify execution on layer 1 as well. Once that happens, 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.

However, this transition raises some interesting questions about how ZK-EVMs will interact with the multi-client philosophy. One of the hard parts is already done: multiple ZK-EVM implementations are being actively developed. But other hard parts remain: how would we actually make a “multi-client” ecosystem for ZK-proving correctness of Ethereum blocks? This question opens up some interesting technical challenges – and, of course, the looming question of whether or not the tradeoffs are worth it.

How will ZK-EVMs come in on layer 1 in the future?

Explanation of ZK-EVMs

ZK-EVMs, or Zero-Knowledge Ethereum Virtual Machines, are used in rollups to increase scaling by enabling expensive EVM execution to happen only a few times off-chain. Everyone else simply verifies SNARKs posted on-chain that prove the EVM execution was computed correctly.

This also allows some data, particularly signatures, not to be included on-chain, saving on gas costs. The combination of scalable computation with ZK-EVMs and scalable data with data availability sampling could potentially allow for significant scaling benefits. However, the Ethereum network faces difficulty verifying layer 1, where not many users run their own nodes. Instead, most users trust third-party providers. Light clients such as Helios and Succinct are taking steps toward solving this problem. However, a light client is far from a fully verifying node and does not verify that the chain follows the protocol rules. A different solution would be needed to bring us to a world where users can verify that the chain follows the rules.

Option 1: Constrict layer 1

The Ethereum network’s multi-client philosophy is critical to its security and decentralization. The rise of ZK-EVMs is a major upcoming transition for the network. Ethereum’s approach to scaling could be reducing the layer 1 gas-per-block target to 1 million, which could force almost all user activity to move to layer 2 protocols. In this scenario, the only function of layer 1 would be to be a clearinghouse for layer 2 protocols, verifying their proofs and occasionally facilitating large funds transfers between them.

This design could still support many rollups committed in each block. We could use off-chain aggregation protocols run by customized builders to gather together SNARKs from multiple layer 2 protocols and combine them into a single SNARK. SNARK-verifying layer 1 has an important benefit: it could greatly increase the amount of EVM execution taking place. This could happen by greatly increasing the layer 1 gas limit, introducing enshrined rollups, or both.

Challenges

As Ethereum continues to grow and evolve, there are several challenges to consider when it comes to verifying layer 1 of the network using ZK-SNARKs. While this approach could potentially offer many benefits, there are also significant hurdles to overcome.

One of the main challenges of ZK-SNARK verification is the potential for backward incompatibility. Many existing L1-based applications could become economically nonviable if this approach is implemented. User funds could get stuck as fees become so high that they exceed the cost of emptying those accounts. While users could potentially sign messages to opt-in to an in-protocol mass migration to an L2 of their choice, this would add complexity to the transition. Making it cheap enough would require some SNARK at layer 1, which could prove difficult.

Another challenge is the question of whether verification can be made cheap enough for different devices. Ideally, the Ethereum protocol should be easy to verify not just on laptops but also inside phones, browser extensions, and even inside other chains. Syncing the chain for the first time, or after a long time offline, should also be easy. While a laptop node could verify 1 million gas in ~20 ms, syncing after one day offline could take up to 54 seconds (assuming single slot finality increases slot times to 32s). Verifying a few hundred milliseconds per block for phones or browser extensions might still be a non-negligible battery drain. These numbers are manageable, but they are not ideal.

Benefits

Despite these challenges, there are benefits to having L1 be somewhat affordable, even in an L2-first ecosystem. Validiums can benefit from a stronger security model if users can withdraw their funds if they notice that new state data is no longer being made available. Arbitrage becomes more efficient, especially for smaller tokens, if the minimum size of an economically viable cross-L2 direct transfer is smaller.

Given these challenges, it may be more reasonable to find a way to use ZK-SNARKs to verify layer 1 itself. This approach could work, but there are still significant hurdles to overcome. One of the main challenges is the potential for backward incompatibility. Still, there are potential solutions such as allowing users to sign messages to opt-in to an in-protocol mass migration to an L2 of their choice. Additionally, verifying the chain quickly and efficiently on different devices can still be challenging. However, by addressing these challenges, it may be possible to unlock the many benefits that ZK-SNARK verification could offer while still maintaining the security and efficiency of the Ethereum network.

Option 2: SNARK-verify layer 1

One proposed solution is to SNARK-verify layer 1, which would involve using a type 1 (fully Ethereum-equivalent) ZK-EVM to verify the EVM execution of a (layer 1) Ethereum block. This would be a challenging engineering problem as ZK-EVMs take minutes to hours to verify Ethereum blocks, and generating proofs in real-time would require one or more of (i) improvements to Ethereum itself to remove SNARK-unfriendly components, (ii) either large efficiency gains with specialized hardware, and (iii) architectural improvements with much more parallelization. However, there is no fundamental technical reason why it cannot be done – so it is expected that it will be done even if it takes many years.

There are three options available for SNARK-verifying layer 1, each with its own set of challenges.

• The first option is to use a single ZK-EVM to verify blocks, which would abandon the multi-client paradigm.
• The second option is to agree on 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, which would close off the possibility of developing new clients and lead to a more centralized ecosystem.
• For now, the third and most viable option is to have different clients use different ZK-EVM implementations. This would maintain the benefits of the multi-client paradigm, but it has its own set of challenges.

Challenges

Implementing the third option would not be too difficult. One could have a p2p sub-network for each type of proof, and a client that uses one type of proof would listen on the corresponding sub-network and wait until they receive proof that their verifier recognizes as valid. However, the two main challenges of this option are likely the following: the latency challenge and data inefficiency.

• The latency challenge could be addressed by being careful when designing the single-slot finality protocol. Single-slot finality protocols will likely require more than two rounds of consensus per slot, so one could require the first round to include the block and only require nodes to verify proofs before signing in the third (or final) round. This ensures that a significant time window is always available between the deadline for publishing a block and when proofs are expected to be available.
• The data efficiency issue would have to be addressed by having a separate protocol for aggregating verification-related data. For signatures, we could use BLS aggregation, which ERC-4337 already supports. Another significant category of verification-related data is ZK-SNARKs used for privacy. Fortunately, these often tend to have their aggregation protocols.

Benefits

SNARK-verifying the layer 1 has an important benefit: it could greatly increase the amount of EVM execution taking place. This could happen either by greatly increasing the layer 1 gas limit, introducing enshrined rollups, or both. By making on-chain EVM execution no longer need to be verified by every node, it is possible to increase the amount of EVM execution taking place.

Despite the potential benefits of SNARK-verifying layer 1, several challenges remain to consider. While the implementation of ZK-EVMs can enable scalable computation and data sampling, backward compatibility and device verification issues still need to be addressed. The three options available for SNARK-verifying layer 1 have their own set of challenges, but the third option appears to be the most viable for now. Implementing this option would not be too difficult, but it has its own set of challenges, such as latency challenge and data inefficiency. However, by addressing these challenges, it may be possible to unlock the many benefits that SNARK-verifying layer 1 could offer while maintaining the security and efficiency of the Ethereum network.

Conclusion

Ethereum’s multi-client philosophy is critical to its security and decentralization, and the rise of ZK-EVMs will be a major upcoming transition for the network. While there are still technical challenges to overcome, the development of multiple ZK-EVM implementations is a promising sign for the future of the network. As the network continues to grow and evolve, it will be important to find ways to verify the layer 1 using ZK-SNARKs while addressing the challenges of backward compatibility and device verification. By doing so, it may be possible to unlock the many benefits that ZK-SNARK verification could offer while maintaining the security and efficiency of the Ethereum network.

DISCLAIMER: The Information on this website is provided as general market commentary and does not constitute investment advice. We encourage you to do your own research before investing.

Join us to keep track of news: https://linktr.ee/coincu

Thana

Coincu News