Network Security Internet Technology Development Database Servers Mobile Phone Android Software Apple Software Computer Software News IT Information

In addition to Weibo, there is also WeChat

Please pay attention

WeChat public account

Shulou

How to implement user-defined Token on CKB

2025-01-19 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Internet Technology >

Share

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

This article to share with you is about how to achieve user-defined Token on CKB, Xiaobian think it is very practical, so share it with you to learn, I hope you can gain something after reading this article, not much to say, follow Xiaobian to see it.

CKB's Trading and Contract Model

Because CKB and Ethereum programming models are completely different, it is necessary to introduce CKB's trading and contract models before starting.

First, CKB's transaction model is UTXO structure. Each transaction destroys a part of Cells and generates a part of new Cells. Cells are the smallest structural units on CKB network.

CKB's transaction model is similar to Bitcoin, but on this basis, the destruction and generation rules on Bitcoin are deterministic, and the core improvement of CKB is that the scripts on CKB are user-customizable.

For example, the signature algorithm we use on CKB is SECP256K1, which is consistent with the signature algorithm used by Bitcoin and Ethereum. However, on Bitcoin and Ethereum, this signature algorithm is written in the node and cannot be changed. There is no native signature algorithm on CKB. If you want to implement another signature algorithm SECP256R1 on CKB, you only need to write your own script about SECP256R1. Then write Lock Script can be implemented, and on Ethereum to achieve this function must go through hard fork. The signature algorithm on CKB is replaceable at any time.

Another big improvement of CKB is that the balance before and after the transfer on Bitcoin must be consistent, this equation is fixed in the node, so there is only native BTC on Bitcoin, and no other UDT can be realized. This point can also be customized on CKB, that is, Type Script in CKB, that is, users can develop additional transfer rules on this basis. For example, the user can customize that the balance of a certain field in Type Script must be consistent before and after the transfer, which can actually implement a new UDT on CKB, because the object specified by Type Script can no longer be limited to the native CKB Token, but can be any newly created UDT.

CKB and Ethereum have completely different design patterns. On Ethereum contracts focus on the intent of the action, not the outcome of the action, whereas on CKB we focus on the outcome of the action. Contract interaction on Ethereum is interface-to-interface, while CKB's Script interaction is state-to-state.

ERC20 Review and Analysis

Here we review the contents of ERC20. After analysis, we will find that ERC20 has many problems:

Methods and events provided by common ERC20 contracts

ERC20 only defines interfaces and is not implemented uniformly. Every time you create a new ERC20, you deploy a new contract, and it's hard for users to understand each contract individually. Also, since every new contract is recreated by the developer, this leads to many ERC20 contracts that have security issues either intentionally or unintentionally.

The behavior of the user in the ERC20 interface is coupled. For example, totalSupply, mint, burn is the behavior of the administrator; balanceOf, approve, transfer is the behavior of the ordinary user, and allowance, transferFrom is the behavior of the authorized user. We can see that this ERC20 contract is coupled with at least three user behaviors, which are relatively chaotic.

Logic and data in ERC20 are coupled. The implementation logic of the contract and the amount of data owned under the user address are all within this contract. Because of this coupling, there is no unified implementation on Ethereum.

Design ideas for implementing UDT on CKB:

Logic is separated from state, using a uniform business code. Security will be greatly guaranteed.

User behavior, administrator behavior, and authorization behavior are separated.

Only the core UDT functions are provided. It refers to providing the most core UDT functions to ensure developers 'needs for UDT flexibility.

Adopt a state-oriented, behavior-outcome-oriented design pattern to define UDT behavior.

Minimized UDT

Minimize the two core functions of UDT: one is to issue coins, where you need to define the basic information of UDT and maintain UDT uniqueness; the other is to transfer money to ensure consistency before and after UDT.

Coins: Create Action

Input Cells: Fill in Cells and destroy the state of CKB. It could be the CKB you currently have, or the CKB you are using, and so on.

Output Cells: There are two parts here, one is UDT_ID_CELL, which is used to describe the logic rules, basic information and uniqueness of this UDT. The other is UDT_BALANCE_CELL to describe the balance of this UDT and ensure consistency before and after the transfer.

UDT_ID_CELL mainly contains several contents:

Type Script: Used to store the logic rules for UDT creation, and UUID used to describe the uniqueness of this UDT;

Lock Script: Simply a signature algorithm that explains who can unlock the Cell;

Data: Used to store UDT definition data. Creator information, number of UDTs created, decimal mantissa, etc.

UDT_BALANCE_CELL mainly contains several contents:

Type Script: The logical rule used to store the UDT transfer, and UUID used to describe the uniqueness of this UDT;

Lock Script: Simply a signature algorithm that explains who can unlock the Cell;

Data: Used to indicate the balance of UDT.

Transfer: Transfer Action

UDT transfer will be relatively easy, destroy a part of UDT, generate a part of new UDT can realize the transfer.

Input Cells: Put a portion of UDT_BALANCE_CELL(s) as Input.

Output Cells: Put a portion of UDT_BALANCE_CELL(s) as Output.

Extended Minimal UDT

What we have achieved above is to minimize UDT, and only design the two most basic functions of issuing coins and transferring money. What about other complex functions?

Mint/Burn Action

For UDT administrators, he may need to perform some additional issuance and destruction operations on UDTs. Here we need to make some modifications to the UDT_ID_CELL we created above.

Input Cells :

Enter UDT_ID_CELL. Of course, only administrators specified in Lock Script in UDT_ID_CELL can perform such operations. Not everyone can perform such operations.

(optional) UDT_BALANCE_CELL: If destroyed, enter the address and number of UDTs to be destroyed here.

Output Cells:

Output a new UDT_ID_CELL, which is the newly generated UDT_ID_CELL after the rule is changed;

(optional) UDT_BALANCE_CELL: If it is additional, enter the address to which the additional UDT needs to be sent and the number of UDTs.

Authorization: Approve/Transfer_from

So how do we achieve empowerment? The same can be done with minimal UDT schemes.

Action Approve

Input Cells: Input UDT_BALANCE_CELL

Output Cells: outputs a new UDT_BALANCE_CELL_WITH_APPROVE, which is an intermediate state indicating that the Cell is in the authorized state;

Lock: UDT_APPROVE_LOCK: This is a Script in which the logical rules of authorization are written.

Authorizer information: Authorizer's public key

Licensee information: Licensee's public key

authorized amount

UDT_APPROVE_LOCK here can implement two kinds of logic, one is that the authorizer can use its own private key to unlock this Cell and use the UDT amount therein; the other is that the authorized party can use the private key of the authorized party to unlock this Cell within the authorized amount and use the UDT amount therein.

Action Transfer_from

An authorized party may invoke Transfer_from, using UDTs within the authorized amount range.

Input Cells: Input UDT_BALANCE_CELL_WITH_APPROVE

Output Cells: Output new UDT_BALANCE_CELL_WITH_APPROVE, possibly the authorized amount is not fully used, this is change; Output UDT_BALANCE_CELL, this is the UDT part transferred by the authorized party.

Note: The authorized party information in UDT_BALANCE_CELL_WITH_APPROVE can be Lock Script or Type Script. So the authorized party here could be one address, or N addresses, or another contract.

The above is how to implement user-defined Token on CKB. Xiaobian believes that some knowledge points may be seen or used in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.

Views: 0

*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.

Share To

Internet Technology

Wechat

© 2024 shulou.com SLNews company. All rights reserved.

12
Report