20,000 words: The Rollups Security Debate

Originally written by Jon Charbonneau Compiled by Frank, Foresight News

Introduction

Like it or hate it, Twitter will probably never stop arguing about whether "L2" or Rollup is "inherit security."

While most debates are indiscernible semantic battles, if you manage to narrow down the argument, the underlying points are valuable because they touch on the core questions of when, where, and why Rollup makes sense.

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

These debates mainly boil down to security issues. Unfortunately, the definition of "security" here has always been very elusive. We usually use this term casually, and most people know roughly what we're talking about, but not completely. Here we will break down security in detail across different architectures.

Buzzword definition

Rollup

I previously used the following definition of Mustafa: "Rollup is a blockchain that publishes its blocks to another blockchain and inherits the consensus and data availability (DA) of that blockchain".

The following is a more general definition given by James Prestwich: "Rollup is a way to opt in to another consensus mechanism by customizing state transition functions, and preserving superset state."

Neither requires a verification bridge, and the ability to build cross-chain bridges with minimal trust assumptions is a major benefit of Rollup, but analyzing them separately is crucial.

We can consider the following rollup criteria:

• Rollup is a stateful system (e.g. blockchain) derived by running a custom state transition function (STF) on the data input on the main chain (DA layer).
• All input data (i.e. complete transaction data or state differences) used to derive the final confirmation state of the remote chain (i.e. Rollup) is confirmed on the main chain.
• Since the Rollup state is derived from the State Transition Function (STF) that runs on the data on the main chain, the validity of the Rollup depends on the validity of the main chain. The Rollup node must then 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 state of the Rollup on the main chain consensus result (such as the main chain confirming the ordering and availability of data blocks) by applying its own state transition function (STF).

Cross-chain bridge

A cross-chain bridge is a system that allows two blockchains to communicate with each other. Chain A (the target chain) needs to be confident that something has happened on chain B (the source chain) and vice versa. Ideally, we want this communication to be bidirectional, with strongly correlated security attributes (e.g. high confidence that the message is valid, the source chain will not be undone, etc.).

Fundamentally, the cross-chain bridge acts as an "observer" of another blockchain (just like any other typical human user). The cross-chain bridge implements a given confirmation rule by which it is convinced of the state of the connected chain (for example, how many Ethereum blocks must pass to accept transfer inputs).

• Traditional cross-chain bridges typically run on-chain consensus validator light nodes of the source chain (i.e. whatever they trust most consensus signs);
• Cross-chain bridges can provide stronger security attributes by acting as full validator light nodes (i.e. adding Data Availability Sampling (DAS) + Validity/Proof of Failure). For example, a chain's validator may need to run on all DAS light nodes that connect the chain, which is a more lightweight alternative than a full node that requires the validator to run the connected chain;
• Rollup cross-chain bridge can also retain the activity and resistance of the main chain (because Rollup must share the consensus of the main chain);

Bridging from the main chain → Rollup

This direction is very simple, as the Rollup node fully verifies the main chain.

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

Note that Rollup nodes can also run a full validator light node of their main chain instead, if supported. Let's consider a hypothetical example where Ethereum has fully implemented the following upgrades:

• Ethereum execution blocks with proof of validity (zkEVM research at the base layer is ongoing);
• Ethereum has implemented a full DAS, so nodes can sample the DA;
• The Ethereum execution layer publishes its data as blobs to the data layer, just like any other rollup on Ethereum (e.g. Celestia's execution layer data will be published to its DA layer, so DAS nodes will check the availability of Rollup data and Celestia's own execution layer);
• Ethereum provides full proof of consensus instead of relying on synchronization committees (e.g., through the integration of validators, better signature aggregation, possible ZK consensus proof, etc.);

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

• Ethereum consensus - any light node client can track the consensus signed as the 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, as we'll see later);
• Ethereum's own state validity – with zkEVM, each Ethereum block comes with a proof of validity;

Rollup nodes must check the state validity and DA of Ethereum's own execution layer, as these are the validity conditions for Ethereum blocks. The Rollup node needs to know that it not only tracks Ethereum where consensus has been signed, but also that it is a valid block header. For example, they may accidentally track Ethereum blocks that are consensus signed but invalid (e.g. it generates a lot of ETH).

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

Bridge from the Rollup → main chain

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

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

Rollups, Co-processors, and Intents

