Solanaアーキテクチャ：SOLの速度を支える8つのイノベーション

精度に関する注記：ネットワークパフォーマンス、バリデーター数、手数料、プロトコルの機能、ウォレットサポート、およびサードパーティの連携は時間とともに変化します。日付の付いた数値は過去のスナップショットとして扱い、最新の一次資料のドキュメントを確認してください。

Solanaアーキテクチャは、その初期の技術資料にある8つの設計アイデアを通じて一般的に説明されています。一部は中心的なままであり、他のいくつかは過去の提案であったり進化したりしているため、この記事では元のモデルと現在の実装の主張を区別しています。

初期のSolana資料では、高スループット実行をサポートすることを目的とした8つのアイデアにアーキテクチャがグループ化されていました。現在のパフォーマンス、実装の所有権、ソフトウェアコンポーネント、および組織的役割は進化しているため、この記事では「8つのイノベーション」という枠組みを、完全な現在の仕様ではなく、歴史的な説明モデルとして扱います。

主なポイント

Solanaのアーキテクチャは8つの柱に基づいて構築されており、それぞれが特定のパフォーマンスボトルネックを解決しています。

1. Proof of History (PoH)：コンセンサスメカニズムが実行される前にイベントにタイムスタンプを付ける暗号学的クロック

2. Tower BFT：投票でPoHタイムスタンプを使用するコンセンサスメカニズム

3. Turbine：ブロックをより小さなパケットに分割するブロック伝播

4. Gulf Stream：スケジュールされたリーダーに基づくトランザクション転送

5. Sealevel：並列スマートコントラクト実行ランタイム

6. Pipelining：ステージ化されたトランザクション処理

7. Cloudbreak：同時アクセス用に設計されたアカウントデータベース

8. Archivers：歴史的な分散ストレージ提案

パフォーマンスに関する注記： 過去の理論上のTPS、目標スロット時間、確認、ファイナリティ、基本手数料、および優先手数料は異なる測定値です。現在の、日付の付いたメトリクスとその背後にある方法論を確認してください。

誠実なトレードオフ： Solanaは、2020年3月のメインネットローンチ以降、ネットワーク停止が記録されており、そのバリデーターハードウェア要件（128GB以上のRAM推奨）は中央集権化の圧力を生み出しています。これらは付随的な問題ではなく、既知のアーキテクチャ上のトレードオフです。

Solanaが解決するために構築された問題

ブロックチェーンは伝統的に根本的な制約に直面しています。ブロックチェーンのトリレンマとは、Vitalik Buterinによって普及した概念であり、ネットワークは3つの特性のうち最大2つを同時に達成できると述べています。それらの特性とは、スケーラビリティ（高スループット）、セキュリティ（攻撃耐性）、および分散性（分散制御）です。それを、一方の角をさらに押し出すと常に他の2つが内側に引き込まれるような三角形と考えてください。Bitcoinは10分ごとのブロック生成で約7 TPSを処理し、スループットを犠牲にしてセキュリティと分散性を優先しています。Ethereumは、スケーリングソリューションが追加される前は、ベースレイヤーで約15〜30 TPSを処理しており、こちらもセキュリティと分散性を優先していました。

Qualcommの元分散システムエンジニアであるAnatoly Yakovenko氏は、この制約に異なるアプローチを取りました。2017年11月、彼は「Proof of History: A Clock for Blockchain」というタイトルのホワイトペーパーを発表し、コンセンサスメカニズムの通信オーバーヘッドを劇的に削減できる暗号学的計時メカニズムを説明しました。Greg Fitzgerald氏が共同創設者兼CTOとして加わり、彼らは共にSolanaとなるプロトコルを構築しました。彼らが共同設立した営利企業であるSolana Labsが、コアプロトコルの開発を主導しています。ジュネーブに拠点を置く別個の非営利団体であるSolana Foundationは、エコシステム助成金、バリデーター分散化プログラム、および教育イニシアチブに資金を提供しています。

Solanaの8つの柱からなるアーキテクチャは、ブロックチェーンのトリレンマの制約の中で、スケーラビリティの限界を可能な限り押し広げるように設計されています。この設計は、スループットのコストとして、より高いバリデーターハードウェア要件を意図的に受け入れています。Solanaはブロックチェーンのトリレンマを解決するわけではありません。スケーラビリティ軸上で異常に積極的なポジションを占めています。これらのトレードオフには実際のコストが伴います。これは、以下のアーキテクチャのトレードオフのセクションで検討します。

Solanaの8つのアーキテクチャの柱：概要

歴史的な8つの要素の枠組みは、Proof of History、Tower BFT、Turbine、Gulf Stream、Sealevel、Pipelining、Cloudbreak、およびArchiversをカバーしています。特にArchiversの提案のように、すべての要素が個別に展開される現在のサブシステムと見なされるべきではありません。

1. Proof of History：コンセンサスメカニズムが実行される前に検証可能なタイムスタンプ記録を作成する、シーケンシャルなSHA-256ハッシュチェーン
2. Tower BFT：PoHタイムスタンプを効率的に投票に使用する、PoH強化型ビザンチン障害耐性コンセンサスメカニズム
3. Turbine：ブロックをシュレッドと呼ばれる小さな誤り訂正符号化されたパケットに分割する、BitTorrentにインスパイアされたブロック伝播プロトコル
4. Gulf Stream：トランザクションを次のバリデーターリーダーに直接ルーティングする、メンプールレスのトランザクション転送プロトコル
5. Sealevel：数千もの競合しないプログラムを同時に実行する、並列スマートコントラクト実行ランタイム
6. Pipelining：トランザクションを4つの同時ハードウェアステージで処理する、トランザクション検証最適化（TVO）システム
7. Cloudbreak：同時読み書きをサポートするためにメモリマップドファイルを使用する、水平スケーリングされたアカウントデータベース
8. Archivers：誤り訂正符号化の概念を使用した分散型台帳ストレージの歴史的な提案

各柱は、以下のセクションで詳細に説明されています。

Proof of History (PoH)：Solanaの計時エンジン

Proof of History (PoH) は、コンセンサスメカニズムが実行される前にイベントの検証可能な時系列記録を作成するシーケンシャルなSHA-256ハッシュチェーンであり、ネットワーク全体の共有暗号学的クロックとして機能します。PoHはSolanaのコンセンサスメカニズムではありません。その役割はTower BFTに属します。PoHはTower BFTを高速化する計時レイヤーです。

PoHを、ネットワーク上のすべてのバリデーターが互いの時計を最初に確認する必要なしに、イベント間の経過時間を証明する暗号学的なストップウォッチと考えてください。従来のブロックチェーンネットワークでは、バリデーターはコンセンサスの各ラウンドで互いにタイムスタンプメッセージを交換する必要がありますが、これはバリデーターセットのサイズとともに増加する通信オーバーヘッドを追加します。PoHは、この交換を完全に排除します。

技術的には、PoHはシーケンシャルなSHA-256ハッシュチェーンであり、各出力が次の計算の入力となります。SHA-256はこのチェーン形式では並列化できないため、チェーンの長さは改ざん不可能な経過時間の記録となります。N個のハッシュのチェーンを生成したバリデーターは、N個のシーケンシャルハッシュ演算を計算するために費やされた時間を実証的に示しています。ショートカットは存在しません。Anatoly Yakovenkoは、2017年11月のホワイトペーパー「Proof of History: A Clock for Blockchain」でこのメカニズムを最初に説明しました。

PoH は検証可能な遅延関数 (VDF) として機能します。これは、計算に予測可能で逐次的な時間がかかるものの、ほぼ瞬時に検証できる計算です。計算時間と検証時間のこの非対称性が、PoH を実用的なものにしています。バリデーターは PoH の出力をブロードキャストでき、観測者は、生成に実際にかかった時間にもかかわらず、マイクロ秒単位でその真正性を検証できます。これは、学術研究者やプロトコルアナリストが PoH のセキュリティ特性の理論的基盤として認識する特性です。

検証可能な順序参照を確立することにより、PoH は一部のタイミング調整を軽減できます。コンセンサスメッセージングを排除したり、特定のスロット、確認、またはファイナリティ時間を直接保証したりするものではありません。

重要な明確化: Solana は「Proof of History ブロックチェーン」と説明されることがありますが、これは PoH が Proof of Stake (PoS) を置き換えることを示唆しています。これは誤りです。Solana は、その経済的セキュリティ層において Proof of Stake ブロックチェーンです。バリデーターは SOL を担保としてステーキングし、不正行為に対してスラッシングに直面します。PoH は、Solana の PoS コンセンサスを、Tower BFT を通じて実装された、より高速で効率的なものにする暗号時計です。両方の層が必要であり、どちらも他方を置き換えるものではありません。

Tower BFT: Solana's Consensus Mechanism

Tower BFT は Solana のコンセンサスメカニズムです。これは PoH タイムスタンプ記録を共有クロックとして使用する、Practical Byzantine Fault Tolerance (pBFT) の PoH 拡張バリアントであり、バリデーターがクロック同期メッセージを交換せずに台帳状態に投票することを可能にします。

Byzantine Fault Tolerance (BFT) は、分散システムが、一部の参加者が悪意を持って、あるいは予測不能に動作した場合でも、正しくコンセンサスに到達できる特性を指し、分散コンピューティングにおけるビザンチン将軍問題にちなんで名付けられました。従来の pBFT アルゴリズムは、共通の時間の認識を確立するためにノード間で広範なメッセージパッシングを必要としますが、これはスケーリングには非現実的です。Tower BFT は、そのメッセージパッシングを PoH 記録に置き換えます。バリデーターはすでに PoH クロックを共有しているため、タイムスタンプを交渉する必要はありません。

バリデーターは、SOL をステーキングし、トランザクションを検証し、リーダーとして選択されたときにブロックを生成し、台帳状態に投票するネットワーク参加者です。彼らはフォークに対して指数関数的に増加する時間ロックされた投票を行います。バリデーターが特定のフォークに長く投票するほど、そのフォークが放棄された場合、スラッシング (不正または不整合な動作に対してステーキングされたトークンを削除するペナルティメカニズム) によって失う SOL が増えます。この投票ロックアウトメカニズムは、追加の通信ラウンドを必要とせずに、正直な参加に対する強力な経済的インセンティブを生み出します。

Tower BFT は、バリデーターセットの最大 3 分の 1 がビザンチン的に動作することを許容します。バリデーターの 3 分の 1 未満が悪意を持って動作した場合、ネットワークは正しくコンセンサスに到達します。このしきい値は、1982 年に Lamport、Shostak、Pease によって最初に形式化されたビザンチン将軍問題の数学的要件に由来します。研究者向けのコンセンサス系統: pBFT (Castro and Liskov, 1999) は基礎的なアルゴリズムを確立しました。HotStuff や Tendermint を含む後続のバリアントはそれを改善しました。Tower BFT (2017) は、PoH を通じてクロック同期のオーバーヘッドを排除するというさらなる一歩を踏み出しました。

