Solanaにおけるスケーラビリティ設計

Solanaは他のどのブロックチェーンとも異なる。そのアーキテクチャは、初日からスループットをハードウェアの限界まで押し上げるよう設計されている——並列実行、組み込みのタイムキーピング、mempoolを介さないトランザクション転送——これらが組み合わさることで、1秒未満のファイナリティで数千TPSを実現している。そしてFiredancerがすでにmainnetで稼働し、Alpenglowも控えている今、その上限は大きく引き上げられようとしている。

このペースに追いつくインフラを構築するには、高速なノード以上のものが必要になる。スタックのあらゆる層を、明日の負荷は今日をはるかに上回るという前提のもとで設計する必要がある。

これは、私たちがSolanaプラットフォームをゼロから再構築する際にスケーラビリティにどう取り組んだか、そして今後に向けてどう位置づけているかについての話である。

Solanaのスケーラビリティモデルは根本的に異なる

多くのブロックチェーンインフラは、Ethereumの実行モデル——逐次的なトランザクション処理、グローバルなstate trie、比較的控えめなデータ出力——を前提に設計されている。Solanaはこれらの前提をすべて覆す。

Solanaの並列ランタイムであるSealevelは、すべてのトランザクションに読み書きセットの事前宣言を要求し、重複しないトランザクションを複数のCPUコアで同時実行できるようにする。Proof of Historyは暗号学的な時計をレジャーに直接組み込み、他のチェーンでコンセンサスを遅くしている調整オーバーヘッドを排除する。そしてGulf Streamは、トランザクションをmempoolに置いておくのではなく、次のブロックプロデューサーへ直接押し出すことで、確認レイテンシをさらに削減する。

その結果生まれるのは、極めて高い速度で膨大な量のデータを生成するネットワークだ——ピーク時には年間4ペタバイトを超える。このデータを扱うインフラは、RPCスキーマが違うだけのEthereumのように扱うことはできない。Solana特有のデータパターン、アクセス特性、スケールを前提に設計する必要がある。

この理解が、私たちのあらゆる意思決定の土台になった。

Solanaのデータ特性に合わせたアーキテクチャ設計

Solanaのデータプロファイルは、特有のインフラ上の課題を生む。ブロックは大きく密度が高い。履歴クエリは膨大な範囲にまたがる。開発者は単一トランザクションをシグネチャで取得するランダムなポイントルックアップと、あるアドレスの全シグネチャ履歴をたどる大規模なシーケンシャルスキャンの両方を必要とする。そしてこれらすべてを、世界中どこでも低レイテンシで実現する必要がある。

アーカイブアーキテクチャの技術的詳細——HBaseへの移行、三重検証によるingestion、自己修復パイプライン、そしてgetTransactionでリージョンあたり100,000RPS以上を実現した具体的な最適化——については、別のエンジニアリング記事で取り上げた。この記事では、それらの決定の背後にある設計原則を扱う。

核となる原則は次の通りだ：独立してスケールする必要がある関心事を分離すること。 従来のSolanaインフラは、データingestion、ストレージ、servingを単一のモノリシックなvalidatorノードに詰め込んでいる。この結合により、読み取りを容易にスケールできず、サービスを数時間のダウンタイムなしに再起動できず、スタック全体に手を入れずにストレージレイアウトを最適化することもできない。

私たちはシステムを独立したサービスに分解した——数秒で起動する軽量なRPCサーバー、各インスタンスが扱うデータタイプを細かく制御できる専用のingestor、そしてSolanaのアクセスパターンに特化して設計されたストレージ層だ。各層はそれぞれの条件でスケールする。トラフィックが急増すれば、同じデータ層に対して数秒でRPCインスタンスを追加起動できる。新しいリージョンをオンラインにする必要があれば、ストレージ層はserving層とは独立してレプリケートされる。

スケーラビリティの前提条件としての信頼性

インフラにはよくあるパターンがある：チームは速度を最適化し、スケーリングの壁にぶつかり、その壁が実は信頼性の問題だったと後で気づく。接続の切断、不完全なデータ、負荷下での静かな失敗——これらはすべて、姿を変えたスケーラビリティの失敗だ。

