Consensus supremacy: Rethinking the foundational layer of the ZK era

Authors: krane, lamby (Asula), sylve, lancelot (Hyle) Source: bedlam research Translation: Shanooba, Golden Finance

Introduction

In the past week, we have seen several proposals regarding the roadmap for the ETH consensus layer. Most notably, Justin Drake outlined his vision for the ZK era of ETH at Devcon 2024. It is referred to as the beam chain or beam fork, which brings significant upgrades to ETH, including shorter slot times, faster finality, and the ‘snarkification’ of ETH consensus. People have had mixed reactions to the ambition of this proposal and the timeline of these changes. However, considering the scale of the ETH economy, we should also recognize how important it is to proceed with caution when it comes to ETH. While acknowledging that, it is still useful to consider what an ambitious future for the base layer of the rollup-centric ecosystem might look like. In the spirit of ‘not being burdened by the past, only for the future,’ this article explores a future that leverages ZK and consensus research progress.

We will first study the foundational layer from the perspective of basic principles, and then explore the core concepts in Consensus research. Finally, we will delve into how to apply this research to the design of the next generation foundational layer, especially under the ZK mechanism.

Basic Layer

Today, most Rollups use a centralized sequencer to order and execute transactions. After the sequencer generates blocks, it is also responsible for generating execution proofs for others to verify. In order to make the execution verifiable, third parties need the Rollup’s state data and execution proofs. The state data and proofs are typically published to the Data Availability (DA) layer, and the state transitions are verified by the Verification Layer (often mistakenly referred to as the settlement layer).

In the early days, Ethereum developed a rollup-centric roadmap and became the initial base layer, simultaneously executing data availability (DA) and verification. The unique state of Ethereum, which involves the issuance of a large amount of valuable assets on Ethereum, makes it a natural verification or settlement layer for rollup. By using Ethereum as the foundation, rollup not only inherits its security but also its liquidity. However, there were no dedicated settlement or DA options in the market at that time.

Even in today’s world with many specialized layers, having the largest PoS validator set and blob-supported Ethereum as the DA layer is also a very secure choice. In addition, the number of asset families and the Market Cap on Ethereum have been continuously rising. As ‘Settlement’ is specific to assets, for rollups that allow forced exits, verification must be done on-chain for the issuance of assets. If a rollup wants to allow forced exits for assets issued on Ethereum, it must be verified on Ethereum.

Today’s Ethereum looks like this:

However, dedicated DA layer and Settlement layer are indeed competing directly with ETH for executing these operations. For example, Celestia and EigenDA have provided significantly higher DA throughput (although with different security models). Similarly, Initia is expanding the concept of verification or Settlement center by providing Oracle Machine, unified Wallet experience, and built-in interoperability to provide a more seamless experience for users within the ecosystem (which has also become an important point on the ETH roadmap in the past few months).

All of these systems adopt the same form as ETH, and the underlying layer is decomposed into data availability and verification, with each layer serving as a specialized hub for its respective operation:

The key insight of the new design is that the DA layer and the validation layer must be optimized and separated. The initial function of blockchain was to achieve a trusted third party Decentralization between two untrusted trading partners. In a rollup-centric system, the role of the underlying layer is to act as a trusted third party Decentralization between rollups to achieve interoperability between them. Once the underlying layer verifies the status of the rollup, all other rollups can implicitly trust the underlying layer. Another core attribute of rollup-centric design is that it allows applications to provide users with fast and cheap transaction confirmation access on average (through a somewhat centralized sequencer), without compromising final audit resistance in the worst case (through forced exit of the underlying layer).

Given our understanding of the separation of data availability and verification, as well as the core functionalities of the underlying layer in providing finality, resistance to review, interoperability between Rollups, and asset issuance, we can infer how to build a better underlying layer. Currently, Rollup publishes state data to the underlying layer every few hours, which means that the pre-confirmation provided by the Rollup sequencer is only finalized on the underlying layer within this time range. A higher throughput on the underlying layer than that of Ethereum L1 can allow Rollup to publish data more frequently, reducing the time from Rollup pre-confirmation to underlying layer confirmation, thereby enhancing the security of Rollup. Similarly, faster verification enables faster interoperability between Rollups without the need for Liquidity bridges and market makers. We can leverage insights into the workload shape that the underlying layer must handle to build an underlying layer with higher throughput and faster communication between Rollups.

