Solana の共同創設文：Solana の並行リーダーシップメカニズム、MEV を解決し、グローバルな価格発見エンジンを構築
Solanaのより大きなビジョンは、あらゆる中央集権型取引所（CEX）の最高のパフォーマンスと競争できる、グローバルな無許可の価格発見エンジンを構築することです。编译：深潮TechFlow
概要
MEV は無許可ブロックチェーンにおける基本的な問題です。ほとんどの無許可ブロックチェーンと同様に、Solana の目標は、チェーンオペレーターがユーザーから抽出する MEV を最小限に抑えることです。
Solana のアプローチは、リーダー（すなわちブロックプロデューサー）間の競争を最大化することで MEV を削減することです。これは、スロット時間を短縮し、単一のリーダーが連続してスケジュールするスロットの数を減らし、各スロットの同時リーダーの数を増やすことを意味します。
一般的に、毎秒より多くのリーダーがいることは、ユーザーが T 秒待った後、次のリーダーから最も有利なオファーを選ぶ選択肢が増えることを意味します。より多くのリーダーは、優れたリーダーがブロックスペースを提供するコストが低くなることも意味し、ユーザーは優れたリーダーとの取引を行いやすくなり、不良リーダーの取引を排除できます。市場が良いものと悪いものを決定すべきです。
Solana のより大きなビジョンは、あらゆる中央集権的取引所（CEX）の最高のパフォーマンスと競争できる、グローバルな無許可の価格発見エンジンを構築することです。
シンガポールで市場に影響を与える出来事が発生した場合、情報は光速でニューヨークの CEX に伝送される必要があります。情報がニューヨークに到達する前に、Solana ネットワーク内のリーダーはすでにその情報をブロック内で放送している必要があります。物理的なインターネットの分断が同時に発生しない限り、情報がニューヨークに到達する時点で、Solana の状態はその情報を反映しているはずです。したがって、ニューヨークの CEX と Solana の間にアービトラージの機会が存在すべきではありません。
この目標を完全に達成するためには、Solana は多くの同時リーダーを必要とし、高度に楽観的な確認保証を持つ必要があります。
複数のリーダーの構成
現在のリーダーのスケジュールと同様に、システムは各スロットを 1 つのリーダーではなく 2 つのリーダーに構成します。この 2 つのリーダーを区別するために、1 つのチャネルは A とラベル付けされ、もう 1 つのチャネルは B とラベル付けされます。A と B は独立してローテーションできます。この計画を実現するために答えるべき質問は次のとおりです：
ブロック A と B が異なる時間に到達したり、失敗した場合はどうなりますか？
ブロック A と B の取引順序をどのように統合しますか？
A と B の間でブロック容量をどのように配分しますか？
同時ブロックの伝送
具体的なプロセスを理解するために、Turbine について簡単に説明します。
リーダーはブロックを構築する際に、それをフラグメントに分割します。32 のフラグメントのバッチは 32 のコードフラグメントのエラー訂正コードです。64 のフラグメントバッチはマーク化され、ルートに署名され、これらは前のバッチにリンクされています。
各フラグメントは独立した決定論的ランダムパスを通じて送信されます。各最後のバッチの再送信者はルートに署名します。
受信者の観点から見ると、各受信者は検証済みの再送信者から 32 のフラグメントを受け取る必要があります。欠落しているフラグメントはランダムに修復されます。
この数は増減可能で、遅延への影響は非常に小さいです。
再送信者のフラグメントパスのサンプリングが十分にランダムであり、株式加重されていると仮定すると、協調分割ネットワークに必要な株式は ε 株式をはるかに超えます。受信者が各バッチの 32/64（設定可能）フラグメントが T 時間内に到達したことを検出した場合、各ノードもそうである可能性が高いです。これは、32 のランダムノードが十分に大きく、すべてが同じ分割にランダムに存在する可能性が低いためです。
分割が発生した場合、コンセンサスがそれを解決する必要があります。これは安全性に影響を与えませんが、速度は比較的遅くなります。
複数のブロック生成
単一のブロックを伝送する場合、各受信者（次のリーダーを含む）は、各ブロックのフラグメントバッチが到達するのを確認します。ブロックが T ミリ秒以内に不完全な場合、現在のリーダーはそのブロックをスキップし、それなしで分岐を構築します。リーダーが誤っている場合、他のすべてのノードはブロックに投票し、リーダーのブロックはスキップされます。非故障リーダーは、投票によって示された最も重い分岐に即座に切り替えます。
複数のブロック伝送の場合、各ノードは最大 T ミリ秒待機し、その後観察されたブロック分割に投票する必要があります。2 つの同時リーダーの場合、可能な状況は A、B または A と B です。ブロック遅延がある場合にのみ追加の遅延が発生します。通常の操作では、すべてのブロックは同時に到達するはずであり、各検証者は両方が到達した後に即座に投票できます。したがって、実際には T はゼロに近い可能性があります。
この攻撃が重点的に防御すべき点は、非常に少量のトークンをステークしたリーダーが、スロット境界でわずかに遅れてブロックを伝送し、ネットワーク分割を引き起こし、ネットワークがコンセンサスメカニズムを通じて問題を解決するのに多くの時間を費やさせることができるかどうかです。ネットワークの一部は A に投票し、一部は B に投票し、さらに一部は A と B の両方に同時に投票します。この 3 つの分割状況はすべて、コンセンサスメカニズムによって解決される必要があります。
具体的には、ゼロ近傍の目標は、ノードが同時にブロックを復元することを保証することです。攻撃者がゼロ近傍に協調ノードを持っている場合、彼らは正常に 31/64 フラグメントを伝送し、攻撃者が最後のフラグメントを選択的に伝送して分割を作成しようとすることができます。誠実なノードは、どの再送信者が遅延しているかを検出し、任意の単一の誠実なノードがブロックを復元した後に直ちに欠落しているフラグメントをプッシュできます。再送信者は、どこからでもフラグメントを受信したり、それを復元したりすることができる場合、続行できます。したがって、ブロックは誠実なノードが復元した後すぐにすべてのノードによって復元されるべきです。待機時間を決定するためには、テストを通じて、待機時間が絶対的なものであるか、各フラグメントの到達時間で加重されるべきか、株式ノードの評判を使用するべきかを判断する必要があります。
各ブロック内の協調リーダーと再送信者の確率は約 P リーダー株式（64P 再送信者株式）です。1% の株式は、攻撃者がリーダーとしてスケジュールした ½ フラグメントバッチ内で攻撃を試みることができます。したがって、検出と緩和は十分に強力である必要があります。
この攻撃は次のリーダーに対する影響は小さいですが、非同期実行により未使用の容量が繰り越されることを許可します。したがって、現在のリーダーが次のリーダーにスロットをスキップさせる場合、次のリーダーが 4 つの連続スロットを持っていると、スキップされたスロットの未使用容量は繰り越され、リーダーはスキップされたスロットの取引を再度含めることができます。
同時ブロックの統合
ユーザーが含まれる機会を増やすために、またはブロック内で最初に位置するために、同じ取引を同時にリーダー A と B に送信した場合、これはリソースの無駄を引き起こします。このような場合、同時リーダーの数を増やすことは、彼らが二重のゴミ取引を処理しているだけであるため、パフォーマンス向上の効果は非常に限られます。
重複取引を避けるために、料金支払い者の上位 N 位が取引がどのリーダーチャネルで有効であるかを決定します。この例では、最高位が A または B を選択します。料金支払い者は独占的なチャネルに割り当てられる必要があり、リーダーは料金支払い者が有効であり、他のリーダーで全ての lamports（Solana ブロックチェーン内の最小通貨単位）を使い果たしていないことを確認できます。
これにより、スパム送信者は論理的に同じ取引に対して少なくとも 2 回料金を支払う必要がありますが、最初の取引になる確率を高めるために、スパム送信者は論理的に同じ取引を送信する可能性があります。
この行動を防ぐために、ユーザーはリーダーの優先料金の他に、追加で 100% 廃棄注文料金を含めることを選択できます。最高の注文料金が最初に実行されます。そうでなければ、先入れ先出し (FIFO) ソートを使用します。引き分けの場合は、決定論的なランダム順序を使用して順序を解決します。したがって、スパム送信者にとって、彼らの注文料金を引き上げて最初に実行することは、2 回の包含料金を支払うよりもコスト効率が良いです。
バンドルおよび再順序付けされた取引シーケンスを処理するために、システムは取引をバンドルすることをサポートする必要があります。これにより、取引シーケンス全体の順序コストをカバーするための注文料金を追加できます。手数料支払い者は、彼らの指定されたチャネル内でのみ有効であるため、バンドルは彼ら自身のチャネル内でのみシーケンスを操作できます。
あるいは、注文料金は必要ないかもしれません。FIFO ソートを使用し、スパム送信者がすべてのチャネルで常に優先料金を支払う場合、市場が N 人のリーダーに支払うコストと、最初に取引を含める可能性が最も高い最近のリーダーに支払うコストを決定することを許可するだけで済むかもしれません。
ブロックリソースの管理
ブロックチェーンネットワークでは、2 つの同時リーダーがいる場合、システム全体のブロック容量制限は平均的に分配される必要があります。具体的には、総容量だけでなく、各具体的な制限、たとえば書き込みロック制限 - どのアカウントも 600 万計算単位 (CUs) を超えて書き込むことはできず、各リーダーは最大で 2400 万 CUs の取引をスケジュールできます。これにより、最悪の状況でも、統合されたブロックはシステムの総容量制限を超えることはありません。
このメカニズムは、料金の変動やリソースの未利用を引き起こす可能性があります。なぜなら、スケジューリングの優先順位の料金は各リーダーの容量によって決定され、各リーダーは他の同時リーダーのスケジュール状態をほとんど知らないからです。
リソースの未利用とそれに伴う料金の急騰を緩和するために、未使用のブロック容量は将来のブロックに繰り越されるべきです。つまり、現在の統合ブロックが書き込みロック、総バイト数、または総計算単位 (CUs) で X を未使用の場合、K*X を次のブロックに追加する必要があります。ここで、0 < K < 1 であり、ある最大値まで続きます。非同期実行はチェーンの最上部で最大 1 エポック遅れる可能性があるため、容量の繰り越しはかなり攻撃的に行うことができます。
最近のブロックデータによれば、ほとんどのブロックは通常 80% 満たされており、書き込みロック制限は 50% を大きく下回っています。一般的に、将来のブロックには常にいくらかの予備容量があるべきです。ブロックが一時的に容量制限を超える可能性があるため、実行はコンセンサスプロセスと非同期で行う必要があります。非同期実行提案の詳細については、APE 記事を参照してください。
