Solana共同創設者：Solanaの究極のアーキテクチャを解説
TechFlow厳選深潮セレクト
Solana共同創設者：Solanaの究極のアーキテクチャを解説
すべての非投票取引は、非同期で計算可能である。
Web3業界の深掘り報道に専念し潮流を洞察執筆：Anatoly Yakovenko、Solana CEO（共同創設者兼CEO）
翻訳：1912212.eth、Foresight News
Solanaの目標は、物理法則に従って、単一かつ許可不要のグローバルステートマシンをできる限り迅速に同期させることです。この目標を達成できると考えられるアーキテクチャは以下の通りです。
-
1万を超える多数の完全ノード（N > 10,000）
ネットワークがグローバルステートマシンとして機能するためには、多数の完全ノードをサポートする必要があります。Turbineは、現代のハードウェアおよびネットワーク上で、非常に大規模なネットワークへの高速レプリケーションがスケーラブルであることをすでに実証しています。
-
1万を超える多数のブロック生成リーダー（N > 10,000）
-
並行する複数のリーダーが同時にブロックを生成し、ランダムに4～16の範囲で選択される。
並行リーダーにより、ネットワークはユーザー取引の順序付けを世界中の複数の場所で行えるようになります。これにより、ユーザーとネットワークとの間の距離が短縮され、トランザクションがチェーンに追加される前に全ノードによる検証が必要となる状況が排除されます。
-
ブロック時間は120ミリ秒
短いブロック時間は迅速な最終性ポイントを生み出し、検閲耐性を高め、ユーザーエクスペリエンスを向上させ、取引の再順序化ウィンドウを縮小し、全体的なネットワークスピードを加速します。
-
承認委員会に所属する投票コンセンサスノードが200～400程度存在し、リーダーはランダムに選ばれ、各エポックごとに4～8時間でローテーションする。
コンセンサスはフォーク選択にとって不可欠であり、これはネットワーク分断時に発生します。200以上のノードからなるサンプルは統計的にネットワーク内のすべての主要な分断を代表し、それらの実際の分布に密接に一致します。したがって、すべての完全ノードが投票する必要はなく、200もあれば十分です。承認を委員会に限定することで、120ミリ秒のブロック時間を支えるために必要なメモリおよびネットワーク帯域幅を削減できます。ブロック時間の短縮は当然ながら1秒あたりに送信される投票数を増加させ、コンセンサスに割り当てられたリソースに一定の負荷をかけます。
120ミリ秒ブロックにおける真の課題は、すべてのユーザー取引をリプレイすることです。ネットワークは許可不要であるため、任意のユーザーコードを確実なタイミングで実行できる均質な実行環境を保証することは極めて困難です。可能性はあるものの、ユーザー取引に利用可能な計算リソースを制限し、各ノードが最悪の場合に備えて過剰構成されていることを確認するしかありません。
しかし、フォークの支持やフォーク上での構築を行うリーダーに対するコンセンサスノードの投票において、完全な状態を実行する理由はありません。コンセンサスノードとリーダーの承認を同期させるには、各期間に1回だけ状態を計算すれば十分です。
非同期実行
動機
同期実行では、すべての投票およびブロック作成ノードが、いかなるブロックにおいても最悪ケースの実行時間を特定するために極めて高い構成を要求されます。非同期実行は、ほとんどトレードオフがないという稀なケースの一つです。コンセンサスノードは投票前に少ない作業しか行う必要がありません。作業を集約・バッチ処理することで、キャッシュミスなしに効率的に実行できます。さらには、コンセンサスノードやリーダーとはまったく異なるマシン上で実行することさえ可能です。同期実行を希望するユーザーは、ネットワーク全体の待機なしにリアルタイムで各ステート変換を実行できるよう、十分なハードウェアリソースを割り当てることができます。
アプリケーションおよびコア開発者の多様性を考慮すると、年1回の主要プロトコル変更を計画するのは妥当です。もし一つを選ぶなら、私の選択は非同期実行です。
概要
現在、バリデータは各ブロックですべての取引をすばやく繰り返し、ブロックの完全な状態を計算してから初めて投票を行います。本提案の目的は、フォーク選択の投票決定とブロックの完全な状態遷移の計算を分離することです。
承認内で投票を行うバリデータは、フォークを選択するだけでよく、そもそも何の状態も実行する必要はありません。各エポックごとにのみ、次の承認を計算するために状態を必要とします。
投票手順は独立して実行できるように調整されます。ノードは投票前にのみ投票手順を実行します。バリデータはあまりスペースを消費しないため、メモリ要件は比較的小さくなります。投票は非常に予測可能な実行時間を持つため、投票手順の実行はほぼジッターが発生しません。
すべての非投票取引は非同期で計算できます。これにより、すべての非投票取引をバッチリプレイし、すべてのプログラムに対してJITを事前取得して先回りで準備することが可能になり、ほぼすべてのキャッシュミスが排除されます。長期的な目標は、リアルタイムで低遅延の完全状態計算を必要とするマシンのみがそのタスク用に構成されることです。おそらく、ユーザーは追加のハードウェアに対して料金を支払うことになるでしょう。
一旦フォーク選択と状態実行が分離されたら、進捗を加速することがより容易になります。
-
非同期実行
-
各エポックで固定数の投票委員会をローテーション
-
200ミリ秒のブロック時間
ユーザー取引のリプレイがフォーク選択をブロックしなくなるため、ブロック時間を短縮してもジッターはもはや問題になりません。唯一考慮すべき点は、200ミリ秒の場合、バリデータの投票レートが倍になることです。承認の計算方法についてかなり直接的な変更を行うことで、承認サイズを200または400、あるいは適切と思われる他の数字に固定できるようになります。
実行とコンセンサスを完全に分離することもまた自然な流れです。再起動は、固定サイズの承認内にある投票プログラムアカウントのコンセンサスノードをチェックするだけで済むため、はるかに迅速になります。
実際に、確認時間は向上すると考えられます。なぜなら、承認の大多数は可能な限り速やかに投票を行い、その投票が伝播している間に、完全状態の実行結果をユーザーに提供するノードが同時並行で取引を実行できるからです。したがって、今日見られるようなリプレイ時のジッターは、投票ネットワークの伝播と同時に行われるはずです。
投票
-
投票アカウントは、2つのエポックの投票をカバーできるだけの十分な量のSOLを保有していなければなりません。
-
投票取引はシンプルなものでなければなりません。複雑な投票は必ず失敗します。ブロック生成者は複雑な投票を放棄すべきです。
-
SOLを投票アカウントから引き出すことは可能ですが、残高が1エポック分の投票を下回ってはいけません。
-
すべてのlamportsをゼロにするには、Vote CLOSE命令が完全なエポックの経過を必要とします。エポック1で投票アカウントがCLOSEにマークされても、CLOSE処理はエポック2になってから行われます。CLOSEによりすべてのSOLを引き出し、投票アカウントを削除できます。一度CLOSEにマークされたアカウントは完全に削除される以外に選択肢はなく、再オープンできません。
-
投票には通常のBankHashではなくVoteBankHashを含みます。
リーダー管理および承認
以下の条件を満たすバリデータのみが：
-
ステーキング量 > X
-
およびSOL > 2エポック分の投票
-
かつCLOSEにマークされていない
リーダースケジュールに参加でき、承認にカウントされます。バージョン2では、LeaderScheduleとQuorumを分離でき、それぞれの要件は同一である必要はありません。
VoteBankHashの計算
すべての取引を含めてBankHashを計算する代わりに、バリデータはLeaderScheduler内のバリデータに関連するシンプルな投票取引に対してのみVoteBankHashを計算します。他のすべての取引は無視されます。すべての投票をリプレイした後、VoteBankHashは現在のBankHashと同じ形式で計算されます。
VoteBankHashは、完全なBankHashではなく、以前のVoteBankHashを累積すべきです。
BankHashの計算
すべてのoptimistic確認済みブロック（すべてのブロックに設定可能）について、バリデータはUserBankHashの計算を開始します。UserBankHashにはすべての状態遷移が含まれますが、VoteBankHash計算で既に考慮された取引は除外されます。
その後、BankHashは（VoteBankHash, UserBankHash）の累積から導出されます。上位99.5%のバリデータは、100スロットごとにBankHashを投票の一部として提出します。100スロットごとに提出されるものの、各スロットで計算は行われます。少数のノードが常にgossipを通じてBankHashを提出し、非決定性が観測されていないというソフトシグナルとして扱う価値があるかもしれません。
67%未満のバリデータしか完全なBankHash計算を提出しない場合、リーダーは利用可能なユーザー取引および書き込み可能なアカウントのブロックスペースを50%削減すべきです。これは、リプレイ時間を過度に長くする可能性のある乱用からチェーンを保護するための措置です。
BankHashは、以前のBankHashを累積すべきです。
バンクローダーの廃止
ブロック作成中、リーダーはブロック作成に必要な状態を取得できない可能性があり、またブロック作成中にすべての取引を実行するのは望ましくありません。
-
リーダーは支払いアカウント残高のキャッシュを維持します。
-
支払いアカウントがシステム転送の送信元として使用される場合、またはシステムプログラムとともに別のプログラムに渡される書き込み可能なアカウントとして使用される場合、その支払いアカウントの残高は0に設定されます。
-
宣言された計算ユニット（CUs）に基づき、ローカルの手数料優先度でブロックをパッキングし、ブロックが満杯になるまで続けます。
-
支払いアカウント残高キャッシュから手数料を差し引きます。
-
支払いアカウント残高キャッシュはBankHash計算によって補充されます。
ネットワークが取引スパムによって発生するコストは比較的小さく、アーカイブに保存されるバイト数とブロック内取引の伝播に必要な帯域幅に限られます。
バリデータはすでに自身の収益を最大化しようとしているため、正確な支払いアカウントキャッシュを維持するインセンティブが十分にあります。さらに、ペナルティメカニズムがなくても、長期的にはネットワーク内の誰でも簡単にこのキャッシュを提供できます。サーバー障害時には、バンクローダーを持たないオペレーターは複数のソースから簡単に切り替えたりサンプリングしたりできるべきです。
つまり、バリデータが収益の最大化を目指す動機があるため、彼らは正確な支払いアカウントキャッシュを維持しようと努力します。ペナルティメカニズムがなくても、このキャッシュは長期的にネットワーク内の任意のノードによって提供される可能性があります。また、サーバーに障害が発生した場合でも、バンクローダーを持たないオペレーターは複数のソースから簡単に切り替えまたはサンプリングできます。
トレードオフ
主なトレードオフは、ユーザー状態を提供する完全ノードが、自らの提供する状態が承認の残り部分と完全に一致していることを確認するための署名付き確認を得られない点です。ステートの唯一の権威ある解釈は、帳簿内で各取引が順番にリプレイされたとしても変わらず、どのパフォーマンス最適化も結果を変えてはなりません。したがって、一旦フォークが確定すれば、ランタイム実装に誤りがなければ、正しい状態の計算結果はただ一つだけになります。
信頼性を持って状態を提供しようとするノードは、複数のマシンとクライアントを稼働させ、状態実行に差異が生じた場合は即座に運用を停止すべきです。これは本質的に、運営者が今日行うべきことと同じであり、ネットワークの残り部分に依存するだけでは正直な大多数という仮定を導入してしまうためです。
ユーザーは、BankHashを表明するか中止をトリガーする取引に署名することもできます。これらの取引は、RPCプロバイダーがユーザーに提供するBankHashと、正確に計算されたBankHashが完全に一致した場合にのみ、ネットワークの残りの部分によって実行されます。
長期的なステートレスコンセンサスノードのロードマップ
固定サイズの承認を持つネットワークは、起動に必要な状態量が非常に小さくて済みます。承認自体とそのステーキング重み、およびすべての投票アカウント残高だけです。これは非常に小さなメモリ量であり、すばやく配布でき、再起動時にすばやく初期化できる微小なスナップショットファイルです。
承認と完全ノードが不一致の場合、承認と状態の両方を同時に追跡している完全ノードは動作を停止します。これはつまり、承認と状態が乖離した場合、取引所、法定通貨チャネル、RPC、ブリッジなどがすべて停止することを意味します。このような事態は、ごく少数の欠陥のあるステートレスコンセンサスノードによっても引き起こされ得ます。
バンクローダーを持たないリーダーは、複数の完全ノードからのサンプルに依存して、支払いアカウントの初期残高キャッシュを提供できます。たとえ欠陥があっても、結果はコンセンサスの失敗ではなく、ブロック内のスパムになるだけです。オペレーターはリーダーの健全性とブロックに注入されるスパムの割合を監視し、障害に迅速に対応できるべきです。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@anatolyakovenko
