Solana 節點：驗證者、RPC 節點與自架

錢包讀取餘額、瀏覽器擷取兩年前的交易、交易系統接收帳戶更新，這些操作表面上可能都在使用同一個 Solana 服務。但實際上，它們依賴的是不同的基礎設施。

對於應用程式團隊來說，值得問的問題不是單純的「我們該不該自己跑一個 Solana 節點？」而是：我們的應用程式需要哪些工作負載，又該自行維運堆疊中的哪些部分？

Solana 基礎設施的三個層級是什麼？

在 Solana 上開發時，有三種基礎設施類型，全都源自於 Solana 節點。那 Solana 節點是什麼？簡單來說，Solana 節點就是一台執行 validator 客戶端軟體的伺服器。

負責投票的 validator 負責保障鏈的安全並產生區塊，而不投票的 remote procedure call（RPC）節點則負責公開即時狀態與交易 API。此外還有獨立的封存、索引、快取、串流系統，用來處理標準節點無法自行有效保留或回應的工作負載。

投票 validator 保障鏈的安全

投票 validator 參與共識機制，協助網路就正典鏈達成共識。當被選為 leader 時，它們也會產生區塊。它們的主要職責是保持同步、正確投票，以及可靠地執行 leader 職責。

應用程式依賴這種共識機制，但大部分的應用程式請求並不會直接送到投票 validator。

RPC 節點服務即時應用程式流量

RPC 節點通常執行與投票 validator 相同的 validator 客戶端軟體，只是不投票。它會跟隨叢集、重放區塊、維護目前的帳戶狀態，但不投票，也不會進入 leader schedule。

它公開的是 Solana 的 RPC 介面。錢包、交易所、瀏覽器、機器人及其他應用程式，都透過這個介面查詢鏈上資料、模擬交易並送出交易。

理論上，投票 validator 也可以公開 RPC 介面。但在正式環境中，維運者通常會將此介面保持私有或加以限制，避免無法預測的應用程式流量與共識及區塊產生互相競爭。

次級系統服務特定的資料工作負載

RPC 節點公開的是 Solana 的 API，但提供者不一定要直接從即時節點回應每一個請求。它們可以使用專門為以下用途打造的系統：

• 長期的交易與區塊歷史紀錄
• 帳戶索引與昂貴的篩選查詢
• 快取常被請求的資料
• 具備篩選、緩衝、重播與復原能力的即時串流

對於由這些系統服務的標準 RPC 方法，應用程式仍可繼續使用相同、熟悉的 API 方法、參數、篩選條件與回應格式。改變的只有回應請求的系統。舊的歷史資料來自獨立的儲存系統，因為即時節點已不再保有這些資料；而昂貴的目前狀態查詢，則可以更有效率地由專用索引或快取來服務。

哪個基礎設施層級負責處理哪種 Solana 工作負載？

來看幾個常見的應用程式請求：

• 錢包查詢餘額或模擬交易。即時 RPC 節點可以直接從目前狀態回應。
• 瀏覽器載入兩年前的一筆交易。應用程式呼叫的仍是標準 RPC 方法，但提供者是從封存儲存中回應，因為即時節點已不再擁有這筆資料。
• 投資組合應用程式查詢某個大型 program 擁有的所有帳戶。同樣的 RPC 方法與篩選條件，可以改由帳戶索引或快取來服務，而不用讓節點反覆掃描其狀態。
• 交易系統需要即時取得每一筆帳戶或交易更新。它使用串流基礎設施來持續接收資料，通常同時搭配 RPC 進行特定時間點的查詢。
• 網路維運者想要投票並產生區塊。這需要的是投票 validator，而不是應用程式用的 RPC 服務。

提供者可能會將上述多項能力整合成單一服務。應用程式看到的是熟悉的介面，背後則由不同的系統負責實際運作。

Solana 節點如何服務歷史資料？

getTransaction、getBlock、getSignaturesForAddress 等方法可以查詢舊有活動。然而，標準 RPC 節點在本地只會保留有限的帳本範圍。一旦較舊的資料被清除，即使增加 CPU 也無法讓查詢生效，因為該節點上已經沒有這些資料了。

深度的 Solana 封存資料需要一套獨立的路徑，來：

1. 從即時與歷史來源擷取區塊與交易
2. 偵測並修復缺失的資料
3. 儲存資料以達成長期保留與高查詢量
4. 從這個儲存層來服務歷史 RPC 請求

這就是為什麼「archive RPC」不只是磁碟比較大的普通節點。在正式環境的規模下，提供者通常會透過熟悉的 RPC 介面，由獨立的儲存與查詢系統來服務 archive RPC。

