A lengthy article of 20,000 words, clarifying the debate on the security of Rollups

A Comprehensive 20,000-Word Article Unpacking the Security Debate Surrounding Rollups

User security and cross-chain security are actually two sides of the same coin, with Rollup merely allowing chains to provide confirmation rules, its security reaching the security of the main chain.

Original title: “Do Rollups Inherit Security?”

Author: Jon Charbonneau

Translated by: Frank, Foresight News

• OpenAI ChatGPT: Leaving the Past Behind (Literally!)
• OpenAI and G42 Join Forces to Bring AI to the Middle East
• Damning Twitter messages from Bankman-Fried

Introduction

Whether you love it or hate it, Twitter may never stop the debate on whether “L2” or Rollup “inherits security”.

Although most of the arguments are an indistinguishable semantic battle, if you can narrow down the range of the debate, potential viewpoints become valuable because they touch upon the core questions of when, where, and why Rollup makes sense.

Does scalable L2 eliminate the market demand for L1? Is it possible to turn L1, like Solana, into L2?

These arguments primarily come down to security issues. Unfortunately, the definition of “security” here has always been very elusive. We often use this term casually, and most of us generally know what we mean but are not entirely clear. Here we will break down security in different architectures in detail.

Popular definition of Rollup

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

Here is James Prestwich’s more general definition: “Rollup is a way to choose an alternative consensus mechanism and preserve a superset state by customizing the state transition function”.

Neither requires a verification bridge, 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 standards for Rollup:

• Rollup is a stateful system (e.g., blockchain) derived by running a custom state transition function (STF) on data inputs on the main chain (DA layer).

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

• As the Rollup’s state originates from running a state transition function (STF) on the data on the main chain, the validity of the Rollup depends on the validity of the main chain. Then Rollup nodes must sufficiently validate the consensus and validity of the main chain (or make an honest majority assumption about the main chain);

Rollup nodes determine the state of the Rollup (e.g., data blocks confirming the order and availability of the main chain) by applying their own state transition function (STF) on the consensus result on the main chain.

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 certain that certain events have occurred on Chain B (source chain), and vice versa. Ideally, we want this communication to be bi-directional and have strong security attributes (such as high confidence in the validity of messages and the source chain not being able to revoke them).

Essentially, a cross-chain bridge acts as an “observer” of another blockchain (just like any other typical human user). The cross-chain bridge implements given confirmation rules through which it becomes certain about the state of the connected chain (for example, it must receive inputs from a certain number of Ethereum blocks in order to accept a transfer).

• Traditional cross-chain bridges usually operate lightweight nodes of the source chain’s on-chain consensus validators (i.e., they trust whatever content most consensus signers trust);

• A cross-chain bridge can provide stronger security attributes by also acting as a full validator light node (i.e., adding data availability sampling (DAS) + validity/finality proofs). For example, the validators of a chain may have to run on all the DAS light nodes of the connected chain, which is a lighter alternative compared to requiring validators to run full nodes of the connected chain;

• Rollup cross-chain bridges can also preserve the liveliness and resistance to reorganizations of the main chain (as Rollup must share the consensus of the main chain);

Main Chain Bridge to Rollup

This direction is very straightforward because Rollup nodes fully validate the main chain.

Rollup nodes are aware of everything happening on the main chain, so they know when cross-chain bridge transactions occur. Currently, Ethereum Rollup full nodes also have to run full nodes for the Ethereum base layer.

Note that, if supported, Rollup nodes can also switch to running lightweight validators of their main chain. Let us consider a hypothetical example where Ethereum has fully implemented the following upgrades:

• Ethereum executes blocks with validity proofs (zkEVM research for the base layer is in progress);

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

• Ethereum’s execution layer publishes its data as a blob to the data layer, like any other Rollup on top of Ethereum (e.g., Celestia publishes its execution layer data to its DA layer, so DAS nodes check the availability of both Rollup data and Celestia’s own execution layer);

• Ethereum provides full consensus proofs instead of relying on a sync committee (e.g., through validator aggregation, improved signature aggregation, possible ZK consensus proofs, etc.);

Now, suppose you want to run a full node for an Ethereum-based Rollup in order to follow a valid Rollup chain. To do so, you would need to understand the canonical chain of Ethereum, which requires checking Ethereum’s own consensus and validity:

• The consensus of Ethereum – Any lightweight node client can track the consensus signed as blockchain and block headers;

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

• Ethereum’s own state validity – With zkEVM, every Ethereum block comes 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 for Ethereum blocks. Rollup nodes need to know that they are not only tracking the consensus signed Ethereum but also that it is a valid block header. For example, they might unintentionally track a consensus-signed but invalid Ethereum block (e.g., it generates a large amount of ETH).

If the underlying execution layer itself publishes its data to the DA layer (like other Rollups) and adds validity or fault proofs, then it becomes a built-in Rollup.

From Rollup → Main Chain Bridging

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

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

Rollups, Co-processors, and Intents

As discussed, Rollups, besides having their own state (e.g., Ethereum’s state), also store some of their own state (Rollup’s state). So, does CoW Swap have its own state instead of being part of Ethereum’s state? If it does, it sounds like a Rollup. If it doesn’t, 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 fast pre-confirmations to users (faster than Ethereum’s block time) and promises to include batch processing (batch) of orders – because Ethereum’s batch processing time is longer than most users would like – is it now a Rollup?

