Zenn
🔆

Solana - How it works (by Helius) 日本語訳

に公開
ブロックチェーン
Solana
tech

まえがき

本ドキュメントは、Solana のコアプロトコルについて、誰にでも手が届くような分かりやすさと十分な技術的深さを兼ね備えた包括的な概観を提供することを目的としています。つまり、この業界の広範な知識を前提とせずに読み進められる一方で、Solana プロトコルの複雑さに正面から向き合う資料を目指しています──「言うは易く行うは難し」ですが！

このレポートが、暗号資産業界と密接に関わる決済／金融／Eコマースといった分野の多くの専門家にとって、Solana への理解を深める貴重な参考資料となることを願っています。Solana は確かに従来のブロックチェーンと比べて複雑ですが、決して理解不能な存在ではないことを、このレポートを通じてお伝えできれば幸いです。

本レポートの初期バージョンを読んで貴重なフィードバックをくださった 0xIchigo, dubbelosix, Jacob Creech, Maël Bomane, Nagaprasad Vr, Rex St. John 各氏に心より感謝いたします。

また、SolDic で注釈を加えてくれた Jack Sturt 氏、そしてこのプロジェクトを形にするにあたり、多大な支援と助言をいただいた Jeff（@japarjam）氏と Mert 氏にも深く感謝いたします。

Lostin
Solana 愛好家
テクニカルライター (Helius)
X, Webサイト

イントロダクション

“私たちは「より小さく、より速く、より安く、より優れたもの」を世界中の誰よりも理解していて、今、その考え方をブロックチェーンに応用しています。”
— Greg Fitzgerald (Solana 共同創業者)

Solana は、そのスピード、効率性、ユーザーエクスペリエンスへのフォーカスで有名な、高性能で低レイテンシーのブロックチェーンです。独自の統合アーキテクチャにより、世界中に分散したネットワーク上で毎秒数千件のトランザクションを処理できます。ブロック生成時間は 400 ミリ秒、手数料は 1 セント未満であり、速度とコストの両面で優れたパフォーマンスを提供します。本レポートでは、Solana の設計と動作の詳細を掘り下げ、その性能を支える主要なメカニズムとネットワークトポロジーを解説していきます。

Solana は、創業チームの数十年にわたる分散システム構築の経験を活かし、ブロックチェーン開発に統合的なアプローチをとっています。Solana の中核原則のひとつは「ソフトウェアがハードウェアの足かせになってはならない」というものです。これは、ソフトウェアが実行するハードウェアが何であれ、それを最大限に活用し、それに合わせてスケールすることを意味します。また、Solana は単一チェーン型のブロックチェーンであり、すべての処理が同じ場所で行われます。そのため、この基盤上に構築されるすべてのアプリケーションは高いコンポーザビリティ（相互運用性）を自然と継承し、互いに連携・拡張しやすくなっています。このアーキテクチャによって、ブリッジの利用やチェーン ID の切替、流動性の分断といった煩雑さが不要になり、ユーザーにとって直感的でシンプルな体験が実現されています。

Solana は急速に進化しており、最近では SVM ロールアップや ZK Compression といった重要なスケーリング手法も登場しています。これらのプロジェクトは将来的に Solana のイメージを大きく変える可能性がありますが、現時点では開発や採用がまだ初期段階にあるため、本レポートでは扱いません。

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

本レポートでは、Solana を理解するための主要な視点として、一般的なトランザクションのライフサイクルを追っていきます。Solana におけるトランザクションの最も基本的な流れは次の通りです：

  • ユーザーがトランザクションを発行すると、それらは現在のブロック生成担当ノード（リーダー）に送信されます。リーダーは受け取ったトランザクションをブロックにまとめて実行し、ブロックチェーン上の状態を更新します。
  • 生成されたブロックはネットワーク全体に伝播され、他のバリデータたちがそれを検証して確定します。

本レポートの今後の章では、この基本モデルをさらに詳細に掘り下げ、まずはこのプロセスに関わる主要なプレイヤー、すなわち「ユーザー」から解説を始めていきます。

Solana のコアプロトコルに対する重要な変更は、Solana Improvement Document (SIMD) と呼ばれる正式かつ透明性のある提案プロセスを経て進められます。SIMD は、コミュニティメンバーやコアエンジニアによって公開の場で議論された後、ネットワーク上で投票によって採択の可否が決定される仕組みになっています。

6つのステージ

本レポートでは、冒頭で示した6つのステージからなる図解を随所で参照していきます。これは、Solana の主要な構成要素同士の関係を一貫した枠組みの中で理解するための手がかりを提供してくれます。

レポートの前半では、この6ステージに沿って章立てを行っています。一方、後半の章（「ゴシップとアーカイブ」および「エコノミクス」）では、それ以前の章で扱いきれなかった要素を補足的にまとめています。ただし注意点として、いくつかの章は複数のステージにまたがる内容を扱っており、また同じステージが複数の章に登場することもあります。

これは6ステージという枠組みに一定の限界があるためで、避けられない重複です。実際のところ、Solana は多数の構成要素が相互に依存する極めて複雑な分散システムであるため、このような重複は仕方ありません。

ユーザー

“Solana は暗号資産の Apple になる可能性を秘めている。”
— Raj Gokal (Solana 共同創業者)

ユーザーの旅路は通常、ウォレットアプリケーションのセットアップと資金の入金から始まります。Solana には、モバイル向けのネイティブアプリやブラウザ拡張機能として利用できる、複数の人気ウォレットが存在します。

ウォレットは暗号技術を用いて、公開鍵と秘密鍵からなるキーペアを生成します。このうち公開鍵は、ユーザーのアカウントを一意に識別するための ID として機能し、ネットワーク上のすべての参加者に知られる存在です。Solana におけるユーザーアカウントは、ブロックチェーン上でのやり取りに関する情報や状態を保持するデータ構造と捉えることができます。この意味で、公開鍵は「ファイル名」に似ています。つまり、ファイルシステムにおいてファイル名が特定のファイルを識別するように、Solana の公開鍵は特定のアカウントを一意に識別します。Solana の公開鍵は 32 バイトの Base58 エンコード文字列として表現されます。たとえば、次のような形式です：

FDKJvWcJNe6wecbgDYDFPCfgs14aJnVsUfWQRYWLn4Tn

秘密鍵 (private key) は、シークレットキー (secret key) とも呼ばれ、アカウントへのアクセスや操作を許可するためのパスワードまたはアクセスキーのような役割を果たします。ブロックチェーンにおける認証は、この秘密鍵による署名によって行われます。秘密鍵を知っているということは、そのアカウントに対して完全な操作権限を持っていることを意味します。Solana における秘密鍵の長さは 32 バイトです。そして、公開鍵と秘密鍵を合わせたものがキーペア（keypair）で、こちらは 64 バイトからなります。前半 32 バイトが公開鍵、後半 32 バイトが秘密鍵です。

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語で構成されており、ウォレットのバックアップや復元を容易にするために広く使われています。1つのシードフレーズから、複数のキーペアを決定論的に生成することが可能です。

Solana は、広く使われている Ed25519 と呼ばれる楕円曲線デジタル署名アルゴリズムを、公開鍵暗号の基盤として採用しています。Ed25519 は、鍵サイズや署名サイズが小さく、計算が高速であり、また多くの一般的な攻撃に対する耐性が高いことから、非常に優れた方式とされています。Solana における各ウォレットアドレスは、この Ed25519 楕円曲線上の一点として表現されます。

ユーザーは、自分の秘密鍵でトランザクションに署名します。この署名はトランザクションデータと一緒に送信され、他のネットワーク参加者は送信者の公開鍵を使って署名の正当性を検証することができます。このプロセスは、トランザクションが改竄されておらず、対応する秘密鍵の所有者によって承認されていることを保証します。署名はまた、トランザクションの一意な識別子としても機能します。

Solana のトランザクション

Solana において、ブロックチェーン上の状態を変更する唯一の手段はトランザクションを送信することです。すべての書き込み操作は必ずトランザクションを通じて行われ、さらにトランザクションは アトミック（不可分）です。つまり、トランザクションが実行しようとする処理はすべて成功するか、まったく行われないかのいずれかです。トランザクションは、より正式にはトランザクションメッセージと呼ばれ、ヘッダー（Header）、アカウントアドレス一覧（Account Addresses）、直近のブロックハッシュ（Recent Blockhash）、命令（Instructions）といった4つのセクションで構成されています。

アカウントアドレス一覧:
このリストには、そのトランザクション中に読み取りまたは書き込みが発生するすべてのアカウントが含まれます。このようなリストをすべてのトランザクションごとに事前に構築することが求められるのは、Solana 特有の仕様であり、開発者にとっては手間のかかる作業になりがちです。しかしながら、この仕様のおかげで、トランザクションが事前にどの状態（アカウント）にアクセスするかが明確になるため、他の多くのブロックチェーンでは実現が難しいような高度な最適化を可能にしています。

ヘッダー:
ヘッダーには、先に挙げたアカウントアドレス一覧への参照情報が含まれており、どのアカウントがこのトランザクションに署名しなければならないかを明示します。

直近のブロックハッシュ:
これは、重複トランザクションや古くなったトランザクションの実行を防ぐために使用されます。ブロックハッシュには有効期限があり、おおよそ 151 ブロック（約 1 分間）で失効します。通常、RPC サーバーはトランザクションが確定するか、ブロックハッシュの有効期限が切れるまで 2 秒ごとに再送を試み、有効期限が切れた時点で、無効と見なされ、トランザクションは破棄されます。

命令:
命令はトランザクションの中核部分であり、実際に「何をするのか」を定義します。各命令は具体的な操作（例えば送金、ミント、バーン、アカウント作成、アカウント閉鎖など）を表します。そして各命令は実行対象のプログラム、必要なアカウント、命令を実行するのに必要なデータ（引数）を含んでいます。

トランザクションに含められる命令の数にはいくつかの制限があります。まず第一に、トランザクション全体のサイズに制限があり、最大 1,232 バイトまでと定められています。また、参照可能なアカウント数にも上限があります。さらに、トランザクションには計算単位 (Compute Units; 以下では CU と呼びます) による複雑性の上限も存在します。CU はトランザクションの処理に必要な計算資源の量を数値化したものです。

SOL の最小単位は「lamport」と呼ばれ、1 SOLの 10 億分の 1 に相当します。これは、Bitcoin における「satoshi（サトシ）」のようなものです。「lamport」という名称は、分散システムの理論的基盤を築いた計算機科学者／数学者の Leslie Lamport (レスリー・ラムポート) にちなんでいます。

SOL でトランザクションを実行する際のコストは、基本手数料 (base fee) と優先手数料 (prioritization fee) の2つに分かれています。基本手数料は、取引の複雑さに関係なく、署名 1 件につき 5000 lamports に固定されており、多くの場合はトランザションに含まれる署名は一つです。

優先手数料は、技術的に言えば任意ですが、ブロックスペースへの需要が高まった際には、事実上必須となる場合があります。この手数料は、1 CU あたりの micro-lamport（lamport の 100 万分の 1）単位で設定されます。その目的は、バリデータノードにとって経済的に魅力のあるトランザクションとして処理の優先度を示す価格シグナルとして機能させることです。

手数料の計算式は次のとおりです：

総手数料 = 優先手数料 + 基本手数料

優先手数料 = CU単価 [micro-lamport] × 使用上限CU数

現在、すべてのトランザクション関連手数料の 50% はバーンされ、それは永久に流通から取り除かれます。残りの 50% は、ブロックを生成したブロックプロデューサー（リーダー）に分配されます。今後導入予定の SIMD 96 という変更では、優先手数料の 100% がブロックプロデューサーに分配されるようになりますが、基本手数料の取り扱いには変更ありません。

ユーザーがアプリケーションにウォレットを接続すると、アプリはユーザーの公開鍵を読み取ることが可能になります。一方で、秘密鍵は暗号化された状態で安全に保護されており、アプリケーションとは分離された環境（サンドボックス）内に保持されます。

アプリケーションはユーザーのやり取りに基づいてトランザクションメッセージのパラメータを構築します。たとえば、ユーザーが2つのトークンをスワップしたい場合には、購入したいトークンの数量、売却対象となるトークン、許容可能なスリッページといった情報が指定されます。

トランザクションメッセージが準備されると、ユーザーの秘密鍵で署名するためにウォレットへ送られます。この時点で、取引の意思を確認するためのポップアップがユーザーに提示されます。このポップアップには、トランザクションの結果をシミュレートした内容が含まれていることもあります。ユーザーが署名を完了すると、署名済みのトランザクションメッセージと署名データがアプリケーションに返され、アプリケーションはそのトランザクションを自分の選択した RPC プロバイダーに送信します。

RPC (Remote Procedure Call) プロバイダは、アプリケーションとブロックを生成するバリデータとの間を仲介する存在です。RPC は、アプリケーションが署名済みトランザクションを送信したり、シミュレーションを実行したり、オンチェーンデータを効率的に取得したりするために不可欠なサービスで、ネットワークとやり取りをしたいアプリケーションは、JSON-RPC や WebSocket エンドポイントを介して処理を行います。

Solana における失敗したトランザクション（failed transaction）という用語は誤解を招きやすく、実際に多くの混乱を生んできました。これらのトランザクションは、ランタイムによって正常に実行され、署名者の意図通りに処理されていますが、トランザクション内部のロジックにより終了時にエラーコードが返されたときに「失敗」とみなされます。実際、いわゆる「失敗トランザクション」の 80% 以上はエラーコード 0x1771 (許容スリッページの超過) によるものであり（データはこちら）、これは価格の変動幅が許容値を超えたことによる中止を意味します。注目すべきは、これらのトランザクションの 95% が、全アクティブアドレスのわずか 0.1% から送信されているという点です。つまり、そのほとんどは、一瞬の価格差を狙ったアービトラージ（裁定取引）を行う自動化ボットによるものです。

Gulf Stream

