The concept of a “First-class Function” is nothing new to engineers that favor functional programming. In functional programming languages, a function may be a value assigned to a variable, a parameter passed to another function, or a value returned from a function.
In this paradigm, the function plays the same role as data, to which we give the label ‘First-class citizen’. Many powerful features of functional programming are derived from the ‘First-class Function’.
In the design of Nervos CKB, the Cell model is used to construct the entire state of the Common Knowledge Base. lt is a simple state model that is different from current blockchain designs. When designing the Cell model, we realized that crypto assets built upon it would have some unique characteristics, just as there are differences in approaching functional programming vs. object-oriented programming.
In this article, I’d like to introduce an interesting crypto asset design pattern supported by the Cell model. We call it the ‘First-class Asset’ model because it enables user-defined crypto assets to be “First-class Citizens” on the blockchain.
Lightspeed Tutorial for State Model
Prior to sharing the proposal of Cell model, I’d like to describe two state models that almost all existing blockchains utilize one of — UTXO model and Account model.
UTXO model
Bitcoin is the typical example of a blockchain that utilizes the UTXO model. UTXO stands for Unspent Transaction Output, a UTXO can be considered a spendable unit (Bitcoin) with a single precise denomination (i.e. a UTXO may be worth 1 BTC or 0.0045 BTC or 55 BTC). Each UTXO contains a record of its owner in a lock script, ensuring the UTXO can only be spent by its owner.
In Bitcoin’s blockchain, the set of all UTXOs is maintained by each of the full nodes. This is called the ‘current state’ of the Bitcoin ledger. Each time a transaction is made, UTXO’s are ‘spent’, as some UTXOs owned by payers are removed from current UTXO set and some new UTXOs to payees are added to it.
We call this the UTXO model because the whole ledger state is built on top of UTXOs.
UTXO State Model
Account model
The Account model is used by Ethereum and many other blockchains. An Ethereum account is similar to a bank account, it is a single account controlled by an owner. The most important data associated with an account is its balance, which records the quantity of ETH (ether) in the account. The owner of an account may be a human (in an external account) or a smart contract (in a contract account). Ownership is expressed in different ways in these two kinds of accounts: it’s proven by cryptographic signature for an external account and is confirmed by the smart contract’s code in a contract account.
When the owner of an external account makes a transfer, the transferred quantity of ETH will be deducted from the owner’s balance and then added to the balance of the account they are transferring ETH to. Because the whole ledger state is built with accounts as basic units, we call this the Account model.
Account State Model
First-class Coin
The UTXO and Account model are two different ways to construct the ledger state. A ledger can be defined as a set of relationships between owners and assets they own. The asset-based UTXO model starts with the concept of a “coin” (UTXO) and then attaches the ‘owner’ property to them, while the Account model starts with the concept of an “account” for each owner and stores a balance as a property for each account.
The choice between the two basic models provides the option of a system based on assets (UTXO) or owners (Account).
It can be said that coins are the First-class citizens in the UTXO model, as each UTXO is an object with an independent identifier (Transaction ID + Output Index). Users directly manipulate coins through transactions that change the UTXO set, while the concept of an account (or sum of all UTXO’s an owner controls) exists only in user-facing software like wallets. We can see that the UTXO model introduces us to the First-class Coin.
UTXO Transaction
Alternatively, the Account model instills accounts as First-class citizens and provides no independent identifier for the coins that make up an account balance. Accounts are the objects that users directly interact with, and the account is the user’s agent when moving assets, which is particularly obvious when the recipient is a contract account.
In this model, the transfer of user-defined crypto assets (for example, ERC20 tokens) looks more like third-party bookkeeping than peer-to-peer asset transfer. In this paradigm, the third party is the user-defined asset smart contract, which always has custody of the crypto assets.
Custody of these crypto assets can complicate the design of related smart contracts (the logic that is automatically executed when assets are transferred). This complexity is reduced in the case of native assets (ETH), by the addition of some special logic (a ‘value’ field) which is added to transactions in the Account model. This, however, cannot be implemented for ‘user-defined assets’. Kelvin Fichter has made a reasonable analysis of these problems in his article Looking at ownership in the EVM , so I won’t repeat it here.
Account Transaction
With this background information, it may be easier to understand the design concept of CKB:
The Cell model can help simplify the design of CKB and enable User Defined Assets to be considered “First-class citizens”. This is what we call “First-class Assets”, similar to UTXOs, First-class Assets have an independent identifier and can be directly referred to and operated by users and scripts.
First-class State
In any case, the relationship between owners and their assets needs to be kept on record. The records are essentially the states agreed to by the whole network. First-class State is a prerequisite to First-class Asset, that’s where the Cell model starts.
Common Knowledge Base, or “Nervos CKB” for short, refers to the layer 1 blockchain in the Nervos network, which constantly reaches global consensus on the common key state of the network, hence the name. In other words, the CKB is a state base maintained by global consensus.
The natural model of a state base is to divide the global state into smaller units and organize them. In Nervos CKB, these smaller state units are called Cells. Cells have an independent identifier (Transaction ID + Cell Output Index) and can be directly referred to and transferred as a parameter to scripts. Cells are the “first-class citizens” in the CKB, which in turn means the state is the “first-class citizen” in the CKB.
A Cell is the simplest kind of First-class State. It consists of only four fields, Capacity, Data, Lock, and Type (which can be a piece of code or a reference that points to a code cell). As shown below, the owner of a cell can directly update the state saved in the cell. This is in contrast to the Account model, in which a user can only manipulate the state of an account through the contract code (the code in the contract account). We can see in the Account model it is actually the contract that has control of account state.
First-class State
It is worth noting that cells enable CKB to have a stateful programming model. It is commonly believed that Ethereum owes its expressibility to the Turing-complete virtual machine (EVM), but the Account model that enables smart contracts to have computational state actually plays a more important role here. (a non-Turing complete language is also powerful in its expressibility).
The CKB realizes a new stateful programming model for smart contracts by combining the Cell model and CKB-VM (Simple yet powerful! It deserves an article all by itself). This programming model is more suitable for a layered architecture, in this model Layer 1 is mainly a state layer rather than a computation layer, and the interactive object between Layers 1 and 2 states (cells and state transactions) rather than events (event transactions).
Another characteristic of the CKB programming model is that it does not differentiate between data(state) and code. This differs from the Account model, allowing both the state and code of a contract to be saved in the unified ‘data’ field of a cell, which can then be referred to by other cells (because they are First-class State!).
Code is Data, Data is Code
With this design, there is no need to bind the state and code of a contract and store both in the same place. Developers can provide a simple instruction to load the content of code cells and data cells to runtime memory and then interpret it into code for execution or data for a read-write operation according to their needs.
With this underlying support, the code and state of a contract can be saved in different places.
A state cell refers to a code cell via type reference and may add constraints to the business logic of data saved in the cell and then refers to another code cell via lock reference to express ownership. Each state cell may belong to a different user, making it very easy to realize independent user states with the Cell model (In contrast to the Account model, in which the contract state usually consists of state for multiple users. An ERC20 contract would contain Alice and Bob’s token balance in the contract).
If you want to learn more about CKB-VM, please refer to this article by Xuejie Xiao , and check this article about Nervos CKB.
The CKB programming model makes First-class Assets possible.
First-class Asset
The steps to construct User Defined Assets in the CKB are as follows:
Design an asset definition contract with the major constraints (the total supply, the issuer, and transaction rules- such as the sum of inputs must equal the sum of outputs, etc.) of assets created by the contract.
Save the asset definition in a cell.
With permission of issuance, Issue assets and save the asset state in another state cell. The ‘type’ field of state cell refers to the code cell that saves the asset definition and ensures that state cell changes are restricted by the asset definition defined by the issuer.
Holders of asset cell can change the owner of the asset cell by updating Lock.
First-class Asset on CKB
We can see that the User Defined Asset is designed to be an independent object in the system.
Each asset is a Cell with its own identifier. It is safe to consider asset cells as generalized UTXOs. The example of First-class Asset has the following advantages:
An asset cell can be referred to or provided as direct input into other contracts as a parameter. As long as there is valid user authorization for the input that refers to an asset cell, the contract can use it.
Asset definition is separated from the asset state. The asset definition cell is owned by the issuers of the asset, but each of the asset cells is owned by a user. The authorization logic and business logic for an asset cell are defined separately. Its ownership is entirely determined by its own Lock and has nothing to do with the logic of asset definition. This means First-class Assets belong entirely to users rather than being held by asset issuers, developers or the asset definition contract.
Each user has separate assets and independent asset states. The economic model of CKB focuses on the incentives of state storage. Users are required to pay for state storage of their assets on the blockchain and bear cost proportional to the amount of data stored and length of storage time. This resolves an issue we see when implementing ‘storage rent’ in Ethereum ERC20 contracts for example- when all asset states for all users are mixed, it is difficult to provide each user the ability to pay for storage of only their assets on the blockchain.
The asset definition can be updated independently as long as it is allowed by the lock logic of the Asset Definition Cell.
The above diagram is just one way to realize the concept of a First-class Asset in CKB. Besides the above-mentioned details, we have found other interesting implementation questions. For example, can the asset definition have its own state? Who will provide the asset definition cell and the capacity of the asset cell? We’re working on these problems and we already have some excellent ideas.
Summary
The Cell model is a highly abstract model. In fact, it can realize not only the concept of a First-class Asset but can also simulate the Account model. We can see from this article that the Cell model is a new design that differs from the UTXO model and the Account model.
Besides its unique state model, the CKB also removes computation (i.e. the generation of state) from the blockchain and utilizes the chain solely for state verification. I believe this unique state model and computation-verification separation will open the door to many new DApp architectures and design patterns.
It has been nearly a year since we drafted the CKB whitepaper. During the year, both the First-class State and First-class Asset have attracted more and more attention and discussion, which has inspired us greatly.
CKB is open-source now. The above-mentioned technology has been implemented in code. If you are interested in further discussion of First-asset State and First-class Asset or have any interesting ideas about the CKB programming model, please contact us on Github.
You are welcome to put forward any suggestions on our code!
https://github.com/nervosnetwork/ckb-demo-ruby-sdk (This article provides examples of how to do programming with ruby. It is the best source to understand the CKB programming model.)
Thank Ian Yang, Xuejie Xiao, Kevin Wang knwang for their help in the design of CKB and Cell model.
...and you will also help the author collect more tips.