Integrated Blockchain has a “hot state” area, such as the frequently attacked DEX pool. This makes the relative ordering of all participants’ transactions very important. On the other hand, rollups typically operate on largely independent state spaces, with most transactions affecting only their own state within the rollup. Although cross-rollup interactions do occur (e.g., when users transfer assets between rollups or combine rollups), these interactions are explicit, well-defined, and known in advance. Because the vast majority of transactions within each rollup operate in detached states and cross-rollup transactions are handled through specific interoperability mechanisms, the need for strict total ordering of all rollup data at the base layer is minimal. Instead, selective ordering can be executed only when rollups interact explicitly:

Two Rollups publish a list of state differences and their state transitions to the base layer with ZK proof

Note: We assume Rollup publishes the state difference list here and its Rollup state transition ZK proof.

The core insights here revolve around the causal relationships between transactions and support a significant amount of work done around the Directed Acyclic Graph (DAG) Consensus model. In general, the DAG Algorithm attempts to explicitly identify dependencies so that computation/processing can be done in parallel. Building on these ideas, we anticipate the emergence of a rollup base layer where Consensus is largely relaxed to support higher throughput and lower latency.

The natural division of Rollup states indicates that it may be unnecessary overhead to enforce total order for all Rollup transactions. Systems like delta and Hylé leverage this insight, allowing Rollup to operate independently, only requiring coordination for cross-domain asset transfers. However, this does not completely eliminate Consensus; instead, it is an improvement on where Consensus is truly needed. The innovation lies in recognizing that this ordering can be limited to where it is actually needed, rather than globally enforced in all transactions.

The biggest impact of this partition is to create an elegant Rollup solution that increases the throughput of specialized execution environments without sacrificing the composability with other Rollups.

Cause-effect Ordering and Full Ordering

Before further discussion, let’s review sorting. Broadly speaking, Consensus is the unanimous opinion of all Nodes in the network on the sorting of valid transactions:

• Linear Blockchains must reach consensus on the total order of transactions, that is, the complete linear order in which events occur in the eyes of all participating Nodes. Unrelated transactions will still be neatly placed in the global order.
• On the other hand, causal ordering is just about ordering transactions, that is, transactions that occur earlier are ranked before transactions that depend on their outputs. Transactions without causal relationships do not need to be sorted with each other. This is also known as partial ordering. DAG is just a data structure that implements partial ordering among a set of transactions. Partial ordering also opens the door for parallel transaction execution among disjoint parts in the DAG. Here, there is no single, global transaction ordering agreed upon by all Nodes.

Total order can be built on top of DAG. It requires additional Consensus Mechanism to achieve consensus on the order of concurrent events. An example is the newer evolution in Narwhal And Tuskprotocol or Sui’s Mysticeti.

Transactions within the DAG can be confirmed independently of other unrelated transactions. Once a transaction gains the approval of the majority of validators, it is considered valid. Allowing individual transaction confirmation instead of confirming transactions within a block can greatly increase transaction throughput, as many transactions can be proposed and confirmed in parallel. This can be seen as a generalization of the single leader consensus, where any validators can propose new transactions (note: this can also be seen as proposing a block containing a single transaction).

To sum up, the working principle of transaction verification in DAG is:

• Users will Transaction Broadcast to a subset of validator Nodes.
• When the Node receives a transaction, it first checks whether the transaction conflicts with any transactions it currently knows based on the local view of the graph.
• If there is a conflict, such as attempting to spend the same funds, the transaction will be rejected.
• If there is no conflict, the receiving Node will interact with other Nodes in the network to reach some form of consensus on the validity of the transaction. One method is sub-sampling, where Nodes start several rounds of queries by sampling a subset of other Nodes and asking them if they consider the transaction valid based on their local view. If the threshold of positive responses from the sampled Nodes is reached, the query rounds are considered successful and represent the achievement of a quorum. Repeat this sampling process until Nodes are confident in the validity of the transaction. This process allows Nodes to quickly reach a probabilistic consensus on the validity of the transaction without the need for global consensus. Repeated sampling helps ensure that the entire network achieves consensus, making it highly unlikely for conflicting transactions to be accepted simultaneously.

Subsampling of transaction verification

It should be reiterated that any Node can run this interactive process at any given time to achieve the required number of participants, allowing for multiple paths to reach Consensus. In a sense, each validator or replica runs its own blockchain and regularly synchronizes with other Nodes. The idea of advancing multiple different blockchains before coordination is also explored in non-DAG designs, such as Autobahn (which still relies on the separation of data propagation and ordering). In Autobahn, each validator maintains its own transaction channel and then coordinates during the synchronization process. Although they are not explicitly referred to as blockchains in this article, we consider channels to be very similar to blockchains, with the synchronization process resembling the merging of multiple blockchains.

