非同期プログラム実行：新たなSolana APE-ochの幕開け

はじめに

活発な議論と発表が相次いだ今年のBreakpointカンファレンスで、Solana共同創設者のAnatoly Yakovenkoは、即興かつ録画なしの技術ワークショップを1回だけ開催しました。フリップチャートとマーカーを手に、彼がSolanaの次なる進化として情熱的に推進し、本記事の中心テーマでもある非同期実行の仕組みを詳しく解説しました。

非同期実行（以下、AE）という壮大なビジョンを理解する第一歩として、まずAEの中核となる概念と目的を概説します。次に、将来提案されるアーキテクチャを比較分析するための基礎として、Solanaの現行の実行およびコンセンサスメカニズムを確認します。その後、この移行に不可欠な足掛かりとなるBankless Leadersから始め、AEをめぐるさまざまな提案を詳しく見ていきます。また、2022年の初期設計案から、複数のブロック生成者が同時に動作する設計実装を含み、AEの範囲を超える最近の「Endgame Architecture」提案までを時系列で取り上げます。

AE：高度1万フィートからの概観

SolanaのコアプロトコルにおけるAEとは、実行とコンセンサスを分離し、それぞれが互いに独立して動作できるようにするアーキテクチャ上のアプローチです。ネットワークは、トランザクションを実際に実行せずに、その順序についてコンセンサスを形成します。順序への合意後は、誰でもトランザクションを実行して正しい結果を明らかにできます。

このアプローチでは、リーダーは投票以外のトランザクションを実行せずにブロックを構築し、Turbine経由でネットワーク全体に伝播します。バリデータも、投票以外のトランザクションを実行せずにブロックへ投票できます。コンセンサスはトランザクションの順序と可用性だけを対象とするため、コンセンサス形成に必要な時間と手順が大幅に削減されます。DBAのJon Charbonneauによる要約を言い換えると、順序が真実を決定し、実行がそれを明らかにします。

これは、リーダーがトランザクションを実行してからブロックに格納し、すべてのバリデータが投票前にブロック内のトランザクションをリプレイする現在のコンセンサス方式とは大きく異なります。

AEが可能な理由は次のとおりです。

1. フォーク選択はプログラムの実行に依存しません
2. 決定論的な状態遷移関数があれば、計算可能な正しい状態は1つだけです。最終的には全員が同じ最終状態を算出します
3. 無効なトランザクションは破棄できます。失敗したトランザクションのスパムがネットワークに与えるコストは比較的低く、トランザクションの伝播に必要なTurbineの帯域幅と、台帳内でトランザクションが占有する追加ストレージに限られます
4. 専用RPCサービスプロバイダーが運用するマシンなど、リアルタイムかつ低レイテンシで完全な状態計算を必要とするマシンは、その目的に合わせて明示的にプロビジョニングできます

AEには多くの利点が期待できます。

Yakovenkoはさらに踏み込み、次のように述べています。「非同期実行は、実質的にトレードオフが存在しない珍しいケースの1つです。」

1. ブロック時間の短縮（200ミリ秒）
2. ブロック時間の安定性向上
3. バリデータ要件の引き下げ
4. ユーザー体験の向上（ファイナリティの高速化）
5. 検閲耐性の強化
6. トランザクションを並べ替えられる時間枠の短縮
7. ブロック間での未使用容量の繰り越し
8. Multiple Concurrent Block Producersへの道筋の提供（詳細は後述）

本記事では、AEがこれらの利点を具体的にどのようにもたらすのかを解説します。

AEは、投票プログラムをほかのすべてのプログラムから独立して動作させる仕組みとも捉えられます。投票プログラムとシステムプログラム（常に必須）が、エポック内のコンセンサスに必要な唯一のプログラムです。

SolanaにおけるAEの議論は数年前から続いています。Anatoly Yakovenkoが最初に正式提案したAPEX（Asynchronous Program Execution）は、2022年4月にさかのぼります。SolanaでAEを実用的に実装する方法の具体的な詳細は、複数のSIMDや記事に分散しています。本記事では、それらをほぼ時系列で取り上げます。Yakovenkoは間違いなくSolanaコミュニティで最も強力にAEを支持し、提唱している人物であり、インタビューやポッドキャストへの出演時には、ほぼ必ずこの話題を取り上げています。

用語

AEの議論で重要になる2つの用語、Bankless LeadersとMultiple Concurrent Block Producers（MCBP）を簡単に定義しておくと理解しやすくなります。要約すると次のとおりです。

• Bankless Leader：トランザクションを実行せずにブロックを作成できるリーダー
• Asynchronous Execution（AE）：コンセンサスと実行の完全な分離
• Multiple Concurrent Block Producers（MCBP）：その名のとおり、同じスロット内で複数のブロックを同時に生成する仕組み‍

