Original Title: "We’re All Building the Same Thing"

Author: Jon Charbonneau, DBA联创

Translator: Tia, Techub News

Introduction

This article analyzes the following:

• Asynchronous Execution—Why high-performance integrated blockchains (such as Solana and Monad) separate execution from ordering (sorting) consensus.

• Lazy Sequencing—How they will reflect the design of lazy sequencers (e.g., Astria).

• Pre-confirmation—Preconfs and based rollups on Ethereum L1.

• Based vs. non-based—Comparison of based rollups + pre-confirmation with non-based rollups + base layer fallback.

• General Synchronous Composability—Through atomic inclusion (from shared sequencers) + cryptographic security (e.g., AggLayer) and/or real-time proofs.

• Fast based rollups—Based rollups should only have a fast base layer.

• Timing Games—Time is money, and how this leads to different endgames between Solana and Ethereum.

• Decentralization to Resist Censorship—How separating validators and proposers through executing auctions ensures decentralization of validators (enhancing resistance to censorship through inclusion lists).

Finally, most importantly, we will understand why we are all "building" the same thing.

Optimizing State Machine Replication (SMR)

We will start from the basics to see if the endgame of high-performance blockchains (such as Solana, Monad, HyperSDK) is a lazy sequencer (e.g., Astria). Later, we will comprehensively compare them with Ethereum-based rollups + preconfs.

Ordering and Execution

Blockchain is a state machine replication. Decentralized nodes each maintain and update copies of the system state. The operation of the chain is the result of nodes running a state transition function (STF) based on the current state + new inputs (e.g., new transactions) to produce a new state.

In this section, we will use the following terms:

• Syntactically Valid—Transaction format is correct, with appropriate transaction structure and signatures.

• Semantically Valid—Transaction executes a valid state transition (e.g., paying necessary fees).

• Sequencing—Determining the order and content of data.

• Execution—Interpreting data based on STF and taking action.

• Building—Creating a block (or partial block/fragment) from locally stored transactions.

• Validation—Performing syntax and/or semantic validation of a block (or partial block/fragment).

• Replication—Propagating a block (or partial block/fragment) to other validators.

Let's zoom in on ordering and execution, as these are the core subtasks required to compute chain state:

Additionally, nodes will validate and replicate data across the network. Consensus is reached among nodes to maintain consistency in the chain.

However, the differences in chain architectures lie in who is responsible for these tasks and when they are responsible for these tasks (e.g., block building and validation may include or exclude execution). The complete end-to-end cycle time of state machine replication (SMR) determines the lower limit of system latency. Different structures will result in highly variable times, therefore, to achieve low latency and high throughput performance, there must be an efficient process (SMR process) that can pipeline these tasks.

In the following sections, we will demonstrate the core of an efficient pipeline, which focuses on achieving consensus on inputs rather than outputs of execution. This requires relaxing restrictions on what transactions can be included. Then, we need to reintroduce some weaker constraints to ensure the system remains usable and resistant to attacks (e.g., avoiding DoS attack vectors that do not pay fees).

Traditional SMR

Traditional SMR (e.g., Ethereum) tightly integrates ordering and execution. Full nodes continuously order and execute all base layer transactions - both are prerequisites for node consensus. In addition to verifying the availability (and ordering) of all block data, nodes must also execute the block to verify:

• All transactions are syntactically and semantically valid

• The computed new state matches the state provided by the leader

Validators only vote and build blocks after independently verifying the block state. This means at least two executions are required before consensus is reached (i.e., block producer executes during building + validators execute again for verification).

In this traditional model, both building and validation include execution.

Source: Vryx: Strengthening Decoupled State Machine Replication

Streaming SMR

Streaming SMR (e.g., Solana) is an efficient pipeline form where block producers continuously "stream" block fragments (referred to as shreds) while building a block. Other nodes continuously receive and validate (including execute) these shreds, even if the rest of the block is still being built. This allows the next leader to start building their block faster.

In this streaming model, building and validation still include ordering and execution. This increases the efficiency of SMR relative to traditional SMR, while not relaxing all constraints that all included transactions are syntactically and semantically valid.

Asynchronous Execution

Integrated Approach

Now, can we achieve better performance if we relax these constraints?

Asynchronous execution removes execution from the hot path of consensus - nodes only achieve consensus on the ordering of data without needing to execute the data first. This is more efficient, which is why Solana and Monad plan to implement asynchronous execution.

Leaders will build and replicate a block (or fragment) without executing it. Then, other validators will vote on it without executing it. Nodes only achieve consensus on the order and availability of transactions. This is sufficient because given a deterministic STF, everyone will eventually compute the same state. Execution does not need to maintain consensus - it can run asynchronously. This frees up nodes' execution budget (allowing them more time to spend on execution) and reduces the steps required to achieve consensus (thus reducing time).

Ordering determines truth. Execution merely reveals truth. Once ordering is determined, anyone can execute the data to reveal the truth.

This may be why Keone believes that eventually every blockchain will adopt asynchronous execution, and this is also a key part of Toly's vision for Solana:

"Synchronous execution requires all voting and block-producing nodes to be prepared for worst-case execution time for any block… Consensus nodes can do less work before voting. Work can be aggregated and batched efficiently, without any cache misses. It can even be executed on completely different machines from consensus nodes or leaders. Users needing synchronous execution can allocate enough hardware resources to execute each state transition in real-time without waiting for the rest of the network."

"Currently, validators are replaying all transactions on each block as fast as possible, and only voting after computing the complete state transition of the block. The proposal aims to decouple the decision of forking votes from computing the complete state transition of the block."

It is worth noting that we also want to ensure that truth can be easily revealed to users, which means strong support for light clients. Some designs significantly delay execution, making this process challenging (e.g., Solana considers executing only once per epoch), while others provide state roots within shorter delays (e.g., the design in HyperSDK).

Modular Approach

This separation of ordering and execution sounds very familiar, as it is also a "modular" approach! Mixing and matching different layers that handle different tasks. The separation of ordering and execution is a key design principle of lazy sequencers (e.g., Astria):

• Ordering—Sequencer nodes only achieve consensus on the ordering and availability of rollup data (i.e., they order but do not execute).

• Execution—After the sequencer submits the data, rollup nodes execute their own data.

The main difference here is that the integration of chain nodes in traditional SMR is in ordering and execution, while lazy sequencers push it to completely different and diverse participants. Lazy sequencers have no knowledge of the rollup's state machine. They never execute these transactions. Rollups handle asynchronous execution.

The integrated approach provides a more seamless interoperability for the execution environment's users, but directly reduces the flexibility for application developers (e.g., custom virtual machines, different time slots, application-specific transaction pricing and ordering rules enforced by consensus, etc. ）). The modular approach provides greater flexibility and sovereignty for developers with custom domains, but it is more challenging to unify their experiences.

In either case, what we truly need is a truly large and fast pipeline for sorting data:

However, it's worth noting that technically, you can use almost any chain as a lazy sequencer. After all, it's just a big data pipeline. Rollups can naively throw their data onto their chosen base layer (whether it's Ethereum, Bitcoin, Monad, etc.) to implicitly use it as a sequencer. Then, rollup nodes can execute the data asynchronously afterwards.

The difference is that the chains we call "lazy sequencers" are specifically designed for this task, which is easier said than done (e.g., supporting necessary transaction types, publicly exposing simple interfaces, implementing MEV infrastructure, fast time slots, reliable transaction inclusion, high bandwidth, etc.). Therefore, nodes for integrated chains will eventually execute most of the data they include, while lazy sequencers primarily leave it to rollups.

This is why it's not as simple as "why don't we just use Solana (or any other chain, as it was never the design goal) as a rollup sequencer?":

• Lack of necessary MEV infrastructure designed for rollups (e.g., necessary PBS infrastructure, cross-chain interoperability mechanisms, writers abstracting fee payment for rollup users in the base layer Gas token)

• Lack of native transaction types designed for publishing data for rollups.

• Need to compete with the native execution environment (e.g., it's explicitly designed to use as much of the provided data as possible or as much as possible, leaving less room for reliable transactions, etc.).

• Need to compete for general developer support and upgrade priority. You might be more inclined to choose a protocol and team that specifically helps you launch rollups and designs protocols for you, rather than protocols and teams that most of the community thinks are a bit silly for rollups.

Strengthening Decoupled SMR

So, can we address these issues by relaxing these constraints? In short, yes, simple implementations do bring issues, such as allowing invalid transactions that do not pay fees (which would be a DoS vector if implemented simply), but these issues are solvable, so they are not severe issues.

We won't delve into the details here, but you can refer to the excellent work done by Patrick O'Grady on strengthening decoupled SMR on Vryx, Toly's asynchronous execution endgame, and Monad's implementation of carriage cost. Similarly, undoubtedly, the solutions to these issues, whether in the modular or integrated approach, seem almost the same.

In summary, they can reintroduce some weaker constraints (compared to synchronous execution with full validation) that retain most of the performance advantages without leaving a bunch of attack vectors.

Protocol-Internal Participants vs. Protocol-External Participants

It's important to realize that the above process naively only considers protocol-internal participants. In reality, protocol-external participants play a huge role in these transaction supply chains. This is what we saw before with (protocol-internal) validators in traditional SMR:

But in reality, almost all Ethereum validators outsource block construction through MEV-Boost, with the top three builders (Beaver, Titan, and rsync) building almost all of these blocks. Note that Beaver and rsync review OFAC transactions, while Titan does not.

Source: mevboost.pics

Relays are responsible for replicating these blocks to the rest of the network. The top four operators (ultrasound, bloXroute, Agnostic, and Flashbots) relayed the vast majority of blocks. bloXroute and Flashbots review OFAC transactions, while Agnostic and ultrasound do not.

Source: mevboost.pics

As we discussed before, we see very similar trends in latency optimization, which is not surprising. The trend is towards optimistic relays, which no longer execute block validation before replication because it's faster. Lazy sequencers can be seen as incentivizing relay networks.

These examples highlight how MEV distorts profit incentives in these systems. Validators outsource block production because experienced builders can capture more value than naively ordering blocks.

Even in asynchronous execution, there are often protocol-external block producers executing transactions during construction to maximize value. For example, lazy sequencers are likely to have profit-maximizing builders in some form of PBS. External block producers are always incentivized to fully execute and optimize the value of the blocks, which is actually useful in our relaxed setting of asynchronous execution constraints. Nevertheless, other validators do not need to re-execute before voting.

General Synchronous Composability

Definition

Now, can we obtain the sovereignty and flexibility provided by modular chains while reintegrating them to feel like an integrated chain? Can we have the best of both worlds, or will we ultimately have to take a few more steps to build Solana?

When you hear people talking about fixing the fragmentation problem of rollups, you may have heard the popular term "Universal Synchronous Composability" (USC). However, your reaction might be like this:

The meanings of these terms are different, and some terms are often mistakenly used interchangeably. We need to set some specific definitions. We have defined the following necessary terms in the context of cross-chain composability.

Please note that we will discuss "rollups" in the rest of this report, but many of these concepts also apply to other types of "L2," such as validium. I just don't want to argue about "what L2 really is" anymore.

In the following examples:

• R (A) = rollup A

• R (B) = rollup B

• T (A)(1) = transaction 1 on R (A)

• T (B)(1) = transaction 1 on R (B)

• B (A)(1) = block 1 on R (A)

• B (B)(1) = block 1 on R (B)

Please note that we define "time" here as "slot height." Time is entirely relative to the observer. The only objective concept of time we have is the relative ordering shared by observers, i.e., shared consensus (where "consensus" could be a single participant or a decentralized mechanism).

If two rollups both have a consensus mechanism that provides ordering, we can assert:

• B (A)(1) before B (A)(2)

• B (B)(1) before B (B)(2)

However, the only way to assert:

• B (A)(1) and B (B)(1) occur simultaneously, therefore

• T (A)(1) and T (B)(1) occur synchronously, i.e., if

• they share the ordering provided by the shared consensus for that given slot height.

Therefore, cross-chain synchronous composability by definition requires some form of shared sequencer to meet the requirements of that slot height. Chains without such a sequencer can only have asynchronous composability.

However, note that we can achieve asynchronous atomic composability. Unfortunately, I often notice people using "atomic" and "synchronous" interchangeably, but they are indeed different terms.

With this issue addressed, let's see if we can reintroduce synchronous composability into modular chains. If we can, it seems to negate the value of integrated chains. Here's the TLDR we will delve into:

• Shared sequencing itself can provide synchronous atomic composability (which is much weaker than composability).

• Pairing the shared sequencer with some cryptographic security mechanism (e.g., AggLayer) can strengthen this composability guarantee into practical composability.

• The security guarantees provided by AggLayer for cross-chain security can also be used without a shared sequencer (i.e., in an asynchronous setting).

• We will see how to simulate the effect of synchronous composability using cryptographic economics (directly collateralizing cross-chain transactions), although with lower capital efficiency.

Atomic Composability - Shared Sequencing

Shared sequencing means that for a given slot height, a single entity (the "sequencer," also known as the "proposer") has a monopoly on ordering multiple chains (i.e., proposing blocks). To reiterate, the shared sequencers we typically refer to are lazy sequencers. They reach consensus on the ordering and availability of rollup data but do not execute it. They are completely unaware of the rollup's state machine.

As I've written before, this means that lazy shared sequencers can provide a trusted commitment to include cross-chain bundles (i.e., a group of transactions):

• Atomicity - either all transactions are included, or none are, and

• Synchrony - at the same time (slot height)

This allows super builders (i.e., cross-chain builders) to more efficiently extract MEV when executing cross-chain operations, as they no longer need to risk-price a potentially failing transaction in a cross-chain bundle. The synchrony here implicitly provides atomicity for them.

Cross-Chain Splitting

So, how do we achieve this without fully trusting the shared sequencers of the builders and/or active proposers? If we send two independently signed transactions for each rollup (T(1) and T(2)), the shared sequencer can still decide to include only one of them.

For example, there is currently no native bundling format concept in the EVM, which is why searchers fully trust builders/relayers not to unbundle them. Anyone who sees a set of independently signed transactions before the current leader commits can unbundle them. This is usually fine because builders and relayers have an incentive to maintain their reputation and protect the searcher's bundle, but when this trust is broken (or they are deceived by dishonest participants revealing transactions), unbundling can lead to incredible profits.

If we want true cross-chain interoperability, we need stronger security guarantees. We're not just talking about taking some money from the searcher. If cross-chain DeFi contracts are built under the assumption that cross-chain bundles will be respected, but this trust is broken, the result will be disastrous for these protocols (e.g., in cross-chain bridge bundles for burning and minting, you can skip the burn on one side but mint the funds on the other).

We need robust security guarantees to achieve cross-chain interoperability. This means we must define a transaction format to ensure that multiple transactions in a cross-chain bundle are all included. If only one transaction is included without the other, we need a security guarantee that the included transaction is invalid.

This means we need to create a new transaction structure for cross-chain bundles that cannot be unbundled. The simplest solution is to "create a new transaction type for these rollups," but this is not easy. It requires VM changes to these rollup packages, losing backward compatibility. You also need to tightly couple the rollup packages by modifying the state machine of the rollup package, so that each transaction is only valid when another transaction is included.

However, there is a more elegant way to do this. You can have each transaction in the bundle also sign the bundle hash and then append the hash digest to the empty transaction field (e.g., calldata in the EVM). The rollup must modify its derivation pipeline to check these, but the VM can remain unchanged. With this, rollup users can submit their cross-chain bundles that they determine cannot be unbundled. Attempting to do so would render them invalid.

Source: Ben Fisch

Composability Guarantee vs. State Guarantee

With the above in mind, we have now identified how lazy shared sequencers work:

• They can provide a trusted atomic synchronous inclusion commitment for cross-chain bundles (i.e., all transactions will be included, or none will be included)

• They cannot provide a trusted commitment to the resulting state after such transactions are included (e.g., it is possible that both transactions are included, but some other transaction occurs before them and causes them to be reverted)

Unfortunately, the guarantee of atomic composability itself is much weaker. This commitment to atomic composability is enough to highly trust builders that the cross-rollup blocks they build, if confirmed, will create the resulting state they desire. Builders necessarily know the resulting state of the block because they executed the operation to build it.

But we still have a problem—how can others know exactly how things will turn out?

Consider an example:

• We have two rollups (R (A) and R (B)) sharing the same lazy sequencer

• I want to use a burn-and-mint bridge between R (A) → R (B), burning on R (A) and minting on R (B)

• The minting bridge contract on R (B) needs to guarantee the state transition from R (A) (burn) to R (B) (mint), but the contract cannot know if the token was actually burned on R (A) because it cannot access the state of R (A)

If we submit the appropriate bundle, the lazy sequencer can guarantee that the burn transaction is included in the transaction flow of R (A), but you don't know, for example, if another transaction falls in front of it and invalidates it (meaning the token was not actually burned).

Simply sharing a lazy sequencer is not enough to allow chains to access each other's states during bundle execution. Synchronous composability requires that the state machine of each chain can access the state of other chains during execution (e.g., the bridge contract on R (B) itself needs to know the state of R (A). This capability is key to achieving full composability in a single integrated chain.

Builders cannot just tell the contract "trust me, everything will be fine." We see that atomic composability is a good tool for searchers to trust that builders can correctly execute their bundles, but it is not enough to abstract cross-chain interoperability.

To address this issue, in addition to shared sequencing, we need to add some other mechanisms:

As mentioned, if bundles are included atomically, builders personally know what the final state will be. So how do they provide a trusted commitment to make others believe that if their transactions are included, the final state will be as expected?

They roughly have two options:

• Cryptoeconomics - Builders can commit a large amount of funds to fully guarantee their cross-chain operations. This is usually inefficient and can be said to simulate composability, but it is a useful example to showcase the functionality.

• Cryptography - We can have a mechanism that provides cryptographic guarantees to ensure that transactions will produce the desired state.

Cryptoeconomic Security - Builder Bonds

Let's understand how cryptoeconomics simulates the effect of synchronous composability through an example. The classic example used is cross-chain flash loans. I want to take a flash loan on R(A), use it for arbitrage on R (B), and then repay it on R (A), all within the same timeframe. If these DeFi protocols deploy custom cross-chain functionality and deploy what we call "bank contracts" on each side, this is possible:

Here are the translated results:

---

Now let's take a look at the security issue—contracts on R (A) and R (B) need to know each other's chain state to safely execute this operation, but we haven't taken any measures to address this issue. Well, the "solution" here in cryptoeconomics is actually quite brute force—you have the super builders act as liquidity providers and provide the full value of the flash loan. If the transaction fails, the lending protocol will retain their share anyway. You can understand why this is not the most satisfactory "solution."

Cryptographic Security - AggLayer

What is it

AggLayer is a decentralized protocol with three main advantages:

1. Secure fast cross-chain composability - It generates ZK proofs to provide cryptographic security for AggChains, enabling low-latency atomic cross-chain interoperability in asynchronous or synchronous operations (i.e., faster than Ethereum blocks). The design uniquely isolates chain faults, so it can support any execution environment and prover.

2. Interchangeability of cross-chain assets - It has a shared bridge to ensure the interchangeability of assets across AggChains (i.e., chains using it), so users won't end up with a bunch of wrapped assets. The bridge contract is on Ethereum, the settlement layer . (Note that different chains may still have different security assumptions, which will be detailed below.)

3. Gas optimization - It rolls up proofs of AggChains to amortize fixed costs across multiple chains. The shared deposit contract also optimizes gas costs by allowing direct transfers between L2s without touching L1.

Source: Brendan Farmer，Aggregated Blockchain

To clarify two common misconceptions about AggLayer:

• AggLayer is not just an aggregation proof service - This is confusing because it does indeed aggregate proofs, and they have the word "aggregation" in their name. However, the purpose of AggLayer is to aggregate chains. For the purposes of this article, the important distinction is that aggregating proofs alone cannot achieve the security guarantees we need here.

• AggLayer and shared sequencers are not opposing designs - While they don't need to be used together, they are actually perfect complements, providing different assurances. AggLayer is completely agnostic to how AggChains are sequenced. It doesn't handle any messaging between chains, so it actually explicitly relies on a free-market cooperative infrastructure (e.g., relayers, builders, isolated sequencers, shared sequencers, etc.) to compose chains.

Now let's understand how it works.

Cross-Chain Bridges Are Terrible

Today, cross-chain between rollups is terrible. Suppose you want to cross-chain ETH between two Ethereum optimistic rollups ORU (A) and ORU (B):

• Native Cross-Chain - You will pay expensive Ethereum L1 gas fees (i.e., cross-chain from ORU (A) → Ethereum + Ethereum → ORU (B)), and the round trip will take over a week (due to the existence of challenge proof windows).

• Direct Rollup → Rollup - The wrapped ETH you receive on ORU (B) cannot actually be swapped with native ETH on ORU (A). The path dependency of different cross-chain breaks interchangeability. For example, if the cross-chain from ORU (A) is exhausted, then the wrapped ETH you cross-chain to ORU (B) will not be backed, while the native ETH on ORU (B) will be fine. Fragmented liquidity is terrible, so this is not what users want. In practice, users cross-chain directly through liquidity providers. Someone will give you ETH on ORU (B) and keep your funds on ORU (A). They can withdraw through native cross-chain and wait, but they will charge high fees to bear the risk and high capital costs.

You might think ZK Rollups can solve this problem immediately, but in reality, they do not. Simple implementations still require you to submit L1 transactions, which are also costly and often very slow (e.g., due to Ethereum's finalization time, proof generation time, frequency of publishing proofs in practice, etc.).

Users don't want to deal with this problem. They just want to own funds and use applications. Cross-chain should be completely abstracted—assets should be interchangeable and can be moved quickly, cheaply, and securely.

This is where shared bridge contracts come in. The shared bridge contract opens the door for chains using it to directly bridge between each other without going through L1.

As a result, tokens can also be exchanged between AggChains. Cross-chain ETH from R (A) → R (B) or R (C) → R (B). It's not wrapped assets of locking and minting. It's native ETH. This is possible because all assets are custodied together and settled through a unified cross-chain bridge. This is a major pain point that L2 needs to address today.

But please note, if different chains use different validators (e.g., perhaps you moved from a secure chain to a circuit-faulty chain), users holding ETH on R(A) and R (B) may have different risk profiles.

Pessimistic Proofs

---

AggChains update their state and submit proofs to AggLayer staking nodes, which are responsible for arranging these updates and proofs, generating commitments to all messages, and creating recursive proofs. Then, AggLayer generates an aggregated ZK proof (which they call "pessimistic proof") for settling all AggChains to Ethereum. Since the proof aggregation here spreads the cost across any number of chains, it is feasible from a cost perspective to publish them to Ethereum for quick settlement. The pessimistic proof procedure is written in regular Rust code, using Succinct's zkVM SP1 to simplify development and achieve high performance.

These pessimistic proofs reinforce:

• Inter-chain accounting—proving that all bridge invariants are respected (i.e., no chain can withdraw more tokens than deposited).
• Validity of AggChains—proving that each chain has genuinely updated its state, with no ambiguous or invalid blocks on the chain.
• Cross-chain security—proving that the state updates from cross-chain transactions (with lower latency than Ethereum) are consistent and can be safely settled to Ethereum L1. This includes successfully synchronizing and asynchronously executing cross-chain bundled atomicity.

In this way, AggLayer ensures settlement on Ethereum only when the above conditions are met. If these conditions are not met, the corresponding chain will not be settled. Therefore, AggLayer can allow collaborators (such as shared sequencers or builders) to pass messages between chains with low latency, without trusting the collaborator to ensure security.

Fast and Secure Cross-Chain Interoperability

AggChains can use the guarantees provided here to express block validity constraints relative to other rollups in asynchronous and synchronous interoperability settings.

This will enable users to submit cross-chain bundles that must be successfully executed atomically on both sides. It's not just atomic inclusivity. You are actually enforcing that the resulting states of their execution must be successful. This complements the atomic inclusivity guarantee that the shared sequencer alone lacks.

Source: Brendan Farmer，Aggregated Blockchain

In our previous example:

• We have two rollups (R (A) and R (B)) that share the same lazy sequencer and AggLayer.
• I submit a cross-chain bundle, simultaneously destroying ETH on R (A) and minting ETH on R (B).
• Super builders build a block for both chains, and then the shared sequencer submits that block.
• The minting bridge contract on R (B) can optimistically mint ETH based on the state of R (A) (in this case, successfully executing the ETH destruction).
• These blocks and proofs are submitted to AggLayer to prove that both chains are running effectively (both independently and interdependently), and the shared bridge is being used securely.

To settle to Ethereum successfully, both sides of the bundle must execute correctly. If either side fails, the block will be invalid and cannot be settled. This means that if the shared sequencer signs a block where ETH is not destroyed on R (A) but ETH is minted on R (B), the block will be reorganized. This ensures the security of all chains and prevents dishonest cross-chain operations from being settled.

Regarding these reorganizations, two points to keep in mind:

• They will be very short, as they will be discovered and proven immediately.
• They only occur when collaborators (such as sequencers and/or builders) of the chains you are connected to act maliciously.

Due to the above points, reorganizations should be extremely rare, but precisely because of this, AggChains have control over which chains they want to combine with and what trust assumptions they want to have. For example, R (A) may accept chain states from R (B) and combine based on its sequencer's consensus, but for R (C), it may also want to submit proofs, and for R (D), they may want them to protect all cross-chain atomic dependencies in a cryptoeconomic way. Each chain can make its own customizable trade-offs here to achieve low latency and activity. AggLayer simply provides the foundation for chains with maximum flexibility and minimal subjectivity to achieve secure cross-chain interaction.

You can also see why this design is incompatible in practice with fault-proof-based designs. In theory, they could do this, but in this case, there may be incredibly deep reorganizations. Rapid proofs and resolving all chains limit the worst-case scenario to a very short time, which also serves as a natural deterrent to any malicious attempts.

Fault Isolation of Heterogeneous Provers

It is important to note that AggLayer achieves fully heterogeneous chains in a unique way. You can have an AggChain with any custom VM, prover, DA layer, etc., and securely share cross-chain with everyone.

But how is this possible? This is usually unacceptable because a single faulty participant (e.g., with circuit faults) can often deceive the cross-chain bridge and deplete all funds. This is where the inter-chain accounting proofs mentioned above come into play. These proofs ensure that all cross-chain bridge invariants are respected, so even in the case of a faulty prover, only the funds deposited in the affected chain will be depleted. Faults are completely isolated.

Trusted Neutrality

This type of infrastructure greatly benefits from trusted neutrality, which is why AggLayer's fully open-source code is neutral. In a similar spirit, AggLayer will use ETH as the sole Gas token to pay for proof aggregation.

But of course, it's not perfect. Especially at the outset, it will not maintain neutral trust completely. On the road to achieving invariance and as a public good, there may be contract upgradability.

That being said, it doesn't have to be completely neutrally trusted, as nothing is completely trusted. (We will see this again in the context of rollups in the following text.) In practice, it may offer the most compelling vision for technical competition and takes a deliberately minimalist approach to locking and rent extraction. The goal is to allow AggChains to maintain sovereignty as much as possible while still abstracting trust-minimized cross-chain composability.

AggChains do not require any specific VM, execution environment, sequencer, DA layer, equity token, Gas token, or general governance. Chains can exit at any time. There are no revenue-sharing requirements. You don't need to deploy for L3 on other chains.

In my view, launching L3 on top of a general L2 is mostly a stopgap measure, similar to the architecture being built by AggLayer. But it should be clear that this is why they are being launched today. v1 AggLayer is just a simple shared cross-chain contract. The v2 with proof aggregation and secure low-latency interoperability capabilities is not even live yet. When people are eager to release a product today that will get them the fastest distribution, you can't expect them to wait for years.

Real-Time Verification

While practicality in any low-latency setting is still a few years away, we should note that real-time proofs may also be used in conjunction with shared sequencers to achieve cross-chain security. This is also cool, so let's briefly introduce it. Specifically, "real-time" proofs refer to proof times shorter than the slot time of the relevant chain. Let's reconsider the example of cross-chain minting and burning:

• We have two rollups (R (A) and R (B)) sharing the same lazy sequencer.
• I want to use a burn and mint cross-chain bridge from R (A) to R (B), burning on R (A) and minting on R (B).
• Super builders will create a cross-chain block containing these cross-chain transaction bundles. Within the block, the builders will include a state transition proof that will be included in the other rollup.

We already have the atomic bundled inclusivity guarantee of the shared sequencer, and now each contract can verify the state proof of the other chain to see if it can execute successfully.

For real-time proofs, ideally, the proof time should only take up a small portion of the total slot time, maximizing the "synchronization window." This is the part of the slot time in which you can handle cross-chain synchronization transactions, as you need to reserve enough time in the slot to create the proof and include it in the block.

Source: Justin Drake, Real-Time Proofs

Note that we will eventually implicitly merge or collocate builders and provers. Builders have a clear incentive to optimize proof speed so they can build up to the last second and fit as many blocks as possible.

Source: Justin Drake, Real-Time Proofs

If this high incentive for real-time proofs is indeed achieved in the coming years, it is certainly not friendly to decentralized proofs. When merged or collocated with builders, provers need to be relatively centralized.

Conclusion

General synchronous composability is indeed cool, but its actual value is not yet clear. The internet is asynchronous, but you never perceive it. This is because it is fast and abstracts complexity. This is what users want.

I expect that the value of protocols like AggLayer lies not only in synchronous settings. Instead, it can actually serve as a kind of cross-rollup chain abstraction. Making many chains feel more like a user-facing chain (e.g., more interchangeable native assets, native cross-chain app functionality, fast interoperability, etc.).

Clearly, synchronous composability has economic value (e.g., enabling clearing, more efficient arbitrage, more efficient refinancing using flash loans). However, the internet is asynchronous and runs well, and TradFi is also asynchronous. It's reasonable to want to be better than TradFi, but we should be clear that general synchrony is not a necessary condition for good execution. Building and providing synchronous infrastructure also comes with real costs.

I personally believe the best reason to support USC is that it does indeed bring a better user experience and DevEx in practice. Undeniably, this has brought huge benefits to ecosystems like Solana. However, I hope this is just a problem for today, not forever.

The fact is, it's hard for anyone to deduce this conclusion through reasoning at this stage. It's not binary: "everything in crypto is synchronous" or "everything is asynchronous." I believe we will fundamentally address this issue and lean towards the latter, but both can coexist temporarily.

Ethereum-Based Rollups

Okay, now we should have a good understanding of the solution to the fragmentation of rollups. The next question is, how do we incorporate the base layer into it? What role does Ethereum play here?

We will always use the following abbreviations:

• BL - base layer
• BR - based rollup
• Preconfs - pre-confirmations

Unless otherwise specified, the BL we will discuss is Ethereum, and the BR is Ethereum BR. However, the basic concepts are widely applicable, as you can launch BR anywhere.

Vanilla Flavored Rollups

A few years ago, the initial plan was to implement rollups using BR, but it was later abandoned in favor of using a centralized sequencer to achieve low latency and efficiency. What we now refer to as BR-based sequencing was referred to as "fully anarchic" by Vitalik at the time. It was relatively impractical and inefficient before the development of Ethereum's PBS infrastructure (with mature builders).

In March 2023, BR once again became the focus of attention, and its definition is as follows:

"When the sequencing of a Rollup is driven by the base L1, the Rollup is called based on L1 or L1-sequenced Rollup. More specifically, a based rollup might be the next L1 proposer incorporating the next rollup block into the next L1 block without permission through collaboration with L1 searchers and builders."

They should provide the following benefits:

"The sequencing of this rollup is very simple and inherits the liveliness and decentralization of L1. In addition, based rollups are particularly consistent with their base L1 economically."

Specifically, you can obtain real-time security from Ethereum:

"You inherit Ethereum's resistance to censorship and liveliness. Therefore, you not only have Ethereum's settlement guarantee, but also resistance to censorship, real-time resistance to censorship, not the delayed censorship with escape pods that you know, but real-time censorship."

Once based rollup is chosen, the design based on rollup is logical:

"Ethereum is maximizing these two features, security and trust neutrality, which is almost the definition of Rollup… Rollup has already accepted Ethereum's security assumptions. You won't be adding new security assumptions. You won't be stuck in the weakest link. You are just reusing existing security assumptions. Secondly, you have accepted Ethereum as a trusted neutral platform, otherwise you would choose another chain. Now you can ask yourself, why doesn't everyone just use L1 sequencing?"

In its simplest form, BR can certainly achieve the design goals mentioned above. If a rollup does not use its own sequencer, the current Ethereum proposers will decide what to include every 12 seconds (Ethereum's slot time).

However, based sequencing still has many trade-offs, which is why rollups usually use their own sequencers:

• Fast preconfs - Rollup users do not want to wait more than 12 seconds to get an Ethereum block.
• Secure preconfs - Sometimes Ethereum may prevent reorgs, so users have to wait longer to ensure security, which they do not like. Sequencers can provide preconfs that do not depend on unfinished Ethereum blocks, so reorgs are not necessary even if Ethereum itself experiences brief reorgs.
• Efficient batch publishing - Sequencers can batch process large amounts of data, compress it, and regularly publish it to BL in a cost-optimized way (e.g., ensuring full use of blobs).

Based Rollups + Preconfs

So, can we have the best of both worlds? Let's look at based preconfs.

We will briefly explain based preconfs here so that we can compare BR + preconfs with traditional rollups. Later, we will come back to analyze preconfs in more detail and comprehensively.

The core idea is that BR preconfs must come from BL proposers. To provide preconfs, these proposers must provide some collateral (e.g., re-staking) and choose additional forfeiture conditions (i.e., the preconfs they provide will indeed be included on-chain as promised). Any proposer willing to do this can act as a BR sequencer and provide preconfs.

It should be noted that proposers (i.e., validators) should actually delegate the role of providing preconfs information to a more professional entity, the "gateway." Providing preconfs information requires a relatively complex entity, and Ethereum wants proposers to remain simple.

However, it is expected that existing relayers will also take over this role. The gateway will only interact between users and relayers, so adding another independent entity will only add complexity and delay (although delay can also be addressed through collocation). Relayers are already trusted by builders and proposers, so adding another trust requirement to users here.

Please note that while validators currently act as Ethereum block proposers, an upgrade is being considered, and the protocol itself will directly auction off the proposal right through execution auctions. This will allow mature entities to directly purchase proposal rights, avoiding validators (current proposers) delegating as envisioned here.

In any case, the important point is that any preconfs faster than Ethereum consensus (12 seconds) require a trusted third party (TTP). Whether your TTP is a re-staked validator, a winning bidder in an execution auction, a delegated gateway, or any other way, it fundamentally cannot provide real-time Ethereum security. Whether Coinbase provides "based preconfs" as an Ethereum proposer or "traditional preconfs" as a rollup sequencer, you trust Coinbase. They can also build some ETH bonds, but in either case, this is unrelated to the security of Ethereum consensus.

We should note that any design based on preconfs will inevitably deviate from the original BR goals we proposed (simplicity and BL security). Based preconfs are becoming increasingly complex, and they cannot provide real-time security guarantees for Ethereum.

However, if these preconfs providers go offline or start censoring, you should retain the ability to force transactions directly through BL transactions. When using an inclusion list, these guarantees from Ethereum should become even stronger.](https://x.com/mikeneuder/status/1768717158362595525)

For BR - TTP provides fast preconfs, while BL provides ultimate security.

Non-based Rollups + Based Fallback

Now let's consider a traditional (i.e., non-based) rollup. Its own sequencer (whether centralized or decentralized) provides fast preconfs. Later, their users obtain full Ethereum security after a delay. This includes liveliness (ledger growth + resistance to censorship) from some kind of forced inclusion or BL fallback mechanism.

As I mentioned in Do Rollups Inherit Security?:

Rollups can publicly expose confirmation rules with the same security properties as their main chain. They can receive these properties at most at the speed of main chain consensus (in practice, the speed is usually slower depending on the frequency of Rollup publishing to the main chain).

Rollups can also provide loose confirmation rules ("happy path") (i.e., sequencer) to provide a better user experience, but they have fallback plans in case of failure.

Please note that the time to achieve ultimate security is a key variable that needs to be optimized here:

Assuming rollup users can recover liveliness equivalent to the main chain, i.e., assuming you can force inclusion at the same speed as main chain blocks (e.g., if the rollup sequencer is censoring you, you can force the transaction to be included in the next Ethereum block).

In practice, there is usually a brief delay. If you allow immediate forced inclusion, you may expose profitable censorship MEV and other complexities. However, some designs may provide near real-time liveliness guarantees from the main chain (e.g., at the speed of several main chain blocks rather than one block).

In this spirit, Sovereign Labs has designed the following features:

• Permissioned Sequencing - Rollups set up a permissioned sequencer that processes transactions immediately after being included in BL. Since they have a write-lock on the rollup state, they can provide reliable preconfs faster than BL.

• Based Fallback - Users can also submit transactions directly to their BL, but the processing of these transactions requires a delay of N blocks (where N is sufficiently small). This significantly reduces the "time to achieve ultimate security," in fact, they even refer to this design as "based soft-confirm sequencing"! (Please note that this definition of BR conflicts with the definition we provided earlier, i.e., BL proposers must have the authority to sequence BR or be delegated by them.)

For non-BR - TTP provides fast preconfs, while BL provides ultimate security.

Does it? Non-BR provides fast preconfs, while BL provides ultimate security

We can see that both of the above paths will lead to the same effective results:

These BRs with preconfs no longer provide the simplicity or real-time security of Ethereum. So what does all this mean now? Why not strengthen the fallback measures for "traditional" rollups? What exactly is a "based rollup"?

This can actually be traced back to my article Proof of Governance published last year, where I discussed the fundamental use case of specific re-staking in Ethereum:

1) Technical (proposer commitment) - There is no way around this problem. If you want a trusted commitment to the sorting of Ethereum blocks, it must come from Ethereum validators. MEV Boost++ is an example that may fall under this assumption.

2) Social - I believe the primary use case for Ethereum consistency is most re-staking applications today, not economic security pools or decentralization. It's like saying, "Look, we're an Ethereum project!" This is why regardless of the architecture, blockchain has always called itself an Ethereum L2.

We can modernize this by considering the value of "BR + preconfs" compared to "traditional rollup + fast fallback."

1) Technical (Proposer Commitment) - Ethereum BRs with preconfs have a fundamental technical advantage - they can obtain reliable commitments from current Ethereum proposers regarding the inclusion and ordering of Ethereum block contents. This could be valuable for the same reasons we might want a bunch of rollups to share a sequencer. If BL proposers are also BR proposers (i.e., sequencers), they can provide atomic inclusivity guarantees to BL similar to any rollup sharing a sequencer. They monopolize both chains. Now, how valuable is this? We'll come back to this question later.

2) Social (Alliance/Trusted Neutrality) - Like it or not, Ethereum consistency is the selling point for becoming a BR. Honestly, apart from "they are BR people," I don't know much about Taiko, and I probably wouldn't know who they are if they weren't BR people. Everyone wants good joint marketing. Being a pioneer here is valuable, but I doubt it's a lasting value proposition and won't extend to many potential BRs in the future. Similarly, we've all heard of the first batch of AVs, but can you name all the current AVs? I can't.

