Thank you to Mike Neuder, Luca Donno, James Prestwich, Sreeram Kannan, Francesco D'Amato, and Davide Crapis for valuable feedback and review.
Love it or hate it, Twitter will probably never stop fighting over "L2s" or whether rollups "inherit security".
While most of these debates are indiscernible semantic wars, the underlying points are incredibly valuable if you can manage to narrow them down. They get to the heart of when, where, and why rollups make sense. Do scalable L2s obviate the need for L1s? Is it possible to just turn L1s like Solana into L2s?
These debates largely come down to security. Unfortunately, defining "security" here has been quite elusive. We mostly use the term casually where most people know roughly what we're talking about, but not quite. We'll break down security in detail here across different architectures.
I'm sorry, but we've gotta get this out of the way quickly.
I finally get what ppl felt like when they didn’t like my definitions of L1s and L2s and stuff
Just found out all of these are fruits:
Pistachios, cashews, almonds, olives, eggplants, peppers, zucchini, corn, green beans, peas, pumpkins, cucumbers, chickpeas
Absolute bullshit
— Jon Charbonneau (@jon_charb) July 2, 2023
I've previously used the below definition from Mustafa:
"Rollups are blockchains that post their blocks to another blockchain and inherit the consensus and data availability (DA) of that blockchain."
And here's a more general definition from James Prestwich:
"A rollup is an opt-in, subset of another consensus, keeping a superset of state, via a custom state-transition function."
Neither require a validating bridge. The ability to build a bridge with minimal trust assumptions is a major benefit of rollups, but it's critical to analyze them in isolation.
We can consider the following criteria for rollups:
Rollup nodes determine the rollup's state by applying the rollup's own STF over the outcome of the host's consensus (e.g., what data blobs the host confirmed the ordering and availability of).
Bridges are systems which allow two blockchains to communicate with each other. Chain A (destination chain) needs to be convinced of some event on Chain B (source chain), and vice versa. Ideally, we want this communication to be bi-directional with strong associated security properties (e.g., high confidence that the message is valid, the source chain will not revert it, etc.).
Fundamentally, a bridge acts as an "observer" of another blockchain (just like any other typical human user). The bridge implements a given confirmation rule by which it is convinced of the state of the connected chain (e.g., how many Ethereum blocks must pass to accept an inbound transfer?).
Bridging from host chain → rollup
This direction is pretty straightforward because rollup nodes fully verify the host. Rollup nodes know everything that happens on the host, so they know when a bridge transaction occurs. Current Ethereum rollup full nodes must also run full nodes for the Ethereum base layer itself.
Note that it would also be possible for rollup nodes to instead run full-verifier light nodes of their host chain if supported. Let's consider a hypothetical example where Ethereum has fully implemented the following upgrades:
Now, say you want to run a full node for an Ethereum-based rollup. To follow the valid rollup chain, you must know Ethereum's canonical chain. This requires checking Ethereum's own consensus and validity:
The rollup node must check the state validity and DA of Ethereum's own execution layer because these are validity conditions for Ethereum blocks. The rollup node needs to know that it's not only tracking the Ethereum chain that consensus has signed off on, but also that it's the valid tip of the chain. For example, they could otherwise be accidentally tracking an Ethereum block that consensus signed off on, but is invalid (e.g., it prints a bunch of ETH).
If the base execution layer itself posts its data to the DA layer (just like other rollups) and adds validity or fault proofs, it would then be an enshrined rollup.
Bridging from rollup → host chain
This direction is trickier because the host chain is by default unaware of the rollup's state and STF (i.e., Ethereum nodes aren't required to run rollup nodes). To convince the host chain of the rollup's state, you can implement the rollup's logic in a smart contract (i.e., the rollup's validating bridge contract) deployed on the host chain. This contract checks the DA and state validity of the rollup.
Again, this bridge is optional. The smart contract on the host chain serves to convince all host chain nodes as to the validity of the rollup. This allows for two-way communication with favorable trust assumptions.
Based on what we just saw, is this a ZK rollup then?
If Cowswap added ZK proofs that solvers must submit with each batch showing optimal execution (by whatever pre-defined rules), is Cowswap a ZK rollup?
Solvers do complex offchain computation over many txs, batch them, prove results and settle back to L1, all data is on L1
— Jon Charbonneau (@jon_charb) September 4, 2023
As discussed, rollup nodes hold some state of their own (the rollup's state) in addition to the state of their host chain (e.g., Ethereum's state). So, does CoW Swap have its own state here that isn't part of the Ethereum state? If yes, then it sounds like a rollup. If not, then it may be a co-processor.
However, even this question isn't quite as simple as it might appear:
Arguably its not stateless in that the definition of optimal here is very much state dependent; that's in fact the crux of the problem OPT(bundle | state) vs. OPT(bundle) are of very different computational complexities
— Tarun Chitra (@tarunchitra) September 4, 2023
You may instead argue that the differentiating factor is the persistence of state:
Yes, but if the trades, prior to entering the solver, agree to be locked + transferred up to some limit, then you've effectively make a "just-in-time" L2 (assets are 'bridged' to the solver)
But yeah, I agree, let's not go into the semantic hinderlands; I just wanted to point…
— Tarun Chitra (@tarunchitra) September 4, 2023
What if CoW Swap permissioned certain actors to give users fast pre-confirmations (faster than Ethereum's block times), committing to the orders that will inevitably go into the batch, because the Ethereum batch times are longer than most users want? Now is it a rollup?
Chris Goes poked around this topic in his talk at Modular Summit. First, he offered an approximate definition for an intent as "a commitment to a preference function over the state space of a given system."
Note the parallels here between partial solving (matching intents) and rollup sequencing. An operator takes users' offchain signed messages → posts resulting data to the host chain.
Intent-centric architectures and rollup-centric architectures approach similar goals from opposite directions. Intent-centricity broadly approaches this from the perspective of users and applications. Rollup-centricity broadly approaches this from the perspective of distinct blockchains.
Where you set the exact boundary on these isn't critical here. More importantly, we see that rollups are actually not so different from applications with offchain intent-matching that we're already used to! You rely on offchain actors (sequencers vs. solvers/fillers/etc.) for some weaker guarantees such as providing best execution and good UX → settle the results based on data posted to the host chain. However, they do not custody your funds.
The line between the two may blur as verifiable offchain compute becomes increasingly relevant:
Basically same idea as trusting like UniswapX fillers not to screw you for examplehttps://t.co/HEzEeQHw17
— Jon Charbonneau (@jon_charb) September 18, 2023
And if you want your intent solvers or rollup sequencers to be less trusted...
4) Any decentralized “intents” based trading system will need consensus for censorship resistance.
At which point it’s… an onchain CLOB.
— Elijah (🥧. 📈) (@PossibltyResult) October 5, 2023
Monolithic blockchains (a.k.a. integrated blockchains) are typically defined as chains which vertically integrate all core functions (i.e., consensus, DA, and execution). They're fully responsible for their own security. Solana and the Cosmos Hub are classic examples.
DA layers (e.g., Ethereum and Celestia) are often referred to as "modular" blockchains because they outsource execution to rollups, but this isn't quite accurate. They're also independently responsible for their own consensus, DA, and execution. Even Celestia will have limited execution (e.g., transfers, staking, bridging). Similarly, Solana wouldn't magically become a "modular" blockchain if someone launched a rollup on top of it.
So, when you hear people refer to chains like Ethereum or Celestia as "modular" blockchains, just realize this is more of a practical distinction rather than a strict technical one. Both are generally optimizing their own architecture to support rollups. These rollups are expected to handle the majority of execution in their domain.
Even rollups aren't necessarily entirely "modular." Rollup sequencers can reach consensus on transaction ordering, provide DA, and execute transactions prior to the host chain doing anything. This is how users get pre-confirmations. The host chain then provides another "final'' commitment, again asserting DA and consensus over the rollup's transaction ordering.
The more important distinction for our purposes here is "rollup" or "not a rollup." Is a chain's final state derived from data posted to a separate host chain (i.e., DA layer)?
While we associate DAS and validity/fault proofs with traditional rollups today, we should note that these are somewhat logically distinct concepts. Any “integrated” chain (e.g., a typical Cosmos app-chain) can in theory upgrade to add DAS and validity proofs without posting its data to some other external host chain like Ethereum. Nodes would sample and check proofs for that chain alone.
Vitalik touched on this distinction in his classic Endgame:
You may notice that a "traditional big block chain" (integrated chain) that adds DAS + validity/fault proofs can eventually just look like an enshrined rollup! Similarly, the "one rollup that scales and dominates" could become so successful that it just merges with its host chain to enshrine that rollup. The boundaries get fuzzy at the limit.
So, if you believe DAS + validity/fault proofs are the endgame, then "rollups" in some sense are inevitable. The distinction is effectively between the two approaches in the chart above:
When we discuss "rollups" throughout this report, we'll be referring to the former (i.e., not an integrated chain with DAS + validity/fault proofs, which may be referred to as an enshrined rollup).
While "traditional" rollups don't have a monopoly on DAS or proofs (i.e., integrated big block chains could add them), note that we're brushing over a lot of technical details here. You can't just take Solana and decide "oh I think we'll add DAS today." This requires fundamentally rearchitecting the protocol in a way that starts to approach what we see Ethereum and Celestia doing:
The isse with tinydancer DASing is that Solana uses a different erasure code for each batch of 32 1280 byte shreds, so it's not actually DASing rn, as you'd have to do a DASing process for each batch
Requires fundamental Solana data structure change to work
— Mustafa Al-Bassam (@musalbas) June 2, 2023
Changing the way that data is encoded to support DAS would equate to slower block encoding and propagation speed, starting to look closer to traditional DA layers again:
The Firedancer figure on this chart is just the computational speed of computing the erasure code and Merkle root of the block. If you want to do an apple-to-apples comparison, Celestia should be 625MB/s on that chart (just benchmarked it on my laptop).
Firedancer is ~2x faster…
— Mustafa Al-Bassam (@musalbas) September 23, 2023
For this reason, we're seeing teams build the following:
However, fast blocks and DAS aren’t necessarily incompatible if you separate the timing of them. For example, you could imagine a chain like Solana offering two different paths:
This is something that Anatoly actually discussed in this podcast earlier today on how Eclipse can bring together Ethereum, Celestia, and Solana.
Coming from the other end of the spectrum, you could imagine a DA layer adding a faster path prior to making the data available for sampling:
mainly that we just need to get the first version out first
fewer blocks means LCs have to sample less
but if we decouple blocks from squares, then we just create a square once every X blocks
trust minimized finality is still just as long. honest majority is very short ~2s
— zkFART (@evansforbes) September 7, 2023
Providing two paths here within the same base layer protocol effectively internalizes fast shared sequencing, providing an interesting design for based rollups. Note that this is still an incredibly exploratory idea at the moment.
Background in hand, we can now start to break down the security properties for these different architectures.
First off, nodes interact with any blockchain by running a confirmation rule:
"A confirmation rule is an algorithm run by nodes, outputting whether a certain block is confirmed. When that is the case, the block is guaranteed to never be reorged, under certain assumptions, primarily about network synchrony and about the percentage of honest stake."
Arbitrarily many confirmation rules can exist for a given chain:
Because each confirmation rule can make very different assumptions, they can have very different security properties even while interacting with the same chain:
(i) Security (both safety and liveness) is always a property of a particular confirmation rule, it is not a property of a chain.
— Sreeram Kannan (@sreeramkannan) March 6, 2023
This distinction is subtle but critical:
The insistence on focusing on confirmation rules is one of the few instances of consensus people being pedantic for a good reason
— Francesco (@fradamt) September 3, 2023
Now let's dive into whether rollups then "inherit security" from their host chain.
Inherit - It's perhaps clearer to say that rollups "rent" rather than "inherit" anything from their host chain. Rollups pay an ongoing cost for resources consumed (DA). Either party may choose to end this relationship. This isn't the interesting half of the question though.
Security - We'll focus on security from here on out. The security of an algorithm is comprised of safety and liveness:
Using Sreeram's great framing, we can break these down further into five properties that together make a confirmation rule secure:
Let's consider an example of a hypothetical integrated chain with DAS + validity/fault proofs. Its data is not posted to any other external host chain. For simplicity, we’ll assume instant finality (e.g., Tendermint), so there’s no available distinction here between an available ledger vs. a finalized ledger (e.g., as in Ethereum’s Gasper).
We'll consider three confirmation rules that could be used to follow the chain using different types of nodes:
To emphasize this again, "We colloquially talk about a chain being secure, but really it is the confirmation rule to which the security property attaches."
Let's look at some examples.
For background, the CAP Theorem tells us that no single ledger can fulfill both conditions:
Consensus protocols tend to be grouped into one of two buckets, with each fulfilling one of the above conditions:
Bitcoin's consensus does not offer any hard economic finality.
Nodes observe the heaviest chain in their local view, and each user is free to apply whatever confirmation rule (e.g., accept blocks with >k confirmations) they're comfortable with. The standard is to wait for 6 block confirmations, but it's up to you. It's reasonable to wait longer for higher value transactions.
There's a tradeoff between wait time vs. safety (i.e., likelihood of a re-org).
Ethereum's PoS consensus (Gasper) may seem to evade the CAP Theorem at first glance. However, it achieves both properties because it explicitly contains two nested ledgers:
Gasper belongs to the family of "ebb-and-flow" (a.k.a. dual-ledger or dual-confirmation rule) protocols. Dual-ledger designs don't fall under the purview of the CAP theorem (i.e., it assumes a single confirmation rule). The finalized ledger falls behind the adaptive ledger when the network partitions, but it catches up when the network heals.
This allows the trade-off between adaptivity vs. finality to be resolved at a user level, rather than at a system-wide level. This is a feature of "checkpointed longest chain" protocols as proposed in Blockchain CAP Theorem Allows User-Dependent Adaptivity and Finality. These protocols offer individual users the choice between finality and adaptivity instead of imposing it at a system-wide level.
Gasper clearly exposes two distinct confirmation rules, mapping to the two ledgers mentioned above:
As discussed in the paper:
"The more optimistic adaptive rule always confirms blocks that are marked as finalized by the more conservative rule, and may possibly confirm more blocks during variable participation levels. Clients (users) make a local choice between the confirmation rules as per their personal preference, while miners follow a fixed block proposal rule that is consistent with both confirmation rules."
This allows for a system where all (honest) nodes:
Validators continue to extend the longest chain (mine new blocks at increasing heights) regardless of participation levels, but new checkpoints appear only if there is sufficient participation. The longest chain (containing the latest checkpoint) may alternate between divergent chains (i.e., re-org unfinalized blocks), but checkpoints are guaranteed to be on a single chain irrespective of network conditions (i.e., finality).
A user's security depends on what confirmation rule they abide by. There's a tradeoff between fast block confirmations vs. stronger safety guarantees. Users selling coffee may prefer liveness over safety, but users selling yachts may prefer safety over liveness.
Ethereum nodes could also apply some other intermediate confirmation rule heuristic for practical uses. Rather than using a naive k-deep rule as in Bitcoin for the adaptive confirmation rule, we can instead add other heuristics which include assumptions regarding network synchrony and validator honesty.
That's exactly what is proposed in A Confirmation Rule for the Ethereum Consensus Protocol. It proposes a confirmation rule with the following properties:
This confirmation rule is not a substitute for economic finality. Rather, it offers a useful heuristic to users who believe that network synchrony will hold for the near future. Let's compare the two:
Let's consider some examples. You're selling a yacht for $2.5mm ETH, and these are some of the possible confirmation rules:
ethereum is an infura’s L2
— donnoh.eth 💗 (@donnoh_eth) May 27, 2023
As with any chain, nodes use different confirmation rules to interact with the rollup. The rollup's strongest confirmation rule will finalize alongside the consensus of its host. Rollup sequencers can expose weaker confirmation rules for better UX (i.e., fast pre-confirmations for impatient users), but users can also wait for the full security of the host chain's confirmation rules.
The typical rollup transaction flow works roughly as follows:
Once the transaction data has been posted to the host chain:
Different observers of the same rollup use different confirmation rules, so they finalize their view of it at different times:
Users could also confirm transactions faster by trusting sequencer pre-confirmations even prior to the host chain receiving the data. Safety can fail if the sequencer misbehaves. Then once the data is on the host chain (and you've checked DA + validity), only a host chain fault (e.g., an Ethereum re-org) would affect your security.
So, even centralized sequencers don't really make "the rollup" less secure. You always get security up to your desired confirmation rule. You can use the same confirmation rule (e.g., wait for host chain finality and check rollup validity) whether a rollup has a based sequencer or some other design. Assuming proper implementation (e.g., forced transaction inclusion via host chain), you can get the same security properties on the same time horizon holding all else equal.
Similarly, you could imagine Ethereum L1 block producers providing pre-confirmations because of the slow block times. That wouldn't make "Ethereum" less secure either. You'd just have another confirmation rule you decide whether or not to use (with lower security) until the higher security becomes available upon Ethereum validators finalizing it.
The idea of pre-confirmations fits very nicely with the logic underlying Gasper as described by Vitalik:
The general principle is that you want to give users "as much consensus as possible": if there's >⅔ then we get regular consensus, but if there's <⅔ then there's no excuse to just stall and offer nothing, when clearly it's still possible for the chain to keep growing albeit at a temporarily lower level of security for the new blocks. If an individual application is unhappy with that lower level of security, it's free to ignore those blocks until they get finalized.
Bringing this all together, we have a "zone of concordance" when all confirmation rules agree on the same state of the ledger at the same time:
When there are multiple confirmation rules, one can ask when the rules *eventually agree* - this defines a “zone of concordance.” The different rules can be thought of pulling the chain in different directions. If you operate outside the zone of concordance, the chain “explodes”.
— Sreeram Kannan (@sreeramkannan) July 25, 2023
You'll probably have worse security if your confirmation rule is to trust a single sequencer run by SBF vs. a decentralized sequencer set with the world's most reputable validators. Liveness failures and re-orgs are security failures.
Alternatively, you can just wait for the stronger (host chain) confirmation rule to become available. Then the untrustworthy sequencer doesn't impact your security holding all else equal. If you're selling coffee, you're probably good to go right away. If you're selling a yacht, you might wanna double check the host chain confirmation.
However, we can't totally ignore the potentially lower security of the "trust the random dude running a solo sequencer" confirmation rule if everyone actually uses that confirmation rule to sell their yachts. The precise design is a balance based on the level of progressive commitment needed at what time for the given use cases.
Similarly, this touches on what is more often the real criticism of high throughput blockchains like Solana. What confirmation rule do people practically have access to? You might have great security properties running a Solana full node, but that confirmation rule may be inaccessible to most people (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. So, we really care about two aspects here with respect to a given confirmation rule - security & accessibility:
DAS + proof style constructions have a heavy emphasis on making confirmation rules with near optimal security highly accessible
— Jon Charbonneau (@jon_charb) September 2, 2023
In summary:
Practically speaking, when we say a given chain is secure, we’re trying to express the notion that its relevant confirmation rules are both secure and accessible.
We see now that security regarding DA and state validity can be checked directly via cryptographic techniques (DAS + validity/fault proofs) without strong assumptions on the chain’s operators. Any protocol can technically implement these. Full nodes can also check DA and state validity with no external assumptions.
Let's focus on those other properties now - liveness and re-org resistance. As we saw before, these may fail regardless of which confirmation rule you're running. Looking again at an integrated chain with DAS + validity proofs + PoS single-slot finality:
Selecting a strong confirmation rule is particularly effective against a subset of safety failures. Even a malicious majority of validators couldn’t trick full nodes or full-verifier light nodes into all believing:
Full nodes are no more or less convinced of a block’s DA or validity whether Ethereum has 1 validator or a gazillion. They’re guaranteed by checking. Full-verifier light nodes can check in an even lighter way (though note that DAS will make some other assumptions that we’ll discuss later).
However, a malicious majority of validators could halt ledger growth, censor you, or re-org the chain (which failures occur depends on the confirmation rule). DAS + ZK can’t save you here. Re-org resistance and liveness are always reliant to some extent on various underlying properties regarding the given chain (e.g., reliable operators, economic incentives, social consensus, etc.).
It’s less apparent here that liveness and re-org resistance are still properties of a given confirmation rule, because every node is subject to the same attacks in the table above. They have the same assurances regardless of the confirmation rule here.
However, it becomes apparent again when you remove the single-slot finality assumption. In Ethereum’s Gasper, you’d again have different liveness and re-org resistance properties depending on which ledger you follow (i.e., the available longest-chain ledger or the checkpoint finalizing ledger). A malicious majority of validators would cause different security failures depending on which confirmation rule you’re running.
In any case, the point is the chain’s underlying construction matters a lot here. You need robust operators, economic incentives, and social consensus to maintain the chain’s liveness and re-org resistance. Additionally, dual-ledger consensus protocols such as Ethereum’s provide valuable flexibility for users to make an availability vs. finality calculation for themselves based on their own needs.
Let's slightly modify that example now:
You'll notice that rollups then have two completely separate classes of confirmation rules for different time frames (i.e., whether you operate based on the sequencers' pre-consensus or wait for the host chain's final consensus). We'll look at each path now.
Fast Path - Prior to Host Chain Consensus
Rollup nodes can rely on the sequencers' confirmations (prior to posting to the host chain). We'll assume they can run the below rollup nodes:
(It's technically possible for rollup sequencers to facilitate DAS and provide validity proofs even before posting to the host chain, but in practice this doesn't happen. Full-verifier light nodes are generally intended to check these via the host chain. However, I'm assuming "real-time" DAS + proofs for a cleaner apples-to-apples comparison to the integrated chain.)
In the table below, these are the changes compared to the integrated chain example:
Deletions are shown in red strikethrough, and additions are in blue:
Slow Path - Wait for Host Chain Consensus
For additional security, nodes can wait for the host chain's (e.g., Ethereum) consensus. This is where it comes into play more clearly that rollup nodes are expected to also run host chain nodes:
Note that it's possible to then verify the rollup's state validity via two different paths:
If we get a ZK-provable host chain (e.g., Ethereum L1 zkEVM) + all rollups prove their state inside of the host chain → we get Vitalik's vision for a proof singularity. Verifying Ethereum's one ZK proof would imply verifying all others chains with verifier nodes implemented inside of it:
For simplicity, we'll assume here that the rollup's state validity is verified within the host chain itself (e.g., the rollup has an enshrined bridge with the host chain), so we can ignore explicitly running additional rollup node software out-of-protocol.
The changes from the previous "fast path" rollup table are noted below:
Now we can see the security property changes associated with integrated chains vs. rollups:
There’s no way to be cryptographically assured of these properties. (One-shot signatures in a quantum setting may in theory be able to guarantee re-org resistance, but this is next level theoretical moon math for the foreseeable future).
Even across confirmation rules (e.g., whether running a full node or a light node), you may be susceptible to security failures here. No full node or ZK proof can protect you from a liveness failure or re-org if the chain operators go totally rogue.
These properties are achieved with robust and decentralized operators, censorship resistant mechanisms (e.g., inclusion lists), liveness-favoring consensus, high “cost” to re-org, strong social consensus, etc. These are often challenging to objectively compare - how do you measure operator decentralization or social consensus? There’s no one right answer. These are arguably the most difficult aspects to engineer, and they are indeed very unique to a given chain.
Importantly, we see that rollups can delegate re-org resistance and liveness to the host chain. Confirmation rules used on the rollup can have up to the same security properties as if they were operating on the host chain at the same timeframe.
Chains can even pick and choose which properties to delegate to which chain. Different types of “L2” architectures (e.g., validiums, optimiums, and sidechains) can absorb different subsets of security properties. For example:
It's also possible for a rollup to provide an escape hatch for users to exit out of the rollup, but retain the ability to censor users and prevent deposits into the rollup (e.g., Loopring works this way). If the deposit isn't processed after some time, the user can then withdraw their locked funds from the L1 contract.
This highlights the importance of such mechanisms:
On Arbitrum, the "escape hatch" (force inclusion) not only allows you to escape but also allows the DAO to elect a new sequencer
— Lee Bousfield (plasmapower.eth) (@PlasmaPower0) July 17, 2023
Unlike liveness and re-org resistance, nodes can be assured of both DA and state validity without making any large threshold assumptions (or without making a security tradeoff between the two). A malicious majority of block producers can cause liveness and re-org failures, but they can’t cause DA or validity failures for full nodes or full-verifier light nodes.
However, consensus-verifier light nodes of course would be subject to state validity and DA failures from an honest majority. They just trust whatever consensus says. That’s why DA and state validity are where making secure confirmation rules accessible really shines. This is often the big difference in ideology between traditional rollups vs. big block chains that place less emphasis on user verification.
In order, these are generally the preferable ways to balance security and accessibility:
Note that #2 (full nodes) is actually the most secure. ZK verification is pretty straightforward, but DAS nodes make some additional assumptions that full nodes do not. However, they provide close to the same security as full nodes with a fraction of the resource requirements. They’re scalable.
Full nodes simply download all the data, so they have 100% certainty. They only sign off on the block if it’s all there. There’s no assumption made on external parties.
The goal of DAS is to get security that’s nearly as good as a full node with massively lower resource requirements (i.e., higher scale). This post on Security levels for data availability for light nodes covers this incredibly well.
In short, you’re generally making some assumptions around network synchronicity and the existence of enough nodes to reconstruct data. Even a small honest minority of light nodes should be able to collectively reconstruct a block if an adversarial block producer withheld any data. There are also assumptions around selective share disclosure where an adversarial block producer could trick some small amount of light nodes individually, but not collectively.
These “few of N” assumptions (e.g., honest minority of nodes to make DAS secure) are highly favorable relative to typical roughly “N/2 of N” assumptions (e.g., 51% of block producers can cause re-orgs), something covered very well in Vitalik’s post on Trust Models.
Overall, DA and state validity aren’t “delegated” by rollups in quite the same way as liveness and re-org resistance. DA and state validity are directly verifiable by the user, whereas the other properties more heavily rely upon the chain’s consensus participants and their incentives.
Looking back to the earlier example of where to verify the rollup’s proof:
You’re assured of validity in either case. You’re no more certain of the validity regardless of where you check it. Ethereum isn’t really “enforcing” validity in the way that Ethereum nodes “enforce” re-org resistance or liveness properties. Re-org resistance and liveness are very dependent upon who you get them from.
Consider a rollup based on Scam Chain:
Rollups have the ability to expose confirmation rules with equivalent security properties as their host chain. They can receive these properties at best at the speed of their host chain consensus (and in practice it's often a bit slower depending on how frequently the rollup posts to the host chain).
Rollups can also make available a "happy path" looser confirmation rule (i.e., sequencers) for better UX, but they retain the fallback in event of failure. If your sequencer halts, you can keep moving. However, this is not the case if your chain is entirely reliant on your own validator set (i.e., as an integrated chain).
Choosing a rollup's host chain wisely makes a concrete difference in security properties. It's particularly valuable to leverage a host chain with strong liveness (ledger growth + CR) and re-org resistance properties.
Let's look at a simple example. Chain X (CX) is deciding whether to deploy as a rollup on an existing host chain (CH) vs. deploy as its own integrated blockchain.
CH has the following features:
CX has the following features:
The table below gives a simplified visual representation of the best security guarantees that CX users could have under various implementations (i.e., they're using the strongest confirmation rule available). In particular, we're looking at liveness and re-org resistance here (since we gave the benefit of the doubt assuming CX will just implement DAS + validity proofs in both scenarios):
The rollup's "eventual security" is higher than its "real-time security" here because the host chain can't give us guarantees faster than its own block time. Even if you can check that the sequencer's pre-confirmations are valid state transitions, you don't have full assurances of their finality until they end up on the DA layer.
As we can see though, deploying as a rollup to a robust host chain can be additive to security. They can rent security at the speed of their host chain. There is fundamentally no way to get the full security properties of the host chain at a speed faster than the host chain's own consensus.
However, users are often impatient. So, rollups typically offer faster pre-confirmations with lower assurances in the interim. A rollup can choose a sequencer design that balances:
Interestingly, you can argue that L1-sequenced rollups have worse liveness than a centralized sequencer depending on your timescale. We've discussed liveness so far as getting inclusion within some notion of "bounded time." However, that's entirely relative and subjective. Relative to what? What amount of time?
A naive L1-sequenced rollup will only ever be included at the speed of the L1 blocks (e.g., 10 seconds). You have no liveness guarantees between those blocks, all while the world is changing around you. So it depends on your benchmark:
If you tried to implement a "true" based rollup without pre-confirmations, it's even possible that pre-confirmations would arise regardless. There's a financial incentive for actors (e.g., Ethereum builders and validators) to give this promise themselves. That's exactly why there's discussion of how Ethereum builders and stakers could try to give fast pre-confirmations even at the base layer.
One last important note here. The assumption that rollup users can fall back to equivalent liveness as the host chain assumes that you can get forced inclusion at exactly the speed of the host chain blocks (e.g., if the rollup sequencer is censoring you, that you can force transaction inclusion in the next Ethereum block).
In practice, there is generally a short delay. If you allowed for immediate forced inclusion, you could expose profitable censorship MEV among other complexities. However, there are designs which may provide near real-time liveness guarantees from the host chain (e.g., perhaps at the speed of a few host chain blocks rather than one block).
Regardless of the exact time scale, absorbing the host chain's eventual liveness is incredibly powerful. Using a robust host chain as a coordination mechanism provides a credible threat and right to exit. Just exposing this credible threat in and of itself makes it exceedingly unlikely for it to ever be needed, preventing the malicious behavior in the first place.
For example, a centralized rollup sequencer can't just arbitrarily extract rent from its users and lock them in if they have a credible mechanism by which they can forcibly exit and even forcibly remove the operator. This is a general area which Chris Goes discussed in his presentation on The Edge of MEV Switching Costs and the Slow Game at Research Day.
Accidental liveness failures can also of course happen, in which case this backup path can again be quite valuable.
Following all this, we can see that proofs more accurately secure different "observers" (users) of a rollup for a given confirmation rule rather than securing "the rollup" itself. The security of "the rollup" does not exist as a single concrete measure.
Keeping observers secure is of course what practically matters because we're all observers of the chain! The chain is whatever its observers say it is. If you can't observe it in a secure manner, you'd have to trust others (e.g., validators) to tell you the "truth" of it. But we don't want to trust, we want to verify → we want proofs.
To see why delineating between "proofs secure the chain" and "proofs secure observers of the chain" is important, consider the following:
I don't know who needs to hear this, but pessimistic rollups are real.
They're rollups that only support full nodes.
Basically how Tether uses Bitcoin as a DA layer.
They're not great for scaling as they don't scale validity checking, but can be used for app-chains.
— Mustafa Al-Bassam (@musalbas) February 24, 2023
Proofs add security to observers of the chain who are unable to directly check its validity (i.e., light nodes). We don't want users to have to run beefy full nodes, so these proofs are important.
If dishonest majority signs an invalid block:
- it will not trick any user having a full node
- it will not trick a rollup validating bridge
- it will trick user running light client
- it will trick a light client bridge or zkBridge (e.g. IBC)
- who knows what MSig bridge will do— bartek.eth (@bkiepuszewski) September 2, 2023
The rollup's validating bridge is one incredibly important observer! Proofs do secure the bridge!
Like any typical light node, the bridge is unable to directly check the rollup's validity. Rather than trust an honest majority, we protect the bridge with proofs. The consensus protocol of Database A (the DA layer) orders data blobs, then the validating bridge independently checks the validity of the corresponding updates to Database B (the rollup):
A bridge is an observer of another chain, and every asset it mints always carries the security assumptions of the bridge's confirmation rule. The security of its confirmation rule can have wide-ranging effects. That's why building secure bridges is so important! (Or ideally reducing the need for so many bridges in the first place by scaling single-chain execution further.)
A malicious party can't trick you into accepting an invalid state transition if you run a full node for that chain. However, a malicious party could still trick a bridge if it has a different confirmation rule. If you hold assets backed by collateral in that bridge, then your funds could become unbacked. Security failures which trick bridges are "contagious" in this sense.
Let's consider an old hypothetical scenario with Terra:
As Terra collapsed, the price of LUNA plummeted. Eventually, the theoretical profit from the validator set turning malicious would surpass the value of LUNA staked. Terra validators could've signed off on invalid blocks which did the following:
So, what security failed here:
The bridge was using a confirmation rule with a much stronger trust assumption.
The Terra validators would not have been able to steal a bunch of assets on Terra itself from full nodes (they wouldn't have been tricked). They would reject these blocks. However, the validators could've tricked consensus-verifier light clients (including the bridge). That's why consensus faults can impact assets across chains.
(Note that these faults are importantly not "contagious" to the rest of the chain. I.e., this fault is "contagious" to Osmosis assets exposed to the Terra bridge route, but there's no safety fault for the Osmosis chain itself.)
However, we obviously want to bridge stuff (and generically, communicate cross-chain). Being limited to only using native assets on their home chain would suck. We need chains to communicate and bridge securely.
As a thought experiment, the naive solution is just to have every user run a full node of every chain. This includes the bridges themselves. Remember, we already see some one-direction embedded full node bridges:
This works with an Ethereum full node, but this obviously doesn't scale. You couldn't start having every Cosmos chain just require running a full node of every other Cosmos chain. These bi-directional full node bridges wouldn't be scaling, they'd just be naively increasing hardware requirements.
Luckily, there’s a more scalable option. We can deploy bridges which fully verify the state validity and DA of the other chain (in addition to still checking consensus).
State Validity - While IBC is used today with traditional consensus proofs, it could be modified to add validity proofs for the connected chain. Now the bridge wouldn’t be tricked by an invalid state transition. This would’ve prevented exactly the attacks described earlier. The bridge would have rejected the Terra validators’ block as invalid if it was able to verify the state transition validity.
This would look quite similar to how rollup bridges on Ethereum check a proof for the rollup, except these could also be bi-directional here.
DA - Additionally, it’s possible for chains to require their nodes to run DAS light nodes of connected chains. For example, you could have these two Cosmos chains require their own validators to run a DAS light node of the other chain (if each chain implemented DAS light clients, which these chains don’t support today). With this in place, each chain would now know the validity and DA of each other, without running a full node.
For rollups, you by definition have all the data on the host chain, so the bridge there has access to it. In the other direction, rollup nodes run host chain nodes.
Let's look at our five security properties one more time, now in the context of a rollup's validating bridge on Ethereum observing the rollup:
Note that the bridge's security isn't just maximized by having a super strong confirmation rule of the attached chain (e.g., a full-verifier bridge to a chain with a super trustworthy validator set). You get the max security in bridging a native asset if the bridge carries the same security assumptions as the home chain.
Vitalik offered a helpful illustrative example:
"You move 100 ETH onto a bridge on Solana to get 100 Solana-WETH, and then Ethereum gets 51% attacked. The attacker deposited a bunch of their own ETH into Solana-WETH and then reverted that transaction on the Ethereum side as soon as the Solana side confirmed it. The Solana-WETH contract is now no longer fully backed, and perhaps your 100 Solana-WETH is now only worth 60 ETH. Even if there's a perfect ZK-SNARK-based bridge that fully validates consensus, it's still vulnerable to theft through 51% attacks like this.
For this reason, it's always safer to hold Ethereum-native assets on Ethereum or Solana-native assets on Solana than it is to hold Ethereum-native assets on Solana or Solana-native assets on Ethereum. And in this context, "Ethereum" refers not just to the base chain, but also any proper L2 that is built on it. If Ethereum gets 51% attacked and reverts, Arbitrum and Optimism revert too, and so "cross-rollup" applications that hold state on Arbitrum and Optimism are guaranteed to remain consistent even if Ethereum gets 51% attacked. And if Ethereum does not get 51% attacked, there's no way to 51% attack Arbitrum and Optimism separately. Hence, holding assets issued on Optimism wrapped on Arbitrum is still perfectly safe."
You can replace Solana with whatever chain you want - even a hypothetical chain where you trust the validators even more than Ethereum's. Fundamentally, any security assumption is additive when you're talking about bridging an asset from its ledger of record (e.g., ETH from Ethereum), and there's always a chance the connected chain can re-org or have a liveness failure.
However, chains which have a merged consensus (i.e., rollups sharing their host chain consensus) can sidestep these additional security assumptions. Bridges between these domains can have the same eventual liveness and re-org resistance properties as the host chain itself. Shared consensus minimizes the bridging trust assumptions within this shared security domain.
What's a reasonable security assumption is for you to decide then. In practice, there have been no consensus failures among major chains like this. It would be plainly visible and costly, but this could be a stronger assumption for bridging to weaker chains.
There are also downsides associated with tying your rollup chain to a host chain. Let’s compare two bridging scenarios, where in both cases we have two chains using bi-directional full-verifier bridging:
Interestingly, these are both good and bad:
Similarly, there are potential positives and negatives regarding lock-in and excessive rent-seeking. This highlights why a neutral and censorship resistant base layer is so important:
There's also some inefficiency in submitting proofs + running DAS bi-directionally rather than sharing a common host chain:
There are tradeoffs and benefits here, but also keep in mind that there's a huge path dependency of where the interesting assets are here. If you want to use a bunch of Ethereum-native assets (including those in its rollups), then rooting your chain around Ethereum and its bridge there makes sense:
it is not possible to build a secure bridge across two entirely separate blockchains that don't share security
it's not fanatic fealty to eth, it's a desire to use the stuff that's already on there, no other chain comes close to having those things
— c-node (@colludingnode) April 18, 2023
"Rollups inherit security" is nice shorthand, but remember these are the key points we really mean:
Now, considering the benefits of deploying a rollup over an integrated chain:
We should see that these are actually two sides of the same coin. Rollups just allow a chain to provide confirmation rules with security up to that of the host chain. Bridges and normie users are both observers of the chain with a given confirmation rule. Bridges are likely the most important "observers" of these chains, as their security has wide-ranging implications.
When we're trying to make secure systems, we need to care about both the security of given confirmation rules as well as the accessibility of them. Secure confirmation rules aren't very helpful if they're out of reach for most observers (users) interacting with these chains.
While we associate DAS and validity proofs with rollups today, they are logically separate concepts. Any chain can integrate these technologies, and the distinction of what is or isn't a rollup starts to break down at the Endgame (i.e., for a single integrated enshrined rollup that may have logically separate DA and execution layers under one protocol). However, "traditional rollups" and DA layers are clearly dominating these verification and scaling technologies today.
Disclaimer: The views expressed in this post are solely those of the author in their individual capacity and are not the views of DBA Crypto, LLC or its affiliates (together with its affiliates, "DBA").
This content is provided for informational purposes only, and should not be relied upon as the basis for an investment decision, and is not, and should not be assumed to be, complete. The contents herein are not to be construed as legal, business, or tax advice. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services. This post does not constitute investment advice or an offer to sell or a solicitation of an offer to purchase any limited partner interests in any investment vehicle managed by DBA.
Certain information contained within has been obtained from third-party sources. While taken from sources believed to be reliable, DBA makes no representations about the accuracy of the information.
The author of this report has material personal investments in stETH, ETH, EigenLayer, Celestia, and SOL. DBA is an investor in Eclipse Laboratories, Inc.
