Original title: Do Rollups Inherit Security?

Original author: Jon Charbonneau

Original compilation: Frank, Foresight News

introduce

Love it or hate it, Twitter will probably never stop debating whether L2 or Rollup inherit security.

While most arguments are battles of semantics that are hard to discern, if you can manage to narrow it down, the underlying points are valuable because they get to the heart of the question of when, where, and why Rollup makes sense.

Does scalable L2 eliminate the need for L1? Is it possible to turn an L1 like Solana into an L2?

These arguments largely boil down to safety issues. Unfortunately, the definition of security here has been very elusive. We often use this term loosely, and most people have a rough idea of ​​what were talking about, but not entirely sure. Well break down security in detail across different architectures here.

Buzzword definition

Rollup

I have used it beforeMustafaThe following definition of: “A rollup is a blockchain that publishes its blocks to another blockchain and inherits that blockchain’s consensus and data availability (DA).”

The following isJames PrestwichA more general definition is given: Rollup is a way to choose to join another consensus mechanism and retain a superset state through a custom state transition function.

Neither requires a validating bridge, and the ability to build cross-chain bridges with minimal trust assumptions is a key benefit of Rollup, but its critical to analyze them individually.

We can consider the following Rollup criteria:

• Rollup is a stateful system (such as a blockchain) derived by running a custom state transition function (STF) on data input on the main chain (DA layer).

• All input data (i.e. complete transaction data or state differences) used to derive the final confirmed state (i.e. Rollup) of the remote chain is confirmed on the main chain.

• Since the rollup state is derived from the state transition function (STF) run on the data on the main chain, the validity of the rollup depends on the validity of the main chain. Then the Rollup node must fully verify the consensus and validity of the main chain (or make an honest majority assumption about the main chain);

The Rollup node determines the status of the Rollup on the main chain consensus result by applying its own state transition function (STF) (such as the main chain confirms the ordering and availability of data blocks).

Cross-chain bridge

A cross-chain bridge is a system that allows two blockchains to communicate with each other. Chain A (target chain) needs to be convinced that something happened on chain B (source chain), and vice versa. Ideally, we would like this communication to be bidirectional, with strong associated security properties (e.g. high confidence that the message is valid, that the source chain will not be revoked, etc.).

Basically, a cross-chain bridge acts as an observer to another blockchain (just like any other typical human user). A cross-chain bridge implements a given confirmation rule by which it is convinced of the state of the connected chain (e.g. how many Ethereum blocks must pass before a transfer input can be accepted).

• Traditional cross-chain bridges typically run the source chain’s on-chain consensus validator light nodes (i.e. they trust anything signed by a majority consensus);

• Cross-chain bridges can provide stronger security properties by acting as full validator light nodes (i.e. adding Data Availability Sampling (DAS) + Validity/Failure Proof). For example, a chains validators may need to run on all DAS light nodes connected to the chain, which is a more lightweight alternative than requiring validators to run full nodes connected to the chain;

• Rollup cross-chain bridge can also retain the activity and reorganization resistance of the main chain (because Rollup must share the consensus of the main chain);

Bridge from main chain→Rollup

This direction is very simple because the Rollup node will completely verify the main chain.

Rollup nodes know everything that happens on the main chain, so they know when cross-chain bridge transactions occur. Current Ethereum Rollup full nodes must also run full nodes for the Ethereum base layer itself.

Note that Rollup nodes can also be changed to run full validator light nodes of their main chain if supported. Let’s consider a hypothetical example where Ethereum has fully implemented the following upgrade:

• Ethereum executes blocks with validity proofs (zkEVM research on the base layer is ongoing);

• Ethereum has implemented complete DAS, so nodes can sample DA;

• The Ethereum execution layer publishes its data as blobs to the data layer, just like any other Rollup on top of Ethereum (e.g. Celestias execution layer data will be published to its DA layer, so the DAS node will check the Rollup data and Celestia itself availability of the execution layer);

• Ethereum provides full proof of consensus rather than relying on synchronization committees (e.g., through the integration of validators, better signature aggregation, possible proof of ZK consensus, etc.);

Now, assuming you want to run a full node for an Ethereum-based Rollup, to follow a valid Rollup chain, you must understand the Ethereum canonical chain, which requires checking the consensus and validity of Ethereum itself:

• Ethereum’s consensus – any light node client can track the consensus signed as a blockchain, block header;

• Ethereum’s own execution layer DA – Rollup nodes sample Ethereum’s DA layer, checking the availability of Rollup data and Ethereum’s own execution layer data (note that DAS nodes still make some additional assumptions about full nodes , we will see later);

• Ethereum’s own state validity—with zkEVM, every Ethereum block comes with a validity certificate;

Rollup nodes must check the state validity and DA of Ethereums own execution layer, because these are the validity conditions of Ethereum blocks. The Rollup node needs to know that it is not only tracking consensus-signed Ethereum, but also that it is a valid block header. For example, they might accidentally track an Ethereum block that was signed by consensus but invalid (e.g. it generated a large amount of ETH).

If the base execution layer itself publishes its data to the DA layer (just like other rollups) and adds validation or failure proofs, then it becomes a built-in rollup.

From Rollup → Main chain bridge

This direction is tricky because the main chain does not know the status of Rollup and STF by default (that is, Ethereum nodes do not need to run Rollup nodes). In order to make the main chain believe in the status of Rollup, you can implement the logic of Rollup in the smart contract deployed on the main chain (that is, the verification bridge contract of rollup). The smart contract checks the validity of DA and Rollup states.

Again, this cross-chain bridge is optional. Smart contracts on the main chain are used to make all main chain nodes believe in the validity of Rollup, which allows two-way communication under good trust assumptions.

Rollups, Co-processors and Intents

As discussed, Rollups also save some state of their own (the Rollups state) in addition to the state of their main chain (e.g. Ethereums state). So, does CoW Swap have its own state and not be part of the Ethereum state? If so, then it sounds like a Rollup. If not, then it may be a Co-processor.

However, even this problem is not as simple as it seems:

Instead, you might think that the differentiating factor is the persistence of state:

If CoW Swap allows specific participants to provide users with fast pre-confirmations (faster than Ethereums block time) and commit orders that include batch processing - because Ethereums batch processing time is faster than most What the user wants is longer, so is it a Rollup now?

Chris GoesThis topic was discussed in a speech at the Modularity Summit. First, he provided an approximate definition of intentions (Intents): Commitment to a preference function for a given system state space.

