1本の読み取り経路を、
いまの状態と過去の履歴に分ける
Splitting one read path into current state and full history
いまのSolanaでは、1つのRPCノード(Agave)が合意形成・状態管理・台帳の保存・あなたのRPCクエリを、同じ1プロセスで抱えています。読み取りはすべてここを通り、古い履歴はBigTableなどに外付けされてきました。RPC 2.0は、その「読み取り」をバリデータから切り離し、性質の違う2つの問い ── いまの状態と、創世記からの履歴 ── に専用の経路をあてる再設計です。Solana Foundationと連携し、AGPLでオープンソース。受け持つのは Cloudbreak(いまの状態) と Superbank(全履歴) の2つ。動かしながら理解しましょう。 On Solana today, a single RPC node (Agave) handles consensus, state management, ledger storage, and your RPC queries in one process. Every read funnels through it, and old history has been bolted on via external archives like BigTable. RPC 2.0 takes reads out of the validator and gives two fundamentally different questions — current state, and history since genesis — their own purpose-built paths. In partnership with the Solana Foundation, open-sourced under AGPL. Carried by Cloudbreak (current state) and Superbank (full history). Let's learn it hands-on.
💡 AGPL とは ── 誰でも自由に使え、改変もできるオープンソースライセンス。ただし改変版を(ネット越しの)サービスとして提供するなら、その改変ソースも公開する義務があります。中身を隠した“囲い込み”を防ぎ、誰かの改善がみんなに還る ── まさに本資料の「断片化・ロックインを解く」狙いと同じ思想です。 💡 What AGPL means — a free, open-source license: anyone may use and modify it. But if you run a modified version as a network service, you must also publish your modified source. That blocks hidden "lock-in" and keeps one person's improvements flowing back to everyone — the same anti-fragmentation idea this guide is about.
なぜ必要だったのかWhy it was needed
問題は「どれか1つのクエリが遅い」ことではありません。性質の違う読み取りを、合意形成と同じ1プロセスに詰め込んだ「構造」そのものです。 The problem isn't any single slow query. It's the structure: cramming fundamentally different reads into the same process that also runs consensus.
🤔 まず予想してみよう🤔 Predict first
3ヶ月前のトランザクション履歴を引くと遅い。いちばんの原因は?Pulling 3-month-old transaction history is slow. The main reason?
答え: B。 データ量は確かに大きいですが、本当のボトルネックは保管と取り出し方です。古い履歴はノードの手元になく BigTableへネットワーク往復になり、さらに住所の履歴取得は「署名一覧 → 1件ずつ取得」の N+1 で往復が積み重なります。つまり量ではなく構造の問題 — だから量を減らすのではなく、保管そのものを設計し直します(→ 02)。 Answer: B. The volume is large, but the real bottleneck is how data is stored and fetched. Old history isn't local — it becomes a network round trip to BigTable — and address history piles up N+1 round trips ("list signatures, then fetch one by one"). It's the structure, not the size — so the fix is to redesign storage itself, not shrink the data (→ 02).
モノリスが抱える痛みは、大きく3つ。順番に図解します。 The monolith's pain comes in three forms. Let's diagram each.
01遅さ — 読み取りが合意形成と資源を奪い合うSlow — reads fight consensus for the same resources
1つのAgaveノードが合意形成・アカウント更新・台帳書き込み・全JSON-RPCを同時にこなし、メモリ・I/O・CPUを共有します。DEXが重いクエリを投げると、合意処理やストリーム配信と資源を取り合う。さらに古い履歴は手元になく、BigTableへネットワーク往復が発生します。A single Agave node runs consensus, account updates, ledger writes, and every JSON-RPC call at once, sharing memory, I/O, and CPU. A heavy query competes with consensus and streaming. Worse, old history isn't local — it becomes a network round trip to BigTable.
看板の「38倍」は公開RPC比(1,885ms基準)、アカウント側の「20倍超」は平均値基準(jsonParsed 6,276→314ms)です。一方Triton自身の別記事ではgetSignatureStatusesのBigTable比較が188msと10倍も低く出ています。倍率は「どの遅い相手と、どの統計で比べるか」で大きく変わり、すべてTriton自社・軽負荷の測定。独立した第三者ベンチは見当たりません。速くなったのは確かですが、倍率の数字は控えめに受け取るのが安全です。 The headline "38×" uses a public-RPC baseline (1,885ms); the accounts "20×+" uses an average (jsonParsed 6,276→314ms). Yet Triton's own other post lists the BigTable getSignatureStatuses at 188ms — 10× lower. The multiplier swings with which slow baseline and which statistic you pick, and all of it is Triton's own, light-load measurement. No independent third-party benchmark exists. Faster — yes; but treat the exact multipliers with caution.
02コスト — 読み取りなのにバリデータ級ハードを要求Cost — validator-class hardware just to serve reads
読み取りを速く保つにはノードを増やすしかなく、各ノードはRAM 768GB級・高速NVMeを要求(カスタム索引用の専用ノードは月$3,000超)。しかも二重の痛みがあり、新しいRPCノードがネットワークに加わるほどTurbineが配るデータ量が増え、伝播がみんなにとって遅くなる。本来、読み取りにそんな重装備は要らないのに、です。Keeping reads fast means adding nodes — each demanding 768 GB RAM and fast NVMe (a dedicated index node runs $3,000+/mo). And there's a second sting: every new RPC node joining the network forces the chain to push more shreds via Turbine, slowing propagation for everyone. Reads never needed that heavy a rig.
03断片化 — 各社の閉じた自作パイプラインとロックインFragmentation — closed, in-house pipelines and lock-in
性能とコストの壁を回避するため、各プロバイダーがモノリスの周りに独自パイプラインを自作。結果、それぞれが閉じたAPIの裏に隠れ、相互運用を想定しない作りになりました。大きなコードベースほど乗り換えは非現実的になり(ロックイン)、性能改善もエコシステム全体には積み上がりません。To dodge the performance and cost walls, each provider built its own pipeline around the monolith. The result: each hidden behind a closed API, none designed to interoperate. The bigger your codebase, the more impractical switching becomes (lock-in), and performance gains never compound across the ecosystem.
全体像 — 2つの問い、1つの型Anatomy — two questions, one shape
RPC 2.0 はバリデータから読み取りを外に出し、性質の違う2つの問いに別エンジンをあてます。面白いのは、その2つがまったく同じ4段の型でできていること。 RPC 2.0 lifts reads out of the validator and gives two different questions their own engines. The elegant part: both are built from the very same four-stage shape.
🤔 まず予想してみよう🤔 Predict first
アカウントの最新残高と、3ヶ月前の取引履歴。同じデータベースで引くべき?An account's latest balance, and its 3-month-old transaction history. Should one database serve both?
答え: B。 「いまの残高」は1アカウントを頻繁に更新・即時参照する用途、「過去の履歴」は膨大で書き換えのないデータを範囲スキャンする用途。要求が正反対なので、Cloudbreak は PostgreSQL、Superbank は ClickHouse と、土台から分けています。 Answer: B. "Current balance" means frequently updated, instantly read single accounts; "history" means range-scanning huge, immutable data. Opposite demands — so Cloudbreak uses PostgreSQL and Superbank uses ClickHouse, split at the foundation.
2つのエンジンの設計Inside the two engines
ここが図解の主戦場。まず履歴側(Superbank)、次に状態側(Cloudbreak)。どちらもよく来るクエリの形に合わせて作りを最適化します(Superbankは投入時に先回りで、Cloudbreakはあなたのトラフィックに反応して)。 The heart of the diagrams. History first (Superbank), then state (Cloudbreak). Both optimize their structure for the shapes of common queries — Superbank pre-builds them at write time, Cloudbreak reacts to your traffic.
Superbank · 履歴 · ClickHouse· history · ClickHouse
全履歴は膨大で、Tritonによれば1日あたり数千万件規模の取引が積み上がります。鍵は「全部速く読む」のではなく、関係ない部分を読まないこと。列指向のClickHouseは必要な列だけを読み、各テーブルが検索向けに物理的に並べ替えてあるので、無関係な範囲も丸ごと飛ばせます。The full ledger is enormous — by Triton's account the chain adds tens of millions of transactions a day. The trick isn't reading everything fast — it's not reading the irrelevant parts. Columnar ClickHouse reads only the needed columns, and because each table is physically sorted for the query, it skips irrelevant ranges entirely.
Superbank の取り込みは入口を選びません。どこから取り込んでも、そのまま全部ためて、質問されやすい形に整理しておく ── だから後で速く答えられます。Superbank's ingest is not picky about the inlet. Wherever the data comes from, it stores everything as-is and organizes it for the common questions — so it can answer fast later.
実際の取込元・構成を見るSee the real sources & components
📘 取込→ClickHouse→提供の3層。取込元はFumarole / gRPC / JSON-RPC / Bigtableから選び、フィルタせず全件投入(フル履歴のバックフィルにはAnzaのJetstreamerプラグイン)。本番トポロジは単一 / cluster / replicated(ZooKeeper)。ヘッドキャッシュは任意(--features grpc-head-cache)で、有効時<1ms・一部の履歴メソッドでprocessed。 📘 Three layers: ingest → ClickHouse → serve. Ingest picks one of Fumarole / gRPC / JSON-RPC / Bigtable and writes everything unfiltered (full-history backfill uses Anza's Jetstreamer plugin). Production topology: local / cluster / replicated (ZooKeeper). The head cache is optional (--features grpc-head-cache): when on, <1 ms with processed on a subset of methods.
ClickHouse側のキモは、よく聞かれる質問の“作り置きの答え”を書き込み時にあらかじめ用意しておくこと。だからクエリ時に重い計算をせず、整った答えをすぐ返せます。The heart of the ClickHouse side: it prepares answers to the common questions ahead of time, at write time. So at query time it skips the heavy work and returns a ready answer.
実テーブル名と DDL を見るSee the real table names & DDL
📘 全テーブルは ReplacingMergeTree(slot)。基底 transactions がMVの供給源で、各MVは「住所 / 署名 / 所有者」のバケットで分け、slot降順で並べる ── 最新が先頭に来るので履歴クエリが速い。 📘 Every table is ReplacingMergeTree(slot). Base transactions feeds the MVs; each buckets by address / signature / owner and sorts slot-descending so the newest rows sit first.
新メソッド getTransactionsForAddress(beta) ── ウォレットの履歴取得は、これまで「署名を一覧 → 1件ずつ明細を取得」と何度も往復が必要でした(N+1問題)。gTFAはこれを“1回お願いするだけ”にまとめ、サーバ内で処理して1往復で返します。New method getTransactionsForAddress (beta) — fetching wallet history used to need many round trips: list signatures, then fetch each one (the N+1 problem). gTFA folds it into a single request, resolved server-side and returned in one round trip.
サーバ内部の仕組み(実テーブル)を見るSee how it works inside (real tables)
📘 gTFAは gsfa(署名側)を走査し transactions(明細)で補完して1リクエストに束ねる。tokenAccounts フィルタは token_owner_activity が必要(無ければ拒否)。transactionDetails・sortOrder・paginationToken 対応。 📘 gTFA scans gsfa (signatures) and hydrates from transactions (details) in one request. tokenAccounts filters require token_owner_activity (rejected if absent). Supports transactionDetails, sortOrder, paginationToken.
Cloudbreak · 状態 · PostgreSQL· state · PostgreSQL
Cloudbreak の見せ場は自動索引化。あなたの実トラフィックを数え、よく来るフィルタ型が閾値を超えると、専用のPostgreSQL索引を自動で作り、以後そのクエリはスキャンを飛ばして直接索引に当たります。手動の設定も申請も不要。(公式のexample設定では既定値 index-generation-threshold = 10。下のデモもこれに合わせています。)下のボタンで動かしてみてください。Cloudbreak's showpiece is auto-indexing. It counts your real traffic, and once a filter pattern crosses a threshold it builds a tailored PostgreSQL index automatically — and from then on matching queries skip the scan and hit the index directly. No manual setup or index requests. (The official example config defaults to index-generation-threshold = 10; the demo below matches that.) Try it below.
仕組みを一言でいうと、「よく来る質問を数えて、多ければ専用の“近道”を自動で用意する」。図にするとこうです:In a line: it counts which questions come often, and for the frequent ones it auto-builds a "shortcut". As a picture:
実際の構成と既定値を見るSee the real components & defaults
📘 5構成 ── 取込・保管・Query Tracker(フィルタ型の回数を数える)・Index(閾値超で専用Postgres索引)・Serve(標準JSON-RPCを振り分け)。対象プログラムに絞ることも可能。 📘 Five parts — ingest, store, Query Tracker (counts filter patterns), Index (tailored Postgres index past a threshold), Serve (routes standard JSON-RPC). Can be scoped to specific programs.
📘 query-tracker の既定値(公式 example 設定): index-generation-threshold=10 · index-creation-delay=10s · query-counts-reset-interval=24h · indexer-metrics-threshold=5(インデクサーが多忙なら索引作成を待機) · max-auto-indexes=100。included/excluded-programs で対象を限定可。 📘 query-tracker defaults (official example config): index-generation-threshold=10 · index-creation-delay=10s · query-counts-reset-interval=24h · indexer-metrics-threshold=5 (pause index creation when the indexer is busy) · max-auto-indexes=100. Scope via included/excluded-programs.
整合性と自己修復Consistency & self-healing
速い別系統のDBは、停止やデータの取りこぼしにどう耐えるのか。Cloudbreakは起動時にSolanaのフルスナップショットで全アカウントをそろえ、ライブgRPCで更新を追い、取りこぼしを検出すると増分スナップショットから自動で復旧します。 How does a fast, separate database stay consistent and survive dropped data? Cloudbreak seeds the full account set from a full Solana snapshot on startup, follows live gRPC for updates, and auto-recovers from incremental snapshots when it detects a gap.
🤔 まず予想してみよう🤔 Predict first
ライブgRPCがスロットを取りこぼしたら、データはどうなる?If the live gRPC stream drops slots, what happens to the data?
答え: B。 公式によれば、ストリームがスロットを落とすと取り込み器が欠損を検出し、手動介入なしに増分スナップショットから自動復旧します。さらにデータセットは有界で、各アカウントは最新版のみを保持し、上書きされた版は確定時に破棄されます。 Answer: B. Officially, if the stream drops slots the ingester detects the gap and automatically recovers from incremental snapshots, with no manual intervention. The dataset is also bounded: only the latest version of each account is kept, with superseded versions discarded on finalisation.
Solana自体が、全アカウント状態の準同型ハッシュ「Accounts Lattice Hash」をスナップショットに書き込む仕組み(SIMD-215 / 220)を持ち、ノードは起動時にこれを検証することが推奨されています。つまり「スナップショットを真実の源とする」設計には、ネットワーク側に検証可能性の土台があります。ただし、Cloudbreakが内部でこのハッシュ照合や参照Agaveノードとの応答比較をどう使うかは、公開ブログには記載がありません(実装レベルの詳細)。本資料では確証できる範囲に留め、断定は避けています。 Solana itself writes a homomorphic hash of total account state — the Accounts Lattice Hash — into snapshots (SIMD-215 / 220), and nodes are advised to verify it at boot. So a "snapshot as source of truth" design rests on a network-level basis for verifiability. However, exactly how Cloudbreak uses such hashing or reference-Agave comparison internally is not stated in the public posts (an implementation-level detail), so we don't assert it here.
スナップショットはどう手に入れる? ── ブートストラップも自己修復も、同じ cluster tracker と snapshot crate の仕組みを使います。Where do the snapshots come from? — both bootstrap and self-healing use the same cluster tracker and snapshot crate machinery.
オープン化と現在地Open-sourcing & where it stands
RPC 2.0 は、両モジュールをAGPLで公開し、Solana Foundation が運営する中立組織 solana-rpc の下に置く取り組みです。 RPC 2.0 open-sources both modules under AGPL and places them under solana-rpc, a neutral org run by the Solana Foundation.
コスト — 古いデータに割増なしCost — no premium for old data
運用コストが下がったため、どの時代のデータでも料金は同じ。自前運用も現実的で、Cloudbreakはフルチェーンのインスタンス(数百のクエリパターン)でも約700GBに収まり、単一のPostgreSQLノードで月$400未満で動きます。対比として、カスタム索引用の専用Agaveノードは月$3,000超でした。Lower operating cost means the same price for data from any era. Self-hosting is realistic too: a full-chain Cloudbreak instance with hundreds of query patterns fits in ~700 GB and runs on a single PostgreSQL node for under $400/mo — versus a dedicated Agave index node at $3,000+/mo.
あゆみTimeline
正直な現在地(2026年6月)Honest status (June 2026)
- Tritonの本番で稼働中。履歴・アカウントの主要メソッドを提供。Running in Triton production, serving the main history & account methods.
- 標準のSolana JSON-RPC互換で差し替え可。既存連携はそのまま。Drop-in on standard Solana JSON-RPC; existing integrations keep working.
- 本番運用中(Cloudbreakは既存サービスの再設計、Superbankはゼロからの再構築でOld Faithfulの後継)。Running in production (Cloudbreak = re-architecture of an existing service; Superbank = ground-up rebuild, successor to Old Faithful).
- 2026年6月に公開されたばかり(デプロイ可能なコード・docs・テストは同梱)。Open-sourced only in June 2026 (ships deployment-ready code, docs & tests).
- 改名直後(Hydrant/Steamboat→Superbank/Cloudbreak)で名残あり。Just renamed (Hydrant/Steamboat → Superbank/Cloudbreak); leftovers remain.
- 外部の採用・貢献はこれから(RPCワーキンググループは発足済み)。External adoption & contribution are still nascent (the RPC working group is established).
- 性能・コストはすべてTriton自社計測。第三者ベンチなし。All performance/cost is Triton's own; no third-party benchmark.
- 「38倍(履歴)/20倍超(アカウント)」は基準・統計の取り方依存。"38× (history) / 20×+ (accounts)" depends on baseline & statistic.
- 稼働には外部データソースが必要(Cloudbreak=Yellowstone gRPC / Superbank=Fumarole・gRPC・JSON-RPC・Bigtable)。フル履歴の自己ホストは容量が大きく重い。Needs an external data source (Cloudbreak = Yellowstone gRPC / Superbank = Fumarole, gRPC, JSON-RPC, or Bigtable); full-history self-host is large and heavy.
- processedコミットメントは限定的: Cloudbreakは既定でエラー(将来プラグイン予定)、Superbankはヘッドキャッシュ有効時の一部メソッドのみ。processed commitment is limited: Cloudbreak errors by default (plugin planned), Superbank only via the head cache for a subset of methods.
非公式の教育目的の解説です。事実は 📘公式 / 📊Triton計測 / 🌱現状 のラベルで出所を区別しています。📊の数値はTriton自身の計測・試算で、第三者検証ではありません。2026年6月時点の情報で、公開直後のため変わり得ます。一次情報は上の出典でご確認ください。 An unofficial educational explainer. Facts are tagged by origin: 📘 official / 📊 Triton bench / 🌱 current. The 📊 figures are Triton's own measurements/estimates, not independently verified. Current as of June 2026 and subject to change. Verify against the primary sources above.
