Consensus First: Rethinking the Base Layer in the ZK Era

Author: krane, lamby (Asula), sylve, lancelot (Hyle) Source: bedlam research Translation: Shan Ouba, Golden Finance

Introduction

Over the past week, we have seen multiple proposals for the Ethereum consensus layer roadmap. Most notably, Justin Drake laid out his vision for Ethereum's ZK era in his speech at Devcon 2024. Known as the beam chain or beam fork, it implements a number of major upgrades for Ethereum in batches, including shorter slot times, faster finality, and the "snarkification" of Ethereum consensus. There have been mixed reactions to the ambition of the proposal and the timeline for these changes. However, given the size of Ethereum's economy, we should also acknowledge how important it is to approach Ethereum with caution. Despite this acknowledgment, it's useful to consider what the most ambitious future of the base layer of a rollup-centric ecosystem looks like. In the spirit of “not burdened by the past, but looking to the future”, this article presents a future that leverages advances in ZK and consensus research.

We will first examine the base layer from a fundamentals perspective, then explore core concepts in consensus research. Finally, we will dive into how this research can be applied to a new generation of base layer designs, especially in the context of ZK.

Base Layer

Today, most Rollups employ a centralized sorter to sort and execute transactions. After the sorter generates a block, it is also responsible for generating proofs of execution for others to verify. In order for the execution to be verifiable, a third party needs the state data of the Rollup as well as the proof of execution. The state data and proofs are typically published to the Data Availability (DA) layer, and state transitions are verified by the Validation Layer (often mistakenly referred to as the Settlement Layer).

Early on, Ethereum had a rollup-centric roadmap and became the initial base layer, performing both DA and validation. Ethereum’s unique state (i.e., the large number of valuable assets issued on Ethereum) makes it a natural validation or settlement layer for rollups. By using Ethereum as a base, rollups inherit not only its security but also its liquidity. Regardless, there were no specialized settlement or DA options on the market at the time.

Even in today’s world with many specialized layers, Ethereum, with the largest PoS validator set and blob support, is a very safe choice as a DA layer. In addition, the number and market capitalization of asset families on Ethereum have been continuously growing. Since “settlement” is asset-specific, for a rollup to allow forced exits, it must be verified on the chain that issued the asset. If a rollup wants to allow forced exits of assets issued on Ethereum, it must use Ethereum for verification.

Ethereum today looks like this:

However, specialized DA layers and settlement layers do compete directly with Ethereum to perform these operations. For example, Celestia and EigenDA already provide significantly higher DA throughput (albeit with different security models). Similarly, Initia is expanding the concept of a validation or settlement hub to provide a more seamless experience for users within the ecosystem by providing oracles, a unified wallet experience, and built-in interoperability (which has also become a major point on the Ethereum roadmap over the past few months).

All of these systems take the same form as Ethereum, with the base layer broken down into data availability and verification, with each layer acting as a specialized hub for their respective operations:

The key insight of the new design lies in the optimized separation that must be made between the DA layer and the verification layer. The original role of the blockchain was to decentralize a trusted third party between two mutually untrusting counterparties. In a rollup-centric system, the role of the base layer is to act as a decentralized trusted third party between rollups to enable interoperability between them. Once the base layer verifies the state of a rollup, all other rollups can implicitly trust the base layer. Another core property of a rollup-centric design is that it allows applications to provide users with fast and cheap access to transaction confirmations in the average case (via a somewhat centralized sorter) without compromising ultimate censorship resistance in the worst case (via forced exits from the base layer).

Given our understanding of the separation between data availability and validation, and the core functionality of the base layer in providing ultimate censorship resistance, interoperability between Rollups, and asset issuance, we can infer how to build a better base layer. Currently, Rollups publish state data to the base layer every few hours, meaning that pre-confirmations provided by Rollup sorters are only completed on the base layer within this timeframe. A base layer with higher data throughput than Ethereum L1 could allow Rollups to publish data more frequently, reducing the time from Rollup pre-confirmation to base layer confirmation, thereby improving Rollup security. Similarly, validation at a higher rate would enable faster interoperability between Rollups, eliminating the need for liquidity bridges and market makers. We can use specific insights into the shape of the workload that the base layer must handle to build a base layer with higher throughput and faster inter-Rollup communication.

