ERPC、Solana RPC においてヒストリカルデータへのアクセスを全リージョンで提供開始。Old Faithful 統合により欠損のない履歴取得を実現

ELSOUL LABO B.V.(本社:オランダ・アムステルダム、代表取締役 CEO:川崎文武)と Validators DAO が運営する ERPC は、Solana RPC において、ヒストリカルデータ(過去履歴データ)へのアクセスを正式に提供開始したことをお知らせいたします。
edge.erpc.global の Solana RPC では、URL に history=true を付けると、古いブロックやトランザクションを取得するヒストリーアクセスをご利用いただけます。ヒストリーアクセスには、ERPC の RPC プランのトークンが使われます。本対応は、Solana のアーカイブおよびヒストリカルデータ配信を目的として設計されたオープンソース技術 Old Faithful を、ERPC の RPC 基盤に統合することで実現しています。
Solana RPC におけるヒストリカルデータ取得の構造的課題
Solana では、現在 1 エポックあたり 1〜2 日で約 500GB 規模のデータが生成されています。このデータ量は年々増加しており、RPC ノードに求められるストレージ容量および I/O 性能に大きな負荷を与えています。
一般的な RPC ノードは、性能と安定性を維持する観点から、数エポック分のデータのみを保持する構成が主流です。多くの場合、4TB 前後のストレージ構成では 3〜4 エポック分、すなわち直近 1 週間程度のデータのみが保持され、それ以前のブロック、トランザクション、アカウント状態については取得時に欠損が発生します。
この制約は、オンチェーン分析、長期間の挙動検証、バックテスト、監査、研究用途など、ヒストリカルデータを前提とするユースケースにおいて、長らく実運用上の課題となっていました。
従来のアーカイブ手法が抱えていた現実的制約
Solana の全履歴を取得する手段としては、アーカイブノードの運用が知られていましたが、これには大規模なデータコピー、長時間の初期同期、継続的な高コスト運用が必要となります。
特に、Google Cloud Bigtable を用いたアーカイブ構成は、導入時のデータ移行コストに加え、運用開始後も高額なコストが継続的に発生する構造となっており、多くの開発者や事業者にとって現実的な選択肢とはなっていませんでした。また、特定クラウドへの強い依存は、ブロックチェーンが本来目指す分散性の観点からも課題を抱えていました。
Old Faithful によるヒストリカルデータ配布モデル
Old Faithful は、こうした課題を解決するために設計された、Solana 向けのオープンソースアーカイブ基盤です。Solana の warehouse ノードが生成する RocksDB アーカイブをもとに、Content Addressable Archives(CAR)形式の履歴アーカイブを生成し、配信する仕組みを提供します。
CAR 形式では、各エポック、ブロック、トランザクション、Shred がコンテンツハッシュによって一意に識別されます。これにより、取得したデータが改ざんされていないことを検証可能であり、信頼できない配布元から取得した場合であっても、内容の正当性を確認した上で利用することができます。
Old Faithful は、Genesis ブロックから現在に至るまでの Solana の履歴を一貫して扱うことを前提に設計されており、HTTP、CDN、分散ストレージなど、多様な配布形態に対応可能な構造を備えています。
ERPC における Old Faithful 統合と提供内容
ERPC は、この Old Faithful を Solana RPC 基盤に統合することで、既存の Solana RPC インターフェースをそのまま利用しながら、ヒストリカルデータへのアクセスを可能にしました。ヒストリーアクセスに専用エンドポイントやメソッドはなく、
edge.erpc.global の URL に history=true を付けて利用できます。本アップグレードは、ERPC が提供するすべてのリージョンに反映されており、リージョン間で取得可能な履歴範囲に差はありません。グローバル展開を前提とした構成においても、一貫したヒストリカルデータアクセスが可能です。
パフォーマンス特性と今後の研究開発
ヒストリカルデータは、その性質上、最新データと比較してデータサイズが非常に大きく、クエリ内容によっては取得に時間を要する場合があります。これは構造的な特性によるものであり、不具合や性能劣化を意味するものではありません。
ERPC では、最新世代の大容量 NVMe ストレージを活用した構成検証を含め、ヒストリカルデータ取得時の応答時間についても、継続的な改善に向けた研究開発を進めています。実運用で得られた知見をもとに、段階的な最適化を行っていく方針です。
利用可能範囲の拡大について
本アップグレードにより、ERPC の Solana RPC は、リアルタイム用途に加えて、過去データを前提とする幅広いユースケースに対応可能となりました。長期間にわたるオンチェーン分析、履歴検証、研究用途、監査、アプリケーションの挙動検証など、これまで制約の多かった領域においても、追加のインフラ運用なしで ERPC を活用できます。
ヒストリカルデータへのアクセスが前提となる構成を、通常の RPC 利用の延長として実現できる点は、ERPC の Solana RPC 提供範囲を大きく拡張するものです。
ご利用について
edge.erpc.global への history=true 付きのリクエストでは、古いブロックやトランザクションを取得できます。付けなければ、getTransactionsForAddress 以外はノードが持つ最近の範囲から返ります。HTTP のヒストリーアクセスは、API キーを URL に付ける形と、Bearer ヘッダーで送る形のどちらでもご利用いただけます。
text
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=truehttps://edge.erpc.global?api-key=<YOUR_API_KEY>&history=truetext
https://edge.erpc.global?history=true
Authorization: Bearer <YOUR_API_KEY>https://edge.erpc.global?history=true
Authorization: Bearer <YOUR_API_KEY>ヒストリーアクセスの詳細(ERPC ドキュメント): https://erpc.global/ja/doc/rpc/general/
getTransactionsForAddress の full モードを除き、ヒストリーアクセスで結果が返った場合は、通常の料金に、1 メソッドあたり 640 トークンが上乗せされ、ノードが持つ最近の範囲から返った場合は、history=true を付けても通常の料金です。Free プランなどの枠には、ヒストリーアクセスに使える量の上限があります。ヒストリーアクセスは通常のリクエストより大幅に時間を要する場合があり、秒単位になる場合もあるため、
history=true で分けて、通常のリクエストを速いまま保てます。API キーは、ERPC Web Dashboard にて取得・確認できます。
Validators DAO 公式 Discord: https://discord.gg/C7ZQSrCkYR\
ERPC 公式サイト: https://erpc.global/ja


