Original Title: "Possible futures of the Ethereum protocol, part 4: The Verge"

Author: Vitalik Buterin

Translation: Mensh, ChainCatcher

Special thanks to Justin Drake, Hsia-wei Wanp, Guillaume Ballet, Icinacio, Rosh Rudolf, Lev Soukhanoy, Ryan Sean Adams, and Uma Roy for their feedback and review.

One of the most powerful features of blockchain is that anyone can run a node on their own computer and verify the correctness of the blockchain. Even if 9596 nodes running chain consensus (PoW, PoS) immediately agree to change the rules and start producing blocks according to the new rules, every person running a fully validating node will refuse to accept the chain. Miners not part of this conspiracy will automatically converge onto a chain that continues to follow the old rules and will continue to build on that chain, while fully validated users will follow that chain.

This is the key difference between blockchain and centralized systems. However, for this feature to hold, running a fully validating node must be feasible for a sufficient number of people. This applies both to miners (because if miners do not validate the chain, they are not contributing to the execution of the protocol rules) and to ordinary users. Nowadays, it is possible to run a node on consumer-grade laptops (including the laptop used to write this article), but doing so is quite difficult. The Verge aims to change this situation by making the computational cost of fully validating chains inexpensive, so that every mobile wallet, browser wallet, and even smart watch will default to validating.

The Verge 2023 Roadmap

Initially, "Verge" referred to the transfer of Ethereum state storage to Verkle trees—a tree structure that allows for more compact proofs, enabling stateless verification of Ethereum blocks. Nodes can verify an Ethereum block without storing any Ethereum state (account balances, contract code, storage…) on their hard drives, at the cost of a few hundred KB of proof data and a few hundred milliseconds of additional time to verify a proof. Today, Verge represents a larger vision focused on achieving maximum resource-efficient verification of the Ethereum chain, which includes not only stateless verification technology but also using SNARKs to verify all Ethereum executions.

In addition to the long-term focus on SNARK verification of the entire chain, another new issue relates to whether Verkle trees are the optimal technology. Verkle trees are vulnerable to attacks from quantum computers, so if we replace the current KECCAK Merkle Patricia tree with Verkle trees, we will have to replace the tree again in the future. The self-replacement method for Merkle trees is to directly skip using Merkle branches in favor of STARKs, placing them into a binary tree. Historically, this approach has been considered unfeasible due to overhead and technical complexity. However, recently, we have seen Starkware using ckcleSTARKs to prove 1.7 million Poseidon hashes per second on a laptop, and with the emergence of technologies like GKB, the proof times for more "traditional" hashes are also rapidly decreasing. Therefore, over the past year, "Verge" has become more open, with several possibilities.

The Verge: Key Goals

• Stateless client: The storage space required for fully validating clients and marked nodes should not exceed a few GB.
• (Long-term) Fully validating the chain on smartwatches (consensus and execution). Download some data, verify SNARK, and complete.

In this chapter

• Stateless client: Verkle or STARKs
• Validity proof of EVM execution
• Validity proof of consensus

Stateless Verification: Verkle or STARKs

What problem are we trying to solve?

Today, Ethereum clients need to store hundreds of gigabytes of state data to verify blocks, and this amount is increasing every year. The original state data increases by about 30GB per year, and individual clients must store some additional data on top of that to effectively update the triples.

This reduces the number of users who can run fully validating Ethereum nodes: while large hard drives capable of storing all Ethereum state or even years of history are widely available, the computers people typically buy often only have a few hundred gigabytes of storage space. The size of the state also creates significant friction in the process of initially setting up a node: nodes need to download the entire state, which can take hours or even days. This creates a variety of chain reactions. For example, it greatly increases the difficulty for node creators to upgrade their node setups. Technically, upgrades can be done without downtime—by starting a new client, waiting for it to sync, then shutting down the old client and transferring keys—but in practice, this is technically very complex.

How does it work?

Stateless verification is a technique that allows nodes to verify blocks without having the entire state. Instead, each block comes with a witness that includes: (i) the values, code, balances, and storage at specific locations in the state that the block will access; (ii) cryptographic proofs that these values are correct.

