リレーの取り外し方法
MEV-Boostは、イーサリアムにおけるMEV抽出のための現在のサイドカープロトコルであり、中央集権的なリレーと呼ばれるアクターに大きく依存しています。
ビルダーと提案者の間で直接的で暗号化されたプライベートな通信が可能な代替アーキテクチャを提案します。これは、バリデータの既存のBLSキーペアを使用できる、新しい非インタラクティブな形式の「silent」しきい値暗号化に基づいています。
基本的に、スロットのための証明委員会に乗っ取り、プライバシーとデータの利用可能性を閾値暗号化してブロック提案を一部の証明者に乗っ取ります。彼らの証明は復号化キーを形成し、望ましい閾値が証明されたら、ブロックを復号化できます。
私たちの構築物は建設者と提案者のプライバシーを対象としていますが、単独ではブロックの正当性を保証するものではありません。プライバシーとブロックの正当性の両方を提供する機能を完全に再現するために、他のメカニズムと組み合わせることができます。例えば、Trusted Execution Environment（TEE）プルーフやZero-Knowledge（ZK）プルーフなどの証明スキーム、または建設者の担保とする暗号経済学的メカニズムがあります。
リレーが建設者のプライバシーを提供し、ブロックの有効性を確保する必要をなくすことで、遅延を減少させ、Ethereumの分散化と検閲耐性を向上させることを目指しています。
MEV-Boostとリレーの役割
MEV-Boostは、ブロックビルダーとプロポーザーの間を仲介するサイドカープロトコルです。メインの役割リレーの役割は2つの保証を提供することです。
- ビルダー向けのプライバシー：リレーは、提案者がブロックの内容を見ることができず、ビルダーが見つけたMEVを盗むことができないようにします。
- 提案者の安全性：リレーは、ビルダーが提案者に約束した値を支払い、ブロックが有効であること（すべてのトランザクションが固有のガスを支払うなど）を保証します。
リレーへの依存は、ただし、重要な中央集権を導入します。 Ethereumのブロックの約90%が、わずか数のリレーを介して提供されます。 これにはいくつかのリスクが伴います:
- 中央集権化：ビルダーは、提案者の地理的な分散を反映させる代わりに、リレーと共有することでレイテンシーを効率的にすることができます。これは、大規模でグローバルに分散したバリデータセットから得られる地理的な分散化と検閲耐性を直接的に損ないます。
- 収益：効率的な中継のエンドツーエンドのブロック処理の平均遅延は約5〜20ミリ秒です。その後、提案者とビルダーの間に通信遅延があります。中継をスキップすると、遅延が減少し、クロスドメインの実行リスク（例：CEX/DEX）が低下し、提案者のMEV報酬が最終的に増加します。
TEE-Boost
リレーを置き換えるための主要な提案の1つは、“TEE-Boostこれは TEE (Trusted Execution Environment) に依存しています。TEEは私たちのスキームに必須ではないことに注意してください。TEE-Boostは、私たちが解決しようとしている問題の教育的な例として役に立ちます。
具体的には、TEE-BoostはビルダーがTEEを使用して、実際のブロックの内容を提案者に公開せずに、入札の正当性とブロックの有効性を証明する証拠を作成するようにします。提案者は、これらの証拠をTEEを実行せずに自身のコモディティハードウェア上で確認することができます。
しかし、TEE-Boostにはデータ可用性の問題があります:ビルダーはTEEプルーフとブロックヘッダーを提案者とのみ共有し、実際のブロックコンテンツは共有しません。[1]そして、提案者がヘッダーに署名した後でも、ブロックの内容を公開しないことを選択する場合があります（例えば、市況が不利に変わった場合）。このDA問題を解決するための提案された手法は次の通りです:
- [ ] TEE-Escrow: TEE-エスクローは、提案者が署名する前にビルダーからブロックを取得し、署名されたヘッダーを見るとリリースされます。
- [ ] データ可用性レイヤー：ビルダーは暗号化されたブロックペイロードをデータ可用性（DA）レイヤーに投稿します。
両方のアプローチには欠点があります。 TEE-エスクロー解決策は、既存のリレーと同様の集中化の遅延動態を再現します。[2]外部のDAレイヤーを使用すると、外部プロトコルの遅延ダイナミクス（これも不利な可能性があります）を導入するため、プロトコル外の仮定が発生します。
理論的には、提案者も TEE にアクセスできる場合、ビルダーは提案者によって実行される TEE に対してブロックを暗号化できます。提案者のTEEは、ブロックに署名した後にのみブロックを復号化します。ただし、TEE-Boostは、提案者(バリデーター)がTEEを実行する必要があるため、この設計を考慮していないと考えています。私たちは、バリデーターがコモディティハードウェア上で実行できるようにしたいと考えています。↩
レイテンシダイナミックは、提案者自体がバリデータノードのサイドカーとしてTEEEscrowを共有配置することで回避できます。ただし、再び、バリデータがTEEsを実行することは望ましくありません。↩
ビルダープライバシーを実現するための閾値暗号化
TEE-BoostのDA問題に優雅な解決策を提案します：アテスタ委員会への閾値暗号化。具体的には、ビルダー閾値がそのスロットのアテスタ委員会の指定された割合にブロックを暗号化します。十分な証明書が集まると、ブロックは復号可能になります。
コアの有効化技術はサイレントしきい値暗号化この暗号技術により、以前の構築物が必要とした対話型分散キー生成（DKG）セットアップフェーズを必要とせずに、しきい値暗号化を可能にします。代わりに、共同公開鍵は、証明者の既存のBLS公開鍵にいくつかの「ヒント」（後で説明します）を加えて、決定論的に計算されます。
これにより、ビルダーとバリデーター間で直接のシングルホップ通信が、暗号化されたプライバシーを持って実現されます。バリデーターは、自身でTEEを実行したり、新しいキーマテリアルを管理する必要はありません。
メカニクス：
ビルダーはブロックを構築し、それを証明者委員会に暗号化します。
ビルダーは、入札が正直であること、ブロックが有効であること、および正しく暗号化されていることをアテスタ委員会に証明するTEE証明を構築します。
ビルダーは、しきい値の暗号化されたブロックとTEEプルーフ（入札値を含む）を提案者に通信します。[3]
提案者は、勝利したビルダーの暗号化されたブロックに署名し、この提案をバリデータセットに広めます。
指定された分数（例：n/2または2n/3）のn-証明者委員会がスロットを証明した後、ブロックは復号化されます。
複合されたブロックは通常通り最終化されます。
- 提案者の帯域幅要件に与える影響は調査する必要があります。低帯域幅の提案者は、ブロック本体をリクエストする前に証明を検証する、または他のヒューリスティックフィルタリングやスマートダウンロード技術を使用することで、ニーズを制限することができます。これはオープンな問題ですが、通常のメンプールゴシップスパムの問題よりも解決するのがより難しいとは思われません。↩
考慮事項
パフォーマンス
サイレントスレッショルド暗号のパフォーマンス特性は非常に好ましいです。ここで
nは、サポートしたい委員会の最大サイズであり、tは復号のための閾値です。
暗号化と部分的な復号はどちらも一定時間です。単純な実装では、暗号化には7ms以下かかります（並列化可能）。部分的な復号には1ms以下かかります。
暗号文のサイズは、平文よりも大きく、定数の加法因子である768バイトです（任意のnとtに対して）。
部分復号の集約（すなわち、復号）は委員会のサイズに依存します。n=1024の場合、素朴な実装には<200msがかかります。n=128（各スロットの証明委員会のサイズ）の場合、これは10分の1になり、さらに実装を最適化できると予想されています。
重要なのは、暗号化時間がリレーの遅延と比較するための主要なパフォーマンス指標であることです。これは、ビルダーがブロックの生成の「クリティカルパス」で計算しなければならないものです。これは既存のリレーのブロック処理遅延よりも低く、多段階通信を避けます。
データ公開
サイレントしきい値暗号化は完全に無料ではありません。形式の共通参照文字列が必要です：(g,gτ,gτ2,...,グラムτn−t)、KZG多項式コミットメントスキームで使用されているものと類似しています。
また、形式gskのBLS公開鍵を持つすべての検証者は、私たちが「ヒント」と呼ぶグループ要素のセットを公開します：（gsk⋅τ,...,グラムsk⋅τn−t). これらのヒントは、公開鍵を集計し、暗号文を復号化するためにのみ必要です。暗号化は定数サイズの集計された公開鍵のみを使用します。
この記事を書いている時点で、約100万人のバリデーターがいます。n=128 と t=n/2 を設定した場合、各バリデーターは 3 KB ≈ヒントを投稿する必要があります。したがって、すべてのバリデータのヒントを保存するには、3GBが必要です。
この要件はおそらく大幅に減少するでしょうMaxEBの活性化これにより、>32ETHを管理するバリデーターは、(複数の32ETHデポジットに分割するのではなく)同じキーペアでより大きな残高を保持することができます。実現されるバリデーターセットの削減については議論の余地があります。~1GBまで下げられる可能性はあるようです。
最後に、イーサリアムの合意アーキテクチャの将来の変更（例：バリデータセットサイズのさらなる削減、または代替の確定性パイプライン）に応じて、保存する必要のあるヒントのサイズがさらに減少する可能性があります。
リブネス
Ethereumは、不利なネットワーク状況でも生き続けたいと考えています。この方式の1つの問題は、委員会の指定された割合がオフラインになっているために解読できないブロックの可能性です。
1 つの解決策は、ビルダーが復号化のための委員会の許容可能な割合 (t) を決定できるようにすることです。プライバシー(アンバンドリングとMEV窃盗の可能性)と、委員会の閾値がオンラインになる可能性の間にはトレードオフがあります。建設業者にとっては、ブロックをフォークアウトするのではなく、含める方が収益を最大化するため、最適化されたしきい値設定を把握する必要があります。[4]
さらに、この暗号化方式の使用は任意であるべきです。ネットワークの状況が不利な場合、適切なサイズの委員会が一貫して利用できない場合には、提案者やビルダーはリレー、自己構築、またはその他の不利な環境の性質に応じた好ましいメカニズムに戻ることができます。
- ここでの具体的な主張は、ビルダーのブロックがフォークアウトされるのは負のEVであり(彼らはそこから収益を受け取らない)、バンドル解除されるのは非常に負のEVであるということです。ビルダーに [0,128] の t を選ぶ能力を与えるなら、アンバンドリングのリスクが非常に低く、満足する確率が高い (少なくとも t 人の委員がオンラインである) ほど高い t を選択するように自然に動機付けられるはずです。一部のブロックは、通常のネットワーク条件下でも分岐する可能性がありますが、これはタイミングゲームですでに発生しており、チェーンの活性は許容範囲内であることに注意してください。↩
利用不可なブロック
または、委員会はオンラインであるかもしれませんが、ビルダーはブロックが復号できないか、復号後に無効になる状況を作成できるかもしれません（例：不正な証明で）。
プロトコルの視点からは、これらのブロックをフォークすることは問題ありません。広範な検証者セットは、これらのブロックやそれらを参照するブロックに対して証明することができませんでした。この種のエラーを処理する最良の方法は、おそらくコンセンサスクライアントがこの可能性を認識し、優雅に失敗することができるようにすることです。具体的な方法については、さらなる研究が必要です。
マーケット構造
勝利したビルダーは、しきい値に達するまで他の人よりもブロックの内容を知っています。これは、後続のスロットで不公平な利点を生み出す可能性があります。しかし、証明者委員会は次のスロットの終了前に行動することになっており、ブロックの大部分の価値はスロットの終わりにあるため、この利点の影響はできるだけ最小限に抑えられるはずです。
純粋に暗号化された証明
長期的には、TEEプルーフをゼロ知識（ZK）プルーフで置き換えることが可能になるかもしれません。現在、ZKプルーフは遅すぎますが、暗号技術、ソフトウェア、専用ハードウェア（ASIC）の進歩により、必要なレイテンシ制約内でZKプルーフ生成が実現可能になるかもしれません。特に、ブロックに付随するZKプルーフはすでに存在します。Ethereumの長期ロードマップの中核部分.
採用
現在のバリデータセットのサイズと成長率では、この方式はL1に公開するために必要なデータ量に見合う価値があるとは言えないかもしれません。ただし、Ethereumは既にMaxEBでバリデータセットの数を大幅に削減する予定です。
最善のアプローチは、MaxEBと並行して、またはMaxEBの後にアップグレードを行い、コンセンサスクライアントが暗号化されたブロックセマンティクスの可能性を認識し、バリデーターがヒントを公開することを奨励することです。例えば、MaxEB以降は、新しく入力するバリデーターにヒントを公開することを要求し、古いバリデーターにはアップグレードのインセンティブを与えることができます。
ビルダーは、十分な割合のバリデータセットが採用し、十分な委員会のサイズ（つまり、受け入れ可能なプライバシーと解読の可能性の両方）を持つようになると、メカニズムを使用し始めます。
もし私たちのアプローチが多段中継に比べて有利なレイテンシーを持っているのであれば、市場はそれを採用する必要もプロトコルが使用を強制する必要もなく、特定のパラメータ化を確立する必要もありません。
根拠
リレーは、イーサリアムの最も重要な中央集権化の源泉の1つであり、レンタルを求め、プロトコルの地理的な分散化を歪める機会を提供しています。
リレーを取り除く必要があり、これは比較的優雅な方法であると考えています。これにはコンセンサスレイヤーでの変更が必要ですが、検証者側で新しいハードウェアや鍵素材は必要ありません。
デメリットは、市場によって採用されるかどうか（提案されているように）採用されるかどうか不明であるメカニズムのためにコンセンサスレイヤーの複雑な変更であるということです。しかし、MEVパイプラインへの多くの潜在的な変更は、類似した採用および収益最適化の問題を抱えています（例：包含リスト).そして、バリデータセットがしきい値暗号化インフラを利用できることに依存する他の将来のユースケースも考えられます。
免責事項：
相關文章
ステーブルコインとは何ですか？
Cotiとは? COTIについて知っておくべきことすべて
リレーの取り外し方法
MEV-Boostは、イーサリアムにおけるMEV抽出のための現在のサイドカープロトコルであり、中央集権的なリレーと呼ばれるアクターに大きく依存しています。
ビルダーと提案者の間で直接的で暗号化されたプライベートな通信が可能な代替アーキテクチャを提案します。これは、バリデータの既存のBLSキーペアを使用できる、新しい非インタラクティブな形式の「silent」しきい値暗号化に基づいています。
基本的に、スロットのための証明委員会に乗っ取り、プライバシーとデータの利用可能性を閾値暗号化してブロック提案を一部の証明者に乗っ取ります。彼らの証明は復号化キーを形成し、望ましい閾値が証明されたら、ブロックを復号化できます。
私たちの構築物は建設者と提案者のプライバシーを対象としていますが、単独ではブロックの正当性を保証するものではありません。プライバシーとブロックの正当性の両方を提供する機能を完全に再現するために、他のメカニズムと組み合わせることができます。例えば、Trusted Execution Environment（TEE）プルーフやZero-Knowledge（ZK）プルーフなどの証明スキーム、または建設者の担保とする暗号経済学的メカニズムがあります。
リレーが建設者のプライバシーを提供し、ブロックの有効性を確保する必要をなくすことで、遅延を減少させ、Ethereumの分散化と検閲耐性を向上させることを目指しています。
MEV-Boostとリレーの役割
MEV-Boostは、ブロックビルダーとプロポーザーの間を仲介するサイドカープロトコルです。メインの役割リレーの役割は2つの保証を提供することです。
- ビルダー向けのプライバシー：リレーは、提案者がブロックの内容を見ることができず、ビルダーが見つけたMEVを盗むことができないようにします。
- 提案者の安全性：リレーは、ビルダーが提案者に約束した値を支払い、ブロックが有効であること（すべてのトランザクションが固有のガスを支払うなど）を保証します。
リレーへの依存は、ただし、重要な中央集権を導入します。 Ethereumのブロックの約90%が、わずか数のリレーを介して提供されます。 これにはいくつかのリスクが伴います:
- 中央集権化：ビルダーは、提案者の地理的な分散を反映させる代わりに、リレーと共有することでレイテンシーを効率的にすることができます。これは、大規模でグローバルに分散したバリデータセットから得られる地理的な分散化と検閲耐性を直接的に損ないます。
- 収益：効率的な中継のエンドツーエンドのブロック処理の平均遅延は約5〜20ミリ秒です。その後、提案者とビルダーの間に通信遅延があります。中継をスキップすると、遅延が減少し、クロスドメインの実行リスク（例：CEX/DEX）が低下し、提案者のMEV報酬が最終的に増加します。
TEE-Boost
リレーを置き換えるための主要な提案の1つは、“TEE-Boostこれは TEE (Trusted Execution Environment) に依存しています。TEEは私たちのスキームに必須ではないことに注意してください。TEE-Boostは、私たちが解決しようとしている問題の教育的な例として役に立ちます。
具体的には、TEE-BoostはビルダーがTEEを使用して、実際のブロックの内容を提案者に公開せずに、入札の正当性とブロックの有効性を証明する証拠を作成するようにします。提案者は、これらの証拠をTEEを実行せずに自身のコモディティハードウェア上で確認することができます。
しかし、TEE-Boostにはデータ可用性の問題があります:ビルダーはTEEプルーフとブロックヘッダーを提案者とのみ共有し、実際のブロックコンテンツは共有しません。[1]そして、提案者がヘッダーに署名した後でも、ブロックの内容を公開しないことを選択する場合があります（例えば、市況が不利に変わった場合）。このDA問題を解決するための提案された手法は次の通りです:
- [ ] TEE-Escrow: TEE-エスクローは、提案者が署名する前にビルダーからブロックを取得し、署名されたヘッダーを見るとリリースされます。
- [ ] データ可用性レイヤー：ビルダーは暗号化されたブロックペイロードをデータ可用性（DA）レイヤーに投稿します。
両方のアプローチには欠点があります。 TEE-エスクロー解決策は、既存のリレーと同様の集中化の遅延動態を再現します。[2]外部のDAレイヤーを使用すると、外部プロトコルの遅延ダイナミクス（これも不利な可能性があります）を導入するため、プロトコル外の仮定が発生します。
理論的には、提案者も TEE にアクセスできる場合、ビルダーは提案者によって実行される TEE に対してブロックを暗号化できます。提案者のTEEは、ブロックに署名した後にのみブロックを復号化します。ただし、TEE-Boostは、提案者(バリデーター)がTEEを実行する必要があるため、この設計を考慮していないと考えています。私たちは、バリデーターがコモディティハードウェア上で実行できるようにしたいと考えています。↩
レイテンシダイナミックは、提案者自体がバリデータノードのサイドカーとしてTEEEscrowを共有配置することで回避できます。ただし、再び、バリデータがTEEsを実行することは望ましくありません。↩
ビルダープライバシーを実現するための閾値暗号化
TEE-BoostのDA問題に優雅な解決策を提案します：アテスタ委員会への閾値暗号化。具体的には、ビルダー閾値がそのスロットのアテスタ委員会の指定された割合にブロックを暗号化します。十分な証明書が集まると、ブロックは復号可能になります。
コアの有効化技術はサイレントしきい値暗号化この暗号技術により、以前の構築物が必要とした対話型分散キー生成（DKG）セットアップフェーズを必要とせずに、しきい値暗号化を可能にします。代わりに、共同公開鍵は、証明者の既存のBLS公開鍵にいくつかの「ヒント」（後で説明します）を加えて、決定論的に計算されます。
これにより、ビルダーとバリデーター間で直接のシングルホップ通信が、暗号化されたプライバシーを持って実現されます。バリデーターは、自身でTEEを実行したり、新しいキーマテリアルを管理する必要はありません。
メカニクス：
ビルダーはブロックを構築し、それを証明者委員会に暗号化します。
ビルダーは、入札が正直であること、ブロックが有効であること、および正しく暗号化されていることをアテスタ委員会に証明するTEE証明を構築します。
ビルダーは、しきい値の暗号化されたブロックとTEEプルーフ（入札値を含む）を提案者に通信します。[3]
提案者は、勝利したビルダーの暗号化されたブロックに署名し、この提案をバリデータセットに広めます。
指定された分数（例：n/2または2n/3）のn-証明者委員会がスロットを証明した後、ブロックは復号化されます。
複合されたブロックは通常通り最終化されます。
- 提案者の帯域幅要件に与える影響は調査する必要があります。低帯域幅の提案者は、ブロック本体をリクエストする前に証明を検証する、または他のヒューリスティックフィルタリングやスマートダウンロード技術を使用することで、ニーズを制限することができます。これはオープンな問題ですが、通常のメンプールゴシップスパムの問題よりも解決するのがより難しいとは思われません。↩
考慮事項
パフォーマンス
サイレントスレッショルド暗号のパフォーマンス特性は非常に好ましいです。ここで
nは、サポートしたい委員会の最大サイズであり、tは復号のための閾値です。
暗号化と部分的な復号はどちらも一定時間です。単純な実装では、暗号化には7ms以下かかります（並列化可能）。部分的な復号には1ms以下かかります。
暗号文のサイズは、平文よりも大きく、定数の加法因子である768バイトです（任意のnとtに対して）。
部分復号の集約（すなわち、復号）は委員会のサイズに依存します。n=1024の場合、素朴な実装には<200msがかかります。n=128（各スロットの証明委員会のサイズ）の場合、これは10分の1になり、さらに実装を最適化できると予想されています。
重要なのは、暗号化時間がリレーの遅延と比較するための主要なパフォーマンス指標であることです。これは、ビルダーがブロックの生成の「クリティカルパス」で計算しなければならないものです。これは既存のリレーのブロック処理遅延よりも低く、多段階通信を避けます。
データ公開
サイレントしきい値暗号化は完全に無料ではありません。形式の共通参照文字列が必要です：(g,gτ,gτ2,...,グラムτn−t)、KZG多項式コミットメントスキームで使用されているものと類似しています。
また、形式gskのBLS公開鍵を持つすべての検証者は、私たちが「ヒント」と呼ぶグループ要素のセットを公開します：（gsk⋅τ,...,グラムsk⋅τn−t). これらのヒントは、公開鍵を集計し、暗号文を復号化するためにのみ必要です。暗号化は定数サイズの集計された公開鍵のみを使用します。
この記事を書いている時点で、約100万人のバリデーターがいます。n=128 と t=n/2 を設定した場合、各バリデーターは 3 KB ≈ヒントを投稿する必要があります。したがって、すべてのバリデータのヒントを保存するには、3GBが必要です。
この要件はおそらく大幅に減少するでしょうMaxEBの活性化これにより、>32ETHを管理するバリデーターは、(複数の32ETHデポジットに分割するのではなく)同じキーペアでより大きな残高を保持することができます。実現されるバリデーターセットの削減については議論の余地があります。~1GBまで下げられる可能性はあるようです。
最後に、イーサリアムの合意アーキテクチャの将来の変更（例：バリデータセットサイズのさらなる削減、または代替の確定性パイプライン）に応じて、保存する必要のあるヒントのサイズがさらに減少する可能性があります。
リブネス
Ethereumは、不利なネットワーク状況でも生き続けたいと考えています。この方式の1つの問題は、委員会の指定された割合がオフラインになっているために解読できないブロックの可能性です。
1 つの解決策は、ビルダーが復号化のための委員会の許容可能な割合 (t) を決定できるようにすることです。プライバシー(アンバンドリングとMEV窃盗の可能性)と、委員会の閾値がオンラインになる可能性の間にはトレードオフがあります。建設業者にとっては、ブロックをフォークアウトするのではなく、含める方が収益を最大化するため、最適化されたしきい値設定を把握する必要があります。[4]
さらに、この暗号化方式の使用は任意であるべきです。ネットワークの状況が不利な場合、適切なサイズの委員会が一貫して利用できない場合には、提案者やビルダーはリレー、自己構築、またはその他の不利な環境の性質に応じた好ましいメカニズムに戻ることができます。
- ここでの具体的な主張は、ビルダーのブロックがフォークアウトされるのは負のEVであり(彼らはそこから収益を受け取らない)、バンドル解除されるのは非常に負のEVであるということです。ビルダーに [0,128] の t を選ぶ能力を与えるなら、アンバンドリングのリスクが非常に低く、満足する確率が高い (少なくとも t 人の委員がオンラインである) ほど高い t を選択するように自然に動機付けられるはずです。一部のブロックは、通常のネットワーク条件下でも分岐する可能性がありますが、これはタイミングゲームですでに発生しており、チェーンの活性は許容範囲内であることに注意してください。↩
利用不可なブロック
または、委員会はオンラインであるかもしれませんが、ビルダーはブロックが復号できないか、復号後に無効になる状況を作成できるかもしれません（例：不正な証明で）。
プロトコルの視点からは、これらのブロックをフォークすることは問題ありません。広範な検証者セットは、これらのブロックやそれらを参照するブロックに対して証明することができませんでした。この種のエラーを処理する最良の方法は、おそらくコンセンサスクライアントがこの可能性を認識し、優雅に失敗することができるようにすることです。具体的な方法については、さらなる研究が必要です。
マーケット構造
勝利したビルダーは、しきい値に達するまで他の人よりもブロックの内容を知っています。これは、後続のスロットで不公平な利点を生み出す可能性があります。しかし、証明者委員会は次のスロットの終了前に行動することになっており、ブロックの大部分の価値はスロットの終わりにあるため、この利点の影響はできるだけ最小限に抑えられるはずです。
純粋に暗号化された証明
長期的には、TEEプルーフをゼロ知識（ZK）プルーフで置き換えることが可能になるかもしれません。現在、ZKプルーフは遅すぎますが、暗号技術、ソフトウェア、専用ハードウェア（ASIC）の進歩により、必要なレイテンシ制約内でZKプルーフ生成が実現可能になるかもしれません。特に、ブロックに付随するZKプルーフはすでに存在します。Ethereumの長期ロードマップの中核部分.
採用
現在のバリデータセットのサイズと成長率では、この方式はL1に公開するために必要なデータ量に見合う価値があるとは言えないかもしれません。ただし、Ethereumは既にMaxEBでバリデータセットの数を大幅に削減する予定です。
最善のアプローチは、MaxEBと並行して、またはMaxEBの後にアップグレードを行い、コンセンサスクライアントが暗号化されたブロックセマンティクスの可能性を認識し、バリデーターがヒントを公開することを奨励することです。例えば、MaxEB以降は、新しく入力するバリデーターにヒントを公開することを要求し、古いバリデーターにはアップグレードのインセンティブを与えることができます。
ビルダーは、十分な割合のバリデータセットが採用し、十分な委員会のサイズ（つまり、受け入れ可能なプライバシーと解読の可能性の両方）を持つようになると、メカニズムを使用し始めます。
もし私たちのアプローチが多段中継に比べて有利なレイテンシーを持っているのであれば、市場はそれを採用する必要もプロトコルが使用を強制する必要もなく、特定のパラメータ化を確立する必要もありません。
根拠
リレーは、イーサリアムの最も重要な中央集権化の源泉の1つであり、レンタルを求め、プロトコルの地理的な分散化を歪める機会を提供しています。
リレーを取り除く必要があり、これは比較的優雅な方法であると考えています。これにはコンセンサスレイヤーでの変更が必要ですが、検証者側で新しいハードウェアや鍵素材は必要ありません。
デメリットは、市場によって採用されるかどうか（提案されているように）採用されるかどうか不明であるメカニズムのためにコンセンサスレイヤーの複雑な変更であるということです。しかし、MEVパイプラインへの多くの潜在的な変更は、類似した採用および収益最適化の問題を抱えています（例：包含リスト).そして、バリデータセットがしきい値暗号化インフラを利用できることに依存する他の将来のユースケースも考えられます。
免責事項：
相關文章
ステーブルコインとは何ですか？