Solanaのスケーリングメカニズム分析：可用性を犠牲にして高効率を追求する極端な試み | CatcherVC Research
Solanaはシステムの可用性を犠牲にして、Layer1のスケーリングの物語を極端に推し進め、基本的にシャーディングのないパブリックチェーンのTPSのボトルネックに達しました。しかし、何度もダウンタイムが発生したことは、可用性を犠牲にして効率を追求する結果を示唆しているようです。著者：SA，CatcherVC
技術顧問：劉洋、『組み込みシステムの安全性』著者
要約
- Solanaのスケーリングは主に、ネットワーク帯域幅の効率的利用、ノード間の通信回数の削減、ノードの計算速度の向上の3つの側面に基づいており、これらの対策はブロック生成と合意通信の時間を直接短縮するが、システムの可用性（安全性）を低下させる。
- Solanaはブロック生成者のリーダーリストを事前に公開し、単一の信頼できるデータソースを明らかにし、合意通信のオーバーヘッドを削減した。しかし、これにより賄賂や標的攻撃などのセキュリティリスクが生じる。
- Solanaは合意通信（投票情報）を取引イベントとして処理し、TPSの成分の70%以上が合意メッセージであり、ユーザー取引に関連するTPSは約500---1000である。
- SolanaのGulf Streamメカニズムはグローバルな取引プールを廃止し、取引処理速度を向上させたが、ゴミ取引のフィルタリング効率を低下させ、リーダーがダウンしやすい。
- Solanaのリーダーノードは取引シーケンスを発表し、実際のブロックではない。Turbine伝送プロトコルと組み合わせることで、取引シーケンスは切り刻まれ、異なるノードに配布され、データ同期速度は非常に速い。
- POH（Proof Of History）は実質的に計時とカウントの方法であり、異なる取引イベントに番号を付け、取引シーケンスを生成する。リーダーは実質的に取引シーケンス内で全ネットワークで一致するタイマー（時計）を発表する。非常に短いウィンドウ期間内に、異なるノードの帳簿の進行と時間の経過は一致している。
- Solanaには132のノードが67%のステーキングシェアを占め、そのうち25のノードが33%のステーキングシェアを占めており、基本的に「寡頭政治」または「元老院」を構成している。この25のノードが共謀すれば、ネットワークは混乱に陥る可能性がある。
- Solanaはノードのハードウェアレベルに対する要求が非常に高い。デバイスコストを代償にして、縦のスケーリングを実現した。Solanaノードを運営する個体は主にクジラや機関、企業であり、真の意味での分散化には不利である。
- 以上を総合すると、Solanaは高級ノードデバイス、破壊的な合意メカニズムとデータ伝送プロトコルを用いて、Layer1のスケーリングを極端に推進し、基本的に分割のないパブリックチェーンが維持できるTPSの限界に達した。しかし、複数回のダウンは、可用性/安全性を犠牲にして効率を追求する結果を示唆している。
導入
2021年はブロックチェーンとクリプトの転換の年であった。Web3などの概念が注目を集める中、パブリックチェーン界は史上最も強力なトラフィックの増加を迎えた。このような外部環境の中、Ethereumは十分な分散化と安全性を持ち、Web3の世界の指針となったが、効率の問題が「アキレス腱」となった。TPSが軽々と千を超えるVISAに対し、毎秒10数件の取引を処理するEthereumは、まるで赤ちゃんを抱くようで、「世界級の分散型アプリケーションプラットフォーム」という壮大なビジョンとはかけ離れている。
これに対し、Solana、Avalanche、Fantom、Nearなどのスケーリングを核心とする新しいパブリックチェーンは、一時的にWeb3の物語の主要な役割を果たし、大量の資本の注目を集めた。Solanaを例に取ると、「Ethereumキラー」と称されるこのトップパブリックチェーンは、2021年に時価総額が170倍に急増し、絶頂期を迎え、さらには老舗のパブリックチェーンであるPolkadotやCardanoを一時的に超え、Ethereumと競争する勢いを見せた。
しかし、この勢いは長続きしなかった。2021年9月14日、Solanaは性能上の問題により初めてダウン事故を迎え、17時間にわたってサービスが停止し、SOLトークンの価格は急速に15%下落した。2022年1月、Solanaは再びダウンし、30時間も続いたことで広範な議論を引き起こした。その後の5月には、Solanaは2回のダウンを経験し、6月初めにも1回ダウンした。Solanaの公式によれば、そのメインネットは少なくとも8回の性能低下またはダウン事故を経験した。
（ChainNewsの共同創設者、劉鋒によるSolanaへのコメント）
多くの問題が発生する中、Ethereum支持者を中心とした批評家たちは次々とSolanaに疑問を投げかけ、Solanaに「SQLana」というレッテルを貼る者もいた（SQLは集中型データベースを管理するシステムである）。その後、多くのコメントや分析が生まれた。今日に至るまで、Solanaの真の可用性に関する議論は決して止まることがなく、無数の好奇心旺盛な観察者を引き寄せている。主流のパブリックチェーンへの関心と注目から、CatcherVCは自身の視点から、この記事でSolanaのスケーリングメカニズムとそのダウンの一部の原因について簡単に解説する。
Solanaのシステムアーキテクチャ、合意メカニズム、ブロック伝送プロセス
パブリックチェーンの効率は主にその取引処理能力、すなわちスループットTPS（毎秒処理される取引数）を指し、この指標はブロック生成速度とブロック容量の影響を受け、同時に取引手数料やユーザーの活発度にも影響を与える。2018年に話題となったEOSから、最近の発行されたOptimismまで、すべてのスケーリングソリューションはほぼ「ブロック生成の加速」という最も重要な要素を避けることはできない。
ブロック生成速度を向上させるためには、しばしばブロック生成プロセスに「手を加える」必要があり、Solanaも例外ではない。そのスケーリング方法は主にネットワーク帯域幅の効率的利用、ノード間の通信回数の削減、ノードの処理速度の向上の3つの側面に立脚しており、これらの対策はブロック生成と合意通信の時間を直接短縮する。Solanaの創設者Anatoly Yakovenkoとそのチームは、各詳細に対して慎重に手を加え、システムの可用性（安全性）を代償にして、効率を可能な限り向上させ、基本的に分割のないパブリックチェーンの実際のTPS限界に達し、最終的に「代償を伴う」革新を実現した。
他のPOSを採用するパブリックチェーンと比較して、Solanaの最大の革新点はその独特な合意プロトコルとネットワークノード通信方式にある。この合意プロトコルはPOSとPBFT（実用的なバイザンチンフォールトトレランス）に基づき、独自のPOH（Proof of History）を導入してブロックチェーンの台帳を推進するメカニズムを独自に構築した。
表現形式の観点から見ると、Solanaの合意プロトコルはCardanoの初期のOuroboros（衔尾蛇）アルゴリズムに似ており、Epoch（紀元）とSlot（間隔）の2つの時間単位を含んでいる。各Slotは約0.4~0.8秒であり、1つのブロックの時間間隔に相当する。そして、各Epoch周期は43.2万Slot（ブロック）を含み、長さは2~4日である。
Solanaのシステムアーキテクチャにおいて、最も重要な役割は2つのカテゴリに分かれる：Leader（ブロック生成者）とValidator（検証者）。両者は実際にはSOLトークンをステーキングした全ノードであり、異なるSlot（ブロック生成周期）内でリーダーは異なる全ノードが務めるが、リーダーに選ばれなかった全ノードはValidatorとなる。
各新しいEpoch周期が始まると、Solanaネットワークは各ノードのステーキングの重み付けに従って抽選を行い、ブロック生成者リーダーのローテーションリストを構成し、未来の異なる時点でのブロック生成者を「指名」する。全体のEpoch（2~4日）内で、ブロック生成者はリストに指定された順序に従ってローテーションを行い、4つのSlot（ブロック生成周期）ごとにリーダーノードが変更される。
（Solana第313回Epochのブロック生成ノードローテーションリストの一部）
未来のブロック生成ノードが事前に公開されたため、Solanaネットワークは実質的に確定的で信頼できる新しいブロックデータソースを得て、合意プロセスに大きな便利さを提供した。
Solanaのブロック生成プロセスの概要
Solanaのスケーリングメカニズムをより明確に理解するために、ブロック生成の論理から始めて、Solanaの大まかな構造を解析してみよう：
- ユーザーが取引を開始すると、クライアントはそれを直接リーダーノードに転送するか、まず通常のノードが受信し、すぐにリーダーに転送する。
- ブロック生成者リーダーはネットワーク内のすべての未処理の取引を受け取り、実行しながら取引指示を並べ替え、取引シーケンス（ブロックに似たもの）を作成する。一定の時間ごとに、リーダーは整列された取引シーケンスをValidator検証ノードに送信する；
- Validatorは取引シーケンス（ブロック）に指定された順序で取引を実行し、対応する状態情報Stateを生成する（取引を実行するとノードの状態が変わる、例えば特定のアカウントの残高を変更する）；
- N個の取引シーケンスを送信するごとに、リーダーは定期的にローカルの状態Stateを公開し、Validatorはそれを自分のStateと比較し、肯定/否定の投票を行う。このステップはEthereum 2.0や他のPOSパブリックチェーンの「チェックポイント」に似ている。
- 規定の時間内に、リーダーが全ネットワークの2/3のステーキング重みを持つノードからの肯定票を集めると、以前に発表された取引シーケンスと状態Stateが確定し、「チェックポイント」が通過し、ブロックが最終確認Finalityを完了する。
- 一般的に、肯定票を出したValidatorノードとブロック生成者リーダーが実行した取引、実行後の状態は同じであり、データは同期される。
- 4つのSlot周期ごとに、リーダーは切り替えを行い、これはリーダーがネットワークの「最高の発言権」を持つ時間が約1.6秒~3.2秒であることを意味する。
Solanaのスケーリングメカニズムの詳細解析
表面的には、Solanaのブロック生成論理は他のPOSメカニズムを採用するパブリックチェーンと大体一致しており、ブロックを発表し、ブロックに投票するプロセスがある。しかし、各ステップを観察すると、Solanaと他のパブリックチェーンの間には天と地の差があり、これが高TPS、低可用性の根源であることがわかる：
1.最も重要な点：Solanaは各周期Slotのブロック生成者リーダーを事前に公開し、合意プロセスの作業量を大幅に削減した。他のPOSパブリックチェーンでは、単一の信頼できるブロック生成ノードが欠如しているため、ネットワークの合意通信効率は非常に低く、生成される時間の複雑さはしばしばSolanaよりも数桁高く、これが多くのパブリックチェーンのTPSのボトルネックとなっている。
主流のPOS合意プロトコルやPBFTアルゴリズムの例を挙げると、これらのアルゴリズムはほとんどSolanaと同じ時間単位と役割の分担を採用しており、Epoch紀元、Slotブロック周期、Leaderブロック生成者、Validator検証者、Vote投票の設定も似ているが、パラメータの設定や呼び名が異なるだけである。最大の違いは、これらのアルゴリズムはほとんどが安全性（可用性）を前提としており、リーダーリストを事前に公開しないことである。
（例えばCardanoも事前にリーダーローテーションリストを生成するが、そのリストは公開されない。選ばれたリーダーは自分がいつブロックを生成するかは知っているが、他の時点でのブロック生成者が誰であるかは知らない。これにより、ブロック生成ノードは外部から予測できなくなる。）
公開されたブロック生成者がいないため、ノード間は「互いに信頼しない」と「各自で行動する」。この時、あるノードが合法的なブロック生成者を名乗っても、誰も信じることができず、関連するProofを示す必要がある。しかし、このようなProofの生成、伝播、検証は帯域幅リソースを浪費し、追加の作業量を生じる（場合によってはZKのゼロ知識証明に関係することもある）。Solanaは各時間帯のリーダーを公開することで、このようなトラブルを回避できる。
さらに重要なのは、ほとんどのPOS合意プロトコルやPBFT類アルゴリズムにおいて、新しいブロックに対する投票Vote（ブロックがネットワーク内の2/3のノードから肯定票を得る必要がある）は、各ノードが「流言プロトコル」を通じて、1対1の通信方式で送信または収集されることが多く、ウイルス式のランダム拡散に似ており、実質的には各2つのノード間で通信が1回行われる必要があり、その複雑さと時間がSolanaの合意プロトコルよりもはるかに高くなる。
TendermintなどのPBFTアルゴリズムでは、単一のValidatorノードはネットワーク内の2/3のノードからの単一の投票を収集する必要がある。全ネットワークのノード数がNである場合、各ノードは少なくとも2/3×Nの投票を受け取る必要があり、ネットワーク全体での通信回数は少なくとも2/3×N²となる。明らかにこの数量は非常に大きく（Nの二乗に比例する）。ノード数が多い場合、その合意プロセスの所要時間は急増することが多い。
（一般的なパブリックチェーンにおける単一ノードの投票の伝播方式、類似のプロセスは各ノードが1回行い、各ブロック生成時にN回の類似の伝播が行われる）
（関連の解説：《Avalanche合意メカニズムを詳しく解説する雪崩DEX開発者》）
これに対して、SolanaとAvalancheは異なる方法でノードの投票収集の通信プロセスを改善し、時間の複雑さを低下させた。簡単に言えば、リーダーはすべてのValidatorからの投票を集中して集約し、これらの投票をまとめて（取引シーケンスに書き込み）、一度にネットワークにプッシュする。
こうすることで、ノードは「流言プロトコル」を通じて頻繁に、1つずつ投票情報を交換する必要がなくなり、通信回数は定数NまたはlogNの数量級に減少し、これによりブロック生成時間が大幅に短縮され、TPSが大幅に向上した。
現在、Solanaのブロック生成周期は基本的に単一のSlotの長さと一致しており、0.4~0.8秒であり、Avalancheよりも3倍速い場合もある。（Solanaブラウザに表示されるブロックは、実質的に各Slot内でリーダーが発表した取引シーケンスである）。
しかし、これにより別の問題が生じる：リーダーが取引シーケンス（ブロック）内でノードの投票情報を発表することは、ブロックスペースを占有することになる。Solanaの設定では、リーダーは実質的に合意投票を取引イベントとして処理し、発表された取引シーケンスにはノードの投票Voteが含まれ、これらの投票はSolanaのTPSの主要成分である（一般的に70%以上を占める）。
Solanaブラウザのデータ統計によれば、実際のTPSは2000~3000の範囲で維持されており、その70%以上は一般ユーザーに無関係な合意投票メッセージであり、ユーザー取引に関連する実際のTPSは500~1000である。これはBSCやPolygon、EOSなどの高性能パブリックチェーンよりも1桁高いが、公式が誇る1万レベルには達していない。
同時に、Solanaが今後分散化の程度を高め、より多くのノードが合意投票に参加できるようにすれば（現在約2000のValidatorが存在）、リーダーが発表する取引シーケンスにはより多くの投票情報が含まれることになり、ユーザー取引に関連するTPSスペースが継続的に圧縮されることになる。これは、Solanaが分割なしの前提の下で、基本的により高いTPSを達成することが難しいことを示している。
ある意味で、Solanaの毎秒500~1000件の取引処理能力は分割のないパブリックチェーンの頂点に達しており、ノード数が多く、分割なしでスマートコントラクトをサポートする前提の下で、新しいパブリックチェーンがSolanaのTPSレベルを超えることは基本的に難しい。彼らが「委員会」モデルを採用し、少数のノードのみが合意に参加するか、中央集権的なサーバーに退化しない限り、合意に参加するノードの数が多ければ多いほど、Solanaよりも高い「証明可能なTPS」を達成することは難しい。
特に注目すべきは、各Epoch内の（2~4日）のブロック生成者リストが事前に公開されているため、Solanaの合意プロトコルは元のTendermintアルゴリズムと本質的に変わらず、実際にはブロック生成者に予測不可能性を与えていないことである。すべての人が未来のある時点で誰がブロックを生成するかを予知できるため、可用性/安全性に多くのリスクをもたらす。
（リーダーは計画的なDDOS攻撃に遭いやすく、故障率が高まり、連続して数回のリーダーが故障すると、ネットワークが容易にダウンする。また、ユーザーは事前にリーダーに賄賂を贈ることもできる。）
2.Gulf Streamとネットワークダウン：Solanaがブロック生成者リーダーのリストを公開するもう一つの重要な目的は、独自のGulf Stream（湾流）メカニズムと組み合わせて、ネットワークの取引処理速度を向上させることである。
ユーザーが取引を開始すると、通常はクライアントプログラムが直接指定されたリーダーに転送するか、最初にある通常のノードが受信し、その後そのノードがリーダーに迅速に送信する。この方法により、リーダーは取引要求を迅速に受け取り、応答速度を向上させることができる。（これをGulf Streamメカニズムと呼び、Solanaのダウンの主な原因の一つである）
Solanaのこの設定は、他のパブリックチェーンとは全く異なる取引提出方式である。Gulf StreamはビットコインやEthereumの「グローバル取引プール」の設定を廃止し、通常のノードは大容量の取引プールを運営しない。あるノードがユーザーの未処理の取引を受け取ると、それをリーダーに渡すだけで、他のノードに送信する必要はなく、この方法は効率を大幅に向上させるが、取引プールを廃止したため、通常のノードはゴミ取引を効率的に遮断できず、リーダーノードがダウンしやすくなる。
この点を深く理解するために、ETHと比較してみよう：
・Ethereumの各全ノードには、未上チェーンの未処理取引指示を保存するための取引プール（メモリプール）と呼ばれるストレージエリアがある。
・ノードが新しい取引要求を受け取ると、最初にフィルタリングを行い、取引指示が適切かどうか（重複取引やゴミ取引でないか）を判断し、その後取引プールに保存し、他のノードに転送する（ウイルス式拡散）。
・最終的に、合法的な未処理取引はネットワーク全体に広がり、すべてのノードの取引プールに入ることで、異なるノードが同じデータを取得し、「一貫性」を示す。
Ethereumとビットコインがこのメカニズムを採用する理由は明確である：未来のブロック生成者が誰であるかわからないため、すべての人が新しいブロックをパッケージ化する可能性がある。したがって、異なるノードが同じ未処理取引を受け取る必要があり、ブロックパッケージ化の準備をする必要がある。
もしマイニングプールノードが新しいブロックを発表すると、ブロックを受け取ったノードはその中の取引シーケンスを解析し、順番に実行し、その部分の取引指示を取引プールから削除する。これにより、一連の未処理取引が上チェーンされる。
SolanaはEthereumのその種の取引プールを廃止し、未処理の取引はネットワーク内でランダムに拡散するのではなく、指定されたリーダーに迅速に提出され、取引シーケンスとして一度に配布される（前述の投票の配布方式に似ている）。最終的に、取引は取引シーケンスに挟まれて、ネットワーク内で1周（Ethereumは実際には2周）するだけで済む。取引数が非常に多い場合、この微細な違いが伝播効率を大幅に向上させることができる。
しかし、取引プールTxPoolに関する技術説明によれば、取引プール/メモリプールは実質的にデータバッファとフィルターの役割を果たし、パブリックチェーンの可用性を向上させることができる。すべてのノードが取引プールを運営し、ネットワーク内のすべての未処理取引を収録することで、異なるノードが独立してゴミリクエストをフィルタリングし、最初の段階で重複取引を遮断し、トラフィックの圧力を分担することができる。取引プールを採用するとブロック生成速度が遅くなるが、ユーザーが重複取引（取引プールに記録があるリクエスト）や他のタイプのゴミリクエストを発起した場合、取引を受け取ったノードはローカルでそれをフィルタリングし、再度転送することはないため、フィルタリング作業が全ネットワークのノードに分担される。
（Ethereumネットワークでは、悪意のあるユーザーが発起した重複取引が各ノードによって直接遮断されやすい）
Solanaは逆のアプローチを取った。Gulf Streamメカニズムの下で、通常のノードは全ネットワークで一致した取引プールを運営せず、重複/ゴミ取引を効率的に遮断できない。通常のノードができることは、取引データパッケージが正しい形式に合致しているかどうかを確認するだけであり、悪意のある重複リクエストを識別することはできない。また、通常のノードが「一斉に」取引指示をリーダーに押し付けることは、フィルタリング取引の「重荷」をリーダー自身に押し付けることに相当し、トラフィックが非常に多く、重複取引が非常に多い場合、リーダーノードは過剰な圧力によりスムーズにブロックを生成できず、合意投票が正常に伝播せず、ネットワークが崩壊しやすくなる。
これに対し、Solanaの創設者Anatoly Yakovenkoは今年の1月27日に、特定の人気プロジェクトの公売期間中、毎秒最大で約200万件の取引要求が同じリーダーノードに到達し、その90%以上が完全に同じ重複取引であり、最終的にSolanaがダウンした。
（参考資料：《深度調査：新しいパブリックチェーンが頻繁にダウンする理由は？》）
以上を総合すると、Ethereumは実質的に効率を犠牲にして安全性を追求し、Solanaは安全性を犠牲にして効率を追求している。その問題は次のように要約できる：
リーダーのローテーション順序が定まっているため、そのローテーションチェーンを継続的に進める必要がある。しかし、トラフィック分担メカニズムが不完全なため、リーダーノードの故障率が高く、特定の期間内にユーザートラフィックが過剰になると（特定の人気NFTの公売が開始されるなど）、複数のリーダーが次々と故障する可能性がある（例えば、将来の40のSlotのリーダーがすべてスムーズにブロックを生成できない場合）、このような場合、合意プロセスが妨げられ、ネットワークが分岐し、リーダーローテーションチェーンが完全に断裂し、最終的に完全に崩壊する。
3.BTトレントのようなTurbine伝送プロトコル：前述のGulf Streamメカニズムと組み合わせて、リーダーは一定の時間内にすべての取引要求を迅速に受け取り、その合法性を確認し、その後取引を実行する。同時に、リーダーはPOH（Proof of History）と呼ばれるメカニズムを採用し、各取引にシーケンス番号を付け、取引イベントを並べ替える。（詳細は後述する）
リーダーが取引イベントを整列させた後、取引シーケンスをX個の異なる断片に切り分け、ステーキング資産が最も多いX個のValidatorにそれぞれ送信し、彼らが他のValidatorに伝播させる。Validatorグループは受け取った断片を交換し、ローカルで完全な取引シーケンス（ブロック）を組み立てる。
理解を容易にするために、各異なる断片をデータ量を縮小した小さなブロックと見なすことができる。リーダーが一度にX個の断片を外部に配布することは、X個の異なる小さなブロックを発信し、異なるノードが受信してさらに拡散させることに相当する。
Solanaのこのメッセージ配布方式は非常に特別であり、BTトレントからインスピレーションを得ている。（原理を文字で表現するのは難しいが、主な目的は複数のノードのアイドル帯域幅を同時に利用し、データを並行して伝送することである）。一般的に、取引シーケンスが切り分けられる断片の数が多いほど、ノードグループが断片を拡散し、取引シーケンスを組み立てる速度が速くなり、データ同期効率も大幅に向上する。
他のパブリックチェーンでは、ブロック生成者がX個の隣接ノードに同じブロックを送信することが多く、これは1つのブロックをX部コピーして送信することに相当し、X個の異なる断片（小さなブロック）を配布するのではない。このようなアプローチはデータの冗長性と帯域幅の無駄を引き起こす。根本的な原因は、従来のブロック構造が切り分けられず、柔軟に伝送できないことである。Solanaは取引シーケンスをブロック構造の代わりに使用し、BTトレントのようなTurbineプロトコルを組み合わせることで、高速なデータ配布を実現し、TPSを大幅に向上させた。
Solanaの公式によれば、Turbine伝送プロトコルの下で、ネットワークに4万のノードがある場合、0.5秒以内に1つの取引シーケンスをすべてのノードに同期できる。
同時に、Turbineプロトコルの下で、ノードはそのステーキング資産の重みに従って異なる階層（優先度）に分けられ、ステーキング資産が多いValidatorが最初にリーダーから送信されたデータを受け取り、その後これらのノードが次の層に伝達する。このメカニズムにより、全ネットワークのステーキング資産の2/3の重みを持つノードグループが最初にリーダーから送信された取引シーケンスを受け取り、台帳（ブロック）の確認速度を加速する。
Solanaブラウザが公開したデータによれば、現在2/3のステーキング重みは132のノードによって分配されており、前述の伝播メカニズムと組み合わせることで、これらのノードは最初にリーダーから送信された取引シーケンスを受け取り、最初に投票を行うことになる。そして、これら132のノードの投票を得る限り、リーダーが発表した取引シーケンスは確定することができる。ある意味で、これらのノードは他のノードよりも先に行動し、もし彼らが共謀すれば、悪意のあるシナリオを生じる可能性がある。
さらに注目すべきは、現在Solanaには25のノードが1/3のステーキング重みを占めており、バイザンチンフォールトトレランス理論によれば、これら25のノードが集団で共謀すれば（例えば、特定のリーダーに投票を送らないことを故意に行う）、Solanaネットワークは混乱に陥る可能性がある。ある意味で、Solanaが直面している「寡頭政治」の問題は、すべてのPOS投票制を採用するパブリックチェーンが重視すべきものである。
4.POH（Proof Of History）：前述のように、Turbineプロトコルはリーダーが取引シーケンスを切り分け、異なる断片を発表することを可能にする。このようなアプローチには保証が必要である：取引シーケンスが切り分けられた後、簡単に再構築できる必要がある。この問題を解決するために、Solanaはデータパッケージにエラー訂正コードを混ぜ込み（データの損失を防ぐ）、独自のPOH（Proof Of History）メカニズムを導入して取引イベントを並べ替える。
Solanaのホワイトペーパーでは、Yakovenkoがハッシュ関数SHA256を例に挙げ、POHの原理を示している。理解を容易にするために、以下の例でPOHメカニズムを説明する：
（POHおよび対応する時間の進行ロジックは言葉で表現するのが難しいため、まずSolanaの中国語ホワイトペーパーを読んでPOHの解釈を理解し、この記事の以下の部分を補助的に読むことをお勧めする）
・SHA256関数の入力値と出力値は一意にマッピングされる（1対1）、入力パラメータXを後に、唯一の出力結果SHA256（X）=？；異なるXは異なる？=SHA256（X）を得る。
・SHA256をループ、再帰的に計算する場合：
X2 = SHA256 ( X1 )を定義し、次にX2を用いてX3 = SHA256 (X2)、さらにX4 = SHA256 (X3)を計算し、このプロセスを繰り返すと、Xn = SHA256 ( X[n-1] )となる。
・このプロセスを繰り返し実行すると、最終的にX1、X2、X3……Xnのシーケンスが得られ、このシーケンスには特徴がある：Xn = SHA256 ( X[n-1] )、後に位置するXnは前に位置するX[n-1]の「子孫」である。
・このシーケンスが公開されると、外部の誰かがそのシーケンスの正確性を検証したい場合、例えばXnが本当にX[n-1]の「合法的な子孫」であるかを判断したい場合、直接X[n-1]をSHA256関数に代入して計算し、結果がXnと一致するかを確認できる。
・このようなモデルでは、X1がなければX2は得られず、X2がなければX3は得られず……Xnがなければ後のX[n+1]は得られない。こうして、シーケンスは連続性と一意性を持つ。
・最も重要な点：取引イベントはシーケンスに挿入できる。例えば：
x3が生成された後、x4がまだ存在しない時、取引イベントT1は外部入力として、X3と重ね合わせてx4 = SHA256（X3+T1）を得る。この場合、X3の出現はT1よりもわずかに早く、X4は（T1+X3）から生まれた子孫であり、T1は実質的にX3とX4の「誕生日」の間に挟まれている。
このように、T2はX8が生成された後、外部の入力パラメータとして計算され、X9=SHA256（T2+X8）となり、T2の出現時間はx8とx9の「誕生日」の間に挟まれる。
・上記のシーンにおいて、実際のPOHシーケンスは以下の形式である：
ここで、取引イベントT1とT2は外部からシーケンスに挿入されたデータであり、POHシーケンスの時間記録上では、T1はX3の後、X4の前に位置する。
T1がPOHシーケンス内での順序番号を与えられれば、T1の前にSHA256計算が何回行われたかを知ることができる（T1の前にはX1、X2、X3があり、3回のSHA256計算が行われた）。
同様の理屈で、T2の前にはX1~X8の8つのXがあり、8回の計算が行われた。
以上のプロセスの平易な説明は次の通りである：ある人がストップウォッチを持って秒を数え、彼が手紙を受け取るたびに、ストップウォッチの読みを記録する。10通の手紙を受け取った後、これら10通の手紙に記録された秒数は必ず異なり、先後の区別がつくため、これにより異なる手紙に順序が付けられ、手紙に記録された内容から2通の手紙の間隔がどれくらいであるかもわかる。
・リーダーが外部に取引シーケンスを発表する際、T1のデータパッケージにX3の数値を提供し、X3の順序番号（第3の）を知らせることで、受信データパッケージのValidatorはT1の前の完全なPOHシーケンスを解析できる；
T2のデータパッケージにX8の数値とその順序番号8を提供することで、ValidatorはT2の前の完全なPOHシーケンスを解析できる。
・POHの設定に従い、各取引にPOHシーケンス内の順序番号（Counter）をマークし、その隣にあるX値（Last Valid Hash）を提供することで、各取引の順序を明らかにできる。SHA256関数自体の特性により、このようにハッシュ計算を通じて確定された順序は改ざんが難しい。
同時に、ValidatorはリーダーがPOHシーケンスを得る方法を知っており、同じ操作を実行して完全なPOHシーケンスを復元し、リーダーが発表したデータの正確性を検証できる。
例えば、リーダーが発表した取引シーケンスデータパッケージが次のようなものであるとする：
T1、順序番号3、X3に隣接；
T2、順序番号5、X5に隣接；
T3、順序番号8、X8に隣接；
T4、順序番号10、X10に隣接；
POHシーケンス初期値X1；
Validatorは上記のデータパッケージを受け取ると、X1を初期パラメータとして、SHA256関数に代入してループ計算を行い、完全なPOHシーケンスを解析することができる：
こうすることで、シーケンス内に含まれるXの総数を知る限り、計算者が何回SHA256計算を行ったかを知ることができる。事前に各ハッシュ計算にかかる時間を見積もることで、異なる取引の時間間隔を知ることができる（例えばT1とT2の間に2回のハッシュ計算が行われた場合、約？？ミリ秒である）。異なる取引の間隔の秒数を知ることで、各取引の発生時刻を粗略に推定することができ、非常に便利であり、ノードが特定のデータの到達時間を独立して確認できる。
同時に、POHメカニズムは各ノードが投票を行う時間点を統計するのにも便利である。Solanaのホワイトペーパーでは、Validatorはリーダーが毎回State状態情報を発表した後の0.5秒以内に投票を提供すべきであると提案している。
もし0.5秒が100万回のハッシュ計算に相当し（前述の100万個のX）、リーダーがStateを発表した後、後のシーケンスに連続して100万回のハッシュ計算がノードの投票に含まれなければ、皆はそのノードが怠けており、規定の時間内に投票義務を果たしていないことを知ることができ、その際にシステムは相応の罰則を実行できる（Tower BFT）。
6.Optimismとの類似性：以上がSolana独自のPOH（Proof Of History）であり、OptimismやArbitrumの取引順序形式に似ている。これらはハッシュ関数に関連する計算を通じて、「改ざんが難しく、唯一の確定した」取引イベントシーケンスを確立し、その後リーダー/シーケンサーがこのシーケンスを検証ノードValidator/Verifierに発表する。
Optimismにもリーダーに似た役割があり、シーケンサー（順序付け者）と呼ばれ、データ伝送の中でブロック構造を廃止し、定期的にEthereumの特定のコントラクトアドレスに取引シーケンスを発表し、Validator自身がそれを読み取って実行する。異なるValidatorが受け取る取引シーケンスはすべて同じであり、彼らが実行した後に得られる状態Stateも必然的に同じである。この時、シーケンサーの状態Stateと比較することで、各Validatorはその正確性を検証でき、ほとんど他のノードとコミュニケーションを取る必要がない。
Optimismの合意メカニズムでは、異なるValidator間の相互作用を要求せず、投票を収集するステップもなく、「合意」は実質的に暗黙的である。もしValidatorが取引シーケンスを実行した後、シーケンサー/リーダーが提供する状態情報Stateが正しくないことを発見した場合、「挑戦」を発起し、シーケンサー/リーダーに異議を唱えることができる。しかし、このモデルでは、Optimismは取引イベントに7日間の確定ウィンドウを提供し、シーケンサーが取引シーケンスを発表した後、7日間誰も異議を唱えなければ最終的に確認される。これは明らかにSolanaが受け入れられないものである。
SolanaはValidatorに迅速に投票を提供させることを要求し、ネットワークが迅速に合意に達し、取引シーケンスを迅速に確定させることを目的としており、これによりOptimismよりも高い効率を持つことができる。
さらに、Solanaは取引シーケンスの配布と検証の方法がより柔軟であり、シーケンスを切り分けて断片の形で配布することを許可し、Turbineプロトコルの実施に完璧な土壌を提供する。
同時に、Solanaはノードが同時に複数の計算部品を運営し、並行して異なる断片の正確性を検証し、検証作業を分担することを許可し、時間を大幅に節約する。OPやArbitrumではこのようなことは許可されておらず、Optimismは1つの取引に対して1つの実行後の状態Stateを対応させる方式を採用し、Transcation---Stateマッピングの形式で取引シーケンスを提供し、1つのCPUコアが最初から最後まで一歩ずつ計算しなければならず、全体のシーケンスの正確性を検証するのは相対的に重く非効率的である。SolanaのPOHシーケンスは任意の位置から検証を開始でき、複数の計算ユニットが同時に異なるPOH断片を検証できるため、マルチスレッドの並行検証モデルの基礎を提供する。
7.ノード自体に対する縦のスケーリング：以上はSolanaのブロック生成プロセス、合意メカニズム、データ伝送プロトコルの改善であり、さらにSolanaはSealevel、Pipeline、Cloudbreakと呼ばれるメカニズムを作成し、マルチスレッド、並行、同時実行の実行モードをサポートし、GPUを計算部品として使用することをサポートし、ノードの指示処理速度を大幅に向上させ、ハードウェアリソースの利用効率を最適化し、縦のスケーリングの範疇に属する。関連する技術的詳細は非常に複雑であり、この記事の焦点とは無関係であるため、ここでは詳述しない。
Solanaの縦のスケーリングはノードデバイスの取引指示処理速度を大幅に向上させたが、ハードウェア構成に対する要求を高めた。現在、Solanaのノード構成要求は非常に高く、多くの人々から「企業レベルのハードウェアレベル」と評され、「ノードデバイスが最も高価なパブリックチェーン」と非難されている。
以下はSolanaのValidatorノードのハードウェア要件：
CPU 12または24コア、メモリは少なくとも128 GB、ハードディスクは2T SSD、ネットワーク帯域幅は少なくとも300 MB/s、一般的には1GB/s。
現在のEthereumノードのハードウェア要件（POSへの移行前）と比較すると：
CPU 4コア以上、メモリは少なくとも16 GB、ハードディスクは0.5 T SSD、ネットワーク帯域幅は少なくとも25 MB/s。
EthereumがPOSに移行した後、ノードのハードウェア構成要求が低下することを考慮すると、Solanaのノードハードウェアに対する要求は前者をはるかに上回っている。一部の言説によれば、Solanaのノードのハードウェアコストは、数百のPOSに移行したEthereumノードに相当する。ノードの運営コストが非常に高いため、Solanaネットワークの運営は大部分がクジラや専門機関、企業の特権となっている。
これに対し、Ethereumの前CTO、Polkadotの創設者Gavin Woodは、昨年Solanaが初めてダウンした後にコメントし、真の分散化と安全性は高効率よりも価値があると述べた。もしユーザーがネットワークの全ノードを自分で運営できないのであれば、そのようなプロジェクトは伝統的な銀行と何ら変わらない。
全文のまとめ
- Solanaのスケーリングは主に、ネットワーク帯域幅の効率的利用、ノード間の通信回数の削減、ノードの処理速度の向上の3つの側面に基づいており、これらの対策はブロック生成と合意通信の時間を直接短縮するが、システムの可用性（安全性）を低下させる。
- Solanaは各ブロック生成周期Slot内のブロック生成者リーダーリストを事前に公開し、実質的に単一の信頼できるデータソースを明らかにし、これにより合意通信のプロセスを大幅に簡素化した。しかし、リーダー情報の公開は賄賂や標的攻撃などの潜在的なセキュリティリスクをもたらす。
- Solanaは合意通信（投票情報）を取引イベントとして処理し、TPSの成分の70%以上が合意メッセージであり、実際のユーザー取引に関連するTPSは約500---1000である；
- SolanaのGulf Streamメカニズムは実質的にグローバルな取引プールを廃止し、これにより取引処理速度が向上したが、通常のノードはゴミ取引を効率的に遮断できず、リーダーは巨大な圧力にさらされ、ダウンしやすくなる。リーダーがダウンすると、合意メッセージが正常に発表されず、ネットワークが分岐したり崩壊したりしやすくなる；
- Solanaのリーダーノードは取引シーケンスを発表し、実際のブロックではない。Turbine伝送プロトコルと組み合わせることで、取引シーケンスは切り刻まれ、異なるノードに配布され、最終的なデータ同期速度は非常に速い。
- POH（Proof Of History）は実質的に計時とカウントの方法であり、異なる取引イベントに不可逆的な番号を付け、取引シーケンスを生成する。同時に、同じ時間に単一のリーダーが取引シーケンスを発表するため、POH計時シーケンスが含まれ、リーダーは実質的に全ネットワークで一致するタイマー（時計）を発表する。非常に短いウィンドウ期間内に、異なるノードの帳簿の進行と時間の経過は一致している；
- Solanaには132のノードが67%のステーキングシェアを占め、そのうち25のノードが33%のステーキングシェアを占めており、基本的に「寡頭政治」または「元老院」を構成している。この25のノードが共謀すれば、ネットワークは混乱に陥る可能性がある；
- Solanaはノードのハードウェアレベルに対する要求が高く、デバイスコストを代償にして縦のスケーリングを実現した。しかし、これによりSolanaノードを運営する個体は主にクジラや機関、企業であり、真の意味での分散化には不利である。
ある意味で、Solanaは実際にパブリックチェーンの中で最も特異な存在となり、高級なノードハードウェアレベル、破壊的な合意メカニズムとネットワーク伝送プロトコルを用いて、Layer1のスケーリングの物語を極端に推進し、基本的に分割のないパブリックチェーンが長期的に維持できるTPSのボトルネックに達した。しかし、Solanaの複数回のダウンは、可用性/安全性を犠牲にして効率を追求する結果を示唆している。
長期的には、分散化と安全性は常にパブリックチェーン分野の核心的な物語であり、Solanaは一時的なTPS数値とSBFなどの金融大物の後押しによって、一時的に資本の注目を集めたが、EOSの結末はすでに示唆している。Web3の世界は単なるマーケティングや高効率を必要とせず、真に可用性を持つものだけが歴史の流れの中で立ち続け、永遠に存続することができる。
（ここで特に感謝したいのは、『組み込みシステムの安全性』の著者、劉洋氏、Rebaseコミュニティ、W3.Hitchhikerチームの本著者への支援です）
参考文献
1.Solanaホワイトペーパー日本語版
2.Gulf Stream: Solanaのメモプールなしの取引転送プロトコル
6.バイナンスウォレットと提携した高性能パブリックチェーンSolanaはどのようにスピードアップしたのか？
7.710,000 TPSを超えるブロックチェーンのオーバークロック：Proof of Historyアルゴリズムのレビュー
10.Ethereumソースコード分析：取引バッファプールtxpool
13.Tendermint-2-合意アルゴリズム:Tendermint-BFTの詳細解説
14.Cardano（ADA）の合意アルゴリズムOuroboros
15.深度調査：新しいパブリックチェーンが頻繁にダウンする理由は？
