ブロックチェーン・アプリケーション・ビルダーを使用したトークン化のサポート

トークン化

トークン化は、物理アセットまたはデジタル・アセットがトークンで表されるプロセスであり、ブロックチェーンに転送、追跡および格納できます。資産をトークンとして表すことで、ブロックチェーン台帳を使用して資産の状態と所有権を確立し、標準のブロックチェーン・プラットフォーム機能を使用して資産の所有権を移すことができます。

ブロックチェーン・アプリケーション・ビルダーにはトークン化のサポートが含まれています。トークン・クラスとメソッドは自動的に生成され、開発者がトークンの複雑なビジネス・ロジックを作成できるように追加のトークン・メソッドが提供されます。自動生成されたプロジェクトには、トークン・ライフサイクル・クラスと関数、CRUDメソッドおよび追加のトークンSDKメソッドが含まれ、引数の自動検証、マーシャリング/アンマーシャリングおよび透過的な永続性機能がサポートされます。これらのコントローラメソッドを使用して、トークンの初期化、アクセスの制御、アカウントの設定、役割の管理、およびトークンのライフサイクルの管理を行うことができます。

次の図は、トークンAPIやトークンSDKなど、ブロックチェーン・アプリケーション・ビルダーによって実装されるトークン・アーキテクチャを示しています。トークン・アーキテクチャの図

自動生成されたトークンAPI: Blockchain App Builderは、トークンとトークンのライフサイクルをサポートするメソッドを自動的に生成します。これらの方法を使用すると、トークンを初期化し、ロールとアカウントを管理し、その他のトークン・ライフサイクル・タスクを追加のコーディングなしで完了できます。
トークンSDK: Token SDKには、トークン・アプリケーションの複雑なビジネス・ロジックを開発するのに役立つメソッドが含まれています。
マルチバージョン並列性制御(MVCC)の最適化: トークンチェーンコードのMVCC最適化により、転送、ミント、書き込み、および保持操作のエラーを減らすことができます。

トークンと勘定科目/残高モデル

ブロックチェーン・アプリケーション・ビルダーは、真菌性トークンおよび非真菌性トークンをサポートします。真菌性トークンには、交換可能な値があります。真菌性トークンの数量は、同じトークンのクラスの他の等しい数量と同じ値です。無菌トークンは一意です。トークンは、全体または小数でもかまいません。小数のトークンは、指定した小数点以下の桁数に基づいて、小さい部分に分割できます。

トークンは動作によっても記述できます。真菌性トークンのサポートされている動作には、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が含まれているため、ユーザーは複数の組織にわたってサポートできます。

トークン標準

ブロックチェーン・アプリケーション・ビルダーは、トークンの構造と動作を定義するために、トークン・タクソノミ・フレームワーク、ERC-721標準およびERC-1155標準の標準と分類を拡張します。ERC-1155は、真菌性トークンと非真菌性トークン(NFT)の両方をサポートする標準です。ERC-721はNFTの標準です。トークン・タクソノミ・フレームワークは、トークン・タクソノミ・イニシアチブによって開発されました。詳細は、トークン・タクソノミ・フレームワークを参照してください。

次の表に、ブロックチェーン・アプリケーション・ビルダーがサポートするトークン・タイプを示します。

標準	サポートされるトークン・タイプ
トークン・タクソノミ・フレームワーク	分数の真菌性トークン
エルク-721	無菌トークン全体
エルク-1155	全真菌トークン分数の真菌性トークン無菌トークン全体小数の非代替トークン

トークン化フロー

ブロックチェーン・アプリケーション・ビルダーでは、入力仕様ファイルの構文を拡張してトークン化がサポートされるため、CLIまたはVisual Studio Codeを使用して、他のプロジェクトと同じ方法でトークン固有のプロジェクトを作成します。詳細は、「入力仕様ファイル」を参照してください。

一般的なトークン化フローは、次の基本ステップに従います。

