Ethereumのネイティブ取引アサーションとは？EIP-7906の仕組みと限界

Ethereumのネイティブ取引アサーションは、署名した「操作」ではなく、取引後に実際に生じた「最終結果」を条件で縛るための提案です。最低受取額を下回る、想定外のトークン承認が増える、許可していないコードが変わるといった条件違反を取引の末尾で検知し、取引本体を原子的に巻き戻す構想です。

中心となるEIP-7906は、取引が変更した残高・ストレージ・コード・イベントをEVMから読み出す命令を提案しています。ただし、2026年10月9日時点ではEIP-7906も、実行の土台となるEIP-8141もDraftです。現在のEthereumメインネットや一般的なウォレットで、利用者がすぐ使える完成済み機能ではありません。

署名画面では安全に見えた交換が、実行までの状態変化によって想定外の結果になったら、どう止めるのか。この記事では一つの交換取引を通し例に、検査の順序、既存対策との違い、導入後にも残る限界を整理します。

ネイティブ取引アサーションは「最終結果」を制約する仕組み

アサーション（assertion）は、ここでは「成立していなければ取引を成功させない条件」を意味します。スマートコントラクト内の個別なrequire条件に似ていますが、ネイティブ取引アサーションが目指す範囲はより横断的です。呼び出した一つのコントラクトの返り値だけでなく、その取引によって最終的に変わった複数アカウントの残高、ストレージ、配備コード、イベントを調べます。

たとえば、交換取引に「少なくとも指定量のトークンを受け取る」「支出は上限以内」「新しい無制限承認を作らない」という条件を添えられれば、途中で複数のコントラクトを経由しても、最後の状態が条件を満たしたかで成否を判断できます。重要なのは、アプリが説明した予定ではなく、EVMが実行した後の差分を基準にする点です。

条件違反なら取引本体を原子的に巻き戻す

提案では、取引本体の実行後にアサーションを評価し、条件に反していれば本体の状態変更をまとめて戻します。「原子的」とは、一連の変更の一部だけを残さず、全体を成功または失敗として扱うことです。受取額だけ不足しているのに支出だけ確定する、といった中途半端な結果を避ける考え方です。

巻き戻しは、危険な取引をチェーンへ送る前に消してくれるという意味ではありません。取引は実際に検証・実行され、その後に条件が評価されます。アサーションのプログラム自体が間違っていたり、必要な条件を書き忘れていたりすれば、利用者が望まない結果でも条件を通過する可能性があります。

失敗しても取引は有効でガスは支払われる

アサーションが失敗すると取引本体の状態変更は戻されますが、取引そのものが存在しなかったことになるわけではありません。計算資源を使って本体と検査を実行したため、ガス代は支払われます。これはスマートコントラクトの実行がrevertした場合にもガス消費が残るのと同じ方向の考え方です。

したがって、条件を厳しくすれば無料で安全になるわけではありません。条件が現実の状態と合わず何度も失敗すれば、資産移動は防げてもガス負担は発生します。ウォレットには、条件の意味、想定ガス、失敗理由を利用者へ分かる形で示す設計が必要になります。

EIP-7906は状態差分をどう検査するのか

EIP-7906は、取引によって生じた変更をアサーション用コードが読むため、TXTRACE、TXDIFF、EVENTDATACOPYという三つの命令を提案しています。通常のコントラクトが任意の過去履歴を取得する仕組みではなく、現在の取引が作った差分を末尾で検査するインターフェースです。

交換取引の流れは「本体を実行→TXTRACEで変更先を列挙→TXDIFFで残高・保存データ・コードの差分を読み、EVENTDATACOPYでイベントを読む→EIP-8141のPOST_TXで条件を判定→違反なら本体を巻き戻す」です。たとえば受取額、支出額、承認、コード変更を同じ末尾検査で照合します。成功なら結果を確定し、失敗なら資産移動などの状態変更を残しません。

TXTRACEで変更されたアカウントを列挙する

ここでいうアカウントには、利用者の口座だけでなく、交換ルーターやプールなど取引中に関係したコントラクトも含まれます。画面上の直接の送信先だけに検査対象を限定しないことが、複数コントラクトをまたぐ操作では重要です。