Bankless Leadersは、完全なAEを実現するために必要なステップです。同様に、AEの実装成功は、その後Multiple Concurrent Leaders（MCL）とも呼ばれるMultiple Concurrent Block Producers（MCBP）を導入するうえで不可欠です。AEの議論は、MCBPの議論と一緒に扱われることがよくあります。Yakovenkoは、どちらもSolanaの「Endgame Architecture」に不可欠な要素として提唱しています。

このようなアーキテクチャ強化を検討しているブロックチェーンはSolanaだけではありません。Monadは、コンセンサスと実行を別々のスレッドに分離してAEを実装する予定です。同様に、Ethereumの研究コミュニティでも、複数の提案者を同時に導入する可能性が以前から検討されています。

Yakovenkoの提案を実装するにはSolanaのコアプロトコルを大幅に変更する必要があるため、現在もコミュニティ内で議論が続いています。AEが最善の道だという意見で全員が一致しているわけではありません。Yakovenkoが提案するEndgame Architectureを完全に実装すれば、Solanaの運用が根本的に変わり、プロトコル全体の複雑性が増すと言っても過言ではありません。

AEを詳しく検討する前に、Solanaにおける現在の実行とコンセンサスの仕組みを振り返る必要があります。特に、本記事の後半で参照する要素に注目します。また、投票トランザクションと非投票トランザクションのデータを分析し、後の議論に役立つ追加の知見を明らかにします。これらの機能をすでに十分理解している読者は、次のセクションを読み飛ばしても構いません。

同期実行（現在のSolana）

実行

Solanaは継続的ブロック構築を採用しており、割り当てられた400ミリ秒のスロット内で、ブロックを動的に組み立てながらストリーミングします。リーダーには交代まで4つの連続スロット（1.6秒）が割り当てられます。ブロックがネットワークに受け入れられるには、リーダーがブロック内の各トランザクションを検証して実行しなければなりません。さらに、コンセンサスに参加するほかのすべてのアクティブなバリデータも、ブロック内の全トランザクションを再検証して再実行します。

リーダーは、Gulfstream上でQUICを介してトランザクションパケットを受信します。パケットは、ブロック生成を担うリーダーの中核ロジックであるTransaction Processing Unit（TPU）に入ります。TPUがパケットを受信するポートは3つあります。

• tpu：トークン転送、NFTミント、プログラム命令などの通常のトランザクションを処理します
• tpu_vote：投票トランザクションだけを処理します
• tpu_forwards：現在のリーダーがすべてのトランザクションを処理できない場合、未処理のパケットをこのポート経由で次のリーダーへ転送します‍

順序付けや実行を始める前に、すべてのトランザクションパケットに対して厳格な検証と健全性チェックが行われます。これには、署名検証、署名数が正しいかの確認、重複トランザクションの除外が含まれます。なお、投票トランザクションと非投票トランザクションでは、署名検証プロセスが異なります。

ブロック構築はBanking Stageで行われます。bankとは、特定のブロック時点の状態です。トランザクションは並列処理され、台帳のentry、つまり競合しない64件のトランザクションからなるバッチにまとめられます。すべてのトランザクションには、読み書きするアカウントの完全なリストが含まれます。この設計により、バリデータは各entry内で競合しないトランザクションだけを容易に選択して実行できます。同じアカウントに書き込む場合（書き込み同士）、または同じアカウントを読み書きする場合（読み取り＋書き込み）、トランザクションは競合します。競合するトランザクションは別々のentryに入り、順次実行されます。一方、競合しないトランザクションは並列実行されます。

6つのスレッドがトランザクションを並列処理し、そのうち4つが非投票トランザクション専用、2つが投票トランザクション専用です。コンセンサス投票はBanking Stage内で優先トランザクションとして扱われます。価格は一律0.000005 SOL、消費する計算ユニット（CU）は2,100で、Vote Programによって実行されます。 

トランザクションがentryにまとめられると、Solana Virtual Machine（SVM）によって実行されます。トランザクションに必要なアカウントがロックされ、トランザクションが最近のもので、まだ処理されていないことが確認されます。アカウントが読み込まれ、トランザクションロジックが実行されてアカウントの状態が更新されます。entryのハッシュは記録のためProof of History（PoH）サービスへ送信されます。成功すると、すべての変更がbankにコミットされ、各アカウントのロックが解除されます。

プロトコルは、ブロック内の有効なトランザクションの順序を規定していません。チェーンの最終状態は、確認されたすべてのトランザクションの結果です。この状態は、ブロックチェーンの履歴から常に決定論的に再現できます（つまり、Genesisまたはスナップショットから台帳をリプレイします）。

各bankには、以下のSHA256ハッシュである対応するBankHashがあります。

• 親BankHash - 直近の親ブロックのBankHash
• アカウントDeltaHash - 現在のブロックで状態が変化したすべてのアカウントによる16分木のMerkle treeルート
• 署名数 - 現在のブロック内にあるトランザクション署名の総数
• 最後のBlockhash