ターゲットスロット時間は、ファイナリティ保証として提示されてはなりません。アプリケーションは、処理済み、確認済み、およびファイナライズされたコミットメントレベルを区別し、リスクモデルに基づいて確認ルールを選択する必要があります。

Turbine: Block Propagation at Scale

理論上の TPS 65,000 で、すべてのバリデーターにフルブロックをブロードキャストすると、ネットワークサイズに比例して増加する帯域幅のボトルネックが発生します。Turbine は、BitTorrent が大規模ファイル配布を解決するのと同じ方法でこれを解決します。つまり、データを小さな断片に分割し、ネットワーク全体に伝播負荷を分散させます。

Turbine は、BitTorrent のピースベースの配布モデルに触発された Solana のブロック伝播プロトコルです。1 つのリーダーが完全なブロックをすべてのバリデーターに同時にブロードキャストするのではなく、Turbine はブロックをシュレッドと呼ばれる小さな誤り訂正符号化されたパケットに分割し、ツリー構造のバリデーターネットワークを通じてそれらを配布します。

シュレッドは冗長性のために誤り訂正符号化されています。伝播ツリー内の各ノードはシュレッドのサブセットを受け取り、それを次のレイヤーに再送信し、受け取ったサブセットから完全なブロックを再構築します。誤り訂正符号化により、一部のシュレッドが送信中に失われたとしても、ブロックは残りのパケットから再構築できます。各バリデーターはブロック全体のデータのほんの一部しか処理しないため、帯域幅要件はネットワークサイズに対して線形ではなく対数的にスケーリングします。

バリデーターセットを拡張しても、ノードあたりの帯域幅要件は比例して増加しません。2,000 のバリデーターを持つネットワークは、集権型システムよりも 2,000 倍の帯域幅を各バリデーターに処理させる必要はありません。伝播ツリーが負荷を分散します。Turbine のシュレッド構造は、バリデーターオペレーターがデータ受信およびブロック再構築能力を計画する際に重要です。

Gulf Stream: Mempool-less Transaction Forwarding

Gulf Stream は、従来の共有グローバルメンプールではなく、リーダーを意識したフォワーディングを使用します。これはキューイングモデルを変更しますが、輻輳やトランザクション順序付けのインセンティブを排除するものではありません。

Ethereum では、未確認のトランザクションはメンプールに待機します。これは、ブロックに含めるのを待っている未確認トランザクションの共有プールです。高需要時には、このプールは輻輳、手数料の高騰、およびメンプール内でのトランザクションの順序変更、挿入、または検閲によって最終確定前に抽出される利益である Maximal Extractable Value (MEV) の発生源となります。Ethereum ユーザーはトランザクションの優先順位付けのために高いガス手数料を提示するため、ピーク時の使用量では手数料が歴史的に 5 ～ 50 ドル以上に達しました。

この設計は、Solana の既知のリーダー スケジュールを使用して、従来のグローバル プールにブロードキャストする代わりに、トランザクションを今後のリーダーに転送します。バリデーターは、ブロック生成の順番を待つ前にトランザクションをステージングできるため、キューイング遅延を短縮できる可能性がありますが、輻輳、手数料競争、ドロップ、および MEV は個別の懸念事項として残ります。

リーダーを意識したトランザクション フォワーディングは、トランザクションがスケジュールされたリーダーに到達する方法を変更しますが、輻輳、優先手数料競争、MEV、トランザクションのドロップ、またはバリデーターリソースの圧力を排除するものではありません。現在の基本手数料と優先手数料は、固定の USD 金額に変換するのではなく、直接測定する必要があります。

メンプールの不在は、Solana 上で構築する開発者のトランザクション送信パターンを変更します。トランザクションには予測可能な転送パスがあり、完全なファイナリティの前に楽観的な確認が可能になります。Solana における MEV の表面積は Ethereum よりも大幅に小さいですが、ゼロではありません。ステーキング加重トランザクション順序付けは独自のダイナミクスを生み出すため、dApp 設計者は構築前にこれを研究する必要があります。

Sealevel: Parallel Smart Contract Execution

Sealevel は Solana の並列スマートコントラクト実行ランタイムであり、オンチェーンプログラム (Ethereum がスマートコントラクトと呼ぶものを Solana ではこう呼びます) を実行するエンジンです。Ethereum の EVM はコントラクトを一度に 1 つずつ逐次的に実行しますが、Sealevel は利用可能な GPU および CPU コア全体で、競合しない何千ものプログラムを同時に実行します。

Ethereum の EVM は、スーパーマーケットの 1 つのチェックアウトレーンのようにスマートコントラクトを処理します。つまり、一度に 1 つのトランザクション、すべての客が前の客の後ろに並びます。Sealevel は 20 のチェックアウトレーンを同時に開き、競合しないトランザクションを並列で実行します。これが、Solana のスループットがベースレイヤーで Ethereum を超える主なアーキテクチャ上の理由です。

