イーサリアムはボットが攻撃する前に、ボットから取引を隠したいと考えています

イーサリアム開発者らは、ブロックチェーンに到達する前に保留中のトランザクションを悪用する略奪的な取引ボットに対する新たな防御策を検討している。

この問題は、トランザクションを実行前に検査できる透明な待機室であるイーサリアムの公開メモリプールに起因しています。この可視性により、自動トレーダーは収益性の高い注文を見つけて、その注文を中心に独自の取引を配置し、取引が決済される前にユーザーから価値を引き出すことができます。

この慣行はサンドイッチ攻撃と最も密接に関連しています。ボットは保留中のスワップを発見し、最初に同じ資産を購入してユーザーに不利な価格を動かし、その後、被害者の取引がより悪い価格で実行された直後に売却します。

推定では、このような攻撃による損失は以前のピークに比べて減少していることが示唆されていますが、問題が解消されたわけではありません。 4月には、イーサリアムの共同創設者ヴィタリック・ブテリン氏自身も、悪名高いJaredfromsubway.ethボットが彼のアドレスの1つから小規模なスワップをフロントランおよびバックランした際に標的となった。

開発者らは現在、暗号化によってこうした攻撃を可能にする情報上の優位性を排除できるかどうかを検討している。

プロトコル研究者らは、8月19日の「メンプールの暗号化」会議でこの問題について議論する予定で、ブロック内の位置がすでにコミットされるまでトランザクションの内容を隠すように設計された提案を検討する予定だ。

この取り組みは、イーサリアムユーザーの長期にわたるトレードオフをターゲットにしています。トレーダーはすでに、プライベートリレーを介してトランザクションをルーティングすることでパブリックメモリプールをバイパスでき、フロントランニングへのエクスポージャを減らすことができます。しかし、その保護には、トランザクションの包含と可用性を制御する仲介者への依存が伴います。

暗号化されたパブリックメモリプールは、順序が修正される前にビルダーやボットが基礎となる取引を参照できないようにしながら、ブロックスペースへの許可のないアクセスを維持しようとします。

主要な提案の 1 つは、LUCID として知られる EIP-8184 です。この草案では、ブロックビルダーに対し、トランザクションの内容を知らずに、課金対象のチケットと暗号化されたペイロードを含む封印されたトランザクションをコミットすることが求められる。コミットメントが行われた後にのみ、送信者またはオフプロトコル鍵発行者は、暗号化を解除するために必要な情報を公開します。

この設計は悪用の道を 1 つ閉ざす一方で、イーサリアム開発者がまだ解決できていない別の問題も生み出します。

復号化のジレンマ

完全に暗号化スキームを確立するには、イーサリアムの規模で一連の困難な制約を満たす必要があります。

EIP-8184の作成者は、要件として、小さな公開鍵、非対話型復号化、信頼できるセットアップなし、実用的な暗号文サイズ、選択された暗号文の強力なセキュリティ、量子安全性への信頼できるルートを挙げています。

彼らは、現在、イーサリアムの規模でセット全体を満たす既知の暗号構造は存在しないと述べています。

したがって、LUCID は復号化の構築をコアプロトコルの外側に残し、送信者が独自のキーのリリースを管理したり、キー発行者の指示に従ったりできるようにします。これにより、後でより強力な暗号化を行うための柔軟性が保たれますが、EIP-8184 のセキュリティ上の考慮事項により、発行者の選択がユーザーのセキュリティモデルの一部となることが明示されています。

この設計は金融負債も生み出します。

LUCID の最初の草案では、鍵が保留されているか、予定通りに到着しない場合、マルチ鍵公開の失敗に対するプロトコルレベルのペナルティを、サードパーティの鍵プロバイダーに自動的に転送するのではなく、トランザクション送信者に残しておきます。

失敗した公開に経済的コストをかけるために、LUCID は、暗号化されたブロックのトップセグメントをブロックガス制限の 8 分の 1 に制限し、予約料金を使用します。その金額のほとんどは、復号化に成功した後に返還されますが、公開に失敗すると予約全体が失われる可能性があります。

そのため、失敗したリリースや選択的なリリースは高価になりますが、キーが到着しなかった理由を特定したり、発行者が意図的に早期にキーを漏洩したかどうかを判断したりすることはできません。

著者らは、出版社がバンドル内の取引に資金を提供し、封印されたままであれば損失を吸収するというオフプロトコルのスポンサーシップ協定について説明している。イーサリアム自体はその誓約を強制しません。

取引仲介者とネットワークの拡張

水曜日の議題では、一時的な非ポスト量子暗号ソリューションが受け入れられるかどうかが開発者に尋ねられる。

また、バリデーターのホワイトリストのメンバーによる保留または早期の鍵販売をどのように証明できるか、またそれらの証明を自動化できるかどうかという、より深い適用の問題も対象としています。

ホワイトリストは、誰にキーの公開を許可するかを確立できます。それ自体では、意図的な不正行為とソフトウェアの障害、ネットワークの遅延、または期限の遅れを区別することはできません。

代替案である EIP-8105 では、登録プロバイダーが信頼する他のプロバイダーを識別する有向信頼グラフが使用されます。プロバイダーは独自の源泉徴収条件を設定し、インセンティブ、信頼性システム、および潜在的な罰則メカニズムをイーサリアムのコンセンサスルールの範囲外に残すことができます。

他のアプローチでは、独自のコストが発生します。しきい値による復号化により、制御が複数の参加者に分散されますが、タイミングのプレッシャーが加わります。信頼できるハードウェアは、新しいハードウェアとオペレータの依存関係を導入しながら、キーへのパスを短縮できます。

実稼働環境のデプロイメントも、イーサリアムのより広範なロードマップと調整する必要があります。 LUCID は、FOCIL (EIP-7805) に関連付けられた包含リストパイプラインを拡張するように設計されており、ビルダーが含める必要があるトランザクションを識別する役割を複数のバリデーターに与えます。

イーサリアムのセキュリティロードマップは現在、2027年のヘゴタアップグレードに向けたコンセンサス層の優先事項としてFOCILをターゲットにしているが、より広範なポスト量子インフラストラクチャのマイルストーンはさらに先にある。