The Nervos Network is a layered blockchain network centered around CKB. It utilizes Layer2 solutions to achieve infinite scalability while maintaining the composability of assets. CKB serves as a single-chain Layer1 that stores and preserves value, providing security and state validation services to Layer2.
CKB is a crucial piece of the layered Nervos Network. Although it resides in the core area of the network, Nervos is incomplete without the “graphical interface” and “drivers” that complement CKB Layer1 (the kernel).
To ensure decentralization, security, and sustainability of Layer1 (CKB), an upgraded version of the UTXO model called the Cell model has been adopted in the programming paradigm.
The consensus algorithm used is an improved version of the Nakamoto Consensus known as NC-Max.
In terms of the economic model, a combination of the halving mechanism and secondary issuance is implemented to maintain economic sustainability. Additionally, a state renting mechanism has been introduced.
The network has chosen a layered approach for its scalability roadmap, exploring and implementing solutions such as state channels, Rollups, and sidechains.
The CKB-VM, based on the RISC-V instruction set, has been selected as the virtual machine, as Layer1 should be as stable as hardware.
Native account abstraction is used in the account design, supporting arbitrary cryptographic primitives without the need for added precompiled instructions.
For cross-chain interoperability, CKB’s abstract capability is leveraged to function as a cross-chain hub.
The CKB consensus protocol is a variant of NC that raises its performance limit and selfish mining resistance while keeping its merits. By identifying and eliminating the bottleneck in NC’s block propagation latency, our protocol supports very short block interval without sacrificing security. The shortened block interval not only raises the throughput, but also lowers the transaction confirmation latency. By incorporating all valid blocks in the difficulty adjustment, selfish mining is no longer profitable for a large range of parameters in our protocol.
Downloading and verifying all blocks is taking hours and requiring gigabytes of bandwidth and storage. Hence, clients with limited resources cannot verify transactions independently without trusting full nodes. Even some light clients only download all block headers, the storage and bandwidth requirements of those clients still increase linearly with the chain length. We propose a more efficient FlyClient-based light client protocol. It uses a sampling protocol tailored for NC-Max difficulty adjustment algorithm. It requires downloading only a logarithmic number of block headers while storing only a single block header between executions.
Due to the fact that CKB-VM is a virtual machine based on the RISC-V instruction set, it not only offers high performance but also allows developers to write scripts using advanced languages such as Rust and C. This means you can utilize any cryptography algorithm implemented in C or Rust on CKB without waiting for precompiled instructions to be added to the virtual machine. For instance, you can use various mechanisms like BTC and ETH signature algorithms, passkeys, or email as authentication methods for your CKB accounts.
- ckb-sdk-rust: The Rust SDK for Nervos CKB.
- ckb-sdk-ruby is an SDK implemented in Ruby and provides APIs for developers to send requests to the CKB blockchain. CKB-Explorer utilizes ckb-sdk-ruby.
- ckb-sdk-java is an SDK implemented in Java and provides APIs for developers to send requests to the CKB blockchain.
- ckb-sdk-go is an SDK implemented in Golang.
There is a contradiction in the application of the blockchain, that is, immutability and upgradeability.
Because CKB supports arbitrary cryptographic primitives, there are many lockscript and Auth schemes to choose from.
Due to the off-chain determinism feature of CKB, a CKB transaction cannot directly access the current block height and timestamp. This can pose challenges when designing time-dependent applications. There are two ways to work around this limitation: using the “Since” field or utilizing the “load_header” function to retrieve the timestamp of a specific block that has been already recorded on the chain.
load-header, then you can use the block_number and timestamp of that header.
The Layer 1.5 development paradigm of the Cell model is a design approach that involves storing states off-chain. Here are the main characteristics and principles of the Layer 1.5 development paradigm in the Cell model:
State Storage: Layer 1.5 utilizes vector commitments to store states, where each leaf node represents a state unit. States can include assets, token balances, contract code, etc. Each leaf node can represent a specific state unit, such as non-fungible tokens (NFTs) or accounts. By creating and consuming leaf nodes, state changes and transfers can be achieved.
UTXO or Account Model: Layer 1.5 can adopt the UTXO model, account model, or a combination of both. The UTXO model is suitable for NFT applications and fungible tokens, while the account model is suitable for implementing features like swaps and EVM compatibility.
Cross-Cell Communication: Layer 1.5 requires designing mechanisms for cross-cell communication, enabling information exchange between different cells. Asynchronous communication, synchronous compositional communication, and asynchronous communication are commonly used communication methods.
Time and Sequencer Issues: Layer 1.5 needs to address time-related concerns such as time locks and interest calculations. Sequencer issues can be resolved through global locks, time controls, or unlocking logic in the form of DAOs.
Related Component Requirements: To support Layer 1.5 development, it is necessary to design and develop related components such as state storage components (aggregators), transaction browsers (explorers), and universal identity interfaces, and universal type interfaces.
Development Examples: Development examples of Layer 1.5 include cross-chain asset receivables, personal asset management, asset trading platforms, and blockchain-based games.
By following these principles and utilizing the related components, developers can more easily engage in Layer 1.5 application development using the Cell model and explore its potential for innovation and application possibilities.
CKB Open Transaction is an extensible transaction format, which allows attaching any attribute to the transaction. It divides transaction construction into multiple small steps, each with a different modularised solution. A modular Open Transaction ecosystem could expand the possibilities for CKB DApps while lowering the barrier to development.
Since CKB script programming allows the use of Rust and C languages, theoretically, any zero-knowledge proof library (Arkworks, Halo2, Plonky2, Jellyfish) implemented in these two languages can be used for CKB script development. However, sometimes optimizations are required to minimize off-chain costs. Here is an example that demonstrates the implementation of a Brainfuck virtual machine using Halo2 and verifies the proof on CKB.
Godwoken is an EVM-compatible Rollup built on CKB and is a Layer 2 module within the Nervos Network. Being EVM-compatible, it allows for easy migration of projects developed using Solidity. Developers familiar with Solidity can quickly start developing new projects on Godwoken.
Axon is a high-performance Layer 2 framework with native cross-chain function. Built on top of the Overlord consensus protocol and the P2P network Tentacle , Axon supports hundreds of nodes and achieves thousands of TPS. Axon is also EVM-compatible with well-developed toolchains. Its high interoperability facilitates cross-chain communication among dApps.
If you would like to donate to support my writing, please send it to: