單詞化

權杖化是實體或數位資產以權杖表示的流程，這些權杖可以傳輸、追蹤並儲存在區塊鏈上。

透過將資產表示為權杖，您可以使用區塊鏈分類帳來建立資產的狀態和所有權，並使用標準區塊鏈平台功能來轉移資產的所有權。

Blockchain App Builder 包含權杖化支援：系統會自動產生權杖類別和方法，並提供其他權杖方法，讓開發人員能夠為權杖建立複雜的業務邏輯。自動產生的專案包含權杖生命週期類別和函數、CRUD 方法和其他權杖 SDK 方法，並支援自動驗證引數、封送處理 / 解除封送處理 (Marshal/unmarshalling) 以及通透的持續性功能。您可以使用這些控制器方法來初始化記號、控制存取、設定帳戶、管理角色，以及管理記號的生命週期。

下圖顯示 Blockchain App Builder 所實行的權杖架構，包括權杖 API 和權杖 SDK。

自動產生的權杖 API

Blockchain App Builder 會自動產生支援權杖和權杖生命週期的方法。您可以使用這些方法來初始化記號、管理角色和帳戶，以及完成其他記號生命週期工作，而無需進行任何其他編碼。

權杖 SDK

Token SDK 包含了能幫助您為 Token 應用程式開發複雜商業邏輯的方法。

多重轉移並行控制 (MVCC) 最佳化

權杖鏈碼的 MVCC 最佳化可以減少傳輸、薄荷、燒錄和保留作業的錯誤。

變數替代字與帳戶 / 餘額模型

Blockchain App Builder 支援有趣且不可行的權杖。

有趣的權杖具有可互換的值。任何有趣記號數量的值，都會與相同類別記號的任何其他相等數量相同。不可行的權杖是唯一的。記號也可以是整數或分數。分數記號可以根據指定的小數位數，細分為較小的部分。

權杖也可以依行為描述。有趣記號的支援行為包括：mintable、transferable、divisible、holdable、burnable 及 roles (minter、burner 及 holder)。對不可行記號的支援行為包括：mintable、transferable、singleton、indivisible、burnable 和 roles (minter 和 burner)。

權杖化功能使用帳戶 / 餘額模型，將權杖化資產表示為帳戶中的餘額。帳戶與一般銀行帳戶類似，其中存款、轉帳及其他狀態轉換會影響帳戶的餘額。系統會全域追蹤每個科目的餘額，以確保交易金額有效。同時也會追蹤保留結餘 (適用於有趣的記號) 和交易歷史記錄。

任何擁有權杖或完成權杖相關作業的使用者，都必須在網路上擁有一個帳戶。每個帳戶都使用唯一的 ID (account_id) 來識別。帳戶 ID 是透過結合執行處理擁有者的使用者名稱或電子郵件 ID (user_id) 或登入執行處理的使用者，以及目前網路組織中使用者的成員服務提供者 ID (org_id) 來建立。系統提供準備使用的方法來建立帳戶。因為帳戶 ID 包含組織 ID，所以多個組織可以支援使用者。

權杖標準

Blockchain App Builder 擴展了權杖分類架構、ERC-721 標準和 ERC-1155 標準的標準和分類，以定義權杖的異常和行為。

ERC-1155 是支援有趣和不可行記號 (NFT) 的標準。ERC-721 是 NFT 的標準。「權杖分類架構」是由「權杖分類標準初步計畫」所開發。如需詳細資訊，請參閱權杖分類架構。

下表描述 Blockchain App Builder 支援的權杖類型：

標準	支援的權杖類型
權杖分類架構	分數有趣的記號
二氧化碳 -721	整個不可行記號
ERC-1155	完整有趣的記號 分數有趣的記號 整個不可行記號 分數不可變記號

變數替代字流程

由於 Blockchain App Builder 支援透過擴充輸入規格檔案語法來進行記號化，因此您可以使用 CLI 或 Visual Studio Code 建立其他專案的方式，建立記號特定專案。

如需使用 Blockchain App Builder 建立專案的詳細資訊，請參閱輸入規格檔案。

