Shulou(Shulou.com)06/01 Report--

This article mainly introduces the relevant knowledge of "what is the concept of First-class Asset". The editor shows you the operation process through an actual case, and the operation method is simple, fast and practical. I hope this article "what is the concept of First-class Asset" can help you solve the problem.

First-class Asset

Engineers who like functional programming should be familiar with the term First-class Function, which should be translated into Chinese as "first-class function" or "first-class function". First-class Function refers to a class of programming languages in which a function is a completely independent concept: a function can be assigned to a variable as a value, passed to other functions as an argument, or passed from other functions as a return value. In such languages we can manipulate functions in the same way as data, so functions are First-class citizen like data in these languages. First-class Function is a key feature of functional languages, and many of the powerful capabilities of functional programming come from it.

Nervos CKB uses the Cell model to build the status of the entire common knowledge base. The Cell model is a very simple state model but very different from the existing blockchain design. When we designed the Cell model, we already realized that the DApp based on the Cell model will have some very different properties, just like functional programming and object-oriented programming will produce very different design patterns and program features. In this article, I want to explain a very interesting DApp design pattern that the Cell model can support, which we call First-class Asset because we can turn user-defined encryption assets into "first-class citizens" in the blockchain.

Getting started with State Model

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

The representative of using the UTXO model is Bitcoin. UTXO is an acronym for unspent transaction output (Unspent Transaction Output). A UTXO can be simply understood as a bitcoin, but unlike ordinary coins, the face value of each UTXO is different. Each UTXO records the owner of the coin through a lock script (lock script), while ensuring that only the owner can spend the coin. Each bitcoin full node maintains a collection of all the current UTXO, which we call the current state of the bitcoin account (that is, the current ledger). Each bitcoin transfer is a process of removing several coins (belonging to the payer) from the UTXO collection and then adding a few new coins (belonging to the payer and / or the payer). Since the entire account state is built on the smallest unit of UTXO, we call it the UTXO model.

The representative of using Account model is Etay Fong. Account is an account, similar to a bank account, which represents the owner of the asset. The most important data in the account is the balance (Balance), which records the number of etheric coins held in the account. The account is the representative of the owner of the asset, which can be the person (corresponding to the external account) or the intelligent contract (corresponding to the contract account). The external account verifies the ownership of the asset through the private key signature, and the ownership of the contract account is determined by the contract code. The contract code and status are kept inside the contract account. When the external account is to be transferred, the user indicates the amount of the transfer in the transaction, and the balance of the payer's account and the cashier's account will decrease and increase accordingly. Since the entire account state is based on the smallest unit of the account (Account), we call it the Account model.

First-class Coin

The UTXO model and the Account model represent two ways to construct the state of the account. An account book is a collection of the relationship between the owner and the asset. The UTXO model is based on assets, first constructing the concept of "coin", and then giving the owner the attribute to the coin; the Account model is based on the owner, first constructing the concept of "account", and then giving the balance attribute to the account. Which way is used as the underlying model determines whether the basic object of the operation in the system is the asset or the account (owner).

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

In the Account model, the account is First-class citizen, and the coins aggregated in the account balance do not have a separate identifier. The account is the object directly operated by the user, and the transfer of assets is realized by the account as the agent of the user, which is most obvious when the recipient is the contract account. Under such a model, user-defined encrypted assets (such as ERC20) are more likely to be transferred through third-party accounting rather than peer-to-peer, and this difference introduces a third party (the third party here refers to the smart contract that hosts the encrypted asset) into the asset transfer process, increasing the design complexity of the smart contract (we can think of the smart contract as the logic that is automatically executed when the asset is transferred). To reduce this complexity, transactions in the Account model need to add special logic (value fields), but such special logic only helps native assets and results in different code paths to native assets and user-defined assets. Kelvin Fitcher has written an article on Looking at ownership in the EVM 5 that gives a good analysis of these issues, so I won't repeat them here.

With this background, it should be easier for us to understand the design philosophy of CKB:

With the Cell model, we can simplify the design and implement user-defined assets (User Defined Assets), or First-class Assets.

Like UTXO, First-class Assets has independent identifiers that can be directly referenced and manipulated by users and scripts.

First-class State

How to implement First-class Assets?

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

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

