署名した後の最終確認：Ethereumは取引結果を巻き戻せるか

指示書と受け取り結果の間

ある資産を渡し、別の資産を指定した最低数量以上受け取る交換を考えてみよう。画面が示すのは実行する動作だが、自分が求めているのは実行後の残高である。両者は結びついていても同じ約束ではない。署名は取引データを承認する。それだけで頭の中の期待すべてが強制可能な条件に変わるわけではない。これは説明用の仮定であり、失敗した取引の報告ではない。^[1][2]

Ethereum Foundationの10月5日の解説は、この隔たりを扱っている。読みやすい署名画面は要求された動作を説明し、シミュレーションは特定のチェーン状態に基づく結果を予測する。実際の実行時には状態やコントラクトの振る舞いが変わる可能性がある。EIP-7906の問いは、取引自身に最終結果の検査を添え、失敗した場合にその実行効果を拒否できるか、というものだ。^[2]

既存の条件検査に、より広い視野を

結果に条件を付ける仕組みは、すでにアプリケーション内にある。Uniswap v3の交換インターフェースには、最低受取量を設定するamountOutMinimumがある。開発者ガイドは、学習用の簡略例のようにゼロを設定することは本番では危険だと警告している。検査機構があっても、選ぶ条件に意味のある制限がなければ十分ではない。^[7]

今回の提案は、取引中に何が変わったかを検査コントラクトがより一般的に把握するためのものだ。呼び出すアプリごとの内部検査だけに頼らず、ウォレットが別のアサーションを添えられる。EIP-7906は、別の草案EIP-8141に依存する。EIP-8141は取引を検証、ガス支払いの承認、実行などの役割を持つフレームに分ける。そこに最後の検査モードを追加する。^[1][3]

処理の後、同じ取引の中で確かめる

現行の文面では、ASSERTフレームは取引の末尾に連続して配置される。読み取り専用なので、検査側が状態を書き換えてから自分でその変更を承認することはできない。TXTRACEは取引による変化を列挙し、TXDIFFは特定のアカウントやストレージ項目を参照し、EVENTDATACOPYは発生したイベントのデータを読み出す。一般のウォレットにあるボタンではなく、提案されたEVM命令である。^[1]

状態差分は、すべての操作を撮った動画ではなく、前後の比較表に近い。同じストレージスロットへの複数回の書き込みは純変化にまとまり、開始時の値に戻った項目は、その一覧に純変化として現れない。ネイティブETH残高、コントラクトの保存値、デプロイされたコードは異なる情報である。トークンの経済的意味には適切な解釈ロジックも必要だ。保存値を読むだけで、すべてのトークンや権限が人に分かる一覧になるわけではない。^[1]

先ほどの仮の交換では、意図した受取人が約束した最低数量を受け取ったかを検査できる。しかし、それだけでは別の場所で起きる無関係な変更を禁じられない。どの資産、受取人、権限が重要かも条件に含める必要がある。プロトコルは検査を実行できても、取引を行うという広い許可から利用者の意図すべてを読み取ることはできない。^[1]

巻き戻しにも境界と費用がある

ASSERTが失敗すると、現行設計はガス支払いを承認したフレームの直後まで実行本体を巻き戻す。取引自体はブロックに含められる有効な取引として残り、支払者は消費済みのガス代を負担する。検査の失敗で取引全体が消える、あるいは失敗した試行が無料になると説明するのは誤りだ。^[1][5]

先行する検証部分、validation prefixは確定したまま残る。そこには支払い承認だけでなく、アカウントのデプロイが含まれる場合もある。ウォレットは保護したい外部アプリの動作を、この境界より後に置く必要がある。検証部分に入れた動作は最後の検査では戻せない。10月15日の改訂はこの境界を明示した。処理費用と信頼する初期設定を残して実行結果を拒否する仕組みであり、万能の取消ボタンではない。^[1][3][5]

受け入れる条件を誰が決めるか

誤った、あるいは悪意ある画面が緩すぎる条件を渡せば、望まない結果も通過し得る。そのため仕様は、ルールの出所、入力値、検査コード自体を設計の一部として扱う。同じ取引が変更できる値に基づく検査は、制約したい動作そのものを承認しかねない。選ぶ条件は、利用者の意図を意味のある形で独立して表せる必要がある。^[1]

すべての取引に特定の検査を強制する提案でもない。ウォレットの検証ロジックは、有用な検査があるはずだと期待するのではなく、正しい検査フレーム、呼び出し先、データを要求しなければならない。信頼できる検査器、適切なガス予算、確かな検証ロジックは引き続き必要だ。対象は現在の取引が生むオンチェーン効果であり、後の相場変動や別チェーンでの履行まで保証するものではない。^[1]

提供済みの保証ではなく、発展中の仕様

10月5日のブログはこのモードをPOST_TXと呼んでいた。15日の巻き戻し境界の明確化に続き、16日にマージされた変更でASSERTに改名された。17日の確認時点で、EIP-7906も依存先のEIP-8141もDraftである。ForkcastはEIP-7906をHegotaのConsidered for Inclusionとして記録している。これは有効化の発表ではなく、仕様の成熟度とアップグレードへの組み込み予定も別の指標だ。^{[1][2][3][4][5][6]}

この提案の意義は、ウォレットが利用者の合意を表現できる場所を広げる点にある。署名する指示だけでなく、実行が生んだ結果にも条件を課そうとしている。実際の保護につながるかは、採用と、ウォレットが要求する正確なルール次第だ。今読めるのは、巻き戻しの境界を定めた結果制約の設計である。署名したどんな取引でも後から取り消せるという約束ではない。^[1][6]