イーサリアム財団のクリア・サイニング標準、イーサリアムでのブラインド・サイニングのリスク終焉を目指す

2026年5月12日

ブロックチェーンセキュリティにおいて、最も脆弱な箇所は、しばしば暗号技術そのものではなく、「承認」プロセスです。長年、多くのイーサリアムユーザーは、読めないカルデータ、一般的な警告、または不明瞭なメッセージプロンプトとして表示されるトランザクションの確認を求められてきました。これは一般的に「ブラインド・サイニング」として知られています。つまり、署名画面で意味のある検証ができないものに許可を与えることです。

このシステム的なUXセキュリティのギャップに対処するため、イーサリアムエコシステムは「クリア・サイニング」を中心に結集しています。これは「見て確認したものが署名するもの（What You See Is What You Sign、WYSIWYS）」をデフォルトにするためのオープンなアプローチです。この取り組みは、イーサリアム財団の「Trillion Dollar Security（1TS）」という計画の下で進められており、ブラインド・サイニングとトランザクションの不確実性を、イーサリアムの次の成長フェーズにおける重要な採用の障害として明確に指摘しています。1TSの詳細については、イーサリアム財団のイニシアチブに関するブログ記事や、公式の「Trillion Dollar Security」ハブでの広範なセキュリティ作業の流れをご覧ください：Trillion Dollar Securityイニシアチブ発表およびセキュリティ課題の概要。

なぜ「ブラインド・サイニング」が2025-2026年に最重要リスクとなったのか

イーサリアムのトランザクションは、もはや単なる「ETHを送る」だけではありません。今日の署名リクエストには、日常的に以下のようなものが含まれています：

複雑なパラメータ（無制限の承認額を含む）を伴うDeFiの承認
マルチシグ操作とコントラクトベースのアカウントアクション
署名時に結果が明白でない可能性のあるクロスチェーンおよびL2トランザクション
強力な権限をエンコードできるEIP-712型付けデータメッセージ

攻撃者もそれに応じて適応しています。多くの影響力の大きいインシデントには、共通するパターンがあります。ユーザー（またはオペレーター）がWeb UI上では無害に見えるものに承認を与えたものの、実際に署名されているペイロードは別のことを許可している、というものです。

広く議論されている例として、Bybitのインシデントがあります。このインシデントの分析では、署名体験が実際に許可されている内容を確実に伝達しない場合、署名者がどのように誤解される可能性があるかが強調されています。これらのUIと署名の不一致が破滅的な結果につながる可能性についての技術的な解説は、NCC Groupの技術分析を参照してください。

ここから得られる教訓は単純です：読み取れないウォレットのプロンプトは人間による監査が不可能であり、それゆえに暗号技術を破るよりもソーシャルエンジニアリングの方がはるかに安価になるのです。

クリア・サイニング：人間による検証のために構築された表示レイヤー

クリア・サイニングは、イーサリアムのトランザクションセマンティクスを変更しません。代わりに、標準化された検証可能な解釈レイヤーを追加することで、ウォレットは以下を表示できるようになります：

構造化されたアクションラベル（例：「Swap」、「Stake」、「Revoke allowance」）
正しい小数点以下の桁数とトークンメタデータを持つ、人間が読める金額
明確な相手方/受取人情報
ユーザーがプロトコルと意図を認識するのに役立つコンテキスト

クリア・サイニングの取り組みは、Clear Signing: See what you sign で公開されており、問題とアプローチの実用的な概要はFrom raw calldata to readable intent で確認できます。

中核となるビルディングブロック：ERC-7730ディスクリプタ

標準化の推進の中心にはERC-7730があります。これは、プロトコル（およびその他の貢献者）が、特定のコントラクトインタラクションまたはメッセージタイプを署名者に対してどのように表示するかを定義できる構造化されたフォーマットです。

平易な言葉で言えば、ERC-7730は生のバイトデータを、一貫性のあるトランザクション「説明テンプレート」に変換します。 ウォレットは、署名時にそのテンプレートを適用して、ユーザーが実際に理解できる確認画面を表示することができます。

