Understanding the Cell Model of CKB

Time:2019-8-13

When designing CKB, we want to solve three problems:

The tragedy of Commons caused by state explosion and the loss of decentralization;
Computing and validation are coupled together, which makes it difficult to expand and lose flexibility in both computation and validation.
The inherent contradiction between the two goals of transaction and value storage will be amplified by the emergence of Layer 2 and cross-chain, which will have a very negative impact on the economy of Layer 1.

Without an answer to these questions, Layer 1 will not be able to run for long, and the promises that block chains give us will naturally be impossible to talk about. These three problems are rooted in the deepest part of block chain architecture and protocol design. It is difficult to solve them by patching. We must start with the most basic data structure, re-examine the root of the problem and find a more suitable foundation.

Fortunately, this more suitable foundation is so simple and happy that it has always been in front of us. (This article will contain some very simple code that should not affect the reading of non-technical readers…)

What do we learn from Bitcoin

Bitcoin keeps the whole book segmentation in UTXO, which is the abbreviation of Unspent Transaction Output, which is actually the output contained in the transaction (CTO Output). CTO Out has a very simple structure with only two fields:

class CTxOut
{
public:
    CAmount nValue;
    CScript scriptPubKey;
...
}

Each CTxOut represents a coin with a different face value (Yay bit – “Coin”), where nValue represents what the face value of the coin is, and scriptPubKey is a script indicating who the coin owner is (usually containing the owner’s public key). Only those who can provide the correct parameters to make the script run successfully Only then can the coin be “transferred” to another person.

Why quote “transfer”? Because when transferring, instead of simply changing or replacing scriptPubKey in coins, it will destroy and create new coins (after all, the cost of destroying and creating virtual coins in the digital world is very low). Every Bitcoin transaction will destroy a batch of coins and create a batch of coins. New coins will have new denominations and new owners, but the total value destroyed is always greater than or equal to the total value of new coins, so as to ensure that no one can add them at will. Transactions represent changes in the status of books.

Understanding the Cell Model of CKB

The characteristics of such a model are:

Coins (assets) are primary;
The owner is the property of a coin. Each coin has and has only one owner.
Coins are constantly destroyed and created.

Is it simple? If you think you understand Bitcoin and UTXO, congratulations, you also understand CKB and Cell!

Cell

The focus of Layer 1 is state, and the focus of CKB design aiming at Layer 1 is state naturally. Ethereum divides transaction history and state history into two dimensions. Blocks and transactions express events that trigger state migration rather than state itself. The transaction and state in Bitcoin protocol merge into one dimension. Transaction is state, and state is transaction, which is a state-centered architecture.

At the same time, CKB wants to validate and preserve the status for a long time, not just simple numbers (nValue), but data that anyone thinks is valuable and consensual. Obviously, Bitcoin’s transaction output structure can’t meet this requirement, but it has given us enough inspiration: just by generalizing nValue from an integer space to a space where arbitrary data can be stored, we can get a more general “CTxOut”, or Cell:

pub struct CellOutput {
    pub capacity: Capacity,
    pub data: Vec<u8>,
    pub lock: Script,
    pub type_: Option<Script>,
}

In Cell, nValue becomes capacity and data fields, which together represent a storage space. Capacity is an integer, which indicates how large the space is (in bytes), and data is where the state is stored and can be written to any byte; scriptPubKey becomes lock. It’s just a change of name, which means who owns the consensus space – only those who can provide parameters (such as signatures) to make the lock script execute successfully can “update” the status in the Cell. The number of bytes occupied by the entire CellOutput must be less than or equal to capacity.

There are many Cells in CKB, all of which form the current complete state of CKB. In the current state of CKB, any common knowledge is stored, and it is no longer just a digital currency.

Understanding the Cell Model of CKB

Trading still indicates a change/migration of state. Changes in state, or “updates” of Cell content, are actually accomplished by destruction and creation (not really modifying the content in the original Cell). Each transaction actually destroys a batch of Cells and creates a new batch of Cells; the newly created Cells will have new owners and store new data, but the total capacity destroyed is always greater than the total capacity created, thus guaranteeing that no one can freely add capacity. Because capacity can be transferred, it can not be added. Having capacity equals having a corresponding number of consensus state space. Capacity is the original asset of CKB network. Cell destruction simply marks it as “destroyed.” UTXO like Bitcoin has never been spent to become spent, not deleted from the block chain. Every cell can only be destroyed once, just as every UTXO can only be spent once.

The characteristics of such a model are:

State is primary;
Owners are attributes of states, and each state has only one owner.
The state is constantly destroyed and created.

