Partnered With:

Delphi Digital In-depth Report: The endgame of blockchain expansion

Read this article in 30 Minutes

After comprehensive consideration, multi-chain hub may be the most suitable to solve the pressing needs of the blockchain industry

Delphi Digital In-depth Report: The End of blockchain Expansion

Can Gurel, Delphi Digital

Highlights of the report:

1. A monolithic chain is limited by what a single node can handle, while a modular ecology goes beyond this limitation and provides a more sustainable form of capacity expansion;

2. A key motivation behind modularity is efficient resource pricing. Modular chains provide more predictable costs by dividing applications into different resource pools (i.e., expense markets);

3. However, modularity introduces a new problem called data availability (DA), which can be addressed in a number of ways. For example, rollups can batch off-chain data and commit it to the chain. By making "data available" on the chain, they overcome this problem and inherit the underlying security of the base layer, establishing untrust. > L2 communication;

4. The latest form of modular chain, called the Dedicated Data Availability (DA) layer, is intended to serve as a shared security layer for Rollup. Given DA's scalability, it could be the endgame for blockchain expansion, and Celestia is a pioneer project.

5. Zk-rollups offers more extensibility than Optimistic Rollups, which we have observed in practice. For example, dYdX performs about 10 times as well as Why while consuming only one-fifth as much L1 space.

On-chain activities are evolving at breakneck speed, and with that comes the demand for block space.

At its core, this is a war of extensibility, involving technical terms such as parallel chains, side chains, cross-chain Bridges, zones, sharding, rollup, data availability (DA), etc. In this article, we try to cut through the noise and elaborate on the scalability wars. So have a cup of coffee or tea before you strap in, because it's going to be a long ride.

Looking for scalability

Ever since Vitalik came up with his famous extensibility trilemma, there has been a misconception in the crypto community that the trilemma is set in stone and that everything has to be a trade-off. While this is true most of the time, every now and then we see the trilemma boundaries being pushed up (either by genuine innovation or by introducing additional but reasonable assumptions of trust).

We'll highlight some of these examples as we look through the different designs. But before we begin, it's important to define what extensibility means. In short, scalability is the ability to process more transactions without increasing the cost of validation. With that in mind, let's take a look at the CURRENT TPS data for the major blockchains. In this article, we will explain the design attributes that enable these different throughput levels. Importantly, the numbers shown below are not the highest they can reach, but the actual values of historical usage of these protocols.

Monolithic chain VS modular chain

Monolithic blockchain

First, let's take a look at the single-chip chain. In this camp, Polygon PoS and BSC don't fit our definition of scalability because they simply increase throughput through larger blocks (a tradeoff that is known to increase resource requirements on nodes and sacrifice decentralization to improve performance). While such trade-offs have their market fit, they are not long-term solutions and therefore not as compelling. Polygon recognizes this and is moving to a more sustainable solution centered around rollup.

Solana, on the other hand, is a serious attempt at the boundaries of a fully compostable single-chip blockchain. Solana's secret weapon is called a Proof-of-history (PoH) ledger. The PoH idea is to create a global time concept (a global clock) in which all transactions, including consensus voting, carry a reliable timestamp attached by the issuer. These timestamps allow nodes to progress without waiting for each block to synchronize with each other. Solana achieves better scaling by optimizing its execution environment to process tX in parallel, rather than one tx at a time, as EVM does.

Although Solana achieves throughput gains, it is still largely due to more intensive hardware and network bandwidth usage. While this reduces user costs, it limits node operations to a limited number of data centers. This is in contrast to Ethereum, which is ultimately managed by its active users, who can run nodes from home, though not available to many due to its high cost.

How can a monolithic blockchain fail?

The scalability of a monolithic blockchain is ultimately limited by the processing power of a single powerful node. Whatever one's subjective view of decentralization, such capacity can only be pushed hard before governance is limited to a relatively small number of actors. In contrast, modular chains split the total workload between different nodes, thus generating more throughput than any single node can handle.

Crucially, decentralization is only one half of a modular image. Just as important as decentralization is another motivation behind modularity, efficient resource pricing (i.e., fees). In a monolithic chain, all TXS compete for the same block space and consume the same resources. Thus, in the case of blockchaincongestion, excess demand for a single app in the market adversely affects all apps on the chain, as fees rise for everyone. The issue has been around since CryptoKitties caused congestion on the Ethereum network in 2017. Importantly, the extra throughput never really solves the problem, but rather postpones it. The history of the Internet tells us that each increase in capacity makes room for new, unviable applications that often quickly consume the extra capacity that has just been added.

Finally, monolithic chains simply cannot optimize themselves for disparate applications with different priorities. Take Solana, Kin and Serum DEX as an example.

Solana's low latency applies to applications like Serum DEX, however, maintaining such latency also requires limiting state growth, which is enforced by charging a state rent for each account. This, in turn, adversely affects account-intensive applications like Kin, which are too expensive to offer Solana's throughput to the masses.

Looking ahead, it would be naive to expect a single resource pool to reliably support a variety of Crypto applications, from Metaverse and games to DeFi and payments. While it is useful to increase the throughput of fully composable chains, we need wider design space and better resource pricing for mainstream adoption. This is where the modular approach comes in.

The evolution of blockchain

In the sacred mission of capacity expansion, we have witnessed a trend shift from "composability" to "modularity". First, let's define these terms: composability refers to the ability of applications to interact seamlessly with each other in a way that minimizes friction, while modularity is a tool for breaking up a system into multiple individual parts (modules) that can be stripped and reassembled at will.

Ethereum Rollup, ETH 2.0 sharding, Cosmos Zone, Boka parallel chains, Avalanche Subnets, Near chunks, and Algorand sub-chains can all be considered modules. Each module handles a subset of the total workload in its own ecosystem while maintaining cross-communication capabilities. As we delve deeper into these ecosystems, we'll notice that modular designs vary greatly because of the way they implement security across modules.

Multi-linked hubs like Avalanche (Avalanche), Cosmos, and Algorand are best suited for stand-alone security modules, while Ethereum, Polkadot, Near, and Celestia (a relatively new L1 design) envision modules that eventually share or inherit each other's security.

Multi-chain/multi-network Hub

The simplest modular design is called an interoperability Hub, which refers to multiple chains/networks that communicate with each other over standard protocols. Hubs provide a wider scope for design, so they can customize application-specific blockchains at many different levels, including virtual machines (VMS), node requirements, cost models, and governance. The flexibility of an app chain is unmatched by a smart contract on a general-purpose chain, so let's briefly review some examples:

1. Terra supports over $8 billion worth of decentralized staboins with a special fee and inflation model optimized for the adoption and stability of its staboins.

By far the largest transchain DEX Osmosis is handled by IBC, which encrypts TX until they are finalized to prevent front-running.

Algorand Avalanche aim to host enterprise use cases on a custom network. Everything from CBDCS run by government agencies to gaming networks run by the Game Companies Council is possible. Importantly, the throughput of such networks can be increased by more powerful machines without affecting the level of decentralization of other networks/chains.

Hubs also provide scalability advantages because they can use resources more efficiently. In the case of Avalanche Avalanche, C-chain is used for EVM-compatible smart contracts, while X-chain is used for P2P payments. Because payments can usually be independent of each other (Bob pays Charlie and Alice does not depend on Alice paying Dana), the X-chain can process some Tx concurrently. Avalanche Avalanche can handle more Tx by separating the VM from the core utility.

These ecosystems can also scale vertically through radical innovation. Avalanche and Algorand are particularly prominent here because they enable better expansion by reducing consensus communication overhead, Avalanche does this through a process of "secondary sampling voting," Algorand uses cheap VRF nodes to randomly select a unique committee to reach consensus on each block.

Above, we listed the advantages of the Hub approach. However, there are some key limitations to this approach. The most obvious limitation is that blockchains need to guide their own security, since they cannot share or inherit each other's security. It is well known that any secure cross-chain communication requires a trusted third party or synchronization assumption. In the case of the Hub approach, the trusted third party becomes the primary validator of the transaction pair bracelet.

For example, tokens connected from one chain to another via IBC can always be redeemed (stolen) by a malicious majority of source chain verifiers. This majority trust assumption may work well today when only a few chains coexist, however, in a future where there may be long tails of chains/networks, it is far from ideal to expect these chains/networks to trust each other's verifiers to communicate or share liquidity. This brings us to rollups and sharding that provide cross-chain communication and provide stronger guarantees than most trust assumptions.

(Although Cosmos will introduce cross-zone shared pledges, and Avalanche can validate multiple chains across the same network, these solutions are less scalable because they place higher demands on the validator. In fact, they are likely to be adopted by most active chains, not long tail chains)

Data Availability (DA)

After years of research, it's widely believed that all secure sharing efforts boil down to a very subtle issue called data availability (DA), and to understand why, we need to take a quick look at how nodes behave in a typical blockchain.

In a typical blockchain (Ethereum), the full node downloads and validates all Tx, while the light node only checks the block header (the summary of the block submitted by most verifiers). Thus, while the full node can independently detect and reject invalid transactions (such as unlimited token printing), the light node treats anything submitted by most people as a valid TX.

To improve on this, ideally any single full node can protect all light nodes by publishing small proofs. Under such a design, light nodes can operate with similar security guarantees as full nodes without consuming as many resources as possible. However, this introduces a new problem called data availability (DA).

If a malicious verifier publishes a block header but holds back some or all of the transactions in the block, the full node will not be able to determine whether the block is valid because the missing transaction may be invalid or result in a double flower. Without this knowledge, full nodes cannot generate invalid fraud proofs to protect light nodes. In short, for the protection mechanism to work first, the light node must ensure that the verifier has provided a complete list of all transactions.

DA problems are an integral part of modular design and will transcend most trust assumptions when it comes to cross-chain communication. In L2, rollups are special because they don't want to avoid this problem.

Rollup

In rollup's environment, we can think of the main chain (Ethereum) as the light node of Rollup (Arbitrum), which publishes all its transaction data on L1 so that any L1 node willing to put resources together can execute them, And build the rollup state from scratch. With the full state, anyone can convert a rollup to a new state and prove the validity of the transition by publishing a validity or fraud certificate. Having data available on the main chain allows rollup to run on the assumption of a negligible single honest node, rather than an honest majority.

Consider the following to see how rollup can achieve better scalability through this design:

- Since any single node with the current rollup state can protect all other nodes without that state, there is less risk of centralization of rollup nodes and therefore a larger rollup block can be reasonably made.

- Even though all L1 nodes download the rollup data associated with their transactions, only a small number of nodes execute these TXS and build the rollup state, reducing the overall resource consumption.

- rollup Data is compressed using a clever technique before being published to L1.

- Similar to application chains, Rollup can customize their VMS for specific use cases, which means more efficient use of resources.

By now, we all know that there are two major categories of rollups: Optimistic rollup and ZK-rollup, which have an advantage over Optimistic rollup from a scalability perspective because they compress data in a more efficient way, resulting in a lower L1 footprint in some use cases. Such nuances can already be observed in practice.

Optimism publishes data to L1 to reflect each TX, while dYdX publishes data to reflect each account balance. Thus, dYdX's L1 footprint is 1/5 of that of Optimism, and the estimated processing throughput is about a 10-fold difference. This advantage naturally translates into lower costs for the ZK-ROLLup layer 2 network.

Unlike the fraud proof on Optimistic rollup, the validity proof from ZK-Rollup also supports a new extensibility solution called Volition. While the full impact of Volition remains to be seen, they seem very promising because they give users the freedom to decide whether to publish data on or off the chain. This allows users to determine their level of security based on the type of transaction they are making. Both zkSync and Starkware have volition schemes coming out in the coming weeks/months.

Although rollup uses clever techniques to compress the data, all data must still be published to all L1 nodes. As a result, rollups provide only linear scalability gains and are limited in their ability to reduce fees, and they are highly subject to fluctuations in ethereum gas prices. To scale sustainably, Ethereum needs to expand its data capacity, which explains the need for Ethereum sharding.

Sharding and data availability (DA) proof

Sharding further liberalizes the requirement that all main chain nodes download all data, instead leveraging a new primitive called DA proof for greater extensibility. With DA proof, each node only needs to download a small part of the shard chain data, and knowing a small part of it can jointly rebuild all the shard chain blocks. This implements shared security across shards because it ensures that any single shard chain node can raise a dispute, which can be resolved by all nodes as needed. Polkadot and Near have implemented DA proof in their sharding design, which will also be adopted by ETH 2.0.

At this point, it's worth noting how the sharding roadmap for ETH 2.0 differs from other roadmaps. Although ethereum's original roadmap was to be like Polkadot, it recently seems to have moved to shard only data. In other words, shards on Ethereum will act as the DA layer for rollup. This means ethereum will remain as monolithic as it is today. In contrast, Polkadot performs all executions at the base layer where each shard has a different state.

A major advantage of using shards as a pure data layer is that ROLLup has the flexibility to dump data onto multiple shards while remaining fully composable. Therefore, the throughput and cost of rollup are not limited by the data capacity of a single shard. With 64 shards, the maximum total throughput of rollup is expected to increase from 5K TPS to 100,000 TPS. By contrast, regardless of how much throughput the boca as a whole generates, the cost is constrained by the limited throughput (1000-1500 TPS) of a single parallel chain.

Dedicated DA layer

Dedicated DA layers are the latest form of modular blockchain design. They use the basic idea of the ETH 2.0 DA layer, but take it in a different direction. The pioneering project is Celestia, but newer solutions, such as Polygon Avail, are also moving in this direction.

Similar to DA shards for ETH 2.0, Celestia acts as the base layer and other chains (rollups) can be inserted to inherit security. Celestia's solution differs from Ethereum in two fundamental ways:

- It does not perform any meaningful state execution at the base layer (ETH 2.0 does). This frees rollup from highly unreliable base layer fees that, in a stateful environment, can skyrocket as token sales, NFT airdrops, or high-yield farming opportunities arise. Rollup consumes the same resources (that is, bytes in the base layer) for security, and only for security. This efficiency allows rollup costs to be primarily associated with the use of that particular rollup rather than the base layer.

- Celestia can increase its DA throughput without sharding due to DA proof. A key feature of DA proof is that as more nodes participate in sampling, more data can be stored. In the Celestia case, this means that blocks can become larger (higher throughput) as more light nodes participate in DA sampling (without centralization).

As with all designs, dedicated DA layers have some disadvantages. One immediate drawback is the lack of a default settlement layer. Therefore, in order to share assets with each other, rollup must implement methods to interpret each other's proof of fraud.

conclusion

We evaluated different blockchain designs, including monolithic chains, multi-chain hubs, rollup, shard chains, and dedicated DA layers. Given their relatively simple infrastructure, wider design space, and ability to scale horizontally, we believe multi-chain Hubs are best suited to address the pressing needs of the blockchain industry. In the long run, given resource efficiency and unique scalability, dedicated DA layers are likely to be the end of the road.