TXTRACEは、取引中にどのアカウントへ変更が生じたかをたどる入口です。検査側は変更対象を列挙し、「想定していないアドレスに影響が及んでいないか」「許可リスト外のコントラクトが書き換わっていないか」を確認できます。

ここでの狙いは、dAppが自己申告した変更先だけを見るのではなく、EVMが記録した取引全体の差分を起点にすることです。複数の内部呼び出しを経由する取引では、表面上の送信先以外にも状態変更が広がり得るため、横断的な列挙が意味を持ちます。

TXDIFFで残高・ストレージ・コードの差分を読む

TXDIFFは、列挙したアカウントについて、残高、ストレージ、配備コードなどの変更内容を読むための命令です。これを使えば、利用者のETH残高減少が上限内か、特定の承認スロットが新しく書き換わっていないか、コード変更が発生していないかを条件化できます。

手数料の前払いを資産の送付と混同しないよう、提案はガス前払いを別に扱います。これにより、利用者が意図した支出と実行手数料を分けて検査できます。

EVENTDATACOPYでイベントデータを検査する

EVENTDATACOPYは、取引が発生させたイベントのデータを読み取るための命令です。イベントはアプリが取引結果を追跡する重要な手掛かりで、トークン移転やプロトコル固有の処理結果を条件へ含められます。提案では、コントラクトが出すログだけでなく、プロトコルが生成するログも差分の対象として扱います。

ただし、イベントはコントラクトが出す通知であり、それだけを見れば十分とは限りません。通知内容と実際の残高や保存データの差分を合わせて調べることが重要です。

途中経過ではなく開始前と検査時の純差分を扱う

状態差分は、実行中のすべての書き込みを時系列に再生する完全なトレースではありません。取引開始前と検査時点を比較した純差分です。同じストレージスロットへ何度も書き込み、最後に一つの値へ落ち着いた場合、複数回の途中操作ではなく最終的な一件の差分として扱われます。

この性質は、最終結果を条件化する目的には合っています。一方、「途中で一度でも危険な値が設定されたか」「どの内部呼び出しが最初に変更したか」を調査する用途とは異なります。また、仕様上列挙されない変化もあり得るため、差分を実行履歴の完全な監査記録と考えてはいけません。

EIP-8141のPOST_TXフレームがアサーションを実行する

EIP-7906だけでは、取引本体の後に安全に検査コードを動かす枠組みが足りません。そこで依存するのがEIP-8141のFrame Transactionです。EIP-8141は、一つの取引を複数のフレームへ分け、検証、実行、ガス支払いなどを構成できる新しい取引型を提案しています。

検証・実行・ガス支払いを複数フレームで構成する

従来の取引では、EOA（秘密鍵で直接操作する一般的なアカウント）による固定的な検証とガス支払いの形が強く結び付いています。Frame Transactionは、検証処理や実行処理などを明示的なフレームとして並べ、スマートアカウントに必要な柔軟性をプロトコル側へ取り込む構想です。

このうち取引本体の後へ置けるPOST_TXフレームが、最終状態を検査する場所になります。前段のフレームが成功しても、POST_TXでアサーションが失敗すれば、本体を含む状態変更を確定させません。検査を取引と同じ原子的な境界の中へ置くことが要点です。

POST_TXで状態を変えずに条件を判定する

POST_TXは読み取り専用のフレームとして想定されています。検査側が追加送金をしたり、ストレージを書き換えたりして結果を変えるのではなく、完成した差分を読んで合否を返します。これにより、検査コード自体が新しい副作用を生む範囲を抑えます。

ただし読み取り専用でも、複雑な全件走査には計算コストがかかります。どの差分を何件まで確認するか、失敗時の原因をどう表すか、ウォレットが検査コードをどう提示するかは、実用化に向けた重要な設計課題です。

条件は取引と一緒に署名される

アサーション条件は取引と結び付けて署名されるため、ネットワークへ送った後に第三者が条件だけを外したり、緩い条件へ差し替えたりすれば署名が成立しない設計を目指します。最低受取額を設定したのに、送信経路で条件が削除される事態を防ぐためです。

一方、署名前に悪意ある画面が取引と条件を同時に作れば、暗号学的には整合した危険な組み合わせになり得ます。「署名に含まれる」ことと「利用者の本当の意図を表す」ことは同じではありません。分かりやすい表示と独立したポリシーが欠かせません。

署名・Clear Signing・シミュレーションとの違い

