How CKB Turns User Defined Cryptos Into First-Class Assets

Key Takeaways

CKB Cell model is a highly abstract model in blockchain architecture design.
Cell model differs from Bitcoin's UTXO and Ethereum's Account model. It can realize the concept of first-class asset and simulate the Account model.
CKB moved the computation (state generation) off-chain and only kept the state storage and verification on-chain.
Cell model and CKB's computation-verification separation will together trigger the advent of new architectures and patterns in the future of DApps design.

When talking about first-class function, it should be familiar to those engineers who enjoy functional programming. First-class function is a programming concept. In some programming languages, functions are independent objects. It can be a value assigned to a variable, an argument passed to other functions, or a value returned from other functions. Put differently, functions serve the identical purposes as data, therefore, functions are also referred to as "first-class citizens" in these languages. First-class function, as the core feature of functional languages, underpins the power of functional programming.

Nervos CKB uses Cell model to construct the entire state of the layer 1 blockchain, Common Knowledge Base. Cell model is simple yet differentiated from existing blockchain state model designs. When designing the Cell model, we noticed that DApps built on it would have some distinct properties. Similarly, functional programming and object-oriented programming lead to distinctive design patterns and program characteristics. In this article, I will present a very intriguing DApp design pattern supported by the Cell model, named first-class asset, which turns user-defined crypto assets into "first-class citizens" on the blockchain.

State Model ABCs

Before CKB, state models in use by different blockchains are two types: UTXO and Account model.

Bitcoin's UTXO

UTXO refers to Unspent Transaction Output, the most famous example is Bitcoin. Simply put, a UTXO is a bitcoin. Unlike any regular coin, each UTXO has varying par values. Each UTXO has a lock script that records ownership information and ensures only the owner can spend it. The entire UTXO set is maintained by all the full nodes in the Bitcoin network. The set is called the current state of the bitcoin ledger (i.e. the current ledger). Transferring is the process of removing and adding the coins from/into the UTXO set. As the whole ledger state is built on the basis of UTXO, we call it UTXO model.

f1 First-class Asset _ UTXO Model.png Figure 1. Blockchain State Presented In Bitcoin's UTXO Model

Ethereum's Account Model

Speaking of Account Model, it naturally reminds us of Ethereum. The account here is similar to a bank account, controlled by the owner of the asset. The most important field of an account is the balance, which registers the amount of ETH belonging to the account owner. The account represents the asset owner, and the owner can either be a human (an external account), or a smart contract (a contract account). In terms of verifying asset ownership, an external account uses private-key signatures, while a contract account uses contract codes to verify (Contract code and status are stored inside the contract account).

When making a transaction, the owner of an external account has to specify the amount to be transferred. The balances of the sender and the receiver will decrease or increase accordingly. As the whole ledger state is built upon the Account as the base unit, we call it Account model.

f2 Blockchain State Presented In Ethereum's Account Model.png Figure 2. Blockchain State Presented In Ethereum's Account Model

First-Class Coin

A ledger consists of relationships between owners and assets. UTXO model and Account model represent two approaches to construct a ledger state. The UTXO model is an asset-based model that begins with the concept of "coin (UTXO)" and then assigns owner attributes to the coin, while the Account model is an owner-based model that starts with the concept of "owner (account)" and then makes the account have the property of balance. The choice of a different state model determines whether the object of operations in the system is an asset or an account (owner).

Hence we say a coin is the first-class citizen in the UTXO model. Each UTXO is an entity with a unique identifier (Transaction ID + Output Index). Users operate directly on coins via transactions (UTXO contained in the transaction constructed by the user). Asset transfer is more like “handing over” coins from the sender to the recipient.

Upon the base layer of coins, we can have accounts in the UTXO model too. But here, the account is a higher-level (second-class) structure built upon coins. It exists only in the wallet.

f3 First-class Asset _ UTXO Transaction.png Figure 3. Assets Transaction Under UTXO

In the Account model, accounts are first-class citizens. Coins aggregated in the account balance have no independent identifier. Users operate directly on accounts. Native asset transfer is completed by modifying the balances in the accounts of the sender and the recipient, while user-defined asset transfer is completed by modifying balances in a third-party contract. In such a model, user-defined crypto assets (e.g. ERC20) are more like balances registered in banks (ERC20 contracts), rather than cash held in hands. This model introduces a third-party between the sender and the recipient, also increases the complexity of smart contract (An example is the interactions between the ERC20 contract and a recipient when the recipient is a contract too). The complexity is alleviated for the native asset by adding a special field value in transaction format; however, it only works for the native asset and creates different logic paths for native and user-defined assets.

F4. Assets fTransaction Under Account Model.png Figure 4. Assets Transaction Under Account Model

In light of all the foregoing, the design principles of the Cell model should be easier to comprehend:

Cell model makes user-defined assets to be the “first-class citizens” on Nervos CKB, known as the “first-class assets”.

Cell model makes it possible and easy to create first-class assets. Similar to UTXO, they have independent identifiers and can be referenced and operated by users and contracts directly.

First-Class State

So how to create first-class assets? Either way, the relationship between the owner and the asset needs to be recorded. Such a record is agreed upon by all consensus parties. It has an independent identifier, and can be referenced and operated by users and contracts directly, i.e. first-class state. First-class assets cannot exist without first-class state, and the latter is exactly what a cell is.

CKB stands for Common Knowledge Base. The reason for calling the Nervos blockchain a "Common Knowledge Base" is that CKB continuously facilitates global consensus on an ever-changing database. Put differently, CKB is a permissionless database maintained and verified by the global consensus. The structure of the database is about dividing the entire state into smaller units and reorganizing them. These smaller units of state are Cells.

A cell is a state unit with an independent identifier (Transaction ID + Cell Output Index). It can be referenced directly and transferred as a parameter to contracts. A cell is a "first-class citizen " in CKB, meaning that a state is a "first-class citizen" in CKB. As first-class state, cell is the simplest of its kind. Each cell contains four fields, capacity, data, lock, and type (type is optional and can be a piece of code or a reference to a code cell).

A cell is a state unit with an independent identifier (Transaction ID + Cell Output Index). It can be referenced directly and transferred as a parameter to contracts. A cell is a "first-class citizen" in CKB, meaning that a state is a "first-class citizen" in CKB. As first-class state, a cell is the simplest of its kind. Each cell contains four fields, capacity, data, lock, and type. Type is optional and can be a piece of code or a reference to a code cell.

As shown in the graph below, a cell owner can update the state stored in the cell directly without any intermediaries. In contrast, users of Account model can only access the state through the contract code, code in the intermediary account. The state is actually in the custody of the intermediary contract.

Figure 5 Independent State Update Under Cell Model VS Shared State Update Through ERC 20 Under Account Model..jpg Figure 5. Independent State Under Cell Model VS Shared State Through ERC 20 Under Account Model

Although the popular view is that the Ethereum programming model owes its expressibility to the Turing-complete virtual machine, in my opinion, the stateful smart contracts enabled via Account actually contribute more, because EVM is not really Turing-complete (hint: gas limit) and non-Turing-complete programming languages can also be powerful in their expressibility.

Cells and CKB-VM together endow CKB with a novel stateful programming model. This model is more aligned with Nervos’ layered architecture because its core is data and assets. Layer 1 is for data, layer 2, for application; Layer 1 is for assets, layer 2, for finance; Layer 1 is for verification, layer 2, for computation.

An interesting characteristic of CKB programming model is that data and code are not differentiated. Contrary to the Account model, both the state and the code of contracts are stored in the data field of Cell. A cell containing code can be referenced by other cells (as they are First-class State), and the state and code of contract are not required to be bound and stored together in one place. Developers can load the data cells into runtime memory via a simple instruction, then decode the contents as needed, either for execution as code or for reading and writing as data.

f6 An Interesting Feature of CKB Programming Model-Data And Code Are Not Differentiated.jpg Figure 6. An Interesting Feature of CKB Programming Model: Data And Code Are Not Differentiated

These underlying architectures permit us to store the code and state of a contract in separate places. The code field (data) of the code cell stores the code, while the state field (data) of the state cells stores the states. State cell references a code cell via type ref to establish constraints to the state stored, and references another code cell via lock ref to indicate the ownership of the state cell.

Each state cell can belong to a different user so that the independent user state under the cell model is easy to implement. In contrast, the contract state in the Account model usually contains multiple user states mixed together. For example, the ERC20 token balances of both Alice and Bob are recorded in the internal state of the same ERC20 contract.

With such a programming model we can create first-class assets.

First-Class Assets

Building the first-class user-defined assets on CKB contains the following stages:

Design an Asset Definition contract to define the main attributes of the asset, e.g. total quantity, issuer, amount sum invariance before and after the transaction, etc;
Store the Asset Definition contract code in the Asset Definition Cell;
The issuer issues tokens according to Asset Definition and creates Asset Cells. An Asset Cell is a state cell storing the asset value and ownership data. The type field of Asset Cell refers to the Asset Definition Cell which contains the Asset Definition contract code and ensures that changes to the Asset Cells are restricted by the constraints.
An owner of Asset Cell can transfer assets by unlocking the cell and updating asset state and/or lock field.

Figure 7. Example of the First-Class Asset Implementation on CKB.jpg

Figure 7. An Example of First-Class Asset Implementation on CKB

In this design, user-defined assets reside as independent objects on CKB. An asset is a cell, and each asset has its own identifier. The Asset Cell can be considered a generalized UTXO. The advantages of first-class asset are as follows:

Asset Cell can be referenced directly by contracts or passed directly as a parameter to contracts. With valid owner authorization, any contract is allowed to operate an Asset Cell or a group of Asset Cells.
Asset Definition is separated from the asset state. The Asset Definition Cell is owned by the asset issuer, whereas the Asset Cell is owned by the individual user. The owner logic and asset logic of the user-defined token are separated, the ownership is entirely up to the Asset Cell’s lock with no interference with the logic in the Asset Definition. First-class asset is not in the custody of the asset issuer, developer, or asset definition contract, but truly belongs to the user, like cash, not balance.
Assets are isolated from each other, and asset states remain separate. The economic model of CKB concerns the incentive for state storage: users need to pay for the write their assets on-chain and cover the storage cost proportional to the storage space-time. If the asset states are mixed in one place (as with the ERC20 contract for example), who should pay for the storage cost becomes a problem.
Asset definitions can be updated separately from asset states.

The graphic above (Figure 7) is just one example to demonstrate the implementation of first-class asset concept on CKB. There are still some intriguing aspects deserve discussion, for instance, what if an Asset Definition Cell has its own state? Who provides the capacity to the Asset Definition Cell and the Asset Cell? I’m looking forward to different first-class asset designs on CKB.

Reference

Appreciation to Ian Yang, Xuejie Xiao, Kevin Wang who helped in CKB and Cell model design.

✍🏻 Written by Jan Xie

By the same author:

Blockchain Abstraction and Interoperability 2.0