はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、実行するコントラクトの機能のバイトコードと実行内容を生成して、よりセキュアに機能を実行する仕組みを提案しているERC4430についてまとめていきます！

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

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

概要

ERC4430では、コントラクト内に仮想関数を定義することで、実行可能なバイトコードと同時に人間が読める説明文も生成できる仕組みを提案しています。
これにより、ユーザーはUI上で内容を理解しながら同意でき、同意後には実際のバイトコードが実行されます。

つまり、トランザクションの実行前に「何が実行されるのか」を人間にも分かる形で提示して、内容に同意した上で処理を進められるようにする仕組みです。

動機

Ethereumのウォレット（MetaMask、Clef、ハードウェアウォレットなど）では、ユーザーがトランザクションに同意しない限り送信できません。
しかし、多くのEthereumトランザクションは非常に複雑で、ウォレット側ではその内容を十分に説明できません。

現在は、ERC20トークンの送信など、一部のよく知られた処理だけが特別に可視化されていますが、それ以外の多くの処理ではユーザーは意味のわからないバイナリデータに署名させられています。

ERC4430では、開発者がコントラクト内で人間向けの説明を生成するための手段を用意することで、ユーザー体験の向上を目指します。
この仕組みは、悪意あるコントラクトを検出・防止するものではなく、ユーザーの利便性を重視した「正直なコントラクト」に向けたものです。

人間が読める説明は、コントラクトコードと同時に監査可能であり、コード監査者がその内容の正確性を検証することも可能です。
これにより、ユーザーが内容を理解し納得してから安全に操作できる環境を実現しようとしています。

仕様

この提案で定義される関数は以下のシグネチャを持ちます。

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に非常に近い考え方を持っています。
どちらも、人間に理解しやすい形式と機械に処理可能な形式の両立を目指しており、ユーザーが安心して署名操作を行えるようにするための取り組みです。

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

セキュリティ

HTMLの埋め込み

表示される文字列にHTMLタグ（特に<script>などのスクリプトタグ）が含まれている場合、Webベースのウォレットがそのコードを実行してしまう可能性があります。
悪意あるスクリプトにより、例えば秘密鍵が外部サーバーに送信される危険もあります。

見た目を偽る文字列

以下のような手法でユーザーに誤解を与える表示が可能です。

ricmoo.eth のような名前の前に <span style="display:none">not-</span> を挿入し、実際には not-ricmoo.eth であるにもかかわらず、画面上は ricmoo.eth に見せかける。
 ricmoo.eth のように見えにくい空白を使い、別の名前に見せかける。

特殊文字や制御文字

説明文に含まれる次のような文字は、表示の崩れや予期せぬ動作を引き起こす可能性があります。

ダブルクオート（"）
改行（\n）、タブ（\t）、フォームフィード（\f）
バックスラッシュ（\）
通常でない空白文字（非標準ホワイトスペース）

UTF-8の脆弱性

UTF-8の扱い方にも注意が必要です。
過去にはUTF-8のバグを悪用して、任意コード実行やレンダラーのクラッシュが発生するケースがありました。
一般的でないコードポイント（Unicodeの領域）を使った場合は、UTF-8の置換文字などで無害化する対応が推奨されます。

ホモグリフ攻撃

α（ギリシャ文字）や а（キリル文字）など、形が似ているが別の文字コードを使うことで、正規の文字列に見せかける攻撃（ホモグリフ攻撃）も存在します。

右から左の記号（RTLマーク）

Unicodeにはテキストの表示方向を変える制御文字（例：右から左へ表示させるマーク）があります。
これにより、表示される文字列の順番が入れ替わるなどの視覚的なトリックが可能になります。

その他の攻撃

レンダリングエンジンや表示環境によっては、さらに多くのセキュリティリスクが存在します。
環境に応じた防御策の検討が必要です。

引用

Richard Moore (@ricmoo), Nick Johnson (@arachnid), "ERC-4430: Described Transactions [DRAFT]," Ethereum Improvement Proposals, no. 4430, November 2021. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-4430.

最後に

今回は「実行するコントラクトの機能のバイトコードと実行内容を生成して、よりセキュアに機能を実行する仕組みを提案しているERC4430」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！