Beyond L1 and L2: a new paradigm of blockchain construction

A bit of a riff on my previous post about this topic.

As a short recap: we’re heading into a new paradigm where a blockchain’s three broad functions: consensus (or security), data availability and execution can be split arbitrarily. Obviously, large swaths of this post are oversimplified, but it should help you understand this new paradigm. For a more detailed and accurate understanding, please look up these individual constructions. So here are some ways the blockchains of the future could work. All of this definitely has a better presentation in graphical form, but I only do text so here it is. Please feel free to adapt accordingly!

Monolithic

This is how blockchains works currently. They do all of their security, data availability and execution themselves. We have other precursor setups like merge-mined chains, commitchains, but by and large they still fall under the monolithic variety. The key question is: can you reconstruct the state of your chain 1 from another chain 0 if your chain 1 fails? If the answer is no, then it’s a monolithic chain.

Consensus, data availability and execution: all on chain 0.

Examples: Bitcoin, Ethereum, Polygon PoS.

Within the monolithic category, we have multi-chain ecosystems like Cosmos where multiple monolithic chains split the same validator set. Or sharded ecosystems like Polkadot, where multiple chains share the same validator set.

Rollups

Rollups only do execution, while relying on a different chain for security and data availability. (Note: rollups and similar constructions do have full nodes, but these are not required for security.)

Execution: chain 1; consensus and data availability: chain 0.

Example: Arbitrum One, zkSync 2.0. Execution on Arbitrum One, security and data availability by Ethereum.

So far, monolithic blockchains are called L1, and rollups L2. But we have all sorts of other constructions possible now! I do have a potential nomenclature system in mind, but that’s for another time.

Validium

zk rollups that have data availability on a different chain or committee (so they are no longer rollups). The advantage here is that while you’re still relying on the data availability chain, they have significantly limited authority as state root transitions are proved on chain 0. So the consensus mechanism on the data availability chain could freeze your funds, they’d never be able to reorg.

Execution: chain 1; consensus: chain 0; data availability: chain 2.

Example: DeversiFi. Execution: DeversiFi; consensus: Ethereum; data availability: DeversiFi’s committee.

While in this above example the operators of the execution chain also run the data availability consensus mechanism, this could be an entirely different chain. For example, zkPorter could use Celestia, Solana or Avail for their data availability instead of zkPorter’s own consensus mechanism.

Another possibility is centralized validiums, where complete data availability is held by a centalized entity. Hypothetical example: A centralized DeFi chain run by a CEX or financial institution, where they are responsible for complete data availability in centralized databases, but interact with Ethereum smart contracts and commit state transitions to Ethereum mainnet. The advantage here is they can offer very cheap fees while also offering some degree of security and interoperability with public Ethereum.

Data availability

A new breed of L1s with no execution layers, focused entirely on data availability for other chains. They have their own consensus mechanisms purely for data. It’s important to note these chains are useless by themselves, and need other execution chains — whether monolithic or validiums — to leverage them.

Examples: Celestia, Avail, Ethereum data shards. (Though Ethereum data shards will share consensus mechanism with its execution layer.)

Volition

These are zk rollups which have both rollup and validium modes, with data availability on two separate chains, so users or smart contract developers can choose.

Execution: chain 1; consensus: chain 0; data availability: chain 0 (rollup mode), chain 2 (validium mode).

Example: zkSync 2.0. Execution: zkSync 2.0; consensus: Ethereum; data availability: Ethereum (rollup mode), zkPorter (validium mode).

Adamantium

This is part of volition: users can choose to provide their own data availability instead of choosing a chain or committee. I can see this being used by financial institutions, service providers, CEXs etc. Unlike a centralized validium, they wouldn’t need to run their own chain: just use an already existing validium but choose to not pay fees for data availability.

Multi-volition

I just made this up, no such chains exist, and it’s unclear if there ever will. You could say adamantium is part of a setup like this. This is very much like volition, except they use an arbitrary number of chains for data availability.

Execution: chain 1; consensus: chain 0; data availability: chain 0, 2, 3…n.

How this would work: Users on the chain select between, say, Ethereum, Solana, Celestia and Avail for data availability; or a committee, or even themselves (admantium). Each of these may have different security and cost trade-offs. State transitions will always be commmitted to chain 0, Ethereum, but data availability can be split across multiple chains.

Smart contract developers may also choose to use multiple chains for data availability within this volition, so it’s abstracted away from users. For example: A massive game like Fortnite would want to keep most of their data on centralized servers, but perhaps commit high-value NFTs to Ethereum, low-value NFTs to zkPorter etc.

Or, it could be used for redundancy. E.g. a validium may choose to commit on both Avail and Celestia, so if either fails, there’s still a backup. There are some issues around finality, but I think it could be worked out. Potentially, despite paying for both, it could still be significantly cheaper than Ethereum.

Volition-like monolithic

Monolithic chains might choose to branch out by using other chains for data availability, while still maintaining its own consensus mechanism.

Execution: chain 1; consensus: chain 1; data availability: chain 1, 2 (or 3…n).

Currently, no such chain exists, but Polygon has some in the works. These will be sidechains with their own consensus mechanisms, but use Avail for data availability.

As a side note, a monolithic chain can abandons its consensus mechanism and become a rollup. Or keep its consensus mechanism around just for data availability, but post state transitions to a more secure chain, which would make it a validium.

Security chains

While this doesn’t currently exist, the concept here is that L1 no longer has an execution layer: just a consensus mechanism and a minimal data layer that only hosts state transitions and proofs from execution chains (and other simple things like transfers, consensus data etc.), or perhaps coordinates with an execution chain.

Polkadot’s relay chain and Ethereum’s beacon chain are kind of like this. I don’t really see the point of a new chain like this, though, as building a secure consensus mechanism is far and away the hardest part.

zk-monolithic

This is a variant of the traditional monolithic chain with its own consensus mechanism, except its execution layer is a zkVM. So, it still does everything itself, but can get some of the benefits of zk rollups.

Examples: Mina and Aleo; Ethereum in the distant future.

Tl;dr: The future of blockchain is different types of constructions with varying degrees of centralization/decentralization. L1 was the first primitive, L2s are next, and it’s just going to expand from there. Above are just some examples, but there’s going to be a vast number of combinations possible in a multi-chain, multi-layered, departmentalized blockchain world.

Rants and musings on blockchain tech. All content here in the public domain, please feel free to share/adapt/republish.