検閲抵抗のための強制的な包摂メカニズムの実用的な制約

上級9/27/2024, 4:04:38 PM
この記事では、取引の検閲問題に対処するための強制包含メカニズムの制限について説明しています。ArbitrumやOptimismなどのシステムでは、ユーザーが特定の取引を特定の時間枠内で含めるよう要求できますが、リッチステートチェーンでは、シーケンサーが共有ステートを変更することでこれらの取引を失敗させることができます。

著者の注意:init4次世代のイーサリアムツールに取り組む研究集団です。これは研究ノートであり、開示書ではありません。既存および提案されたシステムのセキュリティモデルの微妙なニュアンスやギャップについて議論することがありますが、これらを「脆弱性」と表現することは誇張であり、「以前には知られていなかった」とも言えません。

検閲抵抗は一般的に暗号通貨の中心価値であり、イーサリアム特に. 私たちは、オンチェーンでの取引の利点が誰にでも利用可能であるべきであり、チェーンのルールがすべてのユーザーと用途に等しく適用されるべきだと信じています。価値がこの空間を前進させます。エンジニアリングは、価値を現実に対してテストするプロセスであり、どこでどのように壊れるかを見つけるためのものです。

ドミノも順番に並べるんだよ :) 写真 by トム・ウィルソンUnsplash

検閲の定義

検閲を意図的に取引が正規の順序に現れないように防ぐこととしてモデル化する傾向があります(つまり、取引の除外)。注文が経済的結果だけに依存するときには公平または中立であると考えますが、他の情報に依存するときには不公平または検閲されたと考えます。たとえば、ブロックを作成する際、手数料の低い取引を含めないのは許容されますが、特定の人物からの送金であるために取引を含めないのは許容されません。したがって、取引が非経済的情報に依存している場合、それは検閲されたと言います。取引が含まれないが、含まれた取引よりも注文システムにより多くの利益をもたらす場合、それは検閲されたと見なされます。この定義は、検閲抵抗のための強制的な含まれるメカニズムに取り組む動機づけとなります。ユーザーが自分の取引の含まれることを強制できる場合、この定義によれば、それは検閲されることはありません。

強制的な包摂メカニズム

OP Stackチェーンの主要なセキュリティ目標は、シーケンサーがL2チェーンにトランザクションを送信することをユーザーが妨げることができないことです。

モダンなロールアップは一般的に中央集権的なシーケンシングを持ちます。つまり、シーケンサーによる検閲は簡単であり、彼らは単に特定のユーザートランザクションを含めないように選択することができます。これを緩和するために、複数のロールアップが含まれています。楽観主義そしてアービトラム- 強制的な包含メカニズムを持っています。これらのメカニズムにより、ユーザーは、シーケンサーの動作に関係なく、ある時間の遅延後にロールアップによってトランザクションが実行されることを保証することができます。包含はL1上に展開された契約によって強制されます。したがって、強制的な包含トランザクションは(理論的には)他のEthereumトランザクションと同じく検閲抵抗性を持っています。

強制的な包含は、有効な順序付けに保持する必要があるサブレンジを指定します。

Ethereumには、強制的な包括メカニズムも提案されています。EIP-7547. インクルージョンリストを使用すると、ブロック提案によって次のブロックの内容を部分的に指定することができます。ブロック提案者はブロックビルダーよりも検閲する動機が少ないという仮定の下で、これは検閲に対する効果的な緩和策を提供します。

一般的に、強制的な包含メカニズムは、有効な順序への新たな制約を作り出します。これにより、プロトコルのルールによって広範な順序クラスが無効になります1. 強制的な包括は、ユーザーが将来の順序のサブセットを指定できるようにすると考えるべきです。すべての有効な順序は、強制されたサブセットを拡張しなければなりません。

検閲のモデルを拡張する

残念ながら、トランザクションの確認は手段であり、目的ではありません。私たちの検閲のモデルは不完全です!

検閲は目標の観点で定義されなければなりません。ユーザーはトークンを送信したり、NFTを購入したり、資金を借りたりすることを望んでいます。トランザクションの確認はその目標に対して付随するものです2. センサーも同様に、特定の目標を持っています。その目標は、ハックトランザクションの成功を防止すること、法律を遵守すること、または競合他社のビジネスに干渉することである場合があります。両当事者の意図を尊重するために、検閲を再定義する必要があります。

この考えに基づいて、私たちは検閲の定義を拡大すべきです。つまり、第三者が取引が目標を達成することを妨げることができる場合、取引は検閲されています。つまり、検閲者は取引の確認を阻止する必要はありません。彼らは単にスマートコントラクトの実行を取り消す必要があります。EVMトランザクションを取り消すことは、そのトランザクションの検閲です。取引の内容を無視する脅威モデルでは、検閲を正確にモデル化することはできず、したがって効果的にユーザーを保護することはできません。

形式的には、チェーンとの任意の相互作用に対して、結果の順序付けを評価し、0(目標が失敗)または1(目標が達成)を生成するスコアリング述語fが存在すると言えます。このモデルでは、検閲者のスコアリング関数は単純に否定です:f' = !f。ユーザーがしない場合、検閲者は自分の目標を達成します。3

ユーザーの目標は隠されているかもしれませんが、取引そのものにはほとんど常にそれを推測するための十分な情報が含まれています。Uniswap取引には明らかな目標があります。また、ブロックチェーンは決定論的であるため、検閲者は完璧に予測することができます、どの順序が検閲者の述語を満たすか。その結果、ユーザーはEVMモデルにおいて検閲から自分を守るために隠された情報に頼ることはできません。取引の詳細は公開されなければならず、それはユーザーの目標に関する情報も公開されていることを意味します。

単純化のために、標準的なランアヘッドシーケンサーモデルで作業していると仮定しましょう。4. 強制的な含める取引は後でシーケンサの回転の下で取り扱います。このモデルでは、シーケンサはシーケンスに対して完全な制御を持ち、任意の結果を完璧にシミュレートすることができます。つまり、彼らはすべての可能な順序のセットから選ぶことができます。したがって、検閲に関する私たちの準形式的な質問は、「fが0に評価される有効な順序が存在するか」ということになります。そのような順序が存在する場合、シーケンサはそれを選択することができます。

そこから、強制的な包含を考慮に入れるためにモデルを拡張することができます。「fが0に評価される有効な順序が存在するか?」そのような順序が存在する場合、シーケンサはそれを選択することができます。強制的な包含は、シーケンサが順序に対して制御を行使するのを防ぐものではなく、彼らの行動を制約するだけです。残念ながら、強制的な包含には根本的な問題があり、多くの取引に対して有効な検閲抵抗メカニズムとなることを阻んでいます。

The Hand-off Problem

強制的な包括メカニズムは、2つのモードのうちの1つで順序付けが行われることを意味します:強制されない場合と強制される場合です。強制されない場合から強制される場合(およびその逆)への移行が定義されています。そのポイントはハンドオフです。ハンドオフは、強制的な包括メカニズムの設計において複雑な問題を提起します。

非強制的な参加から強制的な参加への移行が必要です。

強制トランザクションはハンドオフ時に状態で実行されます。したがって、再び、状態の競合5醜い頭をもたげる。トランザクションのバッチ (ブロックなど) 内でハンドオフが発生すると、バッチの作成者はハンドオフ時の状態を制御できます。強制インクルード トランザクションがパブリック状態を読み取る場合、バッチの作成者は、強制トランザクションの実行の前後にその状態を書き換えることができます。競合は検閲に十分です。

バッチ作成者は、ハンドオフ時に状態を制御できるため、強制トランザクションの結果に影響を与えることができます。結果に影響を与えることができるため、スコアリング述語の結果に潜在的に影響を与えることができます。たとえば、シンプルなAMMインタラクションを考えてみましょう。ユーザーは最低許容価格を設定しますが、バッチ作成者はハンドオフポイントで市場価格を最低許容価格よりも低くすることができます。これにより、ユーザートランザクションがリバートされ、ユーザーが検閲されることになります。67

興味深いことに、排除による検閲よりも、国家の競合による検閲の方が効果的です。除外されたトランザクションは将来のブロックに含まれる可能性がありますが、競合によって検閲されたトランザクションは永久に無効化されます。それはチェーンに含まれており、二度と含めることはできません。そのトランザクションはユーザーの目的を達成することができません。再度試すには、ユーザーはトランザクションを再作成して再送信する必要があります(そして再び検閲される可能性があります)。

実用的なシステム

[A]ny user can bypass the Sequencer entirely to submit any Arbitrum transaction (including one that, say, initiates an L2 to L1 message to withdraw funds) directly from layer 1. Thus [sic] mechanism thereby preserves censorship resistance even if the Sequencer is being completely unresponsive or even malicious.

ランアヘッド・シーケンシング・モデルでは、シーケンサーはシーケンス内のハンドオフの位置をほぼ完璧に制御し、より少ない料金を支払います(チップを渡す必要がなく、EIP-1559の基本料金をある程度制御できるため)。その結果、シーケンサーは、状態の競合を使用してユーザーの操作を検閲する特権的な立場にあります。些細なことです。ハンドオフの問題により、シーケンサーは大きなクラスのトランザクションを検閲できます。

EIP-7547では、ビルダーがブロックのハンドオフがどこで発生するかを選択します。8その結果、ビルダーはブロック内でのハンドオフの場所を選択することができます。これは、彼らが任意にプレフィックスとポストフィックスを選択できることを意味します。9ブロックガスのルールを尊重する限り。接頭辞はチェーンをトランザクションが元に戻す状態にすることができ、接尾辞はチェーンを通常の状態に復元します。EIP-7547 包含リストは、係争状態にアクセスするトランザクションの検閲を防ぐのに十分ではありません。ハンドオフの問題により、ほとんどの場合、IL はトランザクションの実行を保証できません。

強制的な包括は、ブロックチェーンの非自明な用途において、ユーザーを検閲から保護するために効果的ではありません。引き継ぎの問題により、順序に関する十分な裁量権がなくても、検閲者は状態に対して十分な裁量権を持つことが保証されます。この問題は、AMM、貸出市場、オークション、およびその他のほとんどのDeFiアクションに影響を与えます。トランザクションの包括を保証できる場合でも、多くの重要なアクションは検閲可能です。状態の競合は、強制的な包括を検閲抵抗機構としての効果を制限します。

ケーススタディー

これの遠い影響を見るためには、Optimismのレンディング市場でUSDCを貸し出すユーザーを考えてみてください。ユーザーが市場からUSDCを引き出したいとき、彼らはOptimismトランザクションを提出し、そのトランザクションはシーケンサーによって検閲されます。その後、彼らは公式の強制インクルージョンメカニズムを使用して、シーケンサーを迂回してEthereumでトランザクションをキューに入れます。

シーケンサーはキュー内のトランザクションを見ることができ、それをサンドイッチにすることができます。トランザクションを検閲するために、シーケンサーは強制トランザクションの直前に市場から利用可能なすべてのUSDCを借ります。市場にはもはや流動性がないため、強制トランザクションは元に戻ります。その後、シーケンサーはすぐにUSDCを返済することができます。

シーケンサーまたはビルダーは、ハンドオフ時に状態を操作することができます。

これには、シーケンサーがUSDCを借りるために十分な担保を持っている必要がありますが、非常にわずかな借入コストしか課されません。10さらに、担保は、借入が開かれたままになることがないため、すべての検閲に再利用できます。その結果、AAVEまたはCompound on Optimism(またはArbitrumまたはその他の中央配列ロールアップ)のユーザーは、担保を引き出すことができるという保証はありません。シーケンサーは、いつでも貸付市場からの引き出しを検閲できます。強制的なインクルージョンは、ユーザーを検閲から守るのに十分ではありません。

フォローアップ作業

追跡調査の分野はいくつかあります。

まず、EIP-7547は簡単に改善することができます。ILトランザクションを次のブロックの終わりに処理するように要件を追加することです。PBSオークションの文脈では、検閲はMEVです。ビルダーは非経済的な価値を生み出し、それにETHで表される主観的な価値を割り当てる必要があります。ビルダーによる検閲は、ビルダーのブロック入札の増加を引き起こします。11これは検閲バンドルを作成する可能性のある検索者にも適用され、検閲の経済価値の一部は提案者によって捕捉され、直接参加していなくても検閲を容認する動機を提供します。強制的なインクルージョン取引をブロックの最後に配置することで、ブロックビルダーの能力を無効にし、論争のある検閲の経済コストを増加させます。たとえば、状態の争いを通じてAMMの相互作用を検閲することは、AMMの裁定取引を一部放棄するか、市場を範囲外に押し出すために高いコストを支払う必要があり、そのサンドイッチを閉じて回収できない可能性があります。さらに、これにより、ビルダーではなく検索者が1ブロックあたりに生成することができる検閲バンドルが制限されます。12プレフィックスはサフィックスよりも重要ですので、ブロックの一番上での実行をお勧めしますが、これによりILトランザクションのコストが大幅に増加します。この方法では、強制的な含めることによるブロック一番上のMEV抽出が可能になります。13検閲官がILトランザクションに原子的に後置する権利を削除することは、小さな改善です。

第 2 に、検閲者がトランザクション シミュレーションによって先を見越し、入力状態を制御できるため、ハンドオフの問題が存在します。多くのMEV耐性メカニズムは、ユーザーの目標に関する情報を導き出し、結果をシミュレートする検閲者の能力を排除するために、隠された情報を導入します。通常、これらはコミット/公開スキームであり、一部のトランザクション情報は注文が行われるまで非公開です。注文と実行の分離と隠された情報は有望に見えますが、MEVサプライチェーン、イーサリアムのコンセンサスプロセス、およびシーケンスされたロールアップモデルとは大きく互換性がありません。トランザクションをシミュレートする機能を無効にする何らかの方法は、検閲と大規模なクラスのMEVに対処しますが、プロトコル、プロトコルのオペレーター、アプリケーション、およびエンドユーザーにとって非常に侵襲的です。

第 3 に、「順序に依存しない」スコアリング関数という興味深いクラスがあります。これらは、論争のある状態にアクセスしないか、またはアクセスする競合状態が何らかの意味で「信頼できる」ものにするのに十分な制約を持っているため、状態の競合によって検閲できない目標です。順序に依存しないアクションには、ETHをEOAに送信することが含まれ、ほとんどのERC-20送信、14そして、市場への担保の追加など、いくつかのDeFiインタラクション。これらのアクションは、競合による検閲から保護されています。このクラスの目標は、安全なクロスチェーン通信とMEV耐性にも興味深い対応関係があり、より深く研究する価値があります。アプリケーションやプロトコルは、場合によっては順序に依存しないアクションのみを含むように設計されている可能性がありますが、さらなる研究が必要です。

結論

リッチステートは、悪意のあるアクターがトランザクションを含めながら検閲することを可能にします。ハンドオフの問題は、強制インクルージョンメカニズムの基本であり、軽減することしかできません。一元的にシーケンスされたロールアップでは、軽減策は不可能です。強制的な包含は、論争国の存在下での検閲に対処することはできません。経済的に重要な取引の大きなクラスは、たとえ強制的に含まれていたとしても、打ち切られる可能性があります。ハンドオフの問題は、現代のロールアップに特有のものであり、イーサリアムの検閲耐性EIPにも存在します。その結果、強制的な包摂は有益ではあるが、富裕国チェーンに検閲への抵抗力を与えるには決して十分ではない。ロールアップはイーサリアムのセキュリティプロパティを「継承」しておらず、継承すると示唆するのはばかげています。インクルージョンにこだわるのをやめると、検閲への抵抗がMEVへの抵抗の特殊なケースであることが明らかになります。

私たちは感謝したいと思いますマイク・ニューダー, Tarun Chitra、そしてブランドン・カーティスレビューとフィードバック用です。

1

通常、L1 では無効なブロックを拒否することで実現されますが、ロールアップでは、何らかのフィルタリング関数を使用して無効なシーケンスを有効なシーケンスに強制することで実現されます。

2

これは意図についての投稿ではなく、現時点では世界はこれ以上の意図を必要としていません。

3

これは、結果の主観的な値を考慮していないため、明らかに不完全なモデルです。例えば、検閲に失敗した場合、検閲官はいくらでもお金を失う可能性があります(例えば、特定の行動を検閲しなかった場合、フランスの警察に逮捕される可能性があるため)。一方、ユーザーは、特定の時間枠で目標が達成されない場合、任意の金額を獲得/失う可能性があります(たとえば、自分のトークンに対して$ 100mm+のローンを組み、清算される前にポジションを再担保する必要があります)。

4

「ベース」のシーケンサーモデルとは対照的です。最近のほとんどのロールアップでは、シーケンサーは、トランザクションがイーサリアムにコミットされる前に、トランザクションの包含と実行の証明を提供するため、イーサリアムの「先」を実行します。このモデルでは、シーケンサーがシーケンスを完全に制御し、トランザクションの結果はイーサリアムの再編成から独立している必要があります。

5

複数のユーザーが同じ契約、資産、または状態にアクセスする場合、彼らのトランザクションは互いに「競合」し、互いの結果に干渉する可能性があります。競合は偶然に起こるか、意図的に起こる可能性があります。これはブロックチェーンシステムにおけるリッチステートの解決の難しい問題です。共有状態への一般のアクセスは、MEV、スケーラビリティの問題、および現代社会における礼儀の低下の根源です。

6

一般に、国家の争いによる検閲は、MEVの特殊なケースと考えるべきです。抽出された値はオフチェーンであり、観測不可能であり、潜在的に非常に大きいため、国家の競合による検閲がいつ発生するかを予測することは困難な場合があります。

7

私たちは2017年の記事「特に、状態の競合を使用してトランザクションを元に戻す方法について説明しました。」でトランザクションを元に戻すための状態の競合について特集しました。マイナーはあなたの友達ではありません”. 当時、”MEV”という用語はまだ使用されていませんでした。

8

PBSは検閲抵抗を著しく複雑化することがよく知られています。VBの参照をご覧ください。@vbuterin/pbs_censorship_resistance">研究ノート。

9

トランザクションの接頭辞と接尾辞は一般に "サンドイッチ" と呼ばれ、状態の競合を使用して MEV を抽出する方法としてよく理解されています。

10

借り入れはわずか数秒しか保持されません。ロールアップシーケンサーは、効果的な借り入れ時間を0にするために、いくつかの場合にはタイムスタンプやブロックの境界を保持することがあります。

11

ビルダーは、検閲の主観的な価値まで支払いをする意思があり、それによりブロックの客観的に観測可能な抽出可能な価値を上回る入札が生じる可能性があります。極端な場合、これにより検閲者のETH残高の変化がマイナスになることがあります(つまり、ブロックの作成にETHを支払い、手数料や報酬で受け取るETHよりも多く支払うことになります)。

12

これは、異なるバンドルからの交互にトランザクションを禁止し、「必ず失敗する」トランザクションを許可しないMEVオークションルールに依存していることに注意してください。これらのルールが緩和され、バンドルトランザクションを交互にできるようになった場合、および/またはビルダーがバンドル内の「必ず失敗する」ブロックをサポートし始めた場合、保護は消失する可能性があります。この動的は、ILトランザクションがブロックの最後になければならない場合、非強制トランザクションを交互にすることができず、したがって最大1つのサーチャー検閲バンドルが発生する可能性があるためです。

13

ビルダーが限定的なブロック間バンドルを効果的に作成できるようにします。次のような事前コンセンサスシステムFOCILこれをmitiGateできました。

14

標準的なERC-20トークンの場合、第三者がユーザーの残高を減らすことができないため、通常、転送呼び出しは競合によって検閲できません。ただし、transferFrom 呼び出しについて考えてみます。承認された譲渡者が、独自の状態での競合を許可する契約である場合、アクションは、その競合によって検閲される可能性があります (意図しない方法で transferFrom に必要な承認を消費します)。

免責事項:

  1. この記事は[から転載されています技術], All copyrights belong to the original author [init4の]. この転載に異論がある場合は、お問い合わせください。Gate Learn(ゲート・ラーン)チームがすぐに対処します。
  2. 責任免除声明:この記事に表明された見解や意見は、著者個人のものであり、投資アドバイスを提供するものではありません。
  3. この記事の翻訳はGate Learnチームによって行われています。特に言及されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。

検閲抵抗のための強制的な包摂メカニズムの実用的な制約

上級9/27/2024, 4:04:38 PM
この記事では、取引の検閲問題に対処するための強制包含メカニズムの制限について説明しています。ArbitrumやOptimismなどのシステムでは、ユーザーが特定の取引を特定の時間枠内で含めるよう要求できますが、リッチステートチェーンでは、シーケンサーが共有ステートを変更することでこれらの取引を失敗させることができます。

著者の注意:init4次世代のイーサリアムツールに取り組む研究集団です。これは研究ノートであり、開示書ではありません。既存および提案されたシステムのセキュリティモデルの微妙なニュアンスやギャップについて議論することがありますが、これらを「脆弱性」と表現することは誇張であり、「以前には知られていなかった」とも言えません。

検閲抵抗は一般的に暗号通貨の中心価値であり、イーサリアム特に. 私たちは、オンチェーンでの取引の利点が誰にでも利用可能であるべきであり、チェーンのルールがすべてのユーザーと用途に等しく適用されるべきだと信じています。価値がこの空間を前進させます。エンジニアリングは、価値を現実に対してテストするプロセスであり、どこでどのように壊れるかを見つけるためのものです。

ドミノも順番に並べるんだよ :) 写真 by トム・ウィルソンUnsplash

検閲の定義

検閲を意図的に取引が正規の順序に現れないように防ぐこととしてモデル化する傾向があります(つまり、取引の除外)。注文が経済的結果だけに依存するときには公平または中立であると考えますが、他の情報に依存するときには不公平または検閲されたと考えます。たとえば、ブロックを作成する際、手数料の低い取引を含めないのは許容されますが、特定の人物からの送金であるために取引を含めないのは許容されません。したがって、取引が非経済的情報に依存している場合、それは検閲されたと言います。取引が含まれないが、含まれた取引よりも注文システムにより多くの利益をもたらす場合、それは検閲されたと見なされます。この定義は、検閲抵抗のための強制的な含まれるメカニズムに取り組む動機づけとなります。ユーザーが自分の取引の含まれることを強制できる場合、この定義によれば、それは検閲されることはありません。

強制的な包摂メカニズム

OP Stackチェーンの主要なセキュリティ目標は、シーケンサーがL2チェーンにトランザクションを送信することをユーザーが妨げることができないことです。

モダンなロールアップは一般的に中央集権的なシーケンシングを持ちます。つまり、シーケンサーによる検閲は簡単であり、彼らは単に特定のユーザートランザクションを含めないように選択することができます。これを緩和するために、複数のロールアップが含まれています。楽観主義そしてアービトラム- 強制的な包含メカニズムを持っています。これらのメカニズムにより、ユーザーは、シーケンサーの動作に関係なく、ある時間の遅延後にロールアップによってトランザクションが実行されることを保証することができます。包含はL1上に展開された契約によって強制されます。したがって、強制的な包含トランザクションは(理論的には)他のEthereumトランザクションと同じく検閲抵抗性を持っています。

強制的な包含は、有効な順序付けに保持する必要があるサブレンジを指定します。

Ethereumには、強制的な包括メカニズムも提案されています。EIP-7547. インクルージョンリストを使用すると、ブロック提案によって次のブロックの内容を部分的に指定することができます。ブロック提案者はブロックビルダーよりも検閲する動機が少ないという仮定の下で、これは検閲に対する効果的な緩和策を提供します。

一般的に、強制的な包含メカニズムは、有効な順序への新たな制約を作り出します。これにより、プロトコルのルールによって広範な順序クラスが無効になります1. 強制的な包括は、ユーザーが将来の順序のサブセットを指定できるようにすると考えるべきです。すべての有効な順序は、強制されたサブセットを拡張しなければなりません。

検閲のモデルを拡張する

残念ながら、トランザクションの確認は手段であり、目的ではありません。私たちの検閲のモデルは不完全です!

検閲は目標の観点で定義されなければなりません。ユーザーはトークンを送信したり、NFTを購入したり、資金を借りたりすることを望んでいます。トランザクションの確認はその目標に対して付随するものです2. センサーも同様に、特定の目標を持っています。その目標は、ハックトランザクションの成功を防止すること、法律を遵守すること、または競合他社のビジネスに干渉することである場合があります。両当事者の意図を尊重するために、検閲を再定義する必要があります。

この考えに基づいて、私たちは検閲の定義を拡大すべきです。つまり、第三者が取引が目標を達成することを妨げることができる場合、取引は検閲されています。つまり、検閲者は取引の確認を阻止する必要はありません。彼らは単にスマートコントラクトの実行を取り消す必要があります。EVMトランザクションを取り消すことは、そのトランザクションの検閲です。取引の内容を無視する脅威モデルでは、検閲を正確にモデル化することはできず、したがって効果的にユーザーを保護することはできません。

形式的には、チェーンとの任意の相互作用に対して、結果の順序付けを評価し、0(目標が失敗)または1(目標が達成)を生成するスコアリング述語fが存在すると言えます。このモデルでは、検閲者のスコアリング関数は単純に否定です:f' = !f。ユーザーがしない場合、検閲者は自分の目標を達成します。3

ユーザーの目標は隠されているかもしれませんが、取引そのものにはほとんど常にそれを推測するための十分な情報が含まれています。Uniswap取引には明らかな目標があります。また、ブロックチェーンは決定論的であるため、検閲者は完璧に予測することができます、どの順序が検閲者の述語を満たすか。その結果、ユーザーはEVMモデルにおいて検閲から自分を守るために隠された情報に頼ることはできません。取引の詳細は公開されなければならず、それはユーザーの目標に関する情報も公開されていることを意味します。

単純化のために、標準的なランアヘッドシーケンサーモデルで作業していると仮定しましょう。4. 強制的な含める取引は後でシーケンサの回転の下で取り扱います。このモデルでは、シーケンサはシーケンスに対して完全な制御を持ち、任意の結果を完璧にシミュレートすることができます。つまり、彼らはすべての可能な順序のセットから選ぶことができます。したがって、検閲に関する私たちの準形式的な質問は、「fが0に評価される有効な順序が存在するか」ということになります。そのような順序が存在する場合、シーケンサはそれを選択することができます。

そこから、強制的な包含を考慮に入れるためにモデルを拡張することができます。「fが0に評価される有効な順序が存在するか?」そのような順序が存在する場合、シーケンサはそれを選択することができます。強制的な包含は、シーケンサが順序に対して制御を行使するのを防ぐものではなく、彼らの行動を制約するだけです。残念ながら、強制的な包含には根本的な問題があり、多くの取引に対して有効な検閲抵抗メカニズムとなることを阻んでいます。

The Hand-off Problem

強制的な包括メカニズムは、2つのモードのうちの1つで順序付けが行われることを意味します:強制されない場合と強制される場合です。強制されない場合から強制される場合(およびその逆)への移行が定義されています。そのポイントはハンドオフです。ハンドオフは、強制的な包括メカニズムの設計において複雑な問題を提起します。

非強制的な参加から強制的な参加への移行が必要です。

強制トランザクションはハンドオフ時に状態で実行されます。したがって、再び、状態の競合5醜い頭をもたげる。トランザクションのバッチ (ブロックなど) 内でハンドオフが発生すると、バッチの作成者はハンドオフ時の状態を制御できます。強制インクルード トランザクションがパブリック状態を読み取る場合、バッチの作成者は、強制トランザクションの実行の前後にその状態を書き換えることができます。競合は検閲に十分です。

バッチ作成者は、ハンドオフ時に状態を制御できるため、強制トランザクションの結果に影響を与えることができます。結果に影響を与えることができるため、スコアリング述語の結果に潜在的に影響を与えることができます。たとえば、シンプルなAMMインタラクションを考えてみましょう。ユーザーは最低許容価格を設定しますが、バッチ作成者はハンドオフポイントで市場価格を最低許容価格よりも低くすることができます。これにより、ユーザートランザクションがリバートされ、ユーザーが検閲されることになります。67

興味深いことに、排除による検閲よりも、国家の競合による検閲の方が効果的です。除外されたトランザクションは将来のブロックに含まれる可能性がありますが、競合によって検閲されたトランザクションは永久に無効化されます。それはチェーンに含まれており、二度と含めることはできません。そのトランザクションはユーザーの目的を達成することができません。再度試すには、ユーザーはトランザクションを再作成して再送信する必要があります(そして再び検閲される可能性があります)。

実用的なシステム

[A]ny user can bypass the Sequencer entirely to submit any Arbitrum transaction (including one that, say, initiates an L2 to L1 message to withdraw funds) directly from layer 1. Thus [sic] mechanism thereby preserves censorship resistance even if the Sequencer is being completely unresponsive or even malicious.

ランアヘッド・シーケンシング・モデルでは、シーケンサーはシーケンス内のハンドオフの位置をほぼ完璧に制御し、より少ない料金を支払います(チップを渡す必要がなく、EIP-1559の基本料金をある程度制御できるため)。その結果、シーケンサーは、状態の競合を使用してユーザーの操作を検閲する特権的な立場にあります。些細なことです。ハンドオフの問題により、シーケンサーは大きなクラスのトランザクションを検閲できます。

EIP-7547では、ビルダーがブロックのハンドオフがどこで発生するかを選択します。8その結果、ビルダーはブロック内でのハンドオフの場所を選択することができます。これは、彼らが任意にプレフィックスとポストフィックスを選択できることを意味します。9ブロックガスのルールを尊重する限り。接頭辞はチェーンをトランザクションが元に戻す状態にすることができ、接尾辞はチェーンを通常の状態に復元します。EIP-7547 包含リストは、係争状態にアクセスするトランザクションの検閲を防ぐのに十分ではありません。ハンドオフの問題により、ほとんどの場合、IL はトランザクションの実行を保証できません。

強制的な包括は、ブロックチェーンの非自明な用途において、ユーザーを検閲から保護するために効果的ではありません。引き継ぎの問題により、順序に関する十分な裁量権がなくても、検閲者は状態に対して十分な裁量権を持つことが保証されます。この問題は、AMM、貸出市場、オークション、およびその他のほとんどのDeFiアクションに影響を与えます。トランザクションの包括を保証できる場合でも、多くの重要なアクションは検閲可能です。状態の競合は、強制的な包括を検閲抵抗機構としての効果を制限します。

ケーススタディー

これの遠い影響を見るためには、Optimismのレンディング市場でUSDCを貸し出すユーザーを考えてみてください。ユーザーが市場からUSDCを引き出したいとき、彼らはOptimismトランザクションを提出し、そのトランザクションはシーケンサーによって検閲されます。その後、彼らは公式の強制インクルージョンメカニズムを使用して、シーケンサーを迂回してEthereumでトランザクションをキューに入れます。

シーケンサーはキュー内のトランザクションを見ることができ、それをサンドイッチにすることができます。トランザクションを検閲するために、シーケンサーは強制トランザクションの直前に市場から利用可能なすべてのUSDCを借ります。市場にはもはや流動性がないため、強制トランザクションは元に戻ります。その後、シーケンサーはすぐにUSDCを返済することができます。

シーケンサーまたはビルダーは、ハンドオフ時に状態を操作することができます。

これには、シーケンサーがUSDCを借りるために十分な担保を持っている必要がありますが、非常にわずかな借入コストしか課されません。10さらに、担保は、借入が開かれたままになることがないため、すべての検閲に再利用できます。その結果、AAVEまたはCompound on Optimism(またはArbitrumまたはその他の中央配列ロールアップ)のユーザーは、担保を引き出すことができるという保証はありません。シーケンサーは、いつでも貸付市場からの引き出しを検閲できます。強制的なインクルージョンは、ユーザーを検閲から守るのに十分ではありません。

フォローアップ作業

追跡調査の分野はいくつかあります。

まず、EIP-7547は簡単に改善することができます。ILトランザクションを次のブロックの終わりに処理するように要件を追加することです。PBSオークションの文脈では、検閲はMEVです。ビルダーは非経済的な価値を生み出し、それにETHで表される主観的な価値を割り当てる必要があります。ビルダーによる検閲は、ビルダーのブロック入札の増加を引き起こします。11これは検閲バンドルを作成する可能性のある検索者にも適用され、検閲の経済価値の一部は提案者によって捕捉され、直接参加していなくても検閲を容認する動機を提供します。強制的なインクルージョン取引をブロックの最後に配置することで、ブロックビルダーの能力を無効にし、論争のある検閲の経済コストを増加させます。たとえば、状態の争いを通じてAMMの相互作用を検閲することは、AMMの裁定取引を一部放棄するか、市場を範囲外に押し出すために高いコストを支払う必要があり、そのサンドイッチを閉じて回収できない可能性があります。さらに、これにより、ビルダーではなく検索者が1ブロックあたりに生成することができる検閲バンドルが制限されます。12プレフィックスはサフィックスよりも重要ですので、ブロックの一番上での実行をお勧めしますが、これによりILトランザクションのコストが大幅に増加します。この方法では、強制的な含めることによるブロック一番上のMEV抽出が可能になります。13検閲官がILトランザクションに原子的に後置する権利を削除することは、小さな改善です。

第 2 に、検閲者がトランザクション シミュレーションによって先を見越し、入力状態を制御できるため、ハンドオフの問題が存在します。多くのMEV耐性メカニズムは、ユーザーの目標に関する情報を導き出し、結果をシミュレートする検閲者の能力を排除するために、隠された情報を導入します。通常、これらはコミット/公開スキームであり、一部のトランザクション情報は注文が行われるまで非公開です。注文と実行の分離と隠された情報は有望に見えますが、MEVサプライチェーン、イーサリアムのコンセンサスプロセス、およびシーケンスされたロールアップモデルとは大きく互換性がありません。トランザクションをシミュレートする機能を無効にする何らかの方法は、検閲と大規模なクラスのMEVに対処しますが、プロトコル、プロトコルのオペレーター、アプリケーション、およびエンドユーザーにとって非常に侵襲的です。

第 3 に、「順序に依存しない」スコアリング関数という興味深いクラスがあります。これらは、論争のある状態にアクセスしないか、またはアクセスする競合状態が何らかの意味で「信頼できる」ものにするのに十分な制約を持っているため、状態の競合によって検閲できない目標です。順序に依存しないアクションには、ETHをEOAに送信することが含まれ、ほとんどのERC-20送信、14そして、市場への担保の追加など、いくつかのDeFiインタラクション。これらのアクションは、競合による検閲から保護されています。このクラスの目標は、安全なクロスチェーン通信とMEV耐性にも興味深い対応関係があり、より深く研究する価値があります。アプリケーションやプロトコルは、場合によっては順序に依存しないアクションのみを含むように設計されている可能性がありますが、さらなる研究が必要です。

結論

リッチステートは、悪意のあるアクターがトランザクションを含めながら検閲することを可能にします。ハンドオフの問題は、強制インクルージョンメカニズムの基本であり、軽減することしかできません。一元的にシーケンスされたロールアップでは、軽減策は不可能です。強制的な包含は、論争国の存在下での検閲に対処することはできません。経済的に重要な取引の大きなクラスは、たとえ強制的に含まれていたとしても、打ち切られる可能性があります。ハンドオフの問題は、現代のロールアップに特有のものであり、イーサリアムの検閲耐性EIPにも存在します。その結果、強制的な包摂は有益ではあるが、富裕国チェーンに検閲への抵抗力を与えるには決して十分ではない。ロールアップはイーサリアムのセキュリティプロパティを「継承」しておらず、継承すると示唆するのはばかげています。インクルージョンにこだわるのをやめると、検閲への抵抗がMEVへの抵抗の特殊なケースであることが明らかになります。

私たちは感謝したいと思いますマイク・ニューダー, Tarun Chitra、そしてブランドン・カーティスレビューとフィードバック用です。

1

通常、L1 では無効なブロックを拒否することで実現されますが、ロールアップでは、何らかのフィルタリング関数を使用して無効なシーケンスを有効なシーケンスに強制することで実現されます。

2

これは意図についての投稿ではなく、現時点では世界はこれ以上の意図を必要としていません。

3

これは、結果の主観的な値を考慮していないため、明らかに不完全なモデルです。例えば、検閲に失敗した場合、検閲官はいくらでもお金を失う可能性があります(例えば、特定の行動を検閲しなかった場合、フランスの警察に逮捕される可能性があるため)。一方、ユーザーは、特定の時間枠で目標が達成されない場合、任意の金額を獲得/失う可能性があります(たとえば、自分のトークンに対して$ 100mm+のローンを組み、清算される前にポジションを再担保する必要があります)。

4

「ベース」のシーケンサーモデルとは対照的です。最近のほとんどのロールアップでは、シーケンサーは、トランザクションがイーサリアムにコミットされる前に、トランザクションの包含と実行の証明を提供するため、イーサリアムの「先」を実行します。このモデルでは、シーケンサーがシーケンスを完全に制御し、トランザクションの結果はイーサリアムの再編成から独立している必要があります。

5

複数のユーザーが同じ契約、資産、または状態にアクセスする場合、彼らのトランザクションは互いに「競合」し、互いの結果に干渉する可能性があります。競合は偶然に起こるか、意図的に起こる可能性があります。これはブロックチェーンシステムにおけるリッチステートの解決の難しい問題です。共有状態への一般のアクセスは、MEV、スケーラビリティの問題、および現代社会における礼儀の低下の根源です。

6

一般に、国家の争いによる検閲は、MEVの特殊なケースと考えるべきです。抽出された値はオフチェーンであり、観測不可能であり、潜在的に非常に大きいため、国家の競合による検閲がいつ発生するかを予測することは困難な場合があります。

7

私たちは2017年の記事「特に、状態の競合を使用してトランザクションを元に戻す方法について説明しました。」でトランザクションを元に戻すための状態の競合について特集しました。マイナーはあなたの友達ではありません”. 当時、”MEV”という用語はまだ使用されていませんでした。

8

PBSは検閲抵抗を著しく複雑化することがよく知られています。VBの参照をご覧ください。@vbuterin/pbs_censorship_resistance">研究ノート。

9

トランザクションの接頭辞と接尾辞は一般に "サンドイッチ" と呼ばれ、状態の競合を使用して MEV を抽出する方法としてよく理解されています。

10

借り入れはわずか数秒しか保持されません。ロールアップシーケンサーは、効果的な借り入れ時間を0にするために、いくつかの場合にはタイムスタンプやブロックの境界を保持することがあります。

11

ビルダーは、検閲の主観的な価値まで支払いをする意思があり、それによりブロックの客観的に観測可能な抽出可能な価値を上回る入札が生じる可能性があります。極端な場合、これにより検閲者のETH残高の変化がマイナスになることがあります(つまり、ブロックの作成にETHを支払い、手数料や報酬で受け取るETHよりも多く支払うことになります)。

12

これは、異なるバンドルからの交互にトランザクションを禁止し、「必ず失敗する」トランザクションを許可しないMEVオークションルールに依存していることに注意してください。これらのルールが緩和され、バンドルトランザクションを交互にできるようになった場合、および/またはビルダーがバンドル内の「必ず失敗する」ブロックをサポートし始めた場合、保護は消失する可能性があります。この動的は、ILトランザクションがブロックの最後になければならない場合、非強制トランザクションを交互にすることができず、したがって最大1つのサーチャー検閲バンドルが発生する可能性があるためです。

13

ビルダーが限定的なブロック間バンドルを効果的に作成できるようにします。次のような事前コンセンサスシステムFOCILこれをmitiGateできました。

14

標準的なERC-20トークンの場合、第三者がユーザーの残高を減らすことができないため、通常、転送呼び出しは競合によって検閲できません。ただし、transferFrom 呼び出しについて考えてみます。承認された譲渡者が、独自の状態での競合を許可する契約である場合、アクションは、その競合によって検閲される可能性があります (意図しない方法で transferFrom に必要な承認を消費します)。

免責事項:

  1. この記事は[から転載されています技術], All copyrights belong to the original author [init4の]. この転載に異論がある場合は、お問い合わせください。Gate Learn(ゲート・ラーン)チームがすぐに対処します。
  2. 責任免除声明:この記事に表明された見解や意見は、著者個人のものであり、投資アドバイスを提供するものではありません。
  3. この記事の翻訳はGate Learnチームによって行われています。特に言及されていない限り、翻訳された記事のコピー、配布、または盗作は禁止されています。
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!
It seems that you are attempting to access our services from a Restricted Location where Gate.io is unable to provide services. We apologize for any inconvenience this may cause. Currently, the Restricted Locations include but not limited to: the United States of America, Canada, Cambodia, Cuba, Iran, North Korea and so on. For more information regarding the Restricted Locations, please refer to the User Agreement. Should you have any other questions, please contact our Customer Support Team.