hashv(&[
	parent_bankhash,
	accounts_delta_hash,
	num_sigs,
	blockhash,
])

BankHashは、バリデータが各スロットで投票する暗号学的コミットメントです。

コンセンサス

バリデータが投票プロセスを行うには、3つのアカウントが必要です。

Identity Account

このシステムアカウントは、すべての投票トランザクションの署名者兼手数料支払者です。サーバーハードウェアに直接保存されるホットキーペアです。その名のとおり、このアカウントの公開鍵がバリデータのネットワークIDとして機能します。投票アカウントの作成にはIdentity Accountが必要です。

Vote Account

委任者がSOLを委任するアカウントです。このアドレスはアカウントの検索に使用され、トランザクションの署名には使用されません。

Withdrawal Account

このアカウントは、投票アカウントから資金を引き出すために使用されます。Identity Accountを変更することもできます。このアカウントの秘密鍵は通常、安全なマルチシグまたはコールドウォレットに保管され、バリデータIDおよび投票権限のキーペアとは異なるものでなければなりません。

バリデータが署名する各投票（例）には、バリデータの公開鍵と、投票対象のブロックを識別するハッシュが含まれます。バリデータが正しく有効な投票を送信すると、クレジットを獲得します。

ネットワークは、新しく生成されたブロックについてすべてのバリデータが合意するのを待たずに次のブロックを生成します。そのため、同じ親ブロックに2つの異なるブロックがつながり、フォークが発生することも珍しくありません。バリデータはこれらのフォークに投票し、元のPractical Byzantine Fault Tolerance（pBFT）の一種であるTower BFTを使用して、採用するフォークを決定する必要があります。 

競合するフォークが存在する場合、ネットワークはいずれか1つをファイナライズし、バリデータは破棄されたフォーク内のブロックを放棄します。各スロットにはあらかじめリーダーが決められており、そのリーダーのブロックだけが受け入れられます。1つのスロットに2つのブロックを提案することはできません。したがって、発生し得るフォークの数は、リーダー交代スロットの境界で生じる「存在する／存在しない」というスキップリストに限定されます。 

バリデータがフォークを選択すると、ロックアウト期間が終了するまでそのフォークにコミットされます。つまり、最低限の期間はその選択を維持しなければなりません。この仕組みにより、バリデータには、採用される可能性が最も高いと考えるフォーク、すなわち「最も重い」フォークへ慎重に投票するインセンティブが生まれます。

3分の2の圧倒的多数が投票すると、ブロックは楽観的に確認されたと見なされます。その上に31個のブロックが構築されると、ファイナライズされたと見なされます。Solanaの歴史上、楽観的に確認されたブロックがファイナライズされなかった例は一度もありません。

フォークがファイナライズされると、ブロックはbankのアカウント更新とともにルート化され、その祖先がディスクへ書き出されます。また、ファイナライズされたbankの祖先ではない以前のbankによるアカウント更新はすべてプルーニングされます。

投票トランザクションと非投票トランザクション

ここまで見てきたように、Solanaでは、トランザクションの実行プロセスとTower BFTによるコンセンサス形成が密接に結び付いています。投票トランザクションと非投票トランザクションは同じ経路をたどります。entryにまとめられ、SVMで実行され、Proof of History（PoH）ストリームに刻印された後、Turbineを介してネットワークへ配信されます。この統一されたプロセスにより、バリデータがコンセンサス状態を一貫して認識できます。投票をgossipサービスだけで伝播すると、バリデータ間で不一致が生じる可能性があります。その結果、どのフォークが正しい可能性が高いかについて、バリデータごとに異なる見方を持つことがあります。継続的なブロック構築には継続的な投票が必要であり、特に以前のブロックを確認している間は重要です。

この一括処理の副作用として、Solanaの1秒あたりのトランザクション数（TPS）指標をめぐる論争があります。未加工の数値には投票トランザクションと非投票トランザクションの両方が含まれますが、業界の多くの同等ネットワークではそうではありません。そのため、投票トランザクションを除外し、トランザクション処理能力をより正確に示す「実質TPS」という指標が採用されるようになりました。

最近のSolanaのアクティビティを見ると、投票トランザクションは1ブロック当たり平均1,000件弱で、非投票トランザクションを上回っています。

投票トランザクションが1ブロック当たりの総計算ユニットに占める割合はごくわずかです。平均は1ブロック当たり200万CU強で、常に210万～230万CUの範囲に収まっています。これはSolanaブロックの4,800万CUという計算上限のわずか4.5%です。

投票トランザクションは、非投票トランザクションと比べて、処理時間と必要な計算量の面で非常に安定しています。これは本記事の後半で再び取り上げる重要な点です。非投票トランザクションのCUは一定せず、ハードウェアの利用効率を低下させます。 ‍

