User security and cross-chain security are actually two sides of the same coin, and Rollup only allows the chain to provide confirmation rules, and its security can reach the security of the main chain.

Original Title: "Do Rollups Inherit Security?"

Author: Jon Charbonneau

Translation: Frank, Foresight News

Introduction

Whether you like it or not, Twitter may never stop debating whether "L2" or Rollup "inherits security."

While most of the debate is an indistinguishable semantic battle, if you can narrow down the scope of the debate, potential perspectives become very valuable because they touch on the core issues of when, where, and why Rollup makes sense.

Does scalable L2 eliminate the market demand for L1? 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 often use this term casually, and most people roughly know what we are talking about, but not entirely clear. We will here detail security across different architectures.

Popular Definitions

Rollup

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

Here is a more general definition given by James Prestwich: "Rollup is a way to join another consensus mechanism through a custom state transition function and retain a superset state."

Both do not require verification bridges, and the ability to build cross-chain bridging with minimal trust assumptions is the main benefit of Rollup, but analyzing them separately is crucial.

We can consider the following Rollup standards:

• Rollup is a stateful system (e.g., a blockchain) derived by running a custom state transition function (STF) on data inputs on the main chain (DA layer).
• All input data used to derive the final confirmed state (i.e., Rollup) for the remote chain (i.e., complete transaction data or state differences) is confirmed on the main chain.
• Since Rollup's state originates from running a state transition function (STF) on the data on the main chain, the validity of Rollup depends on the validity of the main chain. Then Rollup nodes must fully verify the consensus and validity of the main chain (or make an honest majority assumption about the main chain).

Rollup nodes determine the state of Rollup (e.g., data blocks confirming the order and availability of the main chain) based on the consensus result of the main chain by applying their 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 (target chain) needs to be sure that certain events have occurred on Chain B (source chain), and vice versa. Ideally, we want this communication to be bidirectional, with strong security properties (e.g., high confidence in the validity of messages, source chain will not revoke, etc.).

Fundamentally, a 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, through which it is confident in the state of the connected chain (e.g., how many Ethereum blocks must be accepted for a transfer input).

• Traditional cross-chain bridges typically run light nodes of the source chain's on-chain consensus validators (i.e., they trust anything signed by the majority of consensus).
• Cross-chain bridges can provide stronger security properties by acting as full validator light nodes (i.e., adding data availability sampling (DAS) + validity/fault proofs). For example, validators of the chain may need to run on all DAS light nodes of the connected chain, which is a more lightweight alternative to requiring validators to run full nodes of the connected chain.
• Rollup cross-chain bridges can also retain the liveness and resistance to reorganization of the main chain (as Rollup must share the consensus of the main chain).

From Main Chain Bridging to Rollup

This direction is very simple because Rollup nodes fully verify the main chain.

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

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

• Ethereum executes blocks with validity proofs (zkEVM research is ongoing at the base layer).
• Ethereum has implemented full DAS, so nodes can sample DA.
• Ethereum publishes its data as a blob to the data layer, just like any other Rollup on top of 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 consensus proofs instead of relying on a sync committee (e.g., through validator integration, better signature aggregation, possible ZK consensus proofs, etc.).

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

• Ethereum's consensus—any light node client can track consensus signed as blockchain, block header.
• Ethereum's own execution layer DA—Rollup nodes will 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 will see later).
• Ethereum's own state validity—with zkEVM, every Ethereum block will come with a validity proof.

Rollup nodes must check the state validity and DA of Ethereum's own execution layer because these are the validity conditions of Ethereum blocks. Rollup nodes need to know that they are not only tracking consensus-signed Ethereum but also that it is a valid block header. For example, they might inadvertently track consensus-signed but invalid Ethereum blocks (e.g., it produces a large amount of ETH).

If the base execution layer itself publishes its data to the DA layer (just like any other Rollup) and adds validity or fault proofs, it becomes an embedded Rollup.

From Rollup to Main Chain Bridging

This direction is more tricky because the main chain does not know the state and STF of Rollup by default (i.e., Ethereum nodes do not need to run Rollup nodes). To make the main chain trust the state of Rollup, you can implement the logic of Rollup in a smart contract (i.e., the verification bridge contract) deployed on the main chain. The smart contract checks the validity of DA and Rollup state.

Similarly, this cross-chain bridge is optional. The smart contract on the main chain is used to make all main chain nodes trust the validity of Rollup, allowing bidirectional communication under good trust assumptions.

Rollups, Co-processors, and Intents

