Solana共同創業者:グローバルステートマシンの構築とSolanaの究極のアーキテクチャの分析

**文:アナトリー・ヤコヴェンコ氏、Solana社CEO(共同創業者兼CEO)

コンパイラ: 1912212.eth, Foresight News

Solanaの目標は、物理法則に従って、単一のパーミッションレスなグローバルステートマシンをできるだけ早く同期させることです。 これを実現できるアーキテクチャは、次のようになります。

• 10,000 を超える多数のフル ノード (N > 10,000)

ネットワークがグローバルステートマシンとして機能するためには、多数のフルノードをサポートする必要があります。 Turbine は、非常に大規模なネットワークへの高速レプリケーションが、最新のハードウェアとネットワークでスケーラブルであることを証明しています。

• 10,000を超える多数のブロック生成リーダー(N > 10,000) *同時リーダーは、4〜16の範囲でランダムに選択されたブロックを同時に生成します。

Concurrency Leader を使用すると、ネットワークは世界中に複数の場所を持ち、ユーザー トランザクションを並べ替えることができます。 これにより、ユーザーとネットワークの間の距離が短縮され、トランザクションがチェーンに追加される前にノード全体を検証する必要がなくなります。

※ブロック時間は120ミリ秒です

ブロック時間が短いため、ファイナリティポイントが速くなり、検閲耐性が高まり、ユーザーエクスペリエンスが向上し、トランザクションを並べ替えるウィンドウが短縮され、ネットワーク全体が高速化されます。

*承認小委員会の投票コンセンサスノードの一部は、200〜400の数で、ランダムに選択され、エポックごとに4〜8時間ごとにローテーションされます。

フォークを選択するにはコンセンサスが不可欠ですが、これはネットワークのパーティショニングが原因で発生します。 200 以上のノードのサンプルは、ネットワーク内のすべての主要なパーティションを統計的に表し、実際の分布とほぼ一致します。 したがって、すべてのフルノード投票は必要なく、200で十分です。 承認を小委員会に限定して、120 ミリ秒のブロックをサポートするために必要なメモリとネットワーク帯域幅を削減します。 ブロック時間を短縮すると、当然、毎秒送信される投票数が増加し、コンセンサスに割り当てられるリソースにいくらかの圧力がかかります。

120msブロックの本当の課題は、すべてのユーザートランザクションを再生することです。 ネットワークはパーミッションレスであるため、任意のユーザーコードを実行するための信頼できる時間で均質な実行環境を保証することは非常に困難です。 可能性はありますが、ユーザートランザクションに使用可能なコンピューティングリソースを制限し、すべてのノードが最悪のシナリオに過剰に割り当てられるようにすることによってのみ実現できます。

ただし、フォークに投票するコンセンサスノードや、フォークに基づいて構築するリーダーに完全な状態を強制する理由はありません。 コンセンサスノードとリーダーの承認を同期させるためには、期間ごとに一度だけ状態を計算する必要があります。

非同期実行

モチベーション

同期実行では、最悪のケースの実行時間を決定するために、ブロックを投票および作成するすべてのノードを任意のブロックでスーパー構成する必要があります。 非同期実行は、トレードオフがほとんどない数少ないケースの 1 つです。 コンセンサスノードは、投票前に行う作業が少なくて済みます。 作業は集約してバッチ処理できるため、キャッシュを失うことなく効率的に実行できます。 コンセンサスノードやリーダーとはまったく異なるマシンで実行することもできます。 同期実行を希望するユーザーは、ネットワーク全体を待つことなく、各状態遷移をリアルタイムで実行するために十分なハードウェアリソースを割り当てることができます。

アプリケーションとコア開発者の多様性を考えると、毎年大規模なプロトコルの変更を計画する価値があります。 どちらかを選ばなければならないとしたら、私の選択は非同期に実行することです。

概要

現在、バリデーターは各ブロックですべてのトランザクションをすばやく繰り返し、ブロックの完全な状態が計算された後にのみ投票します。 この提案の目的は、フォークに関する投票の決定を、ブロックの完全な状態遷移の計算から分離することです。

承認に投票するバリデーターは、フォークを選択するだけでよく、状態を実行する必要はまったくありません。 各エポックでのみ、次の承認を計算するためにステータスが必要です。

