---
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 上构建时,有 3 种类型的基础设施,它们都源自 Solana 节点。那么什么是 Solana 节点?简单来说,Solana 节点就是运行验证者客户端软件的服务器。

投票验证者(voting validator)负责保护链的安全并生产区块,而非投票的远程过程调用(RPC)节点则暴露实时状态和交易 API。独立的归档、索引、缓存和流式传输系统,则用于服务那些标准节点无法自行高效保留或响应的工作负载。

### 投票验证者负责链的安全

投票验证者参与共识,帮助网络就规范链达成一致。当被选为 leader 时,它们也会生产区块。它们的主要职责是保持同步、正确投票,并可靠地履行 leader 职责。

应用依赖于这种共识,但大多数应用请求并不会直接发送给投票验证者。

### RPC 节点服务实时应用流量

RPC 节点通常运行与验证者相同的客户端软件,只是不参与投票。它跟随集群、重放区块并维护当前账户状态,但不投票,也不进入 leader 调度。

相反,它暴露的是 Solana 的 RPC 接口。钱包、交易所、浏览器、机器人和其他应用使用该接口来查询链上数据、模拟交易并提交交易。

投票验证者在技术上也可以暴露 RPC。在生产环境中,运营者通常会将该接口设为私有或加以限制,以免不可预测的应用流量与共识和区块生产竞争资源。

### 二级系统服务专门的数据工作负载

RPC 节点暴露 Solana 的 API,但服务提供商不必让每个请求都直接由实时节点来回答。它们可以使用专门构建的系统来处理:

- 长期交易和区块历史记录
- 账户索引和开销较大的过滤查询
- 缓存高频请求的数据
- 带过滤、缓冲、重放和恢复功能的实时流

对于由这些系统提供服务的标准 RPC 方法,应用可以继续使用相同的、熟悉的 API 方法、参数、过滤器和响应格式。变化的只是回答请求的系统。旧的历史数据来自独立的存储,因为实时节点已不再保有这些数据;而开销较大的当前状态查询,则可以由专门的索引或缓存更高效地提供。

## 每种 Solana 工作负载分别由哪个基础设施层处理?

来看几个常见的应用请求:

- 钱包查询余额或模拟一笔交易。实时 RPC 节点可以直接根据当前状态作答。
- 浏览器加载两年前的一笔交易。应用调用的仍是标准 RPC 方法,但服务提供商是从归档存储中作答,因为实时节点已不再保有这些数据。
- 投资组合应用查询某个大型程序拥有的所有账户。同样的 RPC 方法和过滤器,可以由账户索引或缓存来提供服务,而不必让节点反复扫描其状态。
- 交易系统需要实时获取每一次账户或交易更新。它使用流式基础设施实现持续交付,通常还会搭配 RPC 用于定点查询。
- 网络运营者希望参与投票和区块生产。这需要一个投票验证者,而非应用 RPC 服务。

服务提供商可能将上述多项能力整合为一项服务对外提供。应用看到的是熟悉的接口,而背后处理工作的则是不同的系统。

## Solana 节点如何提供历史数据服务?

诸如 `getTransaction`、`getBlock` 和 `getSignaturesForAddress` 这样的方法可以查询旧的活动记录。然而,标准 RPC 节点在本地只保留有限的账本窗口。一旦较旧的数据被清理掉,增加 CPU 也无法让查询恢复工作。数据已不再存在于该节点上。

