The hypothesis is straightforward: by disaggregating the key components of a Layer 1 blockchain, we may enhance individual layers separately, culminating in a more composable, scalable, and decentralized system.

Blockchain recap

We need to understand the present blockchain architecture and the constraints that blockchains now face in order to have a thorough discussion on modular blockchains. Let's recap the fundamentals of blockchain. The block header and the transaction data linked to that header are the two parts that make up a block in a blockchain. Blocks are checked for validity by "full nodes," which calculate the entire block's contents and interpret it to make sure, among other things, that users aren't transmitting more assets than their account balance.

Here are the functional layers that make up a blockchain:

Execution: Users often engage with the blockchain through this layer by confirming transactions, implementing smart contracts, and sending assets.
‍Settlement: The settlement layer is where rollup execution is confirmed and conflicts are settled. This layer does not present in monolithic chains and is an optional component of the modular stack. Consider the Settlement layer to be the U.S. Supreme Court, offering ultimate arbitration on disputes.
‍Consensus: The consensus layer offers ordering and finality via a network of complete nodes downloading and executing block contents and achieving consensus on the legitimacy of state changes.
‍Data Availability: This layer should broadcast and store the data necessary to validate a state transition. In the case of an attack in which malevolent block producers withhold transaction data, this should be clearly verifiable. The data availability layer is the primary obstacle for the blockchain scalability trilemma, which we will discuss further below.

Ethereum, for example, is monolithic, which means that the basic layer manages all of the aforementioned components.

Blockchain Scalability Trilemma

Source: Research Gate

The "Blockchain Scalability Trilemma" is a difficulty that blockchains are now facing. Similar to Brewer's theory for distributed systems, blockchain design generally sacrifices decentralization, security, or scalability to give strong enhancement for the remaining two.

The capacity of the network to function in the face of an assault is referred to as security. Because this is a fundamental premise of blockchains and should never be violated, the true tradeoff is generally between scalability and decentralization.

Let's interpret decentralization in the framework of blockchain systems: for a blockchain to be decentralized, hardware specifications must not be a barrier to participation, and the resource needs for network verification must be low.

Scalability is defined as a blockchain's throughput divided by its expense to verify: a blockchain's capacity to accommodate a growing number of transactions while keeping verification resource needs low. There are two primary methods for increasing throughput. To begin, you can raise the block size and hence the number of transactions that can be contained in a block. Unfortunately, bigger block sizes lead to network centralization as the hardware requirements for running complete nodes grow in response to the demand for more computational output. Monolithic blockchains, in particular, face this problem since increasing throughput correlates with increasing the cost of verifying the chain, resulting in less decentralization. Second, you may transfer execution off-chain, reducing the weight of computing away from primary network nodes while leveraging proofs that permit on-chain computation verification.

Through the idea of separation of layers, blockchains can begin to overcome the blockchain scalability trilemma with a modular architecture. Blockchains may grow throughput while keeping qualities that make the system trustless and decentralized by breaking the association between compute and verification costs via a modular execution and data availability layer. Let's look at how this is achievable by discussing fault proofs, rollups, and how they relate to the Data Availability problem.

Fault proofs

According to Vitalik's Ethereum roadmap, a likely settlement between centralization and decentralization is for the future of block production to become centralized toward pools and specialized producers for reasons of scalability, while block verification—which is crucial for maintaining producers' integrity—should remain decentralized. By dividing blockchain nodes into full nodes and light clients, this may be accomplished. This concept is applicable to two issues: block availability (verifying all data has been published) and block validation (validating that the computation is accurate). Let's first investigate its use in block validation.

zk-rollup

Source: Ethereum.org

Light clients merely download block headers and presume the transactions are genuine, whereas full nodes download, calculate, and validate every transaction in the block. For transaction validation, light clients rely on fault proofs supplied by full nodes. As a result, light clients may independently identify erroneous transactions, allowing them to function with almost the same security assurances as a complete node. Light clients believe that state transitions are legitimate by default and can challenge the authenticity of states by getting fault proofs. When a node's state is questioned by a fault-proof, the consensus is reached by a complete node re-executing the necessary transactions, leading to the dishonest node's stake being slashed.

Under the honest minority assumption, in which there is a minimum of one honest full node with the entire state of the chain submitting fault proofs, light clients, and the fault-proof architecture are secure. This model is especially pertinent for blockchains that are divided into shards, such as the architecture of Ethereum after the Merge because validators can choose to run full nodes on only one shard and light clients on the others while still maintaining 1 of N security guarantees across all shards.

