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

トークン化

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

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

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

自動生成されたトークンAPI: ブロックチェーン・アプリケーション・ビルダーは、トークンおよびトークン・ライフサイクルをサポートするメソッドを自動的に生成します。これらのメソッドを使用して、トークンの初期化、ロールとアカウントの管理、およびその他のトークン・ライフサイクル・タスクを追加コーディングなしで行えます。
トークンSDK: トークン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の標準です。トークン・タクソノミ・フレームワークは、トークン・タクソノミ・イニシアチブによって開発されました。詳細は、「Token Taxonomy Framework」を参照してください。

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

標準	サポートされるトークン・タイプ
トークン・タクソノミ・フレームワーク	フラクショナル代替可能トークン
ERC-721	ホール非代替トークン
ERC-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、ミンター、バーナーまたは公証人ロールを割り当てることができます。
組織管理: 拡張トークン・タクソノミ・フレームワーク・メソッドでは、Org Adminロールがサポートされます。Token Adminユーザーは、Org Adminロールを任意のユーザーに割り当てることができます。Org Adminユーザーは管理権限を持ちますが、その権限は組織内に限られます。アカウントを作成したり、アカウント残高を確認できますが、対象となるのは組織内のユーザーのみです。ミンター・ロール、バーナー・ロールまたは公証人ロールを持つOrg Adminユーザーは、そのロールを組織内の他のユーザーに割り当てることができます。
トークン・ミンター: ミンター・ロールが割り当てられているユーザーはToken Minterで、トークンをミントできます。
トークン・バーナー: バーナー・ロールが割り当てられているユーザーはToken Burnerで、トークンをバーンできます。
トークン公証人: 公証人ロールが割り当てられているユーザーは、Token Notaryです。Token Notaryは、支払者と受取人の間のトランザクションにおいて第三者として機能します。Token Notaryは、支払者から受取人へのトークン転送の完了をトリガーしたり、かわりに支払者のアカウントにトークンを返すことができます。
ボールト・マネージャ: ボールト・ロールが割り当てられているユーザーは、Vault Managerです。Vault Managerは、ロックされたNFTのロックを解除できます。ボールト・ロールは、拡張されたERC-721およびERC-1155標準にのみ適用できます。NFTをロックするための前提条件は、ボールト・ロールをユーザーに割り当てることです。ボールト・ロールを割り当てることができるのは、チェーンコードごとに1人のユーザーのみです。

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

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

ロールベースのアクセス制御と所有権ベースのアクセス制御を組み合せた方法もあります。たとえば、ロールベースのアクセス制御では、ミンター・ロールを持つユーザーがトークンを作成できます。所有権ベースのアクセス制御では、非代替トークン所有者はトークンのカスタム・プロパティを変更できますが、トークン・メタデータは変更できません。ミンター・ロールを持つユーザーが非代替トークン(NFT)を作成すると、そのユーザーはNFTの所有者になります。そのNFTの所有者として、カスタム・プロパティを変更できます(アート・コレクション・トークンの場合、トークン価格はカスタム・プロパティです)。トークン作成者がNFTを別のユーザーに転送すると、2番目のユーザーが所有者となり、トークンを作成したユーザーがトークンの所有者ではなくなります。所有権ベースのアクセス制御により、新しい所有者はカスタム・プロパティ値を更新できますが、前の所有者はもう更新できません。ロールベースのアクセス制御により、前の所有者は引き続きNFTをミントできますが、新しいユーザーはできません。

独自のアクセス制御関数を作成したり、アクセス制御を無効にしたりすることもできます。アクセスを制御する自動生成されたコードを次の例に示します。

TypeScript:

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

Go:

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: チェーンコードを作成する際、「Create Chaincode」ウィンドウで「Enable MVCC optimization」を選択します。

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

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

MVCC_READ_CONFLICTエラーを回避する他の方法には、このエラーの発生時にクライアント・アプリケーションにリクエストを再試行させる方法や、ブロックチェーン・ネットワークに送信される前にキューを使用して同時リクエストを捕捉する方法などがあります。詳細は、Hyperledger Fabricドキュメントの「Read-Write set semantics」を参照してください。

ノート:

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