Solanaのプログラミングモデルでは、すべてのトランザクションが送信時に読み書きするアカウント（Solana上のデータを保存する状態オブジェクト）を宣言する必要があるため、並列処理が可能です。Sealevelはこれらのアカウントアクセスリストを分析して、競合しないトランザクションを特定します。完全に異なるアカウントにアクセスするトランザクションは、競合する状態変更を生成することなく同時に実行できます。アカウントを共有するトランザクションは、逐次的に実行する必要があります。Sealevelランタイムは、この宣言を使用して、利用可能なハードウェアコア間で並列または逐次実行をスケジュールします。

オンチェーンプログラムは主にRustで記述され、Berkeley Packet Filter (BPF) バイトコードにコンパイルされ、Sealevelランタイムによって実行されます。GPUおよびCPUコア全体での並列実行により、65,000 TPSという理論上の性能がハードウェアレベルで物理的に達成可能になります。

ビルダーにとっての意味

Solanaでプログラムをデプロイする際、トランザクション送信時にプログラムが読み書きするすべてのアカウントを宣言する必要があります。このアカウントアクセスリストはオプションではなく、Sealevelが並列実行をスケジュールするために使用するメカニズムです。アカウントを省略したり、誤って宣言したりすると、トランザクションの失敗につながります。

他のプログラムと状態を共有するプログラム（同じアカウントに書き込む）は、並列処理の恩恵を受けることができず、常に逐次実行されます。可能な限り共有状態を最小限に抑えるようにプログラムのアカウント構造を設計してください。狭く、重複しないアカウントアクセスパターンを持つプログラムは、Sealevelの並列スケジューラから最大の恩恵を受けます。

Anchorフレームワークは、一般的なプログラムパターンを簡素化するマクロと抽象化を提供するRustベースのツールキットであり、Solanaプログラムで最も広く使用されている開発ツールキットです。アカウントモデル、プログラム由来アドレス、およびSealevelランタイムの詳細については、Solana開発者ドキュメント.)を参照してください。

パイプライニング：トランザクション検証を組み立てラインのように

自動車の組み立てラインは、1台の車を完全に作り終えてから次の車に取り掛かるわけではありません。各ステーション（溶接、塗装、内装）は、同時に別の車で作業します。Solanaはこの同じロジックを、トランザクション検証最適化（TVO）を通じてトランザクション検証に適用します。

Solanaにおけるパイプライニングとは、TVO、すなわちCPUパイプラインアーキテクチャをブロックチェーンのトランザクション処理に適用することを指します。トランザクション検証プロセスは4つの個別のステージに分割され、それぞれが独立したハードウェアユニットによって並行して処理されます。あるトランザクションバッチが1つのステージを通過している間に、次のバッチはすでに先行ステージに入っています。

4つのステージは次のとおりです。

1. フェッチ: カーネルスペースのユニットがネットワークから受信トランザクションデータを取得します。
2. 署名検証（SigVerify）: GPUがバッチ全体の暗号署名を並列で検証します。
3. バンキング: CPUがトランザクションロジックを処理し、アカウント残高を確認し、アカウントの状態を更新します。
4. 書き込み確認: ディスクが最終的な状態変更を書き込みます。

バッチAがバンキングステージにある間に、バッチBはSigVerifyステージにあり、バッチCはフェッチされています。どのハードウェアも、前のバッチの完了を待ってアイドル状態になることはありません。この継続的なステージングにより、スループットを制限する可能性のある処理ステージ間のCPUアイドル時間が排除されます。

パイプライニングは、SealevelおよびGulf Streamとともに、Solanaの総トランザクション処理能力を生み出す3つの柱の1つです。Solanaは、いずれかのステージがバッチ間でアイドル状態になるのを防ぎ、すべての処理コンポーネントを常に稼働させることにより、同じハードウェアからより多くのスループットを引き出します。

Cloudbreak：水平スケーリングされたアカウントデータベース

Cloudbreakは、Solanaの並列プロセッサがキューイングなしでアカウントデータへの読み書きを同時に行えるようにするファイルシステムです。これがなければ、ストレージレイヤーはすべてのアカウントの読み書きをシリアル化し、Sealevelの並列処理によるメリットはデータベース境界で消滅してしまうでしょう。

CloudbreakはSolanaの水平スケーリングされたアカウントデータベースであり、ネットワーク上のすべてのアカウントの状態を保存するデータ構造です。メモリマップドファイルとSSDに最適化されたデータ構造を使用し、複数のスレッド間での同時読み書きをサポートします。

アカウントは、並列アクセス可能な複数のデータ構造に分散されています。オペレーティングシステムのメモリマップドI/Oにより、Cloudbreakはディスク上のアカウントデータをRAM上にあるかのように扱うことができ、シークレイテンシを排除し、スレッドレベルでの同時アクセスを可能にします。Sealevelが10,000件の並列トランザクションをスケジュールすると、Cloudbreakはリクエストをキューにシリアル化することなく、10,000件の同時アカウント読み書きを処理します。

データベースアーキテクチャと実行ランタイムは相互に依存しており、どちらか一方がなければスループットは実現しません。CloudbreakのI/Oパターンには、高性能NVMe SSDが必要です。標準的な回転ディスクドライブでは、Cloudbreakの同時アクセスモデルが要求するランダムな読み書きスループットを維持できません。Cloudbreakのアカウントモデルを理解することは、Solanaプログラム設計の基礎となります。すべての状態は個別のカウントオブジェクトに格納され、プログラムはそのアカウント上でステートレスに操作され、アカウントレイアウトの決定は実行時の読み書きパフォーマンスに直接影響します。