Because Cell is a state unit with an independent identifier (Transaction ID + Cell Output Index) that can be directly referenced and passed to the script as a parameter, it is a "first-class citizen" in CKB, that is, a "first-class citizen" in CKB. Cell is not only a First-class State, but also the simplest kind of First-class State: there are only four fields in a Cell, Capacity,Data,Lock and Type (optional, Type can be a piece of code or a Reference that points to a Code Cell). As shown in the following figure, the owner of Cell can directly update the state saved in Cell without going through any intermediate party, while in the Account model, the user can only manipulate the state in the account through the contract code (code in the account), which is actually hosted in the hands of the contract.

It is worth pointing out that with Cell,CKB, you actually get a stateful programming model. A common view is that the expressive power of the ethering programming model comes from Turing's complete virtual machine, and actually enabling intelligent contracts to preserve computing state through accounts is an advantage over EVM (Turing's incomplete language also has strong expressive power 1). CKB through Cell and CKB-VM (Simple Yet Powerful! This requires a separate article.) the combination implements a new stateful intelligent contract programming model. This programming model is more suitable for Layer 2, because by analyzing the common pattern of the Layer 2 protocol, we can see that the interaction objects between the protocol layers should be state objects (State Transaction) rather than event objects (Event Transaction), and Layer 1 should be a state layer rather than a computing layer.

Another feature of the CKB programming model is that it does not distinguish between data (state) and code. This means that, unlike the Account model, the state and code of the contract can be stored in the data field of the Cell, the Cell that holds the code can be referenced by other Cell (because they are First-class State!), and the state of the contract and the code do not need to be bound together and stored in one place. Developers can load the contents of code Cell or data Cell into runtime memory with a simple instruction, and then interpret it as code execution or data to read and write as needed.

With these low-level support, we can store the code and state of a contract in different places: the code (data) field of Code Cell stores the code, while the state (data) field of State Cell stores the state; in State Cell, the business logic constraint of the saved state is established by type ref referencing Code Cell, and the ownership of State Cell is expressed by lock ref referencing another Code Cell. Each State Cell can belong to a different user, so it is very easy to implement an independent user state under the Cell model (in the Account model, the contract state is often composed of multiple user states, for example, in an ERC20 contract, the Token balances of Alice and Bob are recorded in the internal state of the same contract).

If you want to know more about contract writing on CKB-VM, please see articles 1 and 2

With such a programming model, we can construct First-class Asset.

First-class Asset

User-defined assets (User Defined Asset) in CKB can be constructed as follows:

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

Save the contract code to Asset Definition Cell.

If the issuing authority is satisfied, the issuer issues the asset and saves the asset state in a different State Cell. The Type field reference of State Cell holds the Code Cell of the asset definition, ensuring that changes in State Cell are constrained by the asset definition.

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

As you can see, 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 think of Asset Cell as a generic version of UTXO. Such First-class Asset has the following advantages:

Asset Cell can be referenced and can be passed in directly as a parameter for other contracts. As long as the input referencing Asset Cell has the correct user authorization, the contract can use the user's Asset Cell normally.

Asset definition is separated from asset status. The owner of Asset Definition Cell is the issuer of the asset, while 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, which means that First-class Asset is not hosted in the hands of asset issuers, developers, or asset definition contracts, but really belongs entirely to the user.

The user's assets are isolated from each other, and the user's asset status is independent. The economic model of CKB focuses on the incentive problem of state storage: users who save state on the block chain not only need to pay the writing fee, but also should bear the storage cost proportional to the storage time. If the user's asset states are mixed in one place (for example, ERC20), it will be a problem who will pay for the storage cost of these states. CKB Economics Paper is working hard to write. )

Asset definitions can be updated independently as long as Asset Definition Cell's lock logic allows.

The diagram above is just one way to implement First-class Asset on CKB. In addition to the aspects discussed above, there are some interesting details, such as, can Asset Definition Cell have its own state? Who should provide the capacity for Asset Definition Cell and Asset Cell? We already have some very beautiful ideas about these problems. The design, discussion and implementation of these details are what we are doing now.

Summary

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 that is different from the UTXO model and the Account model. In addition to the differences in the state model, CKB also transfers the computation (that is, state generation) to the chain, where only the logic of verifying the state is needed. The unique state model and the separation of computational verification determine that new DApp paradigms and design patterns will inevitably appear in the programming model of CKB.

This is the end of the introduction to "what is the concept of First-class Asset". Thank you for your reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.