Note the similarities between partial resolution (matching intent) and rollup sorting. The operator obtains the users off-chain signed message → publishes the resulting data to the main chain.

• Intent-based applications - the resulting state changes are resolved on-chain (e.g., in the CoW Swap example, the application is on the underlying chain, so the tokens are redeemed there);

• Rollup application - uses data submitted to the main chain to calculate the state changes produced by Rollup;

Intent-centric architecture and Rollup-centric architecture achieve similar goals from opposite directions. The intent-centric approach broadly solves this problem from the user and application perspective, and the rollup-centric approach broadly addresses this problem from the perspective of different blockchains.

Here, setting specific boundaries of distinction is not important. Whats more, we found that Rollup is actually not that different from the apps were used to with off-chain intent matching!

You rely on off-chain participants (sorters vs. solvers/populators, etc.) for some weaker guarantees, such as providing best execution and a good user experience → determining results based on data posted to the main chain. However, they do not keep your funds safe.

As verifiable off-chain computation becomes increasingly important, the line between the two may become blurred:

If you want the intent solver or rollup sorter to be less trusted...

Modular blockchain vs monolithic blockchain

A monolithic blockchain (aka integrated blockchain) is generally defined as a chain that vertically integrates all core functions (i.e. consensus, DA, and execution). They take full responsibility for their own security, with Solana and Cosmos Hub being prime examples.

DA layers (such as Ethereum and Celestia) are often referred to as modular blockchains because they outsource execution to Rollup, but this is not entirely accurate. They are also independently responsible for their own consensus, DA, and execution.

Even Celestias execution will be limited (e.g. transfers, staking, cross-chain). Likewise if someone launches Rollup on top of Solana, it wont magically become a modular blockchain.

So when you hear people refer to chains like Ethereum or Celestia as modular blockchains, realize that this is more of a practical distinction than a strictly technical one. Both are typically optimizing their architecture to support Rollup. These rollups are expected to handle the majority of trade execution within their scope.

Even Rollup is not necessarily completely modular - the Rollup sequencer can reach consensus on transaction ordering, provide DA, and execute transactions before the main chain performs any operations. This is how users get pre-confirmation. The main chain then provides another final commitment, once again stating the DA and consensus on the Rollup transaction sequence.

Rollups and “Integrated Chains”

For our purposes, the more important distinction is rollup or non-rollup. Does the final state of the chain originate from data published to a separate main chain (i.e. the DA layer)?

Although we today associate DAS and validity/failure proof with traditional Rollup, we should note that these are logically different concepts. In theory, any integrated chain (such as a typical Cosmos application chain) can be upgraded to add DAS and validity proofs without publishing its data to other external main chains such as Ethereum. Nodes will individually sample and check proofs of the chain.

Vitalik in his endgame(Endgame) talks about this difference:

You may notice that adding DAS + validity/failure proof to a traditional big blockchain (integrated chain) may end up looking like an enshrined rollup! Similarly, a scalable and dominant rollup may become so successful that it simply merges with its main chain to accommodate the rollup.

The lines of distinction blur at the limit.

Therefore, if you believe that DAS + validity/failure proof is the end result, a rollup of some kind is inevitable. There is a valid difference between the two approaches in the image above:

• Rollups, also known as modularization - build logically independent chains, publish data to its main chain (DA layer), and reuse the consensus of the main chain;

• Integrated blockchain is also known as monolithic blockchain - integrates everything into a protocol with its own consensus, and does not publish data to a separate main chain (even if the DA layer and execution layer are in some sense is a logically independent part of the sharing agreement);

When we discuss Rollup in this report, we will be referring to the former (i.e. not an integrated chain with DAS + validity/failure proof, which might be called a built-in Rollup).

While traditional Rollup doesnt have a monopoly on DAS or proofs (i.e. integrated large blockchains can add them), please note that were ignoring a lot of technical details here, and you cant just pick Solana and decide Oh, I guess we Add DAS today.

This requires a fundamental refactoring of the protocol to start approaching what we see Ethereum and Celestia doing:

Changing the way the data is encoded to support DAS will equate to slowing down the block encoding and propagation speed, starting to be closer to the traditional DA layer:

For this reason, weve seen teams build the following:

• Dedicated DA layer (such as Ethereum’s Danksharding, Celestia, etc.) - slow block + DAS;

• Shared sequencer (e.g. Espresso, Astria or even Solana) - effectively just a fast DA layer, no DAS required;

However, if the timing of fast blocks and DAS is separated, they are not necessarily incompatible. For example, you could imagine a chain like Solana offering two different paths:

• Fast path - continue to execute transactions and propagate data as quickly as possible (just like today);

• Slow path - Encodes data after the fact in a way that can be sampled asynchronously, providing DAS nodes with guarantees that they are slightly behind consensus;

Anatoly on the podcastdiscussLooking at how Eclipse brings together Ethereum, Celestia and Solana, looking at the other end, you can imagine the DA layer adding a faster path before making the data available for sampling:

Providing two paths in the same base layer protocol effectively internalizes fast shared ordering, allowing for interesting designs based on Rollup. Note that this is still a very exploratory idea at this time.

Confirm rules

With this background knowledge in hand, we can now begin to break down the security properties of these different architectures.

First, nodes interact with any blockchain by running Confirmation Rules:

A confirmation rule refers to an algorithm run by a node that outputs whether a certain block is confirmed or not. In this case, under certain assumptions, mainly involving network synchronization and the percentage of honest shares, when these conditions are met, the Blocks are guaranteed to never be reorganized.

There can be any number of validation rules for a given chain:

• How many blocks do you need to wait before a Bitcoin transaction is confirmed? 1 ? 6? 10?

• Do you use LMD GHOST to confirm blocks based on the Ethereum available ledger, or do you wait for the finality gadget (Casper FFG) to confirm?

• Do you run full nodes that directly validate each block, or only light nodes that check consensus signatures?

• Are you just asking Infura?

Since each confirmation rule can make very different assumptions, they can have very different security properties even when interacting with the same chain:

The distinction is subtle but important:

Security = security + activity

Now let’s delve into whether Rollup will “inherit security” from its main chain.

Inheritance, perhaps more clearly, Rollup always rents rather than inherits anything in its main chain, it pays an ongoing cost for the resources (DA) consumed, and either party can choose to end the relationship . But thats not the interesting part of the question.

Security, we will focus on security from now on. The security of the algorithm consists of safety and liveness:

