The author of this article is Jan. The article explains a very interesting DApp design pattern supported in the Cell model: First-class Asset, which makes encrypted assets a "first-class citizen" in the blockchain.

Engineers who like functional programming should be familiar with a term: First-class Function, translated into Chinese should be called "first-class function" or "first-class function". First-class Function refers to a class of programming languages ​​in which functions are a completely independent concept: functions can be assigned to a variable as a value, passed as parameters to other functions, or used as The return value is passed from other functions. In such a language, we can manipulate functions like manipulating data, so functions and data are "first-class citizens" in these languages. First-class Function is a key feature of functional languages, and a lot of the power of functional programming comes from it.

secondary title

A quick primer on the state model

Before the Cell model, there were basically two state models used by various blockchains: UTXO model and Account model.

The representative of the UTXO model is Bitcoin. UTXO is the abbreviation of Unspent Transaction Output. A UTXO can be simply understood as a Bitcoin. However, unlike ordinary coins, the face value of each UTXO is different. Each UTXO records who the owner of the coin is through a lock script (Lock Script), and at the same time ensures that only the owner can spend the coin. Each Bitcoin full node maintains a collection of all current UTXOs, which we call the current state of the Bitcoin ledger (that is, the current ledger). Every Bitcoin transfer is a process of removing several coins (belonging to the sender) from the UTXO set and adding several new coins (belonging to the payee and/or sender). Since the entire ledger state is constructed based on the smallest unit of UTXO, we call it the UTXO model.

text

So we say that coin (Coin) is a First-class Citizen in the UTXO model, each UTXO is an object with an independent identifier (Transaction ID + Output Index), and Coin is an object directly operated by the user (the user constructs The transaction contains UTXO), and the account is based on the upper concept established by Coin (only exists in the wallet). So UTXO is a First-class Coin.

In the Account model, accounts are First-class Citizens, and coins aggregated in account balances have no independent identifiers. The account is the object of the user's direct operation, and the transfer of assets is realized by the account as the user's agent. This is most obvious when the recipient is a contract account. Under such a model, user-defined encrypted assets (such as ERC 20) are more like a third-party accounting method rather than a point-to-point transfer. This difference will make the third party (the third party here refers to the managed encrypted assets smart contract) introduces the asset transfer process, increasing the design complexity of the smart contract (we can think of the smart contract as the logic that will be automatically executed when the asset is transferred). In order to reduce this complexity, transactions in the Account model need to add special logic (Value field), but such special logic only helps native assets, and causes different code paths for native assets and user-defined assets.

On these issues, Kelvin Fitcher wrote anLooking at ownership in the EVMThe analysis is well done and I won't repeat it here.

With these backgrounds, it should be easier for us to understand the design concept of CKB:

With the Cell model, we can simplify the design and implement User Defined Assets (User Defined Assets) as "first-class citizens" on Nervos CKB, referred to as First-class Assets.

secondary title

First-class State

How to realize First-class Assets?

Either way, we need to document the relationship between the owner and the asset. These relationship records are essentially a consensus state. To have First-class Assets, there must first be First-class State, and this is the starting point of the Cell model.

The name of Nervos CKB comes from the abbreviation of Common Knowledge Base (common knowledge base). The reason why we call the blockchain in the Nervos network "Common Knowledge Base" is because its responsibility is to continuously form a global consensus on the common state of the network. In other words, CKB is a state maintained by a global consensus library. The basic model of a state library naturally divides the entire state into smaller state units to organize. These smaller state units are Cells.

Since Cell is a state unit with an independent identifier (Transaction ID + Cell Output Index), it can be directly referenced and passed as a parameter to the script. It is a "first-class citizen" in CKB, which means that the state is CKB "first class citizens". Cell is not only a First-class State, but also the simplest First-class State: a Cell only has Capacity, Data, Lock and Contract (optional, Contract can be a piece of code or a Reference pointing to a Code Cell ) four fields.

As shown in the figure below, the owner of the Cell can directly update the state saved in the Cell without any intermediary. In the Account model, the user can only operate the state in the account through the contract code (Code in the account). In fact, it is hosted in the hands of the contract.