“Solana の目標は、世界中のニュースが伝わるのと同じ速さでトランザクションを処理することだ。つまり、光ファイバーを通じて光が伝わる速度と同じくらいの速さだよ。私たちが競争している相手は、NASDAQ やニューヨーク証券取引所なんだ。”
— Anatoly Yakovenko (Solana 共同創業者)

Solana の文脈では RPC (Remote Procedure Call) という用語は、RPC ノードを指します。これらのノードは、ネットワークと対話したりデータを読み取ったりするためのゲートウェイのような存在です。RPC ノードは、フルバリデータと同じソフトウェアを実行していますが、設定が異なっており、トランザクションの正確なシミュレーションや最新のネットワーク状態の保持に特化しています。本記事の執筆時点で、Solana ネットワーク上では 4,000 以上の RPC ノードが稼働しています。

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

Solana が際立っている点は、最初から mempool なしで運用できるように設計されていることです。ゴシッププロトコルを使ってトランザクションをネットワーク全体にランダムに広く伝播させる従来のブロックチェーンとは異なり、Solana はすべてのトランザクションをスロットごとにリーダーと呼ばれる所定のリードバリデータに転送することになっています。

Solana では現在、Localnet / Testnet / Devnet / Mainnet-Beta という4つのクラスターが運営されています。一般的に「Solana」または「Solana ネットワーク」と言えば、ほとんどの場合は Mainnet-Beta を指しています。この Mainnet-Beta は、唯一トークンに実際の経済的価値がある本番環境であり、他のクラスター (Localnet / Testnet / Devnet）はすべて、開発やテスト専用の環境として使われています。

訳註： Localnet はユーザーのサーバーや PC において単独で動作する開発用ローカル環境なので、「ネットワーク」と呼ぶのはやや語弊があるかもしれません。

RPC がブロックに含めるべきトランザクションメッセージを受け取ると、それをリーダーに転送しなければいけません。Solana では、エポック（約2日）ごとに「リーダースケジュール」が生成されます。エポックは 400 ミリ秒ごとのスロットに分割され、それぞれのスロットに対してリーダーが選ばれます。より多くのステークを持つバリデータほど、リーダーに選ばれる確率が高くなります。各スロットの間、トランザクションメッセージはそのスロットのリーダーに転送され、リーダーはブロックを生成する機会を得ます。バリデータがリーダーを担当する出番になると、「リーダーモード」に切り替わり、トランザクションを処理してネットワーク全体にブロックをブロードキャストします。

Stake-Weighted Quality of Service - SWQoS

2024年初頭、Solana はスパムを防止し、Sybil 攻撃への耐性強化を目的とした「Stake-Weighted Quality of Service（SWQoS）」と呼ばれる新たな仕組みを導入しました。この仕組みにより、リーダーが受け取るトランザクションメッセージに優先順位を付けることが可能になりました。ここでは、ステーク量の多いバリデータほど、リーダーにトランザクションメッセージを送信できる容量が比例して大きくなります。この設計によって、ネットワーク全体において、ステークを持たないノードからの Sybil 攻撃を効果的に抑制することが可能になりました。

このモデルでは、バリデータが自分のステークに応じた通信キャパシティを RPC ノードへリースする契約を結ぶこともできます。RPC ノードはその対価として帯域を拡張でき、ブロックへのトランザクション取り込み率を向上させられます。注目すべきは、リーダーのキャパシティの 80％（2,000 接続分）が SWQoS 用に予約されている点です。残りの 20％（500 接続分）はステークを持たないノードからのトランザクションメッセージに割り当てられます。このような割り当て戦略は、高速道路の優先レーンにたとえることができます。ドライバーが通行料を支払うことで、混雑を避けてスムーズに通行できるのと同じように、ステークを通じてトランザクション送信の優先度を得ることができるということです。

SWQoS は、トランザクションをリーダーに転送する要件を引き上げ、スパム攻撃の有効性を低下させることで、Solana エコシステムに影響を与えました。この変更は、大量のトランザクションを処理するアプリケーションに対して、垂直統合（vertical integration）を促すインセンティブとなりました。自らバリデータノードを運用するか、ステークされた接続の利用権を確保することで、アプリケーションはリーダーへの優先的なアクセスを実現し、自らのトランザクション処理能力を強化することが可能になったのです。

QUIC について

2022 年末、Solana は QUIC ネットワーキングプロトコルを導入し、トランザクションメッセージをリーダーへ送信する際の通信手段として採用しました。この移行は、オンチェーン NFT ミントをスパムするボットによってネットワークが混乱したことに起因します。QUIC は迅速な非同期通信を容易にします。

2012 年にグーグルによって開発された QUIC は、TCP と UDP 両者の長所を提供します。QUIC は、UDP のような高速で非同期な通信を可能にしつつ、TCP が持つセキュアなセッション管理や高度なフロー制御機能も備えています。これにより、特定の送信元からの過剰なトラフィックを制限し、ネットワークは通常のトランザクション処理に集中することができます。また、QUIC はストリームを個別に扱う設計になっており、仮に1つのトランザクションが失敗しても、他のトランザクションに影響を与えることなく処理を継続します。要するに、QUIC は TCP と UDP の最良の特性を組み合わせようとしていると考えることができるのです。

ステークによる重み付け（stake-weighting）は、投票報酬、Turbine ツリー、リーダースケジュール、Gulf Stream、ゴシップネットワークなど、Solana のコアシステム全体に繰り返し出現する原則です。より多くのステークを持つバリデータは、ネットワーク内でより高い信頼を与えられ、優先的な役割を担うことになります。

ブロック生成

“SVM（Solana Virtual Machine）は、現時点で最も優れた仮想マシン技術だと私たちは考えています.”
— Andre Cronje (Fantom 財団)

多くのブロックチェーンネットワークでは、ブロック全体を構築してからブロードキャストする方式が採用されており、これは「離散的ブロック構築（discrete block building）」と呼ばれます。これに対して Solana は「連続的ブロック構築 (continuous block building)」を採用しており、割り当てられたタイムスロットの中でブロックを動的に組み立てつつ、同時にストリーミング配信します。この手法により、レイテンシー（遅延）が大幅に削減されます。

各スロットの長さは 400 ミリ秒で、各リーダーには連続して 4 スロット（合計 1.6 秒）が割り当てられ、その後、次のリーダーへと交代します。ブロックがネットワークに受け入れられるためには、その中のすべてのトランザクションが有効であり、他のノードによって再現可能である必要があります。

リーダーを担当する 2 スロット前になると、バリデータはトランザクションの転送を停止し、直後に始まる負荷の高い処理に備えます。この準備期間中、ネットワーク全体から新たなリーダーに向けてパケットが集中するため、受信トラフィックが急増し、毎秒 1 ギガバイトを超えることもあります。

トランザクションメッセージが到着すると、それらはトランザクション処理ユニット (Transaction Processing Unit; 通常 TPU と呼ばれます) に送られます。TPU は、ブロック生成を担うバリデータの中核的な処理ロジックです。ここでトランザクション処理の流れが始まります。最初は Fetch ステージで、トランザクションが QUIC 経由で受信されます。続いて SigVerify ステージに進み、厳格な検証処理が行われます。このステージでは、バリデータが署名の有効性を確認し、署名の数が正しいかを検査し、重複トランザクションを排除します。

Banking ステージ

Banking ステージは、ブロック構築のステージと表現することができます。これは TPU の中でも最も重要なステージです。「バンク（bank）」という名前は、特定のブロック時点における状態（state）を表すものです。Solana では、ブロックごとに対応するバンクが存在し、そのブロック時点の状態へのアクセスに使われます。あるブロックに対して十分な数のバリデータが投票し、ファイナライズ（確定）されると、そのバンクに記録されたアカウントの更新情報がディスクに書き込まれ、永続化されます。チェーンの最終的な状態は、すべての確定済みトランザクションの結果であり、この状態はブロックチェーンの履歴から決定論的に再現可能です。

トランザクションは並列に処理され、「エントリー（entry）」と呼ばれる単位にまとめられます。各エントリーは、競合しないトランザクションを最大64件まで含むバッチです。Solana で並列トランザクション処理が可能なのは、各トランザクションにおいて、読み書きするすべてのアカウントを明示的にリスト化しなければならない設計によるものです。この設計は開発者にとっては負担になりますが、バリデータ側では競合のないトランザクションを簡単に識別可能なため、競合条件（同時アクセスによる不整合）を避けて効率的に処理することができるのです。トランザクションが競合するのは、両方が同じアカウントに書き込もうとする場合、または一方があるアカウントから読み込もうとし、もう一方が同じアカウントに書き込もうとする場合です。競合するトランザクションは別々のエントリーに分けられて順次（逐次）実行される一方で、競合しないトランザクションは同一エントリー内で並列実行されます。

トランザクションの並列処理には 6 つのスレッドが使われており、そのうち 4 つは通常のトランザクションを、2 つは Solana のコンセンサスメカニズムに不可欠な投票トランザクション専用です。これらの並列処理は、すべて複数の CPU コアを利用して実現されています。バリデータには GPU は必要ありません。

トランザクションがエントリーにまとめられると、それらは Solana Virtual Machine（SVM）によって実行される準備が整います。まず、トランザクションで使用されるアカウントがロックされ、そのトランザクションが最近のものであり、すでに実行されていないかどうかの確認が行われます。次にアカウントのデータが読み込まれ、トランザクションのロジックが実行され、アカウントの状態が更新されます。エントリーのハッシュは、Proof of History（PoH）サービスに送信され、記録されます（詳細は次のセクションで説明されます）。この記録が成功すれば、すべての変更がバンクに反映され、さきほどロックしたアカウントのロックは解除されます。この実行処理は、SVM によって行われます。SVM は、Solana 独自にフォークされた rBPF ライブラリを用いて構築された仮想マシンで、JIT（Just-In-Time）コンパイルや eBPF プログラム向けの仮想マシン機能を持っています。なお、Solana では、ブロック内でトランザクションをどのような順序で並べるかについて、バリデータに対して特定のルールは課されていません。この柔軟性は、後述の「エコノミクス」の章で重要なポイントとして取り上げられます。

SVM という用語は、「Solana Virtual Machine」を指す場合と 「Sealevel Virtual Machine」を指す場合があり、ときに曖昧です。「Sealevel」は Solana のランタイム環境の正式名称なので、どちらの用語も同じ概念を表しています。SVM という用語は、明確に定義しようという最近の動きにも関わらず、広く曖昧に使われ続けています。

クライアント

Solana は、数千の独立して運用されるノードが協調して、単一の統一された台帳（ledger）を維持しているネットワークです。各ノードは、クライアントと呼ばれる同一のインテリジェントなオープンソースソフトウェアを実行する高性能なマシンで構成されています。

当初は Solana Labs クライアント、現在は Agave クライアントとして知られている Rust で書かれた単一のバリデータクライアントソフトウェアから Solana はスタートしました。それ以来、クライアントの多様性を拡大することが重要な目標とされており、それが Firedancer クライアントの登場により本格的に実現されつつあります。Firedancer は、C 言語で書かれたオリジナルの完全なクライアントの書き直しです。高頻度取引（HFT）企業 Jump に所属する経験豊富なチームによって開発されており、あらゆるブロックチェーンにおいて最も高性能なバリデータクライアントとなることが期待されています。

Proof of History

“コーヒーを2杯とビールを1本飲んで、朝の4時まで起きていたんだ。そのときにひらめいたんだよ。Proof of Work に似た仕組みを、同じ SHA-256 のプレイメージ耐性ハッシュ関数を使って作れないかって……。そのとき、“時間の矢”を手に入れたって確信したんだ。”
— Anatoly Yakovenko (Solana 共同創業者)

Proof of History（PoH）は、Solana の“秘伝のソース”とも言える仕組みであり、各バリデータに搭載された特殊な「時計」のように機能し、ネットワーク全体の同期を可能にします。PoH は、イベントの順序や時間の経過に対して信頼できる基準（source of truth）を提供するものであり、特に重要なのは、リーダースケジュールを正確に守ることを保証する役割を担っている点です。名前こそ似ていますが、Proof of History は、Proof of Work のようなコンセンサス・アルゴリズムではありません。

ネットワークが拡大するにつれて、ノード間の通信負荷が増加し、同期や調整はますます複雑になります。Solana はこの問題に対して、ノード間通信の代わりに「PoH によるローカル計算」を採用することで解決しています。これにより、バリデータは1回の投票だけでブロックにコミットできるようになります。トランザクションメッセージに含まれる信頼できるタイムスタンプによって、バリデータは規定より早くブロックを開始できないよう制限され、一定時間待機したうえでブロックを提出することが義務付けられています。PoHの根底には、ハッシュアルゴリズム、特に SHA256 のユニークな特性があります：
・決定論的（Deterministic）：同じ入力は常に同じハッシュを出力する
・固定長（Fixed Size）：入力のサイズに関わらず、出力は常に 256ビット
・効率性（Efficient）：任意の入力に対して高速にハッシュを計算できる
・プレイメージ耐性（Preimage Resistance）：出力から元の入力を逆算するのは実質不可能
・アバランチ効果（Avalanche Effect）：入力を 1 ビットでも変えると、出力は大きく変化する
・衝突耐性（Collision Resistance）：同じ出力を生成する異なる2つの入力を見つけることは非常に困難

各バリデータクライアント内では、専用の「Proof of History サービス」が常時稼働しており、SHA256 ハッシュアルゴリズムを連続して実行し、ハッシュのチェーンを生成しています。ここで、各ハッシュの入力は、ひとつ前のハッシュの出力となっています。このチェーンは、順番にしか計算できず、未来のハッシュを事前に知ることができないという性質から、検証可能な遅延関数 (verifiable delay function) のように機能します。たとえば、PoH サービスが 1,000 個のハッシュを連続して生成した場合、それらを逐次的に計算するには時間がかかるため、確かに時間が経過したという証明になるわけです。これは「マイクロ版 Proof of Work」とも言える仕組みです。一方で、他のバリデータは、その 1,000 個のハッシュの入力と出力がすでにネットワーク上に共有されているため、それらを並列に検証することが可能です。このため、PoH は「作るのは難しいが、検証するのは簡単」という特性を持っています。

SHA-256 の計算性能に関しては、CPU ごとの差が意外なほど小さく、特に高速なマシン同士では性能の違いはごくわずかです。この関数は、ビットコインで長年にわたり利用されてきたこともあり、すでに最適化のために多大な時間と労力が注がれてきました。その結果として、一般的な性能上限にほぼ到達しており、これ以上の劇的な高速化は難しいとされています。

リーダーのスロット中、PoH サービスは Banking ステージで処理された新しいエントリーを受け取ります。そして、現在の PoH ハッシュと、エントリー内のすべてのトランザクションのハッシュを組み合わせて、次の PoH ハッシュが生成されます。これにより、そのエントリーがハッシュチェーン内に時系列的に挿入され、トランザクションがどの順番で処理されたかを証明するタイムスタンプの役割を果たします。この処理は、時間の経過を示すだけでなく、トランザクションの暗号学的な記録としても機能します。1ブロックあたり、およそ80万個のハッシュが生成されます。さらに PoH ストリームには 「ティック（tick）」 と呼ばれる空のエントリーも含まれており、リーダーが正常に稼働していることやごくわずかな時間の経過を示しています。ティックは 6.25 ミリ秒ごとに発生するので、1 ブロックあたり 64 ティックとなり、ブロック時間は 400 ミリ秒となります。

なお、バリデータはリーダーでないときでも常に PoH の時計（PoH サービス）を動かしており、ノード間の同期において極めて重要な役割を担っています。

PoH（Proof of History）の最大の利点は、たとえブロック生成者（リーダー）がオフライン、つまり delinquent と呼ばれる状態になっていたとしても、正しいリーダースケジュールが必ず守られるようにすることです。PoH は、悪意のあるバリデータが自分の番が回ってくる前にブロックを生成することを防ぎます。

アカウントモデル

“SVMでコードとステートを分離したのは、最高の設計判断だった。このコンセプトを私の脳みそに叩き込んでくれた組み込みシステム開発者に感謝したい。”
— Anatoly Yakovenko (Solana 共同創業者)

Solana のバリデータ内部では、グローバルな状態は AccountsDB と呼ばれるアカウントデータベースで管理されています。このデータベースは、すべてのアカウント情報をメモリ上およびディスク上に保存する役割を担っています。アカウントインデックスの主要なデータ構造は ハッシュマップであり、AccountsDB は実質的に巨大なキー・バリュー型ストアといえます。キーはアカウントアドレス、バリューはそのアカウントに紐づくデータです。時間の経過とともに、Solana のアカウント数は数億に急増していて、この数の多さは、Solanaの開発者がしばしば好んで言うように、"Solana 上のすべてがアカウントである"ことも一つの要因です。

Solana のアカウント

アカウントは、コンピューター上のファイルのように、データを持続的に保持するコンテナであり、以下のような様々な形態で利用されます：

  • ユーザーアカウント： プライベートキーを持ち、一般的にはウォレットソフトによってユーザーのために生成されます。
  • データアカウント：ユーザーが保有する特定のトークンの数など、状態情報（state）を保持するアカウントです。
  • プログラムアカウント：実行可能なバイトコードを含む大型のアカウントであり、Windows でいう .exe ファイル、Mac でいう .app ファイルのような役割を果たします。
  • ネイティブプログラムアカウント：ネットワークのコア機能を担うあらかじめデプロイされた特別なプログラムアカウントです。Vote プログラムや BPF Loader プログラムがその一例です。

すべてのアカウントは、以下のフィールドを持っています：

フィールド 形式 説明
Owner 公開鍵アドレス アカウントの所有者。デフォルトでは System Program。
Lamports u64 アカウントが保持する SOL の量（単位は lamports)。
Data 可変長バイト列 ファイルのデータに相当する最も重要なフィールド。
Rent Epoch u64 互換性のためのレガシーフィールド。Rent は後述。
Executable boolean アカウントが実行可能プログラムを保持していれば true。