• Safety (nothing bad will happen), the final state determined by two functioning nodes will never conflict;

• Liveness (good things will eventually happen), all functioning nodes will have a limited time to complete reflecting the new state suitable for included transactions;

Excellent using Sreeramframe, we can further decompose them into five properties that together ensure the safety of the confirmation rules:

Lets consider an example of a hypothetical integration chain with DAS + validity/failure proof. Its data is not published to any other external main chain. For simplicity, we assume instant finality (e.g. Tendermint), so there is no usable difference between a usable ledger and a finalized ledger (e.g. Ethereum’s Gasper).

We will consider three confirmation rules that can be used to follow a chain using different types of nodes:

• Consensus Validator Light Node - Validates proof of consensus (i.e. trusts an honest majority consensus).

• Full validator light node - verify consensus + check DA (using DAS) + verify state validity (using validity/failure proof);

• Full node - verify consensus + directly verify DA (download all data) and validity (execute all transactions and calculate status);

Confirm that the rule has security attributes, but the chain does not

To emphasize this point again, we talk colloquially about a chain being secure, but in reality it is the validation rules attached to the security properties.

Lets look at some examples.

CAP theorem

As a background,CAP theoremTell us that no ledger can satisfy both conditions at the same time:

• Adaptivity (aka dynamic availability) - remains active with dynamic participation (i.e. if a majority of nodes are offline);

• Finality (aka consistency) - staying safe under network partitions;

Consensus protocols are often divided into two parts, each of which meets one of the above conditions:

• Longest Chain Protocols - These protocols (e.g. Bitcoins Satoshi Consensus) guarantee liveness even when the number of actively participating nodes is variable (i.e. they are adaptive), however they are not secure under network partitions (i.e. no finality);

• BFT-type protocols - Classic consensus protocols (such as PBFT) achieve finality but not adaptability;

Bitcoin confirmation rules

Bitcoins consensus does not provide any hard economic finality.

Nodes observe the longest chain in their local view, and each user is free to apply any confirmation rules they like (e.g. accept blocks with >k confirmations). The standard is to wait for 6 block confirmations, but its up to you.

For higher value transactions, it makes sense to wait longer. There is a trade-off between waiting time and safety (i.e. the possibility of reorganization).

Ethereum confirmation rules

Ethereums PoS consensus (Gasper) seems to avoid the CAP theorem at first glance. However, it implements both properties because it contains two nested ledgers:

• Dynamically available ledger - secure and active with dynamic participation if the network is not partitioned;

• Finalized prefix ledger - always safe and secure. If the network is not partitioned and enough nodes participate, it remains active;

Gasper belongs to the ebb-and-flow (ebb-and-flow, also known as double ledger or double confirmation rule) protocol family. The dual-ledger design is outside the scope of the CAP theorem (i.e. it assumes a single confirmation rule). When the network partitions, the finalized ledger lags behind the adaptive ledger, but it catches up when the network repairs.

This allows the trade-off between adaptability and finality to be addressed at the user level rather than at the system-wide level. This is a feature of the checkpoint longest chain protocol proposed by the blockchain CAP theorem in allowing users to rely on adaptability and finality. These protocols provide individual users with a choice between finality and adaptability rather than imposing it on the entire system level.

Gasper explicitly exposes two different confirmation rules, mapping to the two ledgers mentioned above:

• Dynamically available rules - guaranteed adaptability. Respect the block header of the longest chain.LMD GHOSTis the fork selection rule used to determine the heaviest subtree;

• Finalization Rules - Guaranteed finality. Respect blocks confirmed by finality gadgets.Casper FFGIt is a final gadget applied to fork selection rules;

As discussed in the paper:

The more optimistic adaptive rule always confirms blocks marked as final by the more conservative rule, and may confirm more blocks during variable participation levels. Clients (users) decide between confirmation rules based on personal preference Local selection is made between blocks, and miners follow fixed block proposal rules consistent with these two confirmation rules.

This allows all (honest) nodes in the system to:

• Follow the common block proposal mechanism;

• But different nodes can choose different confirmation rules;

Validators will continue to extend the longest chain (mining new blocks at ever-increasing heights) regardless of participation, but new checkpoints will only occur when there is sufficient participation.

The longest chain (containing the latest checkpoint) can alternate between different chains (i.e. reorganizing outstanding blocks), but checkpoints are guaranteed to be on a single chain regardless of network conditions (i.e. finality).

Users security depends on the confirmation rules they follow. There is a trade-off between fast block confirmations and stronger security guarantees. A user who sells coffee may prefer activity to security, but a user who sells yachts may prefer safety to activity.

There are also some other intermediate confirmation rule heuristics that Ethereum nodes can apply to practical purposes. Rather than using a naive k blocks as an adaptive confirmation rule like Bitcoin does, we can add other heuristics that include assumptions about network synchronization and validator honesty.

This is exactly what Ethereum consensus protocol confirmation rules》, which proposes confirmation rules with the following properties:

• Under ideal conditions - the rule will confirm new blocks immediately after their slot;

• Under typical mainnet conditions - this rule should be able to confirm most new blocks within a minute;

This confirmation rule is not a substitute for economic finality. Rather, it provides a useful heuristic for users who believe that network synchronization will be maintained in the near future. Lets compare the two:

Lets consider some examples, say you bid to sell a yacht for $2.5 million in ETH. Here are some possible confirmation rules:

• Full nodes + waiting for final results - even a malicious majority of validators cannot trick you into accepting invalid blocks (e.g. generating fake ETH). If they pay you $2.5 million in ETH and then try to reorganize the finalized block later, they will incur huge costs (at least a third of the stake is punitively slashable);

• Full nodes + waiting for a block - most malicious validators still cant trick you into accepting an invalid block, however they can send you $2.5M ETH in a valid block, leave on a yacht, and then the block Immediate reorganization, which is possible if there is sufficient stake weight or poor network conditions, they are not punished by cuts;

• Light Node Client - A malicious sync committee can lie to you with no penalty and the buyer can sail away on a yacht (note that this sync committee is unique to Ethereum as a subset of consensus, others have more PoS chains supported by efficient light node clients can check all consensus votes even with a small number of validators);

• MetaMask - You just trusted Infura, the person you bought the yacht from promised Infura employees they could go on the yacht for the weekend, so they lied to you and you thought you had $2.5 million in ETH, and then you handed it over key;

Rollup confirmation rules