So Cell is a generalized version of UTXO.

Verify

It is not enough to have only one space to hold any state. Bitcoin is valuable because all nodes in the network verify every transaction, so that all users believe (and know that others believe) that the rules written in the Bitcoin protocol (such as the ceiling of 21 million) will be guaranteed.

The reason why common knowledge can become common knowledge is that everyone knows that others recognize it. The reason why block chains can make knowledge become common knowledge is that everyone knows that other people can independently verify it and consequently generate recognition. Any process of consensus includes a series of validation and mutual confirmation, which is the process of forming common knowledge in the network. (It should be noted that validation knowledge is relative to pre-determined validation rules, and the validated knowledge does not represent the truth of the proposition.)

How do we validate the data stored in Cell? At this point, you need another field type in Cell to work. Type, like lock, is a script. Type defines the rules that data stored in the data field must abide by in the process of state migration, which is a constraint on the state. In the process of consensus, CKB network executes type script in CKB-VM to verify that the state saved in newly generated Cell conforms to the pre-defined rules in type. All Cells satisfying the same type constraint hold the same type of data.

For example, suppose we want to define a token called Satoshi Coin (UDT, User Defined Token), what constraints must be met for its state transition? There are only two:

The user must prove that he is the owner of the input token.
At each transfer, the number of tokens entered must be greater than or equal to the number of tokens exported.

The first treaty bundle can be expressed by lock script. If you are interested, you can see the sample code here, which is the same as Bitcoin’s scriptPubKey principle. The second treaty bundle is implemented by hard coding at the bottom in Bitcoin and by type script in CKB. The number of Satoshi Coins represented by each Cell is a state. First, we define its state structure. That is, the state saved by each Cell type equal to Satoshi Coin in data is an 8-byte string, representing the number after serialization:

{
    "amount": "Bytes[8]" // serialized integer
}

In the execution of the type script, you need to read in all the same types of Cells in the transaction (which can be judged by the type field), and then check that the sum of amounts saved in the input Cells of the same type is greater than the sum of amounts saved in the output Cells. So through two scripts, lock and type, we realized the simplest token.

Lock and type scripts can not only read the state saved in their own Cell, but also reference and read the state saved in other Cells, so CKB programming model is a stateful programming model. It is worth noting that Ethereum’s programming model is more powerful because of its state than because of its limited Turing completeness. We can save the type script in a separate Cell and refer to it in each Satoshi Coin Cell type field. The advantage of this is that the same type script only needs one space to save. Cell that stores the definition of digital assets like this is called ADC (Asset Definition Cell).

Another feature of Satoshi Coin is that records between specific assets and owners are stored in separate Cells, which can be provided by developers to users, owned by users themselves, or even rented. Only when the ownership of consensus space is clear can the owner really own the assets stored in the consensus space (any data is an asset). On CKB, because users can really have consensus space, users can really own digital assets (when you can really own land, you can really own houses on land).

Cell is an abstract state validation model. Cell provides storage without any internal structure. Cell supports arbitrary state validation rules (type) and ownership validation rules (lock). We can simulate UTXO model on Cell model (like atoshiCoin above) or build A on Cell model. Ccount model. The lock script is executed when validating the transaction input to ensure that the user has ownership of the input and has the right to destroy the input Cells; the type script is executed when validating the transaction output to ensure that the new state generated by the user conforms to the type constraint and generates the new Cells correctly. Because of the different state models and the separation of computation and verification, the programming model of CKB is very different from that of Ethereum. What is the best practice of CKB programming model still needs a lot of exploration.

Understanding the Cell Model of CKB

General Verification Network

Bitcoin is a Verification Network. When transferring money, the user tells the wallet/local client the number of transfers and the payee that the wallet calculates according to the information provided by the user, finds the appropriate number of coins (UTXO) owned by the user locally, and generates a batch of new coins, some of which belong to the payee, some of which are for change. The wallet then packs the spent coins and the newly generated coins into a transaction, broadcasts the transaction, verifies the transaction on the network, and packs the transaction into a block, and completes the transaction.

In this process, the nodes in the network do not care how the old state (destroyed coins) is searched out, nor how the new state (new coins) is generated. They only care that the total face value of these coins remains unchanged before and after the transaction. In the transfer process, the calculation is completed at the user end, so the user can determine what the calculation result (new state) is when the transaction is sent.

Ethereum is a General Computation Network. When using DApp, the user tells the wallet/local client what operation they want to perform. The wallet packages the user’s operation request into the transaction as it is and broadcasts the transaction. After the network node receives the transaction, it calculates the current state of the block chain and the operation request contained in the transaction, and generates a new state. In this process, the calculation is completed at the far end, and the result of the transaction (new state) can only be determined after the transaction is packaged to the block. The user can not completely determine the result of the calculation when the transaction is sent.