From a higher level, you wouldn't make all Ethereum rollups choose to join the (hypothetical) "Optimism shared sequencer" or "Arbitrum shared sequencer." But you're more likely to make them all choose to join the "Ethereum shared sequencer." No new tokens, no new brands, no new consensus. If you think it's valuable for all Ethereum L2s to unite on sequencing, this trusted neutrality may be the strongest Schelling point to achieve that goal.

This trusted neutrality may be most valuable for rollup developers trying to attract cross-ecosystem users (e.g., applications with infrastructure like ENS). If the Optimism sequencer alienates Arbitrum users, they might hesitate to use it, and vice versa.

We'll delve into each of these in more detail below.

Trusted Neutrality

From a social perspective, BRs are generally seen as the most "Ethereum" option. Regardless of anyone's judgment of its value, the important point is that this presupposes a high degree of trusted neutrality for any BR design.

In a vanilla scenario, designing a trusted neutral BR is easy, but as we pointed out, no one really wants these. Then, preconfs inevitably require proposers to choose additional forfeiture conditions. These additional forfeiture conditions require proposers to make commitments using some additional system (e.g., possibly EigenLayer re-staking, Symbiotic, or other standards). Rollups may be happy to choose a trusted neutral "Ethereum sequencer" in the abstract, but if you're using a private project, or even their own token, trusted neutrality may be lost.

