原題：「
この記事は WeChat 公開アカウント Old Yuppie からのものです。
この記事は WeChat 公開アカウント Old Yuppie からのものです。
導入
導入
検閲はイーサリアムの価値と互換性がありません。
私たちは過去 1 か月ほど、どのようにしてここにたどり着いたのかを考えるのに十分な時間を費やしてきました。この問題をどのように解決するか、今後の方向性について話し合います。
開発者は何をすべきでしょうか?
検閲と正面から戦うことが最優先事項であるべきだ。売却もできるだけ早く解決する必要があるだろう。
ただし、スケーリングなどの問題は後回しになる可能性があります。イーサリアムは多少高い手数料には耐えられますが、検閲には耐えられません。 EIP-4844、Danksharding、その他のアップグレードは複雑で、多くの時間と注意力を奪う可能性があります。本当に必要な場合、EIP-4488 は非常に迅速かつ効率的に実装できます。
検閲への抵抗を優先することは、コミュニティの価値観を示す最も明確な方法です。そうしないと、信頼性を損なう可能性のある非常に悪いシグナルになります。コアプロトコルの開発がそれを行わないのに、なぜバリデータ、Flashbot、またはその他の中継者/構築者が抵抗を優先する必要がありますか? 検閲はどうですか?
MEV-Boost
さらに、今は弱気市場であり、誰もが貧しいか逃亡中です。手数料は許容範囲内です。
アーキテクチャの簡単な概要から始めましょう。
MEV の捕捉には高度な技術が必要です。バリデーターにこのタスクが与えられた場合、バリデーターは集中化され、MEV を抽出できる成熟したバリデーターのみが競争力のある報酬を獲得できるようになります。 Proposer-Builder Separation (PBS) は、最適なブロックを構築するための新しい専用の「ビルダー」ロールを作成することで、この問題を解決します。次に、ビルダーは提案者 (バリデーター) に入札してブロックを受け入れます。提案者になるのはまだ簡単で、競争力のある報酬を獲得できる = 分散型を維持します。
PBS は最終的にはプロトコルに組み込まれる予定ですが、まだ準備が整っていません。ただし、PBS はすでに存在しています。MEV-Boost は現在、プロトコルの外への足がかりです (追加の信頼の前提にもかかわらず)。これは、バリデーターがアウトソーシングされたブロック構築をクエリするために実行できる追加のサイドカー ソフトウェアです。バリデーターは、独自の実行クライアントを使用してブロックをローカルに構築するオプションを引き続き保持しています。
多くの MEV 検索者は特定の戦略を実行し、バンドルに含めるビルダーに入札します。ビルダーは、これらのバンドル + 他のプライベート注文ストリーム + パブリック メモリプール トランザクションを集約し、最適なフル ブロックを構築できます。一部のビルダーは、検索を内部化し、自分自身でこの役割を引き受けることもできます。
リピーターの概要
中継者は、提案者と構築者の両方が信頼する仲介者です。彼らはビルダーのブロックを受け取り、提案者に送信する前にエスクローします。特定のリレーラーの場合、プロセスは次のようになります。
設計目標
MEV-Boost は、MEV-Geth の 2 つの主要な欠点に対処します。
1. ソロステーカーの参加
PoW マイナーはバンドルを受け取り、これらのバンドルを最上位に置く完全なブロックを作成します。フルブロックが送信されることはありませんでした。 Flashbot は、OFAC ブラックリストに登録されたトランザクションをバンドルに含めることはありませんでしたが、マイナーはブロック内の他の場所にトランザクションを含めることができるため、それは問題ではありません。
このスキームは、マイニング プールの運営者を信頼することを意味します。彼らはこれらのバンドルを明確に見ることができるため、必要に応じてこれらの機会を直接盗むことができます。この信頼は、イーサリアムバリデーターの大規模なセットには対応しません。これが、MEV-Boost が提案者に完全なブロックを提供する理由です。提案者は、ブロック本体が公開される前に、ブロック ヘッダーに署名して送信します。ブロックの本体を見た後に MEV スティールを試みる場合は、別のブロックを提案する必要があります。オリジナルの署名が提示され、提案者は重複した署名のために切断されます。
このフルブロックのアプローチにより、バリデーターの分散化が可能になりますが、中継者/構築者レベルでの重大な検閲リスクが追加されます。バリデーターが検閲中継者からのブロックを受け入れると、事実上の検閲者になります。
レビュー構築者が最も収益性の高い構築者である場合、提案者は次の 2 つのうちの選択を迫られます。 :
経済合理性 - たとえ検閲されても、最も価値の高いブロックを受け入れる
利他主義 - 価値の低いブロックを検閲なしで受け入れる
理想的には、利他的な仮定は完全に削除されるか、可能な限り最小限に抑えられるべきです。
2. 顧客の多様性
ほとんどのマイナーは Go Ethereum (Geth) クライアントを実行していたため、Flashbot は単純にそれをフォークして MEV-Geth を作成しました。これを実行することが、Flashbots オークションに参加する唯一の方法です。 PoS は顧客の多様性を高める機会です。 MEV-Boost サイドカーは、すべてのコンセンサス クライアントおよび実行クライアントと相互運用可能です。
MEV-Boost はインフラストラクチャに中立です。
中継器 - あらゆる制約やポリシー (検閲/非検閲、「公正な」注文/最大利益など) の下で自由に運用できます。中継者は希望に応じてビルダーからのブロックを受け入れることができます。
ビルダー - 好きな戦略を自由に実行し、ブロックを受け入れてくれる信頼できるリレーラーに展開することができます。
MEV-Boost は、OFAC トランザクションやサンドイッチ トランザクションをレビューしません。これにより、提案者は、自分に合った中継者から選択して、ビルドをアウトソーシングできるようになります。
レビュー
レビュー
私のレビューに関する議論の枠組みは次のとおりです。
弱いレビュー = 遅れたが最終的には含まれる。バリデーターの 50% に OFAC トランザクションが含まれていない場合、それらは平均して 2 ブロック (24 秒) 後に含まれます。 90% の検閲では、10 ブロック (120 秒) 後に含まれるなどとなります。
厳格な検閲 = 検閲されたトランザクションはオンチェーンに含まれません。 Gasper では、これにより、バリデーターの 51% が自身のブロックの OFAC トランザクションを検閲するだけでなく、それらを含むすべての新しいブロックを積極的に無視する必要があります。
バリデーターには検閲の差し迫った脅威はないようです。 OFAC取引を審査する義務はないとの立場をとっているようだ。これは、必要に応じてユーザーがアクティブ化したソフト フォークまたはスラッシュによって解決できますが、ここではそれが私の主な焦点ではありません。
差し迫った検閲の脅威は、中継者/建設者のレベルにあります。これは主に、最大規模のリピーターやビルダーを実行する Flashbot からのものです。ただし、他の中継者も検閲を行っています。彼らは市場シェアが低いだけで、次のようなものがあります。
Blocknative
Eden Network
bloxRoute「監視型」リレーラー
非検閲リピーター:
bloxRoute「利益最大化」中継者
Manifold Finance
bloxRoute の「倫理」リレーラー
このレベルの脅威を軽減する方法に焦点を当てます。
バリデーターは何をすべきでしょうか?
ずいぶん前にこのスレに書きましたが、最近またこのことを思うようになりました。私は今でも同様の感覚を持っています。MEV-Boost を実行するのが最善だと思いますが、検閲されていないリピータでのみ実行してください。
正直に言うと、私がバリデーターだったら、MEV-Boost をまったく実行したくないです。 Flashbot は最も信頼できるライブ リピーター/ビルダー オペレーターであるため、一部を使用することに抵抗があります。しかし、検閲を積極的に推進することは有害です。
したがって、個人クライアントを実行するのは素晴らしく簡単に聞こえますが、他の検閲されていないリレーラーで MEV-Boost を実行する方が良いと思います。そうしないと、採用率が低くなり、負の外部性 (PGA など) がもたらされることになります。さらに、それを実行するバリデーターは、そうでない利他的なバリデーターよりも多くの収入を得るでしょう。彼らは、利他的なバリデーターを排除するのに十分な期間にわたって体系的に市場シェアを拡大します。
MEV を無視してもこの問題は解消されません。以前にもそのような状況が発生したのを見てきました。
Flashbot リレーラーの採用率が低いということは、精査が少ないことを意味する可能性があります。執筆時点 - MEV-Boost の採用はバリデーターの 42% を占め、Flashbot は MEV-Boost ブロックの ~60% を構築しています = イーサリアム ブロックの ~25% はそこで検閲されています。 MEV-Boostの採用も着実に増加しています。現在、他の中継者からの監視はほとんどありません（意味のある市場シェアを持っていないだけです）。
実際のところ、私は「検閲が少ない」ことが違いを生むとは思わない。検閲率が 20% 対 40% 対 60% の場合、それらの OFAC アドレスは検閲され、待機する必要があります。検査率が上がればもう少し待つだろう。
ただし、シグナリングの観点からは非常に重要だと思います。イーサリアムは、この行為が私たちの価値観に合致しておらず、容認されないことを世界に伝える必要があります。
協定は何をするのでしょうか?
残念ながら、上記の「Flashbot リレーラーを使用しない」という解決策は、提案者の利他性に依存しています。 Flashbot が最も価値のあるブロックを構築した場合 (通常はそうします)、バリデーターは収益を減らすために積極的にブロックを使用しないことを選択します。検閲されたブロックを喜んで受け入れるバリデーターは再び比例した市場シェアを獲得することになり、意味のある利他主義は単純に持続可能な長期戦略ではありません。より良いプロトコル設計が必要です。
安置された PBS と crList
PBS がプロトコルに組み込まれると、リピーターはなくなります。ビルダーはプロトコル内オークションを通じて提案者と直接対話します。建設業者は無条件で支払うことを約束し、信頼の必要性を排除します。提案者は、ビルダーによって送信されたブロックヘッダーに署名すると、関連する入札を取得できます (その後、ビルダーが無効なブロック本体を開示するか、完全に保留した場合でも)。
crLists はこの機能をチェックします。正確な実装はオープンな設計空間ですが、ここでは「ハイブリッド PBS」の簡略化した概要を示します。提案者は、ビルダーが (ブロックがいっぱいでない限り) 含めることを強制されるメモリプール内にあるすべての適格なトランザクションのリストを指定します。
提案者は、すべての適格なトランザクションを含む crList と crList のダイジェストを公開します。
ビルダーは提案されたブロックを作成し、それを見たことを証明するために crList ダイジェストのハッシュを含む入札を送信します。
提案者は落札者の入札とブロックヘッダーを受け入れます（ブロック本体はまだ見ていません）。
ビルダーはブロックを公開し、crList からのすべてのトランザクションが含まれていること、またはブロックがいっぱいであることの証明を含めます。そうしないと、ブロックはフォーク選択ルールによって受け入れられません。
オーセンティケータは、発行されたプリンシパルの有効性をチェックします。
実際には、PBS を祀る前に crList の一部のバージョンを実装することもできますが、見た目は異なります。 Flashbots の Quintus からの提案です。 PBSを安置する前に、crListを置き換える提案も進行中です。何らかの形式の包含チェックリスト、おそらく最小限の形式の安置 PBS を優先する必要があります。ここでさらなる提案をお待ちしています。
バルナベ氏も同様のアイデアを提案しています。基本的に、提案者はブロックのプレフィックスを作成して他の打ち切りトランザクションを最上位に含めることができ、その後、ビルダーが残り (または含める打ち切りトランザクションがない場合はブロック全体) を構築できます。
EigenLayer を使用した MEV-Boost によるブロック プロポーザー プロキシの保持
別のメソッドは、トランザクションをアタッチするために提案者のプロキシを返します。このスキームは、EigenLayer を利用して MEV-Boost を強化し、それによって検閲耐性を高めます。
EigenLayer は「再発明された」コレクションで、来年後半に公開される予定です。 EigenLayer にオプトインした Ethereum バリデーターは、バリデーターの引き出しアドレスを EigenLayer スマート コントラクトに設定することにより、追加のスラッシュ条件の対象となります。
このプロトコルは、EigenLayer 上に許可なくデプロイでき、これらのバリデーターが同じステークで (イーサリアムに加えて) 独自のソリューションを保護することを選択するよう奨励しようとします。バリデーターは、選択した任意の EigenLayer アプリケーションにオプトインします。アプリケーションのルールに違反すると、削除される可能性があります。これにより、他のプロトコル (新しいクロスチェーン ブリッジ、データ可用性レイヤー、またはその他のもの) がイーサリアムの経済的に安全なサブセットを直接活用できるようになります。
では、これは MEV-Boost にどのように適用されるのでしょうか?この構造を選択した参加者は次のことを行いました。
提案者はEigenLayerでETHを再ステークする
ビルダーは、ブロック (builder_part) を、含まれるトランザクションの Merkle_root とその入札とともにリレーラーに送信します。
リレイヤーはトランザクションを保存することでデータ可用性 (DA) を提供します。 Relay は merkle_root を送信し、最も収益性の高い有効なブロックを提案者に入札します。
提案者は、接続されているすべての中継者から最高入札額を選択します。
提案者は独自のバックアップ代替ブロック B_alt をローカルに構築します
プロポーザーは、落札者の merkle_root に証明書を送信し、コミットされた commit_B_alt (ブロック ヘッダーではなく、トランザクション ルートの場合もあります) に接続し、それを独自のブロック B_alt に送信します。
リレーラーは、基礎となるトランザクションを含む builder_part を明らかにし、それをプロポーザーに送信します。
プロポーザーは、builder_part を含む新しいブロックを構築し、追加の Proposer_part を追加します (含めたい他のトランザクションがあり、ブロックにスペースがある場合)。中継者が基礎となるトランザクションの解放に失敗した場合、ブロック提案者は構築したブロック B_alt を提案します。
プロポーザーが B_alt 以外のブロックを提案する場合、プロポーザーは builder_part を含める必要があります。そうでない場合、ブロックは、EigenLayer によって切り取られます。これは、遵守しなければならない追加の条件です。これにより、提案者を信頼する必要がなくなります。基礎となるトランザクションを確認した後で MEV を盗もうとした場合、B_alt 以外のブロックを提案する必要があり、スラッシュされます。
これにより、提案者はブロック構築をアウトソーシングして、精査されたトランザクションを付加しながら利益を最大化することができます。提案者はもはや利他主義か経済合理性のどちらかを選択する必要はありません。
最も収益性の高い建設者がレビューを行っており、提案者にレビューの義務がない場合、主な戦略は、この EigenLayer 構造にオプトインすることです (追加の責任と EigenLayer スマート コントラクトのリスクを受け入れることができると仮定して)。このようにして、最高価値のブロックを受け入れることができ、追加のトランザクションを追加することで収益性を高めることができる可能性があります。
builder_part は、ブロックの一部だけになる場合もあれば、ブロック全体になる場合もあることに注意してください。仮に 3,000 万ガスすべてが使用された場合、当然、それが含まれるという保証はありません。ただし、EIP-1559 により、ほとんどの場合に利用可能な予備スペースが確保されます。
あなたが知っている悪魔 vs. あなたが知らない悪魔
Flashbot がオフになっていると仮定します。ご存知のとおり、悪魔は阻止されました。おそらくほとんどの監視はなくなるでしょう。いいですね？
しかし今、あなたが知らなかった悪魔が現れるかもしれません。埋める必要のある権力の空白があり、他のビルダーがそれを埋めるでしょう。私たちが直面するリスクは、別のビルダーが単純に王位を奪い、支配的なビルダーとしての地位を固めてしまい、より大きな損害を与える可能性があることです。
私の意見では、これが起こる最大のリスクは排他的注文フロー (EOF) にあります。
ビルダーは、特定の注文が自分たちにのみ送信されるようにすることができます (たとえば、以前のユーザーには送信しないことを約束し、後の利益にはリベートを与えるなど)。この初期の例をいくつか見ることができます。その後、より高い入札を行い、より多くのブロックを獲得し、より多くの独占的契約を証明することができます。
集中型のブロック ビルダーは大混乱を引き起こす可能性があります。
家賃
競争市場により、家賃の搾取は最小限に抑えられます。ユーザーは提供する価値に対して公正に報酬を受け取り、建設業者は残りの MEV を提案者に入札します。これまでのところ、状況は良好に見えます。建設業者は市場シェアを争っており、捕獲されたほぼすべての MEV をバリデーターに入札しています。比較的支配的な Flashbot でさえ、すべての利益をバリデーターに渡します。
EOFはその逆です。有力な建設業者には、家賃を引き出す動機が与えられています。彼らは、他の建設業者が獲得できる金額よりも高い値を付ければよいのです。 EOF が増えると、他のビルダーとのこの差が広がります。
たとえば、ウォレットはビルダーに EOF を送信します。これは、ビルダーに十分な報酬が支払われているためです。しかし現在、ビルダーはますます大きくなり、ほぼすべてのイーサリアムブロックを構築しています。その後、手数料のリベートを削減します。ウォレットは EOF を撤回し、別の場所に移動したいと考えています。ただし、他のビルダーに送信するということは、ブロックを含めるまでの待ち時間が信じられないほど長いか、ブロックを完全に獲得できないことを意味します。ビルダーが出金を続けている間、ウォレットはスタックします。
レビュー
レビュー
まず第一に、crList のような派手なものはリアルタイムではありません。今日、ウェブは特に検閲に対して脆弱です。
以下の例では、市場が 2 つのビルダーのみで構成されていると仮定します。
B₁ = 検閲に強いビルダー
B₂ = 検閲権を持つ建設者
B₂ が今日大幅な市場シェアを獲得した場合、意味のある弱い検閲を実施する可能性があります。そして私たちはそれを目の当たりにしました。ただし、これは強力な検閲ではないことに注意してください。
合理的なバリデーターを備えた完全な競争市場は、いかなる状況下でも弱い検閲を防ぎます。最適なネットワーク条件では、他の条件が等しい場合、入札 B₁ ≧ 入札 B₂ となります。どちらもパブリック メモリプール トランザクションを含めることができますが、B₁ のみ OFAC トランザクションも含めることができます。したがって、競争力のある PBS は、建設業者が想定している検閲に対する耐性が 1/N しかありません。
もちろん、これは現実ではありません。建設業者は注文フローとアルゴリズムが異なるため、入札額も異なります。しかし、これは私たちが競争市場を目指すべき理由を明確に示しています。 B₂ が EOF またはその他の理由により市場シェアを過度に支配している場合、意味のある精査を行うことができます。
彼らが最も価値のあるブロックを構築し続ける場合、検閲を回避するために効果的なバリデーターの利他主義に依存していることになります。できれば、検閲されたリレーラーを無視し、検閲されていないビルダーからのブロックを提供するリレーラーにのみ接続するようにしてください。しかし、これは長期的には持続可能ではない可能性があります。正直なバリデータであるためのコストは ~0 まで削減される必要があります (または、理想的には検閲を受けない方が収益性が高くなります)。
crList はこの可能性を完全に排除するわけではないことに注意してください。 B₂ が常に最も価値のあるブロックを生成する場合、OFAC トランザクションを含む crList をブロードキャストする提案者は、最も収益性の高いブロックを受け入れることができないことを知っています。経済的に合理的な決定は、空の crList をブロードキャストすることです。ただし、市場競争により入札 B₁ と入札 B₂ の差が無視できる場合 (たとえ B₁ が有利な場合でも)、バリデーターが crlist を公開すると考えるのが合理的です。
EOF は検閲抵抗に対して重大な脅威をもたらします。EOF は、バリデーターに誠実な行動と経済的に合理的な行動のどちらかを選択させる可能性があります。これにより、誠実な行動が妨げられ、レビュー参加者は市場シェアの増加を通じてより高い報酬を獲得できるようになります。これは避けるべきです。
ビルダーによるイノベーションの減少
PBS は、ビルダーが革新的な新機能 (アカウントの抽象化、事前確認など) を提供する機会です。
競争力のあるビルダーは、ユーザーの OF を引き付けるために機能を革新することが奨励されます。強固な基礎を備えたビルダーはそうではありません。たとえ別のビルダーがより優れた機能を提供し始めたとしても、切り替えコストが高すぎるか、単に達成不可能である可能性があります (トランザクションを含めるのに非常に長い時間がかかる、ブロックを獲得できない、PFOF トランザクションなど、他のビルダーにとっては)。
優れた関数により OF≠PFOF が得られることに注意してください。
優れた機能により OF を取得 - 参入障壁は新機能の提供です。
PFOF - 参入障壁は明示的な支払いであり、ユーザーは長時間待つ必要があり、契約に違反する可能性もあります
簡単に言えば、ここでの PFOF は独占性を意味しますが、その機能はそうではありません。一部のビルダーが EOF と引き換えに望ましい機能のみを提供した場合、これは PFOF と同様に望ましくないものになります。
EOFについてはどうですか？
ここでは深くは説明しませんが、考えられるルートの 1 つは、オーダー フロー オークションを実行することです。実際、ユーザーの注文を執行する権利を求めてオークションが開催されることもあります。彼らは、MEV の作成に対して公正な価値を獲得し、良好な実行保証を獲得します。公開オークション、または手数料エスカレーションの形で非公開オークションを行うことができます。
分散型ビルダー
ここでの基本的な考え方は、優勝ビルダー自体を分散型プロトコルにすることです。これは、ビルダーの集中化の脅威に対抗する非常に興味深い設計空間です。
分散型ビルダー マーケットプレイスが注文フローを安全に共有する方法については、より広い設計スペースもあります。
Flashbots のホームページに記載されている目標は次のとおりです。
私たちは、ユーザーに権限を与え、パブリック ブロックチェーンの分散化を最大限に高めるために、分散型ブロック構築ネットワークを構築しています。
フラッシュボットは何をするのですか?
Flashbots が現在、他のビルダーにキーを渡すことに躊躇していることは理解していますが、そこにいる人々は善意を持っていると私は信じています。前述したように、他のビルダーの中には、より疑わしい動機を利用して自分たちの立場を強化し、ネットワークにさらなる損害を与えようとする人もいるかもしれません。これは明らかに望ましくないことです。分散型ビルダーに有利な点から操作するよう促す方が簡単かもしれません。
しかし、Flashbot は検閲を行います。そして、適用される規制はまだ少し不明確ですが、それは問題ではありません。 Flashbot の継続的な運用 (検閲を含む) が、そうでない場合よりも大幅に優れた結果をもたらす場合、Flashbot は長期的にはイーサリアムにとって最大の利益となるでしょう。この精査はレーダー上のほんの一瞬かもしれないが、前述のアイデアが具体化され実現されるにつれて、来年かそこらで消え去るだろう。
そうは言っても、私個人としては、将来他の人が検閲を行うのを防ぐことを期待して、検閲を決定的に正当化するのは難しいと感じています。
ビルダーをオープンソースにして市場をリードする
論理的な次のステップは、できるだけ早くビルダーを (やはり AGPL の下で) オープンソース化することです。これは建設業者にとって市場参入の障壁を下げる重要なステップであり、主に建設業者の意図を示すものとなるでしょう。これにより、短期的な競争上の優位性よりも、エコシステムの健全性が直接優先されることになります。
研究
研究
Flashbot の研究は、分散型ビルダー、インクルードリスト、共有注文フローなどの検閲問題の解決に引き続き焦点を当てるべきです。これらは Flashbot の定められた目標です。
しかし、これを外部の視点から見るのは難しいです。現在、イーサリアムネットワーク全体が大規模に検閲されているかどうかを事実上判断しているのはほんの一握りの人々だけです。実績や掲げた目標に関係なく、この活動に取り組んでいる企業を支援することは、ほとんど合理化できません。
この研究に関して大幅な進歩を遂げ、短期的には公開し続ける必要があります。
リピータの操作
正直に言うと、リピーターについては何度も考えました。リピーターはそれを実行すべきでしょうか?ヴィタリック、ジャスティン・ドレイク、フィル・ダイアン、ザキ・マニアン、フランチェスコ・ダマトに聞いてみた。
Vitalik 氏は 1 つの選択肢を繰り返し述べました。Flashbot は、中立的な研究機関を企業運営体から分離する可能性があるということです。これにより、研究における利益相反が排除され、運営者の動機を疑う必要がなくなりました。私たちは、彼らがこの分野の他のほとんどの人々と同様に、自分たちのために働いていることを理解しているだけです。これのマイナス面は、研究部門と製品部門が協力して有意義な進歩を生み出す正のフィードバック ループを構築し、その一部を失うリスクがあることです。 MEV-Boost は当初研究として実行され、後に製品側で実装されたことがわかりました。
単純に中継器の稼働を停止しただけでは、問題は完全には解消されません。検閲率は下がるかもしれないが、他のレビュー中継者がその穴を埋めるかもしれない。時間の経過とともに、検閲の予期せぬ新たな脅威が現れる可能性もあります。 Flashbot がリレーラー/ビルダーとして参加すると、MEV-Boost の全体的な導入に 2 つの影響があります。
導入の増加 - 信頼できるサービスプロバイダーとしての Flashbot の存在により、限界的な導入が増加します。しかし、時間の経過とともに、他の中継者や建設者が問題を解決するにつれて、この利点は先細りになる可能性があります。重要なことは、Flashbot はこれを実現するために積極的に取り組むことができ、可能な限りあらゆる方法でサポートする必要があるということです。
彼らがリレーラーを実行し続けるつもりなら、最終的にはある時点でバリデーターの割合に上限を課すことは理にかなっているはずです。繰り返しになりますが、実際にはどちらにしても、検閲は弱いです。しかし、それでも 1% のレビューと 99% のレビューではシグナルに大きな違いがあることがわかります。これは、検閲された Ethereum ブロックの割合が上昇し続け、これを軽減するための新しい変更が実装されない場合に最も必要になります (crLists、EigenLayer 提案など)。
最終的な考え
最終的な考え
ここで Flashbot について言及したのは、主にいくつかの理由からです。これらは確かに検閲の主要な原因ですが、イーサリアムのエコシステム内で驚くほど多くの活発な作業も生成します。さらに、彼らが中立的なコミュニティ構築者と従来の企業運営者の間に立つのであれば、エコシステムに対して重大な責任があると私は信じています。結局、頭がいいからカッコいいものが生まれるのかもしれない。
元のリンク
IOS
Android