As with any chain, nodes interact with Rollup using different validation rules. Rollups strongest confirmation rules will be finalized together with the consensus of its main chain. The rollup sequencer can expose weaker confirmation rules for a better user experience (i.e. provide fast pre-confirmation for impatient users), but users can also wait for the full security of the main chain confirmation rules.

A typical rollup transaction process is roughly as follows:

• The user submits a transaction to the sequencer;

• The sequencer sorts transactions and gives preconfirmations;

• Deterministic STF is applied to ordered transactions to calculate the new rollup state;

• The updated Rollup status commitment and related transaction data are finally published to the main chain;

After the transaction data is published to the main chain:

• Rollup full node - directly verify whether the proposed chain state is correct;

• Rollup light nodes (including verification bridge) - cannot be directly verified;

• Different observers of the same Rollup use different confirmation rules, so they finalize their opinions at different times:

• Assume full transaction data is published (not just status differences);

• As mentioned previously, Rollup nodes must also run main chain full nodes or full validator light nodes (or use consensus validator light nodes to make honest majority assumptions). Rollup light nodes can run as additional software or implicitly within the main chain node (i.e. the cross-chain bridge contract on the main chain verifies Rollup);

Users can also confirm transactions faster by trusting sequencer pre-confirmation, even before the main chain receives the data. Security can fail if the sequencer misbehaves. Then, once the data is on the main chain (and you have checked DA+ validity), only a main chain failure (such as an Ethereum reorganization) will affect your security.

Therefore, even a centralized sequencer will not really reduce the security of Rollup. You always get security that matches the confirmation rules you need. Whether the rollup has a sequencer-based or other design, you can use the same confirmation rules (such as waiting for the main chain to be finalized and checking the rollup validity). Assuming proper implementation (for example, forcing transaction inclusion via the main chain), you can achieve the same security properties in the same time frame while keeping other things the same.

Likewise, you could imagine Ethereum L1 block producers providing pre-confirmations due to slow block times, which would not make Ethereum any less secure. You just have to decide whether to use another confirmation rule (less secure) until Ethereum validators finalize higher security.

The idea of ​​pre-confirmation fits very well with Gaspers logic as described by Vitalik:

The general principle is that you want to provide users with as much consensus as possible: if there is > 2/3, then we will reach consensus regularly, but if there is< 2/3, then there is no reason to delay and not provide anything, as it is clear that the chain will likely continue to grow despite the temporarily lower security level of new blocks. If an individual application is not satisfied with the lower level of security, it is free to ignore these blocks until they are finalized.

Putting all this together, we have a consistency zone when all confirmation rules agree on the same state of the ledger at the same time:

Confirm Rules - Security and Accessibility

If your confirmation rules are to trust a single sequencer run by SBF instead of trusting a decentralized sequencer composed of the most reputable validators in the world, then you may have worse security, liveness failures, and Reorganization is a safe failure.

Alternatively, you can wait for stronger (main chain) confirmation rules to become available. Then, all else being equal, an untrusted sequencer has no impact on your security. If youre selling coffee, you can probably go right away, but if youre selling a yacht, youll need to double-check the main chain confirmation.

However, we cant completely ignore the potentially lower security of the trust a random person running a separate sequencer validation rule if everyone is actually using it to sell their yachts. Precise design is based on balancing the progressive level of commitment required for a given use case at what time.

Again, this touches on a real criticism of high-throughput blockchains like Solana. What validation rules can people actually use? You may have good security conditions to run a Solana full node, but the confirmation rules may not be accessible to most people (ie, depending on resource requirements and/or cost).

Direct verification (i.e. not just trusting an honest majority) is a core property of these systems. So, for a given validation rule, we really care about two aspects - security and accessibility:

In short:

• Users interact with any chain via confirmation rules;

• A chain can have any number of confirmation rules;

• Security is a property of the validation rules, not the chain itself;

• We care about the security and accessibility of the confirmation rules for a given chain;

In effect, when we say that a given chain is secure, we are trying to convey the notion that its associated confirmation rules are both secure and accessible.

Rollups and integrated chain security

1. Integrated chain with DAS+ validity proof

We now see that security regarding DA and state validity can be directly checked via cryptography (DAS + Validity/Failure Proof) without making strong assumptions about the chains operator. Any protocol can technically implement these. Full nodes can also check DA and state validity without external assumptions.

Now lets focus on other attributes - liveness and resistance to reorganization. As we saw before, these can fail no matter which validation rule you run. Let’s look at an integration chain of DAS+ validity proof+PoS single-slot finality:

Choosing strong confirmation rules is particularly effective against a subset of security failures, where even a majority of malicious validators cannot fool full nodes or full validator light nodes into believing:

• Unavailable data is actually available;

• or invalid state transition is valid;

Whether Ethereum has 1 validator or countless validators, full nodes more or less trust the DA or validity of a block, which they ensure by checking. Full validator light nodes can be checked in a simpler way (but note that DAS makes some additional assumptions, which we will discuss later).

However, a malicious majority validator could prevent the ledger from growing, censor you, or reorganize the chain (which failures occur depends on the confirmation rules). DAS + ZK cant save you. Resistance to reorganization and liveness always depend to some extent on various underlying properties of a given chain (e.g. reliable operators, economic incentives, social consensus, etc.).

What is less obvious is that liveness and resistance to reorganization are still properties of a given confirmation rule, since every node is subject to the same attacks as in the table above. Regardless of the confirmation rules here, they all have the same guarantee.

However, this becomes apparent again when you remove the single-slot finality assumption. In Ethereums Gasper, you will again have different liveness and reorg resistance properties depending on which ledger you follow (i.e. the longest chain ledger available or the checkpoint finalized ledger). Most malicious validators will cause different security failures depending on which validation rules you run.

Regardless, the point is that the underlying construction of the chain is very important here. You need strong operators, economic incentives and social consensus to maintain the activity of the chain and resist reorganization. Additionally, dual-ledger consensus protocols such as Ethereum provide users with valuable flexibility to calculate availability and finality on their own based on their needs.

2. Use DAS + Validity Proof Rollup

Now lets modify this example a little bit:

• Previous example - integrated chain with DAS + proof of validity, imagine taking todays Solana but adding DAS + proof;

• New example - Rollup deployed on an external main chain (e.g. Ethereum) with proof of validity + DAS (note that Ethereum DAS is not yet online), Rollup has a decentralized sequencer set that can achieve fast pre-confirmed consensus ;

Youll notice that Rollup has two completely separate categories of confirmation rules for different timeframes (i.e. whether you operate based on the sequencers pre-consensus or wait for the main chains final consensus), lets look at each path now .