In practice, implementing stateless verification requires changing the structure of Ethereum's state tree. This is because the current Merkle Patricia tree is extremely unfriendly for implementing any cryptographic proof scheme, especially in the worst case. Whether it is the "raw" Merkle branches or the possibility of "wrapping" them into STARKs, both face challenges. The main difficulties stem from some weaknesses of the MPT:

1. It is a six-way tree (i.e., each node has 16 children). This means that in a tree of size N, a proof on average requires 32(16-1)log16(N) = 120log2(N) bytes, or about 3840 bytes for a tree with 2^32 items. For a binary tree, it only requires 32(2-1)log2(N) = 32log2(N) bytes, or about 1024 bytes.

2. Code is not Merkleized. This means that to prove any access to account code, the entire code must be provided, up to 24000 bytes.

We can calculate the worst-case scenario as follows:

30000000 gas / 2400 (cold account read cost) * (5 * 488 + 24000) = 330000000 bytes

The branching cost is slightly reduced (using 5480 instead of 8480) because when there are more branches, the top part will repeat. But even so, the amount of data to be downloaded in a single time slot is completely unrealistic. If we try to encapsulate it with STARK, we will encounter two problems: (i) KECCAK is relatively unfriendly to STARK; (ii) 330MB of data means we must prove 5 million calls to the KECCAK round function, which may be unprovable for all hardware except the most powerful consumer-grade hardware, even if we can make STARK prove KECCAK more efficiently.

If we directly replace the hex tree with a binary tree and additionally Merkleize the code, then the worst-case scenario would roughly become 30000000/240032(32-14+8) = 10400000 bytes (14 is the subtraction for the redundancy bits of 2^14 branches, and 8 is the length of the proof entering the code block leaf). It is important to note that this requires changing the gas costs to charge for access to each individual code block; EIP-4762 does just that. 10.4 MB of capacity is much better, but for many nodes, the amount of data to be downloaded in a single time slot is still too much. Therefore, we need to introduce more powerful technologies. In this regard, there are two leading solutions: Verkle trees and STARKed binary hash trees.

Verkle Trees

Verkle trees use elliptic curve-based vector commitments to provide shorter proofs. The key to unlocking this is that regardless of the width of the tree, the proof portion corresponding to each parent-child relationship is only 32 bytes. The only limitation on the width of the proof tree is that if the proof tree is too wide, the computational efficiency of the proof will decrease. The proposed implementation width for Ethereum is 256.

Thus, the size of a single branch in the proof becomes 32 - log256(N) = 4log2(N) bytes. Therefore, the theoretical maximum proof size is roughly 30000000/240032*(32-14+8)/8 = 130000 bytes (the actual calculation may vary slightly due to the uneven distribution of state blocks, but this serves as a first approximation).

It is also worth noting that in all the examples above, this "worst case" is not the worst case: a worse case would be if an attacker deliberately "mines" two addresses to have a long common prefix in the tree and reads data from one of those addresses, which could potentially double the length of the worst-case branch. But even with such a scenario, the worst proof length for Verkle trees is 2.6MB, which is roughly consistent with the current worst-case verification data.

We also leveraged this observation to do another thing: we made the cost of accessing "adjacent" storage space very low: either many code blocks of the same contract or adjacent storage slots. EIP - 4762 provides a definition of adjacency, charging only 200 gas for adjacent access. In the case of adjacent access, the worst-case proof size becomes 30000000 / 200*32 - 4800800 bytes, which still roughly falls within the tolerance range. If we want to reduce this value for safety, we can slightly increase the cost of adjacent access.

STARKed Binary Hash Trees

The principle of this technology is self-evident: you simply create a binary tree, obtain a maximum proof size of 10.4 MB, prove the values in the block, and then replace the proof with the STARK proof. In this way, the proof itself only contains the data being proven, plus a fixed overhead of 100-300 kB from the actual STARK.

The main challenge here is the verification time. We can perform calculations similar to those above, but instead of calculating bytes, we calculate hash values. A 10.4 MB block means 330,000 hash values. If we add the possibility of an attacker "mining" addresses in the tree with a long common prefix, the worst-case scenario for hash values could reach about 660,000. Therefore, if we can prove hash values at a rate of 200,000 per second, we should be fine.

These numbers have already been reached on consumer-grade laptops using the Poseidon hash function, which is specifically designed for STARK friendliness. However, the Poseidon system is still relatively immature, and many people do not yet trust its security. Thus, there are two realistic paths forward:

1. Conduct rapid and extensive security analysis of Poseidon and become sufficiently familiar with it for deployment on L1.
2. Use more "conservative" hash functions, such as SHA256 or BLAKE.

If we want to prove conservative hash functions, Starkware's STARK circle can currently only prove 10-30k hash values per second on consumer-grade laptops as of the writing of this article. However, STARK technology is rapidly improving. Even today, GKR-based technology shows promise in increasing this speed to the range of 100-200k.

Use Cases for Witnesses Beyond Block Verification

In addition to block verification, there are three other key use cases that require more efficient stateless verification:

• Memory Pool: When transactions are broadcast, nodes in the P2P network need to verify the validity of the transactions before rebroadcasting. Currently, verification includes validating signatures, checking if balances are sufficient, and ensuring prefixes are correct. In the future (for example, using native account abstraction like EIP-7701), this may involve running some EVM code that accesses some state. If the node is stateless, the transaction needs to come with a proof of the state object.
• Inclusion List: This is a proposed feature that allows (potentially small and uncomplicated) proof-of-stake validators to enforce that the next block includes certain transactions, regardless of the (potentially large and complex) block builders' wishes. This would weaken the ability of powerful actors to manipulate the blockchain by delaying transactions. However, this requires validators to have a way to verify the validity of the transactions in the inclusion list.
• Light Clients: If we want users to access the chain through wallets (like Metamask, Rainbow, Rabby, etc.), they need to run light clients (like Helios). The Helios core module provides users with verified state roots. To achieve a completely trustless experience, users need to provide proofs for every RPC call they make (for example, for Ethereum call requests, users need to prove all the state accessed during the call).

All these use cases share a commonality in that they require a considerable number of proofs, but each proof is small. Therefore, STARK proofs do not make practical sense for them; instead, the most realistic approach is to use Merkle branches directly. Another advantage of Merkle branches is that they are updatable: given a proof of a state object X with block B as the root, if a sub-block B2 and its witness are received, the proof can be updated to have block B2 as the root. Verkle proofs are also natively updatable.

Connections to Existing Research:

• Verkle trees
• John Kuszmaul's original paper on Verkle trees
• Starkware
• Poseidon2 paper
• Ajtai (lattice-hardness based alternative fast hash function)
• Verkle.info

What else can be done?

The remaining major tasks are:

1. More analysis on the implications of EIP-4762 (changes in stateless gas costs).
2. More work to complete and test the transition program, which is a major part of the complexity of any stateless environment implementation.
3. More security analysis of Poseidon, Ajtai, and other "STARK-friendly" hash functions.
4. Further development of ultra-efficient STARK protocol features for "conservative" (or "traditional") hash functions, such as those based on Binius or GKR.

Additionally, we will soon decide on one of the following three options: (i) Verkle trees, (ii) STARK-friendly hash functions, and (iii) conservative hash functions. Their characteristics can be roughly summarized in the table below:

| Algorithm | Proof Size | Security Assumption | Worst-case Proving Time | |-----------|------------|---------------------|--------------------------| | Verkle | 100-2000 kB | Elliptic Curve (non-quantum resistant) | 1s | | Conservative Hash Functions (e.g., SHA256, BLAKE) | 100-300 kB | Conservative Hash Functions | > 10s | | Attack-oriented Hash Functions (e.g., Poseidon, Ajtai) | 100-300 kB | Relatively new and less tested hash functions | 1-2s |

In addition to these "headline numbers," there are several other important considerations:

• Today, Verkle tree code is quite mature. Using any code other than Verkle would delay deployment and likely postpone a hard fork. This is acceptable, especially if we need extra time for hash function analysis or validator implementation, or if we have other important features we want to incorporate into Ethereum sooner.
• Updating the state root using hash values is faster than using Verkle trees. This means that hash-based methods can reduce the synchronization time for full nodes.
• Verkle trees have interesting witness update properties—Verkle tree witnesses are updatable. This property is useful for mempool, inclusion lists, and other use cases, and may also help improve implementation efficiency: if the state object is updated, the penultimate layer of the witness can be updated without reading the contents of the last layer.
• Verkle trees are more challenging for SNARK proofs. If we want to keep reducing proof sizes to a few kilobytes, Verkle proofs will present some difficulties. This is because the verification of Verkle proofs introduces a large number of 256-bit operations, which requires the proof system to either have a lot of overhead or have a custom internal structure that includes the 256-bit Verkle proof portion. This is not a problem for statelessness itself, but it does introduce more challenges.

If we want to achieve Verkle witness updatability in a quantum-safe and reasonably efficient manner, another possible approach is to use lattice-based Merkle trees.

If the efficiency of the proof system is not high enough in the worst case, we can also leverage the unexpected tool of multidimensional gas to compensate for this shortcoming: setting separate gas limits for (i) calldata; (ii) computation; (iii) state access; and possibly other different resources. Multidimensional gas increases complexity, but in exchange, it more strictly limits the ratio between average and worst-case scenarios. With multidimensional gas, the maximum number of branches that need to be proven could theoretically decrease from 12,500 to, for example, 3,000. This would make BLAKE3 barely sufficient even today.

Multidimensional gas allows resource limits for blocks to be closer to the resource limits of the underlying hardware.

Another unexpected tool is to delay the computation of the state root until after the block's time slot. This gives us a full 12 seconds to compute the state root, meaning that even in the most extreme cases, a proving time of only 60,000 hashes per second is sufficient, which again leads us to believe that BLAKE3 can barely meet the requirements.

The downside of this approach is that it increases the light client delay by one time slot, but there are also more clever techniques to reduce this delay to just the proof generation delay. For example, proofs can be broadcast on the network immediately after being generated by any node, rather than waiting for the next block.

How does it interact with other parts of the roadmap?

Addressing the stateless issue significantly increases the difficulty of single-point finality. If there are technologies that can lower the minimum balance for single-point finality, such as Orbit SSF or application-layer strategies like squad finality, this will become more feasible.

If EOF is introduced simultaneously, multidimensional gas analysis will become easier. This is because the main execution complexity of multidimensional gas arises from handling child calls that do not pass all gas from the parent call, while EOF can make such child calls illegal, rendering this issue trivial (and native account abstraction will provide an in-protocol alternative for the current main use case of partial gas).

There is also an important synergy between stateless verification and historical expiration. Today, clients must store nearly 1TB of historical data; this data is several times the size of the state data. Even if the client is stateless, unless we can relieve the client of the responsibility of storing historical data, the dream of having almost no storage client will be unattainable. The first step in this regard is EIP-4444, which also means storing historical data in torrents or the Portal Network.

Validity Proof of EVM Execution

What problem are we trying to solve?

The long-term goal of Ethereum block verification is clear—it should be possible to verify Ethereum blocks by: (i) downloading the block, or even just downloading a small portion of the data availability sampling in the block; (ii) verifying the validity of the block with a small proof. This would be a resource-efficient operation that could be performed on mobile clients, browser wallets, or even on another chain (without the data availability portion).

To achieve this, SNARK or STARK proofs need to be applied to (i) the consensus layer (i.e., proof of stake) and (ii) the execution layer (i.e., EVM). The former is a challenge in itself and should be addressed in the ongoing improvement of the consensus layer (for example, targeting single-slot finality). The latter requires proof of EVM execution.

What is it and how does it work?

Formally, in the Ethereum specification, the EVM is defined as a state transition function: you have some previous state S, a block B, and you are calculating a new state S' = STF(S, B). If the user is using a light client, they do not fully possess S and S', nor even E; instead, they have a previous state root R, a new state root R', and a block hash H.