仕様はこちらで確認できます：ERC-7730: Structured Data Clear Signing Format。特に、ERC-7730は、型付けデータ署名フロー（EIP-712 を参照）や、ERC-7730仕様で参照されているアカウント抽象化ユーザーオペレーション（EIP-4337 を参照）を含む、最新のイーサリアムパターン全体で機能するように設計されています。

オープンな提出、独立したレビュー、ウォレットローカルな信頼

グローバルなディスクリプタシステムは、明白な疑問を生じさせます。「誤解を招くメタデータを提出したらどうなるか？」

クリア・サイニングは、公開と信頼を分離することで、これに対処します：

ディスクリプタはオープンに作成・提出できます（これにより、少数のホワイトリストを超えてカバレッジを拡大できます）。
独立したレビューシグナルは、アテステーションを介して追加できます。
ウォレットは依然として主権を維持します：各ウォレットは、どのソースとレビューシグナルを信頼するか、メタデータが存在しない、または信頼できない場合にどのように動作するかを選択します。

この設計は、プロジェクトのガバナンスモデルで強調されています：Clear Signing governance principles。

実装面では、エコシステムは、メタデータが欠落していたり信頼できない場合にウォレットがより良い信頼決定を下せるように、整合性/検証メタデータをディスクリプタに添付する方法も標準化しています。その一例が、ERC-7730ディスクリプタに関する整合性検証の議論です：ERC-8176 integrity verification discussion。

なぜ「トランザクションとは別のメタデータ」が重要なのか

微妙でありながら重要なアーキテクチャ上の選択は、クリア・サイニングのメタデータ（ディスクリプタ、アテステーション、レジストリエントリ）がトランザクション自体とは分離されていることです。

この分離には2つの大きな利点があります：

後方互換性: 既存のコントラクトやdAppは、再デプロイすることなくクリア・サイニングのサポートを得られます。
将来の耐性: イーサリアムのUX（アカウント抽象化、バッチコール、新しい署名タイプなど）が進化しても、表示レイヤーはトランザクションの有効性を損なうことなく進化できます。

この「検証可能な表示レイヤーを追加する」という考え方は、クリア・サイニングの概要で説明されているアプローチの中核です：Clear Signing architecture overview。

一般ユーザーにとって何が変わるか

クリア・サイニングは魔法の盾ではありませんが、承認が発生するまさにその瞬間の曖昧さを減らすことで、多くの一般的な攻撃のコストを大幅に引き上げます。

採用が進むにつれて、ユーザーはより健全なデフォルトのワークフローを期待できるようになるでしょう：

トランザクションが適切に記述され、独立してレビューされている場合、ウォレットは明確で構造化されたインテント画面を表示できます。
メタデータが存在しない、または信頼されていない場合、ウォレットは明示的な警告とより安全なフォールバックを提供します（読めないプロンプトを無視するようにユーザーを静かに訓練するのではなく）。

それまでの間、ユーザー側のベストプラクティスは依然として重要です：

読めない署名リクエスト、特に承認や署名リクエストは高リスクとして扱ってください。
署名デバイスが意味のある詳細（金額、受取人、アクション）を表示するワークフローを優先してください。
必要なくなったトークン承認は、定期的にレビューし、取り消してください。

ビルダー（dApp、プロトコル、ウォレットチーム）が次にすべきこと

イーサリアム上に構築している場合、クリア・サイニングはセキュリティのベースラインの一部となりつつあります。これは、検証済みコントラクト、監査、安全な承認設計が時間とともに期待されるようになったのと同じようにです。

実用的なステップ：

プロトコル/dApp: コアコントラクトと高頻度トランザクションフローのためにERC-7730ディスクリプタを公開し、コントラクトが進化するにつれて（特にプロキシアップグレード）、それらを更新し続けてください。
セキュリティチーム: ディスクリプタをセキュリティアーチファクトとして扱ってください。それらは損失を防ぐことができますが、不正確なディスクリプタはユーザーを誤解させる可能性もあります。
ウォレットチーム: ERC-7730の消費と、レジストリおよびアテステーションに関する明確な信頼ポリシーを実装してください。

クリア・サイニングのサイトには、具体的な提出および実装パスがここにあります：Implement ERC-7730 (Build guide)。