Fast path - before main chain consensus

Rollup nodes can rely on sequencer confirmation (before publishing to the main chain), we assume they can run the following Rollup nodes:

• Rollup consensus validator light node - trusts the honest majority in the Rollup sequencer consensus;

• Rollup full validator light node - runs DAS on the sequencers feed + checks validity proofs before publishing anything to Ethereum;

• Rollup full node - downloads all data from the sequencers feed and executes all transactions to directly check DA and validity;

Technically, a Rollup sequencer could facilitate DAS and provide proof of validity before publishing to the main chain, but in practice this will not happen. Full validator light nodes are typically designed to check these via the main chain, but I assume live DAS+ proofs would allow for a clearer apples-to-apples comparison with the integrated chain.

The following table shows the changes compared to the integration chain example:

• Rely on the Rollup sequencer to achieve liveness and resistance to reorganization, rather than integrating the chains validator set;

• Only the final activity attributes are deleted, because only the time range before the main chain consensus is viewed here (these final activity attributes will come from the main chain later);

Deleted content is shown with a red strikethrough, and added content is shown with a blue line:

Slow path - waiting for main chain consensus

For extra security, nodes can wait for consensus from the main chain (e.g. Ethereum), and this is where it comes into play more clearly, i.e. Rollup nodes should also run main chain nodes:

• Main chain consensus validator light node - trusts the honest majority consensus of the main chain;

• Main chain full validator light node - Check the validity proof of the main chain + run DAS on the main chain (including data Rollup + main chain data);

• Main chain full node - download all main chain data (including checking Rollup data) + execute all main chain transactions to directly check validity;

• Please note that the state validity of a Rollup can be verified via two different paths:

• Outside the main chain (running additional Rollup node software) - Rollup does not need its main chain to verify its state or STF, does not need to deploy a verification bridge, instead the Rollup proof can be checked through another method (such as receiving the Rollup proof through p2p), This requires running additional Rollup node software to verify the proof (i.e. Rollup light node);

• Internal to the main chain (implementing the Rollup node inside the main chain) - This is the norm today. The Rollup light node validator logic is deployed in the main chain itself (that is, Rollups built-in bridge contract). Since this Rollup validator node is in the main chain It runs within the STF, so verifying the STF of the main chain also means verifying the STF of Rollup;

If we get a zero-knowledge proofable main chain (such as Ethereum L1 zkEVM) + all Rollups prove their state inside the main chain → we getVitalik’s vision for proof of singularity. Validating a zero-knowledge proof for Ethereum means validating all other chains and their internally implemented validating nodes:

For simplicity, we assume here that Rollups state validity is verified within the main chain itself (eg Rollup has a built-in bridge to the main chain), so we can ignore the need to explicitly run additional Rollup node software outside of the protocol.

The changes compared to the previous Quick Path Rollup table are as follows:

Achieved by the main chain forcing transaction inclusion or forcing sequencer/certifier replacement, we call it the final activity here, because from the perspective of Rollup, it is a slow path, but from the main chains From a perspective, this can be considered real-time activity.

Rollup and integrated blockchain

Now we can see the security property changes related to integrating blockchain and Rollup:

• DA and state validity - If implemented, DAS + validity proofs can provide applicable security guarantees regardless of whether the chain is integrated or traditional rollup. In fact, these technologies today are dominated by Rollup;

• Liveness Re-org Resistance - The integrated blockchain takes care of these independently in all scenarios. On the contrary, Rollup provides the choice of confirming rules in different time ranges. You can use less secure confirmation rules (trust sequencer consensus) to get fast guarantees, or wait for more secure confirmation rules (wait for main chain consensus);

Activity and resistance to recombination

These properties cannot be cryptographically guaranteed, and you may be vulnerable to security failures even across confirmation rules (e.g. whether running a full node or a light node).

No full node or ZK proof can protect you from a liveness failure or reorganization if the operator completely loses control.

These attributes are achieved through powerful and decentralized operators, censorship-resistant mechanisms, consensus that favors activity, high costs of reorganization, strong social consensus, etc. Comparing these objectively is often challenging.

How do you measure operator decentralization and social consensus? There is no one right answer. These are arguably the most difficult aspects to design, and they are indeed very unique to a given chain.

Importantly, we see that Rollup can delegate reorganization resistance and liveness to the main chain, and the confirmation rules used on Rollup can have the same security properties as if they were run on the main chain in the same time frame.

Chains can even choose which properties to delegate to which chain, and different types of L2 architectures (such as validitys, optimizations, and sidechains) can absorb different subsets of security properties. For example:

• Resistance to reorganization - Rollup may delegate resistance to reorganization to Ethereum, and its fork selection rule is to select the canonical chain based on the content confirmed by the Ethereum consensus. If Ethereum reorganizes, so will Rollup.

• Liveness - However, if Rollup lacks forced inclusion and forced operator replacement mechanisms, Rollup users still will not receive Ethereum’s liveness attributes;

Rollups can also provide users with an escape route out of the Rollup, but retain the ability to censor users and prevent deposits from entering the Rollup (this is how Loopring works, for example). If the deposit is not processed after a period of time, users can withdraw locked funds from the L1 contract.

This highlights the importance of such mechanisms.

Data availability and status validity

Unlike liveness and reorganization resistance, nodes can ensure the validity of DA and state without making any large threshold assumptions (or without making security trade-offs between the two). Malicious majority block producers may cause liveness and reorganization failures, but they will not cause DA or validity failures for full nodes or full validator light nodes.

However, consensus validator light nodes are of course affected by honest majority state validity and DA failure. They just believe everything the consensus says. Thats why DA and state validity are what make security validation rules accessible and really useful. This is often a huge ideological difference between traditional Rollup and larger blockchains that place less emphasis on user verification.

In order, these are generally the preferred methods for balancing security and accessibility:

• Make DAS and proofs of effectiveness widely available;

• If you dont have DAS and/or proof of validity, make the full node widely accessible (i.e. low resource requirements, easy to run, etc.);

• If you dont have DAS and/or validity proofs, and full nodes are basically inaccessible, then make consensus validator light nodes widely accessible and have a trustworthy honest majority consensus;

• Visit Infura;

Note that 2 (full node) is actually the most secure. ZK verification is very simple, but DAS nodes make some additional assumptions that full nodes do not. However, they provide close to the same security as full nodes with a fraction of the resource requirements, and they are scalable.

Full nodes only need to download all data, so there is 100% certainty. Only when everything is there will they sign the block. No assumptions are made about external parties.

The goal of DAS is to achieve security that is almost as good as a full node, with significantly lower resource requirements (i.e. higher scale). This article aboutLight node data availability security levels article covers this very well.

In short, you usually make some assumptions around network synchronicity and whether there are enough nodes to reconstruct the data. If a hostile block producer withholds any data, even a small group of honest light nodes should be able to collectively reconstruct the block. There are also some assumptions about selective share disclosure, where adversarial block producers can individually spoof some small number of light nodes, but not collectively.

These few of N assumptions (e.g., an honest minority of nodes can ensure DAS security) are very favorable compared to the typical rough N/2 assumptions (e.g., 51% of block producers can cause a reorganization). Vitalik is intrust modelTheres a good introduction to this in this post.

In general, DA and state validity are not delegated by Rollup in the same way that liveness and resistance to reorganization are. DA and state validity are directly verifiable by users, while other properties rely more heavily on the chains consensus participants and their incentives.

Let’s review the previous example of verifying the Rollup proof:

• To publish Rollups ZK proof to an Ethereum smart contract, you run an Ethereum full node to implicitly verify the proof;

• Send Rollups ZK certificate to my Rollup light node to directly verify the certificate;

In either case, youre guaranteed effectiveness. No matter where you check, you cant be sure of its validity. Ethereum does not really enforce effectiveness in the same way that Ethereum nodes enforce reorganization resistance or liveness properties. Resistance and vitality depend largely on who you get them from.

Consider a rollup based on a scam chain:

• The fork selection rule of Rollup is to follow the tip of the chain confirmed by the fraud chain → if the fraud chain is reorganized, Rollup will also be reorganized;

• Rollups forced inclusion mechanism and sequencer deletion are enforced through the cross-chain bridge contract on the scam chain → if the scam chains ledger stops, then Rollups ledger will also stop. If the scam chain wants to censor your rollup, then you will be censored;

Rollups are able to expose confirmation rules with the same security properties as their main chain, and they can receive these properties at most as fast as their host chain consensus (in practice, its usually slower depending on how often Rollup publishes to the main chain).

Rollup can also provide happy path looser confirmation rules (i.e. sequencers) for a better user experience, but they retain transaction fallback on failure. If your sequencer is stopped, you can keep moving. However, this is not the case if your chain relies entirely on your own set of validators (i.e. as an integrated chain).

Choosing Rollups main chain wisely will have a specific impact on the security properties. It is especially valuable to utilize a main chain with strong liveness (ledger growth + CR) and resistance to reorganization.

Different security assumptions for different time periods

Lets look at a simple example. Chain X is deciding whether to deploy as a Rollup on the existing main chain or as its own integrated blockchain.

Rollup has the following characteristics:

• 10 seconds block time;

• Can support DAS light nodes

• Can provide high-security confirmation rules regarding liveness and resistance to reorganization (such as decentralized trusted validators, etc.);

Integrated blockchain has the following characteristics:

• The block generation time is 1 second;

• DAS light nodes and validity proofs can be implemented, whether it is launched as an integrated blockchain or as a Rollup;

• Such as implementing a centralized sequencer - it will provide low-safety confirmation rules regarding liveness and resistance to reorganization;

• If you implement your own decentralized consensus (either as a pre-confirmed rollup sequencer set or as an integrated chain validator set), it will provide moderately safe confirmation rules with respect to liveness and resistance to reorganization;

The table below gives a simplified visual representation of the best security guarantees a user might have under various implementations (i.e. they use the strongest confirmation rules available). In particular, we focus here on liveness and recombination resistance (since we assume that the chain will only implement DAS + proof of validity in these two cases):

Rollups ultimate security is higher than its real-time security because the main chain cannot provide us with a guarantee faster than its own block time. Even if you can check that the sequencers pre-acknowledgements are valid state transitions, you cant fully guarantee their finality before they finally reach the DA layer.

But as we have seen, deploying to a strong main chain in a rollup manner can enhance security. They can rent security at the speed of their main chain. Fundamentally, there is no way to obtain all the security attributes of the main chain faster than the consensus of the main chain itself.

However, users are often impatient. Therefore, Rollup will typically provide faster pre-confirmations, but with lower guarantees during this period. Rollup can choose a balanced sequencer design:

• Practical functionality and efficiency. For example, a centralized sequencer can provide fast pre-acknowledgment and reduce operational overhead;

• Strong guarantee. For example, an incredibly decentralized set of sequencers could provide better real-time liveness, but at the cost of higher operational costs and latency (in the most extreme case, you would just let the DA layer handle the rollup Sorting, choose not to expose the faster path);

Interestingly, you could argue that L1 sorted rollups are less lively than centralized sequencers, depending on your time scale. So far, weve discussed liveness, incorporating it into some sort of finite time concept. However, this is entirely relative and subjective. Relative to what? How much time is needed?

A pure L1 sequential rollup will only be included at the rate of L1 chunks (e.g. 10 seconds), and you have no liveness guarantees between those chunks while the world around you is changing. So it depends on your benchmark:

• If baseline = operations inside Rollup, L1 sequential Rollup may provide better liveness. No one else on the chain should be committed until the main chain is confirmed, so you are all on equal footing;

• If Baseline = Operation outside Rollup - Rollup with soft pre-confirmation can provide better liveness. Pre-confirmation is just a free option, you still fall back to main chain guarantees at main chain speeds, but you get weaker guarantees in the meantime. If you dont trust them, just wait for the main chain to confirm. The world does not freeze between Ethereum blocks, and stale prices between long block times may not be acceptable for many applications;

If you try to implement a real based rollup without pre-confirmation, its even possible that pre-confirmation will occur anyway. There is a financial incentive for participants (such as Ethereum builders and validators) to make this commitment themselves. This is exactly why there is discussion about how Ethereum builders and stakeholders are trying to provide fast pre-confirmations at the base layer.

There is one last important note here. Assuming Rollup users can fall back to the same activity as the main chain, assuming you can force inclusion entirely at the speed of main chain blocks (e.g. if the Rollup sequencer is censoring you, you can force inclusion of transactions on main chain next ether square block).

In practice, there is usually a short delay. If you allow immediate forced inclusion, you may expose profitable censorship MEV as well as other complexities. However, there are designs that can provide near real-time liveness guarantees from the main chain (e.g., perhaps at the rate of several main chain blocks instead of one).

Regardless of the exact time scale, absorbing the eventual activity of the main chain is very powerful, and using a strong main chain as a coordination mechanism provides credible threats and exit rights. Merely exposing this credible threat itself makes it extremely unlikely that it would be needed to prevent malicious behavior in the first place.

For example, if users have a reliable mechanism to force quit or even forcefully delete an operator, then a centralized rollup sequencer cannot extract rents from users at will and lock them away. This is Chris Goes aboutMEV conversion costs edge and slow gamingA general area discussed in the presentation.

Of course, unexpected liveness can also occur, in which case this backup path can again be very valuable.

Proofs do not protect the chain, they protect the users

Following all this, we can see that for a given validation rule, it proves more accurate to protect the different observers (users) of the Rollup, rather than protecting the Rollup itself. The security of Rollup does not exist as a single specific measure.

Ensuring the safety of observers is of course paramount, as we are all observers of the chain! The chain is whatever its observer says it is. If you cant observe it in a secure way, you have to trust someone else (such as a validator) to tell you the truth about it. But we don’t want to trust, we want verification → we want evidence.

To understand why it is important to distinguish between a proof protection chain and an observer of the proof protection chain, consider the following:

• Light Nodes - Rollup light nodes are more secure if there is proof, they dont have to trust the validity of anyones word;

• Full Nodes - Rollup full nodes are not more or less secure if they have proofs, you can start a Rollup without a built-in bridge or even any proofs (a pessimistic rollup), and if you start sending validity proofs, full nodes Node security will not increase or decrease;

Proof adds security for chain observers (i.e. light nodes) who cannot directly check its validity. We dont want users to have to run powerful full nodes, so these proofs are important.

Proof of ensuring the safety of the Rollup Bridge

Rollups verification bridge is an extremely important observer! The evidence does ensure the safety of the bridge!

As with any typical light node, the bridge cannot directly check the validity of the rollup. Instead of trusting the honest majority, we protect bridges with evidence. The consensus protocol of Database A (DA layer) sorts the data blobs, and then the verification bridge independently checks the validity of the corresponding updates in Database B (Rollup):

The bridge is an observer of the other chain, and every asset minted by it always comes with the security assumption of the corresponding bridges confirmation rules. The security of its confirmation rules can have wide-ranging impacts. Thats why its so important to build secure bridges (or ideally, reduce the need for so many bridges by further scaling single-chain execution in the first place).

If you run a full node for the chain, a malicious party cannot trick you into accepting an invalid state transition. However, if a malicious party has different confirmation rules, it can still spoof the bridge. If you hold assets backed by collateral in the bridge, your funds may become unbacked. In this sense, security failures in deception bridges are contagious.

Lets consider an old hypothetical scenario about Terra:

• Terra has its own validator set, its native token is LUNA, and can issue native UST;

• Osmosis has its own validator set and its native token is OSMO.

• We have a standard Terra ←→ Osmosis IBC bridge, where each side runs the other chains consensus validator light nodes (i.e. each side of the bridge relies on an honest majority of the other chains validator set);

• You as the user run your own full node for each chain;

• We call the UST on Osmosis bridged through IBC osmoUST;

• We call OSMO on Terra bridged through IBC terraOSMO;

• You have terraOSMO on Terra;

• You are doing LP in the osmoUST/OSMO pool on Osmosis;

As Terra collapses, the price of LUNA plummets, and eventually, in theory, the profits of a malicious validator set will exceed the value of staked LUNA. Terra validators can sign invalid blocks and do the following:

• Mint fake UST → Cross-chain to Osmosis to mint osmoUST, use it to deplete all osmoUST trading pairs (e.g., withdraw all OSMO from the osmoUST/OSMO pool;

• Minting fake terraOSMO → cross-chain to Osmosis to withdraw all native OSMO collateral locked on Osmosis to support terraOSMO, all remaining terraOSMO on Terra will now no longer be supported;

• Well, security fails here:

• Full node (me) - My full node recognizes Terra blocks as invalid and rejects them, Terra validators cannot steal my terraOSMO or osmoUST/OSMO LP positions;

• Light Node (Bridge) - The bridge just checks that Terras consensus signed the blocks (not checking for valid state transitions), so it doesnt reject them, and Terra validators can steal the OSMO collateral backing my terraOSMO, and from osmoUST/OSMO uses up all OSMO in the pool (leaving a bunch of worthless osmoUST behind);

The bridge uses confirmation rules with stronger trust assumptions.

Terra validators cannot steal large amounts of Terras own assets from full nodes (they cannot be tricked) and they will reject these blocks. However, it is possible for validators to spoof consensus validator light clients (including bridges), which is why consensus errors can affect cross-chain assets.

Note that it is important that these failures are not contagious to the rest of the chain, i.e. the failure is contagious to Osmosis assets exposed to the Terra Bridge route, but there is no security failure in the Osmosis chain itself.

However, we obviously want to bridge things (in general, communicate across chains) and it would be bad to be limited to using native assets on their main chain, we need chains to communicate securely and bridge across chains.

As a thought experiment, the simplest solution is to have every user run a full node for each chain, and this includes the cross-chain bridge itself. Keep in mind that weve seen some one-way embedded full-node bridges:

• Ethereum Rollups currently require their nodes to run Ethereum full nodes, and these Rollups share the consensus of Ethereum;

• Namada (a separate Tendermint chain, not the Rollup chain) will require its nodes to run Ethereum full nodes, however Namada does not agree with Ethereums consensus (i.e. it will not publish data to Ethereum or derive its status based on this) ;

This works for Ethereum full nodes, but this obviously doesnt scale. You cant start having every Cosmos chain just run a full node on every other Cosmos chain. These bidirectional full-node bridges dont scale, they just increase the hardware requirements.

Fortunately, there is a more scalable option. We can deploy bridges to fully verify the state validity and DA of another chain (in addition to still checking consensus).

State Validity - While IBC currently works with traditional consensus proofs, it could be modified to add chain-connected validity proofs and now the bridge cannot be fooled by invalid state transitions. This would have prevented exactly the attack described earlier, by rejecting the Terra validators blocks as invalid if the bridge was able to verify the validity of the state transition.

This looks very similar to how the Rollup bridge on Ethereum checks Rollup proofs, except here it can be bidirectional as well.

DA - Additionally, a chain may require its nodes to run DAS light nodes connected to the chain. For example you could have two Cosmos chains require their own validators to run the other chains DAS light nodes (if each chain implements a DAS light client, which those chains currently dont support). With this done, each chain can now know each others validity and DA without having to run a full node.

With Rollup, by definition you own all the data on the main chain, so bridges there can access it. Rollup nodes, on the other hand, run the main chain nodes.

Dependency chain and independent chain

Let’s look at our five security properties again, now in the context of the Rollup Validation Bridge looking at Rollup on Ethereum:

• Ledger growth - Ethereum validators can force Rollups ledger to continue growing (for example, forcing the inclusion of transactions);

• Censorship Resistance - Ethereum validators can force the operator of a Rollup not to be censored indefinitely (e.g. forcing transaction inclusion or sequencer replacement);

• Resistance to reorganizations - Rollups resistance to reorganizations is relevant to Ethereum. If Ethereum reorganizes, then all Rollups on Ethereum will be reorganized;

• Data Availability - Rollups DA is guaranteed because Rollup is by definition derived from data confirmed by the main chain consensus (where the Rollup contract resides), Rollup and the main chain share the merged consensus, and DA is a validity condition of Ethereum itself, so If the data is not available, then the Ethereum block itself is invalid. The bridge can access data on the main chain without adding trust assumptions;

• State Validity - The contract will check the validity proof of the Rollup state transition (or wait for the challenge window to pass), which proves that the declared state update is a valid result of applying Rollups STF on the corresponding data confirmed on the main chain;

Note that the security of a bridge is maximized not just by attaching super-strong confirmation rules to the chain (e.g., a full validator bridge to a chain with a super-trustworthy validator set). If the bridge has the same security assumptions as the main chain, you get maximum security when crossing native assets across chains.

Vitalik provides a helpful illustrative example:

You transfer 100 ETH to a bridge on Solana, get 100 Solana-WETH, and then Ethereum is subject to a 51% attack. The attacker deposits a bunch of his ETH into Solana-WETH, and then immediately after it is confirmed by Solana Resume the transaction on the Ethereum side. The Solana-WETH contract is now no longer fully supported and maybe your 100 Solana-WETH is now only worth 60 ETH. Even with a perfect ZK-SNARK based bridge fully validating consensus, it still Vulnerable to 51% attacks like this.

Therefore, holding Ethereum native assets on Ethereum or holding Solana native assets on Solana is always safer than holding Ethereum native assets on Solana or holding Solana native assets on Ethereum. In this case, Ethereum refers not only to the base chain, but also to any appropriate L2 built on top of it.

If Ethereum is subject to a 51% attack and recovers, Arbitrum and Optimism will also recover, so cross-rollup applications that save state on Arbitrum and Optimism are guaranteed to remain consistent even if Ethereum is subject to a 51% attack. If Ethereum is not subject to a 51% attack, then there is no way to conduct a 51% attack on Arbitrum and Optimism respectively. Therefore, it remains completely safe to hold assets issued based on Arbitrums Optimism.

You can replace Solana with any chain you want - even a hypothetical chain that you trust more than Ethereums validators, basically when youre talking about moving an asset across its ledger of record (e.g. ETH from Ethereum) When chaining, any safety assumptions are additive, and there is always the possibility that a connected chain may reorganize or experience a liveness failure.

However, chains with merged consensus (i.e., rollups that share the consensus of their main chain) can sidestep these additional security assumptions. Cross-chain bridges between these different regions can have the same ultimate activity and recombination resistance properties as the backbone itself. Shared consensus minimizes cross-chain trust assumptions within this shared security zone.

Its up to you to decide what are reasonable security assumptions. In fact, there has never been a similar consensus failure among major chains. This would be obvious and costly, but it may be a stronger assumption for connecting weaker chains.

Binding the Rollup chain to the main chain also has some disadvantages. Let’s compare two cross-chain scenarios, in both cases we have two chains bridged across chains using a two-way full validator:

• Dependency - The remote chain (i.e. Rollup) shares the consensus of the main chain (i.e. DA layer) and derives its own state from the data on the main chain. The remote chain must fork together with the main chain and determine its final state based on the main chain. sex;

• Independent - These chains have their own independent consensus and they do not derive their own state based on data on other chains. They do not share the remote chain (i.e. Rollup) ←→ main chain (i.e. DA layer) relationship. They do not regroup together and do not depend on each others activity;

• Interestingly, there are pros and cons to these:

• Bad - Reorganizing your chain with other chains or having liveness glitches may sound like a disadvantage at first, why would my chain have problems because your chain is broken?

• Good - this is actually an important benefit if this divergence would cause serious problems on your chain (e.g. if you have a large number of cross-chain assets from the source chain, then it would be from your cross-chain bridge perspective to reorganize, leaving unbacked collateral), the chain and its cross-chain bridges need to be consistent with each other;

Likewise, there are potential positive and negative impacts of lock-in and excessive rent-seeking, which highlights why a neutral and censorship-resistant base layer is so important:

• Good - A good main chain can protect Rollup users from Rollup operators extracting too much value from them, thereby enforcing exit permissions;

• Bad - A bad main chain could arbitrarily raise prices and extract that value from Rollup and its users themselves;

• There are also some inefficiencies with proof of submission + running DAS in both directions instead of sharing a common main chain:

• You don’t want to require your nodes to run DAS light nodes on a bunch of other chains and have to add new chains manually, it’s much more efficient to run DAS on a giant shared DA layer;

• It is inefficient for each chain to bidirectionally verify validity proofs for many different chains, however, it is theoretically possible to aggregate proofs across multiple chains so that the entire chain cluster only needs to publish a single proof to the chain;

There are trade-offs and benefits here, but also keep in mind that interesting assets have huge path dependencies where, if you want to use a bunch of Ethereum-native assets (including those in its Rollup), then root your chain in Ethereum and its cross-chain bridges make sense.

in conclusion

Rollups inheritance safety is a good shorthand, but keep in mind these are the key points of what we really mean:

• Rollup pays rent to its main chain (e.g. Ethereum) for the resources it consumes (DA);

• Rollup can expose confirmation rules with security properties as high as those of the main chain (i.e. users can get the same security guarantees as when operating on the main chain itself);

• Users obtain these main chain security attributes at the speed of main chain consensus;

• If Rollup users want faster confirmations than the main chain provides, they can use confirmation rules, which make additional temporary security assumptions;

• Observers (i.e. users) interact with Rollup through confirmation rules. The verification bridge with minimal trust assumptions is such an (optional but very valuable) observer;

Now, consider