ランタイムで正確な実行時間を保証することは難しく、実際には概算値に近いものです。平均的にはブロック時間を400ミリ秒以内に収めることを目指していますが、時折急増します。こうした急増はバグと見なすことができ、特定と修正の取り組みが継続的に進められているため、改善が続いています。

1エポックは432,000スロットで構成されます。各スロットが正確に400ミリ秒なら、1エポックはちょうど48時間になります。しかし、過去のデータから分かるように、エポックがこの目標を達成することはほとんど、あるいはまったくありません。過去1年間では、通常1エポックに2.1～2.3日かかっています。

同期実行では、コンセンサスに参加するステーキング済みのすべてのバリデータが、任意のブロックにおける最悪の実行時間に対応できるよう、過剰なリソースを備える必要があります。そのため、Solanaのバリデータのハードウェア要件は比較的高くなっています。

以上で、Solanaの現在のコンセンサスと実行の仕組みについて、主に後の議論に関連する部分を中心とした確認を終えます。より包括的な概要については、以前のHeliusブログ記事であるコンセンサス、PoH、Turbine、Solanaの仕組みを読むことをお勧めします。次のセクションでは、Solanaのプロトコル設計に今後加えられる変更を検討します。

APEX、2022年

YakovenkoによるAEの最初の正式提案は2022年4月にさかのぼり、APEX（Asynchronous Program EXecution）と題されています。この比較的短い提案では、コンセンサスを実行から分離する実用的な詳細が示され、状態を2つの隔離されたドメイン、デフォルトの「Domain 0」とVote Programの「Domain 1」に分割する概念が導入されています。この構成により、Vote Programがbankのほかの部分から分離されます。‍

すべてのアカウントはいずれか1つのドメインに属し、トランザクションは複数のドメインにまたがるアカウントを読み書きできません。そのようなトランザクションは即座に失敗し、無視されます。System Programは両方のドメインに存在し、Domain 1ではVote Programだけがそれ以外のプログラムです。

特殊なシステム命令（SystemInstruction::MoveDomains）により、投票アカウントとの間でSOLを転送できるよう、アカウントがエポックごとに1回ドメイン間を移動する仕組みが提供されます。

この提案では、BankHashに対応するForkHashの概念も導入されています。ForkHashの計算ではDomain 1のVote Program命令だけを評価し、BankHashではDomain 0のVote Program以外のすべての命令を評価します。投票命令はForkHashを参照します。BankHashの計算は、コンセンサスバリデータが投票するルートの外部で行われます。従来、フォークを選択して投票するには、bank内のすべてのトランザクションを完全に評価し、実行する必要がありました。今後、フォーク選択で評価されるのはVote Programに関係するトランザクションだけです。

この初期設計には未解決の疑問が多く残されていますが、後で再び取り上げる隔離ドメインという基礎概念を確立しています。

Bankless Leaders

Bankless Leaderとは、非投票トランザクションを実行せずにブロックを生成できるリーダーであり、AEの実装に不可欠な前提条件です。AnzaのエンジニアAndrew Fitzgeraldは、The Road to Banklessと題したブログ記事で、同じくAnzaのTao Zhuによる以前のBankless Leader提案（SIMD-005、2022年12月、クローズ済み）を発展させています。FitzgeraldはSolanaにBankless Leadersを導入するために必要な複数の変更を説明し、AEの実装を制限するプロトコル上の制約を、ブロック制約、entry制約、トランザクション制約という3つの主要カテゴリーに分類しています。

現在は、これらの制約のいずれかに違反するとブロック全体が無効になります。これらの制限をなくすことで、SolanaプロトコルはAEへの道を開き、ブロックの生成と検証における柔軟性を高められます。以下に、各種制約の概要を示します。‍

ブロック制約

ブロック全体に課される制約で、次のものが含まれます。 

• ブロックには64個のtickを含める必要があります
• ブロックの最後のentryはtickでなければなりません
• すべてのブロックentry内のトランザクションは、ブロックの上限内に収まる必要があります

Entry制約

このカテゴリーの主な制約は、entryに競合するトランザクションを含められないことです。Fitzgeraldは昨年11月、この問題に特化したSIMD 0083：Entry制約の緩和を提出しました。このSIMDは承認されています。

トランザクションレベルの制約

最大のカテゴリーで、3つのサブカテゴリーに分けられます。

静的制約

追加の状態を把握しなくても検証できる制約です。これには、署名検証、トランザクションサイズ、読み取り／書き込みアドレスリストに記載されたアカウント数、トランザクションデータ形式への準拠（つまり、トランザクションをデシリアライズできること）が含まれます‍

トランザクションレベル制約のこのサブカテゴリーは、変更する必要がありません。

Bank状態の制約