Causality in the Base Layer

Now, since we understand the concept of causality, we can try to piece together the relationship between this concept and the underlying layer. As mentioned earlier, rollup typically publishes state data or state difference lists, which correspond to the state updates on its own persistent partition state. The data published by two rollups will not contend for some ‘hot state’ because the data do not intersect at all. This relaxes the need for the underlying layer to have a global order. In addition, to verify the new rollup state, it is only necessary to verify the previously published rollup state. Therefore, the underlying layer can freely order these rollup transactions so that they can operate independently of each other without having to wait for a global order.

More broadly, rollups should be able to freely publish data and proofs to the underlying layer without worrying about fees. As data propagates through the network, validators on the underlying layer will verify the proofs published by the rollup aggregator. If a certain number of validators verify the proof, the transaction is assumed to be confirmed. Such a system will allow rollups to achieve confirmation at the speed at which data passes through the underlying layer. In theory, this should also shorten the time between the rollup aggregator’s pre-confirmation and the underlying layer’s confirmation.

The above system depends on ZK-based execution Sharding, rather than replicated execution as the future of verifiable applications.

Cross-shard transactions moving data between two rollups require ordering, but it is also partial. For example, transferring asset X from rollup A to rollup B requires rollup A’s withdrawal transactions to reach the statutory number, and then rollup B can include deposit transactions. Fast confirmation from the underlying layer will provide reliable guarantees for interoperability between rollups in the same ecosystem, thereby creating network effects for the underlying layer. Fast interoperability, combined with a large amount of valuable assets, may be sufficient to make the underlying layer attractive to potential rollups. In short, this specialized design will allow:

• Rollup transaction confirmation time is fast.
• Fast interoperability between Rollups (without the need for Liquidity bridges or market makers).
• Dedicated DA throughput for Rollup.
• Special verification tool for Rollup (more proof systems).

Brief introduction: Accumulation of underlying asset value

The above discussion provides a cheap, fast, and secure base layer for rollup. However, most of the current discussions surrounding the rollup-centric roadmap revolve around the value accumulation of ETH and Ethereum below rollup. L2s with user relationships, such as Base, can charge a premium for their Block space and only return a small portion of their revenue to Ethereum in the form of DA fees.

By allowing rollups to publish state data more frequently, the underlying layer can capture some of the revenue that would otherwise be lost to market makers and Liquidity bridges. The value brought to the underlying layer by better interoperability systems depends entirely on the number of rollups that need to communicate with each other. In settings where a single rollup does not meet the requirements of multiple applications, the value accumulation of the underlying layer becomes more apparent. Applications can achieve composability by interacting with the underlying layer. They can achieve high throughput and maintain control over their own space without sacrificing composability.

There is also an argument that improving the execution at the base layer can increase the value accumulation of the native Token. This actually allows the base layer to compete with rollup, which contradicts the rollup-centric design principle. Another approach to include execution (and possibly our preferred approach) is to build an enshrined rollup, where the base layer assets are protected by restaking the rollup sequencer. If necessary, the base layer validators set can even act as the sequencer set of the rollup (although the validators set does not have to be the same). In fact, after Martin Köppelmann’s speech at Devcon 2024, the topic of enshrined or native rollup began to heat up. For ecosystems like Ethereum, it will allow ETH to earn back some of the lost value, while also allowing developers to experiment more freely on rollup, as the stake of rollup may be much lower than Ethereum Layer-1.

Conclusion

Overall, we believe the ZK era represents an exciting and forward-looking future for Ethereum and the entire blockchain. In this article, we outline how the combination of ZK with state-of-the-art Consensus represents a potential new direction for the base layer in a rollup-centric system. By combining Zero-Knowledge Proofs with ideas borrowed from DAG-based Consensus Mechanism, we can reimagine the base layer optimized specifically for rollups. Consensus is only applied where there is actual shared state, rather than being a uniform requirement for all operations. As the ecosystem continues to evolve towards modular design, we expect this more nuanced approach to base layer Consensus to become the standard for modular blockchain.

Overall, we believe that, given that several new supporting technologies have just been put into production, the underlying layer must adopt this technology to remain competitive.

We cannot be afraid to have bigger dreams.