Solana 节点：验证者节点、RPC 节点与自建节点

一个读取余额的钱包、一个检索两年前交易记录的浏览器,以及一个消费账户更新的交易系统,可能看起来都在使用相同的 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 归档数据 需要一条独立的路径,它需要:

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

这就是为什么"archive RPC"并不只是磁盘更大的普通节点。在生产规模下,服务提供商通常会通过独立的存储和查询系统来提供 archive RPC 服务,并以熟悉的 RPC 接口呈现出来。

在 Alchemy,我们直接经历过这一限制。我们最初使用 Google Bigtable 存储 Solana 历史数据,后来重建了基于自托管 HBase 的归档技术栈。如今,每条记录都会被写入两次,通过程序化方式验证,并进行完整性扫描。当系统发现缺口时,会重新摄取缺失的条目。像 getTransaction 和 getSignaturesForAddress 这样的历史方法,现在从这个经过优化的数据层读取数据,而不再依赖实时 RPC 节点集群的本地保留数据,从而提供客户所期望的速度和可靠性。

为什么 getProgramAccounts 开销很大?

getProgramAccounts 展示了另一种限制。账户数据确实存在于当前状态中,但要回答该请求,可能需要在查询时搜索一大批账户并应用过滤条件。

节点存储账户主要是为了重放区块和维护当前链状态,它并不是一个通用的分析型数据库。偶尔进行直接扫描或许可以接受,但在生产流量下反复扫描数百万个账户会变得缓慢且消耗大量资源。

对于持续性的工作负载,运营者可以持续消费账户更新,并维护便于查询的索引或缓存视图。这样一来,请求读取的是预先准备好的结果,而不必每次都重复一次完整扫描。

反复发起的 getProgramAccounts 请求是一个索引问题,而不是需要更大节点的问题。换句话说,区别不在于"小节点还是大节点",而在于是实时节点数据服务,还是索引数据服务。

Geyser 和 gRPC 流式传输是如何工作的?

交易系统、索引器和其他实时应用通常需要在账户、交易、slot 或区块更新发生时对其进行处理。

WebSocket 订阅是 Solana 标准接口的一部分,适用于部分选定的实时事件。对于需要更低延迟、更高吞吐量或更丰富过滤能力的工作负载,Yellowstone gRPC 提供了一个基于 HTTP/2 上的 gRPC 构建的、性能更高的流式接口。

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

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

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

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

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

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

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

运营 Solana 基础设施需要什么?

当前的 Agave 硬件指导 给出了一个较高的起点,而这还没有考虑生产流量、冗余以及配套数据系统。

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

如何运行一个 Solana 节点?

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

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

有关最新的验证者命令和参数或 RPC 节点搭建,请使用官方持续维护的 Agave 指南。

应该如何评估 Solana 基础设施服务提供商?

先明确你的应用需要哪些工作负载,再询问服务提供商如何服务其中的每一项。

对你的应用将要使用的方法、订阅和地区进行基准测试。Solana RPC 服务提供商指南按照这些标准对当前的各类选项进行了比较。

结论

一个 Solana 应用并不需要抽象意义上的"一个节点"。它需要的是具体的能力:实时状态、交易 API、历史记录、索引查询、流式数据,或者在少数情况下,还需要共识参与。

先识别出这些工作负载,再决定技术栈中哪些部分由内部运营能带来真正的优势,哪些部分更适合从托管服务获取。

使用 Alchemy 在 Solana 上构建

大多数应用团队并不需要自行运营 RPC 节点集群、归档数据库、索引和流式基础设施。我们提供用于状态和交易查询的实时 Solana RPC、通过标准方法从创世区块开始的区块和交易历史记录,以及兼容 Yellowstone 的 gRPC 实时流服务。

开始在 Solana 上构建、参考 Solana API 快速入门,或联系我们的团队了解专属容量和自定义工作负载。

常见问题

什么是 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 节点,还是使用服务提供商?

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