トランクの取り外し方

MEV-Boostは現在のETHネットワークでMEVを抽出するためのプロトコルであり、重要な中心化された参加者であるリレーに依存しています。私たちは、建設者と提案者の間で直接的で暗号化された通信を可能にする代替アーキテクチャを提案しています。このアーキテクチャは、新しい非対話型"サイレント"しきい値暗号化形式に基づいており、バリデータの既存のBLS秘密鍵を使用できます。

本質上、我々は閾値暗号化ブロック提案を一部の参加者に送信して、証明委員会の協力を得てプライバシーとデータの可用性を実現しています。彼らの証明が復号秘密鍵を形成します。必要な閾値に達すると、ブロックが復号できます。

私たちのソリューションは、建設者と提案者の間のプライバシー問題を解決していますが、単独ではブロックの有効性を保証することはできません。これは、他のメカニズムと組み合わせることができ、リレーの機能を完全に模倣し、プライバシーやブロックの有効性を含むものです。たとえば、受信実行環境（TEE）プルーフやゼロ知識（ZK）プルーフ、または暗号化経済メカニズムを使用して、建設者に保証を提供することができます。

リレーを提供することで、ブロックの有効性を確保し、イーサリアムの分散化と検閲耐性を高めることを目指し、ビルダーのプライバシーを排除することは、レイテンシーを減少させることにつながります。

MEV-Boostとリレーの役割

