0. Rollup’s Bottleneck

If you read the previous post on Rollup I wrote, then you probably noticed that there was an intentional bug in the endgame comparison between Optimistic and zk Rollup.

The conclusion was that Optimistic Rollup would outperform zk Rollup in the long run because there is no proving overhead. But in fact, Optimistic and zk Rollup actually take turns to take the lead in performance over time:

Different types of Secured Rollups have different bottlenecks at different stages, and the main problem for them now is that the data availability module by Ethereum is limiting their peak theoretical performance.

To solve this performance problem of Rollup at this stage, we have two ways:

1. Upgrade the Ethereum mainnet and wait for it to be upgraded successfully, with the disadvantage of not being able to take the initiative, which may take a long time.

2. Switch the type of Rollup (e.g. to Validium), directly using a better performance data availability solution, with the disadvantage of sacrificing security.

1. Blockchain’s Modularity

What we now refer to as Secured Rollup (Arbitrum, etc.), is in fact an implementation of a modular blockchain, and there will be many different modular blockchain implementations, or different variants of Rollup, in the future.

Ethereum’s Rollup roadmap reflects the modularity trend of blockchains, allowing the layers of the blockchain to be separated, each doing its own job, and allowing the network to be “rolluped”.

The previous Rollup article mentions two roads to scaling, one is to upgrade the blockchain itself, and the other is to use the blockchain in a “Rolluped” way to make better use of the blockchain.

Modular Blockchain combines the two routes, 1+1 > 2, completely switching the monolithic architecture of the blockchain, making the new modular blockchain network the most suitable base layer for Rollup to grow, and giving these Rollup solutions more module options and higher performance.

a) Four Modules in Two Layers

A blockchain can be split into two layers, consisting of four modules:

• Security Layer: Ensure the security of the blockchain.

Data Availability Module (called DA in later sections): ensures that transaction data is available (guaranteed to be stored and verifiable and available).

Consensus Module: determines the order of transactions, etc. (PoW, etc., is more like an anti-attack mechanism, and is the basis of consensus but not the whole of it)

• Environment Layer: Provides the execution environment of the blockchain.

Settlement module: Settlement of status commitments.

Execution module: Calculates individual state transitions.

For each layer, the same source for both modules is more secure with fewer trust assumptions, e.g. security with both settlement and execution using Ethereum > security with only settlement using Ethereum and execution using Arbiturm environment.

Monolithic blockchains are represented by Ethereum, Solana, Binance Smart Chain, etc. Secured Rollup are represented by Arbitrum, Optimism, etc. DA layers are represented by Celestia, Polygon Avail, etc.

If we draw an analogy between the blockchain modules and computer architecture, then:

• Blockchain’s execution module ⇒ computer’s operating system (the environment where instructions are actually executed)

• Blockchain’s DA module ⇒ computer’s memory (enables short-term data access)

• Blockchain’s settlement and consensus module ⇒ computer’s CPU (should be hardware to guarantee correct execution of instructions)

In the later sections of article, we will call these “modules” “layers”, but they are actually modules.

b) Modularity Trends from Evolution of Web

We can learn from the development of the Web the future of the blockchain modular development route:

The blockchain network is actually a more decentralized and stable cluster, allowing nodes to pool their computing power and form large trusted computer across the globe.

The modularity of the blockchain is very much like the distributed systems of Web2 (not the same as distributed databases). It is essentially a splitting up of the business logic, similar to the architecture of Uber in the diagram below, where the modules have their own roles.

The modularity of both Web2’s distributed system and Web3’s blockchain brings us to two questions to ponder:

• Splitting: The blockchain network has been parsimoniously split into the two layers and four modules mentioned in the previous section.

• Connecting: Ensuring communication and security between modules. This is why homologous modules are more secure, because no additional connections are needed, avoiding the dangers exposed in the process.

The issue of splitting is well defined, but the issue of connecting has an impact on the modular architecture. How to improve security and user experience may be a problem that needs to be solved for modular blockchains.

c) Why Modularize?

After the modular blockchain decouples the single blockchain, the new network structure = multiple different Rollups like Arbitrum or StarkEx + an underlying main network like Ethereum.

The main focus of their enhancement is that, DAs no longer need to be verified and guaranteed by Proof of Replication due to consensus coupling with traditional monolithic blockchains structure (limiting performance and greatly increasing full node size impacting decentralization).

This means that the modular blockchain network no longer has to compete for the consensus of a single blockchain, but instead decouples and directly uses a dedicated layer to handle DA, reducing the waste of excess arithmetic and storage, increasing throughput, and skipping the consensus problem bottleneck under the priority of main network security, thus further increasing the TPS by thousands or tens of thousands.

What are the significant benefits of a modular blockchain besides the overall performance that can break through bottlenecks and leapfrog to the next era?

• Better Blockchain.

Security: Rollup borrows security from underlying security layers such as Ethereum.

Execution Performance: Flexibility to adopt faster execution or/and settlement modules.

• Composability in development.

Iteration: Modules are decoupled. Modules are more suitable for more radical proposals and faster innovation.

Pluggable: More options for app-chain development solutions and technology stacks.

d) Different implementations of Modularity?

Modular blockchain networks can actually be built with very many types of “chains” in practice, with three main broad categories and countless subcategories:

• Rollup (including Sovereign or Secured Rollup, etc., see previous post. E.g. Ethereum/Celestia Security Layer + Execution Environment / or Execution Module Only.)

• Multi-Monolithic (e.g. Tendermint/Substrate security layer + Cevmos) stack with Recursive Rollup execution module. Celestia itself actually belongs to this architecture, and is a Cosmos ecosystem blockchain.)

• Subnet (The most freely assembled blockchain, not inheriting security, but favoring deployment and development efficiency.)

These three modular blockchains and monolithic blockchains have different general directions and different features:

• Rollup: Lightning fast, but the slowest in development.

• Multi-Monolithic: Shared security, composable and interoperable communications, sovereign application chains, but not necessarily good in performance.

• Subnet: Deployed in seconds, mature solution, but security and decentralization are not always there.

• Monolithic: “Full” freedom, but the solution is not lightweight and the whole system may be too coupled.

e) Impact of Modularity Concept

The traditional concept of L1 and L2 may have to be redefined after the era of modular blockchain.

• Monolithic blockchain: L1 refers to a monolithic blockchain such as Ethereum, L2 refers to Rollup which is a combination of an Ethereum-based security layer and an execution environment.

• Modular blockchain: L0 refers to social consensus and trust assumptions on L1, L1 refers to the security layer (DA and Consensus) of the modular blockchain, L2 refers to the execution environment (Settlement and Execution) of the modular blockchain.

Beyond that:

• Performance measure: Comparison of throughput from consensus TPS and TTF to DA.

• Definition: Note that for a Rollup such as Arbitrum, the Arbitrum network = Arbitrum’s Execution Environment + Ethereum’s Security Layer and Settlement Module. For Ethereum itself, the Ethereum network = the execution environment of Ethereum + the security layer and the settlement module of Ethereum. When the solutions can be modularly deconstructed, they can be called a practice of modular blockchain. And a network such as Ethereum, which is suitable for L1, can be called a modular blockchain network.

• Trend: When applications want more functionality, reduced operational costs or enhanced security, and greater sovereignty, applications can choose from a basket of modules to develop an App-chain or App-rollup or App-subnet that suits their needs.

In the future, perhaps every application will choose to become a modular blockchain.

2. DA Layer

Since Rollup not only ensures security, but also improves performance, why not make the blockchain the best ground for Rollup? Modular blockchain is to make blockchain a better foundation layer for Rollup.

Rollup brought attention to the performance impact of the DA layer, and the emergence of Rollup inspired the concept of a modular blockchain network with a focus on multiple Rollups architecture. Modular blockchains allow blockchains to move beyond the consensus bottleneck of the monolithic era into the DA-focused era of modular concepts.

“Rollup is taking the execution layer off-chain, the next step is to take the DA layer off-chain. “

a) What is DA?

For modular blockchains and Rollup networks, **complete data needs to be there and guaranteed to be available, thus ensuring the network’s **decentralization and security:

Current Data Availability: Why do I need the latest state root and tx data available when a block is produced?

• Because for a new block to be produced, it is necessary to expose all this data in L1 so that other nodes can re-execute it and thus verify it, while keeping the security of light clients (they only check the block header! No invalid transactions are rejected).

Archive Data Availability: After the block is valid, does the tx data need to be kept available forever?

• Yes. For example, if you want to see a transaction from months ago, or if you want to run a node from scratch.

Rollup and Modular Blockchain: What does Current Data Availability mean for Rollup and different future modular blockchain practices?

• Optimistic Rollup: The state root data needs to be available when a new block is created to be validated, and the tx data needs to be available during the challenge period to make the challenge doable and secure.

• zk Rollup: In the case of a sequencer rug, the state root data is needed to rebuild the state and retrieve funds.

b) Current Data Availability

Current Data Availability affects the security and performance of the network itself.

When we talk about DA, we are usually referring to it.

• Monolithic blockchain era:

DA solution: Since consensus is not decoupled from DA, it relies on full node for Proof of Replication.

Data is there: guaranteed by a bunch nodes for Proof of Replication.

Data available: Verify data availability by Linear Complexity of download of full node data.

tx validity: Validate tx validity by re-executing.

Problem: too much redundancy, and if nodes store only a fraction of the data on average, a high probability of losing data (similar to the birthday paradox).

• Modular blockchain era:

DA solution: A dedicated independent DA solution.

Data is there: Data availability is guaranteed through erasure coding (the data scheme used by CDs and satellites).

Data available: Verified in sublinear time by data availability sampling, e.g., downloading only 1% of the block data to get a 99% block availability guarantee.

tx validity: Ensure correct coding and tx validity by bad encoding fraud proofs (similar to Optimistic mechanism) or polynomial commitment or even directly on validity proof (we usually call it zk proof).

c) Archived Data Availability

The archived data availability only affects infrastructure outside the network itself, such as blockchain explorers, which may be optional for the network itself, but necessary for user usage.

The main point we want to make first is that Arweave or Filecoin’s Web3 storage solution does not provide direct DA for Current Data Availability:

• Arweave: SPoRA. Essentially a probabilistic storage under Moore’s Law assumptions and economic models (of course everything is probabilistic…). In use, you usually have to wait for a dozen blocks to confirm that the data “lasts forever”, which is not a good guarantee of instant DA.

• Filecoin: PoSt. Peer-to-peer distributed storage network. Miners who store data can hold on to it, no guarantee of decentralization or DA.

• IPFS: Still mostly present as an infrastructure, used in the network layer of both Polygon Avail and Celestia’s DA.

Otherwise, Arweave and Filecoin are still monolithic blockchains with Proof of Replication redundancy model to ensure data availability, making it difficult to establish efficient sampling mechanisms.

While they are not suitable as “memory” to provide current data availability, they are suitable as “hard disk” to provide archived data availability. Web3 still lacks a more modular and focused dedicated “hard disk”.

3. Modular App-chain Design

We can now act as tech architect for a 10,000 TPS project to make some choices and assemble the right app-chain for our application.

a) DA Layer Landscape

The DA layer has been the focus of much attention recently. However, from our choice diagram, there is no high probability to make “right” so many preemptive choices in a row, and finally proceed to the DA choice.

There are basically three options for the DA solution, besides the most likely private DAC (performance + sovereignty) or sidechain DA solution:

• Maximum security: Consistent with the consensus layer, e.g., both DA and consensus use Ethereum or Celestia.

• Extreme throughput: sacrifice security and add additional trust assumptions, something like off-chain data committee (security is the same as multi-signature, poor).

• Both: get high security and high throughput by restaking mode, e.g. DataLayr.

The business landscape for DA solutions will basically look like this:

• Business model: built for application chains, by providing DAs for a “security fee “ paid by the application chain.

• Competition: The strength of the DA solution is really a comparison between two dimensions: security and throughput. And the better throughput is easily the overwhelming winner.