Regarding collateral, there are several unresolved issues:

Collateral Scale

Early designs assumed proposers must personally provide a large collateral of around 1000 ETH. The issue is that fundamentally, proposers can always renege on their commitments and construct blocks themselves, casting doubt on preconfs. This could be valuable, and 1000 ETH is far higher than the highest payment observed since MEV-Boost was established. The downside is that this will inevitably set a high barrier to entry for smaller proposers, while larger proposers (e.g., Coinbase) can reasonably provide 1000 ETH and receive rewards for all their stake weight (> 13% of total staked ETH) as registrants can provide a single collateral for all their validators. There are other ideas to allow proposers to provide much smaller collateral, but of course, it's a trade-off. The design space here is uncertain.

It's worth noting that executing auctions will mitigate this concern, as we can assume all proposers are sophisticated participants who can easily do this.

Collateral Type

In this case, Vanilla ETH may be the only trusted neutral collateral. However, people naturally want to use more capital-efficient assets (e.g., stETH). mteam describes some ideas for underwriters to handle this conversion.

Platform

If "Ethereum-based preconfs" are more like "EigenLayer-based preconfs" or "Symbiotic-based preconfs," then it's not "trusted neutral." Some teams plan to move in this direction, but using such platforms is not a strict requirement. Creating a common neutral standard for everyone seems more suitable for widespread adoption, becoming the most basic choice.

