Solana エグゼクティブ概要

はじめに

Solana は、速度、効率性、ユーザー体験の重視で知られる、高性能かつ低レイテンシのブロックチェーンです。独自の統合型アーキテクチャにより、グローバルに分散化されたネットワーク全体で毎秒数千件のトランザクションを処理できます。ブロック時間は 400 ミリ秒、トランザクション手数料は 1 セント未満であり、速度とコスト効率を両立しています。本レポートでは、Solana の設計と運用を詳しく掘り下げ、その性能を支える主要な仕組みとネットワークトポロジーを解説します。

Solana は、創業チームが分散システムの構築で培った数十年の経験を活かし、ブロックチェーン開発に統合型のアプローチを採用しています。Solana の中核原則の一つは、ソフトウェアがハードウェアの妨げになってはならないというものです。つまり、ソフトウェアは実行環境のハードウェアを最大限に活用し、その性能に合わせてスケールします。統一されたエコシステムとして、この単一のブロックチェーン上に構築されたすべてのアプリケーションはコンポーザビリティを継承し、相互にシームレスに連携して機能を拡張できます。また、このアーキテクチャにより、ブリッジ、個別のチェーン ID、流動性の断片化を必要とせず、シンプルで直感的なユーザー体験を実現します。

Solana は急速に進化しており、近年では重要なスケーリングソリューションとして SVM ロールアップや ZK Compression が登場しています。これらのプロジェクトは、将来的に Solana に対する私たちの認識を形作る可能性がありますが、現時点では開発または導入のごく初期段階にあるため、本レポートでは扱いません。

トランザクションのライフサイクル

本レポートでは、典型的なトランザクションのライフサイクルを主な視点として Solana を理解していきます。Solana のトランザクションを理解するための基本モデルとして、処理の流れを次のように整理できます。 

• ユーザーがトランザクションを開始すると、すべてのトランザクションは現在の主要ブロック生成者（リーダー）へ送信されます。リーダーはこれらのトランザクションをブロックにまとめて実行し、ローカル状態を更新します。
• その後、このトランザクションのブロックはネットワーク全体に伝播され、他のバリデータが実行して確認します。‍

以降のセクションでは、このモデルを拡張して処理をさらに詳しく掘り下げます。まずは主要な参加者であるユーザーから始めます。

6 つのステージ

上の図に示した 6 ステージのビジュアルは、Solana の中核要素間の関係を一貫した枠組みで理解するのに役立つため、本レポート全体を通して参照します。

前半の各章は、この 6 つのステージに沿って構成されています。最後の章であるゴシップ、アーカイブ、経済性、Jito では、残された論点を取り上げます。一部の章は複数のステージにまたがり、一部のステージは複数の章に登場する点に注意してください。

6 ステージの枠組みには限界があるため、この重複は避けられません。実際の Solana は、相互に依存する多数の要素で構成された複雑な分散システムです。

ユーザー

ユーザーの利用は通常、ウォレットアプリケーションを設定し、資金を入れるところから始まります。Solana では、ネイティブモバイルアプリケーションやブラウザ拡張機能として、複数の人気ウォレットアプリケーションを利用できます。

ウォレットは、公開鍵と秘密鍵で構成されるユーザーのキーペアを暗号学的に生成します。公開鍵はアカウントの一意の識別子として機能し、ネットワークのすべての参加者に公開されます。Solana 上のユーザーアカウントは、Solana ブロックチェーンとのやり取りに関する情報と状態を保持するデータ構造と考えられます。この意味で、公開鍵はファイル名に似ています。ファイル名がファイルシステム内のファイルを一意に識別するのと同様に、Solana の公開鍵は Solana ブロックチェーン上のアカウントを一意に識別します。Solana の公開鍵は、32 バイトの Base58 エンコード文字列で表されます。

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

秘密鍵（シークレットキーとも呼ばれます）は、アカウントへのアクセスと変更を許可するパスワードまたはアクセスキーと考えられます。ブロックチェーンでは、秘密鍵による署名を使用して認可を処理します。秘密鍵を知っている者は、アカウントに対する完全な権限を持ちます。Solana の秘密鍵も 32 バイトです。キーペアは、公開鍵（前半）と秘密鍵（後半）を組み合わせた 64 バイトのデータです。

例：

3j15jr41S9KmdfughusutvvqBjAeEDbU5sDQp8EbwQ3Hify2pfM1hiEsuFFAVq8bwGywnZpswrbDzPENbBZbd5nj

[63,107,47,255,141,135,58,142,191,245,78,18,90,162,107,197,8,33,211,15,228,235,250,30,185,122,105,23,147,115,115,86,8,155,67,155,110,51,117,0,19,150,143,217,132,205,122,91,167,61,6,246,107,39,51,110,185,81,13,81,16,182,30,71]

秘密鍵は、通常 12 語または 24 語で構成されるニーモニックシードフレーズから導出することもできます。この形式は、バックアップと復元を容易にするため、ウォレットでよく使用されます。単一のシードフレーズから複数の鍵を決定論的に導出できます。

Solana は、公開鍵暗号の要件に広く使用されている楕円曲線デジタル署名アルゴリズム Ed25519 を採用しています。Ed25519 は、鍵と署名のサイズが小さく、計算が高速で、多くの一般的な攻撃に耐性があることから支持されています。各 Solana ウォレットアドレスは、Ed25519 楕円曲線上の点を表します。

ユーザーは秘密鍵でトランザクションに署名します。この署名はトランザクションデータに含まれ、他の参加者が送信者の公開鍵を使って検証できます。この処理により、トランザクションが改ざんされておらず、対応する秘密鍵の所有者によって承認されていることが保証されます。また、署名はトランザクションの一意の識別子としても機能します。

Solana のトランザクション‍

Solana で状態を変更する唯一の方法は、トランザクションを送信することです。すべての書き込み操作はトランザクションを通じて実行されます。また、トランザクションはアトミックであり、トランザクションが試みるすべての処理が実行されるか、トランザクション全体が失敗するかのどちらかです。より正式には「トランザクションメッセージ」と呼ばれるトランザクションは、ヘッダー、アカウントアドレスのリスト、最近のブロックハッシュ、命令の 4 セクションで構成されます。

ヘッダー

ヘッダーにはアカウントアドレスリストへの参照が含まれ、トランザクションへの署名が必要なアカウントを示します。

アカウントアドレス

このリストには、トランザクション中に読み取りまたは書き込みの対象となるすべてのアカウントが含まれます。トランザクションごとにこのようなリストを作成することは Solana 特有の要件であり、開発者にとって難しい場合があります。しかし、トランザクションがどの状態とやり取りするかを事前に把握できるため、他の多くのブロックチェーンでは不可能な最適化が可能になります。

最近のブロックハッシュ

これは、重複したトランザクションや古いトランザクションを防ぐために使用されます。最近のブロックハッシュは 150 ブロック後（約 1 分後）に期限切れになります。デフォルトでは、RPC はトランザクションがファイナライズされるか、最近のブロックハッシュが期限切れになるまで、2 秒ごとにトランザクションの転送を試みます。期限切れになると、トランザクションは破棄されます。

命令

命令はトランザクションの中核部分です。各命令は、特定の操作（例：転送、ミント、バーン、アカウント作成、アカウント閉鎖）を表します。各命令では、実行するプログラム、必要なアカウント、命令の実行に必要なデータを指定します。

トランザクション内の命令数は、まず最大 1,232 バイトというサイズによって制限されます。参照できるアカウント数にも上限があります。さらに、コンピュートユニット（CU）で測定されるトランザクションの複雑さにも上限があります。CU は、トランザクション処理で消費される計算リソースを定量化したものです。

トランザクションの実行にかかる SOL コストは、基本手数料と優先手数料の 2 つに分かれます。基本手数料はトランザクションの複雑さに関係なく、署名 1 件あたり固定で 5,000 lamport です。通常、1 件のトランザクションには 1 件の署名があります。

優先手数料は技術的には任意ですが、ブロックスペースの需要が高い時期には必要になります。この手数料は、コンピュートユニットあたりの micro-lamport（1 lamport の 100 万分の 1）で設定されます。その目的は価格シグナルとして機能し、バリデータノードがトランザクションをブロックに含める経済的な動機を高めることです。 ‍

total fee = prioritization fee + base fee

prioritization fee = compute unit price (micro-lamports) x compute unit limit

現在、トランザクション関連手数料の 50% はバーンされ、この SOL は流通から恒久的に取り除かれます。残りの 50% はブロック生成者に支払われます。間もなく新たな変更（SIMD 96）が導入され、優先手数料の 100% がブロック生成者に支払われるようになります。基本手数料に変更はありません。

トランザクションの送信

ユーザーがウォレットをアプリケーションに接続すると、アプリはユーザーの公開鍵を読み取れるようになります。秘密鍵は暗号化されたまま、アプリケーションとは別の環境で安全にサンドボックス化されます。

アプリケーションは、ユーザーの操作に基づいてトランザクションメッセージのパラメーターを作成します。たとえば、ユーザーが 2 つのトークンをスワップする場合、購入するトークンの数量、対応して売却するトークン、許容可能なトランザクションのスリッページを指定します。

トランザクションメッセージの準備が整うと、ユーザーの秘密鍵で署名するためにウォレットへ送信されます。この時点で、トランザクションを実行する意思を確認するポップアップがユーザーに表示されます。このポップアップには、トランザクション結果のシミュレーションが含まれる場合があります。署名後、トランザクションメッセージと署名がアプリに返されます。アプリは、自前またはウォレットのプロバイダーを使用して、選択した RPC プロバイダーへトランザクションを転送できます。

RPC（Remote Procedure Call）プロバイダーは、アプリケーションとブロックを構築するバリデータの仲介役を担います。これは、アプリケーションが署名済みトランザクションを送信またはシミュレーションし、オンチェーンデータを効率的に取得できるようにする不可欠なサービスです。ネットワークとやり取りするアプリケーションは、JSON-RPC または WebSocket エンドポイント（ドキュメント）を使用します。

Gulf Stream

RPC（Remote Procedure Call）は RPC ノードを指します。これらのノードは、ネットワークとやり取りしてデータを読み取るためのゲートウェイと考えられます。フルバリデータと同じソフトウェアを異なる設定で実行するため、トランザクションを正確にシミュレーションし、現在の状態を最新に保つことができます。本稿執筆時点で、Solana ネットワークには 4,000 台を超える RPC ノードがあります。

フルバリデータノードとは異なり、RPC ノードはネットワーク内にステークを保有しません。ステークがないため、投票やブロック構築はできません。この構成は、バリデータノードと RPC ノードが通常は同じである他のほとんどのブロックチェーンとは異なります。RPC ノードはステーキング報酬を受け取らないため、その運用の経済性はバリデータとは異なります。多くの RPC ノードは、Solana アプリケーションを運用する開発者向けの有料サービスとして運営されています。

