Skip to main content

How CKB Works

Whether you’re new to blockchain or have a technical background, this guide will help you understand how CKB works. We’ll explore the fundamental components—Cell Model, Scripts, Transaction, and CKB-VM—in a way that’s easy to grasp.

Intro to CKB​

Blockchain is a decentralized, immutable ledger that records transactions across a network, enabling interactions without intermediaries. CKB, or Common Knowledge Base, is the foundational layer of the Nervos Network. It operates on Proof of Work (POW) consensus, where miners solve cryptographic puzzles to secure the network and validate transactions, ensuring strong security and decentralization.

How Transaction Works​

The CKB blockchain works like a storage facility filled with boxes, called Cells. These Cells can hold CKBytes, the native tokens of CKB, which represents both value and storage capacity—the more CKBytes you own, the more data you can store on the blockchain.

The Cell Model defines how these Cells behave, governed by Scripts that set the rules for how Cells can be used or accessed. Once added to the blockchain, Cells are immutable, meaning they can’t be changed. To update a Cell’s data, you must consume it—extract the data, modify it, and create a new Cell with the updated information.

Cells are removed and added to the set of Live Cells

Cells that have not been consumed are known as Live Cells, and these are available for use in future transactions. For example, if you want to send 50 CKByes to Alice from a Live Cell containing 100 CKBytes:

  1. Create: You start by selecting a Live Cell with a capacity of 100 CKBytes. Two new Live Cells will be created as output: one Cell with 50 CKBytes, locked so only Alice can unlock it; another Cell with 49.999 CKBytes locked to yourself as your change. The 0.001 CKBytes difference will be used as the transaction fee.

    Select a Live Cell as input and define two new Live Cells as output

  2. Sign: You sign the transaction with your private key, proving that you have the authority to spend the CKBytes in this Cell.

    Sign the transaction with your private key to unlock the input Cell

  3. Broadcast: After signing, the transaction is broadcasted from your wallet to the nearest CKB network node.

    Transaction broadcasted to the nearest node

  4. Validate: The receiving node performs several checks to validate your transaction. For more details, you can check out the verification process

    Node performs checks to validate your transaction

  5. Propagate: The validated transaction is propagated to other nodes in the network and enters the mempool–a temporary storage area for unconfirmed transactions, waiting for miners to pick up.

    Transaction is propagated to other nodes and enters the mempool

  6. Confirm: Miners will select your transaction from the mempool and include it in a new block. Once the block containing your transaction is mined, it’s added to the blockchain. At this point, your transaction has 1 confirmation.

    Miners select the transaciton from the mempool and include it in a new block. The block is added to the blockchain after validation.

As a result:

  • Your original 100 CKBytes Live Cell is consumed and marked as a Dead Cell.
  • The two new Live Cells (50 CKBytes for Alice and 49.999 CKBytes for you) are now active on the blockchain.
  • With each subsequent block mined, your transaction gains additional confirmations, solidifying its permanence and security in the blockchain.

Scripts​

What is a Script?​

A Script in CKB is a binary executable that can be executed on-chain. It is a program that runs on a virtual machine powered by the RISC-V instruction set, called the CKB-VM, and can perform arbitrary logic to guard and protect your Cells. You can think of it as smart contract.

A Script consists of code_hash, hash_type, and args
  • code_hash : identifies the Script code to be loaded into the CKB-VM
  • hash_type : indicates the the method CKB-VM uses to locate the Script code or Script.
  • args : provides specific arguments that differentiate one Script from another, such as a users’s public key hash.

There’re two main types of Scripts:

  • Lock Script: A required Script controlling the ownership and access to a Cell, ensuring only authorized users can spend its contents.
  • Type Script: An optional Script dictating how a Cell can be used or modified in a transaction.

CKB System Script​

One of the most important system Scripts is the default Lock Script known as secp256k1_blake160_sighash_all. This Script utilizes the secp256k1 elliptic curve and the Blake2b hashing algorithm to ensure that only the owner of the corresponding private key can unlock and spend the CKBytes associated with a given Cell.

For example, if Alice wants to send CKBytes from a Cell that is protected by thesecp256k1_blake160_sighash_all Lock Script, the following process occurs:

  1. The transaction is signed using Alice’s private key. This signature proves that Alice has the authority to spend the CKBytes associated with the Cell.
  2. The public key from the transaction’s signature is hashed using Blake2b to generate a new Blake160 hash. The Lock Script then compares this newly generated Blake160 hash with the one stored in the script_args of the Cell. If the two hashes match, the Script verifies the signature using the secp256k1 curve, ensuring that the signature was indeed generated by the private key corresponding to the public key.

CKB-VM​

The CKB-VM is the virtual machine that executes Scripts on the CKB. It uses the RISC-V instruction set, which is a modern, open-source architecture. This design provides a low-level access to the CPU, enabling highly efficient execution and flexibility.

Script Execution​

The execution of a Script begins when a transaction is submitted to the CKB network. The CKB-VM first invokes syscalls to load the necessary Script code, referenced by code_hash and hash_type into memory. Next, the CKB-VM retrieves relevant data from the Cell and Witness in the transaction through syscalls like ckb_load_cell_data() and ckb_load_witnesses() . Once all necessary components are in place, the CKB-VM executes the Script, which may involve hashing public keys, verifying signatures and comparing these results against stored values to validate the transaction. The CKB-VM ultimately checks the return value of the Script after execution: if the Script returns 0, it indicates successful execution, leading to a valid transaction; if it returns a non-zero value, the CKB-VM considers the execution to have failed, resulting in an invalid transaction.

How CKB-VM process Script

Cycles​

The CKB-VM is designed to be flexible, supporting various control flow constructs like loops and branches. A cycle is a unit that measures the computational cost of executing a Script—each VM instruction or syscall consumes a certain number of cycles. However, this flexibility also necessitates safeguards to prevent malicious behavior, such as Script running in infinite loops. To address this, a cycle limit is introduced at the consensus level through a field called max_block_cycles. This field sets a hard limit on the total number of cycles that all Scripts within a Block can run. If the sum of the cycles in a block exceeds this limit, the block will be rejected.

The current max_block_cycles in CKB Mainnet MIRANA is 3,500,000,000.

Importantly, there is NO limit on the cycles for an individual transaction or Script; they can consume as many cycles as needed, as along as the entire block stays within the max_block_cycles.

To learn more about how cycles are measured for each instruction or syscall, please refer to VM Cycle Limits.

Next Steps​

With the above theoretical knowledge, you're ready to hit the road.

  • Continue with the Quick Start to setup and run your first CKB project.
  • Jump directly to our dApp Tutorials to gain practical knowledge and skills for building on CKB right away.