To reasonably achieve "trusted neutrality" in preconfs-based designs, public goods standards are needed.

Preconfs

Inclusivity and State Presets

Now we'll delve into preconfs in more detail. While we've discussed a specific type of preconfs before (BR state preconfs), we must note that it's a completely general concept. Besides BR, you can also provide preconfs on BL transactions, and you can provide preconfs of different strengths:

• Inclusion preconfs - Weaker commitments to transactions being ultimately included on-chain.

• State preconfs - Strongest commitments to transactions being ultimately included on-chain and guarantees on the final state.

The latter (state preconfs) is what users want their wallets to show them:

I exchanged 1 ETH for 4000 USDC and paid a fee of 0.0001 ETH

Non-inclusion preconfs:

My transaction attempts to exchange 1 ETH for 4000 USDC and pays a fee of up to 0.0001 ETH, but the transaction may succeed or fail, we'll see

However, we should note that in cases where users take action on non-controversial states (e.g., simple transfers where only the user can invalidate the transaction), inclusion preconfs can actually be interchangeable with state preconfs. In this case, a commitment like "The USDC transferred from Alice to Bob will be included in the next few blocks" is enough to show the user "You have sent your USDC to Bob."

Unsurprisingly, stronger commitments (state preconfs) are harder to obtain. Essentially, they require a trusted commitment from the entity currently monopolizing proposer blocks (i.e., a write-lock on the chain state). In the case of Ethereum L1 preconfs, this is always the current Ethereum L1 proposer. In the case of BR preconfs, it's likely the next Ethereum L1 proposer in the BR lookahead (thus making it the current proposer for BR), as described below. Proposers and sequencers are often interchangeable terms, with the former being more common in the L1 context and the latter in the L2 context.