As discussed, Rollups save some of their own state (Rollup's state) in addition to owning the state of their main chain (e.g. Ethereum). So, does CoW Swap have its own state that is not part of the Ethereum state? If yes, then it sounds like a rollup. If not, then it could be a "co-processor."

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

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

If CoW Swap allows specific participants to provide users with fast pre-confirmations (faster than Ethereum's block time) and promises orders that include batches — since Ethereum batch processing takes longer than most users would like, is it now a rollup?

Chris Goes touched on this topic in his talk at the Modularity Summit, beginning with an approximate definition of intents: "the commitment of a preference function for a given system state space."

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

• Intent-based applications – resulting state changes are resolved on-chain (e.g., in the CoW Swap example, the application is on the underlying chain, so tokens are exchanged there);
• Rollup application – uses the data submitted to the main chain to calculate the state changes generated by Rollup;

Intent-centric architectures and Rollup-centric architectures achieve similar goals from opposite directions. Intent-centric approach addresses this problem broadly from the perspective of users and applications, and Rollup-centric approach addresses this problem broadly from the perspective of different blockchains.

Here, it is not important to set specific distinguishing boundaries. What's more, we found that Rollup is actually not much different from the apps we've become accustomed to with off-chain intent matching!

You rely on off-chain participants (sequencers vs. solvers/fillers, etc.) to get some weaker guarantees, such as providing the best execution and a good user experience → determining the outcome based on the data published to the main chain. However, they do not hold your funds in custody.

As verifiable off-chain computation becomes more important, the lines between the two can become blurred:

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

Modular blockchain and monolithic blockchain

Monolithic blockchains (aka integrated blockchains) are often defined as chains that vertically integrate all core functions, i.e., consensus, DA, and execution. They take full responsibility for their own safety, and Solana and Cosmos Hub are 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 enforcement.

Even the execution of Celestia will be limited (e.g., transfers, staking, cross-chain). Similarly, if someone starts Rollup on top of Solana, it won't 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 often optimizing their own architectures to support Rollup. These rollups are expected to handle most of the trade execution within their scope.

Even Rollup isn't necessarily completely "modular" — the Rollup sequencer can agree on transaction sequencing, provide DA, and execute transactions before the main chain does anything. This is how users get pre-confirmed. The main chain then provides another "final" commitment, again declaring the DA and consensus on the order of Rollup's transactions.

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. DA layer)?

While we today associate DAS and validity/proof of failure with traditional rollups, we should note that these are logically different concepts. In theory, any "integration chain" (such as a typical Cosmos application chain) can be upgraded to add DAS and proofs of validity without having to publish its data to other external mainchains such as Ethereum. The node will sample and check the chain separately.

Vitalik talks about this difference in his Endgame:

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

The boundaries of distinction become blurred at the limit.

Therefore, if you believe that DAS+ effectiveness/proof of failure is the end result, then "Rollup" in a sense is inevitable. There is a valid difference between the two methods in the preceding diagram:

• "Rollups" aka "modularity" - build logically independent chains, publish data to its main chain (DA layer), and reuse the consensus of the main chain;
• "Integrated blockchain" aka "monolithic blockchain" - integrate everything into one protocol with its own consensus, without publishing data to a separate main chain (even if the DA layer and the execution layer are logically separate parts of the shared protocol in a sense);

When we talk about "Rollup" in this report, we are referring to the former (i.e. not an integration chain with DAS + validity/proof of failure, which may be referred to as built-in Rollup).

While "traditional" Rollup doesn't have a monopoly on DAS or proofs (i.e. integrated large blockchains can add them), note that we're overlooking a lot of technical details here, and you can't just pick Solana and decide "Oh, I guess we'll add DAS today".

This requires a fundamental refactoring of the protocol to start getting closer to what we're seeing Ethereum and Celestia doing:

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

For this reason, we see the team build the following:

• Specialized DA layers (e.g. Ethereum's Danksharding, Celestia, etc.) - slow blocks + DAS;
• Shared sequencers (e.g. Espresso, Astria or even Solana) - really just fast DA layers, no DAS required;

However, if you separate the time of fast chunks and DAS, they are not necessarily compatible. For example, you can imagine a chain like Solana offering two different paths:

• Fast path - continue to execute transactions and disseminate data as fast as possible (as it is today);
• Slow path - encode data after the fact in a way that asynchronous sampling can be carried out, providing the assurance that DAS nodes are slightly behind consensus;

Anatoly discusses in the podcast how Eclipse brings Ethereum, Celestia, and Solana together, and from the other end of the spectrum, 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 sorting, providing an interesting design based on Rollup. Note that at the moment this is still a very exploratory idea.

Confirm the rule

With that background, we can now begin to break down the security attributes of these different architectures.

First, nodes interact with any blockchain by running "confirmation rules":

"Confirmation rules refer to the algorithm that is run by a node to output whether a block is confirmed or not. In this case, under certain assumptions, mainly involving the synchronization of the network and the percentage of honest shares, when these conditions are met, the block will be guaranteed that a reorganization will never occur ".

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

• How many blocks do you need to wait before confirming a Bitcoin transaction? 1 ？ 6 ？ 10 ？
• Do you use LMD GHOST to confirm blocks based on the Ethereum usable ledger, or do you wait for the final gadget (Casper FFG) to confirm?
• Do you run full nodes that directly verify each block, or only light nodes that check consensus signing?
• Did you just ask Infura?

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

This distinction is subtle but important:

Security = Security + Activity

Now let's dive into whether Rollup "inherits security" from its main chain.

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

Security, from now on we will focus on security. Security of an algorithm consists of Safety and Liveness:

• Security (nothing bad will happen), the final state determined by two healthy nodes will never conflict;
• Liveness (good things will happen eventually), all healthy nodes will complete a new state reflecting the included transactions within a limited time;

Using Sreeram's excellent framework, we can further break them down into five attributes that work together to secure confirmation rules:

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

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

• Consensus validator light node - verifies proof of consensus (i.e. trusts honest majority consensus).
• Full validator light node - verify consensus + check DA (using DAS) + verify state validity (using validity / proof of failure);
• Full node - verification consensus + direct verification of DA (download all data) and validity (execution of all transactions and calculation of status);

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

Again, "we talk colloquially that a chain is secure, but in fact it is a confirmation rule attached to the security attribute".

Let's look at some examples.

CAP theorem

As background, the CAP theorem tells us that no ledger can satisfy both of these conditions at the same time:

Adaptivity (aka dynamic availability) - staying active with dynamic participation (i.e. if most nodes are offline); Finality (aka consistency) – keeping security under network partitions;

Consensus protocols tend to be divided into two parts, each of which satisfies one of the above conditions:

• Longest chain protocols - these protocols (e.g. Bitcoin's Satoshi Consensus) guarantee activity even when the number of active participating nodes is variable (i.e. they are adaptive), however they are not secure (i.e. not final) under network partitioning; BFT-type protocols - Classic consensus protocols (e.g. PBFT) achieve finality but do not achieve adaptability;

Bitcoin confirmation rules

Bitcoin's 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 rule they like (e.g. accepting blocks with >k confirmations). The standard is to wait for 6 blocks to be confirmed, but it's up to you.

For higher value transactions, it is reasonable to wait longer. There is a trade-off between wait time and security, i.e., the possibility of reorganization.

Ethereum confirmation rules

Ethereum's PoS consensus (Gasper) seems at first glance to sidestep the CAP theorem. However, it implements these two properties because it contains two nested ledgers:

• Dynamically available ledger - if the network is not partitioned, it is safe and active with dynamic participation;
• 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" (also known as double ledger or double confirmation rule) protocol family. The two-ledger design falls outside the scope of the CAP theorem (i.e. it assumes a single confirmation rule). When the network is partitioned, the finalized ledger lags behind the adaptive ledger, but it catches up when the network is repaired.

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 characteristic of the "longest chain of checkpoints" protocol proposed by the blockchain CAP theorem in terms of adaptability and finality that users can rely on. These protocols provide individual users with a choice between finality and adaptability, rather than imposing it at the overall system level.

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

• Dynamically available rules - guaranteed adaptability. Respect the block header of the longest chain. LMD GHOST is a fork selection rule used to determine the heaviest subtree;
• Finalization Rules - Guarantees final certainty. Respect blocks confirmed by final gadgets. Casper FFGs are final gadgets that apply on top of fork selection rules;

As discussed in the paper:

"More optimistic adaptive rules always confirm blocks marked as finalized by more conservative rules, and may confirm more blocks during variable participation levels. Customers (users) choose locally between confirmation rules based on personal preferences, while miners follow fixed block proposal rules that are consistent with these two confirmation rules".

This allows all (honest) nodes in the system:

• Follow a common block proposal mechanism;
• However, different nodes can choose different confirmation rules;

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

The longest chain (containing the most recent checkpoint) can alternate between different chains (i.e. reassemble incomplete blocks), but the checkpoint is guaranteed to be on a single chain regardless of network conditions (i.e. finality).

The security of users depends on the confirmation rules they follow. There is a trade-off between fast block acknowledgement and stronger security guarantees. Users who sell coffee may prefer activity over security, but users who sell yachts may prefer security over activity.

Ethereum nodes can also apply some other intermediate confirmation rule heuristics to practical purposes. Instead of using naïve k blocks as an adaptive confirmation rule, as Bitcoin does, we can add other heuristics that include assumptions about network synchronization and validator honesty.

This is exactly what is proposed in the Ethereum Consensus Protocol Confirmation Rules, which propose confirmation rules with the following properties:

• Under ideal conditions - the rule will confirm a new block immediately after its slot;
• Under typical mainnet conditions - the rule should be able to confirm most new blocks within a minute;

This confirmation rule is not a substitute for economic finality. Instead, it provides useful heuristics for users who believe that network synchronization will remain in the near future. Let's compare the two:

Let's consider some examples, such as if you sell a yacht for $2.5 million in ETH, here are some possible confirmation rules:

• Full node + waiting for the final result – even a malicious majority of validators can't trick you into accepting invalid blocks (e.g. producing fake ETH). If they pay you $2.5 million in ETH and then try to restructure the finalized block later, they will incur a huge cost (at least a third of the equity is punishable cut);
• Full node + wait for a block – most malicious validators still can't trick you into accepting an invalid block, however they can send you $2.5 million in ETH in a valid block, leave on a yacht, and then the block is immediately reorganized, which is possible if there is enough stake weight or poor network conditions, they are not punitively cut;
• Light Node Client – Malicious sync boards can lie to you without penalty and buyers can leave on yacht (note that this sync committee is exclusive to Ethereum as a subset of consensus, other PoS chains with more efficient light node client support can check all consensus votes with a small number of validators);
• MetaMask – You just trust Infura, the person who bought the yacht from you promised the Infura employee that they could take the yacht on the weekend, so they lied to you, you thought you had got $2.5 million in ETH, and then you handed over the keys;

Rollup confirms the rules

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

A typical Rollup transaction flow looks like this:

• The user submits a transaction to the sequencer;
• The sequencer sorts transactions and gives pre-confirmation;
• Deterministic STF should be applied to ordered transactions to calculate the new Rollup state;
• The updated rollup status commitment and related transaction data are finally released to the main chain;

After the transaction data is published to the main chain:

• Rollup Full Node - directly verifies that the proposed chain state is correct;
• Rollup light nodes (including verification bridges) - cannot be verified directly;
• Different observers of the same Rollup use different confirmation rules, so they finalize their point of view at different times:
• Assume the release of complete transaction data (not just state differences);
• As mentioned earlier, Rollup nodes must also run mainchain 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. cross-chain bridge contract verification rollup on the main chain);

Users can also confirm transactions faster by trusting the sequencer to confirm in advance, even before the primary link receives the data. If the sequencer behaves incorrectly, security can fail. Then, once the data is on the main chain (and you've checked the DA+ validity), only a mainchain failure (such as an Ethereum reorganization) will affect your security.

Therefore, even centralized orderers do not really reduce the security of "Rollup". You always get security that complies with the confirmation rules you need. Whether the Rollup has a sequencer-based or other design, you can use the same confirmation rules (e.g. wait for the main chain to be finalized and check the Rollup validity). Assuming proper implementation (e.g., enforcing transaction inclusion via the main chain), you can get the same security attributes within the same timeframe while keeping other conditions the same.

Similarly, you can imagine that Ethereum L1 block producers provide pre-confirmation due to slow block times, which does not make "Ethereum" less secure. You just need to decide whether to use another confirmation rule (less secure) until the Ethereum validator finalizes the higher security.

The idea of preconfirmation fits well with the logic of Gasper described by Vitalik:

The general principle is that you want to provide "as much consensus as possible" to the user: if there is > 2/3, then we reach consensus on a regular basis, but if there is < 2/3, then there is no reason to delay without providing anything, because obviously the chain will continue to grow despite the temporarily lower security level of the new block. If a single application is not satisfied with a lower level of security, feel free to ignore these chunks until they are finalized.

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

Confirm the rule - security and accessibility

If your confirmation rule is to trust a single sequencer run by an SBF, rather than a decentralized sequencer made up of the world's most reputable validators, then your security may be worse, and the active failure and reorganization are security failures.

Alternatively, you can wait for stronger (mainchain) confirmation rules to become available. Then, all else being equal, an untrusted sequencer won't affect your security. If you're selling coffee, you're probably going right away, but if you're selling a yacht, you'll need to double-check the main chain confirmation.

However, if everyone actually uses that confirmation rule to sell their yacht, we can't completely ignore the potentially low safety of the "trust random person running a separate sequencer" confirmation rule. Precise design is based on a balance of the level of progressive commitment required for what time for a given use case.

Again, this touches on real criticism of high-throughput blockchains like Solana. What confirmation rules can people actually use? You may have good security conditions to run Solana full nodes, but most people may not have access to that confirmation rule (i.e., depending on resource requirements and/or cost).

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

In a word:

• Users interact with any chain through confirmation rules;
• A chain can have any number of confirmation rules;
• Security is an attribute of the confirmation rule, not the chain itself;
• We care about the security and accessibility of confirmation rules for a given chain;

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

Rollups with integration chain security

1 , integration chain with proof of validity of DAS+

We are now seeing that security regarding DA and state validity can be checked directly by cryptography (DAS + validity / proof of failure) without making strong assumptions about the operators of the chain. Any protocol can technically implement these. Full nodes can also check DA and state validity without external assumptions.

Now let's focus on other properties - activity and resistance to recombination. As we've seen earlier, these can fail no matter what kind of confirmation rule you run. Let's look at another integration chain that proves the finality of the DAS+ effectiveness of the +PoS single-socket:

Choosing strong acknowledgment rules is particularly effective for a subset of security failures, where even most malicious validators cannot trick full nodes or full validator light nodes into believing that:

• Unavailable data is actually available;
• or invalid state transitions are valid;

Whether Ethereum has 1 validator or countless validators, all nodes more or less believe in the DA or validity of the block, which they are guaranteed by checking. Full validator light nodes can be checked in a simpler way (but note that DAS makes some other assumptions, which we'll discuss later).

However, a malicious majority of validators may prevent the ledger from growing, censoring you, or reorganizing the chain (which failures occur depends on the confirmation rules). DAS + ZK will not save you. Resistance to reorganization and activity always depend to some extent on the various underlying attributes of a given chain (e.g. reliable operators, economic incentives, social consensus, etc.).

Less obviously, activity and resistance to reorganization are still attributes of a given acknowledgement rule, since each node is subject to the same attack as in the table above. Regardless of the confirmation rules here, they have the same guarantee.

However, this becomes apparent again when you remove the single-slot finality assumption. In Ethereum's Gasper, depending on the ledger you follow (i.e. the longest chain ledger or checkpoint available), you will again have different activity and reorganization-resistant properties. Most malicious validators cause different security failures depending on the confirmation rules you run.

In any case, the point is that the underlying construction of the chain is very important here. You need strong operators, economic incentives, and social consensus to keep the chain active and resistant to restructuring. In addition, dual-ledger consensus protocols such as Ethereum provide users with valuable flexibility to calculate availability and finality according to their needs.

2, Proof of Rollup using DAS + validity

Now let's modify this example a bit:

• Previous example - an integration chain with proof of validity of DAS +, imagine taking today's Solana, but adding proof of DAS +;
• New example - Rollup is deployed on an external main chain (e.g. Ethereum) with proof of validity + DAS (note that Ethereum DAS is not yet live), Rollup has a decentralized sequencer set that can reach consensus with fast pre-confirmation;

You'll notice that Rollup has two completely separate types of confirmation rules for different timeframes (i.e. whether you're operating based on the pre-consensus of the sequencer or waiting for the final consensus of the main chain), let's now look at each path.

Fast Path - Before the main chain consensus

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

• Rollup Consensus Validator Light Node - Trust the honest majority in the Rollup sequencer consensus;
• Rollup Full Validator Light Node - runs DAS + on the sequencer's feed to check proof of validity before publishing anything to Ethereum;
• Rollup Full Node - Download all data from the sequencer's feed and execute all transactions to directly check DA and validity;

Technically, the Rollup sequencer can facilitate DAS and provide proof of validity before publishing to the main chain, but this doesn't actually happen. Full validator light nodes are usually designed to check these through the main chain, but I'm assuming that "live" DAS+ proofs can be compared more clearly to the same as the integrated chain.

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

• Rely on the Rollup sequencer for activity and anti-recombination, rather than the validator set of the integrated chain;
• Only removed the final activity attribute, because only the time range before the main chain consensus is viewed here (these "final" activity attributes will be self-owned later in the future);

Deletions are shown with a red strikethrough and additions are shown in blue:

Slow path - Wait for the main chain consensus

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

• Main chain consensus validator light node - trust 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);
• Mainchain full node - download all mainchain data (including checking rollup data) + execute all mainchain transactions to directly check validity;
• Note that the state validity of Rollup can be verified through two different paths:
• Outside the main chain (running additional Rollup node software) - Rollup does not require its main chain to verify its state or STF, does not need to deploy a verification bridge, instead can check the Rollup proof by another method (e.g. receiving the Rollup proof via p2p), which requires running additional Rollup node software to verify the proof (i.e. Rollup light nodes);
• Inside the main chain (implement 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 (i.e. Rollup's built-in bridge contract), since this Rollup validator node runs within the STF of the main chain, validating the STF of the main chain also means verifying the STF of the rollup;

If we get a zero-knowledge proof-proof mainchain (e.g. Ethereum L1 zkEVM) + all rollups prove their state inside the main chain→ we get Vitalik's vision of proof of singularity. A zero-knowledge proof of validating Ethereum means validating all other chains and validating nodes of their internal implementations:

For simplicity, we assume here that the state validity of the rollup is verified within the main chain itself (e.g. the rollup has a built-in bridge with the main chain), so we can ignore explicitly running additional rollup node software outside the protocol.

The changes from the previous Fast Path Rollup table are as follows:

This is achieved by the mainchain forcing transactions to include or imposing sequencer/prover substitution, which we call "final" activity here, because from Rollup's point of view, it is a slow path, but from the perspective of the main chain, this can be considered "real-time" activity.

Rollup with integrated blockchain

Now we can see the changes in security attributes related to integrated blockchain and Rollup:

• DA and state validity - If implemented, DAS+ validity proof can provide applicable security assurances, regardless of whether the chain is integrated or traditional Rollup. In fact, these technologies today are dominated by Rollup; Liveness Re-org Resistance – Integrated blockchains are responsible for these independently across all scenarios. Instead, Rollup offers a choice of confirmation rules within different time frames. You can use less secure confirmation rules (trust sequencer consensus) to get fast guarantees, or wait for more secure confirmation rules (wait for mainchain consensus);

Activity and resistance to recombination

These attributes cannot be guaranteed with a password, and even across acknowledgement rules (for example, whether running a full or light node), you may be vulnerable to security failures.

If the operator is completely out of control, no full node or ZK proof can protect you from activity failures or reorganization.

These attributes are achieved through strong and decentralized operators, censorship-resistant mechanisms, consensus conducive to activity, high "cost" of restructuring, strong social consensus, etc. Objectively comparing these 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 anti-reorganization and activity to the main chain, and that the confirmation rules used on Rollup can have the same security attributes as if they were running on the main chain within the same time frame.

Chains can even choose which attributes to delegate to which chain, and different types of "L2" architectures (such as validiums, optimism, and sidechains) can absorb different subsets of security attributes. For example:

• Anti-restructuring - Rollup may delegate anti-restructuring to Ethereum, and its fork selection rules are based on what the Ethereum consensus confirms to select the "canonical chain". If Ethereum reorganizes, Rollup will reorganize as well.
• Liveness - However, if Rollup lacks a forced inclusion and forced operator replacement mechanism, Rollup users still do not receive Ethereum's liveliness attribute;

Rollup can also provide users with an escape route to exit Rollup, but retain the ability to vet users and prevent deposits from entering Rollup (this is how Loopring works, for example). If the deposit remains unprocessed after a certain period of time, the user can withdraw the locked funds from the L1 contract.

This highlights the importance of such mechanisms.

Data availability and status validity

Unlike activity and anti-recombination, nodes can ensure the validity of DA and state without making any large threshold assumptions (or security trade-offs between the two). Malicious majority block producers may cause activity 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 the state validity of honest majorities and DA failures. They just believe everything the consensus says. That's why DA and state validity are what make security confirmation rules accessible and really work. This is often the huge ideological difference between traditional Rollups and large blockchains that don't place much emphasis on user verification.

In order, these are often the preferred ways to balance security and accessibility:

• Make DAS and proof of effectiveness widely available;
• If you do not have DAS and/or proof of validity, make full nodes widely accessible (i.e. low resource requirements, easy to run, etc.);
• If you do not have DAS and/or proof of validity, and the full node is largely inaccessible, then please make the consensus validator light node widely accessible and have a trustworthy honest majority consensus;
• Visit Infura;

Note that 2 (full node) is actually the most secure. ZK verification is straightforward, but DAS nodes make some additional assumptions that full nodes don't. However, they provide nearly the same security as full nodes, and with resource requirements at a fraction of that, they are scalable.

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

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

In short, you usually make some assumptions around network synchronization and whether there are enough nodes to reconstruct the data. If hostile block producers hide any data, even a small group of honest light nodes should be able to collectively rebuild blocks. There are also assumptions about selective share disclosure, in which hostile block producers can deceive a small number of light nodes individually, but not collectively.

These "N-in-2" assumptions (e.g., an honest minority of nodes can secure DAS) are very advantageous in relation to the typical approximate "N/2" assumption (e.g., 51% of block producers can lead to reorganization). Vitalik has a good introduction to this in his post on the trust model.

Overall, DA and state effectiveness are not "commissioned" by Rollup as activity and recombinant resistance. DA and state validity can be verified directly by the user, while other attributes are more heavily dependent on the consensus participants of the chain and their incentives.

Review an example of a previous validation of the Rollup proof:

• Publish Rollup's proof of ZK to an Ethereum smart contract, where you run an Ethereum full node and implicitly verify the proof;
• Send the ZK proof of Rollup to my Rollup light node to verify the proof directly;

In either case, you can guarantee effectiveness. No matter where you check it, you can't determine its effectiveness. Ethereum does not have the same truly "forced" effectiveness as Ethereum nodes "force" anti-restructuring or active properties. Anti-restructuring and vitality largely depend on who you get them from.

Consider a scam chain-based rollup:

• Rollup's fork selection rules follow the tip of the chain→ If the chain is reorganized, Rollup will also reorganize;
• Rollup's mandatory inclusion mechanism and sequencer deletion are enforced through cross-chain bridging contracts on the scam chain→ If the ledger of the scam chain stops, then so does the ledger of the rollup. If the scam chain wants to censor your Rollup, then you will be censored;

Rollup is able to expose confirmation rules with the same security attributes as their main chain, which they can receive at most at the rate of their host chain consensus (in fact, it will usually be slower, depending on how often Rollup is published to the main chain).

Rollups can also provide "happy path" with more relaxed confirmation rules (i.e., sequencers) for a better user experience, but they retain transaction rollbacks in case of failure. If your sequencer stops, you can continue moving. However, this is not the case if your chain relies entirely on your own set of validators (i.e. as an integration chain).

Choosing Rollup's main chain wisely can have a concrete impact on security attributes. It is especially valuable to leverage a backchain with strong activity (ledger growth + CR) and resistance to reorganization.

Different security assumptions for different time periods

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

Rollup has the following characteristics:

• 10 seconds block time;
• DAS light nodes are supported
• "High security" confirmation rules for activity and anti-reorganization (e.g. decentralized trusted validators, etc.) can be provided;

Integrated blockchain has the following characteristics:

• Block output time is 1 second;
• DAS light node and proof of validity can be implemented, whether it is launched as an integrated blockchain or as a rollup;
• If a centralized sequencer is implemented - it will provide "low safety" confirmation rules about activity and resistance to recombination;
• If it implements its own decentralized consensus (either as a preconfirmed Rollup sequencer set or as an integrated chain validator set), it will provide "medium security" confirmation rules for activity and anti-reorganization;

The following table gives a simplified visual representation of the best security guarantees that users may have under various implementations (i.e., they use the strongest acknowledgment rules available). In particular, we focus here on activity and resistance to recombination (because we assume that the chain will only achieve DAS+ proof of effectiveness in these two cases):

Rollup's "ultimate security" is higher than its "real-time security" because the main chain cannot guarantee us faster than its own block time. Even though you can check that the sequencer's pre-acknowledgements are valid state transitions, you can't fully guarantee their finality until they finally reach the DA layer.

But as we've seen, deploying to a strong mainchain in a rollup fashion enhances 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 tend to be impatient. As a result, Rollup will typically provide faster pre-confirmation, but the guarantee will be lower during this period. Rollup can choose a balanced sequencer design:

• Practical functionality and efficiency. For example, centralized sequencers can provide fast pre-validation and reduce operational overhead;
• Strong guarantee. For example, an incredible set of decentralized sequencers can provide better real-time activity, but at the cost of higher operational costs and latency (in the most extreme case, you simply let the DA layer handle the ordering of the rollup, choosing not to expose the faster path);

Interestingly, you can argue that L1 ordering rollups are less active than centralized sequencers, depending on your time scale. So far, we've talked about activity, including it in some sort of "finite time" concept. However, this is entirely relative and subjective. Relative to what? How much time does it take?

A pure L1 sequential rollup will only be included at the speed of L1 blocks (e.g. 10 seconds), and you have no guarantee of activity between these blocks when the world around you changes. So it depends on your benchmark:

• If baseline = operation inside Rollup, L1 sequential Rollup may provide better activity. No one else on the chain should be promised until the main chain is confirmed, so you are all on an equal footing;
• If baseline = operation outside of Rollup - Rollup with soft prequalification can provide better activity. Pre-confirmation is just a free option, and you still fall back to the main chain guarantee at the speed of the main chain, but you can get a weaker guarantee in the meantime. If you don't trust them, just wait for the main chain confirmation. The world does not freeze between Ethereum blocks, and for many applications, stale prices between long block times may be unacceptable;

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

Here's one last important note. Assuming that Rollup users can fall back to the same level of activity as the main chain, assuming you can force inclusion entirely at the speed of the main chain block (e.g. if the Rollup orderer is reviewing you, you can force transactions to be included in the next Ethereum block of the main chain).

In practice, there is usually a short delay. If you allow immediate mandatory inclusion, you risk exposing profitable censorship MEVs along with other complexities. However, some designs can provide near real-time activity guarantees from the main chain (e.g., perhaps at the speed of several main chain blocks instead of one block).

Regardless of the exact timescale, the ultimate activity of the absorption of the main chain is very strong, and using a strong main chain as a coordination mechanism provides credible threats and exit rights. The mere exposure of this credible threat alone makes it highly unlikely that it will be needed to prevent malicious behavior in the first place.

For example, if the user has a reliable mechanism to forcibly exit or even forcibly remove the operator, then the centralized Rollup sequencer cannot arbitrarily extract rent from the user and lock it in. This is a general area discussed in Chris Goes in his talk on MEV Conversion Cost Edge and Slow Gaming.

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

Proof does not protect the chain, but protects the user

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

Ensuring the safety of the observer is of course the most important thing, because we are all observers of the chain! This chain is whatever its observers say. If you can't observe it in a safe way, you have to trust someone else (such as a verifier) to tell you the "truth" about it. But we don't want to trust, we want verification→ we want proof.

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

• Light nodes - Rollup light nodes are more secure if there is proof, they don't have to trust the validity of anyone's words;
• Full node - if there is a proof, the security of the full node of Rollup will not increase or decrease, you can start Rollup ("pessimistic rollup") without a built-in bridge or even any proof, if you start sending proof of validity, the security of the full node will not increase or decrease;

Proven adds security to chain observers (i.e., light nodes) whose validity cannot be checked directly. We don't want users to have to run powerful full nodes, so these proofs are important.

Attestation secures the Rollup bridge

Rollup's verification bridge is an extremely important observer! The evidence does guarantee the safety of the bridge!

As with any typical light node, the bridge cannot directly check the validity of Rollup. We do not believe in honest majorities, but protect bridges with evidence. The consensus protocol for database A (the DA layer) sorts the data blobs and then verifies that the bridge independently checks the validity of the corresponding update to database B (Rollup):

The bridge is an observer of another chain, and each asset it mints always carries the security assumption of the confirmation rules of the corresponding bridge. The security of its confirmation rules can have wide-ranging implications. That's why it's so important to build secure bridges (or ideally, reduce the need for so many bridges by scaling single-chain execution further in the first place).

If you run full nodes for the chain, malicious parties cannot trick you into accepting invalid state transitions. However, if the malicious party has different confirmation rules, it can still spoof the bridge. If you hold collateral-backed assets in the bridge, then your funds may become unsupported. In this sense, the security failure of the spoofing bridge is "contagious".

Let's consider an old hypothetical scenario about Terra:

• Terra has its own set of validators, its native token is LUNA, and native UST can be issued;
• Osmosis has its own set of validators, and its native token is OSMO.
• We have a standard Terra ←→ Osmosis IBC bridge where each side runs the consensus validator light node of the other chain (i.e. each side of the bridge depends on an honest majority of the other chain's set of validators);
• You run your own full node for each chain as a user;
• We refer to UST on Osmosis bridged over IBC as osmoUST;
• We refer to OSMO on Terra bridged via IBC as terraOSMO;
• You own terraOSMO on Terra;
• You are doing LPs in an osmoUST/OSMO pool on Osmosis;

With the collapse of Terra, the price of LUNA plummets, and eventually, the profit of the set of validators that theoretically becomes malicious will exceed the value of the staked LUNA, and the Terra validator 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., take all OSMO out of osmoUST/OSMO pool;
• Minting fake terraOSMO → cross-chain to osmosis to withdraw all native OSMO collateral locked on Osmosis that supports 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 Terra's consensus is signed on the block (not checking valid state transitions) so it doesn't reject them, Terra validators can steal OSMO collateral supporting my terraOSMO and drain all OSMO from the osmoUST/OSMO pool (leaving a bunch of worthless osmoUST);

The bridge uses acknowledgment rules with stronger trust assumptions.

Terra validators cannot steal large amounts of Terra's own assets from full nodes (they will not be deceived), they will reject these blocks. However, validators can trick consensus validators into light clients (including bridges), which is why consensus errors affect cross-chain assets.

Note that it is important that these faults do not "infect" the rest of the chain, i.e. the fault "infects" Osmosis assets exposed to the Terra bridge route, but there is no security fault in the Osmosis chain itself.

However, we obviously want to bridge things (in general, cross-chain communication), it would be bad to limit ourselves 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 each user run full nodes of each chain, which includes the cross-chain bridge itself. Keep in mind that we've seen some one-way embedded full-node bridges:

• Ethereum rollups currently require their nodes to run Ethereum full nodes, and these rollups share Ethereum's consensus; Namada (a separate Tendermint chain, not a Rollup chain) will require its nodes to run Ethereum full nodes, however Namada disagrees with Ethereum's consensus (i.e. it does not publish data to Ethereum or derive its state based on that);

This works for Ethereum full nodes, but this obviously doesn't scale. You can't start having each Cosmos chain just need to run full nodes for every other Cosmos chain. These bidirectional full node bridges do not scale, they just increase 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 is currently used with traditional proof of consensus, it can be modified to add proof of validity for connecting chains, and now bridges are not spoofed by invalid state transitions. This would have prevented exactly what attack described earlier, and if the bridge was able to verify the validity of the state transition, it would have rejected the Terra validator's block as invalid.

This looks very similar to how the Rollup bridge on Ethereum checks for Rollup proofs, except that it can also be bidirectional.

DA - In addition, a chain may require its nodes to run DAS light nodes that connect the chain. For example, you can have two Cosmos chains that require their own validators to run the other chain's DAS light nodes (if each chain implements DAS light clients, which are not currently supported). Once this is done, each chain can now know each other's validity and DA without having to run full nodes.

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

Dependent and independent chains

Let's look at our five security attributes again, now in the context of observing Rollup's Rollup verification bridge on Ethereum:

• Ledger growth – Ethereum validators can force Rollup's ledger to continue to grow (e.g. force inclusion transactions);
• Censorship resistant - Ethereum validators can force Rollup's operators not to censor indefinitely (e.g. force transaction inclusion or sequencer substitution);
• Anti-restructuring - Rollup's anti-restructuring is related to Ethereum. If Ethereum reorganizes, then all the rollups on Ethereum will be regrouped;
• Data availability - Rollup's DA is guaranteed because Rollup is by definition derived from data confirmed by the main chain consensus (where the Rollup contract is located), Rollup and the main chain share the merge consensus, 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 the Rollup's STF on the corresponding data confirmed on the main chain;

Note that the security of a bridge is not only maximized by super-strong confirmation rules for additional chains (for example, a full validator bridge to a chain with a super-trustworthy set of validators). If the bridge has the same security assumptions as the main chain, you can get the most security when cross-chain native assets.

Vitalik provides a useful illustrative example:

"You transfer 100 ETH to a bridge over Solana and get 100 Solana-WETH, and Ethereum gets 51% attacked. The attacker deposits a bunch of their ETH into Solana-WETH and then resumes the transaction on the Ethereum side as soon as the Solana side confirms it. The Solana-WETH contract is 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 is still vulnerable to a 51% attack like this.

Therefore, it is always safer to hold Ethereum native assets on Ethereum or Solana native assets on Solana than to hold Ethereum native assets on Solana or Solana native assets on Ethereum. In this context, "Ethereum" refers not only to the underlying chain, but also to any appropriate L2 built on it.

If Ethereum is 51% attacked and recovers, Arbitrum and Optimism will also recover, so even if Ethereum is attacked by 51%, "cross-rollup" applications that save state on Arbitrum and Optimism are guaranteed to remain consistent. If Ethereum hadn't been 51% attacked, there would be no way to do a 51% attack on Arbitrum and Optimism, respectively. Therefore, it is still completely safe to hold assets issued by Arbitrum-based Optimism.

You can replace Solana with any chain you want - even a hypothetical chain where you surpass an Ethereum validator in terms of trust, and fundamentally, any security assumptions are additive when you talk about cross-chaining assets with their ledger of record (e.g., ETH from Ethereum), and there is always the possibility of a connected chain reorganizing or activity 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 final activity and anti-recombination properties as the main chain itself. Shared consensus minimizes cross-chain trust assumptions within that shared security zone.

What are reasonable security assumptions is up to you. In fact, there has not been a similar consensus failure between major chains. This would be obvious and costly, but it could be a stronger assumption about connecting weaker chains.

There are also some drawbacks to binding a Rollup chain to the main chain. Let's compare two cross-chain scenarios, in both cases we have two chains that use two-way full validator cross-chain bridging:

• Dependency - the remote chain (i.e. Rollup) shares the consensus of the main chain (i.e. the DA layer) and derives its own state from the data on the main chain, the remote chain must fork with the main chain and determine its finality based on the main chain;
• Independent - These chains have their own independent consensus, they do not derive their own state based on data on other chains. They do not share a remote chain (i.e. Rollup) ←→ main chain (i.e. DA layer) relationship. They do not regroup together and do not depend on each other's activity;
• Interestingly, these are both good and bad:
• Bad - Reorganizing your chain with other chains or having activity failures may sound like a drawback at first glance, why is my chain having problems because your chain is broken?
• Good - if this divergence causes serious problems on your chain, this is actually an important benefit (e.g. if you have a large number of cross-chain assets from the source chain, then it will be reorganized from the perspective of your cross-chain bridge, leaving unbacked collateral), the chain and its cross-chain bridge need to be consistent with each other;

Similarly, lock-ins and excessive rent-seeking have potential positive and negative effects, highlighting why a neutral and censorship-resistant base layer is so important:

• Good - A good mainchain protects Rollup users from Rollup operators squeezing too much value out of them, enforcing exit privileges;
• Bad - Bad backchains may arbitrarily inflate the price and extract that value from Rollup and its users themselves;
• Proof of submission + running DAS in both directions instead of sharing a common main chain also has some inefficiencies:
• You don't want to require your node to run a bunch of DAS light nodes of other chains, and have to manually add new chains, running DAS on a huge shared DA layer is much more efficient;
• It is inefficient for each chain to verify the validity for many different chains, however, it is theoretically possible to aggregate proofs between multiple chains so that the entire chain cluster only needs to publish one proof to the chain;

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

Conclusion

"Rollups inheritance security" is a good shorthand, but remember these are the key points we really mean:

• Rollup pays rent to its main chain, such as Ethereum, for the resources it consumes (DA);
• Rollup can expose confirmation rules with security properties up to 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 to be faster than the confirmation provided by the main chain, they can use confirmation rules, which make additional temporary security assumptions;
• The observer (i.e. the user) interacts with Rollup through confirmation rules, and the verification bridge with the least trust assumption is such an (optional but very valuable) observer;

Now, consider the benefits of deploying Rollup on the integration chain:

User safety - Whether you want to implement any cross-chain bridges or not, Rollups can lease DA from its main chain and reclaim its consensus, which allows Rollup to expose confirmation rules that match the main chain to its users without having to reach its own consensus;

Cross-chain security - Rollup can build cross-chain within the shared security domain of the main chain (i.e. the main chain itself and its Rollup), and its security properties are comparable to operating on the main chain itself;

We should see that this is actually two sides of the same coin, and Rollup just allows the chain to provide confirmation rules, and its security can reach the security of the main chain. Both cross-chain bridges and normal users are observers of chains with given acknowledgment rules. Bridges are perhaps the most important "observers" in these chains because their security has wide-ranging implications.

When we try to create a secure system, we need to care about the security of given confirmation rules as well as their accessibility. If most observers (users) interacting with these chains are out of reach, then security confirmation rules don't help much.

While we today associate DAS and proofs of validity with Rollup, they are logically separate concepts. Any chain can integrate these technologies, and the distinction between what is a rollup or is not a rollup begins to break down at the end game (i.e. for a single integrated rollup, it may have logically separate DA and execution layers under one protocol).

However, the "traditional rollup" and DA layers clearly dominate these verification and scaling technologies today.