Rollups = Bridges + Blockchains

The title is a tad click-baity, I agree. :sweat_smile:

I’m not one to complain about click-baity titles here hahahah just funny it’s great

Sovereign rollups do indeed inherit the security of the base chain. In that paragraph I’m excluding them, and my point is that I don’t consider sovereign rollups to be rollups at all. Looking at all different constructions that are talked about, it seems like there are two independent properties: 1) having a trust-minimized bridge, 2) piggybacking/depending/co-opting the base chain’s consensus.
We can imagine a 2-by-2 table with these properties:

  • Has a bridge + co-opts consensus: This would be Based Rollups, for example, and other constructions like it.
  • Has a bridge + independent consensus: Basically every rollup that exists today, having a centralized server is basically a separate chain. Also in this category, rollups that plan to decentralize by implementing their own PoS chain. The example I gave of Ethereum and Near connecting through a trust minimized bridge would also fit in here.
  • No bridge + co-opts consensus: Sovereign “rollups” fit in here.
  • No bridge + independent consensus: These are simply two separate blockchains/L1s. Nothing special here.

For me, it seems weird to consider everything that isn’t separate L1s as rollups. Going back to the example I gave of connecting Ethereum and Near through trust-minimized bridges, if we consider that construction a rollup (and I think we should), then it’s somewhat jarring to also consider sovereign rollups as rollups.

To clarify, I’m not considering everything that isn’t a separate L1 as a rollup. The way I used it was "Rollups are blockchains that post their blocks to another blockchain, and inherit the consensus and data availability (DA) of that blockchain.”

So the Near example here wouldn’t fit that description, although it would have a very interesting bridge in this case.

I would of course call current rollups with a bridge “rollups” (and would still consider them to be rollups even if they implement a PoS set prior to Ethereum consensus). I’d also consider the idea (obviously none are live) of sovereign rollups to be rollups (i.e., those without the bridge). Both constructs post their data to another chain (whether full data or state diffs, enough to reconstruct the full state), and they inherit its consensus and DA.

This works because I’d say that all rollups co-opt the base chain’s consensus, regardless of sequencer implementation. Even if you implement a centralized sequencer or rollup consensus, these are just an additional “pre-consensus” for temporary guarantees, then they eventually defer to the base layer’s consensus. E.g., even with a rollup validator set reaching consensus, this is of course only for pre-confirmations. They’re not finalized until the base layer has also reached consensus and accepted it.

So the base layer consensus is the final arbiter in either case, and of course these “pre-consensus” options for pre-confirmations are equally available to sovereign (i.e., no bridge) and classic smart contract rollups. Either can equally have a centralized sequencer, pre-consensus set, L1-sequenced (based), etc.

(Also open to any definitions hahah, just I think that’s how these would fit in here based on this description which seems helpful to me.)

That’s interesting actually, I haven’t thought of that. Although, if every rollup full node just has a light-client to the base chain, then they would need to be continually asking base chain full nodes for relevant transactions. Not very practical but probably works. But fair enough, it is another type of bridge then, light client bridge, and sovereign “rollups” could indeed work with it. With DAS and validity proofs it could be a very interesting light client bridge. :thinking:

Yea if you want the two-way bridge without a base layer full node, you’d also want L1 validity (or fault) proofs. Though you can also just not have the bridge (i.e., sovereign), in which case you don’t need to keep checking on relevant transactions, you just want to follow the tip of the chain and know that your data is available (and with DAS implemented, you’d know your data is available even if there’s a malicious majority base layer consensus/chain fork, etc.). So it’s not an option to launch a sovereign rollup on Ethereum today like this (as there are no minimized light clients/no DAS yet), in which case you’d definitely need the full node even if you didn’t care about the bridge.

What Anatoly describes is basically an “escape hatch” mechanism. It’s not that different from what most rollups are implementing currently. But I would say that if you have a trust-minimized bridge between two chains then it is a rollup.

So I guess this is the core of it. Based on how I used the term “rollup”:

  • “Sovereign rollups” would indeed be rollups

  • The Near construct wouldn’t be

And based on your description:

  • “Sovereign rollups” aren’t rollups, they’re some other term

  • But this Near construct would be a rollup

So you’re using the rollup definition in a similar manner (possibly the same actually) as how I used “L1” and “L2” definitions. I.e., it’s primarily a description of the security relationship when operating between chains.

I had thought about this a while and ended up going with the description of “rollups” I used because this type of bridging-security relationship felt properly addressed by L1 and L2 already. So it seemed redundant to use rollups in this bridge-centric manner, leaving us without a term to describe the other important relationship (posting data to another chain to inherit its consensus and DA, bridge aside).

Though it seems reasonable to use the terms in the opposite manner, i.e.:

  • If you use rollups as the “bridge-centric” description, as you use it

  • Then it’s probably reasonable to use L1 and L2 to cover the relationship I’m describing with rollups (i.e., you could call sovereign rollups L2s instead, regardless of whether they bridge to the base layer)

I favored the direction I used them, because I think it’s helpful to think of “L1” and “L2” as relative terms, which you seemingly agree with: “That L1 and L2 are relative terms and depend on where a given asset was issued / is native to.”

I’m not sure I want to derail this topic that much! :sweat_smile: It’s probably already going to be a long discussion as it is. But you can DM me if you like and I’ll be happy to share my opinions on shared sequencers too.

Will do!