在 Alchemy，我們是直接體會到這個限制的。我們一開始使用 Google Bigtable 來儲存 Solana 歷史資料，後來重建了自架 HBase 上的封存堆疊。如今，每筆紀錄都會寫入兩次、以程式方式驗證，並掃描其完整性。當系統發現缺漏時，會重新擷取缺失的項目。getTransaction、getSignaturesForAddress 等歷史方法，現在都是從這個經過最佳化的資料層讀取，而不是仰賴即時 RPC 叢集的本地保留資料，藉此提供客戶所期待的速度與可靠性。

為什麼 getProgramAccounts 的成本很高？

getProgramAccounts 展現的是另一種限制。相關的帳戶資料確實存在於目前狀態中，但要回應這個請求，可能需要在查詢時搜尋大量帳戶並套用篩選條件。

節點儲存帳戶主要是為了能夠重放區塊並維護目前的鏈上狀態，它並不是一個通用的分析型資料庫。偶爾直接掃描或許可以接受，但在正式環境流量下反覆掃描數百萬個帳戶，就會變得緩慢且耗費大量資源。

對於持續性的工作負載，維運者可以持續接收帳戶更新，並維護方便查詢的索引或快取視圖。之後的請求就能直接讀取事先準備好的結果，而不必每次都重新執行完整掃描。

反覆的 getProgramAccounts 請求，其實是索引問題，而不是節點不夠大的問題。換句話說，關鍵區別不在於「小節點」與「大節點」之分，而在於「即時節點資料服務」與「索引資料服務」之分。

Geyser 與 gRPC 串流是如何運作的？

交易系統、索引器及其他即時應用程式，通常需要在帳戶、交易、slot 或區塊更新發生的當下就進行處理。

WebSocket 訂閱是 Solana 標準介面的一部分，對於部分即時事件運作良好。若工作負載需要更低的延遲、更高的吞吐量，或更豐富的篩選功能，Yellowstone gRPC 則提供了一個建構在 gRPC over HTTP/2 之上、效能更高的串流介面。

Agave validator 客戶端（包括其以不投票 RPC 節點方式執行時）也可以執行 Geyser plugins。Geyser 會在節點處理鏈上資料的過程中，發出帳戶、交易、slot 與區塊更新。提供者可以透過相容於 Yellowstone 的 Solana gRPC公開這些資料，並加入篩選、緩衝、重播、可靠性與多節點傳遞等機制。

串流並不能取代 RPC。RPC 回答的是關於狀態的問題，串流告訴應用程式的是狀態發生了變化。許多正式環境的系統會同時使用這兩者。

什麼時候應該自行架設 Solana 基礎設施？

大多數應用程式團隊應該從使用提供者開始。單一個自架的 RPC 節點，並不會自動涵蓋你所需的所有使用情境（例如提供持久的歷史資料、索引查詢、全球分散式的 API，或資料串流），而要可靠地做到這一切，需要投入大量心力。

當掌控自己的基礎設施能提升產品，或政策要求讓受管理的服務無法採用時，自行架設才有意義。例如：

• 參與共識機制的 validator 維運者
• 對延遲敏感、需要特定節點位置或交易路由控制權的交易系統
• 需要自訂 Geyser plugins、索引或保留政策的服務
• 有嚴格合規或基礎設施控管要求的組織
• 流量夠大、足以支撐一個專職基礎設施團隊的大型平台

判斷的標準在於：自行掌控基礎設施所帶來的優勢，是否明顯超過所需投入的硬體、工程與 on-call 成本。

維運 Solana 基礎設施需要什麼？

目前的 Agave 硬體建議，在還沒考慮正式環境流量、備援與周邊資料系統之前，門檻就已經不低了。

硬體只是最基本的門檻。在 Solana 目前的共識機制下，投票 validator 每天在投票交易上，最多可能要花費約 1.1 SOL。正式環境的 RPC 服務需要備援節點，以避免單點故障。至於自架且需要深度歷史資料、索引或可靠串流的團隊，也必須自行維運這些系統。

如何架設 Solana 節點？

架設流程的起點是先確定角色，而不是先打指令。