プログラムアカウント

Solana のプログラムアカウントには、実行可能なロジック（コード）だけが格納されています。つまり、プログラムが実行される際には、他のアカウントの状態を変更しますが、プログラムアカウント自身の状態は変化しません。このコードと状態の分離が、Solana を他のブロックチェーンから差別化し、その最適化の多くを可能にしています。

開発者は、安全性とパフォーマンスへの強いフォーカスで知られる汎用プログラミング言語である Rust でこれらのプログラムを書くのが一般的です。さらに、アプリケーションのフロントエンド開発やネットワークとのプログラム的な連携を容易にするため、TypeScript や Python 向けの複数の SDK も提供されています。

多くの一般的な機能は、あらかじめ用意されたネイティブプログラムによって標準で提供されています。たとえば、Solana ではトークンを作成するために開発者がコードをデプロイする必要はありません。代わりに、事前にデプロイされているネイティブプログラムのインストラクション（命令）を実行することで、トークンのメタデータを保持するアカウントが自動的にセットアップされ、新しいトークンが作成されます。

Rent

Rent（レント）は、不要なアカウントを削除し、ネットワーク上の状態の肥大化を抑制するためのインセンティブ設計です。新たにアカウントを作成する際には、「Rent-Exempt Amount（レント免除額）」と呼ばれる一定量の SOL を、そのアカウントに保持しておく必要があります。これは、アカウントがバリデータのメモリ上で生き続けるための保管コストのようなものです。アカウントに保持するデータ量が増えると、それに比例して必要な額も増加します。一方で、そのアカウントが不要になった場合は、アカウントを閉じることで、Rent として保持されていた SOL がアカウント所有者に返還されます。

例として、ユーザーがドル建てのステーブルコインを持っている場合、その状態はトークンアカウントに保存されます。トークンアカウントに必要なレント免除額は現在 0.002 SOL です。もしユーザーがこのステーブルコインをすべて他人に送った場合、トークンアカウントを閉じて 0.002 SOL を回収することができます。このようなアカウントのクローズ処理は、多くの場合プログラム側で自動的に行われ、さらに、未使用アカウントの整理や SOL の回収を手助けしてくれるアプリケーションも複数存在します。

所有権

アカウントデータの読み取りは普遍的に許可されていますが、変更（書き込み）に関しては厳格な制限が設けられています。この所有権モデルは、Solana 上でのルールやアクセス権限を正しく機能させるために不可欠な仕組みです。すべてのアカウントには、「オーナー」となるプログラムが紐づけられており、そのプログラムだけがアカウントの内容を変更する権限を持ちます。これにより、許可されたプログラムのみがデータを操作できるようになり、高いセキュリティが保たれています。lamport（SOLの最小単位）の移動はこのルールの特筆すべき例外であり、アカウントの lamport 残高を増やすことは、所有権に関係なく普遍的に許可されています。

状態ストレージ

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

PDA アドレスは「オフカーブ」、つまり通常のアドレスのように Ed25519 カーブ上に存在しません。PDA を所有するプログラムだけが署名を生成することができ、PDA の状態を変更できる唯一の存在であることを保証します。

