Solana RPC 2.0：加速读取，开启下一轮竞争

Solana 主网 beta 于 2020 年上线。早期，Solana 基金会自己在谷歌云上运行公共 RPC。这是一个务实的快速推进选择，但并未持久。Solana RPC 是重负载任务，需要数百 GB 的内存、多个高速 NVMe 硬盘以及高带宽网络。

谷歌云在 Solana 所需的规模下既昂贵又运营痛苦。将链历史存储在谷歌的 BigTable 中使得账单随时间推移变得更加糟糕，因为一旦 RPC 开始在其他地方运行，从谷歌网络拉取数据的出站成本急剧攀升。

就在那时，@triton_one 介入并向基金会提出了将主网 RPC 从谷歌云迁移到一小批裸机服务器（他们自己拥有并运营的物理机器，而不是租用云容量）的想法，最初是六台。那次交接既是 Triton 的创立，也是 Solana 上商业 RPC 生态系统的创立。

读取层问题

这一举措解决了运营上的痛苦，但并未解决更深层次的问题。每个 Solana 应用程序都通过 RPC 从链上读取数据。你的钱包检查余额，浏览器查询交易，DEX 显示价格，所有这些都经过同一层。这个介于应用程序和链之间的层就是人们所说的读取层。

问题在于，从一开始，读取层就被强行附加到了验证器上。同一软件同时运行两个任务：一边是共识，另一边是应用程序查询。后来出现的每一个问题（慢查询、验证器崩溃、闭源的临时解决方案）都追溯到了最初的设计。

在上一篇文章中，我们阐述了为什么读取层不断崩溃以及它是如何被修补的。Geyser、Yellowstone、Block Machine、Old Faithful，每一个都修复了问题的一部分，但没有一个触及根本问题，即验证器和读取层从未分开。真正的解决方案是 RPC 2.0。https://x.com/solana/status/2044058449298792557?s=20。RPC 节点就是一个包裹着查询层的验证器。两个任务运行在同一个二进制程序中，共享相同的 CPU、内存和磁盘。当查询流量激增时，验证器在共识工作上就会落后。商业提供商 Triton、QuickNode 和 Helius 多年前就意识到了这一点，并在自己的架构中打破了单体结构，但所有这些工作都是在闭源环境下进行的。Solana 最终形成了一个两级生态系统：付费客户获得了现代基础设施，而社区则得到了原始的 Agave 单体。RPC 2.0 是开源版本。Solana 基金会发布了一份征求建议书，寻求一种新的 RPC 堆栈，将读取操作从验证器中分离出来，并以社区能够实际使用的、足够公开的形式交付。Triton 赢得了构建账户模块和历史存档模块的资助。这同时解决了两件事：单体结构的技术问题，以及让社区落后付费提供商多年的开源差距。

RPC 2.0 将读取分为两个模块，因为 Solana 的读取分为两种类型：当前状态和历史。

账户模块

账户模块是 RPC 2.0 的一部分，负责回答关于当前状态的问题：

• 这个钱包里现在有什么？
• 这个地址持有哪些代币？
• 这个程序有哪些账户？

今天，要回答这些问题，RPC 节点会进行暴力扫描。每当一个应用程序调用 getProgramAccounts，节点就会遍历其存储的每一个账户，并针对过滤器检查每一个账户。在一个拥有数亿个账户的链上，这种扫描需要几秒钟。这就是与 Serum 和 Candy Machine 相关的查询不断导致验证器崩溃的原因，也是提供商最终不得不限制 getProgramAccounts 调用以维持其基础设施稳定的原因。

账户模块如何解决这一问题

账户模块用索引查找取代了扫描。索引是捷径：无需遍历整个数据集，数据库已经知道去哪里查找。

这仅在模块始终拥有链的完整图景时才有效。数据来自两个地方：

• 通过 Yellowstone gRPC 的实时更新。Yellowstone 在数据发生变化的那一刻直接从验证器中传输出来：验证器处理新区块时，会立即推送每个账户的更新。账户模块订阅该流。无需轮询，无需等待。
• 用于冷启动的快照加载器。仅靠实时流是不够的——当模块首次启动时是空的，并且无法了解在此之前存在的账户。快照加载器在启动时读取完整的 Solana 快照，本质上是该时刻链上每个账户的完整转储。此后，Yellowstone 接管。模块永远不会是不完整的。

所有数据都存储在 PostgreSQL 中，它可以在从笔记本电脑到云部署的任何地方运行，而且每个后端工程师都知道如何使用它。未来的迭代将允许团队插入其他后端。

模块如何自行实现快速查询

查询跟踪器会根据你的应用程序实际使用模块的方式自动构建索引。通常，数据库会要求你提前规划索引：你预测应用程序的查询模式，为其构建索引，并在应用程序增长时维护它们。在 Solana 上，这尤其困难，因为链产生数据的速度如此之快且不可预测，以至于提前规划几乎是不可能的。

查询跟踪器替你承担了这项工作。循环如下：

• 它监视你的应用程序向模块请求的内容
• 当相同的查询不断出现时，它会在后台悄然为该模式创建索引
• 下次该查询到来时，它会命中预构建的索引，而不是触发扫描
• 答案立即返回

你无需配置任何东西。模块会根据你的使用方式学习并进行自我调优。

从一开始就内置了一个快捷方式：代币查询。"这个地址持有哪些代币"是 Solana 上最常见的问题，每个钱包、投资组合追踪器和 DEX 都在不断询问。因此，模块已经内置了代币索引，这些查询从第一秒开始就是快速的。

开发者如何仅运行他们所需的数据

普通的 RPC 节点必须跟踪 Solana 上的每个账户，因为它不知道应用程序会请求什么。即使是一个小型应用程序，最终也要为存储数亿个它从未触碰过的账户的基础设施付费。

账户模块扭转了这种情况。你告诉它你实际关心哪些程序，它只存储属于这些程序的账户。两个例子：

• 在 Jupiter 上构建？你只摄取与 Jupiter 相关的状态。
• 构建 NFT 浏览器？你只摄取由 NFT 程序拥有的账户。

这就是使该模块可以在笔记本电脑上使用的关键。一个只开发单个 dApp 的开发者不需要一台价值 20,000 美元、拥有 TB 级内存的服务器。他们可以针对应用程序触及的数据在本地运行整个模块，使用真实的索引状态而不是模拟数据进行开发，然后将相同的代码直接部署到生产环境中。

运行真实 Solana 基础设施的门槛从"商业 RPC 运营商"降到了"任何拥有可用机器的开发者"。

历史模块

历史模块是 RPC 2.0 的另一半。

• 账户模块回答"链现在是什么样"的问题。
• 历史模块回答"之前发生了什么"——过去的交易、签名、完整的钱包历史、任何已最终进入账本的数据。

目前 Solana 上最臭名昭著的问题是钱包历史。为了向用户展示他们的交易，应用程序首先向 RPC 请求签名 ID 列表，然后为每个签名单独调用以获取详细信息。200 笔交易，200 次调用。在 Solana 的规模下，这个问题在延迟和 RPC 账单两方面都急剧增长。

模块如何解决这一问题

一次调用即可在一次往返中返回包含所有详细信息的完整历史记录。该管道由三部分组成：摄取数据的数据摄取器、高效存储数据的 ClickHouse 以及快速提供查询的 API 层。

数据摄取器与源无关。它可以从以下来源拉取数据：

• Yellowstone gRPC，用于从验证器流出的实时数据
• BigTable，用于尚未迁移的旧历史数据
• Anza 的 Jetstreamer，用于更新的流式数据源

无论源是什么，它都会将所有内容解码为结构化行，并刷新到 ClickHouse，不进行任何过滤。

为什么选择 ClickHouse

ClickHouse 专为大规模不可变数据而构建，这正是链历史数据的特性。一旦交易最终确定，它就不会再改变。ClickHouse 将计算与存储分离，并能处理数万亿行数据而不会变慢。Triton 已经运行着两个超过 500TB 的 ClickHouse 实例，外加作为第三个独立副本的 Old Faithful。

关键设计选择：数据按应用程序实际查询的方式进行物理排序。数据布局本身即是索引，因此查询直接跳转到所需行，而无需扫描账本。

在 ClickHouse 之前，是一个无状态的 JSON-RPC 层，使用与应用程序已使用的相同方法和请求格式。最近的 slot 来自内存缓存，返回时间在亚毫秒级。较旧的历史数据来自 ClickHouse，返回时间在毫秒级。

工作组还提议了一个新的 JSON-RPC 方法 getTransactionsForAddress，它可以在一次调用中返回钱包的完整交易历史，无需循环。这正是彻底解决 N+1 问题的方法。

Solana 正向网络竞赛迈进

从宏观角度看，RPC 2.0 是一个网络项目。读取操作被从验证器中分离出来，以便数据可以在链和从中读取数据的应用程序之间移动，而不会让验证器本身成为瓶颈。一旦你开始从这个角度审视 Solana，那么 2026 年即将推出的其他功能就都说得通了。

