Skip to main content

How CKB Works

To understand CKB, you first need to understand BTC. If you're familiar with BTC, you can directly jump to our next section detailing the unique aspects of CKB. Otherwise, continue reading and take 1 minute to understand the UTXO, the essential component of BTC.

BTC’s UTXO vs. Cash​

BTC works just like cash. To know how much money you have, you simply count the cash in your pocket. In the BTC world, this cash is termed as a UTXO (Unspent Transaction Output).

Features of UTXO
  • Code as a lock: Unlike a piece of paper, a UTXO is more like a locked box. Each box carries a code that can only be unlocked by some predefined conditions. If you have the right keys, you can unlock the box and claim the ownership.
  • Monetary value display: Each UTXO box records the monetary value on its surface much like the denomination on the cash.
  • Divisibility of value: The value of UTXO boxes can be small or large. Larger value boxes can be split into multiple smaller one, allowing for precise value transactions similar to making change in cash dealings.

Now you understand the 80% of CKB, the rest 20% difference is that CKB uses generalized UTXOs called Cell. A Cell is the basic unit of CKB, just like UTXOs to BTC.

But what exactly are generalized UTXOs?

Generalized UTXOs: Understand CKB’s Cells​

UTXOs are like boxes that carry a lock made up of codes, with the monetary value clearly marked on the surface; Cells are boxes too, but much more versatile and powerful.

Dynamic Storage​

UTXO boxes represent a specific amount of BTC and that's all it can hold—just the cryptocurrency value. UTXO boxes cannot expand and do not have the capacity to store additional data.

On the other hand, Cell boxes are different. Each Cell box not only holds a cryptocurrency value but also has storage capacity that can be used to hold arbitrary data. The larger the denomination, the more storage space available. 1 CKB = 1 byte of storage. Thus, if you have 50,000 CKB tokens, you get 50,000 bytes of on-chain storage space as well.

Versatility of Content​

Cell boxes can store any data types, as long as there is enough space to fit them. This feature makes CKB highly flexible, allowing you to store any kinds of information beyond just cryptocurrency value. This is also why CKB is called common knowledge base.

Advanced Coding Capabilities​

Unlike the simple and limited code that UTXOs can carry, Cells can use complex, Turing-complete codes akin to the normal software runing on your computer. You can learn the difference of limited scripts and Turing-complete scripts further.

Dual Lock System​

BTC only has one lock to guard the ownership of the UTXO box while CKB can have two locks for one Cell box.

  • The first required lock is called Lock Script, which is used to safeguard ownership, similar to BTC’s system.
  • The second optional lock is called Type Script, which determines how the boxes can be spent and updated in the future.

Some people are trying to do things like type script to give BTC the ability to limit and determine how the UTXO can be spent and updated in the future transaction, it is called covenant. However, CKB has such ability from the very first beginning due to the design of it. This also makes CKB the ideal layer 2 for Bitcoin since they share the same ideololegy but CKB has more powerful programability.

Good! We have master the most important ideas of CKB. Now let's get to meet its real face.

Data Structure of CKB​

An entire Cell's data structure looks like this:

Cell: {
  capacity: HexString; # represent the total storage space size of the Cell. The basic unit for capcaity is shannon, where 1 CKB equals 10**8 shannons.
  lock: Script; # a piece of code
  type: Script; # a piece of code
  data: HexString; # this field can store arbitrary bytes, which means it can hold any type of data
}
note

The total size of all four fiels above in a Cell must be less than or equal to the Cell's capacity, as shown below:

capacity = Cell's total space >= Sum of the byte lengths of the 4 fields

A Script‘s structure looks like this:

Script: {
  code_hash: HexString
  args: HexString
  hash_type: Uint8, there are 4 allowed values: {0: "data", 1: "type", 2: "data1", 3: "data2"}
}

You might wonder why the code_hash is not the actual code, but rather a kind of index pointing to the code. This index helps us retrieve the code, but where exactly is it stored?

The answer is simple: the code is stored in another Cell!

Here's how it works: the data field of a Cell can hold arbitrary data, so we can put the real code in the data field of another Cell and link this Cell as a dependency to a transaction. This dependency Cell is therefore called CellDep.

code_hash is interpreted differently based on the value of hash_type:

  • If hash_type is "data", "data1" or "data2", then code_hash should match the blake2b_ckbhash(data) of a dep Cell;
  • If hash_type is "type", then code_hash should instead match the blake2b_ckbhash(type script) of a dep Cell.

Keep in mind, code_hash and hash_type are just ways to locate the code. When a transaction needs to unlock a Cell, it imports the dep Cell, and CKB figures out the rest according to these rules.

So why use this indexing method instead of storing the real code directly?

A major benefit of this design is efficiency. If everyone needs the same type of lock, the lock code will be identical, as will the code_hash. This means you only need to introduce the same dep Cell once, avoiding the need to deploy the same code repeatedly for each transaction.

What Is A Transaction?​

A transaction in CKB is simply an action that destroys some Cells and creates new ones.

transaction structure

The Cells in the inputs must all be Live Cells. These input Cells will be spent and become Dead Cells after a transaction is committed. The newly created output Cells will then become new Live Cells.

When a transaction is submitted on-chain, CKB will run all the Scripts in the Cells of that transaction to verify if all Scripts run successfully.

CKB also ensures that the total capacity of all output Cells is less than the total capacity of all input Cells. This means that a transaction cannot mint capacities out of thin air. The difference between the output capacities and input capacities is the transaction fee for miners.

note

In practice, for storage optimization reasons, we do not put the complete Cell in an input; instead, we just put the Cell's index that leads us to the real input Cell. This index structure is called OutPoint, which points to a particular Cell.

OutPoint: {
  tx_hash: HexString # The hash value of the transaction to which the target Cell belongs
  index: uint32 # The Cell position in the transaction to which the target Cell belongs
}

Congratulations!​

Let's review all the concepts we have learned:

  • A Cell is a box that can be used to store any type of data. 1 CKB = 1 Byte storage.
  • The lock's code_hash and hash_type fields are used to locate code, which is stored in the data field of a dep Cell.
  • Each Cell can carry two Scripts, one is called Lock Script (default) and the other, Type Script (optional).
  • Lock Scripts are often used to protect the ownership of the Cell. Type Scripts often used to handle the Cell transformation rules.

Next Steps​

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

  • Continue with the Dev Environment 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.