As discussed, Rollups not only have their main chain's state (e.g., Ethereum's state) but also retain some of their own state (Rollup's state). So, does CoW Swap have its own state instead of being part of the Ethereum state? If so, it sounds like a Rollup. If not, then it might be a "co-processor."

However, even this issue 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 quick pre-confirmations to users (faster than Ethereum's block time) and promises batch processing of orders—because Ethereum's batch processing time is longer than what most users want—then is it now a Rollup?

Chris Goes discussed this topic at the Modular Summit, where he first provided an approximate definition for "intents": "a commitment to a preference function for a given system state space."

Note the similarity between partial resolution (matching intents) and Rollup ordering. The operator obtains off-chain signed messages from users → publishes result data to the main chain.

• Intent-based applications—resulting state changes are settled on-chain (e.g., in the CoW Swap example, the application is on the base chain, so token exchanges occur there);
• Rollup applications—use data submitted to the main chain to compute state changes produced by Rollup;

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

Here, setting specific differentiation boundaries is not important. What's more important is that we find that Rollup is actually not very different from applications with off-chain intent matching that we are already familiar with!

You rely on off-chain participants (sorters and solvers/fillers, etc.) to obtain some weaker assurances, such as providing optimal execution and a good user experience → determining the results based on data published to the main chain. However, they do not custody your funds.

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

If you want intent solvers or Rollup sorters to be less trusted…

Modular Blockchains vs. Integrated Blockchains

Integrated blockchains, also known as integrated chains, are typically defined as chains that vertically integrate all core functions (i.e., consensus, DA, and execution). They are fully responsible for their own security, with Solana and Cosmos Hub being typical examples.

DA layers (e.g., 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 Celestia's execution is limited (e.g., transfers, staking, cross-chain). Similarly, if someone were to launch Rollup on top of Solana, it would not magically become a "modular" blockchain.

So, when you hear people refer to chains like Ethereum or Celestia as "modular" blockchains, be aware that this is more of a practical distinction rather than a strict technical distinction. Both are typically optimizing their architecture to support Rollup. These Rollups are expected to handle the majority of transaction execution within their scope.

Even Rollup is not necessarily fully "modular"—Rollup sorters can achieve consensus on transaction ordering, provide DA, and execute transactions before the main chain. This is how users obtain pre-confirmations. Then the main chain provides another "final" commitment, once again declaring consensus on DA and the order of Rollup transactions.

Rollups vs. 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)?

While we associate DAS and validity/fault proofs with traditional Rollups today, we should note that these are logically different concepts. In theory, any "integrated chain" (e.g., a typical Cosmos application chain) could be upgraded to add DAS and validity proofs without needing to publish its data to an external main chain like Ethereum. Nodes would sample and verify the chain independently.

Vitalik discussed this distinction in his "Endgame":

You may notice that a "traditional big blockchain" (integrated chain) with added DAS + validity/fault proofs might eventually look like an "enshrined Rollup"! Similarly, "a scalable and dominant Rollup" might become so successful that it simply merges with its main chain.

The distinction boundary becomes blurry at the extremes.

Therefore, if you believe that DAS + validity/fault proofs lead to the final result, then in a sense, "Rollup" is inevitable. There is a valid distinction between the two approaches:

• "Rollups," also known as "modular"—build logically independent chains, publish data to their main chain (DA layer), and reuse the main chain's consensus;
• "Integrated blockchains," also known as "single-piece blockchains"—integrate everything into a protocol with its own consensus, without publishing data to a separate main chain (even though the DA layer and execution layer are logically independent parts shared by the protocol in some sense);

When we discuss "Rollup" in this report, we are referring to the former (i.e., not integrated chains with DAS + validity/fault proofs, which might be called embedded Rollups).

While "traditional" Rollups do not monopolize DAS or proofs (integrated large blockchains can add them), please note that we are ignoring many technical details here. You can't just pick Solana and decide, "Oh, I think we'll add DAS today."

This would require a fundamental protocol reconstruction to start approaching what we see Ethereum and Celestia doing:

Changing the data encoding to support DAS would be equivalent to slowing down block encoding and propagation speed, starting to approach a traditional DA layer:

For this reason, we see teams building the following:

• Dedicated DA layer (e.g., Ethereum's Danksharding, Celestia, etc.) - slow blocks + DAS;
• Shared sequencers (e.g., Espresso, Astria, and even Solana) - essentially just a fast DA layer, without the need for DAS;

However, separating the time for fast blocks and DAS does not necessarily make them incompatible. For example, you can imagine a chain like Solana providing two different paths:

• Fast path - continue to execute transactions and propagate data as quickly as possible (as is done today);
• Slow path - encode the data asynchronously for DAS nodes after the fact, providing slightly delayed assurances behind consensus in a way that can be sampled asynchronously;

Anatoly discussed in a podcast how Eclipse combines Ethereum, Celestia, and Solana. From another perspective, you can imagine the DA layer adding a faster path to make data available for sampling before:

Providing two paths within the same underlying protocol can effectively internalize fast shared sequencing, thus offering interesting designs for Rollup-based systems. Please note that this is still a very exploratory idea.

Confirmation Rules

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

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

"Confirmation rules refer to the algorithm run by nodes to determine whether a block is confirmed. In this case, it primarily involves network synchronization and the percentage of honest stake, under certain assumptions, when these conditions are met, the block will be guaranteed to never be reorganized."

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

• How many blocks do you need to wait for before confirming a Bitcoin transaction? 1? 6? 10?
• Do you use LMD GHOST to confirm blocks based on the available Ethereum ledger, or do you wait for finality gadgets (Casper FFG) to confirm?
• Do you run full nodes that directly verify every block, or do you only run light nodes that check consensus-signed blocks?
• Are you just asking Infura?

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

This difference is subtle but important:

Security = Safety + Liveness

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

"Inheritance," or perhaps more accurately, Rollup always "leases" rather than "inherits" anything from its main chain. It pays a continuous cost for the consumed resource (DA), and either party can choose to end this relationship. But that's not the interesting part of the issue.

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

• Safety (nothing bad will happen) - the final state determined by two normally operating nodes will never conflict;
• Liveness (something good will eventually happen) - all normally operating nodes will complete reflecting the new state containing the included transactions in a finite time;

Using Sreeram's excellent framework, we can further break them down into five properties that together ensure the security of confirmation rules:

Let's consider an example of an assumed integrated chain with DAS + validity/fault proofs. Its data is not published to any other external main chain. For simplicity, we assume immediate finality (e.g., Tendermint), so there is no distinction between available ledgers and finality gadgets (e.g., Gasper) in terms of available ledgers.

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

• Consensus validator light node - verifies consensus proof (i.e., trusts an honest majority consensus).
• Full validator light node - verifies consensus + checks DA (using DAS) + verifies state validity (using validity/fault proofs);
• Full node - verifies consensus + directly verifies DA (downloads all data) and validity (executes all transactions and computes state);

Confirmation rules have security properties, not chains

Again, it is emphasized that "we colloquially talk about a chain being secure, but in reality, it is the confirmation rules that have attached security properties."

Let's look at some examples.

CAP Theorem

As background, the CAP theorem tells us that no ledger can simultaneously satisfy these two conditions:

• Adaptivity (also known as dynamic availability) - maintaining availability under dynamic participation (i.e., if most nodes go offline);
• Finality (also known as consistency) - maintaining safety under network partitions;

Consensus protocols often fall into two categories, each satisfying one of the above conditions:

• Longest chain protocols - These protocols (e.g., Bitcoin's Nakamoto consensus) can guarantee liveness even with a variable number of actively participating nodes (i.e., they are adaptive), but they are not safe under network partitions (i.e., they lack finality);
• BFT-type protocols - Classic consensus protocols (e.g., PBFT) achieve finality but do not achieve adaptivity;

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 prefer (e.g., accepting blocks with > k confirmations). The standard is to wait for 6 block confirmations, but it depends on you.

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

Ethereum Confirmation Rules

At first glance, Ethereum's PoS consensus (Gasper) seems to circumvent the CAP theorem. However, it achieves both properties because it includes two nested ledgers:

• Dynamically available ledger - safe and active under dynamic participation if the network is not partitioned;
• Prefix finality ledger - always safe and reliable. It remains active if the network is not partitioned and there are enough participating nodes;

Gasper belongs to the "ebb-and-flow" (also known as dual-ledger or dual-confirmation rule) protocol family. Dual-ledger design is not within the scope of the CAP theorem (i.e., it assumes a single confirmation rule). When the network is partitioned, the finality ledger lags behind the adaptive ledger, but it catches up when the network is repaired.

This allows for a trade-off between adaptivity and finality at the user level rather than at the system level. This is a feature of the "checkpoint longest chain" protocols proposed in the blockchain CAP theorem, allowing individual users to choose between finality and adaptivity, rather than imposing it at the system level.

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

• Dynamic availability rule - guarantees adaptivity. Respects the block headers of the longest chain. LMD GHOST is used to determine the heaviest subtree for fork selection;
• Finality rule - guarantees finality. Respects the blocks confirmed by the finality gadget. Casper FFG is the finality gadget applied on top of the fork selection rule;

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) make local choices between confirmation rules based on personal preferences, while miners follow fixed block proposal rules consistent with both confirmation rules."

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

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

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

The longest chain (including the latest checkpoint) can alternate between different chains (i.e., reorganize unfinished blocks), but the checkpoint is guaranteed to be on a single chain regardless of network conditions (i.e., finality).

User security depends on the confirmation rules they adhere to. There is a trade-off between fast block confirmation and stronger security guarantees. Users selling coffee may prefer liveness over security, while users selling yachts may prefer security over liveness.

Ethereum Confirmation Heuristics

Ethereum nodes can also apply some other intermediate confirmation rule heuristics for practical use. Instead of using a naive k-block confirmation rule like Bitcoin, we can add other heuristic approaches, including assumptions about network synchronization and validator honesty.

This is what is proposed in the "Ethereum PoS Confirmation Rule" paper, which proposes confirmation rules with the following properties:

• Under ideal conditions - the rule should confirm new blocks immediately after their slot;
• Under typical mainnet conditions - the rule should be able to confirm most new blocks within one minute;

This confirmation rule cannot replace economic finality. Instead, it provides a useful heuristic for users who believe that network synchronization will be maintained in the near future. Let's compare the two:

Examples of Confirmation Rules

Let's consider some examples. If you are selling a yacht for 2.5 million USD worth of ETH, here are some possible confirmation rules:

• Full node + waiting for finality - Even a malicious majority of validators cannot deceive you into accepting invalid blocks (e.g., producing fake ETH). If they pay you 2.5 million USD worth of ETH and then attempt to reorganize the finality-confirmed block later, they will incur significant costs (at least one-third of the stake is subject to punitive slashing);
• Full node + waiting for one block - Most malicious validators still cannot deceive you into accepting invalid blocks, but they can send you 2.5 million USD worth of ETH in a valid block, sail away on the yacht, and then that block immediately reorganizes. This is possible if there is enough stake weight or poor network conditions, and they are not subject to punitive slashing;
• Light client - A malicious sync committee can lie to you without any penalty, and the buyer can sail away on the yacht (note that this sync committee as a subset of the consensus is unique to Ethereum; other PoS chains with more efficient light client support can check all consensus votes with fewer validators);

Rollup Confirmation Rules

Like any chain, nodes interact with Rollup using different confirmation rules. The strongest confirmation rules for Rollup will ultimately determine finality with its main chain's consensus. Rollup sequencers can expose weaker confirmation rules for a better user experience (i.e., providing fast pre-confirmations for impatient users), but users can also wait for the full security of the main chain's confirmation rules.

The typical process for Rollup transactions is roughly as follows:

1. Users submit transactions to the sequencer;
2. The sequencer orders the transactions and provides pre-confirmations;
3. The deterministic STF is applied to the ordered transactions to compute the new Rollup state;
4. The updated Rollup state commitment and related transaction data are eventually published to the main chain;

After the transaction data is published to the main chain:

• Rollup Full Node - directly verifies the proposed chain state for correctness;
• Rollup Light Node (including the verification bridge) - cannot verify directly;

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

1. Assuming complete transaction data is published (not just state differences);
2. As mentioned earlier, Rollup nodes must also run a full main chain node or a full validator light node (or make an honest majority assumption using a consensus validator light node). Rollup light nodes can run as additional software or implicitly within main chain nodes (i.e., cross-chain bridge contracts on the main chain verify Rollup);

Users can also confirm transactions faster by trusting pre-confirmations from the sequencer, even before the main chain receives the data. If the sequencer behaves improperly, security may fail. Once the data is on the main chain (and you have checked DA + validity), only main chain failures (e.g., Ethereum reorgs) would affect your security.

Therefore, even with a centralized sequencer, the security of "Rollup" is not truly compromised. You always get security according to the confirmation rules you require. Whether Rollup is based on a sequencer or other designs, you can use the same confirmation rules (e.g., wait for main chain finality and check Rollup validity). If correctly implemented (e.g., by enforcing transaction inclusion on the main chain), you can achieve the same security properties within the same timeframe, while keeping other conditions the same.

Similarly, you can imagine that Ethereum L1 block producers providing pre-confirmations due to slow block times would not compromise the security of "Ethereum". You just decide whether to use a different confirmation rule (with lower security) until Ethereum validators finalize higher security.

The idea of pre-confirmations aligns well with the logic of Gasper as described by Vitalik:

The general principle is that you want to provide "as much consensus as possible" to users: if there is > 2/3, then we will regularly reach consensus, but if there is 2/3, then there is no reason to delay and not provide anything, because obviously while the security level of the new block is temporarily lower, the chain is still likely to continue growing. If a particular application is not satisfied with the lower level of security, it can freely ignore these blocks until they are finalized.

Putting all this together, when all confirmation rules simultaneously converge on the same state of the ledger, we have a "consistency zone":

Confirmation Rules - Security and Accessibility

If your confirmation rule is to trust a single sequencer operated by SBF, rather than trusting a decentralized sequencer composed of the most reputable validators in the world, your security may be lower, with liveness failures and reorgs being security failures.

Alternatively, you can wait for stronger (main chain) confirmation rules to become available. Then, under the same conditions, the untrusted sequencer would not affect your security. If you're selling coffee, you might want to leave immediately, but if you're selling a yacht, you need to carefully check the main chain confirmation information.

However, if everyone actually uses that confirmation rule to sell their yachts, we cannot completely ignore the potential lower security of the "trust a randomly chosen individual to operate a single sequencer" confirmation rule. Precise design is about balancing the progressive commitment level required for a given use case at a given time.

Similarly, this also touches on the real criticism of high-throughput blockchains like Solana. What confirmation rules can people actually use? You might have good security conditions for running a full Solana node, 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 an honest majority) is a core property of these systems. Therefore, for a given confirmation rule, what we really care about are two aspects - security and accessibility:

In summary:

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

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

Security of Rollups vs. Integrated Chains

1. Integrated Chain with DAS+ Validity Proofs

We now see that the security of DA and state validity can be directly checked through cryptographic techniques (DAS + validity/fault proofs), without strong assumptions about the operation 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 - liveness and resistance to reorgs. As we've seen before, these can fail regardless of which confirmation rule you run. Looking at an integrated chain with DAS+ validity proofs and PoS single-slot finality:

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

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

Whether Ethereum has 1 validator or countless validators, full nodes more or less trust the block's DA or validity, which they are assured of through verification. Full validator light nodes can verify in a simpler manner (but note that DAS makes some other assumptions, which we will discuss later).

However, a majority of malicious validators may prevent ledger growth, censor you, or reorganize the chain (which failures occur depends on the confirmation rule). DAS + ZK won't save you. Resistance to reorgs and liveness to some extent always depend on various underlying properties of a given chain (e.g., reliable operators, economic incentives, social consensus, etc.).

Less obvious is that liveness and resistance to reorgs are still properties of a given confirmation rule, as each node is subject to the same attacks as in the table above. Regardless of the confirmation rules here, they all have the same guarantees.

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 dynamically available longest chain ledger or the checkpoint finality ledger), you will once again have different liveness and resistance to reorgs properties. A majority of malicious validators would cause different security failures, depending on the confirmation rule you run.

Regardless, the underlying construction of the chain is crucial here. You need strong operators, economic incentives, and social consensus to maintain the liveness and resistance to reorgs of the chain. Additionally, dual ledger consensus protocols like Ethereum provide valuable flexibility to users to calculate availability and finality according to their own needs.

2. Using DAS + Validity Proofs for Rollup

Now let's slightly modify this example:

• In the previous example - an integrated chain with DAS + validity proofs, imagine using today's Solana, but adding DAS + proofs;
• New example - Rollup deployed on an external main chain (e.g., Ethereum), with validity proofs + DAS (note that Ethereum DAS is not yet live), Rollup has a decentralized sequencer set that can achieve fast pre-confirmations consensus;

You will notice that Rollup has two completely independent confirmation rules for different timeframes (i.e., regardless of whether you operate based on sequencer pre-consensus or wait for main chain final consensus). Let's now look at each path.

Fast Path - Before Main Chain Consensus

Rollup nodes can rely on sequencer confirmations (before being published to the main chain), assuming they can run the following Rollup nodes:

• Rollup consensus validator light node - trust an honest majority in the Rollup sequencer consensus;
• Rollup full validator light node - run DAS + check validity proofs on the sequencer's feed 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 validity proofs before publishing to the main chain, but in practice, this does not happen. Full validator light nodes are typically designed to check these through the main chain, but I assume "real-time" DAS + proofs can provide a clearer comparison with integrated chains.

The table below shows the changes compared to the integrated chain example:

• Relying on Rollup sequencer for liveness and resistance to reorgs, instead of the integrated chain's validator set;
• Only removing the final liveness attribute, as we are only looking at the timeframe before main chain consensus (these "final" liveness attributes will come from the main chain later);

Changes are shown in red strikethrough for removal and in blue for additions:

Slow Path - Waiting for Main Chain Consensus

For additional security, nodes can wait for main chain (e.g., Ethereum) consensus, which is where it becomes clearer that Rollup nodes should also run main chain nodes:

• Main chain consensus validator light node - trust the honest majority consensus of the main chain;
• Main chain full validator light node - check validity proofs on the main chain + run DAS on the main chain (including Rollup data + 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;

Note that Rollup's state validity can be verified through two different paths:

• External to 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, and instead can check Rollup proofs through another method (e.g., receiving Rollup proofs via p2p), which requires running additional Rollup node software to verify the proofs (i.e., Rollup light node);
• Internal to the main chain (implementing Rollup nodes within the main chain) - this is the current norm, where Rollup light node validator logic is deployed within the main chain itself (i.e., Rollup's built-in bridge contract), and since this Rollup validator node runs within the main chain's STF, verifying the main chain's STF also means verifying Rollup's STF;

If we get a zero-knowledge proof main chain (e.g., Ethereum L1 zkEVM) + all Rollups prove their state internally on the main chain → we get Vitalik's vision for a singularity proof. Verifying a zero-knowledge proof for Ethereum means verifying all other chains and their internally implemented validator nodes:

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

Changes compared to the previous "fast path" Rollup table are as follows:

Implemented through main chain enforced transaction inclusion or enforced sequencer/verifier replacement, we call this "final" liveness here, as from the perspective of Rollup, it is a slow path, but from the perspective of the main chain, this can be seen as "real-time" liveness.

Rollup vs. Integrated Blockchain

Now we can see the changes in security properties related to integrated blockchains and Rollups:

• 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 are now primarily focused on Rollups;
• Liveness and resistance to reorgs - integrated blockchains are independently responsible for these in all scenarios. In contrast, Rollup provides a choice of confirmation rules for different timeframes. You can adopt less secure confirmation rules (trust sequencer consensus) for quick assurances, or wait for more secure confirmation rules (wait for main chain consensus);

Liveness and Resistance to Reorgs

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

If the operators are completely out of control, no full nodes or ZK proofs can protect you from liveness failures or reorgs.

These properties are achieved through strong and decentralized operators, resistance to censorship, consensus conducive to liveness, high "cost" of reorgs, and strong social consensus. Objectively comparing these is usually challenging.

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

Importantly, we see that Rollup can delegate resistance to reorgs and liveness to the main chain, and the confirmation rules used on Rollup can have the same security properties, just as if they were running on the main chain at the same timeframe.

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

• Resistance to Reorgs - Rollup may delegate resistance to reorgs to Ethereum, and its fork choice rule is based on the content confirmed by Ethereum consensus to select the "canonical chain." If Ethereum reorgs, Rollup will also reorg.
• Liveness - However, if Rollup lacks mechanisms for forced inclusion and operator replacement, Rollup users still won't receive Ethereum's liveness attributes;

Rollup can also provide users with an exit ramp from Rollup, while retaining the ability to censor users and prevent deposits from entering Rollup (this is how Loopring works, for example). If a deposit remains unprocessed for a period of time, users can extract locked funds from the L1 contract.

This highlights the importance of such mechanisms.

Data Availability and State Validity

Unlike liveness and resistance to reorgs, nodes can ensure the validity of DA and state without making any major threshold assumptions (or without needing to make security trade-offs between the two). Malicious majority block producers may cause liveness and reorg failures, but they won't cause full nodes or full validator light nodes to fail in terms of DA or validity.

However, consensus validator light nodes will certainly be affected by the failure of state validity and DA by an honest majority. They simply trust everything the consensus says. This is why DA and state validity make secure confirmation rules easily accessible and truly effective. This is often a significant ideological difference between traditional Rollup and large blockchains that do not prioritize user verification.

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

1. Make DAS and validity proofs widely available;
2. If you don't have DAS and/or validity proofs, make full nodes widely accessible (i.e., low resource requirements, easy to run, etc.);
3. If you don't have DAS and/or validity proofs, and full nodes are essentially inaccessible, then make consensus validator light nodes widely accessible and have a trusted honest majority consensus;
4. Access Infura;

Note that 2 (full nodes) 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 nearly the same security as full nodes, with resource requirements being only a fraction, and they are scalable.

Full nodes simply download all data, so they have 100% certainty. They only sign off on blocks when everything is there. No assumptions are made about external parties.

The goal of DAS is to achieve nearly the same level of security as full nodes while significantly reducing resource requirements (i.e., higher scalability). This article on security levels for data availability for light nodes covers this point well.

In summary, you typically make some assumptions around network synchrony and whether there are enough nodes to reconstruct the data. If adversarial block producers withhold any data, even a small number 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 deceive a small number of light nodes individually, but not collectively.

These "N among the minority" assumptions (e.g., honest minority 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 reorg). Vitalik's post on the trust model provides a good explanation of this.

Overall, DA and state validity are not "delegated" by Rollup as much as liveness and resistance to reorgs. DA and state validity can be directly verified by users, while the other properties depend more heavily on the consensus participants of the chain and their incentives.

Recapping the previous example of verifying Rollup proofs:

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

You can guarantee validity in either case. You cannot determine its validity wherever you check. Ethereum does not "force" validity in the same way it "forces" resistance to reorgs or liveness. Resistance to reorgs and liveness largely depend on where you get them from.

Consider a Rollup based on a fraudulent chain:

• Rollup's fork choice rule follows the chain tip confirmed by the fraudulent chain → if the fraudulent chain reorgs, Rollup will also reorg;
• Rollup's forced inclusion mechanism and sequencer deletion are enforced through a cross-chain bridge contract on the fraudulent chain → if the ledger of the fraudulent chain stops, then the ledger of Rollup also stops. If the fraudulent chain wants to censor your Rollup, then you will be censored;

Rollup can publicly offer confirmation rules with security properties similar to its main chain, and they can receive these properties at most at the speed of their main chain consensus (in practice, it is often slower, depending on the frequency of Rollup's publication to the main chain).

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

Wisely choosing Rollup's main chain will have a concrete impact on its security properties. Leveraging a main chain with strong liveness (ledger growth + CR) and resistance to reorgs is particularly valuable.

Different Security Assumptions for Different Timeframes

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:

• Block time of 10 seconds;
• Supports DAS light nodes
• Can provide "high-security" confirmation rules regarding liveness and resistance to reorgs (e.g., decentralized trusted validator, etc.);

The integrated blockchain has the following characteristics:

• Block time of 1 second;
• Can implement DAS light nodes and validity proofs, whether it is launched as an integrated blockchain or as a Rollup;
• If implementing a centralized sequencer - it will provide "low-security" confirmation rules regarding liveness and resistance to reorgs;
• If implementing its own decentralized consensus (as a pre-confirmed Rollup sequencer set or as an integrated chain validator set), it will provide "medium-security" confirmation rules regarding liveness and resistance to reorgs;

The table below provides a simplified and intuitive representation of the best security guarantees users may have under various implementations (i.e., using the strongest available confirmation rules). Specifically, we focus on liveness and resistance to reorgs (as we assume that the chain will only implement DAS + validity proofs in both cases):

The "final security" of Rollup is higher than its "real-time security" because the main chain cannot provide assurances faster than its own block time. Even if you can check whether the sequencer's pre-confirmation is a valid state transition, you cannot fully guarantee its finality until it reaches the DA layer.

But as we have seen, deploying in a Rollup fashion to a powerful main chain can enhance security. They can rent security at the speed of their main chain. Essentially, there is no way to obtain the full security properties of the main chain at a faster speed than the main chain's own consensus.

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

• Practicality and efficiency. For example, a centralized sequencer can provide fast pre-confirmations and reduce operational expenses;
• Strong guarantees. For example, an incredibly decentralized sequencer set can provide better real-time liveness, but at the cost of higher operational expenses and latency (in the most extreme case, you simply let the DA layer handle Rollup sequencing, choosing not to expose a faster path);

Interestingly, you can consider the liveness of L1 sequencing Rollup to be worse than that of a centralized sequencer, depending on your time scale. So far, we have discussed liveness, incorporating it into some concept of "finite time." However, this is entirely relative and subjective. Relative to what? How much time is needed?

Simply L1 sequencing Rollup will only include at the speed of L1 blocks (e.g., 10 seconds), and you have no liveness guarantees between these blocks as the world around you changes. So it depends on your benchmark:

• If benchmark = operations within Rollup, L1 sequencing Rollup may provide better liveness. Others on the chain should not get commitments before main chain confirmation, so you are all on equal footing;
• If benchmark = operations outside Rollup - Rollup with soft pre-confirmations can provide better liveness. Pre-confirmations are just an optional freebie, and you still roll back to the main chain at the speed of the main chain's guarantees, but during this time, you can get weaker guarantees. If you don't trust them, just wait for main chain confirmation. The world doesn't freeze between Ethereum blocks, and the stale prices between long block times may be unacceptable for many applications;

If you try to achieve a "true" Rollup without pre-confirmations, it is even possible that pre-confirmations will occur regardless. For participants (e.g., Ethereum builders and validators), there is an economic incentive for them to make this commitment themselves. This is why some are discussing how Ethereum builders and stakeholders are trying to provide fast pre-confirmations at the base layer.

Here's one final important note. Assuming Rollup users can roll back to the same liveness as the main chain, assuming you can forcibly include at the speed of main chain blocks (e.g., if the Rollup sequencer is front-running you, you can force the transaction to be included in the next Ethereum block).

In practice, there is usually a short delay. If you allow immediate forced inclusion, you may expose profitable front-running MEV and other complexities. However, some designs can provide near-real-time liveness guarantees from the main chain (e.g., at the speed of a few main chain blocks instead of one block).

Regardless of the exact time scale, absorbing the final liveness of the main chain is very powerful, providing a trusted threat and exit right using a powerful main chain as a coordination mechanism. Simply exposing this trusted threat itself makes it highly unlikely to be needed and prevents malicious behavior from the start.

For example, if users have a reliable mechanism to forcibly exit or even forcibly remove operators, then a centralized Rollup sequencer cannot arbitrarily extract rent from users and lock it up. This is a general area discussed in Chris Goes' talk on MEV extraction cost edges and slow games.

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

Proofs protect the observers of the chain, not the chain itself

Following all of this, we can see that for a given confirmation rule, proofs protect the different "observers" (users) of Rollup more accurately than they protect "Rollup" itself. The security of "Rollup" does not exist as a single concrete measure.

Ensuring the security of observers is certainly the most important, as we are all observers of the chain! The chain is whatever its observers say it is. If you cannot observe it securely, you have to trust others (e.g., validators) to tell you its "truth." But we don't want to trust, we want to verify → we want evidence.

To understand why it is important to distinguish between "proofs protecting the chain" and "proofs protecting the observers of the chain," consider the following:

• Light nodes - If there are proofs, Rollup light nodes are more secure, as they do not have to trust anyone's word for the validity of transactions;
• Full nodes - If there are proofs, the security of Rollup full nodes does not increase or decrease. You can launch Rollup without built-in bridges or any proofs ("pessimistic rollup"), and if you start sending validity proofs, the security of full nodes does not increase or decrease;

Proofs increase the security of chain observers (i.e., light nodes) who cannot directly check the validity of the chain. We do not want users to have to run powerful full nodes, so these proofs are important.

Proofs ensure the security of Rollup bridges

The verification bridge of Rollup is an extremely important observer! The evidence indeed ensures the security of the bridge!

Like any typical light node, the bridge cannot directly check the validity of Rollup. We protect the bridge with evidence, not trusting an honest majority. The consensus protocol of database A (DA layer) orders the data blob, and then the bridge independently checks the validity of the corresponding updates to database B (Rollup):

The bridge is an observer of another chain, and every asset it mints always carries the security assumptions of its corresponding bridge's confirmation rules. The security of its confirmation rules can have broad implications. This is why establishing secure bridges is so important (or ideally, reducing the need for so many bridges by further extending single-chain execution first).

If you run a full node for the chain, malicious parties cannot trick you into accepting invalid state transitions. However, if malicious parties have different confirmation rules, they can still deceive the bridge. If you hold assets supported by collateral in the bridge, your funds may become unsupported. In this sense, security failures of deceiving the bridge are "contagious."

Let's consider an old hypothetical scenario about Terra:

• Terra has its own set of validators, its native token is LUNA, and it can issue native UST.
• 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 a light client of the consensus of the other chain (i.e., each side of the bridge relies on an honest majority of the other chain's validators).
• You run your own full node for each chain as a user.
• The UST bridged to Osmosis via IBC is called osmoUST.
• The OSMO bridged to Terra via IBC is called terraOSMO.
• You hold terraOSMO on Terra.
• You are providing liquidity in the osmoUST/OSMO pool on Osmosis.

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

• Mint fake UST → bridge to Osmosis to mint osmoUST, use it to drain all OSMO from the osmoUST/OSMO pool (e.g., remove all OSMO from the osmoUST/OSMO pool).
• Mint fake terraOSMO → bridge to Osmosis to withdraw all native OSMO collateral supporting terraOSMO locked on Osmosis, leaving all remaining terraOSMO on Terra unsupported.

In this case, security fails as follows:

• Full node (me) - My full node will identify Terra blocks as invalid and reject them, preventing Terra validators from stealing my terraOSMO or osmoUST/OSMO LP position.
• Light client (bridge) - The bridge only checks if Terra's consensus is signing the blocks (does not check for valid state transitions), so it will not reject them. Terra validators can steal the OSMO collateral supporting my terraOSMO and drain all OSMO from the osmoUST/OSMO pool (leaving a pile of worthless osmoUST).

The bridge uses confirmation rules with a stronger trust assumption.

Terra validators cannot steal a large amount of assets from Terra itself (they will not be deceived) as they will reject these blocks. However, validators may deceive the consensus validator light client (including the bridge), which is why consensus errors affect cross-chain assets.

It is important to note that these failures do not "spread" to the rest of the chain, meaning the failure will "spread" to Osmosis assets exposed to the Terra bridge route, but the Osmosis chain itself does not have a security failure.

However, it is clear that we want to bridge things (in general, cross-chain communication), and it would be bad to be limited to using native assets on their main chain. We need chains to communicate and bridge securely.

As a thought experiment, the simplest solution is to have each user run a full node for each chain, including the cross-chain bridge itself. Remember, we have 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, but Namada does not agree with Ethereum's consensus (i.e., it will not publish data to Ethereum or base its state on it).

This applies to Ethereum full nodes, but it is obviously not scalable. You cannot start requiring every Cosmos chain to run full nodes for every other Cosmos chain. These bi-directional full node bridges do not scale; they only increase hardware requirements.

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

State Validity - While IBC currently uses traditional consensus proofs, it can be modified to add validity proofs of the connected chain, and now the bridge will not be deceived by invalid state transitions. This could accurately prevent the attacks described earlier, as the bridge would reject Terra validator blocks if it could verify the validity of state transitions.

This looks very similar to how Rollup bridges on Ethereum check Rollup proofs, but here it can also be bi-directional.

DA - Additionally, chains may require their nodes to run light clients of the connected chain's DAS. For example, you can require both Cosmos chains to run their own validators' light clients of the other chain's DAS (if each chain implements DAS light clients, which these chains currently do not support). After doing this, each chain can now know the validity and DA of each other without running full nodes.

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

Dependent Chains vs. Independent Chains

Let's revisit our five security properties, now in the context of observing Rollup's Rollup verification bridge on Ethereum:

• Ledger Growth - Ethereum validators can force the Rollup ledger to continue growing (e.g., force inclusion of transactions).
• Censorship Resistance - Ethereum validators can force Rollup operators not to censor indefinitely (e.g., force inclusion of transactions or sequencer replacement).
• Resistance to Reorgs - Rollup's resistance to reorgs is related to Ethereum. If Ethereum reorgs, all Rollups on Ethereum will reorganize together.
• Data Availability - Rollup's DA is guaranteed because Rollup is derived from data confirmed by the main chain consensus (the position of the Rollup contract), and Rollup and the main chain share merged consensus. DA is a validity condition of Ethereum itself, so if data is not available, Ethereum blocks themselves are invalid. The bridge can access the data on the main chain without adding trust assumptions.
• State Validity - The contract will check the validity proof of Rollup state transitions (or wait for the challenge window to pass), proving that the declared state update is a valid result of applying Rollup's STF on the corresponding data confirmed on the main chain.

It is important to note that the security of the bridge is not maximized solely by attaching the super-strong confirmation rules of the attached chain (e.g., a full validator bridge to a chain with a super trustworthy validator set). If the bridge has the same security assumption as the main chain, you can achieve maximum security when bridging native assets across chains.

Vitalik provides a useful illustrative example:

"You bridge 100 ETH to a bridge on Solana, getting 100 Solana-WETH, and then Ethereum gets 51% attacked. The attacker deposits a bunch of their own ETH into Solana-WETH, then immediately recovers the transaction on the Ethereum side after it's confirmed on the Solana side. The Solana-WETH contract is no longer fully backed, and maybe your 100 Solana-WETH is now only worth 60 ETH. Even with a perfect ZK-SNARK-based bridge that fully verifies consensus, it is still vulnerable to a 51% attack like this."

Therefore, holding Ethereum native assets on Ethereum or Solana native assets on Solana is always safer than holding Ethereum native assets on Solana or Solana native assets on Ethereum. In this case, "Ethereum" not only refers to the base 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 51% attacked, "cross-Rollup" applications that maintain state on Arbitrum and Optimism can still guarantee consistency. If Ethereum is not 51% attacked, there is no way to separately 51% attack Arbitrum and Optimism. Therefore, holding assets issued by Optimism based on Arbitrum is still completely safe.

You can replace Solana with any chain you want - even a chain where you have a trust assumption that exceeds Ethereum validators. Fundamentally, when you talk about cross-chaining assets with their ledger (e.g., ETH from Ethereum), any security assumption is additional, and the connected chain is always susceptible to reorgs or liveness failures.

However, chains with merged consensus (i.e., sharing their main chain consensus with Rollup) can bypass these additional security assumptions. Cross-chain bridges between these different domains can have the same final liveness and resistance to reorgs as the main chain itself. Sharing consensus minimizes the trust assumptions across the shared security domain.

It is up to you to decide what is a reasonable security assumption. In practice, there has not been a case of consensus failure between major chains. This would be obvious and costly, but it could be a more powerful assumption for connecting weaker chains.

There are some drawbacks to binding Rollup chains to the main chain. Let's compare two cross-chain scenarios, where in both cases, we have two chains using bi-directional full validator cross-chain bridges:

• Dependent - The remote chain (i.e., Rollup) shares consensus with the main chain (i.e., DA layer) and derives its state from the data on the main chain. The remote chain must fork with the main chain and base its finality on the main chain.
• Independent - These chains have their own independent consensus and do not derive their state based on data from other chains. They do not share the remote chain (i.e., Rollup) ←→ main chain (i.e., DA layer) relationship. They do not reorganize together and do not depend on each other's liveness.

Interestingly, both have pros and cons:

• Cons - The possibility of your chain being reorganized or experiencing liveness failures due to another chain's failure may initially sound like a disadvantage. Why should my chain have a problem because your chain failed?
• Pros - If such a divergence would cause serious problems on your chain, it is actually a significant benefit (e.g., if you have a large amount of cross-chain assets from the source chain, it will reorganize from the perspective of your cross-chain bridge, leaving unsupported collateral), the chain and its cross-chain bridge need to be consistent.

Similarly, there are potential positive and negative impacts of locking and over-renting, highlighting why a neutral and censorship-resistant base layer is so important:

• Pros - A good base chain can protect Rollup users from being squeezed by Rollup operators for excessive value, enforcing exit permissions.
• Cons - A bad base chain may arbitrarily raise prices and extract that value from Rollup and its users.

Submitting proofs + running bidirectional DAS rather than sharing a common base chain also has some inefficiencies:

• You don't want to require your nodes to run a bunch of other chains' DAS light clients, and adding new chains manually is much more efficient to run DAS on a huge shared DA layer.
• It is inefficient for many different chains to bidirectionally verify validity proofs for each chain. However, theoretically, proofs between multiple chains can be aggregated, so the entire chain cluster only needs to publish one proof to the chain.

There are trade-offs and benefits here, but it is also important to remember that there is a huge path dependency where interesting assets exist. If you want to use a lot of Ethereum native assets (including those in its Rollup), it makes sense to root your chain in Ethereum and its cross-chain bridge.

Conclusion

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

• Rollup pays rent for its consumption of DA from its main chain (e.g., Ethereum).
• Rollup can publicly expose confirmation rules with security properties matching the main chain (i.e., users can obtain the same security guarantees as operating on the main chain itself).
• Users obtain these main chain security properties at the speed of main chain consensus.
• If Rollup users want confirmation faster than what the main chain provides, they can use confirmation rules that make additional temporary security assumptions.
• Observers (i.e., users) interact with Rollup through confirmation rules, and a validation bridge with minimal trust assumptions is such an (optional but very valuable) observer.

Now, consider the benefits of deploying Rollup on an integrated chain:

User Security - Regardless of whether you want to implement any cross-chain bridges, Rollups can rent DA from their main chain and recycle their consensus, allowing Rollup to publicly expose confirmation rules matching the main chain without reaching 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), with security properties equivalent to operating on the main chain itself.

We should see that this is actually a two-sided coin, where Rollup only allows chains to provide confirmation rules with security properties equivalent to the main chain's security. Cross-chain bridges and ordinary users are observers of chains with given confirmation rules. Bridges may be the most important "observers" in these chains, as their security has a wide impact.

When we try to create a secure system, we need to care about the security of given confirmation rules and their accessibility. If most observers (users) interacting with these chains cannot reach them, then secure confirmation rules are not of much help.

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

However, "traditional Rollup" and the DA layer clearly dominate in today's validation and scaling technologies.

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