Disaggregated blockchain layers & evading socioeconomic fragmentation

I have expressed regret multiple times this year for helping propagate the “modular blockchain” meme. There are two significant problems with this: firstly, “modular” is a pretty generic term that has been used by multiple projects to define very different things. The bigger blunder on my part was not talking about socioeconomic fragmentation enough, which led to many misunderstanding “modular blockchains” as meaning different projects should do different things.

I have covered these on Twitter, and in my last post. Here, I’ll make a more concerted effort into correcting my mistakes from 2021.

First, we need a different term. There’s a lot of time wasted as different projects have rightfully appropriated the term for different reasons, some of them years before rollups or data availability layers were conceived. I like the term “disaggregated blockchain layers” (credit: Intel).

I continue to describe “monolithic blockchain” as a blockchain that does execution, settlement, data availability and history all within one layer secured by one honest majority consensus.

“Disaggregated blockchain layer” is one layer of the stack which outsources at least one of the above properties to a different layer. (PS: I like “unbundled blockchain layer” too)

One of my blunders was not considering socioeconomic fragmentation enough, something I explained in my last post. So, it’s very, very important to consider the assumptions added by socioeconomically separating each layer. So, there are two aspects here: technical disaggregation, and socioeconomic disaggregation. The first is very desirable, the latter is very undesirable. Let’s consider the assumptions:

Execution (i.e. rollups): Honest-minority, honest-majority for governance*

Settlement: Honest-majority

Data availability: Honest-majority*

History: Honest-minority

In an ideal situation, you would have a single project that technically disaggregates these layers, but is secured by a single overriding honest majority consensus with a single asset. This is what leads to the highest security and resilience possible. But this is a very tall order. So, where can we compromise?

Straight away, we can see that decoupling history is relatively safe. You just need one honest party. Ideally, we would like the protocol to have an enshrined history layer with incentives, but this is acceptable.

Next, we have execution. Rollups can be secure with an honest minority assumption, and this one honest party can be yourself. But there’s a subtle honest-majority assumption with the rollup’s own governance. With a well-designed governance structure, stringent checks and balances like timelocks this is a pretty weak assumption, but it’s there. Enshrined rollups and immutable rollups are certainly preferred as they have exactly the same assumptions as the base protocol. Given enshrined rollups are difficult and slow to develop, the reality is rollups will exist with their own honest majority governance, so we must ensure they are resilient. L2Beat is leading the charge on this front. With a robust rollup, I think we can get 99% of the way to enshrined rollups, but this is not a given and has to be earned.

The next separation becomes very problematic, as it adds a straight up honest majority assumption — i.e. separating settlement and data availability. (note: not all rollups will settle on layer secured by the same consensus as da, but that’s another can of worms in itself) So, it’s critical for rollups to share the same settlement and data availability layer. Indeed, otherwise it’s not a rollup.

This does not mean we won’t see separation of settlement and data availability — we’re already seeing it — but it’s important to note that this may add a second, critical, honest majority assumption.

Now, there’s a great exception to this — validiums and honest-minority data layers. Because validiums verify validity proofs on the settlement layer, they can function as long as there’s only one honest copy of available data. This enables novel and innovative data availability layers like Adamantium and DataLayr which do not have an honest majority consensus. Nevertheless, this is an additional trust assumption. We must strive to not fragment settlement and data availability — they must share the same consensus.

So, let’s examine the scenarios, relative to the base protocol:

Enshrined rollups, enshrined history: None, identical to the base protocol, the ideal scenario

Enshrined rollup: 1-of-N for history

Regular rollups: 1-of-N for security, 1-of-N for history, potential M-of-N for governance

Validiums: 1-of-N for security, 1-of-N for history, X-of-Z for data availability (until we figure out 1-of-N DA!), potential M-of-N for governance

Sovereign rollups: No secure bridges, so you’re relying entirely on the rollup’s settlement mechanism

The problem is, with each separation of socioeconomic concerns, we have assumptions multiply and stack on top of each other, and they could become relatively fragile systems, at which point while they are far more scalable than monolithic blockchains, they could approach similar security compromises.

Let me make it abundantly clear that with disaggregated layers, we must examine each layer independently. Each project will have different security properties and trust assumptions. It’s quite possible a rollup with very weak governance ends up being less secure in practice than a strong validium with a robust data layer, for example. L2Beat are going to have their work cut out as we see great experimentation in this space!

I’m well aware the “modular blockchain” meme has reached escape velocity, and nothing I say here will change that. I just hope you consider these perspectives that I had missed out on in 2021, and carefully consider the ill-effects of socioeconomic fragmentation. I believe strongly in collaboration and accumulative socioeconomic security — this is the only way we achieve nation-state level resistance.