It's worth pointing out that with Cells, CKB actually gains a stateful programming model. A common view is that the expressive power of the Ethereum programming model comes from Turing's complete virtual machine. In fact, enabling smart contracts to save computing states through accounts is an advantage over EVM (Turing's incomplete language is also very powerful. expressive power: https://en.wikipedia.org/wiki/Total_functional_programming).

CKB implements a new stateful smart contract programming model through the combination of Cell and CKB-VM (Simple Yet Powerful! This is another article). This programming model is more suitable for Layer 2, because by analyzing the common pattern of Layer 2 protocols, we can see that the interaction objects between protocol layers should be state objects (State Transaction) instead of event objects (Event Transaction), and Layer 1 should be A state layer instead of a computation layer.

Another feature of the CKB programming model is that no distinction is made between data (state) and code. This sentence means that, unlike the Account model, the state and code of the contract can be stored in the Data field of the Cell, and the Cell that saves the code can be referenced by other Cells (because they are First-class State!), the state of the contract And the code does not need to be bound together and stored in one place. Developers can load the content of the code cell or data cell into the runtime memory through a simple instruction, and then interpret it as code execution or data reading and writing as needed.

With these underlying supports, we can store the code and state of a contract separately in different places: the Code (Data) field of the Code Cell stores the code, and the State (Data) field of the State Cell stores the state; In the Cell, the contract ref refers to the Code Cell to establish the business logic constraints on the State saved by itself, and the Lock ref refers to another Code Cell to express the ownership of the State Cell. Each State Cell can belong to different users, so independent user states under the Cell model are very easy to implement (under the Account model, the contract state is often composed of multiple user states, for example, in an ERC 20 contract, Both Alice and Bob's Token balances are recorded in the internal state of the same contract).

If you want to know more about contract writing on CKB-VM, please read these two articles:

• Hello CKB！

• An Introduction to Nervos CKB-VM

secondary title

First-class Asset

User Defined Assets in CKB can be structured like this:

• Design the asset definition contract (Asset Definition), specify the main constraints of the asset (such as the total quantity, the issuer, the quantity unchanged before and after the transaction, etc.);

• Save the contract code to Asset Definition Cell;

• When the issuance authority is satisfied, the issuer issues the asset and saves the asset status in another State Cell. The Contract field of the State Cell refers to the Code Cell that saves the asset definition, ensuring that the change of the State Cell is subject to the constraints of the asset definition;

• The owner of the Asset Cell can change the owner of the Asset Cell by updating the Lock.

It can be seen that in such a design, user-defined assets exist in the system as independent objects, each asset is a Cell, and each asset has its own identifier. We can completely think that Asset Cell is a generalized version of UTXO. Such First-class Asset has the following advantages:

• Asset Cell can be referenced and directly passed in as parameters of other contracts. As long as the Input referencing the Asset Cell has the correct user authorization, the contract can use the user's Asset Cell normally;

• Asset definition is separated from asset state. The owner of the Asset Definition Cell is the issuer of the asset, while the Asset Cell belongs to each user. The authorization logic and business logic of Asset Cell are separated, and the ownership is completely determined by its own Lock, which has nothing to do with the logic of Asset Definition. This means that First-class Asset is not hosted in the hands of asset issuers, developers or asset definition contracts, but is truly and completely owned by the user;

• The user's assets are isolated from each other, and the user's asset status is independent. CKB's economic model focuses on state storage incentives: users not only need to pay writing fees to save state on the blockchain, but also should bear storage costs that are proportional to the storage time. If the user's asset status is mixed and stored in one place (such as ERC 20), who will pay for the storage costs of these statuses will be a problem. (CKB Economics Paper is working hard...);

• Asset definitions can be updated independently as long as the Lock logic of the Asset Definition Cell allows.

secondary title

Summary

The Cell model is a highly abstract model. In fact, you can not only implement First-class Asset on Cell, but also simulate Account on Cell. Through the introduction of this article, we can see that the Cell model is a new design different from the UTXO model and Account model. In addition to the difference in the state model, CKB also transfers the calculation (that is, state generation) to the outside of the chain, and only needs to verify the logic of the state on the chain. The unique separation of state model and calculation verification determines that new DApp paradigms and design patterns will inevitably appear on the CKB programming model.

In the nearly one year since the completion of the CKB white paper, we have seen more and more people begin to pay attention to and discuss the two new ideas of First-class State and First-class Asset (although the terms everyone uses are different. same), we are very excited about these developments. If you are interested in discussing more about First-class State and First-class Asset, or have any interesting ideas on CKB's programming model, please contact us for discussion ~

The code of CKB has been completely open sourced, and the content introduced in this article has been implemented in the code. Comments on our code are welcome:

• https://github.com/nervosnetwork/ckb-demo-ruby-sdk (an example of programming with Ruby script on CKB, the best entry to understand the programming model on CKB)

• https://github.com/nervosnetwork/ckb

• https://github.com/nervosnetwork/ckb-vm

Thanks to Ian Yang, Xuejie Xiao, Kevin Wang for their help in CKB and Cell model design ~