Solanaバリデータソフトウェアの違いとは？

はじめに

Solanaのバリデータを比較するとき、「どのクライアントを使っているか」だけでは足りなくなっています。クライアントは、投票やブロック生成を担う中核のソフトウェアです。Agave、Jito-Solana、Firedancer/Frankendancerといった実装があります。

クライアントだけでなく、leader slotで取引を並べてブロックを組み、ブロック報酬（block reward）やMEVを分配する層のソフトウェアが増えています。leader slotは、そのバリデータがブロックを作る順番を指します。MEVは、取引の扱い方から生じる追加的な収益のことです。

収益とリスクの構成は、クライアント本体と、その上に積む層の両方で決まります。

クライアント本体の外側には、block building、scheduler、reward distribution、バリデータポリシーといった層があります。schedulerは、取引をブロックに並べる順番を決める仕組みです。置き換える層が違えば、増える収益源も負うリスクも変わります。

まずレイヤーを分ける

整理の出発点は、Solanaバリデータ周辺のソフトウェアを次の層に分けて見ることです。各層に出てくるbundleやTEE、MEV tipなどの用語は、以下の製品ごとの節で説明します。

• バリデータクライアント：投票とブロック生成を担う中核。例: Agave、Jito-Solana、Firedancer/Frankendancer
• block engine / block building：leader slotで取引を並べ、bundleを組む層。例: Jito Block Engine、Jito BAM、Harmonic
• scheduler / block packing：block CU（ブロックに詰め込める計算量の単位）の範囲で取引を詰める層。例: Agave内蔵scheduler、Rakurai scheduler、各builder scheduler
• reward distribution：ブロック報酬やtipを委任者へ配る層。例: protocol-level inflation reward、Jito tip distribution、Rakurai reward distribution
• バリデータポリシー：toxic MEV（利用者に不利なMEV）の扱いやbuilder依存度を決める層。例: Harmonic policy、Paladinなど

この分類をしないまま「Jito vs Firedancer」「BAM vs Harmonic」と横並びにすると、比較軸がずれます。

Firedancerはバリデータクライアントの新しい選択肢であり、BAM、Rakurai、Harmonicは、block buildingやtransaction scheduling、ブロック報酬の獲得（block reward capture）についての選択肢であることに留意しましょう。

Agave

Agaveは、Anzaが開発する標準的なSolanaバリデータクライアントです。Solana Labsが以前管理していたオリジナルのSolanaバリデータからのfork（既存コードから派生させた実装）で、Rustで書かれています。Solanaのバリデータ運用の標準実装として使われています。

Agave本体が扱うのは、インフレ報酬やpriority fee（取引を優先処理してもらうための上乗せ手数料）といったプロトコル処理です。運用面では、安定稼働、アップグレード追随、設定、監視が中心になります。

鍵の管理やrestart（再起動）の時間帯といった運用規律は、クライアントを問わず共通で、基本の記事と選び方の記事で扱います。Agave自体で見るのは、標準実装としての安定性とアップグレード追随です。

block engine、scheduler、distribution programを載せて初めて、MEV tipやblock buildingの上乗せが加わります。この上の層を扱うのが、次節以降のJito、BAM、Rakurai、Harmonicです。

Jito-SolanaとJito Block Engine

Jito-Solanaは、Jito LabがAgaveバリデータクライアントに最適化を行ったクライアントです。バリデータはJito Block Engineに接続してbundleを受け取れます。bundleは、searcher（取引機会を探して送る主体）やdApp（分散型アプリ）がまとめて送る取引の束のことです。

bundleには、採用を狙ってtip（上乗せ報酬）が付くことがあります。採用されたbundleのMEV rewardsは、バリデータと委任者へ分配される仕組みです。

Jito-Solanaを使ってもインフレ報酬の計算式は変わりません。新たに加わるのは、leader slotで受けるbundleのtipと、JitoのBlock Engine feeという項目です。

ここでのJito-Solanaはクライアントとしての比較です。MEVそのものの仕組み（bundle・Tip Distribution・sandwich対策）はMEVの記事で扱います。

Jito BAM

BAMは、ブロックの組み立てを売買する市場（Block Assembly Marketplace）の略です。構成は、次の3つの部品に分かれています。

• BAM Node：取引の順序付けを担う中央側の部品。
• BAM Client：バリデータ側に載る軽量な部品。
• BAM Validator：BAM Clientを載せ、BAM Nodeに接続するバリデータ。

BAM NodeとBAM Clientは、AgaveやJito-Solanaなど既存のバリデータの上に置き、バリデータとはgRPCやQUICといった通信方式で接続します。BAM Validatorは、BAM Nodeから取引の流れ（transaction stream）を受け取って実行し、実行結果やリーダー時の状態（leader state）を返します。

Jito-Solanaが「Jito Block Engineからbundleを受けるバリデータクライアント」だとすれば、BAMの役割は違います。BAMは、取引の並び順とexecution feedback（実行結果のフィードバック）を扱う設計です。

BAMが扱うのは、TEE（保護された実行環境）と、取引の並び順を非公開で決めるprivate transaction orderingです。さらに、処理の正しさを示すcryptographic attestationや、plugin（差し込み式の処理部品）によるtransaction logicも扱います。報酬差は、tipの額よりもpluginとfee設計の作り込みで出ます。

Rakurai

Rakuraiは、Solanaのバリデータ向けに高TPS（毎秒の取引処理数）のクライアント、scheduler、reward distributionをまとめた仕組みです。掲げる中心は、より高いブロック報酬とMEVの獲得です。あわせて、許可なく誰でも有効化できること（permissionless enablement）も特徴に挙げています。