Chris Goes explores this topic in his speech at the Modular Summit and first provides an approximate definition for Intents: “A commitment to a preference function over a given system’s state space”.

Please note the similarities between Partial Resolving (matching intent) and Rollup sorting. The operator obtains the user’s off-chain signature message → publishes the resulting data to the main chain.

• Intent-based applications——The resulting state changes are resolved on-chain (for example, in the CoW Swap example, the application is on the underlying chain, so the tokens are exchanged there);

• Rollup applications——Use the data submitted to the main chain to calculate the state changes generated by Rollup;

Intent-based architecture and Rollup-centric architecture achieve similar goals from opposite directions. Intent-based solves this problem extensively from the perspective of users and applications, while Rollup-centric solves this problem extensively from the perspective of different blockchains.

Here, setting specific boundaries of separation is not important. What is more important is that we find that Rollup is actually not much different from the applications we are already familiar with, which have off-chain intent matching!

You rely on off-chain participants (such as sorters and solvers/packers) to provide some weak guarantees, such as optimal execution and a good user experience → determine the results based on the data published to the main chain. But they do not hold your funds.

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

If you want the intent solver or the Rollup sorter to be less trusted…

Modular Blockchains vs Monolithic Blockchains

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

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

Even Celestia’s execution is limited (for example, transfers, staking, cross-chain). Similarly, if someone launches a Rollup on top of Solana, it doesn’t magically become a “modular” blockchain.

Therefore, when you hear people refer to chains like Ethereum or Celestia as “modular” blockchains, please be aware that this is more of a practical distinction rather than a strict technical one. Both are usually optimizing their architectures to support Rollup. These Rollups are expected to handle most transaction executions within their scope.

Even Rollup may not be completely “modular”——Rollup sorters can achieve consensus on transaction sorting, provide DA, and execute transactions before any operation on the main chain. This is how users get pre-confirmation. Then the main chain provides another “final” commitment, reasserting DA and consensus on the order of Rollup transactions.

Rollups and Integrated Chains

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

Although today we associate DAS and validity/finality proofs with traditional Rollups, we should note that these are conceptually different. In theory, any integrated chain (such as a typical Cosmos application chain) could be upgraded to add DAS and validity proofs without having to publish its data to other external main chains like Ethereum. Nodes would independently sample and check proofs for that chain.

Vitalik talks about this distinction in his “Endgame”:

You might notice that a “traditional big blockchain” (integrated chain) with added DAS + validity/finality proofs could ultimately look 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 distinction becomes blurry at the extremes.

So, if you believe that DAS + validity/finality proofs are the endgame, then some form of “Rollup” is inevitable. There is a valid distinction between the two approaches in the image above:

• “Rollups,” also known as “modular” — building logically independent chains that publish data to their main chain (DA layer) and reuse the main chain’s consensus;

• “Integrated Blockchains,” also known as “monolithic blockchains” — integrating everything into one protocol with its own consensus and not publishing data to a separate main chain (even though DA layer and execution layers are logically independent parts that share the protocol in a sense);

When we discuss “Rollup” in this report, we will be referring to the former (i.e., not integrated chains with DAS + validity/finality proofs, which might be called enshrined Rollups).

Although “traditional” Rollups do not have a monopoly on DAS or proofs (integrated large blockchains can add them), please note that we are ignoring many technical details here, and you can’t just pick Solana and decide, “Oh, I think we’ll add DAS today.”

This would require fundamental protocol restructuring 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, moving closer to a traditional DA layer:

For this reason, we see teams building the following:

• Dedicated DA layers (e.g., Ethereum’s Danksharding, Celestia, etc.) – slow blocks + DAS;

• Shared sequencers (e.g., Espresso, Astria, or even Solana) – essentially just fast DA layers without the need for DAS;

However, if the quick blocks and DAS time are separated, they may not necessarily be incompatible. For example, you can imagine a chain like Solana that offers two different paths:

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

• Slow Path – encode the data asynchronously for DAS nodes to provide a guarantee slightly behind consensus;

Anatoly discussed in a podcast how Eclipse combines Ethereum, Celestia, and Solana together, while from the other end, you can imagine adding a faster path to the DA layer before making the data available for sampling:

Providing two paths in the same base layer protocol can effectively internalize fast shared ordering, which offers interesting designs for Rollup-based solutions. Please note that this is still a very exploratory idea.

Confirmation Rules

With the background knowledge, we can now start 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 if a block is confirmed. In this case, it mainly involves network synchronization and the percentage of honest stakes. When these conditions are met, the block is guaranteed to never be reorganized.”

There can be multiple 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 Ethereum’s available ledger, or do you wait for finality gadgets (Casper FFG) to confirm?

• Do you run full nodes that directly verify each block or only lightweight nodes that check the consensus signatures?

• Do you just ask Infura?

Since 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 = Security + Liveness

Now let’s dive deeper 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 resources (DA), and either party can choose to end this relationship. But that’s not the interesting part of the issue.

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

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

• Liveness (something good will eventually happen), all normally running nodes will complete reflecting a new state suitable for inclusion in a limited amount of time;

Using Sreeram’s excellent framework, we can further decompose them into five attributes that collectively ensure the security of confirmation rules:

Let’s consider an example of an integrated chain with DAS + validity/failure proof. Its data will not be published to any other external main chain. For simplicity, we assume immediate finality (e.g., Tendermint), so there is no distinction between an available ledger and a finally determined ledger (e.g., Gasper in Ethereum).

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