Ethereumの署名は、秘密鍵を持つ人が特定の取引指示を承認したことを暗号学的に確かめるために重要です。しかし、「その指示を実行すれば最終的に何が起きるか」まで署名だけで保証するものではありません。実行結果は、取引がブロックへ入った時点の状態と、呼び出し先が実際に実行するコードに依存するからです。

署名が固定するのは宛先・値・calldataなどの指示

一般的なEthereum取引には、送信先、送るETHの値、呼び出す関数と引数を表すcalldata（コントラクトへ渡す入力データ）、ガス関連の指定、nonce（取引の通し番号）などが含まれます。署名後にこれらを書き換えれば署名検証に通りません。一方、calldataが「ある交換ルーターでトークンを交換する」という命令でも、受取量や経由先で起きる全変更が署名データへ列挙されているとは限りません。

型付き構造化データを扱うEIP-712も、署名対象を人やアプリが扱いやすくする重要な標準です。ただしEIP-712自身は、リプレイ防止、署名後のブロードキャスト、オンチェーンでの最終結果保証をすべて提供するものではありません。読みやすい署名と、実行結果を強制する仕組みは分けて考える必要があります。

取引順序と取り込み時点の状態が実行結果を変える

署名してからブロックへ取り込まれるまでに、他の取引が先に実行されることがあります。交換プールの残高、オラクル（外部の価格などをチェーンへ伝える仕組み）が参照する値、レンディング市場の利用状況などが変われば、同じ宛先とcalldataでも結果が変わり得ます。ブロック提案者が決める並びや、ネットワークへ届く時間も実行時の前提に影響します。

事前にシミュレーションして成功していても、そのシミュレーションは選択したブロック状態を起点にした予測です。本番で取り込まれる直前までその状態を予約する機能ではありません。予測時点と実行時点の間に前提が変われば、結果もずれる可能性があります。

アップグレード可能なプロキシは署名後にロジックが変わり得る

アップグレード可能なプロキシは、利用者が呼ぶアドレスや保存状態を保ちながら、処理を委譲する実装コントラクトを更新できる仕組みです。ERC-1967は実装先、ビーコン、管理者などを格納する標準スロットを定義しています。更新可能性は不具合修正に役立つ一方、署名時に確認したロジックと実行時のロジックが同じとは限らない、という確認点を生みます。

もちろん、すべてのプロキシが危険という意味ではありません。問題は、署名が呼び出し先アドレスを固定しても、そのアドレスの背後で動くコードの不変性までは自動的に固定しないことです。結果条件として「特定の制御ロジックが変わっていない」「許可したコード変更以外はない」を検査できれば、このずれを別の層で抑えられます。

役割は、署名が「指示を固定」、Clear Signingが「指示を理解」、シミュレーションが「結果を予測」、アサーションが「実際の結果を強制」です。代替関係ではなく、異なる時点の問題を扱います。

Clear Signingは署名要求を人が理解するための仕組み

Clear Signingは、意味の分からない16進数だけを見せる「ブラインド署名」を減らし、操作内容を人が読める形で確認しやすくする取り組みです。ERC-7730は、コントラクト呼び出しや型付きメッセージの表示方法をJSON形式で記述し、チェーンIDやコントラクトアドレスと表示定義を結び付けます。

これにより、「どの資産について、誰に、どの操作を許可しようとしているか」を理解しやすくなります。しかし、表示が正しくても、取り込み時の状態変化やプロキシ更新後のコードまで固定するわけではありません。Clear Signingは結果強制の代替ではなく、利用者が条件と要求を理解するための前段です。

シミュレーションは特定時点の状態に基づく予測

トランザクション・シミュレーションは、選択したブロック状態を基準に取引を仮想実行し、呼び出し経路、イベント、残高やストレージの変化、エラーなどを調べます。複雑なDeFi（分散型金融）操作で、予想外の承認や資産移動を送信前に見つけるうえで有用です。

ただし、シミュレーション結果は将来のブロックに対する約束ではありません。シミュレーション後にプール残高やコードが変わる可能性があるためです。アサーションは、予測した望ましい結果を「最低受取額」「変更を許す対象」のような機械判定可能な条件へ変え、本番実行の末尾で確かめる役割を担います。

アサーションは実際に生じた最終差分を検査する