1. 選定工作負載。決定這個部署要投票、服務 RPC，還是餵給特定的資料處理管線。
2. 佈署主機。依照客戶端與角色，配置符合目前要求的 CPU、記憶體、儲存空間、頻寬、作業系統與公開 IP。
3. 設定角色。RPC 維運者以不投票的方式執行，並選擇所需的歷史資料範圍、帳戶索引與保留設定；validator 維運者則設定其身分與投票帳戶。
4. 保護金鑰與端點。將敏感金鑰放在 validator 主機之外，並在公開的 RPC 與 WebSocket 端點前加上驗證、速率限制與負載平衡。
5. 維運整套服務。監控同步狀態、磁碟、CPU、網路、行程健康狀態，以及應用程式層級的錯誤。同時規劃升級、復原、容錯移轉與濫用防範。

關於目前的 validator 指令與參數或 RPC 節點架設，請參考 Agave 持續維護的指南。

該如何評估 Solana 基礎設施提供者？

先從你的應用程式所需的工作負載開始，再逐一詢問提供者是如何服務每一項的。

針對你的應用程式會用到的方法、訂閱與地區進行效能測試。Solana RPC providers 指南依這些標準比較了目前可用的選項。

重點結論

Solana 應用程式需要的並非抽象意義上的「一個節點」，而是具體的能力：即時狀態、交易 API、歷史資料、索引查詢、串流，或在少數情況下，還包括共識參與。

先確認這些工作負載，再決定堆疊中哪些部分由內部自行維運能帶來實質優勢，哪些則更適合向受管理的服務取得。

用 Alchemy 在 Solana 上開發

大多數應用程式團隊，並不需要自行維運 RPC 叢集、封存資料庫、索引與串流基礎設施。我們提供用於狀態與交易查詢的即時 Solana RPC、透過標準方法從創世區塊起算的區塊與交易歷史紀錄，以及相容於 Yellowstone 的 gRPC 即時串流。

開始在 Solana 上開發、參考 Solana API 快速入門指南，或聯絡我們的團隊，了解專屬容量與客製化工作負載相關資訊。

常見問題

Solana 節點是什麼？

Solana 節點是一台執行 validator 客戶端軟體的伺服器。它會跟隨叢集、重放區塊、維護目前的鏈上狀態，並與其他節點通訊。投票 validator 參與共識與區塊產生；不投票的 RPC 節點則負責公開應用程式所需的 API。

validator 與 RPC 節點有什麼差別？

兩者都會跟隨並重放鏈上資料。投票 validator 參與共識機制，並在被選為 leader 時產生區塊；RPC 節點則不投票，也不會進入 leader schedule，其重點在於向應用程式提供即時狀態與交易 API 服務。

archive 節點是另一種獨立的 Solana 節點類型嗎？

通常不是。深度的交易與區塊歷史紀錄，一般是由獨立的封存資料系統透過相容於 RPC 的介面來服務，而不是靠磁碟比較大的標準節點來提供。

應用程式需要自行執行 validator 嗎？

通常不需要。應用程式依賴 validator 來建立鏈，但它們自身的請求通常會送到 RPC 節點與特定的資料服務。執行 validator 是為了參與共識，而不是為了讓應用程式取得一般的存取權。

Solana validator 或 RPC 節點的硬體需求是什麼？

依目前 Agave 的建議，投票 validator 至少需要 12 核心、24 執行緒與 256 GB RAM；不投票的 RPC 節點則至少需要 16 核心與 32 執行緒，若要執行所有帳戶索引，建議配置 512 GB RAM。兩者都需要高速的 NVMe 儲存裝置與可靠的網路。

執行 Solana 節點需要 SOL 嗎？

不投票的 RPC 節點不需要 SOL 來投票。投票 validator 則需要已注資的身分帳戶與投票帳戶，並在目前的共識機制下負擔投票交易的成本。

執行 Solana validator 划算嗎？

這取決於委託的質押量、投票表現、佣金比例、被選為 leader 時的交易手續費收入、最大可提取價值收入，以及維運成本。委託質押量偏低的 validator，通常很難打平成本。應將 validator 維運視為一項獨立的基礎設施事業來經營，而不是取得應用程式 RPC 存取權的手段。

如何架設 Solana 節點？

先選定角色，再依照目前的客戶端要求佈署主機，設定投票或 RPC 相關行為，妥善保護金鑰與端點，並加入監控與容錯移轉機制。由於支援的版本與建議做法會隨時間變動，請以目前的 Agave 文件為準來取得指令與參數資訊。

我應該自架 RPC 節點，還是使用提供者？

若你需要受管理的容量、歷史資料、索引方法、串流或容錯移轉，卻不想自行維運這些系統，就適合使用提供者。若掌控權、客製化設定、實體位置、持續擴展規模，或政策要求足以支撐一個專職基礎設施團隊，則適合自行架設。