The blockchain execution layer is safely abstracted by optimistic rollups using this paradigm to powerful computers called sequencers, which package and process many transactions and occasionally publish compressed data back to the parent chain. Transaction throughput can be increased by 10-100 times by moving this computation off-chain when compared to executing it on the parent chain. How can we be sure that these off-chain sequencers won't do any harm? We present bonds, which operators must stake in order to execute a sequencer. We may then utilize verifiers, nodes that keep an eye out for state discrepancies between a parent chain and its rollup, to deliver fault proofs and consequently reduce the stake of malicious sequencers since sequencers post transaction data back to the parent chain. Optimistic rollups are safe if there is a single trustworthy verifier present in the network because they use fault proofs. Because state transitions are presumed to be legitimate unless proven invalid during a dispute phase, handled in the settlement layer, optimistic rollups get their name from this usage of fault proofs. Allowing computation to become centralized while keeping validation decentralized is how we can grow throughput while reducing trust.

>> Read more: Ethereum Landscape Post The Merge: A Deep Analysis

The data availability problem

While fault proofs can help with decentralized block validation, full nodes rely on block availability to create fault proofs. A malicious block producer may opt to merely broadcast block headers while withholding some or all of the related data, preventing complete nodes from checking and detecting erroneous transactions and, as a result, producing fault proofs. Full nodes can easily detect this sort of attack since they can simply download the complete block and branch away from the invalid chain when they observe discrepancies or withheld data. Light clients, on the other hand, will continue to follow the headers of a possibly faulty chain, forking away from entire nodes. (Keep in mind that light clients do not receive the complete block and that state transitions are assumed to be valid)

As it relates to fault proofs, this is the crux of the data availability problem: light clients must make absolutely sure that all transactional data is delivered in a block before validation, requiring full nodes and light clients to mutually agree on a common header for the canonical chain. Game theory suggests that a fault-proof-based system would be exploited and lead to a lose-lose scenario for honest actors.

The solution

How can light clients ensure that all transactional data in a block is delivered without obtaining the complete block, hence centralizing hardware needs and negating the objective of light clients?

Erasure coding

‍One method is to use erasure coding, which is a mathematical primitive. Erasure coding allows the restoration of a whole block even if a part of the data is lost by replicating the bytes in a block. This technique is used to perform data availability sampling, which allows light clients to ascertain the entirety of a block has been published by randomly sampling tiny bits of the block. This enables light clients to confirm that all transaction data is contained in a certain block before acknowledging it as legitimate and proceeding with the appropriate block header.

Nevertheless, there are a few drawbacks to this method: The security guarantee is based on the premise that there are enough light clients doing sampling to be able to probabilistically assess the availability of a block, analogous to the honest minority assumption.

Validity proofs

Another option for decentralized block validation is to eliminate the requirement for transaction data for state transitions. In contrast to fault proofs, validity proofs take a more negative stance. By eliminating the dispute process, validity proofs can ensure the atomicity of all state transitions, at the cost of demanding proof for each and every state transfer. This is achieved by employing revolutionary zero-knowledge technologies such as SNARKs and STARKs. Validity proofs demand higher computing intensity than fault proofs in exchange for better state guarantees, which has an influence on scalability.

Zero Knowledge Rolllups are rollups that use validity proofs instead of fault proofs to verify the state. They use a sequencer/prover approach, where sequencers conduct computation and provers create the associated proofs, to follow a similar computation and verification strategy as optimistic rollups (but with validity proofs as the schema instead of fault proofs). Starknet, for example, began with centralized sequencers for ramping purposes and plans to gradually decentralize open sequencers and provers. Because of off-chain execution on sequencers, computations on ZK rollups are unbounded. However, because those calculation proofs must be certified on-chain, finality is still constrained by proof creation.

It should be noted that the concept of using light clients for state verification is only applicable to fault-proof architecture. Because state transitions are assured to be legitimate with validity proofs, nodes no longer require transaction data to validate blocks. However, the data availability problem for validity proofs persists, albeit in a more subtle form: despite the assured state, transaction data for validity proofs are still required so that nodes may update and feed state changes to end users. As a result, rollups based on validity proofs are still constrained by the data availability issue.

Other solutions

Vitalik's thesis is: all paths lead to centralized block generation and decentralized block validating. While innovations in block producer technology can dramatically enhance rollup performance, the fundamental scaling limitation is block availability rather than block validation. This leads to an essential realization: regardless of how strong the execution layer is or what proof implementation we pick, our TPS is ultimately constrained by data availability.