典型的記號化流程遵循下列基本步驟：

• 決定要使用的記號標準。
• 決定要指定的記號行為 (mintable、transferable、divisible、indivisible、singleton、holdable、burnable 和 roles)。
• 在輸入規格檔案中定義記號資產及其特性。
• 從輸入規格檔案編寫鏈碼專案。這會建立鷹架式專案，包括包含記號資產定義及其特性的模型，以及包含記號行為與方法的控制器。
• 部署並測試鏈碼專案。

部署權杖型專案之後，建立權杖和完成生命週期作業的一般流程如下：

• 系統會部署記號鏈碼；傳遞至初始化方法之清單中的使用者會成為鏈碼的 Token Admin 使用者。
• 已起始記號化資產，此資產會建立 token_id，這是該記號特定執行處理的唯一 ID。
• 必須為每個擁有權杖或完整權杖相關作業的使用者建立帳戶。
• 如果為記號指定了 roles 行為，則必須先將角色指派給使用者，才能完成記號相關作業。
• 接著，您可以根據為權杖資產指定的行為來使用權杖生命週期方法。例如，您可以呼叫方法來提示帳戶的記號。

存取控制

記號化支援包括存取控制功能，支援以角色為基礎與以擁有權為基礎的控制機制。

透過以角色為基礎的控制，使用者可以呼叫具有相關角色的特定方法，例如 Token Admin 或 Token Minter。透過以所有權為基礎的控制，您可以限制使用者存取不是其所有權的資產。透過以擁有權為基礎的存取控制，擁有資產的使用者可以呼叫特定方法，例如 Token Owner 或 Account Owner。如需方法存取控制的特定資訊，請參閱下列主題中記載之方法的個別項目：

• ERC-1155 的鷹架式 TypeScript 權杖專案
• ERC-1155 的鷹架式 Go Token 專案
• ERC-721 的鷹架式 TypeScript NFT 專案
• ERC-721 的鷹架式 Go NFT 專案
• 記號分類架構的鷹架式 TypeScript 專案
• 權杖分類架構的鷹架式 Go 專案

以角色為基礎的存取控制支援下列角色：

權杖管理

部署權杖鏈碼時，可以指派 Token Admin 使用者。Token Admin 使用者資訊會儲存在狀態資料庫中。Token Admin 使用者可以授與其他使用者並移除 Token Admin 權限。Token Admin 使用者無法移除自己的 Token Admin 權限。Token Admin 使用者可以將 Org Admin、礦工、燒錄機或公證角色指派給任何使用者。

組織管理

延伸的「權杖分類架構」方法支援 Org Admin 角色。Token Admin 使用者可以指派 Org Admin 角色給任何使用者。Org Admin 使用者具有管理權限，但僅限於其組織內。他們可以建立帳戶或查看帳戶餘額，但只能對組織中的使用者查看。Org Admin 具有礦工、燃燒器或公證角色的使用者可以將該角色指派給其組織中的其他使用者。

權杖探勘器

被指派 minter 角色的使用者是 Token Minter，可以提示記號。

權杖燃燒器

被指派燃燒器角色的使用者是 Token Burner，可以燒錄記號。

權杖公證人

被指派公證人角色的使用者是 Token Notary。Token Notary 在付款人與受款人之間的交易中扮演第三方角色。Token Notary 可觸發將記號從付款人轉移至受款人的完成作業，或改為將記號傳回付款人的帳戶。

保存庫管理程式

具備 Vault 角色的使用者為 Vault Manager。Vault Manager 可解除鎖定已鎖定的 NFT。Vault 角色僅適用於延伸的 ERC-721 和 ERC-1155 標準。將 Vault 角色指定給使用者是鎖定 NFT 的先決條件。每個鏈碼只能有一個指定給保存庫角色的使用者。

權杖稽核者

僅限 Digital Assets Edition：延伸的權杖分類架構方法支援 Token Auditor 角色。此角色與 Token Admin 角色類似，但僅具有唯讀存取權。

組織稽核者

