使用區塊鏈 App 產生器進行權杖化支援

單詞化

權杖化是由權杖表示的實體或數位資產，這些權杖可以傳輸、追蹤並儲存在區塊鏈上。藉由將資產代表為權杖，您可以使用區塊鏈分類帳來建立資產的狀態和擁有權，並使用標準區塊鏈平台功能來轉移資產的所有權。

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

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

自動產生的權杖 API: Blockchain App Builder 會自動產生支援權杖和權杖生命週期的方法。您可以使用這些方法來初始化記號、管理角色和帳戶，以及完成其他記號生命週期工作，而無需進行任何其他編碼。
權杖 SDK: Token SDK 包含可協助您開發記號應用程式之複雜業務邏輯的方法。
多功能並行控制 (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 支援的權杖類型：

標準	支援的權杖類型
權杖分類架構	分數有趣記號
ERC-721 型	整體不可行記號
ERC-1155 型	全效記號分數有趣記號整體不可行記號分數不可行記號

權杖化流程

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

典型的權杖化流程遵循下列基本步驟：

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

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

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

存取控制

權杖化支援包含存取控制功能，支援以角色為基礎和以擁有權為基礎的控制機制。透過以角色為基礎的控制，使用者可以呼叫具有相關角色的特定方法，例如 Token Admin 或 Token Minter。透過以擁有權為基礎的控制，您可以限制使用者存取不屬於他們的資產。使用以擁有權為基礎的存取控制，擁有資產的使用者可以呼叫特定方法，例如 Token Owner 或 Account Owner。如需方法的存取控制特定資訊，請參閱下列主題中記錄之方法的個別項目：

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

權杖管理員: 部署權杖鏈碼時，可以指派 Token Admin 使用者。Token Admin 使用者資訊會儲存在狀態資料庫中。Token Admin 使用者可以授予和移除其他使用者的 Token Admin 權限。Token Admin 使用者無法移除自己的 Token Admin 權限。Token Admin 使用者可以將 Org Admin、minter、Burner 或公證角色指派給任何使用者。
組織管理員: 擴充的「記號分類架構」方法支援 Org Admin 角色。Token Admin 使用者可以將 Org Admin 角色指派給任何使用者。Org Admin 使用者具有管理權限，但僅在其組織內。他們可以建立帳戶或查看帳戶餘額，但只能針對其組織中的使用者。Org Admin 具有較小、較耗用者或公證人角色的使用者可以將該角色指派給其組織中的其他使用者。
Token Minter: 被指派較小角色的使用者是 Token Minter，可以提示記號。
Token Burner: 被指派燃燒器角色的使用者是 Token Burner，可以燒錄記號。
記號公證人: 被指派公證人角色的使用者是 Token Notary。Token Notary 在付款人與受款人之間的交易中扮演第三方角色。Token Notary 可以觸發從付款人到受款人的記號轉移完成，或者可以將記號傳回給付款人的帳戶。
保存庫管理程式: 被指派 Vault 角色的使用者是 Vault Manager。Vault Manager 可以解除鎖定鎖定的 NFT。保存庫角色僅適用於擴充的 ERC-721 和 ERC-1155 標準。將 Vault 角色指派給使用者是鎖定 NFT 的先決條件。每個鏈碼只能指定一個使用者作為保存庫角色。

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

帳戶擁有者: 任何具有帳戶的使用者都是 Account Owner。
權杖擁有者: 所有目前擁有不可行記號的使用者都是該記號的 Token Owner。

在某些方法中，也可以結合角色型存取控制與以擁有權為基礎的存取控制。例如，以角色為基礎的存取控制可讓具有較小角色的使用者建立記號。使用以擁有權為基礎的存取控制，非功能權杖擁有者可以修改權杖的自訂特性，但無法修改權杖描述資料。具有較小角色的使用者建立不可行記號 (NFT) 時，他們會成為 NFT 的擁有者。身為 NFT 的擁有者，他們可以修改自訂特性 (針對 art collection token，記號價格是自訂特性)。權杖建立者將 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 程式碼：建立鏈碼時，請在建立鏈碼視窗中選取啟用 MVCC 最佳化。

若要使用在舊版 Blockchain App Builder 中建立的鏈碼進行最佳化，請完成下列步驟：

安裝最新版本的區塊鏈 App 產生器之後，請依照升級 CLI 中的鏈碼專案和升級 Visual Studio 程式碼中的鏈碼專案中的說明升級鏈碼。
編輯鏈碼根資料夾中的 .ochain.json 檔案，將 enableMvccOptimization 設為 true。
同步鏈碼，它會新增最佳化，並在鏈碼的根資料夾中建立兩個新資料夾：statedb 和 tokens。如需同步化的詳細資訊，請參閱將規格檔案變更與產生的原始程式碼同步與將規格檔案變更與產生的原始程式碼同步。

其他解決 MVCC_READ_CONFLICT 錯誤的方法，包括在產生此錯誤時讓從屬端應用程式重試要求，或使用佇列擷取並行要求，再將它們傳送至區塊鏈網路。如需詳細資訊，請參閱 Hyperledger Fabric 文件中的 Read-Write set semantics 。

附註：

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