‍We presently upload blockchain data on-chain as one method of ensuring data accessibility. The mainnet of Ethereum serves as a data availability layer for rollup implementations, which periodically broadcast all rollup blocks there. This workaround's main drawback is that Ethereum's design currently depends on full nodes to ensure data availability by obtaining the complete block, as opposed to light clients to do data availability sampling. Greater hardware requirements for the complete nodes confirming data availability follow naturally from increasing block sizes to boost performance, centralizing the network.

Ethereum intends to use a sharded architecture that uses data availability sampling and is secured by both full nodes and light clients (technically, Ethereum sharding employs fault proofs rather than KZG commitments, but the data availability problem still applies.) However, this only addresses a portion of the issue as rollup blocks are also leaked to the Ethereum mainnet as call data, which is a fundamental problem for rollup design. Because call data is costly at scale and bottlenecks L2 users at a cost of 16 gas per byte irrespective of rollup transaction batch size, this creates problems later on.

eth batch txn

Source: Ethereum

With validiums, granular transaction data may be transmitted off-chain (with regard to the origin) to a data availability panel, PoS guardians, or data availability layer while still maintaining data availability guarantees. Validiums avoid the fixed byte gas costs connected with greater rollup consumption by transferring data availability from Ether calldata to off-chain alternatives.

‍The unique understanding that blockchains just need to perform the job of ordering blocks and ensuring the data availability of those blocks rather than providing execution or computation itself has also been made possible by rollup architecture. The first modular blockchain network, called Celestia, was created with this as its guiding design concept. Celestia, formerly LazyLedger, started out as a "lazy blockchain," leaving execution and validation to other modular layers and concentrating instead on offering a data availability layer for transaction sequencing and data availability assurances using data availability sampling. The concept of Celestia is based on centralized block production and decentralized block verifiers; even mobile phones may participate as a light client and safeguard the network.

Because of data availability sampling qualities, rollups integrating into Celestia as a data availability layer may enable larger block sizes (and hence throughput) as the quantity of Celestia light nodes rises while keeping the same probabilistic assurances.

Today, other options include StarkEx, zkPorter, and Polygon Avail, with StarkEx remaining the only validium in production. Whatever the case, most validiums provide an implicit assumption of confidence in the data availability resource, whether governed by a trusted committee, guardians, or a generic data availability layer. This trust also implies that fraudulent operators may be able to block users from withdrawing payments.

Current progress

In the present crypto scene, modular blockchain architecture is a widely debated issue. Due to the security problems and extra trust accompanied by a fragmented settlement and data availability layer, the Celestium concept for a modular blockchain architecture has received substantial resistance.

celestium design

Source: Celestia

Meanwhile, tremendous progress has been made across the blockchain stack: Fuel Labs is developing a parallelized VM on the execution layer, while the Optimism team is developing sharding, incentive verification, and a distributed sequencer. In addition, hybrid optimistic and zero knowledge approaches are being developed.

Following the Merge, Ethereum's growth roadmap includes intentions for a single settlement and data availability layer. Danksharding, in particular, is a prospective Ethereum roadmap development that aims to turn and improve Ethereum Layer 1 data shards and blockspace into a "data availability engine," enabling Layer 2 rollups to conduct low-cost, high TPS transactions

A broad range of execution layer technologies can use Celestia's neutral design as a data availability layer, establishing the groundwork for alternative, non-EVM virtual machines such as WASM, SolanaVM and FuelVM. Developers may build trust-minimized bridges across Celestia clusters thanks to the common data availability for a range of execution options. This opens up cross-chain and inter-eco composability and interoperability, similar to what is available between Ethereum and its rollups.

By employing validiums to transport transaction data off-chain or retaining it on-chain, each option has its own advantages and disadvantages, and Volitions, developed by Starkware, offers a unique approach to the on-chain vs. off-chain data availability conundrum.

Additionally, layer 3—fractal scaling—is unlocked by the rising use and popularity of layer 2 solutions. Application developers may now deploy their apps with complete control over their infrastructure, from data availability to privacy, thanks to fractal scaling, which enables application-specific rollups to be delivered on layer 2s. Using layer 3 instead of an application-specific sovereign chain, which requires a pricey base chain, also enables interoperability among all layer 3 apps on layer 2.

The decentralized web is changing from monolithic blockchains and isolated consensus layers to modular, application-specific chains featuring shared consensus layers, much as how web infrastructure changed from on-premise hosts to cloud servers.

Whatever approach and implementation ultimately succeed, one thing is certain: in a modular future, users will be the biggest beneficiaries.

Disclaimer:
This article is intended for and only to be used for reference purposes only. No such information provided constitutes advice or a recommendation that any investment or trading strategy is suitable for any specific name.

Modular Blockchains: A narrative for the future