トランザクション署名が最近のブロックにまだ含まれていないことを確認する一意性チェックと、経過時間の検証（つまり、トランザクションに最近のblockhashを含める必要があること）が含まれます

このサブカテゴリーでは、bankの直近の状態を把握する必要があります。

アカウント状態に基づくトランザクション制約

最も制限の厳しいサブカテゴリーで、Address Lookup Table（ALT）の解決、nonceチェック、手数料支払者のチェック、実行可能性のチェックが含まれます

このサブカテゴリーでは、以前のトランザクションを把握する必要があります。

Fitzgeraldは、現在もオープンになっているSIMD 0082：トランザクション制約の緩和で、このカテゴリーの制約に対する変更を正式に提案しました。

Fitzgeraldが指摘するように、AEの主な要件は、ブロック検証がアカウント状態に依存してはならないことです。ブロックの検証に以前のトランザクション結果が必要であれば、そのブロックを非同期で実行することはできません。したがって、ブロック検証におけるアカウント状態への依存を排除する必要があります。さらに、これらの制約の多くは不必要に厳格です。

たとえば、署名者が手数料を支払うのに十分なlamportsを保有していないトランザクションは、現行プロトコルでも提案された変更後でも実行されるべきではありません。ただし、提案された変更後は、そのようなトランザクションが含まれていても、ブロックの残りの部分まで無効とは見なされません。

総じてFitzgeraldの研究は、AEへの道を開くためにBanking Stageをどのように変更できるかについて実用的な枠組みを提示し、AEの実現に必要なコンセンサス変更を伴う多くの手順を明らかにしています。

APExB 2023：AEとMCBPの融合

最初のAPEX設計から約1年後の2023年3月、Yakovenkoは非同期プログラム実行とブロードキャスト（APExB）SIMD 0023と題する、より包括的で詳細な提案を発表しました。この提案はAEの実装にとどまらず、複数同時ブロックプロデューサー（MCBP）の統合を含む、より広範なビジョンを示しています。

この提案では、リーダーとは別の主体である「ビルダー」という概念が導入されています。ビルダーは、非投票トランザクションのみで構成されるUserBlocksを作成するステーク済みノードです。これらのUserBlocksはTurbineツリーを介して伝播され、独自の「UserBlockSlots」を持ちます。デフォルトでは、通常のスロットごとに2つのUserBlockSlotsがあります。

ビルダーには、リーダーのスケジュールとは独立した独自のスケジュールがあります。複数のビルダーが同時にUserBlocksを構築するようスケジュールできます。コンピュートユニットは、ビルダーとUserBlockスロットの間で均等に分割されます。たとえば、2つのビルダー、2つのUserBlockスロット、4,800万CUの上限を持つブロックでは、UserBlockスロットのCU上限は1,200万（48/4）になります。

リーダーは通常どおりリーダースケジュールに従ってコンセンサス投票のブロックを作成し、同時にビルダーがユーザートランザクションのUserBlocksを生成して送信します。UserBlocksにはスロット番号が指定され、リーダーがブロックの一部を操作または除外できないよう、ビルダーによって署名されます。リーダーはTurbine経由でUserBlockを受信すると、そのUserBlockのハッシュを使用してUserBlockEntryを生成し、このUserBlockEntryをProof of History（PoH）に追加します。

バリデータは、付随するUserBlocksをまだ受信していないブロックには投票できません。そうしなければ、データが秘匿される可能性があり、全員がそのデータを実行できることを保証できないためです。ただし、UserBlockトランザクションを実行する前に投票だけを実行し、リーダーブロックに投票することはできます。バリデータは最も重いフォーク上のUserBlocksのみを実行し、投票時には最新のBankHashを送信するだけで済みます。これは古い親スロットに対するものでも構いません。バリデータはVoteHashesに投票します。これはAPEX 2022の提案におけるForkHashesと同じ役割、つまり投票トランザクション専用のBankHashとして機能します。

ビルダースケジュール

ネットワークブロックごとに10のUserBlockビルダーがある場合、各ビルダーにはTurbineのshredの10%と、利用可能なコンピュートの10%が割り当てられます。ビルダーは、ランダム方式と永続方式の2つのプロセスでスケジュールされます。

各エポックの境界では、ステーク加重の選択プロセスに基づいてランダムビルダーが割り当てられます。永続的なUserBlockスロットはダッチオークション方式で割り当てられ、最も多くのSOLをバーンする用意がある最高入札者が獲得します。

トランザクションの優先順位 

各UserBlockは、リーダーがエンコードしたUserBlockSlotの間に同時に作成されたものとみなされます。UserBlockSlot内の各UserBlockについて、トランザクションは実行前に優先手数料順に並べられます。異なる2つのブロックのトランザクションが同じ優先度を持つ場合、リーダーのPoHに先に現れるUserBlockの順に並べられます。つまり、優先手数料が実行優先度を決定します。 重複または無効なUserBlocksトランザクションは、状態を変更せずにスキップされます。複数のUserBlockEntriesに同じトランザクションが含まれている場合、2つ目はスキップされます。

