1. Introduction
1.1 What is Nervos Network and CKB?
Nervos Blockchain | Nervos CKB
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.
1.2 Blockchain basics
1.3 More about Nervos Nerwork
Positioning
Whitepaper
2. Network & Consensus algorithm
2.1 Basics of Consensus
2.2 Network & Consensus of CKB
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.
2.3 LightClient
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.
- rfcs/0044-ckb-light-client.md
- nervosnetwork/ckb-light-client: CKB light client reference implementation
3. Economic model
3.1 Basics of Cryptonomics
3.2 Cryptonomics of CKB
4. Programming model & State Model
5. Account Abstraction and Open Cryptography Primitives
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.
6. How to program with CKB, the layer1
6.1 Basic
-
Introduction to CKB Script Programming 1: Validation Model| by Xiao Xuejie
-
Introduction to CKB Script Programming 2: Script Basics| by Xiao Xuejie
6.2 SDKs
ckb-sdk is a collection of libraries which allow you to interact with a local or remote CKB node by using JSON-RPC. You should get familiar with ckb transaction structure and JSON-RPC before using it. Now ckb-sdk is implemented by the following programming languages: JavaScript/TypeScript, Rust,Ruby,Swift,Java and Go.
- Lumos
- Lumos is a JavaScript/TypeScript framework designed to make backend Dapp development on Nervos CKB easier. Visit the Lumos Tutorial Page for more instructions and step-by-step guidance.
- ckb-sdk-js(deprecated): JavaScript SDK for Nervos CKB.
- ckb-sdk-rust: The Rust SDK for Nervos CKB.
- ckb-sdk-go
- ckb-sdk-go is an SDK implemented in Golang.
- ckb-sdk-ruby
- 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
- ckb-sdk-java is an SDK implemented in Java and provides APIs for developers to send requests to the CKB blockchain.
6.3 Upgradability
There is a contradiction in the application of the blockchain, that is, immutability and upgradeability.
6.4 lockscript & account
Because CKB supports arbitrary cryptographic primitives, there are many lockscript and Auth schemes to choose from.
6.4.1 Design
6.4.2 Code
-
cryptape/omnilock : a lock script designed for interoperability : Recommended
-
cryptape/ckb-combine-lock-poc: A solution that facilitates the combination of lock scripts on CKB.
6.5 Coin & NFT
-
Enhance sUDT’s Programmability with xUDT：Recommended UDT standard
-
Spore Protocol Github， Spore Protocol：Recommend NFT Standard
6.6 Timelock
Due to the Offchain 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.
6.7 Transaction Cobuild
The CKB Transaction CoBuild Protocol describes an off-chain procedure for multiple parties to collaboratively create a CKB Transaction. This includes standard procedures related to transaction building (Building) and signing (Signing), as well as data exchange formats.
6.7.1 Design
6.7.2 Code
- cryptape/ckb-transaction-cobuild-poc: Demonstrate how to adopt Transaction Co-Build Protocol on CKB
- cryptape/ckb-multisig-cobuild-poc
- cryptape/omnilock：Lock to be cobuild-supported
6.8 Layer1.5
6.8.1 Introduction
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.
6.8.2 Design
-
Compact Extension for m-NFT Protocol: The Key to Mass Adoption
-
[RFC] CoTA: A Compact Token Aggregator Standard for Extremely Low Cost NFTs and FTs
6.8.3 Code
6.9 zkSNARKs
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.
-
Building a Zero-Knowledge Virtual Machine on CKB-VM for Privacy-Preserving and Secure Computing
-
cryptape/ckb-bf-zkvm: A BrainFuck zkVM implementation on CKB, using Halo2.
6.10 CKB with Lua
6.11 Development Framworks
Script development frameworks:
- nervosnetwork/capsule: Capsule is an out-of-box development framework for creating smart contract on Nervos’ CKB.
- cryptape/ckb-script-templates:
6.12 OpenTransaction (Deprecated, see Cobuild)
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.
6.12.1 Design
6.12.2 Code
7. Layer2s of Nervos Network
7.1 Godwoken (Rollup)
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.
7.2 Axon (SideChain)
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.
7.3 Perun-CKB (Payment channel)
If you would like to donate to support my writing, please send it to:
CKB:ckb1qzda0cr08m85hc8jlnfp3zer7xulejywt49kt2rr0vthywaa50xwsqdz0v4f6jcd4xz74r3yzxaypsgfcc5wlgc8q4upx
BTC: 35t45FZnm3kXuWfnS5ojrTVkvDNyuNY1UH
ETH: 0x45e0205A6faE242C082D620d8ae436A6d001A956