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

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

茶話會現場視頻：https://v.qq.com/x/page/x3030...

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，若是是程序員請備註，還會將您拉入開發者羣。