Solana 技術調査（2026/4時点）

こんにちは。BOOSTRY ソフトウェアエンジニアの久禮です。

今回は、高スループットで知られる Solana について、設計思想、アカウントモデル、コンセンサス、トランザクション構造、SPL Token までを整理して解説します。

本記事は 2026年4月時点の公開情報をもとに作成しています。仕様や実装は将来変更される可能性があります。

1. 概要

Solana の大きな特徴は、以下の組み合わせによって高い処理性能を実現している点です。

PoH（Proof of History）による時系列の証明
Tower BFT によるコンセンサス
Turbine による高速なブロック伝播
並列トランザクション実行

その結果、決済、DeFi、NFT、ゲームなど高頻度トランザクションを要する用途との親和性が高いチェーンとして位置付けられています。

観点	Solana	XRPL	Bitcoin	Ethereum
アルゴリズム	Tower BFT	XRP Ledger Consensus Protocol	PoW	PoS
TPS（理論値）	約65,000	約1,500	約7	約15-30
確定時間	Optimistic Confirmation: 約0.4秒 / Finalized: 約12-15秒	3-5秒	約10分/ブロック（確率的確定）	約12秒/ブロック、ファイナライズ約12-15分

2. アカウントモデル

2-1. アカウント構造

Solana では状態をアカウントとして保持し、主に以下のフィールドで構成されます。

lamports: 残高（1 lamport = 0.000000001 SOL）
data: 任意のバイト列（プログラムコード、または状態データ）
owner: そのアカウントを制御するプログラム ID
executable: true ならプログラムアカウント、false ならデータアカウント
rent_epoch: レント徴収の基準となるエポック情報、現在は後方互換性のために残る legacy field

アカウントアドレスは、通常は Ed25519 の公開鍵です。加えて、Program ID と seed から決定論的に導出される PDA（Program Derived Address、詳細は後述）も利用されます。

2-2. アカウントの分類

プログラムアカウント

アカウントのexecutableフィールドがtrueであり、dataのなかにプログラムコードが入っているアカウントです。ほぼEthereumでいうコントラクトみたいなものと考えてよいでしょう。全てのプログラムアカウントにおいて、ownerはプログラムのロード・ファイナライズ・実行を担当するネイティブプログラムであるloader program です。

データアカウント

executableがfalseであり、dataにはプログラムのステートが入ります。プログラムにより作成され、そのプログラムがownerとなります。まずSystem Program（新しいアカウントを作成できる唯一のプログラム）がアカウントを作成したあとownerを指定のプログラムに移し、プログラムがdataフィールドを初期化するという作成の流れになります。

なお、owner が System Program のままのアカウントはシステムアカウントで、ウォレットもこのカテゴリに含まれます。

2-3. 代表的な組み込みプログラム

プログラム名	アドレス	役割
System Program	`11111111111111111111111111111111`	アカウント作成、SOL 転送、領域割り当て
Config Program	`Config1111111111111111111111111111111111111`	ネットワーク設定の保存
Stake Program	`Stake11111111111111111111111111111111111111`	ステーキング管理
Vote Program	`Vote111111111111111111111111111111111111111`	バリデーター投票
BPF Loader	`BPFLoader2111111111111111111111111111111111`	プログラムのデプロイ
Token Program	`TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA`	SPL Token 管理

2-4. PDA（Program Derived Address）

PDA は、秘密鍵を持たずにプログラムが権限を行使できる特別なアドレスです。

項目	通常アドレス	PDA
秘密鍵	あり	なし
生成方法	Ed25519 鍵ペア生成	seed + Program ID から決定論的に導出
署名能力	秘密鍵署名	`invoke_signed` でランタイムが検証
主な用途	ユーザーウォレット	プログラム管理アカウント
カーブ上の位置	Ed25519 カーブ上	カーブ外

例として、DEX のエスクロー、ステーキング情報、ATA（後述）などで利用されます。

Solana は Ethereum と異なり、ロジックと状態を分離する設計です。

Program: ステートレスなロジック（Ethereum の Contract Code に相当）
PDA/Data Account: 状態データ（Ethereum の Contract Storage に相当）

3. コンセンサスアルゴリズム

3-1. PoH（Proof of History）

PoH は、暗号学的に安全なハッシュ関数（SHA-256 など）を単一コアで連続的に実行し、その出力を次の入力に用いることで、時間の経過を検証可能な形で記録し、タイムスタンプを生成します。 1つ前のハッシュ値を入力として次のハッシュ値を算出するため、それらの値には前後関係が生まれ、タイムスタンプとみなせます。ハッシュ関数を用いることで決定論的に算出可能であり、かつ逆算が困難であるため、改ざん防止にもなっています。