上図：シナリオ1では、トランザクションBはPoHストリームへの到着が遅くても優先されます。シナリオ2では、トランザクションCはトランザクションDと同じ優先手数料ですが、そのブロックがPoHストリーム内で先にあるため優先されます。

この設計では、ビルダーがすべてのMEVを獲得します。ユーザートランザクションの手数料をビルダーとリーダーがどのように分配すべきかについては、この提案では未解決のままです。

ビルダーはBundleTransactionsも作成できます。これはUserBlock内のトランザクション群で、順序付けされた単一のバッチとして実行されるよう設計されています。これらのトランザクションには優先手数料を追加でき、現在のJitoバンドルの実装と同様に、バンドル全体を1つのバッチとして優先実行できます。

エポック境界

ステークの重みはフォーク選択に影響し、各エポック境界で更新されます。これは設計上、重要な意味を持ちます。バリデータは、そのエポック境界を越えて投票を続ける前に、非投票トランザクションの実行に追いついていなければなりません。

しかし、Yakovenkoは次のように述べています。「全体のCU上限は同期実行を前提に設定されているため、ノードがそこまで遅れることはありません。ただし、非同期実行の選択肢があれば、追いつくのははるかに容易です。ネットワーク処理を除いた生の台帳処理は20〜30倍高速です。」

考慮事項

複数のビルダーが存在すると、リソース管理はより複雑になります。クライアントは最寄りのビルダーを選択できますが、優先手数料はUserBlockごとに異なる可能性があり、ユーザーはトランザクション送信時にどのブロックが飽和する可能性があるかを把握できないでしょう。

利点には、スケジューリングの予測可能性があります。アプリケーションは、運用に必要なブロック帯域幅の割合に入札し、最終的にチェーンへ確実に決済される専用シーケンサーを作成できます。ランダムなUserBlockビルダーを含めることは重要です。永続的なブロックビルダーによるトランザクションの検閲や、最終的な取り込みの妨害を防げるためです。

2024年のSolanaにおけるAPE

今年6月に公開された非同期プログラム実行（APE）というXの記事で、Yakovenkoは2022年のAPEX提案で最初に説明した実行ドメインの概念をさらに具体化しています。

当初Domain 0およびDomain 1と呼ばれていた実行ドメインは、投票実行ドメイン（VED）とユーザー実行ドメイン（UED）に改名されました。その目的は変わらず、コンセンサス投票をトランザクション実行から完全に分離することです。

実行ドメインは、相互作用するキーと値を伴う個別のプログラム群として定義され、他の群とは独立して実行されます。

• 実行ドメインは異なるスレッドやコアで動作し、物理的に別のマシン上で異なる時点に完了できます 
• 実行ドメインAは、実行ドメインBの値を読み書きできません 
• ドメイン間では、いずれのドメインの実行中も整合性が保たれる状態を共有できます
• 手数料支払者が、トランザクションを実行するドメインを決定します
• ドメイン間の状態を同期し、キーと値の移動を可能にするプロトコルが必要です

投票実行ドメイン（VED）の構成要素

• SystemProgram：送金に使用されます
• VoteProgram：投票の中核プログラムです。このプログラムは静的であり、UEDとVEDの両方に存在する必要があります
• VoteProgram Sysvars：投票に使用される変数です
• 投票権限：投票を許可されたアカウントです
• 投票手数料支払者：投票に関連する手数料を支払うアカウントです
• 手数料支払者の資金提供元：SOLをVEDへ移動するために使用できる、更新可能なアカウントです

VEDに含まれないアカウントはUEDの一部とみなされます。

投票アカウントは有効化する必要があります。有効化された次のエポックでVEDに追加されます。無効化されると、次のエポックでVEDから削除されます。VEDへの資金の出し入れについては、正式なプロセスが定められています。

アカウントは、Linuxのファイル権限（Rは読み取り、Wは書き込み、Xは実行）に似た規則に従って、どの実行ドメインにマッピングされているかを追跡します。有効なマッピングは4つあります。

VEDとUEDの間を移動できるのは、Vote ProgramとSystem Programのアカウントのみです。System Programは、SystemアカウントとVote ProgramアカウントをVEDとの間で移動するためのインターフェースを提供します。このアプローチにより、明示的なFeePayerFundingアカウントは不要になります。任意のSystemアカウントをVEDとUEDの間で再マッピングし、ドメイン間で資金を移動できます。

リーダーは、自身が作成するブロックに対してVEDドメインのみを実行します。そのため、UEDの手数料支払者の状態について、部分的または不完全な情報しか持たない場合があります。ブロックを受信すると、バリデータはまずVEDトランザクションを実行します。結果として得られたVED状態からVED Hashを計算し、バリデータはそれを投票に使用します。 