使用するトークン標準を決定します。
指定するトークンの動作(mintable、transferable、divisible、indivisible、singleton、holdable、burnableおよびroles)を決定します。
入力仕様ファイルでトークン・アセットとそのプロパティを定義します。
入力仕様ファイルからチェーンコード・プロジェクトをスキャフォールドします。これにより、トークン・アセット定義とそのプロパティを含むモデル、およびトークンの動作とメソッドを含むコントローラを含む、スキャフォールドされたプロジェクトが作成されます。
チェーンコード・プロジェクトをデプロイおよびテストします。

トークンベースのプロジェクトをデプロイした後、トークンを作成し、ライフサイクル操作を完了するための一般的なフローは、次のステップに従います。

トークン・チェーンコードがデプロイされ、初期化メソッドに渡されるリスト内のユーザーがチェーンコードのToken Adminユーザーになります。
トークン化されたアセットが初期化されます。これにより、トークンの特定のインスタンスの一意の識別子であるtoken_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またはnotaryロールを割り当てることができます。
組織管理: 拡張トークン・タクソノミ・フレームワーク・メソッドでは、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のロックを解除できます。ボールト役割は、拡張されたERC-721およびERC-1155標準にのみ適用できます。NFTをロックするための前提条件は、ボールト・ロールをユーザーに割り当てることです。ボールト・ロールを割り当てることができるのは、チェーンコードごとに1人のユーザーのみです。

所有権ベースのアクセス制御では、次のペルソナがサポートされます。

アカウント所有者: アカウントを持つユーザーは、Account Ownerです。
トークン所有者: 現在、非代替トークンを所有しているユーザーは、そのトークンのToken Ownerです。

一部の方法では、役割ベースのアクセス制御と所有権ベースのアクセス制御も結合されています。たとえば、ロールベースのアクセス制御では、minterロールを持つユーザーがトークンを作成できます。所有権ベースのアクセス制御では、非代替トークン所有者はトークンのカスタムプロパティーを変更できますが、トークンメタデータは変更できません。minterロールを持つユーザーが非代替トークン(NFT)を作成すると、そのユーザーはNFTの所有者になります。そのNFTの所有者として、カスタム・プロパティを変更できます(アート・コレクション・トークンの場合、トークン価格はカスタム・プロパティです)。トークン作成者がNFTを別のユーザーに転送すると、2番目のユーザーが所有者となり、トークンを作成したユーザーがトークンの所有者ではなくなります。所有権ベースのアクセス制御により、新しい所有者はカスタム・プロパティ値を更新できるようになりましたが、前の所有者は更新できなくなります。ロールベースのアクセス制御のため、前の所有者は引き続き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最適化の有効化」を選択します。

ブロックチェーン・アプリケーション・ビルダーの以前のバージョンで作成されたチェーンコードで最適化を使用するには、次のステップを実行します:

ブロックチェーン・アプリケーション・ビルダーの最新バージョンをインストールした後、CLIでのチェーンコード・プロジェクトのアップグレードおよびVisual Studio Codeでのチェーンコード・プロジェクトのアップグレードの説明に従ってチェーンコードをアップグレードします。
チェーンコードのルート・フォルダにある.ochain.jsonファイルを編集して、enableMvccOptimizationをtrueに設定します。
チェーンコードを同期します。これにより、最適化が追加され、チェーンコードのルート・フォルダに2つの新しいフォルダ(statedbおよびtokens)が作成されます。同期の詳細は、「仕様ファイルの変更と生成されたソース・コードとの同期」および「仕様ファイルの変更と生成されたソース・コードとの同期」を参照してください。

MVCC_READ_CONFLICTエラーを回避する他の方法には、このエラーの生成時にクライアント・アプリケーションの再試行リクエストを指定したり、ブロックチェーン・ネットワークに送信される前にキューを使用してコンカレント・リクエストを取得したりなどがあります。詳細は、Hyperledger Fabricドキュメントの読取り/書込みセット・セマンティクスを参照してください。

ノート:

MVCC最適化は、Oracle Blockchain PlatformとHyperledger Fabricの両方のピアを含むハイブリッド・ネットワーク、またはローカルのHyperledger Fabricネットワークでのテストでは機能しません。ハイブリッドネットワーク上でMVCC最適化を有効にしないでください。これにより、ピア間の不整合が発生する可能性があります。