投票手続きは、独立して実施できるように調整されました。 ノードは、投票前にのみ投票手順を実行します。 バリデーターは多くのスペースを占有しないため、メモリ要件は比較的小さくなるはずです。 投票の実行時間は非常に予測可能であるため、投票手順の実行にジッターはほとんどまたはまったくないはずです。

議決権のないすべてのトランザクションは、非同期で計算できます。 これにより、リプレイは投票権のないすべてのトランザクションをバッチで実行し、すべてのプログラムを事前にプリフェッチしてJITし、すべてのキャッシュ損失を事実上排除できます。 長期的な目標は、リアルタイムで待機時間の短いフルステート計算を必要とするマシンのみをこのタスク用に構成することです。 おそらく、ユーザーは追加のハードウェアの料金を支払うことになります。

フォークの選択とステートの実行が分離されると、高速化が容易になります。

*非同期実行 *各エポックは、一定数の投票委員会をローテーションします

• 200ミリ秒のブロック時間

ユーザートランザクションのリプレイはフォークの選択をブロックしないため、ブロック時間を差し引くときにボラティリティは問題ではなくなります。 考慮すべき唯一のことは、200ミリ秒で、バリデータの投票率が2倍になることです。 承認のクォータの計算方法をかなり簡単に変更することで、承認のサイズを 200 または 400 など、適切と思われる数値に固定できます。

また、実装とコンセンサスを完全に分離することも自然です。 固定サイズの承認で投票プログラムアカウントを確認するだけでよいコンセンサスノードを再起動する方が高速です。

実際、大多数の承認はできるだけ早く投票され、これらの投票が伝播されている間、ユーザーに完全な状態の実行結果を提供するノードは同時にトランザクションを実行できるため、確認時間が長くなると考えています。 したがって、現在見られるリプレイジッターは、投票ネットワークの伝播と同時に発生するはずです。

投票する

• 投票アカウントには、2 エポックの投票をカバーするのに十分な数のSOLが必要です。 ※議決権行使はシンプルに行う必要があります。 単純でない投票は必ず失敗する。 ブロックジェネレータは複雑な投票をあきらめるべきです。 *投票アカウントからのSOLの引き出しは、残高が1エポック未満に下がらない限り許可されます。
• すべての lamports を 0 にするには、 Vote CLOSE ディレクティブは、 完全なエポックが経過することを要求しなければならない。 投票口座は時代1ではCLOSEとマークされますが、時代2ではCLOSEDにしかできません。 CLOSEを使用すると、すべてのSOLを引き出し、議決権アカウントを削除できます。 アカウントがCLOSEとしてマークされると、完全に削除することしかできず、再度開くことはできません。
• 投票には、通常の BankHash ではなく VoteBankHash が含まれます。

リーダーの規制と承認

バリデーターのみが次の基準を満たします。

※ステーク金額>X *投票のSOL >2エポックと同様に

• で、CLOSE のマークが付いていない

をクリックしてリーダー スケジュールに入り、承認にカウントされます。 バージョン 2 では、LeaderSchedule をクォーラムから分離でき、それぞれに同じ要件を持つ必要はありません。

VoteBankHash の計算

すべてのトランザクションを計算するBankhashとは異なり、バリデーターはLeaderSchedulerのバリデーターに関連する単純な投票トランザクションに対してのみVoteBankHashを計算します。 他のすべてのトランザクションは無視されます。 すべての投票を再生した後、VoteBankHash は現在の BankHash と同じ形式で計算されます。

VoteBankHash は、完全な BankHash ではなく、前の VoteBankHash を累積する必要があります。

BankHash の計算

すべての楽観的確認済みブロック(すべてのブロックに対して構成可能)について、バリデーターはUserBankHashの計算を開始しますが、これにはすべての状態遷移が含まれますが、VoteBankHash計算で考慮されたトランザクションは除外されます。

BankHash は、(VoteBankHash, UserBankHash) の累積から派生します。 バリデータの上位99.5%は、100時間帯ごとに投票の一部としてBankHashを提出しています。 100 タイムスロットごとにコミットされますが、すべてのタイムスロットで計算されます。 ごく一部のノードが、非決定論的が観察されないソフトシグナルとしてゴシップでBankHashを一貫して送信する価値があるかもしれないことは注目に値します。