MEV-Boostは、ブロックビルダーと提案者の間の仲介役として機能するサイドカープロトコルです。 リレーの [主な機能] (https://ethresear.ch/t/relays-in-a-post-epbs-world/16278#h-2-relay-roles-today-3) は、次の 2 つの保証を提供することです。

• リレーは、提案者がブロックの内容を見ることができず、構築者が見つけたMEVを盗むこともできないように、構築者のプライバシーを保護します。
• 提案者のセキュリティ：リレーは、建設者が入札額に従って提案者に約束された価値を支払い、ブロックが有効であることを保証します（例：すべての取引が内部のガス費用を支払う）。

しかし、リレーへの依存は著しい中央集権化をもたらしています。約90％のETHブロックはわずかな数のリレーを通じて伝達されています。これにはいくつかのリスクが伴います。

• 中心化：構築者は、リレーとの共同デプロイによりレイテンシー効率を向上させることができ、提案者の地理的な分布を反映する必要はありません。これにより、私たちが大規模なグローバルなバリデータセットから得ることができる地理的な分散化と検閲耐性が直接弱体化します。
• 収益：高効率リレーの平均エンドツーエンドブロック処理レイテンシーは約5-20ミリ秒です。その後、ビルダーと提案者の間には通信レイテンシーが存在します。リレーをスキップすることで、レイテンシーが減少し、クロスチェーン実行リスク（例：CEX/DEX）が低減され、提案者のMEV報酬が最終的に増加します。

TEE-ブースト

リレーの主な代替案の1つは「TEE-Boost」であり、これは信頼できる実行環境（TEEs）に依存しています。TEEsは私たちのソリューションの中核ではありませんが、問題解決の教育的な例としてTEE-Boostを使用することは役立ちます。

具体的には、TEE-Boostは、ビルダーがTEEsを使用して証明を作成し、提案者に入札の誠実さとブロックの有効性を示すことを要求しますが、実際のブロックの内容を提案者に明かす必要はありません。提案者は、TEEsを自分自身で実行する必要なく、これらの証明を通常のハードウェアでチェックすることができます。

しかし、TEE-Boostにはデータ可用性の問題があります:ビルダーはTEEプルーフとブロックヘッダーを提案者と共有するだけで、実際のブロックコンテンツは共有しません^[1]また、提案者がヘッダに署名した後にブロックの内容を公開しない選択肢もあります（例えば、市場状況が不利に変化した場合など）。このデータの可用性問題を解決するための提案方法には、次のものがあります:

TEE保管：TEE保管は、提案者が署名する前にブロックをビルダーから取得し、署名ヘッダーを見た後にそのブロックを解放します。

データ可用性レイヤー: ビルダーは、暗号化されたブロックペイロードをデータ可用性(DA)レイヤーに公開します。

これらの2つの方法には欠点があります。TEE-保全ソリューションは、既存のリレーに似た中央集権的なレイテンシーのダイナミクスを複製しています。[2]。外部DAレイヤーを使用する場合、追加のプロトコルの仮定が導入され、その外部プロトコルのレイテンシーのダイナミック（これらのダイナミックも不利な場合があります）に耐える必要があります。

1. 理論的には、提案者がTEEsにアクセスできる場合、ビルダーはそのブロックを提案者が実行しているTEEに暗号化できます。提案者のTEEは署名後にのみそのブロックを復号化します。ただし、私たちはTEE-Boostがこのような設計を考慮していないと考えています。なぜなら、これには提案者（バリデータ）がTEEsを実行することが必要だからです。我々はバリデータが通常のハードウェア上で実行できることを望んでいます。

2.もし提案者自身がTEE保管を自身のバリデータノードと共同で展開する場合、レイテンシー動を避けることができます。

状態。 ただし、バリデーターがTEEを実行することも望ましくありません。 ↩

閾値暗号学によるビルダーのプライバシー保護

私たちは、TEE-Boostのデータ可用性の問題に対処するために、優れた解決策を提案しています：検証委員会の閾値暗号化。具体的には、ビルダーは、そのスロットにおける指定された割合の検証委員会にブロックを閾値暗号化します。十分な承認が集まると、ブロックは復号化されて利用可能になります。

核心機能技術は無音閾値暗号化です。この暗号技術は閾値暗号化を可能にするもので、事前に交互的分散秘密鍵生成（DKG）設定フェーズを構築する必要はありません。代わりに、連合公開鍵はバリデータの既存のBLS公開鍵といくつかの「ヒント」（後で説明します）に基づいて決定論的に計算されます。

これにより、ビルダーとバリデータの間での直接的なホップ通信が実現され、暗号学的プライバシーが提供されます。バリデータは独自のTEEsを実行したり、新しい秘密鍵材料を管理したりする必要はありません。

メカニズム：

ビルダーはブロックを構築し、それを検証委員会によって暗号化します。

構築者は、TEEプルーフを構築し、検証委員会に3つの側面を証明します：入札が正直であること、ブロックが有効であること、そして暗号化が正しいこと。

ビルダーは、閾値暗号のブロックとTEEプルーフ(出力値を含む)を提案者に伝えます。 ^[3]

提案者は勝利したビルダーの暗号化ブロックに署名し、その提案を検証者グループに伝えます。

指定された割合（たとえばn/2または2n/3）の検証委員会がブロックを認証すると、それが復号化されます。

解読されたブロックは正常に最終確認されます。

3. 提案者の帯域幅要件への影響について調査する必要があります。低帯域幅の提案者は、ブロックリクエスト本体の認証証明を行うか、他の啓示的なフィルタリングやスマートダウンロード技術を使用して要件を制限することができます。これはオープンな問題ですが、通常のメモリープールによるスパムメールの問題よりも解決が困難ではないようです。↩

注意事項

パフォーマンス

サイレント閾値暗号化の性能特徴は非常に有利です。ここで、nはサポートしたい委員会の最大規模であり、tは復号の閾値です。

暗号化と部分解読の時間はどちらも定数時間です。シンプルな実装を使用すると、暗号化にかかる時間は7ミリ秒未満であり、並列化も可能です。部分解読にかかる時間は1ミリ秒未満です。

暗号テキストのサイズはプレーンテキストよりも 768 バイト大きく、これは一定のアドオン係数です (任意の n と t の場合)。

部分解読化された集約（つまり解読）は、委員会のサイズに依存します。n=1024の場合、簡単な実装では200ミリ秒未満の時間がかかります。n=128（各スロットの認証委員会のサイズ）の場合、この時間は10倍短縮され、さらなる最適化が可能であると予想されています。

重要なのは、暗号化時間はリレーレイテンシーと比較しての重要なパフォーマンス指標です。これはブロック生成の「クリティカルパス」でビルダーが計算する必要があるものです。この時間は既存のリレーのブロック処理レイテンシーよりも低く、多段通信を回避します。

データ公開

無音門限暗号化は完全に無料ではありません。実際、それには共通のリファレンス文字列が必要で、形式は次のようになります：(g, gτ, gτ², …, gτⁿ⁻ᵗ)、KZG多項式コミットメントスキームに使用されるものと類似しています。

また、g⁽ˢᵏ⁾の形式を持つBLS公開鍵を持つバリデータは、「ヒント」と呼ばれる群要素のセットを公開します：(g⁽ˢᵏ⁾⋅τ, …, g⁽ˢᵏ⁾⋅τⁿ⁻ᵗ)。これらのヒントは、集約公開鍵と復号化された暗号文のみで使用されます。暗号化には、定数サイズの集約公開鍵のみが使用されます。

この記事が書かれた時点で、約100万のバリデータが存在します。n=128、t=n/2と設定した場合、各バリデータは約3KBのヒントを発行する必要があります。したがって、すべてのバリデータのヒントを保存するには3GBのスペースが必要です。

MaxEBのアクティブ化に伴い、この要件は大幅にドロップする可能性があります。MaxEBにより、同じ秘密鍵で32 ETHを超えるバリデータがより大きな残高を持つことができるようになります（32 ETHのデポジットに分散させるのではなく）。実現されるバリデータセットの減少については、議論が必要です。おそらく約1GBまで低下する可能性があります。

最後、ETH坊コンセンサス架构の将来の変化（例えば、バリデータ集規模のさらなる縮小や最終性パイプラインの代替）に基づいて、保持する必要があるヒントのサイズはさらに縮小する可能性があります。

バイタリティ

ETH坊は、不利なネットワーク条件下でもオンラインを維持することを目指しています。この計画の1つの問題は、指定された比率の委員会がオフラインになっているため、解読できないブロックが発生する可能性があることです。

1つの解決策は、ビルダーが復号化に使用する受け入れ可能な委員会の割合(t)を決定できるようにすることです。プライバシー（アンパックとMEVの盗難の可能性）と委員会の閾値オンラインの可能性の間には、トレードオフが存在します。ビルダーにとって、自分たちのブロックがフォークされずにチェーンに含まれることは収入を最大化するために重要ですので、最適な閾値設定を見つける必要があります。^[4]

さらに、この暗号化スキームの使用は任意である必要があります。 不利なネットワーク条件下では、オンラインのままでいられる許容可能な規模の委員会がない場合、提案者と建設者は、不利な環境の性質に応じて、リレー、セルフビルド、またはその他の選択したメカニズムの使用にフォールバックできます。

具体的には、構築者のブロックはフォークされた場合の期待値が負であり（そこから収入が得られません）、アンパックされた場合の期待値は非常に負です。構築者には、[0, 128]の範囲から選択する機会が与えられ、自然と十分に高いtを選択するように刺激され、アンパックのリスクを下げ、満足の確率を高めるはずです（少なくともt名の委員会メンバーがオンラインである場合）。通常のネットワーク条件では、一部のブロックがフォークされる場合がありますが、時間の経過によるものであり、チェーンの活性化は引き続き受け入れられます。↩

利用できないブロック

また、委員会はオンラインであるかもしれませんが、ビルダーはブロックが復号化されないか無効になる状況を作り出すことができるかもしれません（例えば、詐欺的な証明を使用することなど）。

プロトコルの観点から、これらのブロックをフォークアウトすることは可能です。より広範なバリデータセットは単純にこの種のブロック、またはそれらを参照する任意のブロックを検証することはできません。この種のエラーを処理する最良の方法は、コンセンサスクライアントがこの可能性に気付き、優雅に失敗できるようにすることかもしれません。これについてはさらなる研究が必要です。

市場構造

勝利したビルダーは、しきい値に達する前にブロックの内容を知っているため、これは後続の期間に不公平な利点をもたらす可能性があります。ただし、証明委員会は次の期間が終了する前に行動を起こすべきであり、ブロックの価値の大部分は期間が終了する時点で集中しているため、このような利点の影響をできるだけ小さくする必要があります。

純粋な暗号証明

長期的には、TEE証明の代わりにゼロ知識証明（ZK証明）を使用する機会があります。現時点では、ZK証明は速度が遅いですが、暗号学、ソフトウェア、および専用ハードウェア（ASIC）の進歩により、ZK証明の生成が必要なレイテンシー制限内で実現可能になる可能性があります。なお、ブロックに伴うZK証明はETHのロードマップの中核です。

養子縁組

現在のバリデータセットの規模と成長率に基づいて、この方法はL1に必要なデータ量を公開する価値がないかもしれません。しかし、ETHブロックチェーンはMaxEBを通じてバリデータの数を大幅に減らす計画を立てています。

最も良い方法は、コンセンサスクライアントが暗号化ブロックの意味を認識し、バリデータにヒントを発行する可能性があることをMaxEBの前後にアップグレードすることです。たとえば、MaxEBの後に新しいバリデータにヒントを発行することができ、古いバリデータはアップグレードのインセンティブを得ることができます。

十分のバリデータセットがこのメカニズムを採用すれば、ビルダーはそれを使用し始め、十分な委員会の規模（つまり、プライバシーと解読の可能性の両方を兼ね備えた）を確保します。

もし私たちの方法がレイテンシーの面で実際に多ホップ転送よりも優れているなら、市場は自然にそれを採用するはずであり、プロトコルの強制使用や特定のパラメータ設定を必要とはしない。

根拠

リレーはイーサリアムの最も重要な中央集権化の一つであり、地理的な分散化のプロトコルを歪め、賃貸機会を生み出します。リレーを排除し、それを比較的優雅な解決策と見なす必要があります。これにはコンセンサスレイヤーの変更が必要ですが、バリデータは新しいハードウェアや秘密鍵素材を提供する必要はありません。

缺点は、これがコンセンサスレイヤーの複雑な変更であり、このようなメカニズム（提案されたように選択的に採用される場合）が市場に受け入れられる可能性があるかもしれないが、そうでない可能性もあるということです。ただし、多くの潜在的なMEVパイプラインの変更も同様の採用および収益最適化の問題に直面しています（たとえば、リストを含む）。また、将来的には、他のユースケースがバリデータセットの所有権の閾値暗号化インフラに依存する可能性があります。

免責事項:

1. 本文は[から転載されました。paradigm]、著作権は原作者[Charlie NoyesGuru、Vamsi Policharla]に帰属しますので、転載に異議がある場合は、Gate Learn Teamまでご連絡ください。 チームは、関連するプロセスに従って、可能な限り迅速に対処します。
2. 免責事項：本文に表現されている意見や考えは、著者個人のものであり、投資アドバイスとはなりません。
3. 記事の他の言語版はGate Learnチームによって翻訳され、Gate.ioに言及されていない場合、翻訳された記事を複製、配布、または盗用することはできません。