Cell Model
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.
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.
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.
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.
CKB is a General Verification Network. When using a DApp, the user needs to tell the wallet or local client what he wants to do. The wallet will compute the new state according to the current state and the user’s request. In the process, computation is completed on the user’s side, and its result (the new state) can be confirmed by user before the transaction is sent.
In other words, a transaction is created after the computation is done in the Bitcoin or CKB model, but before the computation is done in the model of Ethereum.
The separation of computation and verification also separate Layer 1 and Layer 2. Layer 1 is concerned with new states rather than the steps by which they are generated. In essence, all the Layer 2 solutions including state channels and Plasma do the computation off-chain and only commit the final state to Layer 1 for verification at a specific time.
Why is CKB better?
We now have a basic data structure that is quite different from others and have designed a unique economic model on it. Is this really better? Maybe we can obtain some inspiration from the three questions raised at the very beginning of this article.
The Tragedy of the (Storage) Commons and the loss of decentralization caused by State Explosion
Capacity is an asset native to CKB with its supply restricted by the pre-defined rules. It is also a unit of measurement for state. The amount of capacity determines how much data can be stored on CKB, i.e., the maximum state space of CKB. This means that the state stored on CKB is limited by the total amount of capacity. Hence, CKB is unlikely to suffer from state explosion. As long as capacity is issued appropriately, the network can maintain its decentralized properties indefinitely. Every Cell is independent and has a specific owner. This privatizes the state space that has served as a kind of public resource, ensuring that precious consensus space can be utilized more effectively.
The lack of flexibility and scalability due to the coupling of computation and verification
As a General Verification Network, CKB separates computation and verification, making each more flexible and scalable. More computation is executed on the user side, closer to their data, as well as application usage. Data can be processed more flexibly and with more diverse tools. With CKB’s architecture, wallets can have more power and capabilities. At the verification stage, it is easier to analyze the dependencies of transactions and execute transactions in parallel given that the results of computation have already been confirmed.
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.
In a Cell-based economic model, the cost of storage is proportional to the amount of consensus space and the length of time required. Miners can earn revenue by providing consensus space and the utility of CKB is derived from its entitlement to safe consensus space. The CKB is valuable for its security and censorship resistance, rather than TPS. CKB supplements the transaction-oriented Layer 2 and is better at value capture in a layered network.
CKB is NOT …
IPFS
It may be confusing to define CKB as storage. You may ask, “isn’t this the same as IPFS, Filecoin or [some distributed storage system]?”
CKB differs from distributed storage in that the latter only stores data without verification and thus can’t reach a consensus on the data stored in it. The capacity of distributed storage can grow in proportion to the development of storage technology. The capacity of CKB however, is limited by the efficiency of reaching a global consensus.
There is no need to worry about the capacity of CKB. As Layer 2 and other layering technologies mature, a single merkle root may be all that is required on Layer 1 in the most extreme cases of Layer 1 efficiency demands. The state required by Layer 1 for verification can also be committed through a transaction, requiring nodes to check merkle proofs to ensure the validity of state and state transfer. We’re actively exploring this direction.
Qtum
Qtum is one of the pioneers that introduce more powerful smart contracts into the UTXO model. To be specific, it builds an Account Abstraction Layer that supports EVM or x86 VM on the original UTXO model of Bitcoin. In Qtum, the verification mechanism of Bitcoin serves as the first layer, while the computation model of the EVM serves as the second layer. (Note this is internal layering in one blockchain protocol, which is different from Layer 1 and Layer 2).
Qtum alters the processing logic of scriptPubKey in a UTXO in order to transmit the request included in the Bitcoin Transaction to the EVM for execution after the transactions are packaged. Qtum is more complex in its architecture because it has merged the execution models of both Bitcoin and Ethereum. Qtum nodes first verify the transaction inputs (same as in Bitcoin) and then call smart contracts to do computation (same as in Ethereum), splits the state in both the UTXO model and the storage space of EVM.
Learn more about Nervos here.