Integrated blockchains have areas of “hot state,” such as DEX pools that are frequently attacked. This makes the relative ordering of transactions across all participants very important. Rollups, on the other hand, typically operate on largely independent state spaces, with most transactions affecting only the state within their own rollup. While cross-rollup interactions do occur (for example, when users transfer assets between rollups or rollups are combined with each other), these interactions are explicit, well-defined, and known in advance. Because the vast majority of transactions in each rollup operate in a disjointed state, and cross-rollup transactions are handled through specific interoperability mechanisms, there is less need for strict full ordering of all rollup data on the base layer. Instead, ordering can only be selectively enforced if rollups explicitly interact:

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

Note: We assume that the Rollup publishes a list of state differences here along with ZK proofs of its Rollup state transitions.

The core insight here revolves around causal relationships between transactions, and underpins a lot of work around directed acyclic graph (DAG) consensus models. In general, DAG algorithms attempt to explicitly specify dependencies so that computation/processing can proceed in parallel. Drawing on these ideas, we expect rollup base layers to emerge where consensus is largely relaxed to support higher throughput and lower latency.

The natural partitioning of Rollup state suggests that enforcing a total order across all Rollup transactions may be an unnecessary overhead. Systems such as delta and Hylé have exploited this insight to allow Rollups to proceed independently, only needing to coordinate cross-domain asset transfers. However, this does not completely eliminate consensus; rather, it is an improvement to where consensus is actually needed. The innovation lies in the realization that this ordering can be localized to where it is actually needed, rather than enforced globally across all transactions.

The biggest impact of this partitioning is the creation of an elegant Rollup solution to increase throughput for specialized execution environments without sacrificing composability with other Rollups.

Causal Ordering vs Total Ordering

Before going any further, let's review ordering. Broadly speaking, consensus is the agreement among all nodes in the network on the order of valid transactions:

• A linear blockchain must agree on a total order of transactions, i.e., the complete linear order in which events occurred as seen by all participating nodes. Transactions that have nothing to do with each other will still fit neatly into the global order.

• On the other hand, causal ordering simply orders transactions, i.e., transactions that occurred first come before transactions that depend on their outputs. Transactions that are not causally related do not need to be ordered with respect to each other. This is also called a partial order. A DAG is just a data structure that implements a partial order in a set of transactions. Partial ordering also opens the door to parallel transaction execution between disjoint parts of a DAG. Here, there is no single, global ordering of transactions that all nodes agree on.

Total order can be built on top of a DAG. It requires additional consensus mechanisms to agree on the order of concurrent events. The Narwhal And Tusk protocol or the newer evolution in Sui's Mysticeti is an example.

Transactions within a DAG can be confirmed independently of other unrelated transactions. Once a transaction is approved by a majority of validators, it is considered valid. Allowing transactions to be confirmed individually rather than within a block can greatly increase transaction throughput, as many transactions can be proposed and confirmed in parallel. This can be thought of as a generalization of single-leader consensus, where any validator can propose new transactions (Note: this can also be thought of as proposing a block containing a single transaction).

To summarize how transaction validation in a DAG works:

• A user broadcasts a transaction to a subset of validator nodes.

• When a node receives a transaction, it first checks whether the transaction conflicts with any transactions it currently knows about based on its local view of the graph.

• If there is a conflict, such as an attempt to spend the same funds, the transaction is rejected.

• If there is no conflict, the receiving node interacts with other nodes in the network to reach some form of consensus on the validity of the transaction. One such method is subsampling, where a node starts several rounds of queries by sampling a subset of other nodes and asking them if they think the transaction is valid based on their local opinion. If a threshold of sampled nodes respond positively, the query round is considered successful and a quorum has been reached. This sampling process is repeated until the nodes are confident in the validity of the transaction. This process allows nodes to quickly reach probabilistic consensus on transaction validity without requiring global agreement. Repeated sampling helps ensure that the entire network reaches consensus, making it extremely unlikely that conflicting transactions will be accepted at the same time.