さらに、任意データをハッシュ連鎖に混ぜ込むことで「そのデータが特定時点より前に存在していた」ことを示せます。具体的には、入力となるハッシュ値とデータを結合し、そのハッシュ値をその時点の出力として扱います。

また、生成には逐次処理が必要ですが、検証は GPU の複数コアを使って並列に実行できるため高速です。

Solana は PoH を独自の「信頼できる時計」としてブロックチェーンに組み込むことで、トランザクションやイベントの信頼性の高い順序付けを実現し、従来のブロックチェーンの課題であったスループットとレイテンシの問題を解決しています。

3-2. Tower BFT

PoH の時系列を土台に、Solana は Tower BFT で合意形成します。時間単位は slot で、ハッシュ計算約12,500回を 1 tick、64 tick を 1 slot と定義しているため、1 slot は約400msです。

各 slot ごとにバリデーターノードの中からリーダーが選出され、ブロックを生成します。トランザクションは並列に処理され、競合しない最大64件のトランザクションがエントリーとしてまとめられます。

Tower BFTの概要図
https://report.helius.dev/

リーダーからの Entry を受け取ったバリデーターは PoH と Tx を検証し、有効であると判断した場合はフォーク（分岐のこと、詳細は後述）を選んで投票します。投票後、バリデーターは一定期間ロックアウトされます。

ロックアウト

バリデーターがあるブロックに投票した場合、一定の期間そのブロックを含むフォークの子孫以外のブロックに投票できなくなります。この期間のことをロックアウトといい、初期のロックアウト期間はデフォルトで2 slotです。つまりこの期間中同じフォークに生まれたブロックにのみ投票が可能です。

あるブロックに投票後同じフォークのブロックに再度投票したときロック期間が2倍になります。

また、あるブロックについて自分のタワーに投票が32個積み重なると max lockout depth に達したとみなされ、最も古い投票が dequeue され、そのバリデーターの報酬が発生します。

フォーク選択

Solana は全バリデーターの合意を取る前にブロック生成するため、ブロックの分岐が発生し得る作りになっています。例えばあるスロットのリーダーがブロックを生成した際にネットワークの遅延などで次のスロットのリーダーがそのブロックを認識できなかったとします。そのまま自分がリーダーのスロットを開始してしまい、ブロックを生成すると分岐（= フォーク）が発生します。

分岐が発生した場合、各バリデーターはステーク重みをもとに投票先を決定します。具体的には以下の条件を満たしたとき投票します。

自身が別フォークのロックアウト中でない
一定深さで十分なステーク支持（例: 2/3）がある
フォーク切替時は追加の安全条件を満たす

3-3. コミットメント

Solana のコミットメントは、一般に次の 3 段階で表現されます。

Processed: ノードが処理済み
Confirmed: 十分な投票が集まり、巻き戻りリスクが低い（Optimistic Confirmation）
Finalized: さらに後続ブロックが積み上がり、実質的に確定

Confirmed のステータスでは 66% 以上のステークがそのブロックに投票している状況です。この場合、巻き戻りのリスクはほぼありません。また、Finalized に比べて Processed のステータスから高速で遷移します。リスクが低く、ほぼ確定状態とみなせることから optimistic confirmation と呼ばれます。

Finalized は Confirmed の条件に加えて、そのブロックの上に 31 以上のブロックが積み上がっていることが条件です。32 slot 分の時間が必要なので、およそ12-15秒ほどかかります。

3-4. Turbine

Turbine は、ブロック伝播を効率化するプロトコルです。BitTorrent に似た発想で、データを分割して木構造で配信します。

リーダーノードがブロック情報を他のバリデーターに伝播させる際、単純に送信するとバリデーターノード数に比例して通信が必要となり、帯域幅が逼迫してしまいます。

Turbine ではまずブロックを小さな Shred に分割します。各 Shred は以下から構成されます。

Data Shred: 実際のトランザクションデータ
Coding Shred: エラー訂正用の冗長データ（Reed-Solomon符号化）

Reed-Solomon 符号化では 32:32 の FEC（Forward Error Correction）比率を使用します。つまり 64 パケット中の 32 パケットが失われても復元が可能です。パケットロス率 15% の条件下において、ブロック復元の成功率は 99% となります。

パケットは Turbine Tree に基づいて伝播されていきます。 Turbine Tree ではノードが層状に分割されます。現時点の Solana の設定では、リーダーが一度にデータを送信するバリデーター数 DATA_PLANE_FANOUT が 200 に設定されており、各ノードが最大 200 の子ノードに転送します。

その他、Turbine Tree では以下のような設計上の工夫がされています。

ステークベースの優先配置
- ステークの多いバリデーターをリーダーに近い位置に配置
- ネットワークの重要なノードに優先的にデータ到達
Shred ごとの経路ランダム化
- 各 Shred で異なるツリー構造を使用
- 悪意のあるノードによる攻撃を分散
決定論的なツリー計算（中央調整不要）
- 各バリデーターが独立して同じツリーを計算
- 中央調整不要

