ERPC 透過 Old Faithful 為所有地區的 Solana RPC 提供完整且無缺口的歷史資料存取

ERPC 透過 Old Faithful 為所有地區的 Solana RPC 提供完整且無缺口的歷史資料存取

ERPC 透過 Old Faithful 為所有地區的 Solana RPC 提供完整且無缺口的歷史資料存取
由 ELSOUL LABO B.V.(總部:荷蘭阿姆斯特丹,CEO:Fumitake Kawasaki)與 Validators DAO 營運的 ERPC 宣布正式開始提供 Solana RPC 歷史資料存取。
在 edge.erpc.global 端點上,ERPC 的 Solana RPC 透過 History Access 提供歷史資料。使用 Free 方案、擁有其他免費額度或使用付費方案的使用者,透過在 edge.erpc.global URL 上加入 history=true,為較早的區塊和交易請求 History Access。
這項功能透過將 Old Faithful——一套專為 Solana 歸檔與歷史資料傳送設計的開源技術——整合至 ERPC RPC 基礎設施來提供。

Solana RPC 歷史資料存取的結構性挑戰

在 Solana 上,每個 epoch 大約產生 500 GB 的資料,通常跨越一到兩天。這一資料量逐年增加,對 RPC 節點的儲存容量與 I/O 效能帶來龐大需求。
為保持效能和營運穩定性,大多數標準 RPC 節點僅保留有限數量的最近 epoch。在許多情況下,約 4 TB 儲存規格只能儲存三到四個 epoch 的資料,相當於大約一週的歷史。因此,嘗試擷取較早的區塊、交易或帳戶狀態時經常會導致缺失或不完整的回應。
這些限制長期以來對依賴歷史資料的用例構成了實際挑戰,包括鏈上分析、長期行為分析、回測、稽核與研究。

傳統歸檔方法的實際侷限性

傳統上,執行歸檔節點被視為存取完整 Solana 帳本歷史的主要方法。然而,這種方法需要大量資料複製、漫長的初始同步與持續的高營運成本。
特別是基於 Google Cloud Bigtable 的歸檔架構,在部署時涉及大量資料遷移成本,並在營運期間繼續產生可觀費用。對於許多開發者與組織來說,這使得此類解決方案不切實際。此外,對單一雲端供應商的強依賴也從去中心化的角度引起了擔憂——而去中心化是區塊鏈系統的基本原則。

Old Faithful 提供的歷史資料傳送模型

Old Faithful 是一個開源歸檔基礎設施,旨在解決 Solana 生態系統中的這些挑戰。它將 Solana warehouse 節點產生的 RocksDB 歸檔轉為內容可定址歸檔(CAR)格式並對外提供。
在 CAR 格式中,每個 epoch、區塊、交易與 shred 都以內容雜湊唯一識別。這讓資料完整性得以驗證,允許使用者確認擷取到的資料即使從未受信任的傳送來源取得也未被篡改。
Old Faithful 旨在處理自創世區塊至今的完整 Solana 帳本歷史,並支援廣泛的傳送方法,包括 HTTP、CDN 與分散式儲存系統。

ERPC 中的 Old Faithful 整合

透過將 Old Faithful 整合至其 Solana RPC 基礎設施中,ERPC 透過現有的 Solana RPC 介面提供歷史資料存取。歷史資料來自與近期資料相同的 edge.erpc.global 端點和相同的 Solana RPC 方法;請求透過在端點 URL 上加入 history=true 來要求 History Access。
此升級已統一應用於所有 ERPC 地區,確保無論地理位置如何都有一致的歷史資料涵蓋範圍。即使採用全球分散式部署,使用者也能在各地區取得相同的歷史資料。

效能特徵與持續研發

由於歷史資料固有的龐大資料量,某些查詢可能比最新資料的查詢需要更長的完成時間。此行為反映了歷史資料存取的結構性特徵,並不表示系統故障或效能降級。
ERPC 持續研發如何縮短歷史資料擷取的回應時間,包括評估採用下一代大容量 NVMe 儲存的架構。未來將依實際營運所得經驗逐步最佳化。

支援用例範圍的擴充

透過本次升級,ERPC 的 Solana RPC 現在支援超越即時應用的更廣泛用例。長期分析、歷史驗證、研究、稽核與應用程式行為分析現在可以在不需要額外基礎設施的情況下進行。
將歷史資料存取作為標準 RPC 使用的自然延伸提供,顯著擴充了 ERPC Solana RPC 服務的實際適用性。

使用方式

若要讀取較早的區塊和交易,請在 HTTP 請求的 edge.erpc.global 端點 URL 上加入 history=true。除 getTransactionsForAddress 外,未帶 history=true 的請求會從每個節點保留的最近範圍內取得回應。
HTTP 請求可以在 URL 中攜帶 API key:
text
https://edge.erpc.global?api-key=<YOUR_API_KEY>&history=true
或者將 API key 放在 Authorization 標頭中,並在 URL 中保留 history=true:
text
https://edge.erpc.global?history=true
標頭為 Authorization: Bearer <YOUR_API_KEY>。
除 getTransactionsForAddress 的 "full" 模式外,由 History Access 回應的呼叫比該方法的一般價格多消耗 640 個代幣,而由每個節點保留的最近範圍回應的呼叫,即使帶有 history=true,仍為一般價格。getTransactionsForAddress 的 "full" 模式在一般價格之上,每取得一筆交易再多消耗 640 個代幣,無論交易是近期的還是較早的。免費額度(包括 Free 方案的額度)對 History Access 設有上限。
對歷史資料的查詢可能比一般請求慢得多,有時以秒計。ERPC 提供 History Access 作為獨立選項,使歷史資料查詢與一般請求彼此分開,讓一般請求保持快速。
使用者可以在 ERPC Web Dashboard 上取得和檢視自己的 ERPC API key。
Validators DAO 官方 Discord: https://discord.gg/C7ZQSrCkYR ERPC 官方網站: https://erpc.global/zh-tw