僅限 Digital Assets Edition：延伸的權杖分類架構方法支援 Org Auditor 角色。此角色與 Org Admin 角色類似，但僅具有唯讀存取權。

所有權型存取控制支援下列角色：

帳戶擁有者

任何具有帳戶的使用者都是 Account Owner。

權杖擁有者

目前擁有不可使用權杖的所有使用者都是該權杖的 Token Owner。

在某些方法中，也會結合以角色為基礎的存取控制與以擁有權為基礎的存取控制。例如，以角色為基礎的存取控制可讓具有 minter 角色的使用者建立記號。使用以擁有權為基礎的存取控制時，不可執行的記號擁有者可以修改記號的自訂特性，但無法修改記號描述資料。當具有次要角色的使用者建立非可行權杖 (NFT) 時，他們會成為 NFT 的擁有者。身為該 NFT 的擁有者，他們可以修改自訂屬性 (針對藝術收藏變數替代字，變數替代字價格為自訂屬性)。權杖建立者將 NFT 傳輸給其他使用者之後，第二個使用者就會成為擁有者，而建立權杖的使用者就不再是權杖的擁有者。由於以所有權為基礎的存取控制，新的擁有者現在可以更新自訂特性值，但先前的擁有者無法再更新。由於角色型存取控制，前一位負責人仍然可以提示 NFT，但新的使用者則無法。

您也可以撰寫自己的存取控制功能，或停用存取控制。以下範例顯示控制存取的自動產生程式碼。

TypeScript：

await this.Ctx.<Token Standard>Auth.checkAuthorization(...)

移至：

auth, err := t.Ctx.<Token Standard>Auth.CheckAuthorization(...)

附註：

若要移除自動產生的存取控制功能，請從您的 TypeScript 或 Go 專案中移除上一行程式碼。

MVCC 最佳化

Hyperledger Fabric 資料庫使用多重版本並行控制 (MVCC)，以避免雙重支出與資料不一致。

當更新相同狀態時，記錄的新版本會覆寫舊版本。如果有並行要求在區塊中更新相同的金鑰，可能會產生 MVCC_READ_CONFLICT 錯誤。

若要減少轉移、薄荷、燒錄和保持操作的 MVCC 錯誤，您可以為符記鏈碼啟用 MVCC 最佳化。此最佳化僅適用於 Oracle Blockchain Platform。預設會停用最佳化。若要啟用最佳化，請完成適用的下列步驟。

• CLI：使用 ochain init 命令指定布林值 -m 或 --enable_mvcc_optimization 參數。依預設，參數會設為 false。若要啟用最佳化，請將 -m true 新增至 ochain init 命令行。
• Visual Studio Code：當您建立鏈碼時，請在建立鏈碼視窗中選取啟用 MVCC 最佳化。

若要將最佳化與舊版區塊鏈 App 產生器中建立的鏈碼搭配使用，請完成下列步驟：

1. 安裝最新版本的 Blockchain App Builder 之後，請升級鏈碼，如升級 CLI 中的 Chaincode 專案和升級 Visual Studio Code 中的 Chaincode 專案中所述。
2. 編輯鏈碼根資料夾中的 .ochain.json 檔案，將 enableMvccOptimization 設為 true。
3. 同步鏈碼，以新增最佳化，並在鏈碼的根資料夾中建立兩個新資料夾：statedb 和 tokens。如需有關同步的詳細資訊，請參閱使用產生的來源代碼同步規格檔案變更與使用產生的來源代碼同步規格檔案變更。

解決 MVCC_READ_CONFLICT 錯誤的其他方法包括在產生此錯誤時讓用戶端應用程式重試要求，或使用佇列先擷取並行要求，再將它們傳送到區塊鏈網路。如需詳細資訊，請參閱 Hyperledger Fabric 文件中的讀寫集語意。

附註：

MVCC 最佳化不適用於同時包含 Oracle Blockchain Platform 和 Hyperledger Fabric 對等的混合式網路，也不適用於在本機 Hyperledger Fabric 網路上進行測試。請勿在混合網路上啟用 MVCC 最佳化，因為這可能會導致對等之間不一致。