[ERC6944] コントラクトが特定のリソース要求をどのようの処理するか指定するための仕組みを理解しよう！

はじめに

初めまして。 CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

CryptoGamesCryptoGamesは、ブロックチェーン技術を活用したゲーム・Web3事業を展開する企業です。トレーディングカード、NFT、RWA領域を中心に、新しいエンターテインメント体験を創出しています。cryptogames.co.jp

代表的なゲームはクリプトスペルズというブロックチェーンゲームです。

日本最大級ブロックチェーンゲーム(NFTゲーム)「CryptoSpells」日本初のブロックチェーンTCG、CryptoSpells。cryptospells.jp

今回は、ERC5219コントラクトのリソース要求を解決するために、ERC4804のresolveModeを追加する仕組みを提案しているERC6944についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

https://eips.ethereum.org/EIPS/eip-6944

他にも様々なEIPについてまとめています。

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

EIP (Ethereum Improvement Proposals)はEthereumの機能拡張や標準を提案するドキュメントで、その中で新たに提案されているのは、ERC5219コントラクトのリソース要求を解決するためにERC4804のresolveModeを追加するものです。

ERC5219については以下の記事を参考にしてください。

[ERC5219] GETリクエストのみの効率的なDapp通信の仕組みを理解しよう！

ERC4804については以下の記事を参考にしてください。

[ERC4804] HTTP形式のWeb3 URLからコントラクトを呼び出すことができる仕組みを理解しよう！

ERC5219

ERC5219は、スマートコントラクトに対してリソースリクエストを行い、HTTPのようなレスポンスを受け取るインターフェースを標準化するEIPです。これにより、Ethereum上の分散アプリケーション（DApps）がより分散された形で動作することが可能になります。主な動機は、DAppsが完全に分散されていない現状を改善することにあり、特に「分散された」アプリケーションのインターフェースにアクセスするためには、まずDAppのフロントエンドコードを含む中央集権的なウェブサイトにアクセスする必要があるという問題が指摘されています。この問題は、信頼の最小化、検閲のリスク、恒久性の欠如、およびDAppインターフェースとスマートコントラクト間の相互運用性の欠如など、いくつかのリスクをもたらします。

このEIPは、アプリケーションロジックとフロントエンドロジックを分離し、DAppコントラクトが特定のインターフェイスを実装することを要求します。また、ガスコストを節約するために、message/external-body MIMEタイプを使用して、スマートコントラクトが直接アクセスできないデータを指すことが推奨されています。例えば、クライアントにIPFS上のデータをフェッチするよう指示するレスポンスが示されています。

リクエストメソッドは読み取り専用とされており、トランザクションの送信コストやユーザーエクスペリエンスの悪化を避け、フロントエンドロジックをスマートコントラクトに保存することのコストや複雑さを避けるためです。このアプローチは、状態変更操作をリクエストするために他のEIPと組み合わせることができ、HTTPリクエストの完全な模倣ではなく、GETメソッドとリソース内のクエリパラメータを主に使用する簡素化されたバージョンが選択されています。

ERC4804

ERC4804は、Web2のユーザーがWeb3ブロックチェーンの内容、特にオンチェーンのWebコンテンツ（SVG/HTMLなど）に直接アクセスできるようにするための標準を提案しています。これにより、Web2プロキシ経由でのデータ読み取りの依存を減らし、ユーザーのコントロールを強化します。主に読み取り専用（例：Solidityのview関数）のセマンティクスを定義し、状態を変更する関数は将来の拡張として定義される可能性があります。

この標準は、以下の形式のWeb3 URLを使用します。

web3SchemaはURLのスキーマを示し、web3://やw3://などが使用されます。
userinfoはEVMコールメッセージの"From"フィールドを指し、特に指定がない場合は0x0が使用されます。
contractNameはコントラクトの名前を示し、EVMコールメッセージの"To"フィールドに対応します。これはアドレスまたは名前サービスからの名前であり、後者の場合は名前サービスプロバイダーのサフィックス（例：eth）を使用します。
chainidはコントラクト名を解決しメッセージを呼び出すチェーンを指定し、特に指定がない場合は名前サービスプロバイダーと同じチェーンが使用されます。
queryは属性と値のペアのシーケンスを含むオプショナルコンポーネントです。

この標準は、Web2とWeb3の間の相互運用性を高め、ユーザーがより直接的にWeb3のコンテンツにアクセスできるようにすることを目指しています。

