4 デジタル・ アセットのAPI

Oracle Blockchain Platform Enterprise Edition for Besuは、スマート・コントラクトの操作に使用できるデジタル・アセットAPIを提供しています。

デジタル・アセットAPIは、Besuでデジタル・アセット・スマート・コントラクトを開発、テストおよびデプロイするための、Solidityベースの再利用可能なコンポーネントです。APIを使用して、トークン構成、アイデンティティおよびアクセス制御、アップグレード性およびガバナンスに対する一貫したアプローチを維持しながら、ドメイン固有のトークン・アプリケーションを実装できます。

Oracle Blockchain Platform Besuアプリケーションの中核は、デジタル・アセットの状態と、デジタル・アセットの作成、転送、保持、利用および管理方法を管理するビジネス・ルールを定義する1つ以上のスマート・コントラクトです。これらのルールは資産のライフサイクルに直接影響するため、契約はデプロイ前に設計、レビューおよびテストする必要があります。2つのAPIはそれぞれ異なるトークン標準をサポートしています。

トークン標準	主な用途	ユースケースの例
ERC-20	各トークンが他のすべてのトークンと交換可能な代替アセット。	支払、stablecoins、預金トークン、決済トークン、および卸売CBDC資産。
ERC-1155	純資産および非純資産(NFT) 同じスマート・コントラクトで複数のトークン・タイプがサポートされます。部分トークン(シェア)がサポートされています。	トークン化されたアセット、コレクションおよび一意のデジタル・アセット。

APIは、構成可能な基本契約およびサポート・ライブラリを提供し、独自のSolidity契約から継承したり、独自のSolidity契約に組み込むことができます。選択したトークン・モデルに応じて、アプリケーションは、ミントと書き込み、制御された転送、保留、承認、アイデンティティ対応権限、ポリシー強制などの機能を組み込むことができます。APIでは、アップグレード可能な契約パターンおよびガバナンスで制御されるライフサイクル操作もサポートされます(これらがアプリケーションで必要な場合)。

次の図は、拡張ERC-20トークン標準実装の機能を示しています。

次の図は、拡張ERC-1155token標準実装の機能を示しています。

プラガブル・アクセス制御モジュール

アカウント・モジュールおよびポリシー・モジュールを選択して、トークン操作をアプリケーションのアクセス制御モデルに連携させることができます。具体的には、APIにはERC-5982権限モデルとEIP-6617権限モデルの両方の契約バージョンとアカウント・バージョンが含まれています。これらのモジュールは、トークン・コントラクトをアイデンティティおよびポリシー・ゲートウェイに接続することで、アプリケーションは、すべてのトークン・コントラクトに単一のアクセス制御実装を埋め込むことなく、ロール対応および組織対応の認可を適用できます。

アプリケーションに適したアカウント・バリアントおよびポリシー機能を選択し、トークン契約から共通のアカウント・インタフェースを使用できます。この分離により、トークン・ビジネス・ロジックはアセットのライフサイクルに重点を置き、アプリケーション要件の進化に応じてアクセス・ポリシーを構成、拡張または交換できます。

契約構成モデル

Solidityトークン化レイヤーでは、契約構成モデルを使用します。アップグレード可能なトークン・ベースを選択し、アセット・ライフサイクルに必要な動作モジュールを追加し、そのトークンを適切なアカウントおよびアクセス制御モジュールとペアにします。このモデルは、すべての操作を公開するためにすべてのトークンを必要とせずに、ミント、書き込み、保留、承認などの機能をサポートします。厳密な構成またはミキシン/互換性の構成を使用できます。

サポートされているトークン操作が設計時にわかっている場合は、厳密な構成が適しています。開発者は、特定の機能のみをサポートする狭い基本契約から継承します。選択した操作のみが契約ABIに含まれます。初期化中は、選択された機能プロファイルに対してトークン構成が検証されるため、互換性のない動作またはミントおよび書き込みモードが拒否されます。

ミキシン/互換性の構成は、実行時の柔軟性と、より広範で再利用可能なトークン操作のセットがより重要である場合に適しています。開発者は、アクティブなオプション・ポリシーを決定する実行時動作フラグとともに、完全な基本契約から継承します。完全なABIは引き続き使用できますが、動作固有の操作では、それらが呼び出されたときに有効な構成が強制されます。

製品要件を満たす最も狭い構成を選択し、必要なアクセス制御アカウント・モジュールおよび製品固有のビジネス・ロジックと組み合せます。厳密な組成は、より小さく、より意図的なABIを生成し、サポートされていない操作が公開されることを防ぎます。ミキシン/互換性構成は、実行時に動作を構成する必要があるアプリケーションのより広範な基盤を提供します。

