# [ERC5568] ウォレットに何らかのアクションが必要であることを通知する仕組みを理解しよう！ > このERC（Ethereum Request for Comment）は、ブロックチェーン上での取引や操作に関する情報をウォレットに伝えるためのルールの一部です。 - URL: https://cardene.dev/articles/0645beb4327317d388b7 - 公開日: 2023-10-04 - 更新日: 2023-10-04 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 初めまして。 **CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！ スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。 https://cryptogames.co.jp/ 代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。 https://cryptospells.jp/ 今回は、コントラクト内の関数を使用して、ウォレットに何らかのアクションが必要であることを通知する規格を提案している**ERC5568**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-5568 :::message alert **5568**は現在（2023年10月3日）では「**Review**」段階です。 ::: ## 概要 このERC（Ethereum Request for Comment）は、ブロックチェーン上での取引や操作に関する情報をウォレットに伝えるためのルールの一部です。 :::message ウォレットのユーザーに対して何らかの行動が必要な場合、それを伝えるための最小限の情報形式を提供します。 この情報形式は、コンピューターが理解しやすいバイナリ形式で表現されます。 ::: このERCの特徴は、将来のバージョンや拡張に対応できることです。 つまり、新しい機能やデータを追加するために、この形式を変更する必要がありません。 また、最大で64 kBのデータを受け入れることができるため、多くの情報を含めることができます。 使用例として、トークンを取引所で承認する場合を考えてみましょう。 取引所はこのERCを使用して、ウォレットに対して「**このトークンを承認してください**」という情報を送信します。 ウォレットはこの情報を受け取り、ユーザーに対してトークンの承認を要求することができます。 同様に、HTTPリクエストを送信するか、一定期間が経過した後にユーザーに新しい鍵を設定するよう要求する際にも、このERCを使用できます。 :::message このERCは、異なるアプリケーションやサービス間での情報のやり取りを効率的に行うための共通のルールを提供し、ウォレットのユーザーに対して必要なアクションを通知するのに役立つものです。 将来の拡張性と柔軟性を持つため、ブロックチェーンエコシステム内で広く活用されることを想定しています。 ::: ## 動機 通常、スマートコントラクトはウォレットに対して、特定のアクションを実行するように通知する必要があります。 これらのアクションには、トランザクションに署名することや、特定のURLにHTTPリクエストを送信することなどが含まれます。 従来、この通知はウォレットのフロントエンドコードに直接組み込む必要がありました。 しかし、このERC（Ethereum Request for Comment）を使用することで、スマートコントラクト自体が必要なアクションを要求できるようになります。 :::message 具体的な例として、取引所や市場がスマートコントラクトに対して「**このトークンの使用を承認してください**」と伝えたい場合を考えてみましょう。 従来の方法では、取引所や市場のフロントエンドコードにこのロジックを組み込む必要がありました。 しかし、このERCを使用すると、スマートコントラクト自体がウォレットにアクションを要求できます。これにより、フロントエンドコードがシンプルになり、コードの効率性が向上します。 ::: :::message 要するに、このERCは、スマートコントラクトがウォレットに対して必要なアクションを要求できる仕組みを提供します。 これにより、スマートコントラクトとウォレットの連携がスムーズに行え、ユーザーエクスペリエンスが向上します。 ウォレットは、スマートコントラクトからの要求に応じて必要なアクションを実行し、ユーザーにとって使いやすい環境を提供します。 ::: ## 仕様 ### アクション検出 ```javascript interface IERC5568 { function walletSignal24(bytes32 selector, bytes function_data) view returns (uint24 instruction_id, bytes instruction_data); } ``` ERC（Ethereum Request for Comment）では、通常、指示（instruction）の番号はERCの番号と同じであるべきです。 特別な理由がない限り、この原則に従います。 ERCは、指示番号をゼロまたは一つだけ定義しなければなりません。 複数の指示番号を設定することは許されません。 指示番号（`instruction_id`）が定義されると、その指示番号に関連する指示データ（`instruction_data`）の形式も、同じERC内で明確に定義されなければなりません。 アクションが必要な場合、ERCは指示番号と指示データを返す必要があります。 これにより、具体的なアクションや処理内容が他のコントラクトやウォレットに伝えられます。 アクションが不要な場合、指示番号をゼロに設定し、指示データには任意の値を設定します。 これにより、何もアクションを実行しないことを示します。 :::message ERCは特定の指示に関するルールとデータ形式を提供し、必要に応じて他のコントラクトやウォレットに対してどのようなアクションが必要かを明示的に伝えるための仕組みです。 指示番号はERCの識別子であり、その具体的な内容は各ERCによって定義されます。 ::: ### Custom Revert Reason この規格に準拠したコントラクトは、アクションが実行されなかったことを示すために以下のエラーで`revert`する必要があります。 ```javascript error WalletSignal24(uint24 instruction_id, bytes instruction_data) ``` ERC（Ethereum Request for Comment）において、通常は指示（`instruction`）の番号はそのERCの番号と同じです。 特別な理由がない限り、このルールに従います。 ERCは、指示番号をゼロまたは一つだけ定義しなければなりません。 複数の指示番号を設定することはできません。 指示番号（`instruction_id`）が定義される場合、その指示番号に関連する指示データ（`instruction_data`）の形式も、同じERC内で明確に定義されなければなりません。 :::message ERCは特定の指示に関する規則を提供し、通常はそのERCの番号と同じ指示番号を使用します。 ただし、特別な事情がある場合には例外を認めることができます。 また、各ERCは指示番号をゼロまたは一つだけ定義し、その指示番号に関連するデータ構造も定義しなければなりません。 これにより、スマートコントラクトやウォレットが必要なアクションを正確に理解しやすくなり、インターフェースの一貫性を保つことができます。 ::: ### Revertの対応 トランザクションをマイニングプール（`mempool`）に送信する前に、`walletSignal24`関数をローカルでシミュレーションしなければなりません。 このシミュレーションでは、状態を変更する一般的な関数と同じように扱われます。 結果として得られる`instruction_id`（指示番号）がゼロでない場合、何かアクションを取る必要があります。 `instruction_id`と`instruction_data`は、`walletSignal24`のシミュレーションから取得しなければなりません。 この指示は、関連するERCのルールに従って評価されます。 ウォレットがその指示をサポートしていない場合、ユーザーにエラーメッセージを表示し、その後、トランザクションを再評価しなければなりません。 ただし、指示がトランザクションの再評価を禁止している場合は除きます。 :::message - **評価（Evaluation）** 指示の評価とは、その指示に基づいて何らかのアクションを実行するプロセスを指します。 具体的には、指示の内容を理解し、それに従ってトランザクションを生成または変更することです。 指示が正当であるかどうかを確認し、適切なアクションをトリガーします。 - **再評価（Re-evaluation）** 指示の再評価は、最初の評価後に何らかの問題が発生した場合や、指示が要求する特定の条件が変化した場合に、トランザクションを再度検討し、必要な修正や追加のアクションを実行するプロセスです。 再評価が行われると、新しい情報や状況に合わせてトランザクションが更新または調整されることがあります。 評価は最初に指示を処理し、トランザクションを生成するプロセスを指し、再評価は後で問題が発生した場合や条件が変化した場合に、トランザクションを再検討して修正するプロセスを指します。 指示の正確さと適切なアクションの実行が重要です。 ::: もし指示が無効であるか、`instruction_id`と`instruction_data`が解釈できない場合、ユーザーにエラーメッセージを表示し、トランザクションを再評価してはなりません。 :::message トランザクションを送信する前に、`walletSignal24`関数をローカルでシミュレーションし、その結果から`instruction_id`と`instruction_data`を取得します。 取得した指示は関連するERCのルールに従って評価され、ウォレットがその指示をサポートしていない場合や指示が無効な場合にはエラーメッセージを表示し、トランザクションを再評価します。 指示がトランザクションの再評価を禁止している場合を除き、再評価が行われます。 ::: ## 補足 このERCは、トランザクションのデプロイ時にかかるガスコストを最小限に抑え、シンプルな設計を重視しています。 将来的には、開発者が利用しやすくするためのライブラリが開発される予定です。 このERCでは、**ERC165**を使用していません。 なぜなら、このインターフェースは非常に単純であり、関数を呼び出すだけで簡単に識別できるからです。 ## 後方互換性 ### Human-Readable Revert Messages **Human-Readable Revert Messages**（人間が理解しやすいリバートメッセージ）は、`revert`（処理の中断）が発生した時に、その理由を分かりやすく表示するものです。 #### ERC3668 このERCと連携して使用できますが、異なる方法を用いて`revert`メッセージの可読性向上を行います。 ## セキュリティ考慮事項 ### Revert Reason Collisions **Revert Reason Collisions**（リバート理由の衝突）は、カスタムエラーの識別情報が通常のエラー情報と一致する可能性が非常に低いという考え方です。 もし一致した場合でも、通常は問題が発生しません。 ただし、その一致が実際に発生する可能性は非常に低いです。 問題が発生する可能性は、データが偶然にも有効な指示と一致する場合に限られます。 ## 引用 Gavin John (@Pandapip1), "ERC-5568: Well-Known Format for Required Actions [DRAFT]," Ethereum Improvement Proposals, no. 5568, August 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5568. ## 最後に 今回は「コントラクト内の関数を使用して、ウォレットに何らかのアクションが必要であることを通知する規格を提案している**ERC5568**」についてまとめてきました！ いかがだったでしょうか？ 質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！ [Twitter @cardene777](https://twitter.com/cardene777) 他の媒体でも情報発信しているのでぜひ他も見ていってください！ https://chaldene.net/ https://zenn.dev/heku https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58