私たちは最初からこれを前提に設計した。マルチリージョンアーキテクチャには3〜5層の自律的なフェイルオーバーが組み込まれている——ノード、ラック、あるいはリージョン全体が劣化した場合、トラフィックは自動的に再ルーティングされる。

データ整合性の面では、すべてのレコードが二重に書き込まれ、プログラムによって検証され、完全性を継続的にスキャンされる。不整合が発見された場合、自己修復パイプラインが自動的に再ingestionしてギャップを修復する——ブロックあたり最大30〜50件の関連アドレスをクロスチェックしながら行う。修復プロセス全体は自動化されており、継続的に稼働している。アラート付きの静的な監視ダッシュボードではない。

Solanaにおけるデータ整合性は、多くの人が認識している以上に難しい問題だ。データの量と速度の大きさゆえに、小さなギャップでも急速に積み重なる——これは開発チームの間でよくある悩みの種であり、多くのチームがインフラプロバイダーからのデータ欠落や不整合を報告している。トランザクションがインデックスされなかったり、シグネチャ履歴が不完全だったりして開発者のアプリが壊れるまで、この問題は見えないままだ。私たちは正確性を交渉の余地のないものとして扱っており、ベストエフォートとしては扱わない。

その結果が99.99%のアップタイムであり、これは選挙の夜のPolymarketやWorldのmainnetローンチのようなアプリを8年以上支えてきたのと同じ運用の厳格さに裏打ちされている。このレベルの信頼性は単なる機能ではない——それは、スケーラビリティに関する他のすべてを可能にする土台だ。

Solanaの次のスループット時代に向けた設計

Solanaの現在のスループットは1秒あたり数千トランザクションで測られている。プロトコルのロードマップは、それをさらに桁違いに上回る方向を指しており、その軌道に合わせて設計されていないインフラはボトルネックになる。

Jump CryptoによるC言語で書かれた独立したvalidatorクライアントであるFiredancerは、2025年後半にmainnetで稼働を開始した。実験室環境では、1秒あたり100万トランザクションを超える性能を実証している。そのモジュール式のタイルベースアーキテクチャ、カーネルバイパスネットワーキング、並列署名検証は、validatorソフトウェアがハードウェアをどう使うかについての根本的な再考を表している。2025年後半時点で、Solanaのstakeの約21%がFiredancerで稼働しており、採用は加速している。

Firedancerに加えて、Alpenglowプロトコルアップグレードは、Solanaのコンセンサスメカニズムを書き換え、ブロックファイナリティを約150ミリ秒まで短縮することを目指している。そしてSIMD-0370のような提案は、ブロックレベルの計算キャップを完全に撤廃し、人為的なソフトウェア上の制限ではなく、実際にハードウェアが処理できる能力に基づいてブロックをスケールさせようとしている。

さらに、Light Protocolが開発したZK Compressionは、ゼロ知識証明を用いて複数のアカウント状態を単一のonchainアカウントに圧縮できるようにする。これはSolanaの拡大し続けるstateストレージの課題に対応するものであり、まったく新しいアプリケーション設計パターンを開く。

私たちのインフラは、こうしたアップグレードを見据えて設計されている。分解されたアーキテクチャにより、スループット要件の増大に合わせて各層を独立してスケールできる。マルチリージョンデプロイメントは、より大規模なグローバルトラフィックに対応するために必要な地理的分散を提供する。これにより、他のSolana RPCプロバイダーに対する2倍のスループット優位性は、到達点ではなく出発点だと言える。

スケーラブルなインフラが開発者にもたらすもの

スケーラビリティは、開発者が何を構築できるかを直接左右する。この8年間、私たちは開発者を最初のAPI呼び出しから、その後のあらゆる転換点まで支えてきた。Circle、Robinhood、OpenSeaのようなチームは、初期のプロトタイプから数億人のユーザーにサービスを提供する製品まで、Alchemy上でスケールしてきた。