APIは、固定アプリケーションではなく開始ポイントとして使用します。通常、チームは必要なアセット・モデルに一致するERC-20またはERC-1155基盤を選択し、動作およびアクセス制御を構成してから、特定のビジネス・ロジックを実装してアセットのライフサイクルをサポートします。これにより、各アプリケーションに独自の参加者、認可ルールおよび運用プロセスを反映しながら、共通の契約基盤が可能になります。

このAPIは、ERC-20およびERC-1155契約ソースを直接操作するSolidity開発者を対象としています。Hardhatを使用してアプリケーションを開発およびテストし、アプリケーションに適したデプロイメント・アプローチを使用してOracle Blockchain Platform環境にデプロイできます。

契約をデプロイおよびアップグレードするためのガバナンス・フロー

ガバナンスは、デプロイされた契約がいつ使用可能になるか、およびどのUPS実装アップグレードが認可されるかを制御します。構成されたプロジェクトでは、アカウントおよびトークン・プロキシをデプロイおよび接続し、ガバナンス契約とガバナンスUUIDの両方にアタッチします。次のライフ・サイクルに示すように、プロキシは、構成されたガバナンス・フローによってアクティブ化されるまで、意図的に非アクティブになります。

1. アカウントおよびトークンのUUPSプロキシを配備します。
2. アカウント/トークン・コンテキストおよびガバナンス・コンテキストを設定します。プロキシは非アクティブのままです。
3. プロキシ・コンポーネント、実装コンポーネントおよびコードハッシュ・コンポーネントを使用して配置目的を送信します。
4. • No-Op: すぐに受け入れられ、コンポーネントはアクティブ化されます。
   • 管理: ポリシー承認を収集し、承認後にコンポーネントがアクティブ化されます。

ガバナンス・モデル

サポートされる2つのガバナンス・モデルは、No-OpおよびGovernedです。

No-Opでは、アプリケーションからガバナンス・ライフサイクルは削除されません。同じガバナンス・インタフェースを実装し、インテントを記録し、デプロイおよびアップグレード・チェックを自動的に承認します。No-Opモデルを本番承認メカニズムとして使用しないでください。

Governedモデルでは、デプロイヤ、ブロックチェーン・アプリケーション・ビルダーまたはCLIスクリプトで承認者をバイパスできません。必要な承認者、しきい値、期限および承認プロセスは、デプロイされたガバナンスおよびポリシー構成によって定義されます。

次の表に、2つのガバナンス・モデルの動作の概要を示します。

ガバナンス・モデル	目的	デプロイメント動作	アップグレード動作
No-Op	地方開発、デモ、およびガバナンス承認が意図的にバイパスされるその他の状況。	proposeDeployIntentファンクションはインテントを受け入れ、そのコンポーネントを即時にアクティブ化します。	アップグレード・インテントはポリシー承認なしで受け入れられます。オペレータは、準備されたupgradeToAndCall実行ステップを実行します。
管理対象	ポリシーベースのレビューおよび承認を必要とする環境。	インテントは、構成済ポリシーが期限前に必要な承認を受け取るまで保留中のままです。その後は、コンポーネントがアクティブ化されます。	提案された実装とそのコード・ハッシュは、実行ステップが実装を消費してプロキシをアップグレードする前に、必要な認可を受ける必要があります。

ブロックチェーン・アプリケーション・ビルダーを使用してプロジェクトを構築する場合、次のガバナンス・ビルディング・ブロックがすでに提供されています:

• IDAContractGovernanceインタフェースと、NoOpGovernanceおよびGovernedGovernance実装。
• 生成されたトークンおよびアカウント契約ベースでのガバナンス・コンテキストおよびアクティブ化のサポート(setGovernanceContext、getGovernanceContextおよびactivateFromGovernanceメソッドを含む)。
• UUPSは、APIのUpgradeAuthorizationLibメソッドを介して認可をアップグレードします。このメソッドは、_authorizeUpgradeプロセス中に構成されたガバナンス契約を呼び出します。
• ガバナンス・コンテキストの設定、インテント・データの準備、マニフェストの記録およびインテント・リクエストの発行を行う、生成されたデプロイメントおよびアップグレード・スクリプト。

これらのビルディング・ブロックはすでに供給されているため、標準構成プロジェクトでは、生成されたトークンおよびアカウント契約に追加のSolidityガバナンス・フックを記述する必要はありません。それでも、適切なガバナンス契約を選択してデプロイまたは取得し、UUIDおよびポリシーを構成して、そのアドレスをデプロイ/アップグレード・ワークフローに提供し、管理環境の承認プロセスを受ける必要があります。Oracle Blockchain Platform Besuネットワークの場合、ガバナンス契約がインスタンス・プロビジョニングの一部としてデプロイされます。