Pricing Presets

Another significant distinction we need to make is what types of states these preconfs involve:

• Non-controversial states - No one else needs access to this state (e.g., Alice wants to transfer USDC to Bob)

• Controversial states - Others want access to this state (e.g., exchange in the ETH/USDC AMM pool)

Preconfs are restrictions on what blocks might ultimately be produced. All else being equal, restricting the builder's search space essentially only reduces the potential value they can extract from ordering. This means the value returned to the proposer will decrease. To make it incentive-compatible, the gateway needs to charge a preconfs fee ≥ potential MEV to constrain the outcome.

When the MEV loss is approximately 0 (e.g., in USDC transfers), this is straightforward. In this case, charging a nominal fixed fee may be reasonable. But we have a big problem - how do we price preconfs for controversial states? Pricing preconfs in advance seems more cost-effective than pricing them in real-time. All else being equal, it's most profitable for the builder to capture and accurately price MEV at the last second.

However, we assume there's enough user demand to quickly preconf controversial states (considering experienced searchers and regular users), so there will sometimes be a clearing price that's beneficial for everyone. Now, how do you price preconfs for controversial state transactions (otherwise you might include them at any time in the next 12 seconds), potentially giving up more profitable opportunities that are no longer possible?

Preconfs for controversial states circulating throughout the block will conflict with how builders create blocks. Accurately pricing preconfs requires real-time assessment of the impact of including them now versus delaying their inclusion on MEV, which means executing and simulating potential outcomes. The gateway now needs to become a highly complex searcher/builder.

We've assumed the gateway and relayer will merge. If they need to continue pricing preconfs, then they will also merge with the builders. We've also accepted that USC will accelerate the merger of builders and verifiers. Executing auctions seems to directly sell proposer rights to mature participants (possibly builders) who can price them.

This puts the entire Ethereum L1 and BR transaction supply chain into a box with a monopolistic write-lock on the state of all chains during that period.

The sorting strategy for preconf services is not yet clear (e.g., whether they always run FCFS or sort in other ways). The gateway may also auction off all preconfs (e.g., allowing searchers to bid on preconfs), although it's unclear what this design would look like and it inevitably means higher latency.

Fair Exchange Issue

There's a fair exchange issue with preconfs because the gateway doesn't actually have a direct incentive to release preconfs.

Consider the following example:

• The current gateway has a 12s monopoly

• A user submits a preconfs transaction request at the start of the slot (t = 0)

• The gateway waits until t = 11.5 to release all the preconfs it made during the slot and leaves a 500ms buffer to include them all in its block. By then, they can decide which preconfs to include and exclude in a profitable scenario

In this case, the user may end up paying for preconfs even if they don't actually receive them until the end of the slot. If the gateway deems it unprofitable to include it, they can simply discard it at the end of the slot. This withholding by the gateway is not objectively attributable as an error (but it may be subjectively attributable).

In fact, the gateway has an incentive to hold onto preconfs information until the last moment. Where there's information asymmetry, there's MEV. Keeping transaction privacy allows builders to better understand the state of the world in a timely manner, enabling them to price risk better and capture MEV. There's no consensus on the set of preconfs information provided to users, so the gateway cannot be held accountable.

Standards need to be established, and it's expected that preconfirmers will immediately publicly broadcast all preconfs information. This would immediately provide users with what they want and show others that the gateway is providing the expected service. If they fail to do this in the future, users won't trust them and won't pay for preconfs information. The reputation of the gateway is valuable. However, being dishonest and violating preconfs information here could also be very valuable.

L1 Base Layer Preconfs

After understanding the general points of preconfs, we will now discuss the subtle differences of L1 preconfs. Although we haven't mentioned them before, some projects are building these preconfs, and their interaction with BR preconfs will be crucial.

For example, Bolt is a protocol that aims to make Ethereum proposers make trustworthy commitments to their block content. Registered proposers can run a Bolt sidecar to receive preconfs requests from users, confirm these requests, and then send this information to relayers and builders, who can return blocks that comply with these constraints (i.e., they return a block containing the transactions given preconfs by the proposer).

It's important to note that the Bolt v1 described here only supports simple transaction inclusion preconfs for non-controversial states, where only the user can invalidate the preconfs. As we discussed earlier, these are the simplest and weakest commitments.

All these preconfs teams have bigger ambitions (e.g., state preconfs, partial block auctions, slot or partial slot auctions), so what's holding them back?

• Accountability - Commitment breaches should be provable on-chain for objective forfeiture. Proof transactions are relatively easy to include, but how to enforce other commitments (like slot auctions) is less clear.

• Capital Requirements - Providing arbitrary commitments means the cost of breaching commitments could be arbitrarily high. The gateway may ultimately need to commit a large amount of capital (e.g., thousands of ETH) to provide these commitments. This capital may end up being concentrated, benefiting the largest entities (e.g., large trading firms or Coinbase) while excluding smaller entities.

• Pricing - Even if we think it's feasible and valuable, there are still many unresolved questions surrounding how to price things like continuous flow state preconfs.

• Network Participation - Perhaps the most important and fundamental point. As we mentioned, only the current proposer with state write-lock can provide commitments like state preconfs. In theory, 100% of proposers could opt into this system and mimic it. But in practice, this won't happen.