ネイティブ取引アサーションは、実行前の説明でも予測でもなく、その取引が実際に作った最終差分を読みます。条件を満たさなければ、状態変更を確定させません。これにより、署名画面が意図を伝え、シミュレーションが候補結果を示し、アサーションが許容範囲を強制するという分担ができます。

それでも「正しい条件を誰が作るか」という問題は残ります。侵害されたdAppが取引要求と一緒に緩いアサーションを生成すれば、両方が整合して見える可能性があります。ウォレットの独立ポリシー、利用者が事前に設定した支出上限、信頼できる第三者が配布する標準条件など、要求元とは独立した判断材料が必要です。

取引アサーションで表現できる条件

アサーションは「安全」という曖昧な判定を自動で作りません。通し例の交換なら、最低受取額と最大支出額は残高差分、新規承認は承認情報を置くストレージ（コントラクトの保存領域）の差分、制御ロジックの変更はコードと関連ストレージの差分、処理結果はイベントで照合します。何を許し、何を拒否するかを具体化する必要があります。

最低受取額と最大支出額を固定する

交換取引なら、受け取る資産の増加量が最低ライン以上であること、支出する資産の減少量が上限以内であることを確認できます。価格そのものを予言するのではなく、利用者が許容する結果の境界を残高差分で表します。

ただし、条件の基準に使う参照価格が正しいとは限りません。取引前のオラクル値も、同一ブロック内の先行取引や操作の影響を受ける可能性があります。最低受取量を誰がどの時点で決めたかまで確認する必要があります。

新規承認や想定外の資産移動を拒否する

トークン承認は、指定した第三者に自分のトークンを移動する権限を与える仕組みです。便利である一方、広い上限が残ると、承認先の侵害後に追加流出へ使われる場合があります。状態差分から承認用ストレージの変更を調べ、「今回の操作で新規承認を増やさない」「指定量を超える承認を作らない」といった条件を設けられます。

Radiant Capitalの侵害後には、残っていた無制限承認を通じた追加流出が問題になりました。取引アサーションは過去の承認を自動で取り消すものではありませんが、新しい操作が承認範囲を広げないことや、想定外の資産移動を伴わないことを検査する用途が考えられます。

コードやアカウント制御ロジックの変更を検知する

配備コードの差分を調べれば、取引中に新しいコードが置かれたり、許可していないコード変更が起きたりした場合に拒否できます。EIP-7702のようにEOAがコードへ委譲できる環境では、送金額だけでなく、アカウントを制御するロジックが意図どおり維持されているかも重要です。

ただし、コードハッシュが同じならすべて安全とは限りません。コードが参照する外部状態、管理権限、プロキシの実装先、署名者構成などでも挙動は変わります。制御ロジックを守る条件は、関連するストレージ差分と組み合わせる必要があります。

許容する状態・イベント変更だけを通す

より厳しい方法は、起きてよい変更の集合を先に定義し、それ以外を拒否することです。たとえば「自分の二つのトークン残高、交換プールの指定スロット、定めたイベントだけが変わる」と表現します。未知の副作用を検知しやすい反面、正当な手数料処理や補助的な更新を漏らすと取引が失敗します。

現実のプロトコルは複数コントラクトを経由し、更新可能な項目も多いため、許容集合の保守には専門知識が必要です。共通操作向けの監査済みテンプレートや、ウォレットが持つ常設ポリシーがなければ、一般利用者が毎回ゼロから条件を書くのは現実的ではありません。

安全性を左右する限界とコスト

ネイティブという言葉は「Ethereumが自動で安全な条件を選んでくれる」という意味ではありません。プロトコルが提供するのは、差分を読み、条件違反時に原子的に戻すための共通機能です。条件の品質、生成経路、ガス上限、ウォレット表示が不十分なら防御効果も限定されます。

不完全な条件は未検査の変更を許してしまう

最低受取額だけを確認しても、同時に新しい承認が設定される可能性を見落とすかもしれません。自分の残高だけを見ても、アカウントの制御コードが変わる可能性は残ります。アサーションが成功したという表示を「取引の全側面が安全」と読み替えるのは危険です。

ウォレットは、検査する項目と検査しない項目を区別して示す必要があります。「受取額は確認済み、承認変更は未確認」のように守備範囲が分かれば、成功表示への過信を抑えられます。標準条件にも、対象プロトコルの更新に追随する保守が必要です。