Turbineの伝播
https://forum.solana.com/t/feature-turbine-improvements-1-14-17/200

4. トランザクション構造

4-1. 基本構造

Solana のトランザクションは以下のような構成になっています。

Transaction
├── signatures
└── message
    ├── header
    ├── account_keys
    ├── recent_blockhash
    └── instructions

signatures は Ed25519 署名配列で、先頭署名者は通常 fee payer です。

4-2. `header`

header は 3 つの u8 で権限情報を圧縮します。

フィールド	意味
`num_required_signatures`	必須署名数
`num_readonly_signed_accounts`	署名者のうち読み取り専用数
`num_readonly_unsigned_accounts`	非署名者のうち読み取り専用数

4-3. `account_keys`

account_keys は次の順序で並びます。

account_keys
├── [0..] 署名者 + 書き込み可能（先頭が fee payer）
├── [..] 署名者 + 読み取り専用
├── [..] 非署名者 + 書き込み可能
└── [..] 非署名者 + 読み取り専用

4-4. `recent_blockhash`

recent_blockhash は次の役割を持ちます。

新規性の証明
二重処理の抑止

一般に約 150 slot で期限切れとなります。

4-5. `instructions`

instructions は CompiledInstruction の配列です。

フィールド	内容
`program_id_index`	呼び出し先プログラム（`account_keys` 参照）
`accounts`	引数として渡すアカウント群（`account_keys` 参照）
`data`	命令識別子とシリアライズ済み引数

クライアントで生成された時点での instructions は以下から構成されます。

フィールド	内容
`program_id`	呼び出すプログラム ID
`accounts`	account meta データの配列。`pubkey`（アカウントの公開鍵アドレス）、`is_signer`（署名の要否）、`is_writable`（アカウントのデータ変更要否）
`data`	命令識別子とシリアライズ済み引数

クライアント側の instruction は、シリアライズ時に CompiledInstruction へ変換されます。 is_signer、is_writable は account_keys の順序と header に畳み込まれます。

4-6. Legacy と V0

Solana は Legacy と V0 の 2 形式をサポートします。バリデータはメッセージの先頭バイト（Legacy は num_required_signatures、V0 は 0x80）を検査して形式を判断します。

V0 では account_keys を static_account_keys フィールドとし、末尾に address_table_lookups フィールドが追加されます。

address_table_lookups
├── account_key
├── writable_indexes[]
└── readonly_indexes[]

Address Lookup Table（ALT）とは、最大256個の公開鍵を保存するオンチェーンアカウントです。ALT を参照することで、32 bytes の公開鍵の代わりに 1 byte のインデックスでアカウントを指定できます。トランザクション送信後、validator はすべての ALT 参照を完全な公開鍵に解決し、static_account_keys に追加して完全な account_keys を得ます。

ALT に多くのアカウントを事前登録しておくことで、複数のアカウントを 1 byte ずつ参照できるため、参照アカウント数が増えるほど byte 数の節約になります。ただし ALT で解決されたアカウントは書き込み可能または読み取り専用（非署名者）のみで、署名者にはなれないため注意が必要です。 V0 を使うべき場面は、多数のアカウントを参照し 1,232 bytes の上限に近づく場合であり、単純なトランザクションには Legacy の方がシンプルで互換性が高いとされています。

4-7. 複数署名

トランザクションの signatures は配列で、複数署名者を 1 トランザクションにまとめられます。header.num_required_signatures を満たさない場合は拒否されます。

Solana は SPL Token Program レベルでマルチシグをネイティブにサポートしています。InitializeMultisig インストラクションで初期化されるマルチシグアカウントは、m-of-n 形式の署名要件を定義します。マルチシグアカウントはトークンの Mint authority や Token account の owner に設定できます。そのため、たとえば「3人の管理者のうち2人が承認しなければトークンをミントできない」という制御が可能です。

5. SPL Token

SPL Token は Solana のトークン標準で、Ethereum の ERC-20 に相当します。現在2つのプログラムが存在します。

プログラム	特徴
Token Program（SPL Token）	標準実装。シンプルで広く利用される
Token-2022（Token Extensions）	上位互換。拡張機能をオプトイン利用可能

5-1. ERC-20 との違い

最大の違いは「残高の保持場所」です。

ERC-20（Ethereum）はコントラクト内 mapping で残高を管理します。

ERC-20 Contract
└── balances mapping
    ├── address_A -> 100
    ├── address_B -> 50
    └── address_C -> 200

SPL Token（Solana）では、トークンの属性を保持する Mint Account と、各保有者ごとの残高を保持する Token Account にデータが分けられます。各ウォレットが各トークンに対して個別の Token Account を持つ構造です。

