Solanaのコンセンサス
実用的な知見
- 同期におけるProof-of-History（PoH）の役割：PoHはコンセンサスアルゴリズムではなく、Solanaのコンセンサスメカニズムが同期に使用するツールです。同様に、Proof-of-Stake（PoS）もコンセンサスではなく、実際にはシビル耐性を提供する仕組みです。
- コンセンサスには投票トランザクションが必要：ブロック内の投票は、TPS指標を人為的に水増しするための余分なトランザクションではありません。投票を単にgossip（非公式のピアツーピア通信）で伝播すると、バリデータ間でTowerの投票状態に対する認識が食い違う可能性があります。
- Solanaには2つの主要な承認ルールがある：短期的なフォーク選択（楽観的承認）と、ファイナリティを得るための完全なPoSコンセンサス（確定済み／ルート化済み）です。クライアントとユーザーは、求めるセキュリティ特性やUXに応じて、これらの承認ルールを選択できます。これは「confirmed」と「finalized」という2つのコミットメントレベルに反映されています。
- 検閲リスクを理解する：バリデータと開発者は、バリデータがブロック生成の順序を妨害しようとする検閲攻撃の可能性を認識する必要があります。そのような攻撃の仕組みと、実行に必要な計算能力およびステークの役割を理解することが重要です。
- 今後のプロトコルアップグレード：バリデータと開発者は、非同期実行やプログラムによるスラッシングなど、Solanaのコンセンサスメカニズムに予定されている変更へ積極的に備える必要があります。
はじめに
Solana上のアクティビティが活発になるにつれ、そのスタックのさまざまなレイヤーが前例のない規模で試されています。ローカル手数料市場などの「注目」トピックについては多くの記事や議論がありますが、Solanaのコンセンサスは長らく見過ごされてきました。しかし、アクティビティと関心が高まり、悪意ある攻撃の動機や潜在的な悪用による利益も増える中、コミュニティにはコンセンサスへの深い理解が求められています。
コンセンサスは、広くコミュニティが理解すべきSolanaの最重要要素の1つです。数千のバリデータがトランザクションの正規の順序について合意する方法を決定するからです。
コンセンサスは、分散システムの分野で長年研究されてきました。Lamport、Shostak、Peaseによるビザンチン将軍問題は、1980年代初頭に発表されました。RAFTのようなコンセンサスアルゴリズムは、web2で長く使用されています。暗号資産分野では、Gasper（Ethereum）、Tendermint（Cosmos）、MonadBFT（Monad）、HotShot（Espresso）、Narwhal/Tusk（Sui）を含め、大半のコンセンサスアルゴリズムはBFTコンセンサスを異なる形で実装したものです。
本記事は、Solanaのコンセンサスメカニズム（TowerBFT）を形式的に証明するものではありません。現時点では主にSolana LabsとFiredancerのコントリビューターの知識にとどまっているこのテーマについて、開発者やより広いコミュニティにSolanaのコンセンサスの仕組みを説明することを目的としています。トレードオフや制約についても考察します。
コンセンサスの簡単な入門
コンセンサスプロトコルの目的は、トランザクションとブロック内での相対的な順序について合意を形成することです。ネットワーク内のバリデータがトランザクションの正規の順序について合意するためのコンセンサスプロトコルには、主に2種類あります。
- 最長チェーンプロトコル：この種のプロトコル（BitcoinのNakamotoコンセンサスなど）は、構築に最も多くの計算作業を要したチェーンを正規化します。これは多くの場合、ブロック数が最も多いチェーンと一致しますが、より正確には、累積作業量または計算能力が最大のチェーンです。
- BFT型プロトコル：大半のPoSプロトコルは、BFTコンセンサスアルゴリズムの一種を実装しています。この種のプロトコル（pBFTなど）は、ライブネスとセキュリティのしきい値に依存します。一貫性と可用性はCAP定理が扱う保証のうちの2つです。CAP定理は、分散データストアが一貫性、可用性、分断耐性という3つの保証のうち、同時に提供できるのは2つだけであると示します。
最長チェーン型とBFT型のどちらのコンセンサスプロトコルも、それぞれの承認ルールからセキュリティを得ます。安全性とライブネスから成るセキュリティは、所定の承認ルールによってもたらされるものであり、チェーン自体の特性ではありません。Ethereum Foundationの定義によると、承認ルールとは「ノードが実行し、特定のブロックが承認されたかどうかを出力するアルゴリズムです。承認された場合、主にネットワークの同期性と誠実なステークの割合に関する一定の仮定の下で、そのブロックは決してreorgされないことが保証されます」。
突き詰めれば、すべては社会的コンセンサスです。最終的には、特定の承認ルールを通じて何をセキュリティと定義するかを表すクライアントコードを書く人々によって決まります。
Proof-of-StakeはBFTモデルに追加のレイヤーを導入し、参加者に自身のステークの提供を求めます。参加者は一連のルールに従うことで報酬を得ますが、二重署名などの不正行為が証明された場合はスラッシングされる可能性があります。これは説明責任のある安全性と呼ばれ、誠実なノードに外部性を及ぼすことなく、プロトコルが悪意あるノードを特定して罰することを可能にします。ただし、BFTコンセンサスプロトコルの基本的なセキュリティメカニズムを置き換えるものではありません。停止を回避するには不正なノードが3分の1未満、誤ったトランザクションの検証を防ぐには3分の2未満である必要があります。ステークベースのシステムは、ネットワークの効率を妨害または低下させる行為に代償を課します。
このようなBFTネットワークには、2つの重要なしきい値があります。
- 1/3：不正なノードが全体の3分の1以上を占めると、ネットワークが「停止」する可能性があります。この場合、それらのノードが単に参加をやめることで、残りのノードはコンセンサスに必要な3分の2の超多数を確保できなくなります。その結果、ネットワークが誤ったトランザクションを生成するのではなく、トランザクションを一切生成しなくなります。よく使われる指標の1つに、やや粗いものではありますが、ライブネス障害（ブロック生成の停止）を引き起こすために必要な最小ノード数を表すNakamoto係数があります。
- 2/3：不正なノードが全体の3分の2以上を占めると、共謀して任意のトランザクションを検証できます。これは、ネットワークが正常に機能しなくなり、不正な超多数の指示どおりにトランザクションを処理する最悪のシナリオです。敵対者がステークの67%超を支配する場合、大手取引所のノード（Binanceなど）のような誠実なノードを隔離できる可能性があります。データセンターと共謀して、そのノードのネットワークトラフィックを制限すれば隔離できます。その後、悪意ある主体は、隔離したノードに自ら作成したブロックを確定させる一方で、競合するブロックをネットワークの残りへ配布できます。この攻撃は隔離されたノードの限られた視野を悪用するもので、ネットワークの残りと隔離されたノードでオンチェーン状態の認識が異なるため、二重支払いにつながる可能性があります。
同様の攻撃は、33%超というより少ないステークでも可能ですが、単なる隔離ではなくネットワーク分断を作り出す必要があります。この場合、ビザンチンなステーク保有者はネットワーク分断を悪用し、競合する情報でネットワークの各セグメントを操作できます。ここでも、二重支払いなどの安全性障害が生じるおそれがあります。
通常、ノード数が多いほど、しきい値へ到達するために大部分を侵害することは難しくなります（地理的に分散していることが前提です）。しかし、ネットワークを大規模化したいという要望は、効率性と衝突しがちです。ノード数が増えるとデータ伝送量が増え、投票の伝播に時間がかかるため、コンセンサスが遅くなる可能性があります。そのため、最大ノード数に厳しい上限を設けるプロトコルもあります。
Proof-of-History（PoH）
Proof-of-Stake（PoS）がネットワークのコンセンサスを確保する一方、SolanaはPoSコンセンサスメカニズムにProof of History（PoH）を組み込み、継続的なブロック生成のための同期を実現しています。Solanaは、同期されたコンセンサスラウンドを待つことなく、低速または無応答のスロットリーダーのスロットをスキップすることでこれを実現します。PoHが証明するのはイベントが発生した正確な時刻ではなく、イベントの順序とイベント間で経過した時間です。
一般的な認識とは異なり、Proof-of-History（PoH）自体はコンセンサスメカニズムでもアルゴリズムでもありません。コンセンサスの現在の実装はPoHの要素を利用していますが、理論上はPoHを取り除いて実装に小さな変更を加えても、Solanaのコンセンサスを動作させられます。
PoHの中核は、検証可能遅延関数（VDF）に似た単純なハッシュアルゴリズムですが、厳密にはVDFではありません。Solanaは、逐次的で原像計算困難なハッシュ関数（SHA-256）を継続的に実行し、各反復の出力を次の入力に使用します。この計算は各バリデータの単一コアで実行されます。
シーケンスの生成は逐次的かつシングルスレッドですが、出力は並列に検証できるため、マルチコアシステムで効率的に検証できます。ハッシュ速度には上限があるものの、ハードウェアの進歩によってさらなる性能向上が得られる可能性があります。
Solanaネットワーク上の4つのバリデータ、A、B、C、Dを例に考えます。この例では、リーダースケジュールによってブロック生成順がA - B - C - Dと定められているとします。最初にバリデータAが順番どおりブロックを生成します。そのために、バリデータAはPoHメカニズムを使ってSHA-256ハッシュ関数を反復実行し、「tick」の時間軸を形成します。このハッシュ処理は、費やされた時間について一意かつ検証可能な記録を作成し、バリデータAのブロックが正確な時間経過を反映するようにします。バリデータAがブロックを完成させると、次はバリデータB、その後はバリデータCがブロックを生成します。
バリデータCが順番を無視してブロックを発行し、バリデータBを飛ばしてバリデータAの直後に続くことで、順序を妨害しようとしたとします。バリデータCがバリデータBの代わりを説得力のある形で務めるには、バリデータBが生成したはずのPoHハッシュシーケンスを再現する必要があります。つまり、バリデータBがブロック生成に要したはずの時間を表すハッシュシーケンスを生成しなければなりません。シングルコアのハッシュ性能には物理的な上限があります。一定時間内にコンピューターが生成できるハッシュ数には上限があるため、一定の時間が経過したことが分かります。
バリデータCは、直前の正当なブロック（バリデータAのブロック）の末尾から、トランザクションを含まない空ブロックのチェーンを生成することで、リーダースケジュール内のバリデータBを検閲しようと試みられます。Bを検閲するには、Cが2つの条件を満たす必要があります。第一に、空のPoHチェーンを生成し続ける計算能力が必要です。第二に、自身に割り当てられたスロットでブロックが受け入れられるよう、十分な数のステーク済みノードへブロックを素早く配信し、Bを事実上検閲する必要があります。バリデータのステーク加重を基に情報フローを優先するTurbineにより、ステーク加重が大きいバリデータほど高速に配信できます。
この攻撃シナリオは実行可能ですが、検閲に成功できる時間枠は限られています。攻撃ノードには、SHA-256のハッシュ計算に必要な大量の計算資源と、生成できるブロック数に比例する相当量のステークが必要です。
CはノードAよりも速くネットワークへ到達するだけでなく、高速にハッシュを生成する必要もあります。この攻撃は主に、スロットnの指定リーダーであるバリデータが、それ以前のリーダースロット（nより前）を持つバリデータを検閲しようとするシナリオを対象とします。このバリデータが実行できる検閲の範囲は、リーダースロットを獲得する能力が保有ステーク量に直接結び付いているため、そのステークによって決まります。
PoHメカニズムは、ブロックが一定の速度で生成されることも保証します。PoHシーケンスは各バリデータが独立して検証できるため、外部の時刻同期は不要です。たとえばEthereumは、コンセンサスのために各ブロックでNetwork Time Protocol（NTP）を使用しています。Solanaでは外部プロトコルを使わず、各バリデータが各ブロックについて、正しい時間スロット内で生成されたことを内生的に検証します。
Tower BFT（Solanaのコンセンサスメカニズム）
SolanaのコンセンサスメカニズムであるTower BFTは、shred（部分ブロック）が他のバリデータへ伝播された後に動作します。
前述のとおり、SolanaはProof-of-Historyと並行してTower BFTを実行します。Tower BFTは、Proof-of-Historyによる同期クロック計算を活用するよう設計されたpBFT類似のコンセンサスアルゴリズムです。これによりネットワーク全体で共通のクロックが確立され、低速または無応答のリーダーに割り当てられたスロットを効率的に飛ばせます。このプロセスにより、スロットごとに同期コンセンサスラウンドを実行する必要がなくなります。また、バリデータは次のブロックを構築する前に以前のブロックの到着を待つ必要がないため、継続的にブロックを生成できます。
もう1つの誤解は、Solanaのコンセンサスメカニズムが現在、プログラムによるスラッシングを実装しているというものです。 スラッシングはロードマップに含まれていますが、現在のネットワークは安全性違反が発生すると停止し、必要に応じたスラッシングを社会的コンセンサスに依存しています。
Solanaのコンセンサスメカニズムでは、ノードごとに影響力が異なります。ネットワーク内の投票は平等ではなく、ステーク加重QoSやTurbineと同じ原則に従い、各ノードのステークに応じて重み付けされます。他の条件が同じなら、ステークが大きいノードほど、ステークが小さいノードより正規のコンセンサス決定に強い影響を与えます。
たとえば、合計100単位のステークを持つ4ノードのネットワークでは、分布と影響力は次のようになります。
- ノードAは10単位のステークを保有します。
- ノードBは20単位のステークを保有します。
- ノードCは30単位のステークを保有します。
- ノードDは40単位のステークを保有します。
この構成では、不正なノードのグループごとに可能な行為が異なります。ノードDは全ノード数の25%にすぎませんが、大きなステークを持つため、単独でネットワークを停止できます。同様に、ノードCとDの組み合わせはノード数の50%にすぎませんが、結果に影響を与えるだけのステークを保有しているため、誤ったトランザクションを承認できます。
ネットワーク停止の3分の1しきい値には、不正、侵害済み、またはブロックされたノードによって到達できます。一方、誤ったトランザクションを検証する3分の2しきい値には、積極的な共謀が必要で、誠実なノードを単にブロックするだけでは不十分です。そのため、後者の実現は大幅に困難です。誠実なノードをブロックするのではなく、ノードを不正化または侵害し、不正な計画へ積極的に参加させる必要があるからです。
スロット内のコンテキスト
Solanaでは、スロットリーダーに合計約1.6秒間続く4つの連続スロット（4ブロック × 1ブロック400 ms）が割り当てられます。リーダーは各エポック（432,000スロット、約~2〜3日）の開始時に選ばれます。リーダースケジュールは、バリデータのステーク加重に応じてランダムに決定されます。
リーダーは、割り当てられた各スロットで新しいブロックを構築し、提案する役割を担います（Ethereumの世界にある提案者とビルダーの分離はありません）。他のバリデータは、Solanaネットワークのヘッドに関する自身のローカルビューへフォーク選択ルールを適用し、投票トランザクションを通じて所定のブロックの有効性を証明します。
ブロックが有効になるには、リーダーが所定のPoH tick範囲内でブロックを公開する必要があります。この範囲内で公開されなかったブロックは、スキップされたと見なされます。
4人の参加者（A、B、C、D）がいて、Dが順序を妨害しようとするリーダースケジュールを例に考えます。DがCの順番に介入するには、Cのブロックを事実上スキップするPoH tickシーケンスを作成する必要があります。その結果、チェーンは次のようになります。
A - B - [Cが欠落] - D。
Cのブロックが欠落している場合、誠実なDは自身のシーケンスを開始する前に、Cのスロット全期間をカバーするPoHシーケンスを生成する必要があります。これにより、Cのスロットに割り当てられた時間の経過後にBのブロックへ続くため、Dのブロックは有効に見えます。
DがCのスロット分のPoHシーケンスを生成している間、通常であればCは適切なPoHシーケンスでBに接続された自身のブロックをストリーミングします。これにより、次の2つの結果が考えられます。
- DのPoH計算がCより速くない場合：Dが自身のブロックのブロードキャストを開始するのとほぼ同時にCがブロックを完成させます。ネットワークはすでにCのブロックを確認しているため、Dのブロックを拒否します。
- DのPoH計算がCより速い場合：Cが自身のブロックを完成させる前に、Dがブロックのブロードキャストを開始します。それでも順序に大きな影響を与えるには、DがCより大幅に高速である必要があります。バリデータがSHA-256計算に使うCPUは高速であり、性能上限も比較的近いため、これは起こりにくいと考えられます。
どちらの場合も、DがCを正常に置き換えられる可能性はわずかです。さらに、Cの置き換えに失敗すると、Dは自身のスロットでブロックを発行する機会を失います。Bの直後にブロックを発行し、その後Cの後でもう1つ発行しようとすると、Dのスロットに2つのブロックを作成する違反となり、スラッシング対象の行為になります。試行に失敗するたびにDは自身のブロック生成機会を失うため、Dがこの戦略を取る可能性は低いと考えられます。
ネットワークから見てDの意図は判別できません。Dが単にCのブロックを認識していなかった場合（Cを検閲する意図はない）と、DがBを検閲しようとしていた場合を区別することは困難であり、ほぼ不可能です。そのため、容易には検出できず、ネットワークが処罰することもできません。
投票トランザクション
Solanaのコンセンサスメカニズムは、合意形成のために投票トランザクションを利用します。投票トランザクションはブロック内に存在しますが、通常のトランザクションに埋もれないよう優先されます。現在、所定のブロック内にあるトランザクションの大半は投票トランザクションです。
ただし、常にそうであるとは限りません。所定のブロック内に占める投票トランザクションの割合は、アクティビティとコンセンサスに参加するバリデータ数の比率を表すためです。将来的には、投票トランザクションがブロック内で少数派になる可能性があります。
投票トランザクションはコンセンサスに必須です。TPS指標を人為的に水増しするための余分なトランザクションではありません。 投票を単にgossip（非公式のピアツーピア通信）で伝播すると、バリデータ間でTowerの投票状態に対する認識が食い違う可能性があります。このような不一致により、どのフォークが正しい可能性が高いかについてバリデータごとに見解が異なり、不完全または一貫性のない情報に基づいて貪欲な選択をすることで、分岐につながる可能性があります。継続的なブロック生成には、特に以前のブロックがまだ承認中の場合、継続的な投票が必要です。そのため、Towerの状態に関する信頼性の高い一貫したビューが求められます。
ユーザーが開始する通常のトランザクションと同様に、投票トランザクションも基本手数料（0.000005 SOL）を支払う必要があります。これはバリデータIDが支払います。継続的に署名するため、バリデータIDはホットウォレットに置く必要があります。一方、投票アカウントはアカウント検索と委任に使用されます。
バリデータが署名する各投票には、バリデータの公開鍵と、投票対象ブロックのハッシュが含まれます。
バリデータは同じスロットについて複数のブロックを受信すると、「最良」のものを判断できるまで、可能性のあるすべてのフォークを追跡します。バリデータは関連する状態遷移関数をローカルで実行し（これは非同期実行で変更されます）、リプレイ後に新しいブロックへ投票します。バリデータは、オンチェーンの投票トランザクションを通じて所定のフォークへの投票を表明します。
各投票トランザクションで、バリデータはロックアウト期間付きの投票を公開します。このロックアウトはコミットメントメカニズムとして機能し、バリデータを選択したフォークへ拘束するとともに、その決定に機会費用を課します。現在、ロックアウトはランタイムではなく社会的コンセンサスによって強制されます。投票ロックアウトへ継続的に違反すると、手動でスラッシングされる可能性が非常に高くなります。投票クレジットを受け取れないだけでは十分な抑止力にならないため、ロックアウト期間への違反に対するプログラムによるスラッシングが近い将来追加される可能性があります。
バリデータは、前回の投票からルート化済み／確定済みブロックまでにあるすべての祖先ブロックについて、そのブロックのハッシュにも署名します。これは重複ブロックの検出に必要です。リーダーが各ノードへ異なるブロックを送信すると、各ノードは同じスロットについて異なる先行ブロックへ投票することになります。ただし、65,000スロットで構成されるエポックでは、最も極端なシナリオで各投票のサイズが最大2 MBに達する可能性があります。65,000スロットのそれぞれについて32バイトのハッシュが必要になる可能性があるためです。これについては今後の記事で詳しく取り上げます。
バリデータは「Vote Tower」を管理します。これは投票を順番に積み上げたスタックであり、各投票はフォークを強化するとともに、Tower内でその上にあるフォークの祖先になります。このTowerへ新しい投票が追加されると、スタック内にある以前の全投票のロックアウトが2倍になり、過去の決定に対するコミットメントとロックアウト期間が徐々に増加します。投票プロセス自体には複数のチェックがあります。バリデータは以前の投票のロックアウト期間を守る必要があります。また、ネットワークの大部分（通常は3分の2）も同じフォークへコミットしていることを確認する必要があります。さらに、新しいフォークへ切り替えるには、代替フォークに対する投票の相当な割合（38%超）が必要です。
スロットnのブロックでは、リーダー以外の投票が早ければn+1からオンチェーンに現れ始めます。投票サブコミッティは存在せず、すべてのバリデータがすべてのブロックへ投票できます。これらの投票はまず、Turbineツリー内で近接する（1ホップ先の）他のバリデータのブロックに現れます。バリデータは「スロットハッシュ」がまだ分かっている任意のスロットへ投票でき、スロットハッシュは512スロット保持されるため、スロットnへの投票は最大でスロットn+512まで現れる可能性があります（情報提供：Shinobi）。スロットnの特定ブロックに、あらかじめ決められた上限はありません。ただし、少なくとも32個の連続ブロックが構築されたルート化済みスロットは、それ以降投票を受け付けず、確定済みになります。
投票方式には、ランタイムによって完全には強制されていない独特な点があります。たとえば現在、バリデータには「ルート化済み」スロットだけへ投票し、チェーンの先端を無視するインセンティブがありますが、コンセンサスによる罰則はありません。これによりバリデータは、実際のコンセンサス処理でチェーンの先端へ貢献しなくても、正規になる可能性が極めて高いフォークについて継続的に投票クレジットを獲得できます。これは現在も発生しており、平均「投票レイテンシ」が68スロットを超えるバリデータも存在します。Timely Vote Creditsという機能案は、このインセンティブの不整合を緩和することを目指しています。
Solanaのフォーク選択ルール
Ethereum（LMD GhostとCasper FFG）と同様に、Solanaには2つの承認ルールがあります。1つは短期的なフォーク選択、もう1つはファイナリティを得るための完全なPoSコンセンサスです。これにより、ユーザーとクライアントは異なる承認ルールの下でUXをカスタマイズできます。これは「confirmed」と「finalized」という2つのコミットメントレベルに反映されています。
「confirmed」ブロック（楽観的承認とも呼ばれます）には、特定のブロックに対して少なくとも3分の2のバリデータが投票トランザクションで投票する必要があります。ファイナリティ違反を可能にするには、現在のステークの~4.6%がスラッシングされる必要があります。「finalized」ブロックには、後続する少なくとも32スロットへの投票、または投票の超多数（>2/3）が必要です。悪意ある攻撃では、ステークの3分の1超がスラッシングされる必要があります。完全なファイナリティを得るには32ブロック前のルート化済みブロックを待つ必要があるため、「confirmed」ブロックより大幅に時間がかかります。
フォーク選択ルールにより、ネットワークはチェーンのヘッドについて合意できます。Solana Labsの実装では、主にheaviest_subtree_fork_choice.rsという適切な名前が付けられた約~4600行のRustファイルでフォーク選択を処理します。これにより、どのフォークが正規になる可能性が最も高いかをバリデータが判断するために必要なロジックが提供されます。コードの詳細な分析は今後の記事で取り上げますが、フォーク選択の仕組みを非常に大まかに説明すると次のとおりです。
add_votes()で投票を追加します。
新しい投票を反復処理し、必要に応じて古いスロットから投票アカウントのステークを差し引き、新しく投票されたスロットへステークを追加します。
generate_update_operations()を呼び出し、フォーク更新操作のバッチを作成します。
処理内容は次のとおりです。
- 古いフォークからステークを差し引く
- 新しいフォークへステークを追加する
- 各フォークからルートまでステークを集計する
process_update_operations()：
- 必要に応じて
mark_fork_valid()/invalid()を呼び出す - 各フォークで
aggregate_slot()を呼び出し、フォークの重みを更新する add_slot_stake()/subtract_slot_stake()を呼び出し、ステークを更新する
aggregate_slot()：
- すべての子スロットのステークを合計する
- ステーク加重に基づいて最も重い子フォークを見つける
- 高さに基づいて最も深い子フォークを見つける
- これらの値を上方へ伝播し、このスロットから最も重い／深いフォークを見つける
select_forks()：
- ブロック生成に使用する全体で最も重いフォークを返す
- 最後の投票から派生する最も重いフォークを返す
投票に基づいてステークを加算／減算し、集計によって各フォークの重みをボトムアップで再計算します。そして、加重されたサブツリーが最も重いルートを、構築と投票の対象となる最良のフォークとして選択します。
取り込まれる可能性
トランザクションが取り込まれる可能性は、各承認ルールに必要な要件を満たした後、トランザクションのライフサイクルに沿って変化します。
リーダーがオフラインの場合など、スロットが「スキップ」されることはありますが、そのトランザクションは将来のブロックに取り込まれるか、まったく取り込まれない可能性があります。
ここでのスロット数は大まかな概算ですが、投票がいつ蓄積する傾向にあるかを読者が把握できるよう示しています。また、これはブロックごとに異なります（ブロックが「confirmed」または「finalized」の承認レベルへ到達するまでの長さは一定ではありません）。取り消しのリスクは、トランザクションのライフサイクル全体を通じて単調に低下します。ブロックが確定（ルート化）された後でも、理論上は社会的コンセンサスによってフォークされ、「正規」チェーンから除外される可能性があります。
今後の研究分野とまとめ
本記事では、SolanaのコンセンサスメカニズムであるTower BFTの内部動作と、その他の関連メカニズムを取り上げました。トランザクションを順序付ける正規フォークを作成するうえで、Proof-of-History、投票トランザクション、フォーク選択がSolana内で果たす役割を解説しました。
これらのメカニズムには、今後研究および形式化すべき方向性が数多くあります。たとえば次のようなものです。
- Ethereumの研究者は、ブロック生成者がスロットの終わりまでブロックの提出を待つTiming Gamesの価値を定量化しています。Solanaにおけるこのゲームは定量的にどのようなもので、現在実際に行われているのでしょうか？
- 非同期実行は、2024年の主要なプロトコル変更としてロードマップに含まれています。状態遷移をローカルで計算せず、既存のフォークへ投票するだけのノードには、どのような潜在的攻撃ベクトルとセキュリティ上の考慮事項があるのでしょうか？
- 現在、相当数の少数派バリデータ（<20%）がSolana LabsまたはJito-Solanaクライアントの改変版を実行しています。ランタイムや承認ルールで管理されていないどのしきい値を変更しているのでしょうか？
- プログラムによるスラッシングの実装。現在、スラッシングを伴わない高収益な取引戦略の実行を抑止する経済的インセンティブは、社会的コンセンサス以外にほとんどありません。
- 完全に異なる2つのクライアントを実行した場合、Solanaのコンセンサスメカニズムに関する性能はどうなるのでしょうか（同じ承認ルールによる定義を試みている場合でも）？
- 投票サブコミッティには、どの程度の性能向上と状態削減が期待できるのでしょうか？
- 確定済みスロットではなく、楽観的に承認されたスロットから再起動する場合、どのような潜在的攻撃ベクトルがあるのでしょうか？取引所などのサードパーティ製オフチェーンソリューションは、楽観的承認または完全なファイナリティの利用をどのように考えるべきでしょうか？
- スラッシングされた資金を、安全性違反に含まれるトランザクションの保険に使うべきでしょうか？SOL建て保険プールの仕組みとインセンティブはどうあるべきでしょうか？
本記事では、Solanaがコンセンサスメカニズムに実装している一部の仕組みとしきい値、そしてそれらが所定のスロット内でリーダーが行う通常のブロック生成とどう関係するかを解説しました。最近のSolana上のアクティビティ増加は、これらのメカニズムに対する現実世界でのライブネスと安全性のテストになっています。同時に、悪意ある攻撃へのインセンティブも高まっています。
議論とコメントを寄せてくださったanoushk（Tinydancer）、dubbel06（Overclock）、Prithvi（Helius）、Mert（Helius）、Jarry（Ellipsis Labs）に感謝します。
関連記事
Heliusを購読
Solana開発の最新情報や新しい記事の公開通知を受け取れます