Cell Model
By: Jan Xie
Tags: Technical, Blockchain, Nervos, Utxo, Bitcoin

A generalized UTXO as state storage

When designing the Nervos Common Knowledge Base (CKB), we wanted to solve three problems:

The tragedy of the (storage) commons and the loss of decentralization caused by state explosion; The lack of flexibility and scalability due to the coupling of computation and verification; The contradictions that exist between the demands for transaction throughput and value storage. Layer 2 and cross-chain implementations will aggravate these contradictions and thus have negative economic impacts on Layer 1.

If the above problems fail to be resolved, Layer 1 will not run for long, let alone fulfill its great promise. These problems are rooted in the underlying blockchain architecture and protocol, making them difficult to solve with patches. We have to reexamine the root of the problems at the underlying data structure and seek a more appropriate base. Fortunately, this base is excitingly simple and nearly here.

“CKB inherits the ideas of Bitcoin’s architecture and creates the Cell model from generalizing the UTXO model, retaining the consistency and simplicity of Bitcoin. In Nervos CKB, all the states are stored in Cells, all computation is done off-chain, and all the verification work is handled by nodes.”

What Have We Learned from Bitcoin?

Bitcoin splits the whole ledger into parts and saves each of them into a UTXO. A UTXO, short for Unspent Transaction Output, is actually the output included in a transaction(CTxOut). A CTxOut is quite simple in structure, which includes only two fields:

Every CTxOut represents a coin with its own denomination (Yay bit-”Coin”), which is defined by nValue. scriptPubKey is a script which indicates the owner of the coin (and usually refers to the public key of the owner). Only the person who provides the right input that make the script run successfully can “transfer” the coin to another person.

Destroy and create UTXOs in transaction processing

Note the quoted “transfer” above mentioned. When a coin is transferred, it does not simply mean to alter or replace the scriptPubKey in it, but to destroy it and create a new one (doing this has very low cost in the digital world). Every Bitcoin transaction will destroy some coins and create new ones, whose value and the owner will change. The total value of the destroyed coins must be larger than or equal to that of the newly created coins, so as to avoid inflation. Transactions reflect the changes of ledger state.



Such a model has the following features:

Coin (Asset) is the most essential element in the system; Owner is an attribute of coin, and each coin has only one owner; Coins are constantly being destroyed and created;

Isn’t this quite simple? If you understand Bitcoin and UTXO, Congratulations! It is now very easy for you to understand CKB and Cell :)

Cell

The focus of Layer 1 is on the state, so the design of CKB as Layer 1 should also lay emphasis on state. In Ethereum, transaction history and state history are two different dimensions. Blocks and transactions represent the events that trigger state transfer, instead of the states themselves. In the Bitcoin protocol, transactions and states are merged into a single dimension. Bitcoin’s architecture is centered on states.



A state verified and held by CKB is not simply a number (nValue), but any data that is considered as valuable and recognized by all the actors. The UTXO model of Bitcoin is obviously unable to make this happen, but it has provided us inspiration. As long as nValue is modified to be a space that can store not just integers, but also any other data, we have a more generalized “nValue”, or Cell:

In a Cell, nValue is replaced by ‘capacity’ and ‘data’. Both of the two fields are combined to represent a storage space. ‘Capacity’ is an integer that holds the size of the space (in bytes), while ‘data’ is where a state described in any given line of bytes is saved. The Cell model also introduces the concept of lock script, which is similar to scriptPubKey, to refer to the owner of the Cell. Only the person who can produce the parameters (such as a signature) required by the lock script can “update” the state of the Cell. The bytes occupied by CellOutput must not be more than the Cell’s ‘capacity’ value. CKB contains a large number of Cells, the set of all of these Cells forms the current state of CKB, which stores not just digital currency, but common knowledge.

The state of CKB is a set of cells

In CKB, a transaction still reflects the change or transfer of a state. The change of state, or the “update” of Cell content, is done through Cell destruction and Cell creation, which means the content of the original Cell is not directly changed. Every transaction actually destroys some Cells and creates new ones, the newly-created Cells will have new owners and store new data. However, the destroyed capacity must be larger than or equal to the newly-created capacity, so that no one can generate additional capacity.



As the native asset of the CKB network, capacity represents space for consensus state, which can only be issued according to a pre-defined fixed formula. When a Cell is destroyed, it is simply marked as “destroyed” in the same way a UTXO is marked as “spent”, instead of being removed from the blockchain. Every Cell can only be destroyed once, just as every UTXO can only be spent once.



Such a model has the following features:

State is the most essential element in the system; Owner is an attribute of state, so each state has only one owner; States are constantly being destroyed and created;

Overall, the Cell model is a generalized version of the UTXO model.

Verify

Only having space to store any state is not enough. The reason why Bitcoin is believed to be valuable is that every transaction needs to be validated by each of the full nodes in the network, so that all users can ensure the rules written in the Bitcoin protocol, i.e., the 21 million supply cap of Bitcoin, is guaranteed (and users know that others know that the rules are being enforced). The concept of common knowledge is also derived from this. If anyone ensures that what he or she knows is also recognized by others, the information they agree on is called common knowledge.



In the blockchain system, it is known that the data can be verified independently and recognized by any actor. This is the reason why common knowledge can be generated by a blockchain. A consensus is reached through verification and confirmation among all the actors. This is also how common knowledge is created. (It should be noted that the knowledge is validated according to predefined rules. However, validated knowledge is not always true.）



How can we verify the data stored in a Cell? This depends on another field in the Cell, the type script. This script defines the rules of state transfer and thus imposes constraints on new state. The CKB-VM will execute the type script and verify that the state saved in the newly-generated Cell conforms to the rules predefined by the type script. All of the Cells that are restricted by the same kind of type script store the same type of data.



For example, if we want to create a UDT (User Defined Token) called SatoshiCoin, its state transfer has to conform to the following constraints:

The user must prove that he or she is the owner of the input token; The amount of input tokens must be greater than or equal to the amount of output tokens in every transaction.

The first constraint can be expressed by a lock script, which is similar to scriptPubKey in Bitcoin. If you are interested in this, you can view the sample code here. The second constraint is hard-coded into the underlying architecture of Bitcoin, but in CKB is implemented by a Cell’s type script. The amount of SatoshiCoin represented by every Cell is a kind of state, with a structure defined by the type, as a string of 8 bytes saved in the data of a SatoshiCoin Cell, and the amount is a serialized integer:

When the type script is being executed, it needs to read all the Cells of the same type (which can be judged from the type field) and then check that the total amount saved in the input Cells is more than or equal to that saved in the output Cells. By utilizing the lock and type scripts, we have created a simple 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. Hence CKB presents a stateful programming model. It is worth mentioning that a stateful programming model rather than Turing-completeness is what makes Ethereum so powerful.



We can save the type script in an independent Cell and reference it in the type of every SatoshiCoin Cell. The benefit is that the same type script only needs to occupy a single space in storage. The Cell that stores the definition of a digital asset is called an ADC (Asset Definition Cell). Another feature of the SatoshiCoin implementation is that the detailed record of assets and their owners is split up and saved in multiple independent Cells, which can be provided by developers to users. These cells are owned by users themselves, and can even be rented to users. Only when the ownership of consensus space is clearly defined, can users really own the assets saved in their cells (any cell’s data can be an asset). Since users are allowed to own consensus space on the CKB, they can also own the digital asset saved in it (an example from real estate: only when you own the land can you really own the house built on it).



As an abstract state verification model, the Cell model offers an internally unstructured storage space (data) and supports any state verification rule (type) and ownership verification rule (lock). We can simulate how the UTXO model works in the Cell model (as seen in SatoshiCoin), or build the Account model in it.



The verification of transaction inputs require execution of the lock script, ensuring the users’ ownership of the inputs and their right to destroy the corresponding Cells (remove them from the set of live cells); and the verification of state transition needs to execute the type script, ensuring the new state generated by users conforms to the constraints of the type script and the new Cells are created correctly. The programming model of CKB differs greatly from that of Ethereum, because it adopts a unique state model and separates computation from verification. Hence, further exploration is needed to seek out best practices for the programming model of CKB.

Cells are removed and added to the set during transaction processing

General Verification Network

Bitcoin is a Verification Network. When making a transaction, a user needs to input to the wallet or local client the amount of coins to be transferred and the recipient. After receiving this information, the wallet will do the computation and search for this amount of coins (UTXOs) owned by the sender (locally) and create new coins, part of which will be transferred to the recipient and part of which will be returned to the sender as change.



The wallet will then package the spent coins and newly-created coins into a transaction and broadcast it to the network. Once the transaction is verified by the network, it will be packaged into a block and completed. In the process, the nodes of the network are not concerned with how the previous state (the destroyed coins) has been found or how the new state (new coins) is generated. The nodes are only concerned with any change in the total value of these coins after the transaction is completed. When a user makes a transfer, the computation (state generation) is done on their (client) side. Hence the user can immediately confirm the result (the new state) when sending the transaction.



Ethereum is a General Computation Network. When using a DApp, the user needs to tell the wallet or local client what he wants to do. The wallet will package the user’s request into a transaction and broadcast it to the network. When the transaction is accepted by the nodes of the network, the new state will be computed according to the current state and the request included in the transaction. In the process, the computation is completed by the nodes. The result (the new state) can only be confirmed after the transaction has been added into a block. As you can see, the user is uncertain about the result when sending the transaction.