Archivers：歴史的ストレージの提案

Archiversの概念は、Solanaの初期のアーキテクチャ資料に登場しますが、現在の実運用サブシステムとして提示されるべきではありません。最新の一次資料の証拠が必要です。

初期の設計資料では、Archivers（一部の説明ではReplicatorsとも呼ばれる）が、歴史的な台帳データの断片を保存し、ストレージを証明する軽量な参加者として提案されていました。これは台帳の成長に対する当初のアプローチを説明するものですが、現在の一次資料の確認なしに、アクティブな報酬を得る実運用ネットワークとして説明されるべきではありません。現在の台帳保持およびアーカイブインフラストラクチャは別途文書化する必要があります。

8つのアーキテクチャの柱がすべて整ったことで、統合システムは、次のセクションで定量化される、Solanaをほとんどの他のパブリックブロックチェーンから際立たせるパフォーマンスベンチマークを生み出します。

Solanaのパフォーマンスベンチマーク：TPS、手数料、ブロックファイナリティ

過去の理論的ベンチマークにおける約65,000 TPSは、最適な実験条件下でのSolanaの理論上の最大値であり、持続的な実世界の数値ではありません。これらの数値を投資分析やシステム設計に使用する人にとって、この区別は重要です。

パフォーマンス比較には、現在の一次情報源と一貫した測定方法を使用してください。

実際のメインネットのスループットは、いくつかの理由で理論上の最大値を下回ります。通常の需要下では、すべてのトランザクションスロットが完全に埋まるわけではありません。スパムフィルタリングメカニズムは、バンキングステージに到達する前に低品質のトランザクションを拒否します。ネットワーク条件が伝播タイミングに影響します。理論上の天井に近づくには、持続的なピーク需要とバリデーターセット全体でのハードウェアの完全な利用が必要ですが、これは継続的ではなく、特定の高トラフィックイベント中に発生する条件です。

Solanaの実行スループット特性は、連携して機能する複数のアーキテクチャ要素に由来します。PoH（プルーフ・オブ・ヒストリー）は、検証可能な順序付けのリファレンスを提供し、時間の調整にかかるオーバーヘッドを削減します。Sealevel（シーレベル）は、競合しない処理を並列に実行します。リーダー認識型のフォワーディングにより、ブロックスロットが開く前にトランザクションをステージングできるため、ネットワークの遅延を解消するわけではありませんが、従来のメンプールによるキューイングを一部軽減できます。

Ethereumのレイヤー2エコシステム（ArbitrumやOptimismを含む）や将来のシャーディングアップグレードにより、Ethereumの実効スループットはベースレイヤーの数値を大幅に上回ります。特定のユースケースで2つのプラットフォームを評価する際は、いかなる完全な比較においても、その拡張されたキャパシティを考慮に入れる必要があります。

アーキテクチャからアプリケーションへ：Solanaの設計がいかに現実のユースケースを可能にするか

Solanaのアーキテクチャ上の選択は、単なる抽象的なパフォーマンス数値ではなく、その上に構築されたアプリケーションに対して具体的かつ測定可能な成果をもたらします。

NFT： Solanaの全般的に低い手数料と並列実行は、大量のミント（鋳造）をサポートできますが、優先手数料、アプリケーションコスト、混雑、失敗、およびアセット標準は依然として重要です。Gulf Stream（ガルフストリーム）は、手数料競争を排除するものではありません。

DeFi： Solanaのランタイムは競合しないトランザクションを並列に処理でき、全般的に低い手数料は頻繁なインタラクションをサポートできます。実際のスワップの遅延とコストには、ルーティング、スリッページ、優先手数料、失敗したトランザクション、プログラムの計算量、および市場状況が含まれます。Gulf Streamは、MEV（最大抽出可能価値）やフロントランニングのリスクを排除しません。

NFTゲームとマイクロトランザクション： 全般的に低い手数料は少額ののアクションをサポートできますが、アプリケーションの総コストや失敗したトランザクションは依然として重要です。EthereumのL1およびL2のコストは、最新のデータを使用して個別に比較されるべきです。

決済： Solanaベースの決済アプリケーションは、迅速なユーザーフィードバックを目標にできますが、ウォレットの承認、楽観的確認、確定したファイナリティ、加盟店のリスク許容度、およびオフチェーン操作は、それぞれ独立した段階です。クレジットカードの承認は、パブリックブロックチェーンの決済と同等ではありません。

これらのアプリケーションを可能にするアーキテクチャの選択には、文書化されたトレードオフも伴います。次のセクションでは、それらを包み隠さず検証します。

アーキテクチャのトレードオフ：ネットワークの信頼性、分散化、および速度

Solanaは、2020年3月のメインネットローンチ以来、文書化されたネットワーク停止を経験しています。これらは主に、バリデーターのメモリを圧倒し、バリデーターがコンセンサスから外れる原因となった、ボットによるトランザクションの洪水によって引き起こされました。

ネットワークの停止

Solanaの高スループット設計は、最小限の事前フィルタリングでトランザクションを処理するため、特有の脆弱性が生じます。ボットがスパムトランザクションをネットワークに氾濫させると、トランザクションがフィルタリング段階に達する前にバリデーターが利用可能なメモリを使い果たし、コンセンサスの失速を引き起こす可能性があります。主な文書化された停止には、ボット主導のIDOイベントによるトランザクションボリュームの急増によって引き起こされた2021年9月の約17時間にわたる停止や、バリデーターからの過剰な重複トランザクションに関連した2022年1月の停止が含まれます。2022年と2023年にも、さらに短時間の停止が発生しています。

Solana Labsは、2つの主要なアーキテクチャ上の緩和策を導入しました。QUICネットワークプロトコルがトランザクションの取り込みにおいてUDPに取って代わり、単一のソースが送信できるトランザクション数を制限する接続レベルのフロー制御を提供しました。ステーキングの重み付けがされたQoS（Quality of Service）は、SOLのステーキング量が多いバリデーターからのトランザクション転送を優先し、ステーキング量の少ないソースによるスパムの影響を低減させました。コンピューティングユニットの手数料市場は、大量のスパムに対して経済的な摩擦を生じさせます。これらの緩和策が導入されて以来、停止の頻度は減少しています。停止の履歴は、継続的な高可用性を必要とするアプリケーションにとって、依然として既知のリスク要因です。

バリデーターの中央集権化に関する懸念

Solanaのバリデーターには、ハイスペックなハードウェアが必要です。Solana財団のバリデータードキュメント,)によると、推奨スペックには128GB以上のRAM、高性能NVMe SSD、および高帯域幅のインターネット接続が含まれます。プロトコルのアップグレードとともに要件は進化するため、閲覧時点での最新スペックを確認してください。これらの要件は、EthereumのバリデーターがPoSコンセンサスに参加するために必要なものを大幅に上回っています。

ハードウェアの障壁により、バリデーターの潜在的なプールは、十分な資本投資を行えるオペレーターに限定されます。ハードウェア要件には実際のエンジニアリング上の目的があります。つまり、現在のスループット目標はそれらに依存しているのです。同時に、それらはより広範なバリデーター参加に対する真の障壁でもあります。Solana財団は、小規模オペレーター向けのバリデーター分散化プログラムや助成金に資金を提供していますが、パフォーマンス目標とハードウェアコストの間の緊張関係は、付随的なポリシーの問題ではなく、設計の構造的な特徴です。

ブロックチェーンのトリレンマにおける位置付け

Solanaはブロックチェーンのトリレンマを解消するものではありません。そのアーキテクチャは、スケーラビリティを優先しセキュリティを維持する一方で、分散化への圧力となる高いバリデーターハードウェア要件を受け入れるという、意図的な選択を表しています。Ethereumは分散化とセキュリティを優先し、レイヤー2ソリューションを通じてスケーラビリティに対処しています。Bitcoinは、最小限のスループットを代償に、セキュリティと分散化を優先しています。各チェーンは同じトリレンマの中で異なるエンジニアリング上のポジションを占めており、これら3つの次元すべてを同時に最大化する構成は存在しません。

停止の履歴、バリデーターのハードウェア要件による中央集権化への圧力、およびトリレンマにおける位置付けは、Solanaネットワークを厳密に技術評価する上での重要な要素です。

Solana vs. Ethereum vs. Bitcoin：アーキテクチャの比較

過去のベンチマークでは、SolanaはEthereumメインネットよりも高いベースレイヤーのスループット特性を示していますが、その測定値は単純に比較できるものではありません。PoHはコンセンサス前の順序付けを提供し、Sealevelは競合しない処理を並行して実行し、リーダー認識型のフォワーディングはトランザクションのルーティングを変更します。しばしば引用される「約65,000」や「約15–30」といったTPSの数値は、ネットワークの永続的な特性ではなく、手法に依存した過去の基準点です。

スループットと実行モデル

EthereumのEVMは、1ブロックにつき一度に1つずつコントラクトを順次実行します。Sealevelは、数千の競合しないコントラクトを同時に実行します。これがTPSの差の主な要因です。Ethereumは、レイヤー2のスケーリングによってスループットに対処しています。ArbitrumやOptimismを含むロールアップは、オフチェーンでトランザクションを処理し、圧縮されたバッチをEthereumのベースレイヤーで決済することで、実効キャパシティを大幅に向上させます。Solanaのアプローチはレイヤー1での水平スケーリングであり、レイヤー2アーキテクチャが開発者やユーザーにもたらす追加の複雑さを回避しています。

開発者プラットフォームの比較

Ethereumの開発者エコシステム（Solidity、EVMツール、長年の監査済みコードを持つ確立されたDeFiプロトコル）は、Solanaよりも大規模で成熟しています。SolanaのRustとSealevelモデルは、より高いベースレイヤーのスループットと低い手数料を提供しますが、アカウントモデルと、Ethereumには直接的な相当するものがない「アカウントアクセス宣言」の要件を理解する必要があります。スループットと手数料コストが制約となるアプリケーションは、Solanaのアーキテクチャに適しています。EVM互換性、広範な開発者人材プール、またはベースレイヤーの最大限の分散化を優先するアプリケーションは、EthereumのベースレイヤーまたはそのL2エコシステムにより適しています。

第3の基準点としてのBitcoin

Bitcoinのアーキテクチャは、スループットよりもセキュリティと分散化を優先しています。約7 TPS、ブロック時間10分という仕様のBitcoinは、高頻度のアプリケーション向けに設計されていません。そのプルーフ・オブ・ワークによるコンセンサスは、設計上計算負荷が高く、経済的なステーキングではなくエネルギー消費を通じてセキュリティを確保しています。SolanaとEthereumはどちらも、Bitcoinがネイティブにはサポートしていないプログラム可能なスマートコントラクトプラットフォームを提供しています。Bitcoinのアーキテクチャ上の立場は、アプリケーション展開において直接的な競合相手というよりも、異なるカテゴリーのシステムと言えます。