在过去的几年里，Solana 的故事是关于计算的。每个版本都削减了计算单元，编译器变得更加紧凑，顶尖团队开始手写汇编代码。在链上更快意味着真正的收益。

这场竞赛基本结束了。下一场是关于数据移动的速度、数据移动的位置以及谁控制着管道。RPC 2.0 是读取层的组成部分。另外两项计划中的升级也指向了同样的转变：

• Alpenglow 将最终性从大约 12 秒缩短到约 150 毫秒。在这种速度下，仍然轮询 RPC 以获取更新的应用程序将无法跟上。跟上节奏的唯一方法是流式传输，即 RPC 在数据发生变化时立即推送数据。RPC 2.0 正是为此而构建的。而基于旧有单体 RPC 的应用程序则无法做到。
• MCP（多并发提议者） 允许多个验证器同时提议区块，而不是一次一个。验证器之间移动的数据量急剧增加，而公共互联网（许多验证器仍在使用它相互通信）从未为这种负载而生。

这正是 @doublezero 要填补的空白。

什么是 DoubleZero？

DoubleZero 是一个专为区块链验证器构建的私有光纤网络。像 Jump、Galaxy、RockawayX 和 Cumberland 这样的公司已经拥有端点位于世界各地数据中心的光纤电缆，其中很大一部分容量未被使用。DoubleZero 将这些闲置的光纤容量汇集到一个共享网络中。Solana 验证器接入该网络并直接相互通信，而不是通过常规的公共互联网路由它们的流量。

最大的技术突破是多播。想想今天的公共互联网是如何工作的：当领导验证器产生一个区块时，它必须一次一个连接地将该区块发送给每个其他验证器。如果有一千个验证器，那就需要一千次单独发送。速度慢、成本高且不平衡。DoubleZero 改变了这一点。领导验证器只发送一次区块，网络本身会复制该区块并同时将其传播到 DoubleZero 网络上的每个验证器。

大约 43% 的 Solana 质押量已经在 DoubleZero 上运行。Alpenglow 的新区块传播系统在设计时就假设了多播的存在，这意味着 DoubleZero 不是一个附带实验，而是 Alpenglow 为之构建的网络。一旦 MCP 上线，不在 DoubleZero 上的验证器将无法跟上新的流量模式。到那时，加入 DoubleZero 不再是可选的。

DoubleZero 最近还推出了一款名为 Edge 的产品。网络上的验证器将其领导碎片发布到一个信息流中，交易者付费订阅（使用 USDC），订阅收入的 32.5% 回流到发布碎片的验证器。除了更好的区块落地率之外，DoubleZero 上的验证器现在还能获得公共互联网上的验证器所没有的收入流。

这对验证器方面意味着什么

对大多数人来说，选择验证器并不是一个真正的决策。验证器之间没有太多差异化空间；它们在正常运行时间、佣金、性能上都非常接近，以至于这个选择对你的质押收益影响不大。每个验证器底层的网络层正在成为决定谁能更快落地区块、每个周期赚取更多收益的因素。过去验证器之间几个基点的差异正在变成真正的收益差距。

许多主要的 RPC 提供商，如 Triton 和 QuickNode，已经在运行自己的基础设施的同时运营着自己的验证器。最初这是一种对冲，一种保持与链紧密联系并控制自身质押经济学的方式。

大多数人并不自己选择验证器。他们使用流动性质押代币（LST），而 LST 替他们做选择。JitoSOL、mSOL、bnSOL、JupSOL、dzSOL。因此，哪些验证器网络连接良好的问题变成了哪些 LST 正在将质押量路由到它们的问题。

今天选择 LST 基本上是一个意识形态的决定。你质押在你信任的协议上，使用你已经使用的品牌。收益差异很小，以至于对大多数人来说，这个选择不会产生多大影响——所有主流 LST 的收益率相差都在一个百分点以内。一旦网络连接和其他差异化因素开始推动验证器收益，这种情况就会改变。你的 LST 将你的 SOL 路由到何处不再是一个次要细节，而是开始对你作为质押者的实际收益产生更大的影响。

从此刻开始领先的 LST 将是那些超越收取费用和传递收益的 LST。它们将利用其委托权力，将质押量推向运行正确软件、构建真实基础设施以及提供推动网络向前发展的服务的验证器。它们将使网络变得更好，而持有者将获得更多回报。

我们将在下周的文章中更详细地介绍 LST 以及它们如何适应这些即将到来的变化，敬请期待！

• 原文链接： x.com/raikucom/status/20...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～