MEV-Boost is a simpler product with years of successful operation, running at extremely high profits, with participation rates exceeding 92% (possibly higher, as this doesn't consider minimum bids). New preconfs services are likely to achieve much lower participation rates. But even if it can reach around 90%, it doesn't seem like a useful product for regular users. You can't tell users "Sorry, there are no available preconfs right now, please check back later" 10% of the time.

At best, it feels like state preconfs will only be an optional tool for seasoned searchers and traders who may want to get commitments early in the block when a proposer happens to opt into the system. This could be valuable, but there's no fragmentation or user experience unlocked here.

L2 Rollup-Based Preconfs

BR preconfs must come from BL proposers (that's why they're "based" on them). This requires them to stake some collateral and choose additional forfeiture conditions (i.e., the preconfs they provide will indeed be included on-chain as promised). Any proposer willing to do this can act as a BR sequencer and provide preconfs.

It's important to note that these BR preconfs are state preconfs, not just inclusion preconfs. This is possible because BR has chosen a design where they rotate the sequencer monopoly to registered BL proposers.

Today, each slot has an Ethereum validator as a proposer, and the schedule of proposers for the current and next period is always known. One period has 32 slots, so we always know the next 32-64 proposers at a given time. The design works by granting the next active sequencer (i.e., the next sequencer in the lookahead) the monopoly power to order transactions for BR that opt into this preconfs system. The gateway must sign to advance the state of the BR chain.

Note that every proposer (even those who didn't opt to be a gateway proposer) has the right but not the obligation to include transactions that have been preconfirmed by sequencers (i.e., those who opted to be gateway proposers). They can act as includers as long as they have the complete list of transactions preconfirmed up to that point (sequencers can create BL blobs containing BR transactions and propagate them).

Source: Ethereum Sequencing, Justin Drake

The transaction process is as follows:

1. BR users submit their transactions to the next sequencer in the lookahead (the proposer of slot n+1 in the diagram)

2. The sequencer immediately provides preconfirmation for the resulting state (e.g., the user on BR exchanged 1 ETH for 4000 USDC and paid a fee of 0.0001 ETH)

3. At this point, any includer can include the sorted transactions (the proposer of slot n in the diagram does this)

Source: Ethereum Sequencing, Justin Drake

If other includers do not include preconfs, the sequencer providing preconfs can simply include them on-chain when it's their turn as a BL proposer. For example, in the diagram above, suppose the slot n includer decides not to include the preconfs provided by the slot n+1 sequencer. Then the slot n+1 sequencer would be responsible for including all the preconfs they provided during slots n and n+1 when submitting the BL block for n+1. This allows sequencers to confidently provide preconfs throughout the entire period between them and the last sequencer.

To simplify the explanation above, we assume that L1 proposers will fulfill this preconfs role. But as mentioned earlier, it's unlikely to be the case. It would require a complex entity to price preconfs, run full nodes for all BR, provide DoS protection for all BR transactions, and enough bandwidth, among other things. Ethereum wants validators to remain very simple, so proposers may outsource preconfs to another entity, just as they outsource full L1 block production through MEV-Boost today.

Proposers can delegate to the gateway through on-chain or off-chain mechanisms, which can continue until before their period. As mentioned earlier, this role may actually be taken over by relayers. They may also need to coordinate with builders.

Source: Based on Sequencing, Justin Drake

As mentioned earlier, only one entity can be delegated as the gateway at a given time. This is necessary to provide reliable state preconfs. The UI (e.g., wallets like MetaMask) will take note of who the next gateway is and send user transactions there.

Ethereum Rollup - What Should They Be Based On?

Now that we have enough background knowledge, what should Ethereum rollups be based on? There are actually two questions here:

1. Should many Ethereum rollups share a sequencer?

2. If so, should it be based on a sequencer (i.e., involving Ethereum BL proposers and the surrounding MEV infrastructure)?

First, it's worth noting that you can temporarily share a sequencer with other chains. For example, if Ethereum proposers bid the highest, they might order a block for you, and then if another BFT consensus bids the highest, they might order a block for you next. However, this still requires a chain to fully opt into this unified shared auction that can run in sync with other chains, so there are still trade-offs in control and flexibility (e.g., shared block time). The winning sequencer entity can transfer.

Regardless, let's assume condition 1 is met. I think there's currently compelling evidence that the demand for decentralized shared sequencers is significant. Even if they don't care much about the "shared aspect," I think the ability to buy off-the-shelf decentralized sequencer-as-a-service has extremely high value (in fact, I think this is the biggest value here).

Should this shared sequencer be based on Ethereum?

Technical (Proposer Commitments)

I don't see a strong technical case for using an Ethereum-based sequencer. Interoperability between BR and Ethereum L1 will be severely limited due to the inability to reliably enforce write-lock on L1 state, longer block times (12 seconds), and the need for BR transactions wishing to interact with L1 to be reorganized alongside it. There's no free lunch here. Compared to any other external shared sequencer, this wouldn't unlock any valuable user-facing products.

The main value I see is that adding Ethereum L1 to this larger combined auction might create higher total value and allow L1 to capture more value. Taking this logic to the extreme, we might as well put everything in the world in the same auction. This universal auction should also order Taylor Swift concert tickets. I'm not there yet.

This is just to emphasize that there are actual costs in creating and getting everyone to opt into this shared auction, and in my view, these costs may outweigh any theoretical additional value creation here. If we're not trying to stack it on top of Ethereum L1 (e.g., just building a simple fast consensus mechanism for this purpose), we could easily build a better technical design from scratch. Not to mention, this combined auction would lead to exponential complexity.

In fact, I think this approach based on a priori system architecture may have a substantial counterproductive impact on Ethereum, as it could accelerate the formation of MEV infrastructure when Ethereum's supply chain is already relatively fragile. This could jeopardize the network's decentralization and censorship resistance - which are the most fundamental features that make it valuable.

Social (Trusted Neutrality)

I do think there's a valid social argument for an Ethereum-based sequencer.

As mentioned earlier, there's no doubt that "alignment" is a selling point for initial BR. That's great, but I don't think it will last. Being the first BR is cool, but being the eighth BR is not cool. Something else needs to be added.

I think the trusted neutrality of an Ethereum-based sequencer could be that additional value. At least, this could be the strongest argument supporting this design. Many chains are looking to get a decentralized sequencer plug-and-play. If we can eventually design enough infrastructure on top of it to improve cross-chain user experience, that's even better. However, in projects wanting to design this way, I think many projects are not willing to "take sides" with any third-party protocol. As mentioned earlier, imagine if you're an application chain with fundamental universal infrastructure like ENS, and you want a Rollup. You wouldn't want to choose Arbitrum's shared sequencer, as it might exclude the Optimism community, and vice versa.

Perhaps the only way to solve this social coordination problem is to have a trusted neutral shared sequencer, and Ethereum is clearly the strongest candidate. Note that this further emphasizes my previous point about trusted neutrality - if this is the primary value-add of such a service, it must be a very high priority design goal when creating it. If it looks like a pet project of some third-party protocol with its own profit motives, it won't work. It actually has to be the Ethereum shared sequencer.

It is worth noting that there is also valid criticism that the "neutrality" here is a code name for "Ethereum." In other words, its primary motivation is to benefit Ethereum and its native surrounding infrastructure. Of course, such a system would benefit all parties involved. This means that the value capture of ETH assets will be higher, and Ethereum builders, relayers, and searchers will gain more profitability.

Fast Based Rollups

Fast Base Layers

Now we should understand that you can have a blockchain on a slow blockchain like Ethereum, you can add trusted preconfs for a faster user experience, and you can even ensure security across chains through cryptoeconomics or cryptographic guarantees.

But as pointed out, what if we were to design this thing from scratch. Not dealing with the technical debt and decisions of existing chains. What is the approach to building this thing…

Previously, we discussed that the only technical reason for a given BL (e.g., Ethereum) to become a BR with preconfs is that its proposers can sometimes provide a trusted commitment with atomic inclusion with the BL.

However, we haven't seriously discussed the ability to become a BR without preconfs. We basically gave up on this because Ethereum is slow, and users are not patient.

So why don't we use fast BL for BR?

This solves almost all the complex edge cases and concerns we encountered before. We don't want gateway liveness failures (which result in the same security failure here), we don't want them to violate committed preconfs (i.e., security failure), and we also don't want Ethereum reorgs. This is why consensus exists.

DA Layer is Dead, Sequencing Layer Forever!

Most discussions about lazy sequencers view them as rollup sequencers and then dump their data to other DA layers. For example, the first two rollup sequencers of Astria (Forma and Flame) will use Celestia as their DA layer. Astria's consensus will sequence these rollups and then forward the data to Celestia.

This combination is particularly good because they are obviously complementary - Astria provides all the sequencing infrastructure, and Celestia provides trust-minimized verification through Data Availability Sampling (DAS).

However, Astria can also be used to sequence native rollups for Ethereum, Bitcoin, Solana, or any other native rollup you want. For example, it can even be set up as a preconfs sequencer for Ethereum's "BR with preconfs" (instead of a centralized gateway, as the lazy sequencer is basically just an incentivized and decentralized relayer).

However, it should be clear that every chain is a DA layer. Full nodes can always check the DA. Data availability is part of any chain's validity condition, so consensus is always signing off on data availability. Light clients check its signature and get an honest majority assumption. The only difference is if the chain offers another option for light clients, i.e., directly sampling the DA instead of asking consensus.

However, as I pointed out in "Do Rollups Inherit Security?", fast chains like Astria can technically add a slow path for DAS (to increase verifiability), and slow chains like Celestia can add a fast path for sequencing (based on a majority trust assumption and without DAS), the so-called "fast blocks slow blocks."

Turning to vertically integrate specialized layers such as sequencing or DAS will further narrow the distinction between modular blockchains and integrated blockchains. This also applies to vertical integration by adding ZK verifier accounts to the base layer of Celestia to create a settlement layer.

However, separating these services instead of bundling them together is significant. It's a modular approach that allows rollups to choose the current functionality they want (e.g., I want decentralized sequencing with fast blocks, but I don't want to pay for DAS, and vice versa). Researchers have indicated they want DAS, but so far, users have indicated they only want fast blocks.

Bundling services like "fast blocks slow blocks" will be very opinionated and integrated. This will inevitably increase complexity and cost. The impact of slot length on the prevalent timing games (and potential decentralization) on Ethereum is also a consideration.

Fast Base Layer vs. Slow + Preconfs

But you can also use Astria as the BL for rollups. The shared sequencer can be seen as a BL optimized for its own BR.

When your BL is fast, your BR doesn't need preconfs because it can get fast confirmations directly! Then your rollup actually gets real-time security from the BL, while BR + preconfs will inevitably lose this.

In fact, a BR without preconfs is the most reasonable way to build a rollup. That's why today's rollups all start from here:

It's clear that a BL with fast blocks solves most of the problems we encountered in "rollup + preconfs" approach. The shared sequencer is naturally built from first principles, "Hey, app developers just want to launch a fast, reliable, and decentralized chain - how do I provide that to them?" Attempting to add preconfs to slower base layers like Ethereum would lead to the complexity described above.

We Are All Building the Same Thing

Modularity is Inevitable

Therefore, we see how modular chains are being re-aggregated to provide Universal Sync Composability (USC). Of course, there are trade-offs involved, but they do reintroduce meaningful uniformity while retaining greater flexibility than using a single state machine. For me, there is a very compelling case that asynchronous composability is what most of our use cases need. We need low latency, performance, and a good user experience. The internet is asynchronous, and abstracting all of these works very well. Composability is a huge value add for crypto, but composability ≠ synchrony.

Setting aside flexibility and sovereignty interests, most people would agree that we ultimately need multiple chains to achieve scalability. This means that we will eventually have many systems that need to be unified, so the modular direction is inevitable here.

Ethereum + Preconfs → Solana?

Now, let's compare the endgames here. Specifically, we will compare the endgame of Solana with the endgame of Ethereum if Ethereum were to go down the path of maximizing uniformity and user experience through rollup + preconfs.

In this vision, a large number of BRs use Ethereum-based sequencers. Gateways continuously transmit proposer-committed (i.e., without any consensus weight) preconfs to users with low latency, and then Ethereum proposers submit them to full blocks at regular intervals. This may sound familiar because it's almost exactly what we previously described for Solana's fragment stream!

So, is this just a more complex Solana? The biggest difference here is the slot time:

Ethereum is attempting to add this functionality on a slow chain, which seems problematic at first glance:

• Ethereum's consensus is too slow for users, so the only way to achieve a reliable, neutral, and fast user experience is to opt into proposer-committed preconfs. Currently, its main bottleneck is due to its large validator set leading to signature aggregation (MaxEB and improved signature aggregation could help here).

• This would lead to proposers monopolizing longer times, providing higher incentives and freedom to gain more MEV through dishonest behavior (e.g., withholding preconfs).

• If gateways do start delaying or withholding preconfs, the worst-case scenario for users is relying on Ethereum's slot time. Even if Solana block producers stop continuously building and transmitting blocks within their allocated monopoly range (which may be reasonable for the same reasons), the worst-case scenario is relying on fast-rotating consensus. However, today's four-slot monopoly is necessary for network reliability.

• In practice, the number of gateways may be very small at the beginning, resulting in a more centralized set of operators than Solana.

• The staking requirements for proposers could be very high (note that the design space is still ongoing).

• Concerns about liveness issues would cause significant losses here (as preconfs loss due to operator liveness issues is equivalent to a security failure for users and must be severely penalized).

All of these can be addressed through fast consensus. All of these systems are actually why we first made BFT systems. So why shouldn't Ethereum make its consensus faster? Are there some less obvious trade-offs to having a super low-latency base layer block time?

Fortunately, I wrote an article about "Is a Shorter Block Time Better?" The biggest concern with a shorter block time is related to centralization of validators and operators. Specifically, people are concerned about the interaction of a shorter block time with timing games:

We see the timing games on Ethereum are ongoing. Proposers delay proposing blocks in their own slots to earn more money at the expense of others. Relayers also provide "timing games as a service," similarly delaying blocks within slots:

Source: Data Always

A few weeks ago, in the infamous Justin vs. Toly Bankless podcast, timing games were a hot topic:

Justin believes timing games will be a problem, and incremental rewards always make sense. Toly believes timing games won't be a problem, and the insufficient incremental rewards from additional MEV extraction are a concern.

I personally find it hard to ignore the importance of timing games:

• Now, we have seen this in practice on Ethereum. Solana's argument is that this situation only occurred because MEV was socialized earlier on Ethereum, but this is not convincing because the early public outcry against timing games has now turned into acceptance of this new reality and designing around it.

• MEV rewards are substantial—the amounts being discussed here have reached billions of dollars, not just a few cents under the couch. Even earning a few percentage points more is a huge sum.

• Even if you don't believe stakers are sensitive enough to marginal returns, actual operators are running businesses, and this directly affects their bottom line.

• Solana is more likely to rely on large stakeholders' altruism in its early lifecycle (e.g., foundations and large investors), but this is unsustainable as any network will further decentralize.

I believe both the directions taken by Solana and Ethereum have tremendous value. If nothing else, we will see all of this in practice. Strategically, I also think it makes sense for Ethereum to differentiate itself. Maximizing decentralization as a means of resisting censorship in adversarial situations. Ethereum has made many sacrifices to maintain a highly decentralized protocol because it is a necessary condition for the long-term game. It has unparalleled client diversity, network ownership distribution, ecosystem stakeholders, operator decentralization, and more. If (likely when) Solana faces serious censorship pressure in the future, the reasons for Ethereum's decisions will become increasingly clear.

Last week, Preconf.wtf took place in Zuberlin, and it's not surprising that everyone is talking about preconfs and based rollups. It's all very cool. But personally, I think Vitalik's talk on "one-bit-per-attester inclusion lists" and Barnabé's talk on "Overload the Execution Proposer instead (From MEV-Boost to ePBS to APS)" are the most important for Ethereum's future.

Source: Barnabé Monnot_ and _From MEV-Boost to ePBS to APS

The discussion about preconfs and rollup-based solutions has recently heated up, and I am definitely more cautious. Vitalik has proposed the following famous endgame:

However, we have delved deep into "centralized production" without implementing stronger anti-censorship protections, such as inclusion lists. Essentially, half of Ethereum is at the bottom row of the diagram below. (I say half because the censorship regime is not actually black and white, and Ethereum only has "weak censorship," meaning most but not all blocks are subject to censorship, so you might just have to wait a bit and then you'll be included):

Source: Proof of Governance

From an experiential standpoint, the Ethereum L1 MEV supply chain currently has more real-time censorship-resistant blocks than any L2 with centralized sequencers.

L2s get L1's final CR without a base (which is still very good). Protocol-based on preconfs cannot get real-time security of the Ethereum protocol; they can only get real-time security from a few relatively centralized infrastructure providers around it. To get better real-time CR, the best option might be to outsource sequencing to some kind of decentralized sequencer running simple BFT consensus. This would be more powerful than centralizing many chains into the current relatively centralized bottleneck. This situation may improve with changes such as execution auctions and inclusion lists, but it's not imminent.

Considering all these factors, I'm not sure if it's a good idea at this stage to expand reliance on Ethereum L1 MEV infrastructure and then solidify it into L2, because only a few people build and relay all Ethereum blocks today, and most uncensored Ethereum blocks rely on a single builder (Titan), and the protocol has not yet implemented any CR tools. This feels like accelerating in a fragile place. Ethereum should certainly strive to improve the user experience of L2, but not at the cost of sacrificing all the underlying properties we originally wanted.

Conclusion

We are all building the same thing.

Clearly, these things are not exactly the same. There will always be practical differences between these systems. However, the overall trend in the crypto space is clear—we are converging towards increasingly similar architectures.

The subtle technical differences between them will have significant implications for their ultimate outcomes in practice. Even as these systems tend towards similar end results, we cannot underestimate the significant role of path dependence in these systems.

Furthermore, some things are almost impossible to reason about. As Vitalik said:

"One thing to note about APS is that from a purely technical perspective, it's actually very lightweight, and we could totally get it done with very few technical errors… but from an economic perspective, the potential for error is much greater…

Just like EIP-1559, we were able to solve the problem through theory. We attended some great economics conferences, learned about the risks and downsides of first-price auctions, found that second-price auctions are not trustworthy, and then found that by using a mechanism that localizes a fixed price within each block, we can do a lot of things in microeconomics.

But APS is not like that. Whether APS will lead to Citadel or Jane Street or Justin Sun or anyone else producing 1% or 99% of Ethereum blocks, that's a very, very difficult question, and fundamentally may not be resolvable.

So, what I want to see now is field experiments… Personally, I want to see APS running on Ethereum L2 from today until I'm very satisfied with APS, and it's been successful for a year, maybe a bit longer, and then we can see some real-time consequences.

So yes, I don't know what will happen either. We can only wait and see. In any case, while we all have consensus on this endgame, we have far more in common than differences, so let's make sure…

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