5つの次元すべてにおける完全なデータ比較については、上記のパフォーマンスベンチマーク表を参照してください。

Solanaのアーキテクチャに関するよくある質問

Solanaにおけるプルーフ・オブ・ヒストリーとは何ですか？

プルーフ・オブ・ヒストリー（PoH）は、コンセンサスが実行される前に、イベントの検証可能で時間順に並んだ記録を作成するシーケンシャルなSHA-256ハッシュチェーンです。これはバリデータネットワーク全体で共有される暗号化クロックとして機能し、バリデータがタイムスタンプメッセージを交換することなくトランザクションを処理できるようにします。PoHはSolanaのコンセンスメカニズムではありません。コンセンスはTower BFTが担当し、PoHのタイムスタンプを共有の時間参照として使用します。

Solanaは1秒間に何件のトランザクションを処理できますか？

過去の資料では理論的および観測されたTPSの範囲が引用されていますが、実際のスループットはトランザクションの組み合わせ、投票の集計、フィルタリング、混雑状況、バリデータソフトウェア、および測定手法に依存します。現在の一次ソースのデータを使用し、何がカウントされているかを定義してください。

Solanaの創設者は誰ですか？

Solanaは、Anatoly Yakovenko氏とGreg Fitzgerald氏によって共同創設されました。分散型システムとクロック同期を専門としていた元QualcommのエンジニアであるYakovenko氏は、2017年11月のホワイトペーパーで初めてプルーフ・オブ・ヒストリーのメカニズムについて説明しました。彼らが共同設立した営利目的の開発会社であるSolana Labsが、プロトコルエンジニアリングを主導しています。ジュネーブに拠点を置く独立した非営利団体であるSolana Foundationは、エコシステムの発展を支援しています。

なぜSolanaはEthereumよりも速いのですか？

いくつかのアーキテクチャ層がパフォーマンスの差に寄与しています。PoHは検証可能な順序付けの参照を提供することで調整のオーバーヘッドを削減し、Sealevelは競合しない作業を並列に実行し、リーダーを認識した転送によりトランザクションがスケジュールされたバリデータに到達する方法が変わります。過去のTPS数値は手法に依存するものであり、いずれのネットワークの恒久的な特性として扱うべきではありません。

Solanaの8つのコア・イノベーションとは何ですか？

初期の資料では、アーキテクチャをプルーフ・オブ・ヒストリー、Tower BFT、Turbine、Gulf Stream、Sealevel、パイプライニング、Cloudbreak、Archiversの8つに分類しています。これは歴史的な説明の枠組みであり、各項目（特にArchivers）が現在も個別の展開されたサブシステムとして残っていることを証明するものではありません。

SolanaにおけるTower BFTとは何ですか？

Tower BFTは、PoHスロットと増加する投票ロックアウトを中心に構築された、Solanaのスケーキング加重投票およびフォーク選択メカニズムです。特定の自動スラッシングの実装を前提としたり、バリデータを平等にカウントしたりしないでください。ビザンチン閾値はステーキング量に応じて加重され、安全性とライブネスの仮定にはより正確な扱いが必要です。

SolanaにおけるGulf Streamとは何ですか？

Gulf Streamは、従来のグローバルなメンプールではなく、リーダーを認識したトランザクション転送について説明しています。これによりキューイングの一部が削減される可能性がありますが、優先手数料（プライオリティ手数料）の競争、混雑、トランザクションのドロップ、MEV、またはフロントランニングのリスクがなくなるわけではありません。現在のネットワークの挙動については、実装ドキュメントを確認してください。

Sealevelランタイムとは何ですか？

Sealevelは、Solanaの並列スマートコントラクト実行ランタイムです。コントラクトを1つずつ実行するEthereumのEVMとは異なり、Sealevelは利用可能なCPUおよびGPUコア全体で、数千の競合しないプログラムを同時に実行します。並列化は、すべてのトランザクションが送信時にどのプログラムにアクセスするかを宣言することを要求することで可能になり、ランタイムが競合しない操作を特定してそれらを並行してスケジュールできるようになっています。

Solanaはプルーフ・オブ・ステークのブロックチェーンですか？

はい。Solanaは、経済的セキュリティレイヤーとしてプルーフ・オブ・ステーク（PoS）を使用しています。バリデータは担保としてSOLをステーキングし、不正または一貫性のない行動に対してスラッシングのペナルティを受けます。プルーフ・オブ・ヒストリーは、SolanaのPoSコンセンスを高速化する独立した暗号化タイムキーピングメカニズムです。PoHはPoSに代わるものではなく、PoSベースのコンセンスメカニズムであるTower BFTの効率を高めるものです。

なぜSolanaではネットワーク停止が発生するのですか？

Solanaで記録された機能停止は、主にボットが生成したトランザクションの洪水がバリデータのメモリを圧倒し、バリデータがコンセンスから外れたことによって引き起こされました。このアーキテクチャの高スループット設計は、最小限の事前フィルタリングでトランザクションを処理するため、大量のスパム攻撃に対して脆弱性が生じます。Solana Labsは、機能停止の頻度を減らすためのアーキテクチャ上の緩和策として、QUICネットワーキングとステーク加重QoSを実装しました。特定の記録された事象については、アーキテクチャのトレードオフのセクションを参照してください。