Solana の際立った特徴は、当初からメンプールなしで動作するよう設計されていることです。ゴシッププロトコルを使用してトランザクションをネットワーク全体へランダムかつ広範に伝播する従来のブロックチェーンとは異なり、Solana はすべてのトランザクションを各スロットで事前に決められた主要バリデータ（リーダー）へ転送します。

RPC はブロックに含めるトランザクションメッセージを受信すると、それをリーダーへ転送する必要があります。リーダースケジュールは、各エポック（約 2 日）に先立って作成されます。次のエポックは、それぞれ 400 ミリ秒に固定されたスロットへ分割され、各スロットのリーダーが選出されます。ステークの多いバリデータほど、各エポック内でリーダーに選ばれる頻度が高くなります。各スロットでは、トランザクションメッセージがブロックを生成する機会を持つリーダーへ転送されます。バリデータに順番が回ってくると「リーダーモード」に切り替わり、トランザクションの処理とネットワークの他の部分へのブロック配信を開始します。

ステーク加重 QoS（SWQoS）

2024 年初頭、Solana はスパムの防止とシビル耐性の向上を目的とする新しい仕組み、Stake-Weighted Quality of Service（SWQoS）を導入しました。このシステムにより、リーダーはステークを持つ他のバリデータを経由したトランザクションメッセージを優先できます。ここでは、ステークが多いバリデータほど、それに比例してトランザクションメッセージのパケットをリーダーへ送信できる容量が増えます。このアプローチは、ネットワーク全体でステークを持たないノードによるシビル攻撃を効果的に軽減します。

‍このモデルでは、バリデータがステーク加重容量を RPC ノードへ貸し出す契約を結ぶこともできます。その対価として、RPC ノードは帯域幅を増やし、トランザクションがブロックに含まれる割合を高められます。特に、リーダーの容量の 80%（2,000 接続）は SWQoS 用に予約されています。残りの 20%（500 接続）は、ステークを持たないノードからのトランザクションメッセージに割り当てられます。この割り当て戦略は、ドライバーが通行料を支払って渋滞を避ける高速道路の優先レーンに似ています。

SWQoS は、リーダーへトランザクションを転送するための要件を引き上げ、スパム攻撃の有効性を低下させることで、Solana エコシステムに影響を与えました。この変更により、トラフィック量の多いアプリケーションには運用を垂直統合する動機が生まれました。独自のバリデータノードを運用するか、ステーク済み接続を利用することで、アプリケーションはリーダーへの優先アクセスを確保し、トランザクション処理能力を高められます。

QUIC に関する補足

2022 年後半、Solana はリーダーへのトランザクションメッセージ送信を管理するため、QUIC ネットワークプロトコルを採用しました。この移行は、オンチェーン NFT ミントにボットがスパムを送ったことで発生したネットワーク障害を受けたものです。QUIC は高速な非同期通信を可能にします。

‍QUIC は 2012 年に Google が開発を開始し、両者の長所を組み合わせることを目指しています。UDP のような高速な非同期通信に加え、TCP の安全なセッションと高度なフロー制御戦略も備えています。これにより、個々のトラフィック発信元に制限を設け、ネットワークが正当なトランザクションの処理に集中できるようになります。また、独立したストリームという概念もあります。そのため、1 つのトランザクションが破棄されても、残りをブロックする必要はありません。つまり QUIC は、TCP と UDP の優れた特性を組み合わせようとするものと考えられます。

ブロック構築

多くのブロックチェーンネットワークは、ブロック全体を構築してから配信します。これは離散的ブロック構築と呼ばれます。対照的に Solana は、割り当てられた時間スロット内でブロックを動的に組み立て、作成と同時にストリーミングする継続的ブロック構築を採用しており、レイテンシを大幅に削減します。

各スロットは 400 ミリ秒で、各リーダーには次のリーダーへ交代するまで 4 つの連続したスロット（1.6 秒）が割り当てられます。ブロックが受け入れられるには、その中のすべてのトランザクションが有効であり、他のノードで再現可能でなければなりません。

バリデータはリーダーになる 2 スロット前に、今後の処理負荷に備えてトランザクションの転送を停止します。この間、ネットワーク全体が次のリーダーへパケットを送るため、受信トラフィックは急増し、毎秒 1 ギガバイトを超えます。

受信したトランザクションメッセージは、ブロック生成を担うバリデータの中核ロジックである Transaction Processing Unit（TPU）へ入ります。ここでは、まず Fetch Stage で QUIC を通じてトランザクションを受信し、トランザクション処理シーケンスが始まります。その後、トランザクションは SigVerify Stage に進み、厳格な検証を受けます。ここでバリデータは、署名の有効性と署名数が正しいことを確認し、重複するトランザクションを除外します。

‍Banking Stage

Banking Stage は、ブロック構築ステージと説明できます。TPU で最も重要なステージであり、その名前は「bank」に由来します。bank とは、特定のブロック時点における状態です。Solana にはブロックごとに bank があり、そのブロック時点の状態へアクセスするために使用されます。十分な数のバリデータがブロックへ投票してファイナライズされると、bank のアカウント更新がディスクへ書き出され、永続化されます。チェーンの最終状態は、確認済みのすべてのトランザクションの結果です。この状態は、ブロックチェーンの履歴から常に決定論的に再作成できます。‍