Mint Account（トークンの定義）
├── supply（総発行量）
├── decimals
├── mint_authority
└── freeze_authority
Token Account（残高を保持するアカウント）
├── mint（どのトークンか）
├── owner（誰が所有するか）
└── amount（残高）

ERC-20との主な違い：

項目	ERC-20	SPL Token
残高の保持場所	Contract の `mapping`	個別 Token Account
残高確認	Contract 参照	Token Account 読み取り
新規受取	アドレスのみで可	Token Account（通常 ATA）作成が必要
マルチシグ	外部コントラクトで実装	Token Program にネイティブ実装
トークン定義	Contract 自体	Mint Account
拡張	コントラクト再実装	Token-2022 の拡張機能

5-2. Associated Token Account（ATA）

SPL Token ではトークンごとの Token Account が必要です。運用簡素化のため、ウォレットアドレスとトークンの Mint アドレスから決定論的に導出される Associated Token Account（ATA）が標準的に使われます。ATA は PDA の一種で、同じウォレット・同じトークンに対して常に同じアドレスが導出されます。

ATA = PDA(
  seeds = [wallet_address, token_program_id, mint_address],
  program_id = associated_token_program_id
)

5-3. Token-2022 の主な拡張

Token-2022 はオプトイン形式で以下のような拡張機能を提供しています。

Transfer Hook: トークン転送時にカスタムロジックを実行
Confidential Transfer: 残高と転送量をゼロ知識証明で秘匿化
Metadata Pointer: トークンのメタデータをオンチェーンに直接格納
Permanent Delegate: 常設の委任者を設定（コンプライアンス用途など）
Transfer Fee: 転送のたびに手数料を自動徴収

6. まとめ

本記事では以下を整理しました。

アカウントモデル（Program / Data Account / PDA）
コンセンサスの流れ（PoH / Tower BFT / Commitment）
トランザクション内部構造（Legacy / V0 / ALT）
SPL Token 設計（Mint / Token Account / ATA）

Solana は、PoH を時間基盤にしながら Tower BFT、Turbine、並列実行を組み合わせることで、低レイテンシかつ高スループットを実現しています。あらゆるシステム要素において、スループットを上げることを念頭に置いて設計されていることが見て取れます。

本記事の内容は、社内勉強会資料をもとに再整理したものです。BOOSTRY では毎週、社内で技術勉強会を開催し、ブロックチェーンをはじめとする先端技術の知見をメンバー間で共有しています。

この記事を通じて、BOOSTRY の技術への取り組みやブロックチェーン技術の可能性に、少しでも興味を持っていただければ幸いです。今後も研究開発およびプロダクト開発を通じて、より効率的で機能性の高い先進的な金融市場の実現に向けて取り組んでまいります。引き続き BOOSTRY の活動にご注目ください。

ご興味のある方は、ぜひ採用情報もご覧ください！

BOOSTRY Tech Blog

株式会社BOOSTRY の技術ブログです

Solana 技術調査（2026/4時点）

1. 概要

2. アカウントモデル

2-1. アカウント構造

2-2. アカウントの分類

プログラムアカウント

データアカウント

2-3. 代表的な組み込みプログラム

2-4. PDA（Program Derived Address）

3. コンセンサスアルゴリズム

3-1. PoH（Proof of History）

3-2. Tower BFT

ロックアウト

フォーク選択

3-3. コミットメント

3-4. Turbine

4. トランザクション構造

4-1. 基本構造

4-2. `header`

4-3. `account_keys`

4-4. `recent_blockhash`

4-5. `instructions`

4-6. Legacy と V0

4-7. 複数署名

5. SPL Token

5-1. ERC-20 との違い

5-2. Associated Token Account（ATA）

5-3. Token-2022 の主な拡張

6. まとめ

補足. 参考資料

1. 概要

2. アカウントモデル

2-1. アカウント構造

2-2. アカウントの分類

プログラムアカウント

データアカウント

2-3. 代表的な組み込みプログラム

2-4. PDA（Program Derived Address）

3. コンセンサスアルゴリズム

3-1. PoH（Proof of History）

3-2. Tower BFT

ロックアウト

フォーク選択

3-3. コミットメント

3-4. Turbine

4. トランザクション構造

4-1. 基本構造

4-2. header

4-3. account_keys

4-4. recent_blockhash

4-5. instructions

4-6. Legacy と V0

4-7. 複数署名

5. SPL Token

5-1. ERC-20 との違い

5-2. Associated Token Account（ATA）

5-3. Token-2022 の主な拡張

6. まとめ

補足. 参考資料

4-2. `header`

4-3. `account_keys`

4-4. `recent_blockhash`

4-5. `instructions`