上記の Solana におけるトークンアカウントは、Program Derived Address（PDA）の具体的な例です。これらはトークンの保管用に使われており、すべて「オフカーブ」のアドレスとして存在しています。Associated Token Account（ATA）プログラムは、各ウォレットがトークンの種類ごとに1つの関連トークンアカウント (ATA) しか持てないことを保証し、トークンアカウントを管理する標準化された方法を提供しています。

Turbine

“Solana でいちばん面白い部分は、並列処理でもなければ SVM でも Toly のツイートでもない。おそらく聞いたこともないかもしれないが―Turbine だ。”
— Mert Mumtaz (Helius)

Banking ステージでは、トランザクションがエントリーにまとめられ、タイムスタンプを付けるために Proof of History（PoH）のストリームへ送られます。その後、ブロックのバンクが更新され、エントリーは次のフェーズ ― つまり Turbine に進む準備が整います。

Turbine とは、リーダーが自分のブロックをネットワーク全体に伝播させるプロセスのことです。これは BitTorrent から着想を得た仕組みであり、通信の負荷を軽減し、リーダーが送信すべきデータ量を最小限に抑えるように設計された、高速かつ効率的な伝播方式です。

Turbine は、「シュレッディング（shredding）」と呼ばれる処理によって、トランザクションデータを 「シュレッド（shreds）」という小さなデータパケットに分割して、この高速伝播を実現しています。シュレッドは、最大 1280 バイトの小さなデータ片で、動画ストリームにおけるフレームのようなものです。これらを再構成することで、バリデータはブロック全体を正確に再生（リプレイ）することができます。シュレッドは UDP でバリデータからバリデータへ送信されます。このとき、消失符号化 (erasure coding) と呼ばれる、多項式に基づく誤り検出・訂正の技術が使われており、通信中のパケット損失や悪意あるシュレッド破棄にも対応可能です。つまり、一部のシュレッドが欠損しても、残りのシュレッドからブロック全体を復元することができ、データの完全性を高く保つ仕組みになっているのです。

シュレッドは、FEC（Forward Error Correction）バッチと呼ばれる単位にまとめられます。デフォルトでは、これらのバッチは 64 シュレッド（32 データシュレッド＋32 リカバリーシュレッド）で構成されます。つまり、バッチ内のパケットの半分までが失われたり破損したりしても、すべてのデータを復元することができます。64 シュレッドの各バッチは Merkle ツリーに構造化され、そのルートハッシュがリーダーによって署名されます。さらに、このルートは前のバッチとチェーン状に連結されており、どのノードからシュレッドを取得しても、その信頼性と改竄がないことを検証できる状態が保たれます。

伝播の開始時、リーダーはまず 1 つのルートノードにのみシュレッドを送信し、このルートノードがさらに他のバリデータノードへと中継していきます。ルートノードは、シュレッドごとに切り替わるようになっています。バリデーターは階層構造に編成され、これを「Turbine Tree」と呼びます。より多くのステークを持つバリデーターは通常、ツリーの上部に配置され、ステークが少ないバリデーターは下部に配置されます。

このツリー構造は、通常2～3ホップの深さを持ち、アクティブなバリデータの数によって変化します。上の図では視覚的にわかりやすくするためにファンアウト（1つのノードが同時に送信する先のノード数）を 3 として描かれていますが、Solana における実際のファンアウト値は 200 に設定されています。また、セキュリティ上の理由から、このツリーのノードの順番は、シュレッドのバッチごとにローテートされる設計になっています。

このような構造を採用する主な目的は、リーダーやルートノードにかかるアウトバウンド通信の負荷を軽減することです。送信（transmit）と再送信（retransmit）の仕組みを活用することで、ネットワーク全体に負荷を分散し、特定のノードに集中して過度な負担がかからないようにしています。

コンセンサス

“Solana には、まじめで賢い開発者コミュニティがあると、何人かの賢い人たちから聞いているんだ……。そのコミュニティが正当に成長するチャンスを得られることを願っているよ。”
— Vitalik Buterin (Ethereum 共同設立者)

バリデータは、Turbine を通じてリーダーから新しいブロックを受け取ると、その中の各エントリーに含まれるすべてのトランザクションを検証しなければいけません。この作業には、ブロック全体のリプレイ、PoH ハッシュの並列検証、PoH によって規定された順序でのトランザクションの再構成、およびローカルバンクの更新が含まれます。