トランザクションは並列処理され、競合しない 64 件のトランザクションをまとめた台帳の「エントリー」にパッケージ化されます。Solana でトランザクションを容易に並列処理できるのは、各トランザクションに読み取りと書き込みの対象となるすべてのアカウントの完全なリストを含める必要があるためです。この設計上の選択は開発者に負担を課しますが、バリデータは競合しないトランザクションだけを各エントリー内の実行対象として容易に選択できるため、競合状態を回避できます。2 つのトランザクションが同じアカウントへの書き込みを試みる場合（書き込み + 書き込み）、または一方が同じアカウントからの読み取りを、もう一方が書き込みを試みる場合（読み取り + 書き込み）、それらは競合します。そのため、競合するトランザクションは別々のエントリーへ入り、順次実行されます。一方、競合しないトランザクションは並列実行されます。

トランザクションを並列処理するスレッドは 6 本あり、そのうち 4 本が通常のトランザクションに、2 本が Solana のコンセンサスメカニズムに不可欠な投票トランザクションの処理に専用で割り当てられます。処理の並列化はすべて複数の CPU コアによって実現され、バリデータに GPU の要件はありません（ドキュメント）。‍

トランザクションがエントリーにまとめられると、Solana Virtual Machine（SVM）で実行する準備が整います。トランザクションに必要なアカウントがロックされ、トランザクションが新しいものであり、まだ処理されていないことを確認するチェックが実行されます。アカウントが読み込まれ、トランザクションロジックが実行されて、アカウントの状態が更新されます。エントリーのハッシュは記録のため Proof of History サービスへ送信されます（詳細は次のセクションで説明します）。記録処理が成功すると、すべての変更が bank にコミットされ、最初のステップで各アカウントに設定されたロックが解除されます。実行は、JIT コンパイルと eBPF プログラム用仮想マシンを扱うライブラリ rBPF の Solana フォークを使用して構築された仮想マシン、SVM が行います。Solana は、バリデータがブロック内のトランザクションをどのように並べるかを規定していない点に注意してください。この柔軟性は重要なポイントであり、本レポートの「経済性 + Jito」セクションで再び取り上げます。‍

クライアント

Solana は、単一の統合台帳を維持するために連携する、独立運用された数千のノードで構成されるネットワークです。各ノードは、「クライアント」と呼ばれる同じオープンソースソフトウェアを実行する高性能マシンです。

Solana は当初、単一のバリデータクライアントソフトウェアでローンチしました。これは Rust で記述され、当初は Solana Labs クライアント、現在は Agave クライアントと呼ばれています。それ以来、クライアントの多様性を高めることが優先課題となっており、Firedancer クライアントのローンチによって本格的に実現します。Firedancer は、元のクライアントを C プログラミング言語でゼロから全面的に書き直したものです。高頻度取引会社 Jump の経験豊富なチームによって構築されており、あらゆるブロックチェーンの中で最高性能のバリデータクライアントになることが期待されています。

Proof of History

Proof of History（PoH）はSolanaの強みの源泉であり、各バリデータ内の特殊な時計として機能し、ネットワーク全体の同期を促進します。PoHは、イベントの順序と時間の経過について信頼できる唯一の情報源を確立します。特に重要なのは、リーダースケジュールの遵守を保証することです。名称は似ていますが、Proof of HistoryはProof of Workのようなコンセンサスアルゴリズムではありません。

‍通常、ネットワークの拡大に伴ってノード間の通信オーバーヘッドが増え、調整も複雑になります。Solanaは、ノード間通信をPoHのローカル計算に置き換えることで、この問題を軽減しています。これにより、バリデータは1回の投票だけでブロックを確定できます。メッセージ内の信頼できるタイムスタンプにより、バリデータ同士が順番を飛び越え、予定より早くブロック生成を開始することを防ぎます。

PoHの基盤となるのは、ハッシュアルゴリズム、特にSHA256が持つ固有の特性です。

• 決定性： 同じ入力からは常に同じハッシュが生成されます。
• 固定サイズ： 入力サイズにかかわらず、出力ハッシュは常に256ビットです。
• 効率性： 任意の入力に対するハッシュを高速に計算できます。
• 原像計算困難性：ハッシュ出力から元の入力を特定することは、計算量の観点から現実的ではありません。
• アバランシェ効果： 入力のわずかな変更（1ビットだけでも）によりハッシュが大きく変化します。この特性をアバランシェ効果と呼びます。
• 衝突耐性：同じハッシュ出力を生成する異なる2つの入力を見つけることは現実的ではありません。

各バリデータクライアントでは、専用の「Proof of Historyサービス」がSHA256ハッシュアルゴリズムを継続的に実行し、ハッシュチェーンを作成します。各ハッシュへの入力は、直前のハッシュの出力です。ハッシュ計算は順番に行う必要があり、将来のハッシュ結果を事前に知ることはできないため、このチェーンは検証可能遅延関数と同じように機能します。PoHサービスが1,000個のハッシュからなるチェーンを作成した場合、各ハッシュを順番に計算するだけの時間が経過したことが分かります。これは「小規模なProof of Work」と考えられます。一方、各ハッシュの入力と出力はネットワークにブロードキャストされるため、他のバリデータは1,000個のハッシュの正しさを並列に、生成時よりもはるかに高速に検証できます。したがって、PoHは生成が難しく、検証は容易です。

CPUが異なっても、SHA-256の計算性能の幅は驚くほど狭く、最速クラスのマシン間でも差はわずかです。Bitcoinがこの関数に依存していることもあり、その最適化には多大な時間と労力が費やされてきましたが、一般的な性能上限にはすでに到達しています。

‍リーダーのスロット中、PoHサービスはバンキングステージから新たに処理されたエントリを受け取ります。現在のPoHハッシュと、エントリ内の全トランザクションのハッシュを組み合わせ、次のPoHハッシュを生成します。これはエントリをハッシュチェーンに挿入するタイムスタンプとして機能し、トランザクションが処理された順序を証明します。このプロセスは時間の経過を確認するだけでなく、トランザクションの暗号学的な記録としても機能します。

1つのブロックには800,000個のハッシュがあります。PoHストリームには「tick」も含まれます。これはリーダーの稼働状態と、1秒未満の短い時間の経過を示す空のエントリです。tickは6.25ミリ秒ごとに発生するため、1ブロックあたり64 tick、合計ブロック時間は400ミリ秒になります。

PoHクロックはノード間の同期プロセスで重要な役割を果たすため、バリデータはリーダーでないときも継続的に動作させます。

アカウントモデル

Solanaバリデータでは、グローバル状態はAccountsDBと呼ばれるアカウントデータベースで管理されます。このデータベースは、すべてのアカウントをメモリとディスクの両方に保存します。アカウントインデックスの主要なデータ構造はハッシュマップであるため、AccountsDBは実質的に巨大なキーバリューストアです。ここでは、キーがアカウントアドレス、値がアカウントデータです。

Solanaアカウントの数は時間とともに急増し、数億件に達しています。これほど多い理由の1つは、Solana開発者がよく言うように、「Solana上ではすべてがアカウントだから」です。

Solanaアカウント

アカウントは、コンピューター上のファイルのようにデータを永続的に保持するコンテナです。アカウントにはさまざまな形式があります。

• ユーザーアカウント：秘密鍵を持つアカウントで、通常はウォレットソフトウェアがユーザー用に生成します。
• データアカウント：ユーザーが保有する特定トークンの数量など、状態情報を保存するアカウントです。
• プログラムアカウント：実行可能なバイトコードを含む大規模なアカウントで、Windowsの.exeファイルやMacの.appファイルに相当します。
• ネイティブプログラムアカウント：ネットワークの各種コア機能を実行する、事前デプロイ済みの特別なプログラムアカウントです。例として、Vote ProgramやBPF Loaderがあります。

すべてのアカウントには、次のフィールドがあります。

プログラム‍

Solanaのプログラムアカウントには、実行可能なロジックのみが含まれます。つまり、プログラムを実行すると他のアカウントの状態は変更されますが、プログラム自体は変更されません。このコードと状態の分離がSolanaを他のブロックチェーンと差別化し、多くの最適化を支えています。開発者は主に、安全性とパフォーマンスを重視する汎用プログラミング言語のRustで、これらのプログラムを記述します。また、アプリケーションのフロントエンド作成やネットワークとのプログラムによる連携を容易にするため、TypeScriptとPythonの複数のSDKも利用できます。

一般的な機能の多くは、ネイティブプログラムによって標準で提供されます。たとえばSolanaでは、トークンを作成するために開発者がコードをデプロイする必要はありません。代わりに、事前デプロイ済みのネイティブプログラムへ命令を送信します。そのプログラムがトークンのメタデータを保存するアカウントを設定し、実質的に新しいトークンを作成します。

Rent

Rentは、ユーザーにアカウントの閉鎖を促し、状態の肥大化を抑えるための仕組みです。新しいアカウントを作成するには、「rent-exempt」額と呼ばれる最低残高のSOLをアカウントに保持する必要があります。これは、バリデータのメモリ内でアカウントを維持するためのストレージコストと考えられます。アカウントデータのサイズが増えると、Rentの最低残高要件も比例して増加します。アカウントが不要になった場合は閉鎖でき、Rentはアカウント所有者に返還されます。 

たとえば、ユーザーが米ドル建てステーブルコインを保有している場合、その状態はトークンアカウントに保存されます。現在、トークンアカウントのrent-exempt額は0.002 SOLです。ユーザーがステーブルコインの全残高を友人に送金した場合、トークンアカウントを閉鎖し、0.002 SOLを取り戻せます。多くの場合、プログラムがユーザーに代わってアカウントの閉鎖を自動的に処理します。ユーザーが古い未使用アカウントを整理し、そこに保存されている少額のSOLを回収できるアプリケーションも複数あります。

所有権

アカウントデータは誰でも読み取れますが、Solanaの所有権モデルは、アカウントデータを変更（書き込み）できる主体を厳密に制限することでセキュリティを強化します。この概念は、Solanaブロックチェーン上でルールと権限を適用するうえで不可欠です。すべてのアカウントには「所有者」であるプログラムがあります。アカウントの所有者はそのアカウントを管理し、承認されたプログラムだけがアカウントデータを変更できるようにします。このルールの重要な例外は、lamport（SOLの最小単位）の送金です。所有権にかかわらず、アカウントのlamport残高は誰でも増やせます。

状態の保存

Solanaプログラムは読み取り専用の実行可能ファイルであるため、「Program Derived Addresses」（PDA）を使用して状態を保存する必要があります。PDAは、特定のユーザーではなくプログラムに関連付けられ、そのプログラムが所有する特殊なアカウントです。通常のSolanaユーザーアドレスはEd25519鍵ペアの公開鍵から導出されますが、PDAには秘密鍵がありません。代わりに、その公開鍵は、多くの場合キーワードや他のアカウントアドレスである複数のパラメータと、所有プログラムのプログラムID（アドレス）を組み合わせて導出されます。

PDAアドレスは「off-curve」に存在します。つまり、通常のアドレスのようにEd25519曲線上にはありません。PDAを所有するプログラムだけが、そのPDAの署名をプログラムによって生成できるため、PDAの状態を変更できるのもそのプログラムだけです。

Turbine

バンキングステージでは、トランザクションがエントリに整理され、タイムスタンプを付けるためにProof of Historyストリームへ送信されます。ブロックのbankが更新され、エントリは次のフェーズであるTurbineに進む準備が整います。

Turbineは、リーダーがネットワークの残りの部分へブロックを伝播するプロセスです。BitTorrentから着想を得ており、高速かつ効率的に動作し、通信オーバーヘッドとリーダーが送信する必要のあるデータ量を最小限に抑えるよう設計されています。

‍Turbineでは、「shredding」と呼ばれるプロセスを通じてトランザクションデータを「shred」に分割し、これを実現します。shredは最大1280バイトの小さなデータパケットで、動画ストリームの個々のフレームに似ています。これらのshredを再構成することで、バリデータはブロック全体をリプレイできます。shredはUDPを使用してバリデータ間でインターネット経由で送信され、パケット損失や悪意あるパケット破棄に対処するために消失訂正符号を利用します。消失訂正符号は、多項式に基づくエラー検出・訂正方式で、データの完全性を保証します。一部のshredが失われても、ブロックを再構成できます。

shredは、前方誤り訂正（FEC）バッチと呼ばれる単位にまとめられます。デフォルトでは、これらのバッチは64個のshred（32個のデータshredと32個のリカバリshred）で構成されます。データ復元はFECバッチ単位で行われるため、バッチ内のパケットの最大半数が失われたり破損したりしても、すべてのデータを復元できます。64個のshredからなる各バッチはマークル化され、そのルートにはリーダーが署名し、前のバッチへ連結されます。マークルルートのチェーンによって真正性と完全性を検証できるため、このプロセスにより、shredを保有するネットワーク内のどのノードからでも安全に取得できます。

リーダーはまず単一のルートノードへブロードキャストし、そのノードがshredを他のすべてのバリデータノードへ配布します。このルートノードはshredごとに変わります。バリデータは複数の層に整理され、「Turbine Tree」を形成します。ステーク量が多いバリデータは通常ツリーの上部に配置され、ステーク量が少ないバリデータは下部に配置されます。

‍通常、ツリーはアクティブなバリデータ数に応じて2～3ホップにわたります。視覚的に分かりやすくするため、上図ではファンアウトを3として描いていますが、現在のSolanaの実際のファンアウト値は200です。セキュリティ上の理由から、shredの新しいバッチごとにツリーの順序が入れ替わります。

このようなシステムの主な目的は、リーダーとルートノードにかかる送信データのエグレス負荷を軽減することです。送信と再送信の仕組みを利用することで、負荷をリーダーと再送信ノードに分散し、単一ノードへの負担を抑えます。

コンセンサス

バリデータはTurbineを介してリーダーから新しいブロックを受け取ると、各エントリ内のすべてのトランザクションを検証する必要があります。これには、ブロック全体のリプレイ、PoHハッシュの並列検証、PoHが定めた順序でのトランザクションの再現、ローカルbankの更新が含まれます。 

‍このプロセスはTransaction Validation Unit（TVU）が処理します。TVUはリーダーのTransaction Processing Unit（TPU）に相当し、shredの処理とブロック検証を担う中核ロジックです。TPUと同様に、TVUのフローは複数のステージに分かれています。最初のShred Fetch Stageでは、Turbine経由でshredを受信します。続くShred Verify Leader Signature Stageでは、shredに対して複数の健全性チェックを行います。なかでも重要なのがリーダー署名の検証で、受信したshredがリーダーから送られたことを確認します。 ‍

Retransmit Stageでは、バリデータがTurbineツリー内の位置に基づいて、適切な下流バリデータへshredを転送します。Replay Stageでは、ローカル版のbankを更新しながら、各トランザクションを正確かつ正しい順序で再現します。

Replay StageはTPUのバンキングステージに相当します。最も重要なステージであり、より直接的にはブロック検証ステージと表現できます。Replayはシングルスレッドのプロセスループで、投票、PoHクロックのリセット、bankの切り替えなど、多くの主要処理を統括します。 

コンセンサス

コンセンサスを実現するため、SolanaはTower BFT（TBFT）を使用します。これは、チェーンの状態について合意するために多くのブロックチェーンで広く使用されているPractical Byzantine Fault Tolerance（PBFT）アルゴリズムを独自に実装したものです。すべてのブロックチェーンと同様に、Solanaもネットワーク内に悪意のあるノードが存在すると想定しているため、システムはノード障害だけでなく、一定水準の攻撃にも耐える必要があります。

Tower BFTは、Proof of Historyが提供する同期クロックを活用する点で他のチェーンと異なります。従来のPBFTではトランザクションの順序について合意するために複数回の通信が必要ですが、Solanaノードは事前に確立されたイベント順序を利用することで、メッセージングのオーバーヘッドを大幅に削減します。

投票

‍コンセンサスに参加して報酬を得るため、バリデータは有効であり、正規のブロックと見なすべきだと判断したブロックに投票します。有効とは、二重支払い、不正な署名などの問題がないことを意味します。バリデータはこれらの投票にトランザクション手数料を支払い、投票はリーダーによって処理され、通常のユーザートランザクションとともにブロックへ含められます。このため、Solanaのトランザクションは投票トランザクションと非投票トランザクションに分類されることがよくあります。バリデータは正しく有効な投票を送信すると、クレジットを獲得します。この仕組みにより、採用される可能性が最も高いと考えるフォーク、つまり「最も重い」フォークへの投票が促されます。

フォーク