Rakurai Activation Programは、バリデータごとにActivation Accountを作ります。このアカウントが保持するのは、schedulerの有効化状態、バリデータのcommission（手数料率）、操作権限（authority）です。Rakurai側のcommissionは将来の計画とされ、現時点の公開ドキュメントには項目がありません。

現在のブロック報酬の配分は、バリデータと委任者の二者です。バリデータが設定した割合（0〜100%）を受け取り、残りが委任者に回ります。配分はエポック（報酬集計の区切り期間）単位で、Merkle tree（多数の配分をまとめて検証する木構造）にまとめて計算する仕組みです。

現時点の公開ドキュメントではRakuraiはfeeを取らないため、委任者の受取額はバリデータの0〜100%設定しだいで大きく動きます。

Harmonic

Harmonicは、Solana向けの開かれたブロック生成基盤（open block building infrastructure）です。複数のblock buildersから候補ブロック（candidate blocks）を集め、バリデータにとって最適なブロックを選びます。

中心となる役割は、次の4つです。取引を受け付けてブロックを組む入口から、最終的にブロックを確定するまでの流れになります。

• TPU Relayer：取引を受け付けてbuilderへ渡す入口。TPU（Transaction Processing Unit＝取引の受付口）を中継します。
• Block Builders：受け取った取引から候補ブロックを組む。
• Auction Engine：候補ブロックを競わせ、最適な1つを選ぶ。
• バリデータ：選ばれたブロックを確定する。

特徴は、単一のbuilderへの依存を下げ、バリデータが自分のポリシーを持てる点です。公式ドキュメントの概要では、Jito、Temporal、Jito BAM、Paladinなどのブロックを集める例が示されています。バリデータは、収益、fair inclusion（公平な取り込み）、toxic MEV回避といった基準でブロックを選べます。

Harmonicはバリデータクライアントそのものではなく、ブロック生成の市場（block building market）を開くソフトウェアです。どのbuilderのブロックを受け入れるかは、バリデータが設定するポリシーが決めます。

FiredancerとFrankendancer

full Firedancerバリデータは2025年12月12日にSolana mainnetで稼働を開始しました。2026年7月時点では、full Firedancerが全stakeの約14%、hybrid型のFrankendancerが約26%で使われています。stake比率は動くので、最新の数字を追い続ける必要があります。

Firedancerは、Jump CryptoがC言語で書いた性能重視の新しいバリデータクライアントです。Frankendancerは、FiredancerとAgaveのコードを並行して使うhybrid型です。Agaveのnetworking stackとblock production componentsを、Firedancer側の実装で置き換える構成になります。

releaseの追随、対応cluster、Jito/BAM/FireBAM（BAMをFiredancer向けにしたもの）などblock building側との接続も、導入判断で見る対象です。

Firedancer/Frankendancerを見る理由は、処理速度だけではありません。もう一つはクライアントの多様性（client diversity）の観点です。

単一クライアントに大きく依存すると、特定の実装バグがネットワーク全体に波及しやすくなります。複数クライアントは、Solana FoundationのNetwork Health Reportでもネットワーク障害リスクを下げる要素です。

Paladin、Temporal、その他の補助線

Paladinは、Jitoバリデータのforkです。Paladinは、sandwiching（取引を前後で挟む攻撃）への対策とブロック報酬の向上を掲げています。あわせて、取引を優先的に送り込める専用の受付口（priority ports）を、transaction sender（取引の送信者）向けに用意します。

Temporalは、Harmonicの文脈で出てくるblock builder / market structure側の名前です。Harmonicの概要では、Jito、Temporal、Jito BAM、Paladinなどのブロックを集める例が示されています。

Temporal単体をバリデータクライアントと見るより、Harmonicが扱うbuilder ecosystemの一部として読む方が、誤解が少なくなります。

報酬への影響はどこに出るか

ソフトウェアを変えても、インフレ報酬の基本ルールは変わりません。ソフトウェアの選択が受取額に効くのは、次の層です（投票実績や運用品質そのものは選び方の記事で扱います）。

• leader slotの処理：block production、priority fee、MEV機会に影響
• block packing：high-fee transactions、block CU、throughputに影響
• Block Engine / BAM接続：bundle、tip、plugin fee、attestationに影響
• scheduler：取引の並び順とブロック報酬に影響
• reward distribution：委任者への配分、claim、commissionに影響
• バリデータポリシー：revenue最大化、fair inclusion、toxic MEV回避のバランスに影響

受取額をいちばん動かすのはleader slotの処理とblock packingで、見落とされやすいのは障害時の切替による報酬損失です。

ソフトウェア面でチェックするべきこと

法人が事業者を評価するとき、ソフトウェアについては次の点をチェックする必要があります。報酬の分配や運用品質でのバリデータの選び方は、選び方の記事にまとめています。

• 現在利用しているバリデータクライアント
• Agave、Jito-Solana、Firedancer/Frankendancerの採用状況
• Jito BAM、Rakurai、Harmonic、Paladinの利用有無
• block buildingやschedulerの有効化条件
• builderやscheduler停止時のfallback
• mainnet upgrade時の検証手順とrollback／クライアント切替方針

クライアント選定の前提は、数か月で変わります。full Firedancerの稼働開始が、その一例です。評価では、最新のrelease情報と現在のstake比率を事業者に確認し、次に見直す日付を決めておきます。