深度 [Solana 归档数据](https://www.alchemy.com/overviews/solana-archival-data) 需要一条独立的路径,它需要:

1. 从实时和历史来源摄取区块和交易
2. 检测并修复缺失的数据
3. 将数据存储起来,以实现长期保留和高查询量
4. 从该存储层为历史 RPC 请求提供服务

这就是为什么"archive RPC"并不只是磁盘更大的普通节点。在生产规模下,服务提供商通常会通过独立的存储和查询系统来提供 archive RPC 服务,并以熟悉的 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 提供了一个基于 HTTP/2 上的 gRPC 构建的、性能更高的流式接口。

Agave 验证者客户端(包括以非投票 RPC 节点方式运行时)也可以运行 [Geyser 插件](https://www.alchemy.com/overviews/solana-geyser-plugin)。Geyser 会在节点处理链上数据时,发出账户、交易、slot 和区块更新。服务提供商可以通过[兼容 Yellowstone 的 Solana gRPC](https://www.alchemy.com/solana-grpc) 来暴露这些数据,并加入过滤、缓冲、重放、可靠性保障以及多节点分发等能力。

流式传输并不能取代 RPC。RPC 回答的是关于状态的问题;流式传输告诉应用状态发生了变化。许多生产系统会同时使用两者。

## 什么时候应该自托管 Solana 基础设施?

大多数应用团队应该从使用服务提供商开始。一个自托管的 RPC 节点并不能自动覆盖你所需要的全部用例(提供持久的历史数据、索引查询、全球复制的 API,或数据流),要可靠地做到这些工作量很大。

当掌控自己的基础设施能提升产品体验,或者政策要求排除了托管服务这一选项时,自托管才是合理的。例如:

- 参与共识的验证者运营方
- 对延迟敏感、需要特定节点部署位置或交易路由控制的交易系统
- 需要自定义 Geyser 插件、索引或保留策略的服务
- 有严格合规或基础设施管控要求的组织
- 流量规模足以支撑专职基础设施团队的大型平台

判断标准在于:掌控基础设施所带来的可衡量优势,是否超过了硬件、工程投入和值班运维的成本。

## 运营 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 当前的共识机制下,投票验证者每天在投票交易上的花费还可能高达约 1.1 SOL。生产环境的 RPC 服务需要冗余节点,以避免单点故障。而如果自托管团队需要深度历史数据、索引或可靠的流服务,还必须自行运营这些系统。

## 如何运行一个 Solana 节点?

搭建工作从明确角色开始,而不是从命令行开始。

1. 选择工作负载。决定该部署是用于投票、服务 RPC,还是为专门的数据管道提供数据。
2. 配置主机。根据所选客户端和角色,匹配当前对 CPU、内存、存储、带宽、操作系统和公网 IP 的要求。
3. 配置角色。RPC 运营者以非投票方式运行,并选择所需的历史记录、账户索引和保留设置;验证者运营者则配置其身份账户和投票账户。
4. 保护密钥和端点。不要将敏感密钥存放在验证者主机上。为公开的 RPC 和 WebSocket 端点加上身份验证、速率限制和负载均衡。
5. 运营完整的服务。监控同步状态、磁盘、CPU、网络、进程健康状况以及应用层的错误。为升级、恢复、故障转移和滥用防护做好规划。

有关最新的[验证者命令和参数](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 服务提供商指南](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 节点是运行验证者客户端软件的服务器。它跟随集群、重放区块、维护当前链状态,并与其他节点通信。投票验证者参与共识和区块生产;非投票的 RPC 节点则暴露应用 API。

### 验证者和 RPC 节点有什么区别?

两者都跟随并重放链上数据。投票验证者参与共识,并可能在被选为 leader 时生产区块。RPC 节点不投票,也不进入 leader 调度,而是专注于向应用提供实时状态和交易 API 服务。

### archive 节点是一种独立的 Solana 节点类型吗?

通常不是。深度的交易和区块历史记录一般是由独立的归档数据系统通过兼容 RPC 的接口提供服务,而不是由磁盘更大的标准节点提供。

### 应用需要运行验证者吗?

通常不需要。应用依赖验证者来建立链本身,但它们自己的请求通常发往 RPC 节点和专门的数据服务。运行验证者是参与共识所必需的,而非应用进行常规访问所必需的。

### 运行 Solana 验证者或 RPC 节点的硬件要求是什么?

当前 Agave 的指导要求投票验证者至少配备 12 核、24 线程和 256 GB 内存。非投票 RPC 节点起步要求为 16 核、32 线程,若运行全部账户索引,则建议配备 512 GB 内存。两者都需要快速的 NVMe 存储和可靠的网络。

### 运行 Solana 节点需要 SOL 吗?

非投票的 RPC 节点不需要 SOL 用于投票。投票验证者需要有资金的身份账户和投票账户,并在当前的共识机制下承担投票交易的开销。

### 运行 Solana 验证者能盈利吗?

这取决于委托质押量、投票表现、佣金比例、被选为 leader 时的交易费收入、最大可提取价值(MEV)收入以及运营成本。委托质押量较少的验证者往往难以实现盈亏平衡。应把运营验证者视为一项独立的基础设施业务,而不是获取应用 RPC 访问权限的手段。

### 如何运行 Solana 节点?

先选择角色,再根据当前客户端要求配置主机,配置投票或 RPC 行为,保护密钥和端点安全,并加入监控和故障转移机制。由于受支持的版本和建议会不断变化,请以当前的 Agave 官方文档中的命令和参数为准。

### 应该自托管 RPC 节点,还是使用服务提供商?

如果你需要托管容量、历史数据、索引方法、流式传输或故障转移能力,而又不想自行运营这些系统,就使用服务提供商。如果掌控力、自定义配置、物理部署位置、持续的规模,或政策要求足以支撑一个专职基础设施团队,则可以选择自托管。