Understanding the Cell Model of CKB

(In the figure, above is the Ethereum process, which contains user requests or event / Event in the transaction; below is the Bitcoin / CKB process, which contains the state / state generated under the chain.)

CKB is a general Verification Network. When using DApp, the user tells the wallet/local client what operation they want to perform, and the wallet calculates the current status and user’s operation request to generate a new state. In this process, the calculation is completed at the user end, and the calculation result (new state) is determined when the transaction is issued.

In other words, both Bitcoin and CKB are computational before consensus, while Ethereum is computational after consensus. Interestingly, there are the same factions in the licensing chain architecture: Fabric is computing before consensus, and CITA (actually not just licensing chain) is computing after consensus. (Question to Consider: Which Architecture is Better for Licensing Chain?)

The separation of computation and verification also makes Layer 2 and Layer 1 naturally separate. Layer 1 is concerned with what the new state is, not how it is acquired. Whether State channel, Plasma or other Layer 2 schemes, their essence is to calculate outside the chain and submit the final state to Layer 1 for verification at a specific time.

Understanding the Cell Model of CKB

Why is the Cell model of CKB better?

Now we have a very different underlying data structure, on which we have designed a unique economic model. Is this really a better result? Looking back on the first three questions may give us some inspiration.

Capacity is a primary asset, which is restricted by the pre-determined issuance rules and its total amount is limited.
Capacity is also a measure of the state, how much capacity, how much data can be put on the CKB, the maximum value of the state space of CKB is equal to the total capacity, and the state saved on the CKB will not exceed the total capacity.

These two points determine that CKB will not explode in a state. In the case of appropriate capacity distribution rules, the network should be able to maintain a long-term de-centralized state. Every Cell is an independent state with a clear owner. The state space originally belonging to public resources is privatized and valuable consensus space can be used more effectively.

CKB is a universal verification network. Computing and verification are separated, and their flexibility and scalability are improved. More computations are pushed to the client to execute. Computing takes place closer to the scene and data. Data processing methods are more flexible and tools are more diverse. This also means that in the CKB architecture, wallet is an entrance that can do more and have more capabilities. On the verification side, because the calculation results are fully determined, the dependency analysis of transactions becomes very easy, and the parallel processing of transactions is also easier.

In the Cell-based economic model, the cost of storage is proportional to the size and time of occupied space. Miners can get corresponding benefits by providing consensus space. The Utility provided by CKB is a secure consensus space. Its value comes from its security and accessibility, not from transaction processing capability (TPS). It complements Layer 2’s transaction characteristics and has better value capture capability in layered and cross-chain networks.

Finally, CKB is not…

IPFS

CKB is a kind of storage, which may be confusing: “Isn’t this IPFS / Filecoin /(any distributed storage)?” “

CKB is not distributed storage, the key difference is that distributed storage only has storage, without verification, it will not form a consensus on its stored data. The capacity of distributed storage can grow proportionally with the growth of storage technology, while the capacity of CKB is limited by the efficiency of forming a global consensus.

CKB does not need to worry about insufficient capacity. In Layer 2 and the mature stage of layered technology, in extreme cases, a Merkle root may be enough on Layer 1. The state required for validation on Layer 1 can also be submitted to the node through transaction. The node verifies that the state is valid through Merkle proof. On this basis, the state migration is valid. Some research has been done in this direction.

Qtum

Qtum is one of the pioneers in attempting to introduce stronger intelligent contracts into UTXO models by keeping Bitcoin’s original UTXO model unchanged and introducing Account Abstraction Layer to support EVM or x86 virtual machines.

In Qtum, the verification of Bitcoin is the first layer, and the computation of EVM is the second layer (note that this is a layer within the block connection protocol, not Layer 1 and Layer 2). Qtum modifies scriptPubKey’s processing logic in UTXO to achieve the effect of passing the request carried in Bitcoin Transaction to EVM for execution after the transaction is packaged.

Qtum bridges Bitcoin and Ethereum’s execution model. The network node first verifies the transaction input (with Bitcoin) and then invokes the contract to calculate (with Ethereum). The state is dispersed in UTXO model and EVM’s own state storage. The overall architecture is complex.

What CKB does is to inherit Bitcoin’s idea of architecture and get Cell model by generalization of UTXO model. The overall architecture maintains consistency and the simplicity of Bitcoin. All states on CKB are in Cell, computation is done under the chain (similar to Bitcoin), and network nodes only verify.