• Public Inputs: Previous state root R, new state root R', block hash H
• Private Inputs: Program block body B, objects in the state accessed by program block Q, the same objects after executing program block Q', state proof (e.g., Merkle branch) P
• Claim 1: P is a valid proof that Q contains certain parts of the state represented by R.
• Claim 2: If STF is run on Q, (i) the execution process only accesses objects within Q, (ii) the data block is valid, (iii) the result is Q'.
• Claim 3: If the new state root is recalculated using the information from Q' and P, R' will be obtained.

If this is the case, a fully verifiable light client for Ethereum EVM execution can be achieved. This significantly reduces the resource requirements for the client. To achieve a truly fully verifiable Ethereum client, similar work needs to be done on the consensus side.

The implementation of validity proofs for EVM computations already exists and is widely used in L2. However, much work remains to make EVM validity proofs feasible in L1.

Connections to Existing Research:

• EFPSE ZK-EVM (now deprecated due to better alternatives)
• Zeth, which works by compiling EVM into RISC-0 ZK-VM
• ZK-EVM formal verification project

What else can be done?

Currently, the validity proofs for electronic accounting systems have shortcomings in two areas: security and verification time.

A secure validity proof needs to ensure that the SNARK indeed verifies the EVM's computation and that there are no vulnerabilities. The two main techniques for enhancing security are multi-verifier and formal verification. Multi-verifier refers to having multiple independently written validity proof implementations, just like having multiple clients; if a block is proven by a sufficiently large subset of these implementations, the client will accept the block. Formal verification involves using tools typically used to prove mathematical theorems, such as Lean4, to prove that the validity proof only accepts correct executions of the underlying EVM specification (e.g., EVM K semantics or the Ethereum Execution Layer Specification (EELS) written in Python).

Sufficiently fast verification time means that any Ethereum block can be verified in less than 4 seconds. Today, we are still far from this goal, although we are much closer than we imagined two years ago. To achieve this goal, we need to make progress in three directions:

• Parallelization—Currently, the fastest EVM verifier can prove an Ethereum block in an average of 15 seconds. This is achieved by parallelizing across hundreds of GPUs and then aggregating their work at the end. Theoretically, we know how to create an EVM verifier that can prove computations in O(log(N)) time: have one GPU complete each step, and then create an "aggregation tree":

There are challenges in achieving this. Even in the worst-case scenario, where a very large transaction occupies the entire block, the computation cannot be split by order but must be done by opcode (EVM or RISC-V opcodes of the underlying virtual machine). Ensuring that the "memory" of the virtual machine remains consistent across different parts of the proof is a key challenge in the implementation process. However, if we can achieve this recursive proof, we know that at least the prover's latency issue has been resolved, even without any other improvements.

• Proof system optimization—New proof systems, such as Orion, Binius, GRK, and more, are likely to lead to significantly reduced verification times for general computations.
• Other changes to EVM gas costs—Many aspects of the EVM can be optimized to be more favorable to provers, especially in the worst-case scenario. If an attacker can construct a block that blocks the prover for ten minutes, then proving a regular Ethereum block in just 4 seconds is insufficient. The required changes to the EVM can be roughly categorized as follows:

- Changes in gas costs—If an operation takes a long time to prove, then even if its computation speed is relatively fast, it should have a high gas cost. EIP-7667 is an EIP proposed to address the most severe issues in this area: it significantly increases the gas costs of (traditional) hash functions because the opcodes and precompiles for these functions are relatively cheap. To offset these increased gas costs, we can lower the gas costs of EVM opcodes that have relatively low proof costs, thereby keeping the average throughput unchanged.

- Data structure replacement—In addition to replacing the state tree with a more STARK-friendly method, we also need to replace transaction lists, receipt trees, and other structures that incur high proof costs. The EIP by Etan Kissling that moves transaction and receipt structures to SSZ is a step in this direction.

In addition, the two tools mentioned in the previous section (multidimensional gas and delayed state root) can also help in this regard. However, it is worth noting that unlike stateless verification, using these two tools means we already have sufficient technology to accomplish the work we currently need, and even with these technologies, complete ZK-EVM verification still requires more work—just less work than before.

