# [ERC4430] コントラクトの機能実行前に実行内容を視覚化する仕組みを理解しよう！ > ERC4430では、コントラクト内に仮想関数を定義することで、実行可能なバイトコードと同時に人間が読める説明文も生成できる仕組みを提案しています。 - URL: https://cardene.dev/articles/d1fb7e1c79fa82e4358a - 公開日: 2025-05-02 - 更新日: 2025-05-02 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 『DApps開発入門』という本や色々記事を書いているかるでねです。 https://amzn.asia/d/gxvJ0Pw 今回は、実行するコントラクトの機能のバイトコードと実行内容を生成して、よりセキュアに機能を実行する仕組みを提案している**ERC4430**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-4430 他にも様々なEIPについてまとめています。 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4 ## 概要 **ERC4430**では、コントラクト内に仮想関数を定義することで、実行可能なバイトコードと同時に人間が読める説明文も生成できる仕組みを提案しています。 これにより、ユーザーはUI上で内容を理解しながら同意でき、同意後には実際のバイトコードが実行されます。 つまり、トランザクションの実行前に「**何が実行されるのか**」を人間にも分かる形で提示して、内容に同意した上で処理を進められるようにする仕組みです。 ## 動機 Ethereumのウォレット（MetaMask、Clef、ハードウェアウォレットなど）では、ユーザーがトランザクションに同意しない限り送信できません。 しかし、多くのEthereumトランザクションは非常に複雑で、ウォレット側ではその内容を十分に説明できません。 現在は、**ERC20**トークンの送信など、一部のよく知られた処理だけが特別に可視化されていますが、それ以外の多くの処理ではユーザーは意味のわからないバイナリデータに署名させられています。 **ERC4430**では、開発者がコントラクト内で人間向けの説明を生成するための手段を用意することで、ユーザー体験の向上を目指します。 この仕組みは、悪意あるコントラクトを検出・防止するものではなく、ユーザーの利便性を重視した「**正直なコントラクト**」に向けたものです。 人間が読める説明は、コントラクトコードと同時に監査可能であり、コード監査者がその内容の正確性を検証することも可能です。 これにより、ユーザーが内容を理解し納得してから安全に操作できる環境を実現しようとしています。 ## 仕様 この提案で定義される関数は以下のシグネチャを持ちます。 ```js function eipXXXDescribe(bytes inputs, bytes32 reserved) view returns (string description, bytes execcode) ``` この関数は、以下の2つの出力を同時に生成します。 - `description` - 人間が読める説明（文字列）。 - `execcode` - 実際に実行されるEVMバイトコード（バイナリ）。 ユーザーに対して処理内容を説明しつつ、EVMにはその処理を正確に実行させるためのコードを提供しています。 例えば、ウォレットやDAppがこの関数を呼び出すことで、画面に説明を表示しながらトランザクションに必要な実行コードも取得できるようになります。 ### 実行の制約 - この関数は`view`で実行される必要があります。 ログ出力（`logX`）、ストレージへの書き込み（`sstore`）、その他副作用のある処理は使用できません。 - 実行中のコンテキストは、トランザクションと一致させる必要があります。 具体的には以下の値です。 - `ADDRESS`（実行先コントラクトアドレス） - `CALLER`（送信元アドレス） - `VALUE`（送金額） - `GASPRICE`（ガス価格） これにより、関数内でこれらの情報に依存した正確な説明を生成できます。 - `execcode` の実行においては、ブロックに関連する情報も可能な限り実際のブロックと一致させることが求められる。 - `BLOCKHASH`、`NUMBER`、`TIMESTAMP`、`DIFFICULTY` は「最新のブロック」と一致させることが推奨されます。 - `COINBASE`（マイナーの報酬受取アドレス）はゼロアドレスに設定されるべきです。 ### エラー処理 `eipXXXDescribe` が `revert` を起こした場合、署名プロセスは中断されてトランザクションは実行されません。 ## 補足 ### メタ記述の考え方 従来、この問題に対して多くの解決策が提案されてきましたが、それらの多くはエンコードされたトランザクションデータやメッセージデータを直接解析する方式でした。 しかし、この方法では人間が理解できる説明を生成するために必要な情報が、最終的なバイナリデータの中には含まれていないことが多く限界があります。 **ERC4430**では、データの直接的な記述ではなく間接的な記述を使うアプローチを取っています。 例えば、ENSの `commit(bytes32)` 関数は、コミットメントハッシュをオンチェーンに保存します。 このハッシュには「名前（`NAME`）」や「所有者アドレス（`ADDRESS`）」、「秘密値（`SECRET`）」がブラインドされた状態で含まれており、実際のトランザクションデータからはこれらの情報を読み取ることはできません。 このようなケースでは、「`NAME` と `ADDRESS` に対して `SECRET` を使ってコミットする*といった意味のある人間向けの説明を生成するには、元の値を保持した状態で説明を構築する必要があります。 これが**ERC4430**の目指す方向性です。 なお、このような「**ブラインドされたデータ**」は、Layer 2ではプライバシーだけでなくデータ圧縮の目的でも頻繁に利用されるため、今後さらに一般的になると考えられます。 ### コントラクトアドレスとの紐づけ **ERC4430**では、署名済みデータが他のコントラクトで使い回されることを防ぐために、コントラクトアドレス（`to` フィールド）をトランザクションに暗黙的に含める設計になっています。 これにより、トランザクションの実行先が明確になり、安全性が向上します。 ### 他のアプローチとの比較 - **NatSpec** NatSpecはトランザクションデータを直接記述するための複雑な記法を持ちます。 大規模なランタイムやメモリ、セキュリティのためのサンドボックスが必要で、ハードウェアウォレットなどの制約された環境には不向きです。 また、ブラインドされたデータには対応できません。 - **カスタム言語** Ethereumトランザクションは非常に複雑であるため、それを扱える汎用的な言語を一から作るのは非現実的です。 EVMという既存の仕組みがすでに存在しており、それを活用する方が合理的です。 - **フォーマット文字列（例：Trustless Signing UI Protocol）** フォーマット文字列は「**正規言語**」という制限のある範囲でしかデータを表現できず、Ethereumの複雑なトランザクションを表すには不十分でした。 これは初期の試みにおいて特に問題となりました。 ### EIP712との関係 **ERC4430**は、署名付き構造データを扱う**EIP712**に非常に近い考え方を持っています。 どちらも、人間に理解しやすい形式と機械に処理可能な形式の両立を目指しており、ユーザーが安心して署名操作を行えるようにするための取り組みです。 :::message **EIP712**については以下の記事を参考にしてください。 ::: [\[EIP712\] 型付き構造化データのハッシュ化と署名の仕組みを理解しよう！](/articles/f54bc85cb66de5a54257) ## セキュリティ ### HTMLの埋め込み 表示される文字列にHTMLタグ（特に`