• ミリ秒単位のアーカイブクエリにより、ウォレットは完全なトランザクション履歴を即座に表示できる。
• recency-firstなクエリにより、ユーザーの最新のアクティビティを表示するために何年分もの古いデータをスキャンする必要がなくなる。
• getTokenLargestAccountsが20件ではなく1,000件の結果を返すことで、分析プラットフォームはトークン分布についてより豊かな視点を得られる。
• ネイティブなガスレストランザクションにより、コンバージョンを妨げるオンボーディングの摩擦がなくなる。
• 100%のstaked writesにより、トランザクションが実際のブロックプロデューサーに届くことが保証され、確認の信頼性が向上する。

これらの機能が存在するのは、私たちがスケーラビリティを第一原理として扱っているからだ。

この先の道のり

Solanaは急速に進化している。ネットワークの容量は増大し、その上に構築されるアプリケーションはスケールにおいてより要求水準が高くなっていく。

私たちのコミットメントは、その流れの先を行くことだ——より低いレイテンシ、より高いスループット、より深いデータアクセス、そしてまだ実現していないユースケースを可能にする新機能への投資を続ける。インフラが、開発者が自分の製品で妥協しなければならない理由になることは決してあってはならない。

ここで述べてきたことはすべて、今日利用可能だ。

• alchemy.com/solanaから始める
• カスタムベンチマーク、専用の料金設定、その他についてはお問い合わせを。

よくある質問

Solanaのスケーラビリティが他のブロックチェーンと異なる点は何ですか？

Solanaは、Sealevelランタイムによる並列トランザクション実行、組み込みのタイムキーピングのためのProof of History、mempoolを迂回するGulf Streamを使用しており、1秒未満のファイナリティで数千TPSを実現し、ピーク時には年間4ペタバイトを超えるデータを生成しています。

Alchemyの分解されたアーキテクチャは、Solanaにおけるスケーラビリティをどう改善しますか？

Alchemyはデータingestion、ストレージ、servingを独立したサービスに分離し、それぞれが独自の条件でスケールできるようにしています。これにより、RPCサーバーを数秒で起動でき、ダウンタイムなしにトラフィックをスケールでき、スタック全体に手を入れることなく新しいリージョンをデプロイできます。

Firedancerとは何であり、Solanaのスループットにどう影響しますか？

FiredancerはJump CryptoによるC言語で書かれた独立したvalidatorクライアントで、2025年後半にmainnetで稼働を開始しました。実験室環境では、モジュール式アーキテクチャ、カーネルバイパスネットワーキング、並列署名検証により、1秒あたり100万トランザクションを超える性能を実証しています。

Alchemyは、Solanaのスケールでどのようにデータ整合性を確保していますか？

すべてのレコードは二重に書き込まれ、プログラムによって検証され、完全性を継続的にスキャンされています。自己修復パイプラインは、ブロックあたり最大30〜50件の関連アドレスをクロスチェックすることで、ギャップを自動的に再ingestionして修復します。

ZK Compressionとは何であり、Solanaにとってなぜ重要ですか？

Light Protocolが開発したZK Compressionは、ゼロ知識証明を用いて複数のアカウント状態を単一のonchainアカウントに圧縮できるようにします。これはSolanaの拡大し続けるstateストレージの課題に対応し、新しいアプリケーション設計パターンを可能にします。

Alchemyは、Solanaでどのようにより高速なアーカイブクエリを実現していますか？

私たちは、Solanaのアクセスパターンに最適化されたHBaseベースのストレージ層、recency-firstなクエリ、マルチリージョンアーキテクチャを使用し、getTransactionのようなメソッドでリージョンあたり100,000RPS以上でミリ秒単位のアーカイブクエリを提供しています。

Alchemyの Solanaインフラをスケールにおいて信頼性の高いものにしているものは何ですか？

3〜5層の自律的なフェイルオーバーを備えたマルチリージョンアーキテクチャ、自動化された自己修復パイプライン、継続的なデータ検証により、99.99%のアップタイムを実現しています。ノード、ラック、リージョン全体が劣化した場合でも、トラフィックは自動的に再ルーティングされます。

Alchemyのスケーラブルなインフラは、開発者にどのような機能を提供しますか？

ミリ秒単位のアーカイブクエリ、recency-firstなクエリ、20件ではなく1,000件の結果を返すgetTokenLargestAccounts、ネイティブなガスレストランザクション、そして確認の信頼性を向上させる100%のstaked writesです。