侵害済みフロントエンドと同じ生成元では防げない

攻撃者がdAppのフロントエンドを改ざんし、危険な取引と、それを許す条件を同時にウォレットへ渡した場合、両者は矛盾しません。アサーションがあるだけでは、利用者の意図から外れた組み合わせを見抜けないことがあります。

対策には生成元の分離が役立ちます。たとえば、ウォレットが独自に「新規承認を禁止」「一日当たりの支出上限」を適用する、複数の独立した提供者から条件を照合する、利用者が通常時にポリシーを登録しておく、といった設計です。独立性がなければ、同じ侵害点へ防御も依存します。

状態差分は実行履歴の完全な再現ではない

前述のとおり純差分は途中の呼び出し順や一時的な変更を残しません。そのため、途中で危険な値になった事実の検知や、原因をたどるインシデント分析には完全な実行トレースが別途必要です。アサーションは最終結果の合否判定に使うものです。

全件走査や失敗時にもガス負担が残る

EIP-7906は典型的な検査コストを抑える設計ですが、変更アカウント、保存領域、イベントを大量に走査すればガスは増えます。網羅性と費用のバランスが必要です。

ガス不足でアサーションを完走できなければ、望ましい取引でも失敗します。そして失敗までに使ったガスは戻りません。網羅性を高めるほど計算量が増えるため、検査対象の絞り込み、上限設計、再利用できる効率的な条件が必要です。

EIP-7906はいつ使えるのか

2026年10月9日時点ではDraft段階

EIP-7906と、その前提であるEIP-8141は、2026年10月9日時点でいずれもDraftです。Draftは議論と改訂が続く提案段階を示します。Ethereumメインネットで有効化された機能でも、一般ウォレットが共通対応を完了した機能でもありません。

ニュースで「Ethereumが取引アサーションを導入」と要約されていても、提案の公開と本番採用を区別してください。現時点で利用者が設定画面を探したり、この機能をうたう非公式サイトへ資産やシードフレーズを預けたりする必要はありません。

採用可否・仕様・導入時期は未確定

Draftでは、命令の詳細、ガス設計、依存する取引形式、セキュリティ上の考慮、採用可否が変わる可能性があります。EIP-7906はEIP-8141のPOST_TXに依存するため、片方だけの状況を見ても導入時期は判断できません。具体的なネットワークアップグレードへの採用が決まり、クライアント実装とテストが進むまでは、本番利用時期を断定できません。

今後確認すべきなのは、EIPページのStatus、依存仕様の変更、実行クライアントへの実装、テストネットでの検証、ウォレットの表示仕様です。日付の予測より、これらの工程が公式に進んでいるかを見る方が確実です。

普及にはウォレットやdApp、標準ポリシーの整備が必要

プロトコルに命令が追加されても、一般利用者がバイトコードの条件を読んで判断することは困難です。ウォレットが条件を自然言語で表示し、dAppが妥当な条件候補を出し、独立したポリシー提供者や監査が品質を支える必要があります。失敗理由とガス見積もりも分かりやすく示さなければなりません。

また、ERC-4337型のアカウント抽象化、Safe Guard、Clear Signing、シミュレーションなど、既存の仕組みとの併用方法も整理が必要です。ネイティブ取引アサーションが導入されても、秘密鍵管理、フィッシング対策、承認管理、コントラクト監査が不要になるわけではありません。

まとめ：理解・予測に「結果の強制」を加える提案

EIP-7906が提案するネイティブ取引アサーションの核心は、取引前に見た説明ではなく、実際の最終状態差分を検査し、条件違反なら本体を原子的に巻き戻すことです。TXTRACE、TXDIFF、EVENTDATACOPYで残高・ストレージ・コード・イベントの差分を読み、EIP-8141のPOST_TXフレームで読み取り専用の判定を行う構想です。

役割を短く整理すると、Clear Signingは「何へ署名するかを理解する」、シミュレーションは「特定状態で結果を予測する」、アサーションは「実際の結果が条件内であることを強制する」です。三つは代替ではなく補完関係にあります。

ただし、守れるのは書かれた条件の範囲だけです。両EIPはDraftであり、現段階では利用可能な安全機能ではなく、署名と実行結果の隙間を埋める提案として捉えてください。