イーサリアムの開発者らは、オンチェーンコードがトランザクションで実際に何が変更されたかを検証できるようにし、結果がユーザーが事前に設定したルールに違反した場合にはトランザクション全体を差し戻せるようにする提案を提出した。ネイティブ・トランザクション・アサーションとして知られるこの概念は、2026年10月5日に公開されたイーサリアム財団のブログ投稿で紹介された。

この提案は、暗号資産セキュリティにおける最も古く、根強い弱点の一つであるブラインド署名を対象としている。

ブラインド署名の問題

ブラインド署名とは、読まずに利用規約に同意することの暗号資産版である。ウォレットがリクエストを表示しても、詳細が読めなかったり不明瞭だったりする中で、ユーザーはそのまま承認してしまう。多くの場合は問題がないが、問題が起きるとその代償は高くつく傾向がある。この弱点はイーサリアムのトランザクションの構造に根ざしている。署名されるペイロードは平文ではなく機械形式のデータであり、ウォレットの画面に表示される内容はそのデータをインターフェースが解釈したものにすぎない。

イーサリアム財団は、この新しい取り組みを、Trillion Dollar Securityイニシアティブで指摘されたリスクへの直接的な対応として位置づけている。同プログラムには、ユーザーが承認する前にトランザクションのリクエストを読み取りやすくすることに焦点を当てたClear Signingなどの対策がすでに含まれている。

ネイティブ・トランザクション・アサーションは、プロセスの異なる段階で機能する。Clear Signingはトランザクションが実行される前にユーザーが内容を理解できるよう支援する。アサーションは、実行後に結果が期待どおりであったかを検証する。

EIP-7906の中身

提案の技術的中核はEIP-7906であり、イーサリアム仮想マシン(EVM)にTXTRACE、TXDIFF、EVENTDATACOPYという3つの新しいオペコードを導入する。オペコードはEVMが理解する低レベルの命令であり、新しいオペコードの追加はスマートコントラクトコードが確認できる範囲と実行できる範囲を拡大する。

今回の場合、新しい命令により、オンチェーンコードがトランザクションが生み出した実際のステート変更を検査できるようになる。これにより、検証の対象は「トランザクションが実行すると主張すること」から「実際に実行したことが証明できること」へと移る。

EIP-8141との連携

EIP-7906は単独では成り立たない。フレームトランザクションフォーマットとして知られるEIP-8141で示されたフレームワークに依存している。トランザクションフォーマットは基盤となる仕組みであり、すべてのノード、ウォレット、開発者ツールがこれを処理できる必要があるため、この層での変更はスタック全体に影響を及ぼす。

フレームトランザクションは、単一のトランザクションを個別のセグメント(フレーム)に分割する。EIP-7906はこの構造に新しい要素としてPOST_TXフレームを追加する。

POST_TXフレームは、実行中に静的コール(static call)として動作する。静的コールは読み取り専用の操作であり、ステートを検査できるが変更はできない。このフレームで定義された条件が満たされない場合、トランザクションの影響は差し戻される可能性がある。

現状とスケジュール

ここで述べられている内容はまだ稼働していない。EIP-7906はドラフト段階にとどまっている。イーサリアムの開発プロセスでは、ドラフトはレビューを通過し、アップグレードを調整する開発者らの承認を得て初めて変更がネットワークに到達する。目標は、2027年に予定されるHegotáアップグレードに含めることである。

予備的なデモはすでに開発ネットワーク上で実施されており、この仕組みがホワイトペーパーの域を超えて機能することを示している。EIP-7906はEIP-8141にも依存しているため、その運命はフレームトランザクションフォーマットが採用されるかどうかにも左右される。

コードを超えた意義

ネイティブ・アサーションは、署名リスクの負担の一部をベース層に移すことになる。プロトコルが結果の検証を直接強制できれば、ユーザーは個々のウォレットの表示ロジックが完璧であることに依存しなくなる。

機関や企業にとって、その魅力は明確である。多額の資金を動かす組織は、ベストエフォートではなく保証を求める傾向がある。結果が定義されたパラメータの範囲外となったトランザクションを自動的に差し戻せる仕組みは、こうしたプレイヤーが他の領域で既に利用しているリスク管理手法と自然に適合する。

未解決の課題も残る。開発者らは、一般のユーザーがトランザクションが満たすべきルールをどのように定義するのかという問題にも取り組む必要がある。専門的な設定を要するセーフティネットは、結局のところ主に専門家しか保護できない可能性があるためである。EIP-7906の上に構築されるユーザビリティ層は、オペコードそのものと同じくらい重要になり得る。
考慮すべきトレードオフもある。新しいオペコードが追加されるたびに、複数のイーサリアムクライアント全体で実装・監査が必要となる範囲が拡大する。新たなエッジケースを持ち込むセキュリティ改善は、そのコストに見合う価値を示さなければならない。

注目すべきポイントは、EIP-7906がドラフトを脱するかどうか、EIP-8141がHegotáに含まれるかどうか、そして初期デモに続いてさらなるdevnetテストが行われるかどうかである。