• Value capture: Since there are not many real-world examples to analyze and compare, we can think about the following questions: If the DA layer has a much lower market value than the application chain (as in the case of Chainlink and DeFi applications), does the entire protocol have a security shortcoming? If the DA layer alone cannot form a complete application ecosystem, how can the tokens capture value? The DA layer alone cannot form a complete application ecosystem.

b) Execution Layer Landscape

If a modular blockchain is compared to a highly compartmentalized kitchen, and the performance of the blockchain is the speed of serving food, then the DA layer with more throughput is the bigger pot, and the better execution environment is the cook who is more skilled and can cook more styles of dishes.

There are also basically several options for execution layer solutions:

• Existing mature solutions: EVM and its ZK or OP variants, WASM and its various variants, etc.

• Future frontier solutions: FuelVM (workflow below in the figure below, so it is faster), AltLayer, etc.

For the execution layer, I think EVM will continue to dominate in the future because of its ecosystem excellence.

For the value capture of cutting-edge execution layer solutions, they can be easily combined into Optimistic Rollups on their own, forming an application ecosystem, so they have a natural advantage over DA layers in terms of value capture.

c) Consensus Layer Landscape

For a modular blockchain, the consensus layer needs to be:

• Security first: ensure the stability and security of the underlying layer.

• Smart contract environment: facilitate on-chain validation of various outputs.

• Social and economic consensus: it needs to be a “well-established” large blockchain, so that no additional trust assumptions are required.

So we are left with few suitable choices:

• Perfectly suitable: Ethereum, Cosmos, etc.

• Barely suitable: Bitcoin, Arweave (no Turing-complete smart contracts on chain, settlement is done on the app-chain), etc.

• Not so suitable: Solana (network is not particularly stable), etc.

• Probably the most suitable: future Celestia, future Ethereum.

4. Thoughts about Modular Solutions

a) Further Exploration

DA layer: The state explosion problem makes the barrier to entry too high and weakens the decentralization of the network. The statelessness we described in the DA paragraph is only weak statelessness, i.e., only the block producers need to store state data, and more optimizations are needed later so that all nodes don’t need to store all the state data.

Execution layer: The current modular division of labor only opens many execution layers (Sharding), and when an execution layer is full, its performance is still not enough to meet Web3 requirements. What we need to extend is more the performance of a single execution layer (Parallelization), such as Fuel and Solana.

b) Demand and Supply

How much demand is there for App-chain?

Only popular apps have demand for App-chain at the moment. We probably need more users onboard before there is a really big demand for modular solutions.

In the meantime, we’ve seen a myriad of modular options, and it will be a process of discovery and selection to determine which ones will actually be actively used.

c) Security

There are two aspects of modularity, splitting and linking:

• Does splitting result in the entire blockchain network having shortcomings? Will that reduce the amount of money needed to attack its shortcomings by a large amount, as a tragedy like the fuse role in the Curve pool that set off Luna?

• The more complex a system is, the more exposed areas are open to attack. Are the “connections” between modules vulnerable (of course Rollup bridges are actually more secure than IBC bridges? (In a previous post we commented on the dangers of composability)

d) Experience

A decentralized modular system may lead to a fragmented user experience and funding simply due to different implementation layers, and will it lead to a fragmented developer experience due to different development tools? Also, how is MEV handled?

e) Divided to United

Similar to Apple’s shift from Intel chips to m-series SoCs, will the fragmented architecture of modular blockchains reunite in a few years due to ecosystem or experiential issues, and will monolithic blockchains return to dominance? Will there be interoperability protocols like Cosmos IBC for modular blockchains?

5. Conclusion

Currently the modular blockchain has only shown the tip of the iceberg, but it is already thriving, with various ethereum-based Secured Rollup, Cosmos, Polkadot, Subnet, etc.

Bitcoin is the concept of blockchain, Ethereum is the implementation of blockchain, and modular blockchain will be the foundation for blockchain to be widely engineered and practiced.

Related Readings

Must-reads:

CyberOrange on DA:

CFG Labs on Celestia:

Rain&Coffee on Modular:

Polynya on Modular:

0:

1:

1a:

1b:

1d:

1e:

2a:

2b:

3a:

3b:

4a:

4c: