1. 程式人生 > >【CKB.DEV 茶話會】如何在 CKB 上實現使用者自定義 Token

【CKB.DEV 茶話會】如何在 CKB 上實現使用者自定義 Token

本貼內容主要來自於 CKB.DEV 茶話會第一期,本期主題是:如何在 CKB 上實現 UDT,分享人是:Cipher 王博。

茶話會現場視訊:
https://v.qq.com/x/page/x30304t25l4.html

CKB 的交易與合約模型

因為 CKB 與以太坊的程式設計模型完全不同,因此有必要在開始之前向大家介紹一下 CKB 的交易與合約模型。

首先 CKB 的交易模型是 UTXO 結構,每一筆交易會銷燬一部分 Cells,生成一部分新的 Cells,Cells 是 CKB 網路上最小的結構單位。

CKB 的交易模型是和比特幣類似的,但是在此基礎上進行了擴充套件,在比特幣上的銷燬和生成規則是確定的,而 CKB 的核心進步點在於 CKB 上的指令碼是使用者可以自定義的。

比如說,我們現在在 CKB 上用的簽名演算法是 SECP256K1,這個和比特幣,以太坊使用的簽名演算法是一致的,但是在比特幣和以太坊上這個簽名演算法是寫在節點裡面的,是無法更改的,而在 CKB 上不存在原生的簽名演算法,如果你想在 CKB 上實現另一種簽名演算法 SECP256R1,你只需要自己編寫關於 SECP256R1 的指令碼,然後寫入 Lock Script 就可以實現了,而在以太坊上需要實現這一功能必須經過硬分叉。而在 CKB 上簽名演算法是隨時可替換的。

CKB 另一個較大的進步在於,在比特幣上轉賬前後的餘額必須一致,這一等式是固化在節點內的,因此比特幣上只有原生的 BTC,無法實現其他的 UDT。而這一點在 CKB 上也是可以自定義的,也就是 CKB 內的 Type Script,也就是說使用者可以在此基礎上進行額外的轉賬規則的開發。比如使用者可以自定義 Type Script 中的某一個欄位在轉賬前後的餘額必須一致,這實際上就可以在 CKB 上實現新的 UDT,因為這裡面 Type Script 指定的物件可以不再侷限於原生的 CKB Token,而可以是任意一種新建立的 UDT。

另外 CKB 和以太坊的設計模式是完全不同的。在以太坊上合約重點關注的是行為的意圖,而不是行為的結果,相反的在 CKB 上,我們重點關注的是行為的結果。以太坊上的合約互動採用的是介面對介面的方式,而 CKB 的 Script 互動採用的是狀態對狀態的方式。

ERC20 回顧與分析

這邊我們再回顧一下 ERC20 的內容,經過分析,我們會發現 ERC20 是存在非常多問題的:


常見 ERC20 合約提供的方法和事件

  • ERC20 僅定義了介面,未統一實現。你每建立一個新的 ERC20,都需部署一個新的合約,而使用者很難一個個去了解每一個合約。另外由於每個新的合約都是開發者重新建立的,這導致很多的 ERC20 合約或故意或無意地出現了安全問題。
  • ERC20 介面中使用者的行為是耦合的。比如其中的 totalSupply,mint,burn 是管理員的行為;而 balanceOf,approve,transfer 是普通使用者的行為,而 allowance,transferFrom 則是授權使用者的行為。我們可以看到這一個 ERC20 的合約內至少耦合了三種使用者的行為,是相對混亂的。
  • ERC20 中的邏輯和資料是耦合的。合約的實現邏輯和使用者地址下擁有的金額資料都是在這個合約內的,正因為這種耦合,因此以太坊上無法進行統一實現。

CKB 上實現 UDT 的設計思路:

  • 邏輯與狀態分離,使用統一的業務程式碼。安全將得到極大的保障。
  • 使用者行為、管理員行為、授權行為分離。
  • 僅提供最核心的 UDT 功能。指提供最核心的 UDT 功能,保障開發者對 UDT 靈活性的需求。
  • 採用面向狀態,注重行為結果的設計模式,去定義 UDT 的行為。

最小化的 UDT

最小化 UDT 最核心的兩大功能:一個是發幣,這裡需要定義 UDT 的基本資訊,並保持 UDT 唯一性;另一個是轉賬,保證 UDT 前後的一致性。

發幣:Create Action

Input Cells :填入 Cells,銷燬這部分 CKB 的狀態。可以是大家目前正在持有的 CKB,也可以是正在使用中的 CKB 等等。

Output Cells:這邊包括兩部分,一個是 UDT_ID_CELL 用來描述這個 UDT 的邏輯規則、基本資訊和唯一性。另一個是 UDT_BALANCE_CELL 用來描述這個 UDT 的餘額,保證轉賬前後的一致性。

UDT_ID_CELL 這邊主要包含幾個內容:

  • Type Script:用於存放 UDT 建立的邏輯規則,和 UUID 用於描述這個 UDT 的唯一性;
  • Lock Script:簡單而言就是簽名演算法,解釋誰可以解開這個 Cell;
  • Data:用於存放 UDT 的定義資料。建立者資訊,建立 UDT 數量,小數點尾數等等。

UDT_BALANCE_CELL 這邊主要包含幾個內容:

  • Type Script:用於存放 UDT 轉賬的邏輯規則,和 UUID 用於描述這個 UDT 的唯一性;
  • Lock Script:簡單而言就是簽名演算法,解釋誰可以解開這個 Cell;
  • Data:用於表示 UDT 的餘額。

轉賬:Transfer Action

UDT 的轉賬會相對容易,銷燬一部分 UDT,生成一部分新的 UDT 即可實現轉賬。

Input Cells :
放入一部分 UDT_BALANCE_CELL(s) 作為 Input。

Output Cells :
放入一部分 UDT_BALANCE_CELL(s) 作為 Output。

擴充套件 Minimal UDT

上面我們實現的是最小化 UDT,只設計了發幣和轉賬這兩個最基礎的功能。那對於其他的複雜的功能要如何實現呢?

增發/銷燬:Mint/Burn Action

對於 UDT 的管理員,他可能需要對 UDT 進行一些增發和銷燬的操作。這裡就需要對於我們上面建立的 UDT_ID_CELL 進行一些修改。

Input Cells :

  • 輸入 UDT_ID_CELL,當然只有之前 UDT_ID_CELL 中 Lock Script 規定的管理員才可以進行這樣的操作,不是誰都可以進行這樣的操作的。
  • (optional) UDT_BALANCE_CELL:如果是銷燬,就在這裡輸入需要銷燬的 UDT 的地址和 UDT 數量。

Output Cells:

  • 輸出新的 UDT_ID_CELL,這是規則發生更改後,新生成的 UDT_ID_CELL;
  • (optional) UDT_BALANCE_CELL:如果是增發,就在這裡輸入增發的 UDT 需要傳送到的地址和 UDT 數量。

授權:Approve/Transfer_from

那麼如何實現授權行為呢?一樣的我們可以在最小 UDT 方案上進行擴充套件。

Action Approve

Input Cells :
輸入UDT_BALANCE_CELL

Output Cells:
輸出新的UDT_BALANCE_CELL_WITH_APPROVE,這是中間狀態,表示這個 Cell 處於授權中的狀態;

  • Lock:UDT_APPROVE_LOCK:這是一個 Script,其中寫入了授權的邏輯規則
    • 授權方資訊:授權方的公鑰
    • 被授權方資訊:被授權方的公鑰
    • 授權金額

這邊的 UDT_APPROVE_LOCK 可以實現兩種邏輯,一個是授權方可以用自己的私鑰解開這個 Cell,使用其中的 UDT 金額;另一個是被授權方可以在授權金額的額度內,使用被授權方的私鑰將這個 Cell 解開,使用其中的 UDT 金額。

Action Transfer_from

被授權方可以呼叫 Transfer_from,使用其中授權金額範圍內的 UDT。

Input Cells :
輸入 UDT_BALANCE_CELL_WITH_APPROVE

Output Cells:
輸出新的 UDT_BALANCE_CELL_WITH_APPROVE,可能授權金額沒有完全使用,這是找零;
輸出 UDT_BALANCE_CELL,這是被授權方轉出的 UDT 部分。

注意:UDT_BALANCE_CELL_WITH_APPROVE 中的被授權方的資訊,可以是 Lock Script 也可以是 Type Script。所以這裡的被授權方可以是一個地址,也可以是 N 個地址,也可以是另一個合約。

在分享的最後,Cipher 還向大家介紹了一個 Token Swap 的例子。

加入 Nervos Community

Nervos Community 致力於成為最好的 Nervos 社群,我們將持續地推廣和普 及 Nervos 技術,深入挖掘 Nervos 的內在價值,開拓 Nervos 的無限可能, 為每一位想要深入瞭解 Nervos Network 的人提供一個優質的平臺。

新增微訊號:BitcoinDog 即可加入 Nervos Community,如果是程式設計師請備註,還會將您拉入開發者群