One point not mentioned above is prover hardware: using GPUs, FPGAs, and ASICs to generate proofs faster. Fabric Cryptography, Cysic, and Accseal are three companies making progress in this area. This is very valuable for L2 but is unlikely to be a decisive factor for L1, as there is a strong desire for L1 to remain highly decentralized, meaning that proof generation must be within a reasonable range for Ethereum users and should not be bottlenecked by the hardware of a single company. L2 can make more aggressive trade-offs.

There is still more work to be done in these areas:

• Parallelizing proofs requires that different parts of the proof system can "share memory" (such as lookup tables). We know the technology to do this, but it needs to be implemented.
• We need to conduct more analysis to identify the ideal set of gas cost changes to minimize worst-case verification times.
• We need to do more work on proof systems.

Possible trade-offs include:

• Security vs. verifier time: Choosing more aggressive hash functions, more complex proof systems, or more radical security assumptions or other designs may shorten verifier time.
• Decentralization vs. prover time: The community needs to reach consensus on the "specifications" for the targeted prover hardware. Is it acceptable for provers to be large-scale entities? Do we want high-end consumer laptops to prove an Ethereum block in 4 seconds? Somewhere in between?
• The degree of breaking backward compatibility: Shortcomings in other areas can be compensated for by more aggressive gas cost changes, but this is more likely to disproportionately increase costs for certain applications, forcing developers to rewrite and redeploy code to maintain economic viability. Similarly, these two tools also have their own complexities and downsides.

How does it interact with other parts of the roadmap?

The core technologies required to implement L1 EVM validity proofs largely share with the other two areas:

• Validity proofs for L2 (i.e., "ZK rollup")
• Stateless "STARK binary hash proof" methods

Successfully implementing validity proofs in L1 will ultimately enable easy single-point staking: even the weakest computers (including phones or smartwatches) will be able to stake. This further enhances the value of addressing other limitations on single-point staking, such as the 32 ETH minimum requirement.

Moreover, L1 EVM validity proofs can significantly increase the gas limits for L1.

Validity Proof of Consensus

What problem are we trying to solve?

If we want to fully verify an Ethereum block with SNARK, then the execution of the EVM is not the only part we need to prove. We also need to prove consensus, which includes the parts of the system that handle deposits, withdrawals, signatures, validator balance updates, and other elements of Ethereum's proof of stake.

Consensus is much simpler than the EVM, but it faces the challenge that we do not have L2 EVM convolution, so most of the work still needs to be done. Therefore, any implementation that proves Ethereum consensus needs to be "built from scratch," although the proof system itself can be built on shared work.

What is it and how does it work?

The beacon chain is defined as a state transition function, just like the EVM. The state transition function mainly consists of three parts:

• ECADD (for verifying BLS signatures)
• Pairing (for verifying BLS signatures)
• SHA256 hash (for reading and updating state)

In each block, we need to prove 1-16 BLS12-381 ECADDs for each validator (potentially more than one, as signatures may be included in multiple sets). This can be mitigated through subset precomputation techniques, so we can say that each validator only needs to prove one BLS12-381 ECADD. Currently, there are 30,000 validator signatures per slot. In the future, with the implementation of single-slot finality, this situation may change in two directions: if we take a "brute force" approach, the number of validators per slot may increase to 1 million. Meanwhile, if Orbit SSF is adopted, the number of validators will remain at 32,768 or even decrease to 8,192.

How BLS aggregation works: verifying the total signature only requires one ECADD from each participant, rather than one ECMUL. However, 30,000 ECADDs is still a large amount of proof.

Regarding pairing, currently, there are at most 128 proofs per slot, which means 128 pairings need to be verified. Through EIP-7549 and further modifications, this can be reduced to 16 per slot. The number of pairings is small, but the cost is extremely high: the runtime (or proof) time for each pairing is thousands of times longer than for ECADD.

