This article is translated from my article:Idea: 以CKB为Kernel的模块化区块链网络Nervos
1. Overview
As envisioned in the Nervos whitepaper, the Nervos network utilizes Layer2 for unlimited scalability while leveraging CKB as a single-chain Layer1 to store value and maintain asset composability. The difficulty in application development using the Cell model stems from its inherent design, as CKB is just one piece of the layered Nervos network puzzle and sits at the core of the network. Additionally, CKB’s state renting model requires application states to be moved off-chain for modular design, as the available state space on the main chain sets a software upper limit.
However, on the flip side of the challenge in application development, the Cell model elegantly solves many fundamental issues in blockchain using a simple approach. These qualities make CKB more akin to a complete kernel of a blockchain network, serving as the final settlement layer. Most applications don’t need direct access to the settlement layer but can leverage its security guarantees and abstract interfaces.
In a blockchain network, the kernel layer is not the ideal place for application development. A better approach is to build development frameworks and infrastructure on top of the kernel, forming a modular blockchain network. In this network, modules such as Layer2 (state channels, Optimistic Rollup, ZkRollup), sidechains, and specialized data availability solutions revolve around the settlement layer CKB, providing a comprehensive and secure development environment. Developers can choose modules based on their composability and security requirements.
But why is CKB better suited as the kernel? What advantages does it have over other blockchains that make it suitable as the settlement layer? Analyzing some of its unique design features compared to other chains showcases the strengths of CKB as a settlement layer.
1.1 Account Abstraction and Open Cryptographic Primitives
The settlement layer should not make any assumptions about the design of user accounts. In a blockchain network, different applications have diverse requirements for account design. Additionally, within a single platform, an application may have users from different account systems, such as users coming from cross-chains or Web2 users.
CKB provides a comprehensive account abstraction where the permissions for accessing states in the Cell model are controlled by abstract Lockscripts. Combined with the powerful cryptographic primitives implemented by CKB-VM, developers can define accounts in any way they choose. This advantage extends not only to Layer1 DApps on CKB but also to Layer1.5 and GodWoken.
Furthermore, the presence of open cryptographic primitives eliminates the need for hard forks to introduce precompiled contracts for deploying new cryptographic schemes, as required on other chains. Developers can deploy any cryptographic algorithm (such as new pairing-friendly elliptic curves) on their own. This is particularly useful for rapidly evolving cryptographic scaling solutions. Moreover, since all signature algorithms on CKB are implemented as contracts, even in the presence of quantum computers, there is no need for hard forks. It only requires deploying quantum-resistant signature algorithms in advance and migrating assets.
1.2 State Renting
In the settlement layer, state is the most critical resource. With the 1 CKB to 1 Byte on-chain state model and the secondary issuance mechanism, CKB achieves state renting, effectively controlling state growth. Additionally, Layer1 captures the value of the entire network ecosystem.
The size of the state on Layer1 is extremely important for decentralization and security of the settlement layer. Applications built on top of the settlement layer must synchronize the state of the settlement layer to rely on the security of the main chain, in addition to maintaining their own application state. Thus, the inflation of the settlement layer’s state will affect the decentralization of all applications in the network. Furthermore, due to value capture, it can prevent the imbalance between the overall network’s value and the security cost invested in the settlement layer.
1.3 Meta Transactions and Off-chain Determinism Also thanks to the Cell model, transactions on CKB are inherently meta transactions. Fee delegation and even self-paid fees are straightforward. By introducing Open Transactions, transactions on CKB can achieve even more magical functionalities.
Furthermore, another property of the Cell model is off-chain determinism, where a transaction can be validated for correctness off-chain. If no Cells are consumed, valid transactions will remain valid indefinitely.
Off-chain determinism may not be considered an advantage for application development, and it can even be seen as an obstacle since it hinders obtaining on-chain information such as the current block height. However, as the settlement layer, off-chain determinism ensures the robustness of the Layer1 network. Illegal transactions are unlikely to be broadcasted, and multiple off-chain applications can progress independently if they are unrelated.
In addition to the mentioned features, CKB has many other characteristics that make it suitable as the settlement layer, such as its adherence to PoW consensus and its use of CKB-VM designed with a hardware instruction set (RISC-V). The interface of the settlement layer should be as stable and reliable as hardware.
2. Existing Modular Components
Of course, it’s not just Nervos that is striving to construct a modular blockchain network. Other platforms such as Ethereum, Polkadot, and Cosmos are also utilizing different approaches to create a multi-layered network and position themselves at the core. By analyzing the existing roadmap, we can identify modular components that can be used in the Nervos network.
The most fundamental resources in the underlying blockchain infrastructure are state, computation, and networking. Achieving security and scalability in all three aspects simultaneously is not easy. Rollups can provide security close to Layer 1 (L1), but they compete for the network resources of the main chain. Validium sacrifices data availability, leading to the risk of asset loss, while side chains have weaker security guarantees.
As a blockchain network, it is possible to design components that developers can choose from and use in a Lego-like fashion to assemble Web3 applications that meet their specific requirements. Some components (e.g., Validium) can move state off-chain, while others provide data availability guarantees.
2.1 State Channels
The first component is state channels. By constructing a complex network of state channels, many transactions can be completed with minimal on-chain settlement. This pattern is suitable for designing payment applications or turn-based games, for example.
2.2 Rollup
Optimistic Rollup based on fraud proofs and ZkRollup based on cryptographic validity proofs share a common characteristic: they move state and computation off-chain, with on-chain operations limited to certification/validation and providing data availability for compressed transactions. However, data availability remains a significant cost. This led to the emergence of hybrid data availability solutions such as Volition or user-custodied data availability.
2.3 Hybrid Data Availability
Hybrid data availability, such as the Volition approach, allows users to choose whether transaction guarantees are provided by the on-chain mechanism (more expensive but more secure) or by off-chain committees (cheaper but with reduced security). Custom applications built on the Starkware framework have achieved good results using this approach. Additionally, a combination of committee-based data availability and user-custodied data availability can be employed to achieve high availability guarantees.
For serious financial applications, the security guarantees of hybrid data availability may be insufficient. However, for gaming, social, and similar scenarios, a combination of on-chain settlement and hybrid data availability can be a good trade-off between security and cost.
2.4 Data Availability-specific Solutions
While Rollup has achieved the separation of state storage and transaction computation from the main chain, it is challenging to eliminate the network overhead caused by compressed transactions. This has led to the emergence of data availability solutions specifically designed for transaction handling without the need for computation. Examples include Arweave, Celestia, and ETH’s data shard.
2.4.1 Arweave and Celestia
Arweave is a PoW-based public chain focused on permanent storage without computation capabilities. The designers of Arweave and its ecosystem aim to build off-chain computing applications on top of its storage layer, treating Arweave itself as a trusted and reliable storage service. Arweave is responsible for data ordering and storage, but it utilizes probabilistic storage, making it susceptible to Sybil attacks. Moreover, its probabilistic storage, similar to BitTorrent, may not meet the data availability requirements for archiving transaction data.
Celestia, formerly known as Lazyledger, ensures data availability through techniques such as data availability sampling and fraud proofs. Data uploaded to Celestia is processed with two-dimensional erasure coding and then fragmented for distribution. Similar to Arweave, Celestia is responsible for data ordering and storage and prices transactions based on their byte size. Developers can design their own settlement protocols on top of Celestia or use other chains such as ETH for settlement.
2.4.2 Data Availability Shard
The Data Availability Shard, or data shard, is a simple sharding solution chosen when designing execution shards becomes challenging. Since the Ethereum Foundation has decided to develop zkEVM as the off-chain execution layer, combining zkEVM with data sharding would achieve scalability effects similar to execution sharding.
The data shard groups committees into overall subnets, horizontal subnets, and vertical subnets. Each block is processed with erasure coding, and its header is broadcasted in the overall subnet. Data blocks are stored in the corresponding horizontal subnet, and each data block is fragmented and stored in the corresponding vertical subnet. If there are 64 shards, each block is 256KB, and a block is produced every 12 seconds, this solution can ideally provide data availability of approximately 1.33MB/s. Assuming the average compressed transaction size is 128 bytes, the ideal scenario can achieve tens of thousands of transactions per second (TPS).
If the proposed data availability layer can deliver its promised functionality while ensuring strong security and availability, separating the data availability component of the application chain and solving it with a dedicated module becomes an excellent scalability solution. For example, a gaming application chain in the Nervos network settles on CKB, performs state storage and computation on an application chain developed based on Axon, stores compressed transactions in a specific data availability layer, and has lightweight nodes on CKB that can ensure data availability during execution verification. This is a feasible development approach.
However, the question remains: can we fully trust the data availability of these solutions? After all, if the data availability service becomes unavailable, the entire application may be interrupted. Additionally, can these applications guarantee long-term data availability? For transactions and financial applications, the ability to verify the entire history from the genesis block is crucial. Of course, for certain applications that can use state snapshots, the need for long-term data availability may not be as significant.
2.5 Polkadot-style Sharding
Indeed, Polkadot employs an architecture of heterogeneous sharded chains, where collators of parallel chains are responsible for storing state, collecting transactions, applying all transactions, generating validity proofs for transactions, and submitting blocks to the relay chain. The relay chain selects a subset of nodes (typically ten) to verify these blocks, while serving as a light client for the parallel chains. Additionally, the relay chain performs erasure coding and slicing on the blocks before sending them to all validating nodes. However, the relay chain itself only retains parallel chain data for a short period, making it inadequate as a data availability layer for the parallel chains and solely focusing on verifying the correctness of state transitions.
Moreover, due to design considerations, parallel chain blocks require additional supplementary data (validity proof data), and all parallel chain blocks compete for the relay chain’s network resources, limiting the maximum number of parallel chains. Furthermore, by selecting only ten nodes to verify a parallel chain block, even controlling 100 nodes out of 1000 nodes would have a high probability of manipulating the verification process of a specific parallel chain block.
In practice, the Polkadot network is more like a Layer 2 network, where the relay chain acts as Layer 1, and the parallel chains act as Layer 2. However, compared to Rollup, Polkadot mandates that all transactions of parallel chains and their corresponding validity proofs be submitted to the relay chain, which needs to execute all transactions to validate the blocks. In terms of network, state, and computation, Polkadot only places the state off-chain, while the network and computation rely on the resources of the relay chain. This limitation necessitates the selection of a small subset of nodes for verification to balance efficiency, and the relay chain itself does not provide data availability for the parallel chains, resembling Validium with a peculiar security model.
3. Nervos’ Modular Vision
In the modular Nervos network, applications should choose infrastructure modules based on their needs for composability, security, and performance.
Firstly, CKB serves as the ultimate settlement layer and should be designed to be sufficiently abstract, secure, robust, and decentralized. On top of that, there are modular infrastructure components such as the existing Rollup framework Godwoken and upcoming sidechain Axon. Additionally, a modular blockchain network requires an ample number of middleware components, including oracles, on-chain data retrieval, and data availability solutions.
For example, let’s assume there is a PoS sidechain specifically designed for data availability, and a lightweight client is designed on CKB for it. In that case, all applications adopting this solution would need to include the corresponding Cell as CellDeps during settlement to ensure the data’s availability on the sidechain.
However, the modular components of the Nervos network are currently incomplete. For instance, there are very few zero-knowledge proof applications in the Nervos network. Optimizing cryptographic libraries to support zero-knowledge proofs for Nervos network applications is necessary. Additionally, the sidechain framework for application chains is still under development.
From the perspective of applications, for DeFi applications such as swaps, algorithmic stablecoins, and lending, high security guarantees and composability are essential. These applications should run on a shared Rollup platform, utilizing a shared global state to achieve composability. However, for order book DEXs, unlike swaps, although security requirements remain crucial, composability needs are reduced, and there is a higher demand for performance. In such cases, specific zkRollup solutions like DYDX and Fluidex can be employed.
On the other hand, security requirements for blockchain games or social applications are lower compared to DeFi. These applications may only require on-chain settlement without the need to back up transaction data on the blockchain. Transaction data can be stored on a PoS sidechain, designed for data availability, similar to Celestia.
To fulfill the need for decentralization, each user should strive to synchronize the state relevant to their assets, thus reducing the hardware requirements for state synchronization. In such a modular blockchain network, a game user, for example, may only need to synchronize the settlement layer and their game-specific sidechain. For DeFi users, synchronizing the settlement layer and the DeFi platform chain would be sufficient. Consequently, each node and each application in the network provide security guarantees for the entire network while enjoying the benefits of network-wide security. It is not necessary to synchronize the entire network’s state because security guarantees are consolidated at the settlement layer, which exemplifies the shared security in a modular blockchain network.
If you would like to donate to support my writing, please send it to:
CKB:ckb1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqdz0v4f6jcd4xz74r3yzxaypsgfcc5wlgc8q4upx
BTC: 35t45FZnm3kXuWfnS5ojrTVkvDNyuNY1UH
ETH: 0x45e0205A6faE242C082D620d8ae436A6d001A956