UEDのリプレイでは、無効な手数料支払者を持つトランザクションをスキップします。UEDの状態更新では、UED Hashと呼ばれるBankhashを計算します。3分の1以上のバリデータが異なるUED Hashを送信した場合、すべてのノードを停止し、オペレーターに警告する必要があります。

新機能の有効化

コンセンサスが実行から分離されたため、VEDの投票がエポック境界をまたぐ可能性があるシナリオに対応できるよう、VoteProgramを設計する必要があります。その結果、新機能の有効化が、UED内でVoteProgramと相互作用するトランザクションとは異なるタイミングで発生する可能性があります。

Endgame Architecture 2024

2024年初頭、YakovenkoはEndgame Architectureを公開しました。これは、Solanaの将来を、ブロック時間120ミリ秒、10,000ノードのネットワークとして描く大胆なビジョンを示した文書です。この文書は、以前の設計提案を再確認して拡張すると同時に、この野心的なビジョンを実現する道筋としてAEの採用を重視しています。

Banklessリーダー

要約すると、次のとおりです。

● リーダーは手数料支払いアカウントの残高キャッシュを維持します

● 手数料支払者が、システム送金元の書き込み可能アカウントとして使用された場合、またはSystem Programとともに別のプログラムへ書き込み可能アカウントとして渡された場合、手数料支払い残高は0に設定されます

● ローカルの手数料優先順位に基づいてブロックが満杯になるまで、申告されたCUに基づいてブロックへ詰め込み、手数料支払者の残高キャッシュからトランザクション手数料を差し引きます 

● 手数料支払いアカウントの残高キャッシュはBankHashの計算によって補充されます 

リーダーは最初に、複数のフルノードまたはRPCへ照会して手数料支払者のアカウント残高を取得できます。まれにノードが誤ったデータを提供しても、コンセンサス障害ではなくトランザクション失敗につながるだけです。手数料支払者の残高が古い場合、コンセンサスに影響を与えずにブロック内でスパムが発生する可能性があります。失敗したトランザクションによるスパムのコストは比較的低く、主にトランザクションの伝播に必要なTurbine帯域幅と、台帳内で占有する追加ストレージです。さらに、TemporalとFiredancerの両チームは、無効なトランザクションのフィルタリングや重複排除、読み書きロックの競合によって確実に失敗するトランザクションの防止といった仕組みを実装し、スパムがブロックへ到達する前に軽減するツールを積極的に開発しています。

この問題は簡単に検出、監視できます。オペレーターはリーダーのパフォーマンスを追跡し、ブロック内のスパム量を評価できるため、問題を速やかに解決し、必要に応じて別のデータソースへ切り替えられます。バリデータには収益を最大化する動機があるため、手数料支払者のアカウント残高を正確にキャッシュしておくインセンティブがあります。

固定サイズの小委員会

大規模な10,000ノードのネットワーク全体にAEを実装するには、固定サイズでローテーションする投票委員会を導入する必要があり、これはコンセンサスメカニズムの大きな転換となります。この変更により、ステーク済みノードの総数にかかわらず、コンセンサス投票のリソースコストが安定します。Yakovenkoは、200または400ノードのローテーション委員会で十分だと提案しています。この構成により、バリデータは、定足数、ステークの重み、投票アカウント残高だけという最小限の状態要件でコンセンサス投票に参加できます。メモリ使用量は小さく、対応するスナップショットファイルも容易に配布でき、再起動時に再初期化できます。

ビザンチン耐障害性（BFT）プロトコルで固定サイズのローテーション式小委員会を使用することは、Tronなどの同種ネットワークによってすでに本番環境へ導入されている確立された概念です。これは、コンセンサスを処理する小規模な委員会を選出し、その結果をレプリカのネットワーク全体へ中継する委員会サンプリング方式に基づいています。

Solanaの初期アプローチとしては、投票に一定数のCUを割り当て、各エポックでそのCUに収まるステーク上位のバリデータを選出してフォーク選択を追跡するだけでもよいでしょう。他のバリデータも引き続き投票して報酬を獲得しますが、その投票はフォーク選択では考慮されません。

投票アカウント

● 投票アカウントには、2エポック分の投票を賄える十分なSOLが必要です 

● 投票トランザクションは単純投票である必要があります

● 残高が1エポック分の投票費用を上回っている場合、投票アカウントからSOLを引き出せます

● すべてのlamportを削除するには、Vote CLOSE命令で1エポック全体の経過を必須にする必要があります。投票アカウントはエポック1でCLOSE対象としてマークされますが、エポック2になるまでCLOSEできません

CLOSEにより、すべてのSOLを引き出し、投票アカウントを削除できます。アカウントがCLOSE対象としてマークされると、削除のみ可能となり、再開することはできません

