---
title: "Solana 節點：驗證者、RPC 節點與自架"
description: "說明 Solana 節點是什麼、驗證者、RPC 節點與次級資料系統的差異，以及何時該自架、何時該使用服務供應商。"
---

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

<ImageBlock
  src="https://media.alchemy.com/blog/solana-nodes-hero-2026-07.png"
  alt="Solana 節點:驗證者、RPC 節點與自架"
  width={5760}
  height={2700}
  priority
/>

錢包讀取餘額、瀏覽器擷取兩年前的交易、交易系統接收帳戶更新，這些操作表面上可能都在使用同一個 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 封存資料](https://www.alchemy.com/overviews/solana-archival-data)需要一套獨立的路徑，來：

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

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

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

## 為什麼 `getProgramAccounts` 的成本很高？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

目前的 [Agave 硬體建議](https://docs.anza.xyz/operations/requirements)，在還沒考慮正式環境流量、備援與周邊資料系統之前，門檻就已經不低了。

<EmbeddedTable
  table={{
    columns: [
      { key: "role", width: 180, title: "Role", dataType: "object" },
      {
        key: "baseline",
        width: 280,
        title: "Baseline requirements",
        dataType: "object",
      },
      {
        key: "production",
        width: 280,
        title: "What production adds",
        dataType: "object",
      },
    ],
    data: [
      {
        role: { title: "Voting validator", tooltip: "", icon: "" },
        baseline: {
          title:
            "12 cores, 24 threads, 256 GB RAM, and separate high-endurance NVMe storage",
          tooltip: "",
          icon: "",
        },
        production: {
          title:
            "Vote-account security, voting costs, upgrades, monitoring, and reliable leader performance",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        role: { title: "Non-voting RPC node", tooltip: "", icon: "" },
        baseline: {
          title:
            "16 cores, 32 threads, and 512 GB RAM when running all account indexes",
          tooltip: "",
          icon: "",
        },
        production: {
          title:
            "Replicas, load balancing, rate limits, failover, abuse protection, and on-call support",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        role: { title: "Secondary data systems", tooltip: "", icon: "" },
        baseline: {
          title: "Workload-dependent compute, storage, and networking",
          tooltip: "",
          icon: "",
        },
        production: {
          title:
            "Ingestion, verification, repair, replication, retention, and query-serving capacity",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
    ],
  }}
/>

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

## 如何架設 Solana 節點？

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

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

關於目前的 [validator 指令與參數](https://docs.anza.xyz/operations/setup-a-validator)或 [RPC 節點架設](https://docs.anza.xyz/operations/setup-an-rpc-node)，請參考 Agave 持續維護的指南。

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

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

<EmbeddedTable
  table={{
    columns: [
      { key: "workload", width: 180, title: "Workload", dataType: "object" },
      {
        key: "evaluate",
        width: 480,
        title: "What to evaluate",
        dataType: "object",
      },
    ],
    data: [
      {
        workload: { title: "Live RPC", tooltip: "", icon: "" },
        evaluate: {
          title:
            "Which regions and node fleets serve reads, simulations, and transaction submission?",
          tooltip: "",
          icon: "",
        },
        id: 0,
      },
      {
        workload: { title: "Historical data", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How far back does retention go, and how does the provider detect and repair missing data?",
          tooltip: "",
          icon: "",
        },
        id: 1,
      },
      {
        workload: { title: "Indexed queries", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How are expensive methods such as getProgramAccounts served under sustained traffic?",
          tooltip: "",
          icon: "",
        },
        id: 2,
      },
      {
        workload: { title: "Streaming", tooltip: "", icon: "" },
        evaluate: {
          title:
            "Which Geyser or gRPC interface is supported, and what happens during a disconnect?",
          tooltip: "",
          icon: "",
        },
        id: 3,
      },
      {
        workload: { title: "Reliability", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How are traffic, failover, replay, and regional incidents handled?",
          tooltip: "",
          icon: "",
        },
        id: 4,
      },
      {
        workload: { title: "Commercial fit", tooltip: "", icon: "" },
        evaluate: {
          title:
            "How do rate limits, burst traffic, pricing, and dedicated capacity change as usage grows?",
          tooltip: "",
          icon: "",
        },
        id: 5,
      },
    ],
  }}
/>

針對你的應用程式會用到的方法、訂閱與地區進行效能測試。[Solana RPC providers 指南](https://www.alchemy.com/overviews/solana-rpc)依這些標準比較了目前可用的選項。

## 重點結論

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

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

## 用 Alchemy 在 Solana 上開發

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

[開始在 Solana 上開發](https://www.alchemy.com/solana)、參考 [Solana API 快速入門指南](https://www.alchemy.com/docs/reference/solana-api-quickstart)，或[聯絡我們的團隊](https://www.alchemy.com/contact-sales)，了解專屬容量與客製化工作負載相關資訊。

## 常見問題

### 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 節點，還是使用提供者？

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