SolanaはEthereumとどう違うのですか？

主なアーキテクチャの違いは、実行モデル（並列のSealevel vs. 逐次のEVM）、トランザクションルーティング（メンプールのないGulf Stream vs. グローバルメンプール）、プログラミング言語（Rust vs. Solidity）、およびベースレイヤーのスループット（理論上約65,000 TPS vs. 約15–30 TPS）です。どちらのブロックチェーンも、経済的セキュリティのためにプルーフ・オブ・ステークを使用しています。Ethereumのより大きな開発者エコシステムとレイヤー2オプションはEVM互換プロジェクトに適しており、Solanaのベースレイヤーのスループットと料金体系は、トランザクション量とコストが主要な制約となるアプリケーションに適しています。

Solanaのブロックチェーンのトリレンマの解決策は何ですか？

完全なトリレンマの解決策というものは存在しません。Solanaは代わりにトレードオフを選択しています。このアーキテクチャはスケーラビリティを優先し、セキュリティを維持する一方で、分散化に測定可能な圧力を与える高いバリデータハードウェア要件を受け入れています。これはブロックチェーンのトリレンマにおける特定のエンジニアリング上のポジションであり、それを排除するものではありません。Solanaのポジションは、他の主要なブロックチェーンと比較して、スケーラビリティ軸において非常に積極的です。

Solanaではどのプログラミング言語が使用されていますか？

Solanaのオンチェーンプログラムは主にRustで記述され、Berkeley Packet Filter (BPF) バイトコードにコンパイルされ、Sealevelランタイムによって実行されます。CおよびC++もサポートされています。Rustベースのツールキットであり、一般的なプログラムパターンを簡素化するマクロと抽象化を提供するAnchorフレームワークが、最も広く使用されている開発ツールキットです。現在のエコシステムツールについては、Solanaの開発者ドキュメントを参照してください。

Solanaのトランザクション手数料はいくらですか？

Solanaのトランザクションコストには基本料金が含まれ、優先順位付けや計算に関連するコストが含まれる場合があります。米ドル換算の価値はSOLの価格とともに変化し、混雑状況やアプリケーションの挙動が最終的な実行コストに影響します。Gulf Streamは手数料競争を排除するものではありません。

Solanaにはいくつのバリデータがいますか？

本稿執筆時点で、Solanaには1,000以上の現役バリデータが存在します。現在の数と分布については、Solana Foundationのバリデータ統計.）で確認してください。バリデータには128GB以上のRAMや高性能NVMe SSDを含む多額のハードウェア投資が必要であり、これが他のほとんどのプルーフ・オブ・ステーク・チェーンよりも参入障壁を高めており、継続的な分散化への懸念の主な要因となっています。

BybitでSOLを探索する

読者は、現在のSOL市場情報)またはSOL/USDTの現物市場.)を確認できます。これらのリンクは市場へのアクセスを提供するものであり、Solana、ウォレット、またはサードパーティのプロトコルがあらゆる読者に適していることを証明するものではありません。

結論：SolanaのアーキテクチャがWeb3エコシステムに意味するもの

Solanaのアーキテクチャは、相互に関連するいくつかの設計上の決定を組み合わせています。PoHは順序付けの参照を提供し、Sealevelは競合しない実行を並列化し、リーダーを認識した転送はトランザクションルーティングを変更し、パイプライニング、Cloudbreak、およびTurbineは処理、ストレージ、および伝播に対処します。記録された機能停止の履歴とバリデータのリソース要件は、パフォーマンス上の利点と同じ技術的評価の中に含まれるべきものです。

プラットフォームを選択する開発者にとって、Solanaは主要なプロダクション・ブロックチェーンの中で最高水準のベースレイヤー・スループットと、最も低い部類のトランザクション手数料を提供しています。アカウントモデルとRustの要件により、イーサリアムのEVMと比較すると設計の複雑さは増します。アカウントアクセス宣言の要件はプログラム状態の構成方法に変化をもたらし、並列実行モデルは共有状態を最小限に抑えるプログラム設計にメリットをもたらします。

研究者向けには、Anatoly Yakovenko氏によるオリジナルのホワイトペーパー「Proof of History: A Clock for Blockchain」（2017年11月）が、PoH設計の基礎となる主要な情報源であり続けています。Solana Labsは、docs.solana.comで最新のアーキテクチャ・ドキュメントを管理しています。Solana Foundationは、solana.org/validatorsでバリデーターネットワークの統計を公開しています。リアルタイムのネットワークデータはSolana Beachから入手可能です。

Solanaの8つのアーキテクチャの柱を理解することで、ネットワークのパフォーマンスに関する主張、そのトレードオフ、そして長期的な軌道を、自分自身の基準で評価するための準備が整いました。

免責事項： 本記事は情報提供および教育目的のみを目的としています。金融上の助言、投資の助言、またはSOLもしくはその他の暗号資産の売買、保有を推奨するものではありません。すべてのパフォーマンス数値は変更される可能性があります。投資判断を下す前に、資格を持つファイナンシャルアドバイザーにご相談ください。

関連トピック

• SolanaのProof of History
• Solanaのコンセンスメカニズム
• SolanaVM
• Solanaの速度