Solanaが高速である理由の一端は、ネットワークが新しく生成されたブロックについて全バリデータの合意を待たずに、次のブロックを生成する設計にあります。その結果、異なる2つのブロックが同じ親ブロックに接続され、フォークが生じることも珍しくありません。

Solanaバリデータはこれらのフォークに投票し、コンセンサスアルゴリズムを使用して採用するフォークを決定する必要があります。競合するフォークが存在する場合、最終的にネットワークが確定するのは1つのフォークだけであり、破棄されたフォーク内のブロックは放棄されます。

各スロットにはリーダーが事前に指定され、そのリーダーのブロックだけが受け入れられます。単一スロットに2つのブロックを提案することはできません。したがって、発生し得るフォークの数は、リーダー交代スロットの境界で生じる「存在する／存在しない」というスキップリスト型のフォークに限られます。バリデータはフォークを選択すると、ロックアウト時間が満了するまでそのフォークにコミットします。つまり、最低期間はその選択を維持する必要があります。

‍Solanaの「スキップ率」、つまりブロックが生成されなかったスロットの割合は2%～10%で、こうしたスキップスロットの主な原因はフォークです。ほかにも、新しいエポックの開始、リーダーのオフライン、不正なブロックの生成などによってスロットがスキップされる場合があります。

覚えておきましょう：

Solana上のトランザクションステータスは、コンセンサスプロセスの現在の段階に応じて変わります。

• Processed：トランザクションがブロックに含まれています。
• Confirmed：トランザクションを含むブロックが、3分の2の圧倒的多数による投票を獲得しています。
• Finalized：トランザクションを含むブロックの上に、31を超えるブロックが構築されています。

現在まで、Solanaの歴史上、（楽観的に）ConfirmedとなったブロックがFinalizedにならなかった例は一度もありません。‍

Solanaはブロックごとにbankを使用し、そのブロック時点の状態へアクセスします。bankが確定すると、そのbankと祖先からのアカウント更新がディスクへフラッシュされます。また、確定したbankの祖先ではない過去のbankからのアカウント更新は削除されます。このプロセスにより、Solanaは複数の潜在的な状態を効率的に維持できます。

Gossipとアーカイブ

Gossip

Gossipネットワークは、Solanaネットワークのコントロールプレーンと考えられます。トランザクションフローを処理するデータプレーンとは異なり、コントロールプレーンは連絡先情報、台帳の高さ、投票情報など、ブロックチェーンの状態に関する重要なメタデータを配布します。Gossipがなければ、バリデータとRPCは各種サービス間の通信に使用できるアドレスやポートを把握できません。新しいノードも、ネットワークへの参加にGossipを利用します。

SolanaのGossipプロトコルは、修正されたPlumTreeアルゴリズムに着想を得たツリー型ブロードキャスト方式で、非公式なピアツーピア通信を行います。この方式は、中央の情報源に依存せずに情報を効率よく伝播します。

Gossipは、他のほとんどのバリデータコンポーネントから独立したシステムとして動作します。バリデータとRPCは、Gossipを介してUDP上で0.1秒ごとに署名済みデータオブジェクトを共有し、ネットワーク全体で情報を利用できるようにします。すべてのGossipメッセージは、最大伝送単位（MTU）である1280バイト以下でなければなりません。これはコードベースで「packet struct」と呼ばれています。

Gossipレコードは、ノード間で共有される実際のデータオブジェクトです。約10種類のレコードがあり、それぞれ異なる目的を果たします。Gossipレコードには署名、バージョン、タイムスタンプが付与され、完全性と最新性が保証されます。

Gossipメッセージには4つの種類があります。‍

1. Push：最も一般的なメッセージで、「push peer」のサブセットと情報を共有します。
2. PullとPull Response：見逃したメッセージを定期的に確認し、Pull Responseによってノードが保持していない情報を返します。
3. Prune：ノードが維持する接続数を選択的に減らせます。
4. PingとPong：ノードのヘルスチェックです。Pingを送信するとPongの応答が期待され、ピアノードが稼働中であることを示します。

GossipデータはCluster Replicated Data Store（CrdsTable）に保存されます。このデータ構造は非常に大きくなる可能性があるため、定期的に枝刈りする必要があります。

アーカイブ

Solanaは、アカウントの現在の状態を判断するために履歴全体を必要としない点で、他のブロックチェーンと一線を画します。Solanaのアカウントモデルでは、任意のスロットにおける状態が既知となるため、バリデータは過去の全ブロックを処理せずに各アカウントの現在の状態を保存できます。RPCとバリデータは設計上、過去の台帳全体を保持しません。代わりに通常は、チェーン先端を検証するのに十分な1～2エポック分（2～4日）のトランザクションデータだけを保存します。

現在、アーカイブは「ウェアハウスノード」によって管理されています。これらはプロのRPCサービスプロバイダー、Solana Foundation、およびトランザクション履歴の可用性確保に関心を持つその他のエコシステム参加者が運用しています。ウェアハウスノードは通常、次の一方または両方を維持します。

1. 台帳アーカイブ：最初からリプレイするのに適した生の台帳とAccountsDBスナップショットをアップロードします。
2. Google Bigtableインスタンス：ジェネシスブロック以降のブロックデータを、RPCリクエストに応答できる形式で保存します。

経済性とJito

Solanaは、エポックごとに新しいSOLトークンを生成し、インフレーションによってステーキング報酬を分配します。このプロセスでは、ステーキングしていない参加者のネットワークにおける持分がステーカーに比べて減少するため、ステーキングしていない参加者からステーカーへの富の移転が起こります。インフレーションは2021年初頭に初期レート8%で始まり、長期レートの1.5%で安定するまで毎年15%ずつ低下します。