• Consensus validator light node – validates consensus proof (i.e., trust majority consensus);

• Full validator light node – validates consensus + checks DA (using DAS) + validates state validity (using validity/failure proof);

• Full node – validates consensus + directly validates DA (downloads all data) and validity (executes all transactions and computes states);

Confirmation rules have security attributes, the chain does not

Again, it is emphasized that “when we colloquially talk about a chain being secure, it is actually the security attributes attached to the confirmation rules”.

Let’s look at some examples.

CAP Theorem

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

• Adaptivity – staying active under dynamic participation (i.e., if a large portion of nodes are offline);

• Finality – staying secure under network partitions;

Consensus protocols often consist of two parts, each satisfying one of the above conditions:

• Longest chain protocol – these protocols (e.g., Bitcoin’s Nakamoto Consensus) can guarantee liveness even when the number of actively participating nodes is variable (i.e., they are adaptive), but they are not secure under network partitions (i.e., no finality);

• BFT-type protocols – classical consensus protocols (e.g., PBFT) achieve finality, but do not achieve adaptivity;

Bitcoin Confirmation Rules

The consensus of Bitcoin does not provide any hard economic finality.

Nodes observe the longest chain in their local view, and each user is free to apply any confirmation rules they like (e.g., 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. The waiting time needs to be balanced with security (i.e., the possibility of reorganization).

Ethereum Confirmation Rules

The PoS consensus of Ethereum (Gasper) seems to bypass the CAP theorem at first glance. However, it achieves both properties because it includes two nested ledgers:

• Dynamic Availability Ledger – Secure and active under dynamic participation if the network is not partitioned;

• Finalized Prefix Ledger – Always secure and reliable. It maintains activity if the network is not partitioned and has enough participating nodes;

Gasper belongs to the “ebb-and-flow” (also known as dual-ledger or dual-confirmation rule) protocol family. The dual-ledger design does not fall within 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 adaptiveness and finality to be resolved at the user level rather than at the system-level. It is a characteristic of the “Checkpoint Longest Chain” protocol proposed in the blockchain CAP theorem that allows users to choose between finality and adaptiveness rather than imposing it on the entire system.

Gasper explicitly states two distinct confirmation rules, mapped to the two ledgers mentioned above:

• Dynamic Availability Rule – Guarantees adaptiveness. Respects the block headers of the longest chain. LMD GHOST is the fork selection rule used to determine the heaviest subtree;

• Finalized Confirmation Rule – Guarantees finality. Respects the blocks confirmed by the finality gadgets. Casper FFG is the finality gadget applied on top of the fork selection rule;

As discussed in the paper:

“More optimistic adaptive rules always confirm blocks as finalized by more conservative rules and may confirm more blocks during periods of variable participation. Clients (users) locally choose 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;

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

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

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

Ethereum nodes can also apply some other intermediate confirmation rule heuristics in practical use. Instead of using a naive k number of blocks as an adaptive confirmation rule like Bitcoin, we can add other heuristic methods, including assumptions about network synchronization and validator honesty.

This is exactly what is proposed in the “Ethereum Consensus Protocol Confirmation Rules“, which presents confirmation rules with the following attributes:

• Under ideal conditions – The rule will confirm new blocks immediately after their slots.

• Under typical mainnet conditions – The rule should be able to confirm the majority of new blocks within one minute.

These confirmation rules do not replace economic finality. Instead, they provide useful heuristic methods for users who believe that network synchronization will be maintained in the near future. Let’s compare the two:

Let’s consider some examples, such as bidding a yacht for 2.5 million ETH. Here are some possible confirmation rules:

• Full node + waiting for finality – Even malicious majority validators cannot deceive you into accepting invalid blocks (e.g., generating fake ETH). If they give you 2.5 million ETH and then attempt to later reorganize the finality-determined block, they will incur a significant cost (at least one-third of stake is punatively slashed);

• Full node + waiting for one block – Most malicious validators still cannot deceive you into accepting invalid blocks, however, they can send you 2.5 million ETH in a valid block, ride the yacht and then immediately reorganize the block if there is enough stake weight or poor network conditions, without being punatively slashed;

• Light client node – Malicious synchronized committees can lie to you without any penalties, and the buyer can leave with the yacht. (Please note that this synchronized committee as a subset of consensus is unique to Ethereum, other PoS chains with more efficient light client support can check all consensus votes with fewer validators);

• MetaMask – You simply trust Infura, and the person buying the yacht from you promises Infura employees they can ride the yacht on the weekend, so they lied to you and you think you have received 2.5 million ETH and hand over the keys;

Rollup Confirmation Rules

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

A typical Rollup transaction process is roughly as follows:

1. Users submit transactions to the sequencer;

2. The sequencer sorts the transactions and provides pre-confirmation;

3. Deterministic state transition functions (STF) are applied to ordered transactions to calculate the new Rollup state;

4. The updated Rollup state commitment and relevant transaction data are eventually posted to the main chain;

After transaction data is posted to the main chain:

• Rollup full nodes – directly verify the correctness of the proposed chain state;

• Rollup light nodes (including verification bridges) – unable to verify directly;

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

1. Assuming complete transaction data is published (not just state differences);

2. As mentioned earlier, Rollup nodes must also run as full nodes or full validator light nodes of the main chain (or make the honest majority assumption using consensus validator light nodes). Rollup light nodes can run as additional software or implicitly within main chain nodes (i.e., cross-chain bridge contracts on the main chain verifying Rollup);

Users can also confirm transactions faster by trusting the sequencer’s pre-confirmation, even before data is received on the main chain. If the sequencer behaves improperly, security may fail. Then, once the data is on the main chain (and you have checked the DA + validity), only main chain failures (such as Ethereum reorganizations) can affect your security.

Therefore, even centralized sequencers do not truly compromise the security of “Rollup”. You always obtain the security that complies with the confirmation rules you need. Whether Rollup has a design based on sequencers or others, you can use the same confirmation rules (e.g., wait for the main chain’s final determination and check Rollup validity). If correctly implemented (e.g., enforced transaction inclusion through the main chain), you can achieve the same security properties within the same time frame while keeping other conditions the same.

Similarly, you can imagine Ethereum L1 block producers providing pre-confirmation due to slow block times, which does not compromise the security of “Ethereum”. You only need to decide whether to use a different set of confirmation rules (lower security) until the Ethereum validators finally determine higher security.

The idea of pre-confirmation aligns well with Vitalik’s description of Gasper’s logic.

The general principle is that you want to provide “as much consensus as possible” to the users: if there is more than 2/3 consensus, then we will regularly reach consensus, but if there is less than 2/3, then there is no reason to delay and not provide any content because obviously, although the security level of the new block is temporarily lower, the chain still has the potential to continue growing. If a single application is not satisfied with the lower level of security, it can ignore these blocks until they are eventually determined.

Putting all of this together, when all confirmation rules simultaneously reach 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 run by SBF, instead of trusting a decentralized sequencer composed of the most reputable validators in the world, then your security may be worse, and liveness failures and reorganizations are security vulnerabilities.

Alternatively, you can wait for stronger (main chain) confirmation rules to become available. In that case, an untrusted sequencer would not affect your security, under the same conditions. If you are selling coffee, you can probably leave immediately, but if you are selling yachts, you would need to carefully check the main chain’s confirmation information.

However, if everyone actually uses the confirmation rule of trusting a randomly chosen person running a separate sequencer, we cannot completely ignore the potential lower security of this rule. Precise design is based on balancing the progressive commitment level required for a given use case at any given time.

Similarly, this also touches on the true criticism of high-throughput blockchains like Solana. What confirmation rules can people actually use? You may have good security conditions to run a full node of Solana, but most people may not have access to that confirmation rule (depending on resource requirements and/or costs).

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

In summary:
– Users interact with any chain through confirmation rules.
– A chain can have as many confirmation rules as desired.
– Security is an attribute of confirmation rules, not the chain itself.
– We care about the security and accessibility of the confirmation rules for a given chain.

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

Rollups and the security of integrated chains

1. Integrated chains with DAS+ validity proof

We now see that the security of DA and state validity can be checked directly using encryption technology (DAS+ validity/failure proof) without making strong assumptions about the operators of the chain. Any protocol can achieve these technically. Full nodes can also check DA and state validity without external assumptions.

Now let’s focus on other properties – activity and resistance to reorgs. As we’ve seen before, regardless of which consensus rule you run, these can both fail. Take a look at a integrated chain with DAS+ Validity Proof + PoS single slot finality:

Choosing strong consensus rules is particularly effective for subsets of security failures, where even most malicious verifiers cannot deceive full nodes or full validator light nodes to believe:

• Unavailable data is actually available;

• Or invalid state transition is valid;

Whether Ethereum has 1 validator or countless validators, full nodes somewhat trust the DA or validity of blocks, guaranteed by their checks. Full validator light nodes can do checks in a simpler way (but note that DAS will make some other assumptions, which we’ll discuss later).

However, most malicious validators might prevent ledger growth, censor you, or reorg chains (which failures happen depend on consensus rules). DAS + ZK can’t save you. Resistance to reorgs and activity depend to some extent on various underlying properties of the given chain (e.g., reliable operators, economic incentives, social consensus, etc.).

It’s not obvious, but activity and resistance to reorgs are still properties of the given consensus rule, since every node is subject to the same attacks as shown in the table above. Regardless of how consensus rules here are, they have the same guarantee.

However, this becomes obvious again when you remove the single slot finality assumption. In Ethereum’s Gasper, depending on the ledger you follow (i.e., longest-chain-available version or finality determined by checkpoints), you’ll have different properties of activity and resistance to reorgs again. Most malicious validators would cause different security failures depending on the consensus rules you run.

Anyway, what’s critical here is the underlying construction of the chain. You need strong operators, economic incentives, and social consensus to maintain the activity and resistance to reorgs of the chain. Additionally, dual-ledger consensus protocols like Ethereum provide valuable flexibility for users to calculate availability and finality according to their needs.

2. Using DAS + Validity Proof Rollup

Now let’s slightly modify this example:

• Previous example – an integrated chain with DAS + Validity Proof, imagine it’s built on today’s Solana but with the addition of DAS + Proof;

• New example – Rollup deployed on an external main chain (e.g., Ethereum), with Validity Proof + DAS (note that Ethereum DAS is not yet available), the Rollup has a decentralized sequencer set that achieves fast pre-confirmation consensus;

You’ll notice that Rollup has two completely independent consensus rules for different time ranges (i.e., operating based on sequencer-based pre-consensus or waiting for final consensus on the main chain), let’s now look at each path.

Fast Path – Before Main Chain Consensus

Rollup nodes can rely on the sequencer’s confirmation (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 Rollup sequencer consensus;

• Rollup full validator light node – run DAS on the sequencer’s feed + check validity proof before publishing anything to Ethereum;

• Rollup full node – download all data from the sequencer’s feed and execute all transactions to directly check DA (data availability) and validity;

Technically, the Rollup sequencer can facilitate DAS and provide validity proof before publishing to the main chain, but in reality, this does not happen. Full validator light nodes are usually intended to check these on the main chain, but I assume that “real-time” DAS + proof can be compared more clearly with an integrated chain.

The following table shows the changes compared to an integrated chain example:

• Rely on the Rollup sequencer for liveness and resistance to reorganization, instead of the validator set of an integrated chain;

• Simply remove the final liveness property because we only look at the time range before the main chain consensus (these “final” liveness properties will come from the main chain later);

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

Slow Path – Waiting for Main Chain Consensus

For additional security, nodes can wait for the consensus of the main chain (e.g. Ethereum), and this is where the Rollup nodes should also run main chain nodes to play a clearer role:

• Main chain consensus validator light node – trust the honest majority consensus of the main chain;

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

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

Please note that Rollup 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 (State Transition Function), no need to deploy a verification bridge, instead, it can check Rollup proof through another method (e.g. receive Rollup proof via p2p), which requires running additional Rollup node software to verify the proof (i.e. Rollup light node);

• Internal to the main chain (implementing Rollup nodes within the main chain) – this is the current norm, Rollup light node validator logic is deployed within the main chain itself (i.e. the built-in bridge contract for Rollup), as this Rollup validator node operates within the main chain’s STF, validating the main chain’s STF also means validating Rollup’s STF;

If we have a main chain with zero-knowledge proofs (such as Ethereum L1 zkEVM) + all Rollups prove their state inside the main chain→ we get Vitalik’s vision of Proof of Singularity. Validating an Ethereum zero-knowledge proof means validating all other chains and their internal implementations of validation nodes:

For simplicity, let’s assume here that the validity of the Rollup state is validated within the main chain itself (for example, Rollup has a built-in bridge with the main chain), so we can ignore additional Rollup node software running outside the explicit runtime protocol.

The changes compared to the previous “fast path” Rollup table are as follows:

This is achieved through main chain enforcement of transaction inclusion or sequencer/verifier substitution, which we call “final” liveness here because from the perspective of Rollup, it is a slow path, but from the perspective of the main chain, it can be seen as “real-time” liveness.

Rollup and Integrated Blockchain

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

• Data Availability and State Validity – If implemented, DAs + validity proofs can provide applicable security guarantees, whether the chain is integrated or traditional Rollup. In practice, these technologies are now primarily focused on Rollups;

• Liveness and Re-org Resistance – Integrated blockchains are responsible for these in all scenarios. In contrast, Rollup provides a choice of confirmation rules within different time ranges. You can adopt less secure confirmation rules (trust sequencer consensus) to get quick assurance, or wait for more secure confirmation rules (wait for main chain consensus);

Liveness and Re-org Resistance

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

If the operators are completely out of control, without full nodes or ZK proofs, you may be vulnerable to liveness failures or re-orgs.

These properties are achieved through powerful and decentralized operators, censorship-resistant mechanisms, consensus that favors liveness, high “cost” of re-orgs, and strong social consensus. Objective comparison of these traits would usually be challenging.

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

What is important is that we see Rollup can delegate re-org resistance and liveness to the main chain, the confirmation rules used on Rollups can have the same security properties as if they were running on the main chain within the same time range.

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

• Anti-Reorganization – Rollup may delegate anti-reorganization to Ethereum, and its forking selection rules are based on the content confirmed by Ethereum consensus to select the “canonical chain”. If Ethereum reorganizes, Rollup will also reorganize.

• Liveness – However, if Rollup lacks mandatory inclusion and mandatory operator replacement mechanisms, Rollup users still won’t receive Ethereum’s liveness attribute.

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

This highlights the importance of such mechanisms.

Data Availability and State Validity

Unlike liveness and anti-reorganization, nodes can ensure the validity of DA and state without making any significant threshold assumptions (or without making security trade-offs between the two). Malicious majority block producers may cause liveness and reorganization 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 are of course affected by the failure of state validity and DA by an honest majority. They simply trust everything that consensus says. That’s why DA and state validity are the reasons that make the security confirmation rules easily accessible and effective. This is often a major ideological difference between traditional Rollup and large blockchains that don’t prioritize user verification.

In order, these are generally the preferred approaches to balancing security and accessibility:

1. Make DA and validity proofs widely available;

2. If you don’t have DA and/or validity proofs, make full nodes widely accessible (i.e., low resource requirements, easy to run, etc.);

3. If you don’t have DA 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;

Please note, 2 (full nodes) are actually the most secure. ZK verification is very simple, but DA nodes make additional assumptions that full nodes don’t. However, they offer nearly the same level of security as full nodes, with only a fraction of the resource requirements, making them scalable.

Full nodes simply download all the data, so they have 100% determinism. They only sign off on a block when everything is there. They don’t make any assumptions about external parties.

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

In a nutshell, you usually make assumptions around network synchronicity and the existence of enough nodes to rebuild the data. If adversarial block producers hide any data, even a small portion of honest light nodes should be able to collectively reconstruct the blocks. There are also some assumptions about selective share disclosure, where adversarial block producers can deceive a few light nodes individually, but not collectively.

Compared to the typical “N/2” assumption (e.g., 51% of block producers can lead to reorg), these “N in minority” assumptions (e.g., a minority of honest nodes can ensure DAS security) are very favorable. Vitalik provides a good explanation of this in his post on the trust model.

Overall, DA and state validity are not “delegated” like activity and resistance to reorganization by Rollups. DA and state validity can be directly verified by users, while other attributes heavily rely on the consensus participants of the chain and their incentives.

Returning to the example of verifying Rollup proofs:

• Publish the Rollup’s ZK proof to an Ethereum smart contract, run a full Ethereum node, and implicitly verify the proof.

• Send the Rollup’s ZK proof to my Rollup light node and directly verify the proof.

In either case, you can ensure validity. However, you can’t determine its validity wherever you check. Ethereum does not “enforce” validity in the same way it “enforces” resistance to reorg or activity. Resistance to reorg and activity largely depend on where they come from.

Consider a Rollup based on a fraudulent chain:

• Rollup’s forking selection rules follow the tip of the chain confirmed by the fraudulent chain → If the fraudulent chain reorgs, Rollup will reorganize as well.

• Rollup’s mandatory inclusion and sequencer deletion are enforced through cross-chain bridging contracts on the fraudulent chain → If the ledger on the fraudulent chain stops, Rollup’s ledger will stop. If the fraudulent chain wants to inspect your Rollup, you will be subject to inspection.

Rollups can publicly offer confirmation rules with the same security properties as their main chain. They can, at most, receive these properties at the speed of their main chain’s consensus (in practice, it often lags a bit depending on the frequency of Rollup publishing to the main chain).

Rollups can also provide “happy path” looser 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 still move forward. However, if your chain relies entirely on your own set of validators (i.e., as an integrated chain), it’s not the case.

Choosing the main chain for Rollup wisely has a concrete impact on security properties. Utilizing a main chain with strong activity (ledger growth + CR) and resistance to reorg is particularly valuable.

Different Security Assumptions at 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 deploy 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 activity and resistance to reorganization (e.g., decentralized trusted validators, etc.);

Integrated blockchain has the following characteristics:

• Block time of 1 second;

• Can achieve DAS light nodes and validity proofs, whether launched as an integrated blockchain or as a Rollup;

• Has a centralized sequencer – it will offer “low security” confirmation rules regarding activity and resistance to reorganization;

• If it implements its own decentralized consensus (as a pre-validated Rollup sequencer set or as an integrated chain validator set), it will offer “medium security” confirmation rules regarding activity and resistance to reorganization;

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

Rollup’s “final security” is higher than its “real-time security” because the main chain cannot provide guarantees faster than its own block time. Even though you can check whether the pre-validated sequencer transitions are valid, you cannot fully guarantee their finality until they reach the DA layer.

But as we have seen, deploying as a Rollup on a powerful main chain can enhance security. They can rent security at the speed of their main chain. Fundamentally, there is no way to obtain all the security properties of a main chain at a speed faster than its own consensus.

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

• Practical functionality and efficiency. For example, a centralized sequencer can offer fast pre-confirmation and reduce operational costs;

• Strong guarantees. For example, an incredibly decentralized sequencer set can offer better real-time activity resilience, but at the cost of higher operational costs and latency (in the most extreme cases, you only need to let the DA layer handle Rollup sorting, choosing not to expose a faster path);

Interestingly, you can think that the activity of ordering Rollup on L1 is worse than a centralized sequencer, depending on your time scale. So far, we have discussed activity, incorporating it into a concept of “limited time.” However, this is completely relative and subjective. Relative to what? How much time is needed?

A simple L1 sequential Rollup will only include at the speed of L1 blocks (e.g., 10 seconds), with no liveness guarantee between these blocks when the world around you is changing. So it depends on your benchmark:

• If the benchmark = Operations within Rollup, L1 sequential Rollup may provide better liveness. Others on the chain should not gain any commitments before the main chain confirms, so you are all on an equal footing;

• If the benchmark = Operations outside Rollup– Rollup with soft-preconfirms can offer better liveness. Pre-confirm is just an optional thing, and you still roll back to the main chain at the speed of the main chain guarantee, but during this time, you can have weaker guarantees. If you don’t trust them, just wait for the main chain confirmation. The world doesn’t freeze between Ethereum blocks, and for many applications, outdated prices between long block times can be unacceptable;

If you try to achieve “true” Rollup without pre-confirmation, there might even be pre-confirmation in any case. It is economically incentivized for participants (e.g., Ethereum builders and validators) to make this commitment themselves. That’s why people are discussing how Ethereum builders and stakeholders are trying to provide fast pre-confirmation at the base layer.

Here is one last important note. Assuming Rollup users can roll back to the same liveness as the main chain, assuming you can force inclusion at the speed of main chain blocks (e.g., if the Rollup sequencer is reviewing you, you can force the inclusion of transactions in the next Ethereum block).

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

Regardless of the exact time scale, absorbing the final liveness of the main chain is very powerful, using a powerful main chain as a coordinating mechanism provides credible threats and exit rights. Just exposing this credible threat itself makes it highly unlikely to be needed and thus 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 rents from users and lock them. This is a general area discussed in Chris Goes’ speech about MEV transformation cost edges and slow games.

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

Proofs protect users, not the chain

Following all of this, we can see that for a given set of confirmation rules, proof protects the different “observers” of Rollup more accurately than protecting Rollup itself. The security of Rollup does not exist as a single specific measure.

Ensuring the safety of observers is of course the most important, because we are all observers of the chain! This chain is anything the observers of it say. If you cannot observe it securely, you must trust someone else (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 “proof-protecting the chain” and “proof-protecting the observers of the chain,” consider the following:

• Light nodes – If there is proof, Rollup light nodes will be more secure as they don’t have to trust the validity of anyone’s words;
• Full nodes – If there is proof, the security of Rollup full nodes does not increase or decrease. You can launch Rollup (pessimistic rollup) without any built-in bridges or even any proofs. If you start sending validity proofs, the security of full nodes does not increase or decrease;

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

Proof ensures the security of the Rollup bridge

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

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

The bridge is an observer of another chain, and every asset it mints is always based on the security assumptions of the corresponding bridge. The security of its confirmation rules can have wide-ranging effects. That’s why building a secure bridge is so important (or ideally, reducing the need for so many bridges by further extending the execution of a single chain first).

If you run a full node for that chain, the malicious party cannot trick you into accepting invalid state transitions. However, if the malicious party has different confirmation rules, it can still deceive the bridge. If you hold asset-backed assets in that bridge, your funds may become unsupported. From this sense, the security failure of deceiving the bridge is “contagious”.

Let’s consider an old hypothetical scenario about Terra:

• Terra has its own set of validators, with LUNA as its native token and the ability to issue native UST;
• Osmosis has its own set of validators, with OSMO as its native token;
• We have a standard Terra ←→ Osmosis IBC bridge, where each side runs a light node of the consensus validators of the other chain (i.e., each side of the bridge relies on the honest majority of the validators of the other chain);
• You run your own full node for each chain;
• We will call the UST bridged on Osmosis osmoUST;
• We will call the OSMO bridged on Terra terraOSMO;
• You own terraOSMO on Terra;
• You are LPing on the osmoUST/OSMO pool on Osmosis;

With the collapse of Terra and the sharp decline in LUNA’s price, the theoretical profits of the malicious validator set will eventually exceed the value of the staked LUNA. Terra validators can sign invalid blocks and perform the following actions:

• Forge fake UST → Cross-chain to Osmosis to forge osmoUST and use it to drain all osmoUST trading pairs (e.g. remove all OSMO from the osmoUST/OSMO pool);

• Forge fake terraOSMO → Cross-chain to Osmosis to withdraw all native OSMO collateral locked on Osmosis that supports terraOSMO. All remaining terraOSMO on Terra will no longer be supported;

So, the security here fails:

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

• Light node (bridge) – The bridge only checks if the consensus of Terra is signed on the block (does not check for valid state transitions), so it does not reject them. Terra validators can steal the OSMO collateral supporting my terraOSMO and drain all the OSMO from the osmoUST/OSMO pool (leaving a pile of worthless osmoUST);

The bridge uses confirmation rules with stronger trust assumptions.

Terra validators cannot steal a large amount of Terra’s assets from the full node itself (they will not be deceived), as they would reject those blocks. However, validators could deceive consensus validator light clients (including the bridge), which is why consensus mistakes impact cross-chain assets.

Note that it is important to understand that these failures do not “infect” the rest of the chain. In other words, the failure only “infects” Osmosis assets exposed to the Terra bridge route, but there is no security failure within the Osmosis chain itself.

However, it is apparent that we do want to bridge things (in general, cross-chain communication), and restricting it to using native assets on its main chain would be limiting. We need chains to communicate and bridge securely.

As a thought experiment, the simplest solution would be to have each user run a full node for each chain, including the cross-chain bridge itself. Keep in mind that we have already 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, although Namada does not agree on Ethereum’s consensus (i.e., it does not publish data to Ethereum or derive its state from it);

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

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

Validity of state – Although IBC currently uses traditional consensus proofs, it can be modified to add validity proofs for connecting chains, so the bridge will not be deceived by invalid state transitions. This would accurately prevent the attacks described earlier, where the bridge would consider the Terra validator’s blocks as invalid and reject them if it could validate the validity of state transitions.

This appears to be very similar to how Rollup bridges on Ethereum check Rollup proofs, except here it can be bidirectional as well.

DA – Additionally, the chain may require its nodes to run lightweight nodes for the connecting chain’s DApps. For example, you can have both Cosmos chains require their own validators to run lightweight nodes for the other chain’s DApps (if each chain has implemented DApp lightweight clients, which these chains currently don’t support). After this is done, each chain can now know the validity and DA of each other without running full nodes.

For Rollup, 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 and independent chains

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

• Ledger growth – Ethereum validators can enforce the continuous growth of Rollup’s ledger (e.g., by forcing the inclusion of transactions);

• Censorship resistance – Ethereum validators can enforce that Rollup operators don’t indefinitely perform censorship (e.g., by forcing the inclusion of transactions or replacing the sequencer);

• Reorganization resistance – Rollup’s reorganization resistance is tied to Ethereum. If Ethereum reorganizes, then all Rollups on Ethereum will reorganize together;

• Data availability – Rollup’s DA is guaranteed because Rollup derives data from the main chain consensus (where the Rollup contract resides), Rollup and the main chain share merged consensus, and DA is an Ethereum-wide validity condition, so if the data is unavailable, the Ethereum block itself is considered invalid. The bridge can access data on the main chain without adding trust assumptions;

• Validity of state – The contract will check the validity proof of Rollup state transitions (or wait for the challenge window to pass), which proves that the claimed state updates are valid results of applying Rollup’s STF to the corresponding data confirmed on the main chain;

Please note that the security of the bridge is maximized not only by adding overwhelmingly confirming rules from the attached chain (e.g., a fully validating bridge to a chain with a super trusted set of validators). If the bridge has the same security assumptions as the main chain, you can achieve maximum security when dealing with cross-chain native assets.

Vitalik provided a useful explanatory example:

“You transfer 100 ETH to a bridge on Solana and receive 100 Solana-WETH. Then Ethereum gets attacked by a 51% attack. The attacker deposits a bunch of their own ETH into Solana-WETH and then immediately recovers the transaction on the Ethereum side after confirmation on the Solana side. 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 bridging mechanism that fully verifies consensus, it is still vulnerable to attacks like a 51% attack.”

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

If Ethereum gets attacked by a 51% attack and recovers, Arbitrum and Optimism will also recover, so even if Ethereum is attacked, “cross-rollup” applications that store state on Arbitrum and Optimism can guarantee consistency. If Ethereum does not suffer a 51% attack, there is no way to separately attack Arbitrum and Optimism. Therefore, holding assets issued on Optimism based on Arbitrum is still fully secure.

You can replace Solana with any chain you prefer – even a hypothetical chain that you trust more than Ethereum validators. Fundamentally, when you talk about cross-chain assets with their respective ledgers (e.g., ETH from Ethereum), any security assumption is an add-on, and the connected chain can always undergo reorganization or exhibit liveness faults.

However, chains with merged consensus (i.e., Rollups that share the main chain consensus) can avoid these additional security assumptions. Cross-chain bridges between these distinct realms can have the same finality and resistance to reorganization as the main chain itself. Sharing consensus minimizes the cross-chain trust assumptions within that shared security realm.

What constitutes a reasonable security assumption is up to you. In practice, there have been no cases of similar consensus failures among major chains. It would be obvious and costly, but it could be a stronger assumption when connecting weaker chains.

Binding a Rollup chain to the main chain also has some drawbacks. Let’s compare two cross-chain scenarios, where in both cases, we have two chains using a bi-directional fully-verified cross-chain bridge:

• Dependent – The remote chain (i.e., Rollup) shares consensus with the main chain (i.e., DA layer) and derives its state from data on the main chain. The remote chain must fork alongside the main chain and rely on it for finality;

• Independent – These chains have their own independent consensus, they do not derive their state from data on 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, these all have pros and cons:

• Con – Reorganizing your chain with other chains or encountering liveness faults may initially seem like a disadvantage, why should my chain have problems because of your chain?

• Pro – If such disagreements cause significant issues on your chain, it is actually an important benefit (e.g., if you have a large amount of cross-chain assets from the source chain, it will be reorganized from the perspective of your cross-chain bridge, leaving unsupported collateral), chains and their cross-chain bridges need to be consistent;

Similarly, locking and excessive rent-seeking also have potential positive and negative impacts, which highlights why a neutral and censorship-resistant base layer is so important:

• Pro – A good main chain can protect Rollup users from being exploited by Rollup operators, forcing them to enforce exit permissions;

• Con – A poorly designed main chain may arbitrarily increase prices and extract value from the Rollup and its users;

There are also inefficiencies in using submission and verification of proofs in both directions instead of sharing a common public main chain:

• You don’t want to require your nodes to run DAS light clients for a bunch of other chains and manually add new chains, it is much more efficient to run DAS on a large shared data availability layer;

• For each chain, it is inefficient to have proof of validity verification for many different chains. However, theoretically, proofs between multiple chains can be aggregated so that 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 interesting assets have a huge path dependency, so it makes sense to anchor your chain to Ethereum and its cross-chain bridges if you want to use a bunch of Ethereum-native assets (including assets in its Rollup).

Conclusion

“Rollups inherit security” is a good shorthand, but please keep in mind these key points that reflect our true intentions:

• Rollup pays rent for the resources it consumes (DA) to its main chain (such as Ethereum);

• Rollup can publicly expose confirmation rules with security properties as strong as 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 faster confirmation speeds 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 verification bridge with minimal trust assumptions is such an (optional but highly valuable) observer;

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

User Security – Whether you want to implement any cross-chain bridges or not, Rollups can rent DAs from their main chain and recycle their consensus, allowing Rollups to expose confirmation rules that match the main chain to their users without reaching their own consensus;

Cross-Chain Security – Rollups can build cross-chains within the shared security domain of the main chain (i.e., the main chain itself and its Rollup), and their security properties are equivalent to operating on the main chain itself;

We should see that this is actually a double-edged sword. Rollup only allows the chain to provide the confirmation rules, and its security can reach the security of the main chain. Cross-chain bridges and ordinary users are observers of the chain with given confirmation rules. Bridges may be the most important “observers” in these chains because their security has a broad impact.

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

Although we associate DAs and validity proof with Rollup today, they are logically independent concepts. Any chain can integrate these technologies, and the difference between what is a Rollup and what is not a Rollup starts to break down in the end (i.e., a single integrated Rollup may have logically independent DAs and execution layers under one protocol).

However, “traditional Rollup” and the DA layer obviously dominate in today’s verification and scaling technologies.

We will continue to update Blocking; if you have any questions or suggestions, please contact us!