仕様

/// @dev IDecentralizedApp is the ERC-5219 interface
interface IERC5219Resolver is IDecentralizedApp {
    // @notice The ERC-4804 resolve mode
    // @dev    This MUST return "5219" (0x3532313900000000000000000000000000000000000000000000000000000000) for ERC-5219 resolution (case-insensitive). The other options, as of writing this, are "auto" for automatic resolution, or "manual" for manual resolution.
    function resolveMode() external pure returns (bytes32 mode);
}

ERC5219をERC4804のresolveModeとして使用したいコントラクトが実装しなければならないインターフェイスに関する説明です。以下のIERC5219Resolverインターフェースは、ERC5219標準を適用し、ERC4804のresolveモードとして機能するための具体的な要件を定義します。

`IERC5219Resolver` インターフェイス

このインターフェイスは、IDecentralizedAppを継承しており、ERC5219標準に準拠したDappsのためのものです。この継承は、IERC5219ResolverがDappsの一般的な機能や定義を含むようにするためのものです。

`resolveMode()` 関数

この関数は、ERC4804のresolveモードを指定するために使用されます。

戻り値
- bytes32型のmodeを返します。
- このmodeは、スマートコントラクトがどのようにしてERC5219のリソース要求を解決するかを定義します。
定義されたモード
- "5219"
  - このモードは、ERC5219の解決方式を明示的に使用することを示します。
  - モード値は0x3532313900000000000000000000000000000000000000000000000000000000として返され、これは16進数で"5219"に相当します。
  - このモードを選択したコントラクトは、ERC5219に準拠した解決メカニズムを使用することを意味します。
- "auto"
  - 自動解決モードを示し、スマートコントラクトが最適な解決策を自動で選択することを意味します。
- "manual"
  - 手動解決モードを示し、ユーザーまたは開発者が解決方法を手動で指定する必要があることを意味します。

実装について

スマートコントラクトがERC4804のリゾルブモードとしてERC5219を選択する場合、IERC5219Resolverインターフェイスを実装し、resolveMode()関数で"5219"を返すようにしなければなりません。これにより、そのコントラクトはERC5219に基づいた解決メカニズムを使用することが保証されます。

この設計は、スマートコントラクト開発者がリソース解決のメカニズムを明示的に指定できる柔軟性を提供し、ERC5219標準の利用を促進することを目的としています。また、このようなインターフェースの定義は、Ethereum上でのdAppの相互運用性と標準化を促進することにも寄与します。

補足

ERC165は、スマートコントラクトが特定のインターフェイスをサポートしているかどうかを検出するための標準です。コントラクトがERC165を実装している場合、他のコントラクトはsupportsInterface関数を呼び出して、特定のインターフェイス識別子に対するサポートを照会できます。これは、スマートコントラクト間の相互運用性を確認する際に有用なツールです。

この規格では、ERC4804のresolveMode関数の導入により、ERC165を使わないでもインターフェースのサポートをチェックできます。 ERC4804のコンテキストでresolveMode関数を呼び出すことにより、コントラクトがERC5219リゾルブモードをサポートしているかどうかを確認できます。これは、resolveMode関数が特定のモード（例えば"5219"、"auto"、"manual"）を返すことで、コントラクトがどのようなリゾルブモードをサポートしているかを明示するためです。

このアプローチにより、ERC165のsupportsInterface関数を使ってサポートされているインターフェイスを確認する代わりに、直接resolveModeを呼び出して対象のコントラクトが特定の解決モードをサポートしているかどうかを確認できます。これにより、ERC4804とERC5219のコンテキストでは、ERC165に依存する必要がなくなり、より直接的かつ効率的な方法でインターフェイスの相互運用性を確認できるようになります。

ERC165については以下の記事を参考にしてください。

[ERC165] コントラクトが特定のインターフェースをサポートしているか確認する仕組みを理解しよう！

実装

abstract contract ERC5219Resolver is IDecentralizedApp {
    function resolveMode() public pure returns (bytes32 mode) {
      return "5219";
    }
}

セキュリティ

ERC4804およびERC5219のセキュリティに関する考慮事項が適用されます。

引用

Gavin John (@Pandapip1), Qi Zhou (@qizhou), "ERC-6944: ERC-5219 Resolve Mode [DRAFT]," Ethereum Improvement Proposals, no. 6944, April 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6944.