バリデーターの67%未満が完全なBankHash計算を提出した場合、リーダーはユーザートランザクションと書き込み可能なアカウントに利用可能なブロックスペースを50%削減する必要があります。 この措置は、再生時間を過度に増加させる可能性のある悪用からチェーンを保護するためのものです。

BankHash は、以前の BankHash を蓄積する必要があります。

銀行のリーダーのところへ

ブロック作成中は、リーダーがブロック作成に使用した状態を取得できない可能性が高く、ブロック作成期間中にすべてのトランザクションを実行するのは理想的ではありません。

*リーダーは、有料アカウントの残高のキャッシュを維持します。

• 有料アカウントがシステム転送のソースとして、またはシステムプログラムとともに別のプログラムに渡される書き込み可能なアカウントとして使用される場合、有料アカウントの残高は 0 に設定されます。
• ブロックは、ブロックがいっぱいになるまで、宣言された計算ユニット (CU) に従って、ローカル料金の優先順位でパックされます。 ※手数料は有料アカウントの残高キャッシュから差し引かれます。 *有料アカウントの残高のキャッシュは、BankHashの計算によって補完されます。

ネットワークは、アーカイブに格納されたバイト数と、ブロック内のトランザクションを伝播するために必要な帯域幅のみで構成され、トランザクションスパムの失敗に対するコストは比較的少なくなります。

バリデーターがすでに収益の最大化を目指していることを考えると、有料アカウントの正確なキャッシュを維持するための十分なインセンティブがあります。 さらに、ペナルティが設定されていなければ、どのネットワークでも、長期的には誰でも簡単にキャッシュを提供できます。 サーバーが破損した場合、バンクレスのリーダーオペレーターは、複数のソースから簡単に切り替えたり、サンプリングしたりできる必要があります。

つまり、バリデーターは収益を最大化したいというモチベーションから、有料アカウントの正確なキャッシュを維持するよう努めます。 ペナルティメカニズムがない場合、このキャッシュはネットワーク内の任意のノードによって長時間提供される可能性があります。 さらに、サーバーに障害が発生した場合、バンクリーダーのいないオペレーターは、複数のソースから簡単に切り替えたり、サンプリングしたりできる必要があります。

トレードオフ

主なトレードオフは、ユーザーステートにサービスを提供するフルノードに、その配信ステータスが承認されたレストとまったく同じであることを確認するための確認署名がないことです。 状態に関する唯一の権威ある説明は、各トランザクションが台帳で順番に再生される場合でも、同じままである必要があります。 パフォーマンスを最適化しても、結果が変わることはありません。 したがって、フォークがファイナライズされると、ランタイム実装にエラーがない限り、正しい状態のみが計算に残ります。

状態を確実に提供するように設計されたノードは、複数のマシンとクライアントを実行する必要があり、状態の実行に不一致がある場合は、動作を停止する必要があります。 これは、ネットワークの残りの部分だけに頼ると、ほとんどの整合性の仮定が発生するため、オペレーターが今日行うべきことです。

ユーザーは、BankHashをアサートしたり、中止をトリガーしたりするトランザクションに署名することもできます。 ネットワークの残りの部分は、計算された正確な BankHash が RPC プロバイダーによってユーザーに提供する BankHash とまったく同じである場合にのみ、これらのトランザクションを実行します。

ステートレスコンセンサスノードの長期ロードマップ

固定サイズの承認を持つネットワークは、開始するのに必要な状態はごくわずかです。 承認自体とその誓約の重み、およびすべての議決権口座の残高。 これは、非常に少量のメモリと小さなスナップショット ファイルであり、再起動時にすばやく配布および初期化できます。

承認がフルノードと矛盾している場合、承認とステータスの両方を追跡しているフルノードは実行を停止します。 これは、承認とステータスの間に不一致がある場合、取引所、法定通貨チャネル、RPC、ブリッジなどがすべて機能しなくなることを意味します。 これには、欠陥のあるステートレスコンセンサスノードのごくわずかな割合しか必要ありません。

バンクレスのリーダーは、複数のフルノードのサンプルに依存して、有料アカウントの初期残高のキャッシュを提供できます。 たとえ欠陥があったとしても、結果はコンセンサスの失敗ではなく、ブロック内のスパムになります。 オペレーターは、リーダーの健康状態とブロックに注入するスパムの割合を監視し、障害に迅速に対応できる必要があります。