Subsampling Transaction Validation

It is important to reiterate that any node can run this interactive process to achieve a quorum at any given time, allowing for multiple paths to consensus. In a sense, each validator or replica is running its own blockchain and periodically syncing with other nodes. This idea of ​​advancing multiple different blockchains before coordinating 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, which is then coordinated during the synchronization process. While we don’t explicitly refer to them as blockchains in this article, we consider channels to be very close to blockchains, and the synchronization process is similar to merging multiple blockchains.

Causality in the Base Layer

Now, since we understand the concept of causality, we can try to piece together how this concept relates to the base layer. As mentioned earlier, a rollup typically publishes state data or a list of state differences that correspond to state updates on its own persistent partitioned state. Data published by two rollups will not cause contention for some “hot state” because the data is completely disjoint from each other. This relaxes the base layer’s need for global ordering. Additionally, to verify a new rollup state, one only needs to verify the previously published rollup state. The base layer is therefore free to order these rollup transactions, allowing them to proceed independently of each other without having to wait for a global ordering:

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

The above system depends on ZK-based execution sharding, not replicated execution as the future of verifiable applications.

Cross-shard transactions that move data between two rollups require ordering, but this is also partial. For example, transferring asset X from rollup A to rollup B requires rollup A's withdrawal transaction to reach a quorum before rollup B can include the deposit transaction. Fast confirmations from the base layer will provide reliable guarantees for interoperability between rollups in the same ecosystem, creating network effects for the base layer. Fast interoperability coupled with a large pool of valuable assets may be enough to make the base layer attractive for potential rollups. In summary, this specialized design will allow for:

• Fast confirmation times for Rollup transactions.

• Fast interoperability between Rollups (no liquidity bridges or market makers required).

• Dedicated DA throughput for Rollups.

• Dedicated validation tools for Rollups (more proof systems).

Brief Note: Value Accumulation of Underlying Assets

The above discussion provides a cheap, fast, and secure base layer for rollups. However, much of the current discussion around a rollup-centric roadmap revolves around the value accrual of ETH and Ethereum in the presence of rollups. L2s that have user relationships, like Base, are able to charge a premium for their blockspace and only have to return a small portion of their revenue to Ethereum in the form of DA fees.

By allowing rollups to publish state data more frequently to enable fast interoperability, the base layer can capture some of the revenue that would otherwise be lost to market makers and liquidity bridges. Although the value that a better interoperability system brings to the base layer depends entirely on the number of rollups that need to communicate with each other. In a setting where rollups do not meet the needs of multiple applications, the value accrual of the base layer becomes much clearer. Applications can achieve composability by simply using the base layer to interact. Applications can gain high throughput and control over their own space without sacrificing composability.

There are also arguments for improving the value accrual of native tokens by improving the execution of the base layer. This effectively allows the base layer to compete with rollups, violating the design principles of rollup-centricity.

Another approach to encapsulated execution (and likely our preferred approach) is to build enshrined rollups, where base layer assets secure the rollup collator by re-staking. If desired, the base layer validator set can even act as the rollup’s collator set (although the validator set does not have to be the same). In fact, the topic of enshrined or native rollups has started to heat up after Martin Köppelmann’s talk at Devcon 2024. For an ecosystem like Ethereum, it would allow ETH to earn back some of its lost value, while also allowing developers to experiment more freely on rollups, as rollups can have much lower collateral than Ethereum L1.

Conclusion

Overall, we think the ZK era represents a truly exciting and forward-looking future for Ethereum and blockchain as a whole. In this post, we outlined how the combination of ZK and state-of-the-art consensus represents a potential new direction for the base layer in rollup-centric systems. By combining zero-knowledge proofs with ideas borrowed from DAG-based consensus mechanisms, we can reimagine a base layer that is truly optimized for rollups. Consensus is only applied where state is actually shared, rather than as a uniform requirement for all operations. As the ecosystem continues to move toward modular designs, we expect this more nuanced approach to base layer consensus to become the standard for modular blockchains.

Overall, we believe that given that several new supporting technologies are just entering production, it is imperative that the base layer adopt this technology to remain competitive.

We can't be afraid to dream bigger.