● 投票には通常のBankHashではなく、VoteBankHashが含まれます 

BankHashes

バリデータは、他のすべてのトランザクションを無視し、現在のBankHashと同じ形式を使用して、単純な投票トランザクションのVoteBankHashを計算します。これらのVoteBankHashesには、完全なBankHashではなく、直前のVoteBankHashが組み込まれます。

3分の2の圧倒的多数によって楽観的に確認されたブロックについては、バリデータはUserBankHashの計算も開始します。これには、VoteBankHashですでに考慮されたものを除く、すべての状態遷移が含まれます。

VoteBankHash、UserBankHash、直前のBankHashを組み合わせ、スロットごとにBankHashを計算します。上位99.5%のバリデータは、100スロットごとの投票の一部として、このBankHashを送信します。さらに、一部のノードはgossipネットワークを介してBankHashをブロードキャストし、非決定性が検出されていないことを通知できます。

3分の2未満のバリデータしか完全なBankHashを送信しなかったとします。その場合、リーダーはユーザートランザクションと書き込み可能アカウントに割り当てるブロックスペースを50%削減し、リプレイ時間を過度に増加させる悪用を防ぐことができます。

次の定足数を確立するために状態を計算する必要があるのはエポックごとに1回だけであり、コンセンサスノードとリーダーの同期が保たれます。実行は、コンセンサスノードとは別のマシン上で集約し、バッチ処理できます。同期実行を必要とするユーザー（大部分のアプリケーションとRPC）は、ネットワーク全体を待たずに、すべての状態遷移をリアルタイムで処理する専用ハードウェアリソースを用意できます。

考慮事項

ユーザーへリアルタイムの状態データを提供するRPCプロバイダーには、ローカルで計算した状態がネットワーク全体で計算された状態と一致することを検証するための署名がありません。ただし、フォークが確定すると、ネットワークは決定論的に計算できる単一の正しい正規状態へ収束します。ランタイムのバグやデータ破損のリスクを最小限に抑えるため、正確な状態データの提供を目指すノードは複数のノードを運用すべきです。状態実行に不一致が検出された場合は、直ちに運用を停止する必要があります。

さらに、ユーザーはBankHashを表明するトランザクションや、中断をトリガーするトランザクションを送信できます。ネットワークがこれらのトランザクションを処理するのは、計算されたBankHashが、RPCプロバイダーからユーザーへ提供されたものと一致する場合のみです。

まとめ

Yakovenkoは、AEの採用によってブロック時間を120ミリ秒まで短縮し、ノード数を劇的に増やすという、Solanaの大胆な未来を構想しています。しかし、この未来を実現するには、別々のクライアントチームと幅広いSolana開発者コミュニティをこのビジョンのもとに結集し、こうした変更の実装に伴う重大なエンジニアリング上の課題に対処する必要があります。 

コミュニティの著名なメンバーは、提案された変更の多くに懸念を表明しています。FiredancerチームのRichard Patelは、*「ブロックプロデューサーに非同期実行を実装するのは非常に複雑で、大きなリスクを伴います」*と警告しました。

Jito LabsのZano SherwaniはAEを支持しているものの、MCBPについて、*「複数同時プロポーザーは、解決すべき問題を探しているようなひどい解決策です。プロトコルにもたらす複雑さは、それが解決しようとしているものが仮にあるとしても、それに見合いません」*と批判しています。

最近のポッドキャストで、複数のブロックビルダーについて尋ねられたHeliusのMert Mumtazは、*「完全には納得していません」*と答えました。

AEには、大幅なパフォーマンス向上をもたらす可能性があることは間違いありません。ブロック時間の短縮は確認の高速化とユーザー体験の改善につながり、同時に検閲耐性を高め、トランザクションを並べ替えられる時間枠を短縮します。

しかし、プロトコルの複雑性が増す可能性や、RPCプロバイダーへの依存度が高まることなど、欠点も慎重に評価する必要があります。特定のシナリオでは、これらのプロバイダーだけがチェーン状態の最新かつリアルタイムなビューを持つ参加者となる可能性があります。

AEはSolanaにとって大規模なアップグレードです。本記事では、AEがもたらす注目すべき変更についてSolana開発者コミュニティの認知を高め、この重要なテーマについて、より多くの情報に基づく議論を促すことを目指しています。

本稿の初期版をレビューしてくださった0xIchigoとAnatoly Yakovenkoに心より感謝します。

関連リソース

• Solanaのコンセンサス - Heliusブログ
• Solanaエグゼクティブ概要 - Heliusブログ
• Banklessへの道 - A. Fitzgerald
• 非同期プログラム実行（APE） - A.Yakovenko
• 最終段階のアーキテクチャ - A.Yakovenko
• 非同期プログラム実行とブロードキャスト（APExB）SIMD 0023