このプロセスは、トランザクション検証ユニット (Transaction Validation Unit; 以下 TVU と呼びます） によって処理されます。TVU は、リーダーの TPU に相当する存在であり、シュレッドの処理とブロックの検証を担う中核的なロジックです。TPU と同様に、TVU の処理フローもいくつかのステージに分かれています。最初の Shred Fetch ステージでは、Turbine を通じてシュレッドが受信されます。続く Shred Verify Leader Signature ステージでは、複数の整合性チェックが行われ、とくにリーダーの署名の検証が行われます。これにより、受け取ったシュレッドがリーダーから送信されたものであることが確認されます。

Retransmit ステージでは、バリデータは Turbine ツリーにおける自身の位置に基づいて、シュレッドを適切な下流のバリデータに転送します。そして Replay ステージでは、規定された順序でトランザクションを正確に再現し、ローカルバンクを更新します。

この Replay ステージは、TPU における Banking ステージに相当し、より直接的にはブロック検証のステージと表現できます。リプレイは単一スレッドで動作するプロセスループであり、投票処理、PoH クロックのリセット、バンクの切り替えといった数多くの重要な操作を統括しています。

Anza の Justin Starry による上図において、Replay ステージは、バリデーターをリーダーモードに切り替え、ブロック生成を開始する役割を担っています。

コンセンサス

コンセンサス（合意形成）を実現するために、Solana は Tower BFT（TBFT） を採用しています。これは、ブロックチェーンにおける状態の合意に広く用いられている Practical Byzantine Fault Tolerance（PBFT） アルゴリズムを、Solana 向けにカスタム実装したものです。すべてのブロックチェーンと同様に、Solana もネットワーク内に悪意あるノードが存在する可能性を前提として設計されており、ノードの故障だけでなく、一定の攻撃にも耐えられる仕組みが必要です。

Tower BFT の特徴は、Proof of History によって提供される同期クロックを活用している点にあります。従来の PBFT では、トランザクションの順序について合意を取るために複数ラウンドの通信が必要とされていましたが、Solana のノードはすでに確立されたイベントの順序を利用できるため、通信の負荷を大幅に削減することができます。

投票

コンセンサスに参加し報酬を得るために、バリデータは有効であると信じるブロック（つまり、二重支払いや署名ミスなどの問題がないブロック）に対して投票を行います。これらの投票にはトランザクション手数料がかかり、通常のユーザートランザクションと同様に、リーダーによって処理されブロックに含まれます。そのため、Solana のトランザクションは投票トランザクションと非投票トランザクションの二つに分類されることがあります。バリデータが正しいかつ成功した投票を送信すると、「クレジット」が付与されます。この仕組みは、バリデータが「最も採用される可能性の高いフォーク（= 最も重いフォーク）」に対して投票するインセンティブになっています。

フォーク

Solana が非常に高速である理由の一つは、新しいブロックが生成されるたびに、すべてのバリデータの合意を待つことなく、次のブロックの生成に進むという設計にあります。 このため、同じ親ブロックに対して異なる2つのブロックが接続される＝フォークが発生することは珍しくありません。

Solana のバリデータは、これらのフォークに対して投票を行い、どのフォークを採用するかをコンセンサスアルゴリズムによって決定する必要があります。複数のフォークが競合する場合でも、最終的にネットワークによって 1つのフォークのみが確定 (ファイナライズ) され、残りのフォークに含まれるブロックは破棄されます。

各スロットにはあらかじめ決められたリーダーが存在し、そのリーダーが生成するブロックのみが受け入れられます。つまり、1つのスロットに対して複数の提案ブロックは存在できません。そのため、フォークが発生しうる状況は、リーダー交代の境界においてブロックが「存在する／存在しない」のスキップリスト的な形に限定されます。一度バリデータが特定のフォークを選択すると、ロックアウト期間が終了するまでそのフォークに拘束され、一定期間はその選択を変えることができません。

Solanaの 「スキップ率」（ブロックが生成されなかったスロットの割合）は 2% から 10% で、フォークがスキップされたスロットの主な理由になっています。その他の理由としては、新しいエポックの開始、オフラインのリーダー、無効なブロックの生成などが考えられます。

Solana におけるトランザクションのステータスは、コンセンサスプロセスにおける現在の段階によって次のように分類されます：

  • Processed: トランザクションがブロックに含まれた状態です。
  • Confirmed: そのトランザクションを含むブロックに対して、3分の2以上の多数による投票が行われた状態です。
  • Finalized: そのブロックの上に 31 個以上のブロックが構築された状態です。

これまでのところ、Solana の歴史上、（楽観的に）確認済みとされたブロックが最終的に確定しなかった事例は一度もありません。

Solana では、各ブロックごとのバンクを使って、そのブロック時点の状態にアクセスします。あるバンクがファイナライズされると、そのバンクおよびその祖先にあたるバンクからのアカウント更新情報がディスクに書き込まれ、永続化されます。一方で、確定されたバンクの祖先ではない、それ以前のバンクからのアカウント更新情報は削除されます。この処理によって、Solana は（フォークによる分岐などの）複数の状態の候補を効率的に保持・管理することが可能になっています。

ゴシップとアーカイブ

“ブロックチェーンとは、暗号学、分散システム、オペレーティングシステム、プログラミング言語といった分野の巧妙な融合を必要とするものです。Solana の“スーパーパワー”とは、これらの各分野における最も興味深い問題から、叫びながら逃げ出す覚悟を持っていたことなのです。.”
— Greg Fitzgerald (Solana 共同創業者)

Solana におけるゴシップネットワークは、ネットワーク全体の制御層 (control plane) として機能します。これは、トランザクションの流れを処理するデータプレーンとは異なり、連絡先情報、元帳の高さ (ledger height)、投票情報など、ブロックチェーンの状態に関する重要なメタデータを広く伝達する役割を担っています。ゴシップがなければ、バリデータや RPC ノードは、さまざまなサービスにおいて、どのアドレスやポートが通信可能であるかを知ることができません。新しいノードがネットワークに参加する際も、ゴシップに頼ることになります。

Solana のゴシッププロトコルは独自のピア・ツー・ピア通信を用いており、修正された PlumTree アルゴリズムに着想を得たツリー型のブロードキャスト方式を採用しています。この手法により、中央のサーバーに依存せずに、ネットワーク全体に情報を効率よく伝播させることができます。

ゴシップは、Solana ネットワーク内の多くのバリデータ構成要素とは独立して動作する、やや分離されたシステムとして機能しています。バリデータと RPC ノードは、ゴシップで 0.1 秒ごとに署名済みのデータオブジェクトを UDP で交換しており、ネットワーク全体で情報が常に利用可能な状態に保たれています。すべてのゴシップメッセージは、最大伝送単位（MTU）1280 バイト以下である必要があり、コードベース上ではこの形式を「packet struct」と呼んでいます。

ゴシップレコードとは、ノード間で実際に共有されるデータオブジェクトのことです。おおよそ 10 種類のレコードが存在し、それぞれ異なる目的で使用されます。すべてのレコードには、署名・バージョン・タイムスタンプが付与されており、整合性と情報の鮮度が保証されています。

ゴシップメッセージには、以下の4種類があります：

  • Push: 最も一般的な形式で、情報を一部の「push ピア」に送信します。
  • Pull & Pull Response: 定期的に過去のメッセージの漏れを確認し、レスポンスとして欠損分の情報を返します。
  • Prune: ノードが保持する接続数を選択的に減らすことができます。
  • Ping & Pong: ノードのヘルスチェック用で、Ping を送信したら、相手から Pong が返ってくることで、相手がまだ稼働中であることを確認します。

ゴシップデータは、Cluster Replicated Data Store（CrdsTable） と呼ばれるデータ構造に保存されます。この構造は非常に大きくなる可能性があるため、定期的なプルーニングにより不要データを削除する必要があります。

アーカイブ

Solana が他の多くのブロックチェーンと異なる点の一つは、アカウントの現在の状態を把握するために、すべての履歴データを必要としないという点です。Solana のアカウントモデルでは、任意のスロットにおける状態が明示的に管理されており、バリデータは過去のすべてのブロックを処理しなくても、各アカウントの現時点の状態を把握できるようになっています。そのため、RPC やバリデータノードは設計上、チェーンの全履歴を保存する必要はありません。通常、保存されるのは 1〜2 エポック分（約2〜4日間）のトランザクションデータのみであり、それだけでも直近のチェーンの検証には十分です。

アーカイブは現在「ウェアハウスノード」によって管理されており、専門の RPC サービスプロバイダーや Solana 財団、取引履歴を確実に利用できるようにすることに関心を持つ他のエコシステム参加者によって運営されています。ウェアハウスノードは通常、以下のいずれか、もしくは両方を保持しています：

Ledger Archive: 生の台帳データと AccountsDB のスナップショットをアップロードし、最初からのリプレイを可能にします。

Google Bigtable Instance: ジェネシスブロックからのブロックデータが、RPC リクエストに適した形式で保存されています。

エコノミクス

“人々は今、Solana こそが、今日において一般消費者向けアプリケーションを本格的に支えられる唯一のブロックチェーンであるという事実に気づき始めています。”
— Ted Livingston (Code 創業者)

Solana では、インフレーションによってステーキング報酬が分配される仕組みを採用しています。エポックごとに新たな SOL トークンが発行され、ステーカーに配布されることで報酬となります。この仕組みにより、ステーキングしていないユーザーの保有比率は相対的に減少し、結果として非ステーカーからステーカーへの資産価値の移転が生じます。インフレーションは 2021 年初頭に年率 8％ から開始され、その後毎年 15％ ずつ減少していき、最終的には長期的な安定目標である年率 1.5％ に落ち着くよう設計されています。

SOL トークンを保有するすべてのユーザーは、1つまたは複数のバリデータにトークンをステーキングすることで、報酬を得ながらネットワークのセキュリティ強化に貢献することができます。このようにトークンをバリデータに割り当てる行為は、「デリゲート（委任）」と呼ばれます。トークンをバリデータにデリゲートすることは、そのバリデータに対する信頼の表明ですが、バリデータがそのトークンの所有権や操作権限を持つわけではありません。ステーキング・アンステーキング・デリゲーションなどの一連の操作は、すべて次の新しいエポックの開始時に実行されます。

投票報酬

バリデータが投票を行い、その投票が正確かつ成功した場合、バリデータにはクレジットが付与されます。投票は通常のトランザクションとして実行され、手数料は0.000005 SOLですが、優先手数料はかかりません。投票にかかる費用は 1 日あたり約 1 SOL とされており、これがバリデータ運用における主なコストの一つとなっています。エポックの期間中、バリデータは投票によってクレジットを蓄積し、エポック終了時にクレジットに応じたインフレ報酬と引き換えることが可能です。

最も優秀な部類のバリデータは、スロットの約90％に対して正しく投票しており、一方で、スロットの2％〜10％程度はスキップされてブロックが生成されないため、これらには投票できません。**一般的なバリデータの成功投票率は約80％**で、1エポック（432,000スロット）のうち 約345,600クレジットを獲得する計算になります。

インフレーション報酬の分配は、まずそのエポック内に各バリデータが獲得したクレジット数に基づいて比率配分されます。バリデータの報酬割合は、「そのバリデータのクレジット数 ÷ 全バリデータの合計クレジット数」で計算されます。この割合に対して、さらにステーク量による重み付けが行われます。

したがって、あるバリデータが全体のステークの1％を受けていて、平均的なクレジット数を獲得している場合、そのバリデータはインフレ報酬全体の約1％を受け取ることになります。もし獲得したクレジット数が平均より多かったり少なかったりすれば、その分だけ報酬も増減します。

このように、投票のパフォーマンスの違いが、バリデータがステーカーに提供できる利回り（APY）に差が出る要因のひとつです。その他にも、バリデータが設定する手数料率も報酬に影響します。これは、インフレ報酬のうち何％をバリデータ自身が受け取るかを示すもので、残りがステーカーに配分されます。さらに、バリデータが delinquency と呼ばれるオフライン状態またはブロックチェーンと同期できていない状態に陥った場合、報酬は大きく低下する可能性があります。

ブロック報酬

特定のブロックのリーダーに指定されたバリデータは、追加のブロック報酬を受け取ります。この報酬には、そのブロック内で処理されたすべてのトランザクションに対する 基本手数料の50％ と 優先手数料の50％ が含まれます。残りの 50％ はバーンされ、ネットワークから恒久的に取り除かれます。この報酬は、ブロックを実際に生成したバリデータのみに付与され、他のバリデータと共有されることはありません。また、ステーキング報酬がエポックごとに分配されるのに対し、ブロック報酬はブロックの生成と同時にバリデータのアイデンティティアカウントへ即座に付与されます。

リキッドステーキング

リキッドステーキングは、従来のネイティブステーキングに代わる選択肢として広く人気を集めています。この仕組みでは、ユーザーが SOL をステーキングすると、その見返りとして LST (Liquid Staking Token) や LSD (Liquid Staking Derivative) と呼ばれるトークンを受け取ります。多くの場合、これらの SOL は複数のバリデータに分散してデリゲートされる「ステークプール」を通じて運用されます。ユーザーが受け取る LST は、ステークされた SOL に対するユーザーの持分を表しており、他者への譲渡や売買、dApps（分散型アプリケーション）での利用も可能です。それでいて、ステーキング報酬も継続的に得ることができるのが最大の特徴です。この仕組みによって、資本効率が大幅に向上するというのが大きなメリットといえます。

LSTの価格 = （プール内の総ステークSOL × SOLの価格）÷ 発行済みLSTの総数

ネイティブステーキングでは、時間とともに直接 SOL の量が増加していくのに対し、リキッドステーキングにおいては、報酬がプール内で再投資されるため、LST の理論価格が上昇していきます。LST とステークされた SOL との交換手段が確保されている限り、アービトラージ（裁定取引）を行うトレーダーによって LST の価格は適正水準に保たれる傾向にあります。

Jito

執筆時点で、Solana 上のステークの 80％ 以上が「Jito クライアント」と呼ばれるバリデータソフトウェアを使用しています。Jito クライアントは、もともとの Agave クライアントをフォークして開発されたもので、Solana のプロトコルの枠外で行われる「ブロックスペースオークション」という仕組みを導入しており、チップ（報酬）を通じてバリデータに追加の経済的インセンティブを与えることができます。こうした仕組みが、多くのバリデータに Jito クライアントが広く採用されている理由の一つです。

リーダーとなったバリデータが Jito クライアントを使用している場合、トランザクションはまず「Jito リレイヤー」と呼ばれるオープンソースソフトウェアに送られます。これは、トランザクションのプロキシルーターとして機能します。ネットワーク上の他のノードはこの Jito リレイヤーの存在を認識しておらず、リーダーがゴシップネットワーク上で自らの受信ソケットとして表明したアドレスとポートに通常どおりトランザクションを送信すると、それが結果的に Jito リレイヤーに届く形になります。

Jito リレイヤーは、すべてのトランザクションをリーダーに転送する前に 200 ミリ秒間保持します。この「速度抑制 (speed bump)」の仕組みにより、トランザクションが届いてすぐ処理されるのではなく、オークションを行うための短い時間的猶予が設けられています。200 ミリ秒が経過すると、リレイヤーはオークション結果に関係なく、楽観的にすべてのトランザクションをリーダーに送信します。

ブロックスペースオークションは、Jito ブロックエンジンを介してオフチェーンで実行されます。このとき、検索者（searchers）やアプリケーションがバンドルと呼ばれる、アトミックに実行されるトランザクションのグループを送信することができます。これらのバンドルには、アービトラージや清算（liquidation）など、時間的制約のある重要な取引が含まれるのが一般的です。Jito はすべてのチップに対して 5％の手数料を課し、最低チップ額は 10,000 lamport です。これらのチップはプロトコルの外で運用されており、Solana のインプロトコルな優先手数料や基本手数料とは完全に別の仕組みです。以前、Jito はプロトコル外の公式 mempool サービスを運用していましたが、現在は廃止されています。

免責事項

本レポートで述べられている意見および解釈は、あくまで著者個人の見解であり、Turbin3、Helius、Solana Foundation、Solana Labs、その他いかなる団体の公式な見解を示すものではありません。本調査は、関連ドキュメントの精査、文献の分析、コードの検証、エコシステム関係者へのインタビュー、および著者自身による独自の調査に基づいて行われました。

本ドキュメントに記載されている内容は、SOL トークンの購入を推奨・勧誘するものではなく、あくまで情報提供を目的としたものであり、投資助言を構成するものではありません。

Discussion