イーサリアムが提案した安全性チェックでは依然として悪質な取引がスルーされる可能性がある

イーサリアムはすでにいくつかの財務制限を実施しています

Uniswap v3 には現在、具体的な保護手段があります。そのスワップ ルーターは、受信金額が最小受信額を下回る場合、正確な入力のスワップを拒否します。 amountOutMinimum。正確な出力スワップの場合、最大入力を超える支出は拒否されます。 amountInMaximum。これらは、呼び出しパラメーターで指定される実行時の条件です。

条件を持つこととサウンド値の選択の違いは、Uniswap 独自のシングルスワップ ガイドに記載されています。その単純化された例では、最小出力をゼロに設定し、実稼働環境でそうすることは危険であることを明示的に警告し、開発者にソフトウェア開発キット、価格オラクル、またはより安全な値を求める別のデータ ソースを誘導します。

最低受取額はトークンの量であり、取引がお買い得かどうかを判断するものではありません。建設業者が非常に少額の入庫を許可するフロアを設定した場合、そのフロアのすぐ上の結果が合格します。すでに不十分な見積りから下限値を導き出すと、制限を正しく適用しながら、その不十分な取引が維持されます。

他の保護は、問題のさまざまな部分に対処します。今年初め、イーサリアムワーキンググループは、2026 年 5 月 12 日にクリア署名標準を発表しました。これは、ウォレットがユーザーに提示できる構造化された説明を、独立したレビューと証明、およびウォレットが選択した信頼できるソースとともに提供します。これは、署名者が要求されたアクションを理解するのに役立ちます。この説明自体は、最低限の財務結果を課すものではありません。

シミュレーションでは、選択したチェーン状態に対する影響を予測します。トランザクションがブロックに到達する前に状態が変化する可能性があります。一方、Safe スマート アカウントのガードは、実行前にパラメータをチェックし、その後 Safe の最終状態をチェックして、設定されたルールに基づいてトランザクションをブロックできます。

Ethereum トランザクション アサーションで追加されるもの

EIP-7906 は、取引の影響についてより広範な見方を提案しています。 EIP-8141 の順序付けされたフレームに基づいて構築されており、検証とアクションのステップが分離され、読み取り専用が追加されています。 POST_TX 最後にフレーム。アサーション コードは結果の状態を検査し、そのルールに違反する実行を拒否します。

提案された命令は、その作業を 3 つの操作に分割します。 TXTRACE 指定されたネット変更とイベントを列挙します。 TXDIFF キーによって値を取得し、 EVENTDATACOPY イベント データをアサーションで利用できるようにします。定義されたスコープには、ネイティブ ETH 残高、ストレージの変更、新しくデプロイされたコントラクト、コード ハッシュが含まれます。トークン残高チェックでは、関連するコントラクト ストレージを解釈し、選択した制限を適用する必要があります。

これにより、1回のスワップの最小産出量を超えた政策が可能になる可能性がある。アカウントでは、その制御構成がそのまま維持されることを要求したり、ポリシーで承認を制限したり、ルートに関係する契約全体での効果を確認したりすることができます。

このビューは依然として最終的な結果です。 1 つのストレージ スロットへの複数の書き込みは、開始値と最終値に折りたたまれます。元の値に復元されたスロットは、純変更列挙から消えます。

小切手を要求し、保護しなければならないのは誰ですか

この提案では、すべてのトランザクションにアサーションを含める必要はありません。これに依存するアカウントは、特定のを要求するように検証ロジックを構成する必要があります。 POST_TX バイパスのないフレーム。

プロトコルには関連する義務があります。その保護された機能は、必要なアサーションを正確に強制し、通常のトランザクションと、チェックが欠落または不正確なフレーム トランザクションを拒否する必要があります。ソルバーが取引の実行ルートを選択する決済フローでは、ユーザーの結果を保護するには、署名された注文または決済プロトコルでソルバーをポリシーにバインドする必要があります。提案されたソルバー保証は、1 つのネットワーク上の 1 つのトランザクションに適用されます。

ポリシーは、判断すべきアクションにも耐える必要があります。 EIP-7906 のセキュリティ ガイダンスでは、不変でアップグレード不可能なアサーション ターゲットが必要です。そうしないと、トランザクションによって検証後、最終チェック前に執行契約が変更される可能性があります。このガイダンスでは、意図したターゲットの検証が、状態が変化する前に行われる検証に依存していることも明確にしています。

変更されていないアサーション コードでも、侵害された参照を読み取る可能性があります。仕様では、アサーションの実行前に実行本体が変更できる価格、レジストリ、プロキシ、その他の状態について警告しています。取引によって、その結果が許容できるかどうかを判断するために使用される価格が変動した場合、実際の最終状態を読み取っても比較は役に立ちません。

EIP-7906 では、署名時に固定された参照値、またはトランザクション開始時の状態から抽出された参照値を推奨しています。どちらのアプローチでも、実行本体が参照を書き換えるのを防ぎます。同じブロック内の以前のトランザクションがその開始状態を移動する可能性があるため、通常のオラクルのリスクが残ります。

結果が拒否された場合でもガソリン代がかかります

この提案では失敗 POST_TX チェックすると実行本体が元に戻ります。トランザクションはブロック内に残ります。ガス支払者は消費したガスに対して請求されたままとなり、検証プレフィックスとして知られる初期検証ステップの変更はコミットされたままになります。これには、支払いの承認やアカウントの作成が含まれる場合があります。

保護されるべきアクションは、アサーションがロールバックできる部分に配置する必要があります。コミットされた検証プレフィックスに信頼できない実行を含めると、保護の範囲外になります。

チェックを完了するには十分なガスも必要です。 EIP-7906 は、変更やイベントを列挙するとバジェットが使い果たされる可能性があり、不完全なガス欠チェックをアサーションの失敗として扱う必要があると警告しています。

財団は、委任されたエージェントとソルバー決済における潜在的なアプリケーションについて説明しています。 AI ウォレットの許可に関する CryptoSlate の 9 月の記事では、決定的な制限と必要なアサーションについてすでに説明されています。

有意義な実装では、承認前に必要な制限とその参照が明確になり、ビルダーの弱体化を防ぐことができます。イーサリアムは、間違った金融取引を強制しながら、安全条件を完全に強制する可能性があります。