Proving BLS12-381 operations presents a major challenge due to the lack of convenient curves with an order equal to the size of the BLS12-381 field, which adds significant overhead to any proof system. On the other hand, the Verkle tree proposed for Ethereum is built using the Bandersnatch curve, making BLS12-381 itself a self-curve used in the SNARK system for proving Verkle branches. A relatively simple implementation can prove 100 G1 additions per second; to achieve sufficiently fast proof speeds, clever techniques like GKR will almost certainly be required.

For SHA256 hash values, the worst-case scenario currently involves epoch transition blocks, where the entire validator short balance tree and a large number of validator balances will be updated. Each validator's short balance tree is only one byte, so 1 MB of data will be rehashed. This amounts to 32,768 SHA256 calls. If the balances of a thousand validators are above or below a threshold, the valid balances in the validator records need to be updated, which corresponds to a thousand Merkle branches, potentially requiring ten thousand hash values. The shuffling mechanism requires 90 bits per validator (thus needing 11 MB of data), but this can be computed at any time during an epoch. In the case of single-slot finality, these numbers may vary based on specific circumstances. Shuffling becomes unnecessary, although Orbit may partially restore this need.

Another challenge is the requirement to retrieve all validator states, including public keys, to verify a block. For one million validators, reading just the public keys requires 48 million bytes, plus Merkle branches. This necessitates millions of hash values per epoch. If we must prove the validity of PoS, a realistic approach is some form of incremental verifiable computation: storing a separate data structure within the proof system that is optimized for efficient lookup and proving updates to that structure.

In summary, there are many challenges. To effectively address these challenges, a deep redesign of the beacon chain will likely be necessary, potentially occurring simultaneously with the shift to single-slot finality. The characteristics of this redesign may include:

• Changes in hash functions: Currently, the "full" SHA256 hash function is used, which requires two calls to the underlying compression function for each invocation due to padding. If we switch to the SHA256 compression function, we can achieve at least a 2x gain. If we switch to Poseidon, we might achieve a 100x gain, thereby resolving all our issues (at least in terms of hash values): at 1.7 million hash values per second (54 MB), even one million verification records can be "read" into the proof in seconds.
• If using Orbit, directly store shuffled validator records: If a certain number of validators (e.g., 8,192 or 32,768) are chosen as the committee for a given slot, placing them directly next to each other in the state allows for reading all validators' public keys into the proof with minimal hashing. This also enables efficient completion of all balance updates.
• Signature aggregation: Any high-performance signature aggregation scheme will involve some form of recursive proof, where different nodes in the network perform intermediate proofs on subsets of signatures. This naturally distributes the proof workload among multiple nodes in the network, significantly reducing the workload of the "final prover."
• Other signature schemes: For Lamport + Merkle signatures, we need 256 + 32 hash values to verify a signature; multiplied by 32,768 signers, this results in 9,437,184 hash values. Optimizing the signature scheme can further improve this result by a small constant factor. If we use Poseidon, this can be proven within a single slot. However, in practice, using a recursive aggregation scheme would be faster.

Connections to Existing Research:

• Concise Ethereum Consensus Proof (synchronous committee only)
• Concise Helios within SP1
• Concise BLS12-381 Precompiles
• Halo2-based BLS Aggregate Signature Verification

What work remains to be done, and what are the trade-offs:

In reality, we need several years to achieve validity proofs for Ethereum consensus. This timeframe aligns roughly with the time required to implement single-slot finality, Orbit, modify signature algorithms, and conduct security analyses, which require sufficient confidence to use "radical" hash functions like Poseidon. Therefore, the most prudent approach is to address these other issues while considering STARK friendliness.

The main trade-off will likely be in the order of operations, between a more gradual approach to reforming the Ethereum consensus layer and a more radical "one change many" approach. For the EVM, a gradual approach is reasonable as it minimizes disruption to backward compatibility. For the consensus layer, the impact on backward compatibility is smaller, and a more "comprehensive" rethinking of the various details of how the beacon chain is constructed to optimize SNARK friendliness in the best way is also beneficial.

How does it interact with other parts of the roadmap?

In the long-term redesign of Ethereum PoS, STARK friendliness must be a primary consideration, especially regarding single-slot finality, Orbit, changes to signature schemes, and signature aggregation.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。