‍SOLトークンの保有者は、1つ以上のバリデータにトークンをステーキングすることで、報酬を獲得し、ネットワークの安全性向上に貢献できます。バリデータにトークンを割り当てることをデリゲートと呼びます。バリデータへのデリゲートは、そのバリデータへの信頼を示します。ただし、バリデータにトークンの所有権や管理権を与えるものではありません。ステーキング、ステーキング解除、デリゲートのすべての操作は、次の新しいエポックの開始時に実行されます。

投票報酬

‍バリデータが投票を送信し、その投票が正確かつ有効であれば、クレジットを獲得します。投票トランザクションのコストは0.000005 SOLで、優先手数料は免除されます。投票費用はバリデータ1台あたり1日約1 SOLであり、バリデータ運用の主なコストです。バリデータはエポックを通じて投票からクレジットを蓄積し、エポック終了時にインフレーションの一部と交換できます。

最高水準のバリデータは、約90%のスロットで投票に成功します。ブロックがないスロットの割合（スキップスロット率）は2%から10%超の範囲であり、これらのスロットには投票できない点に注意してください。平均的なバリデータは約80%のスロットで投票に成功し、432,000スロットのエポックで345,600クレジットを獲得します。

インフレーション報酬の総額は、まずエポックで獲得したクレジットに基づいて分配されます。全クレジットに占めるバリデータの割合、つまりそのバリデータのクレジットを全バリデータのクレジット合計で割った値によって、比例配分される報酬が決まります。さらに、ステークによる重み付けが行われます。

したがって、総ステークの1%を持つバリデータは、平均的なクレジット数であれば、インフレーション総額の約1%を獲得します。クレジット数が平均を上回るか下回る場合、報酬もそれに応じて変動します。‍

投票パフォーマンスの違いは、バリデータがステーカーに提供するリターン（APYで測定）が異なる理由の1つです。もう1つの要因はバリデータが設定するコミッション率で、これはそのバリデータに割り当てられたインフレーション報酬総額に対する割合です。また、バリデータがオフラインになる、またはブロックチェーンとの同期が外れる状態（delinquency）も、リターンに大きく影響します。

ブロック報酬

特定ブロックのリーダーに指定されたバリデータは、追加のブロック報酬を受け取ります。この報酬は、ブロック内の全トランザクションの基本手数料の50%と優先手数料の50%で構成され、残りの手数料はバーンされます。この報酬を受け取るのは、ブロックを生成したバリデータだけです。エポック単位で分配されるステーキング報酬とは異なり、ブロック報酬はブロック生成時にバリデータのidentity accountへ即座に入金されます。

リキッドステーキング

リキッドステーキングは、ネイティブステーキングに代わる人気の選択肢となっています。参加者はSOLをステーキングする見返りとして、Liquid Staking Token（LST）またはLiquid Staking Derivative（LSD）と呼ばれるトークンを受け取ります。通常は、複数のバリデータにトークンをデリゲートするステークプールを使用します。新たに受け取るLSTトークンは、ステーキングされたSOLに対するユーザーの持分を表します。これらのトークンはステーキング報酬を獲得し続けながら、取引、アプリケーションでの利用、他者への送付が可能です。このシステムの主な利点は、資本効率を大幅に高められることです。

Price of LST = (total staked SOL in pool * price of SOL) / total LST minted

従来のネイティブステーキングでは、ステーカーが時間の経過とともにSOLを直接蓄積します。一方、リキッドステーキングでは、報酬がプールへ再投資され、LSTの公正価値が上昇します。LSTをその裏付けとなるステーキング済みSOLと交換する仕組みがある限り、アービトラージトレーダーによってトークン価格の妥当性が保たれます。

Jito

執筆時点では、Solana上のステークの80%以上（出典）がJitoクライアントのバリデータソフトウェアを使用しています。元のAgaveクライアントからフォークしたこのクライアントは、プロトコル外のブロックスペースオークションを導入し、チップを通じてバリデータに追加の経済的インセンティブを提供します。この追加インセンティブが、バリデータの間でJitoクライアントが広く採用されている主な要因です。

リーダーがJitoバリデータクライアントを使用する場合、そのトランザクションは最初にJito-Relayerへ送られます。このオープンソースソフトウェアは、トランザクションのプロキシルーターとして機能します。ネットワーク内の他のノードはJito-Relayerの存在を認識しません。リーダーがGossipネットワークを介してingress_socketとして通知したアドレスとポートの設定をリーダー自身のものと想定し、単にそこへトランザクションを送信するためです。

‍リレイヤーはすべてのトランザクションを200ミリ秒保持してからリーダーへ転送します。この「減速帯」の仕組みにより、受信トランザクションメッセージを遅延させ、オークションを実施するための短い時間を確保します。200ミリ秒後、リレイヤーはオークション結果にかかわらず、楽観的にトランザクションを解放します。

ブロックスペースオークションはJito Block Engineを介してオフチェーンで行われ、サーチャーやアプリケーションはbundleと呼ばれる、アトミックに実行されるトランザクショングループを送信できます。これらのbundleには通常、アービトラージや清算など、時間に敏感なトランザクションが含まれます。Jitoはすべてのチップに5%の手数料を課し、最低チップ額は10,000 lamportです。チップはプロトコル内の優先手数料や基本手数料とは別に、完全にプロトコル外で機能します。以前、Jitoは正規のプロトコル外mempoolサービスを運用していましたが、現在は廃止されています。