Alchemy 扩展对 Stellar 的支持,推出 Data APIs 并迈向 Tier-1 验证节点

自从Alchemy 推出 Stellar 支持以来，我们提供 RPC、websocket 支持，以及和我们支持的每个网络一样的 99.99% 正常运行时间和 SOC 2 Type II 可靠性标准。今天这一覆盖范围在两个方向上深入：Alchemy 正在推进成为 Stellar 上的一级验证者，我们还新增了三个用于大规模读取 Stellar 数据的索引化 Data API。

我们正在 Stellar 上搭建一级验证：一组分布在不同地理位置的全节点验证者，它们参与共识、发布公开历史归档，并达到网络对正常运行时间和法定人数（quorum）质量的最高要求。一级验证者被包含在许多 quorum set 中，有助于支撑网络的韧性，这也是我们正在努力达到的标准。

在 RPC 和 websocket 之外，我们现在在主网和测试网上提供三个索引化的、以地址为中心的 Data API：转账历史、代币余额和 NFT 持仓。你传入一个地址和一个网络，就能得到索引好的历史记录或状态，无需自己运行索引器。这正是我们运营一整套集成基础设施所能为开发者提供的能力，也是数据从链上抵达单次查询结果的方式。

为什么运营链本身对读取链数据很重要

以生产规模读取 Stellar 数据本质上是一个索引问题。Soroban RPC 只能提供近期一小段区间的 ledger 数据。Horizon 能提供历史数据，但要回答一个像"这个账户收到过的所有资产"这样简单的问题，仍然需要翻阅大量的原始数据单元，并自行保持数据同步。多数团队最终只能自己运行一套索引器，仅仅为了支撑一个资产组合展示页面。

推进一级验证改变了我们解决这个问题所依赖的基础。一级验证组织运行全节点验证者并发布公开历史归档，这正是任何严肃的索引器都需要的那种持久、完整的 ledger 记录，也正是我们在 Stellar 上正在构建的基础设施。因此我们的 Data API 并不是第三方从外部抓取链数据的结果。它们运行在我们端到端自行运营的基础设施之上，基于和维持整个网络同步所用的同一种历史记录。验证、RPC、websocket 和 Data API 是同一套技术栈，在同一个 API key 之下，遵循同一套可靠性标准。

Stellar Data API 能做什么

接口设计得有意保持精简。每个方法接收一个账户地址和一个网络，返回原本需要你自己回填才能得到的索引化数据：

• 转账历史： 某地址的资产转移记录，以分页形式返回
• 代币余额： 某地址当前持有的资产余额，一次调用即可获取
• NFT 持仓： 某地址持有的 NFT，涵盖经典 Stellar 资产和 Stellar 智能合约（Soroban）代币两种类型。

你查询某个地址持有什么，或者做过什么，答案都是从索引好的历史记录中组装而来。具体的请求和响应字段参见 Stellar API quickstart。要记住的核心形态是：输入地址，输出索引化历史。

为什么 Stellar 需要定制化的 pipeline

通用的 EVM 索引器不适用于 Stellar。Stellar 的 ledger 有自己的结构：operation、payment、trustline 和经典资产。在此之上，Soroban 又带来了一套模型完全不同的智能合约代币。Stellar 上的 NFT 既可能是经典资产，也可能是 Soroban 合约代币，一个正确的持仓查询结果必须同时覆盖这两种情况。

因此这些 Data API 建立在一条专为这种模型打造的 pipeline 之上，共分四个阶段。

pipeline 的运作方式

起点是 Galexie，Stellar 网络官方的 ledger 导出工具。Galexie 将 ledger 元数据以有序分区的形式写入对象存储，这为链上数据提供了一个持久、可重放的真实来源，同时不会对节点造成压力。链上数据只需导出一次，下游的一切都从这些分区中读取。

一个针对 Stellar 定制的 ingestor 随后遍历这些分区，写入规范化的行数据。有两点使它具备对 Stellar 的适配性。其一，它运行统一的单一模型，而非分离的回填（backfill）和实时同步（frontfill）路径，因此历史数据追赶和保持最新是同一套代码，按每个分区已摄入的最高 ledger 编号做 checkpoint。其二，它以独立的工作负载运行：一个负责分类转账和余额，另一个独立的 NFT 分类器遍历相同的分区，解析经典资产和 Soroban 资产的持仓情况。worker 并行运行，并按网络独立扩缩容，因此主网和测试网的规模各自独立配置。

这些规范化数据最终写入一个专用的 Stellar ClickHouse 集群。ClickHouse 是一个为分析型读取而构建的列式数据库，这正好对应这些查询的特性：按地址过滤、扫描、聚合。为 Stellar 单独分配集群，隔离了它的查询负载，从而降低了跨网络的延迟。

Data API 服务从 ClickHouse 中读取数据，并通过与 Alchemy 其他所有链相同的网关、鉴权、限流和计算单元计费机制对外暴露。Stellar 不是一个拥有自己登录方式和特殊规则的独立系统，它只是同一个 API key 之下又一个网络。

一次请求是什么样子

这三个方法共享同一种形态。输入是一个地址加一个网络。输出是索引化的、分页的历史记录或状态，且已经解析为开发者所预期的资产模型，经典资产和 Soroban 资产统一呈现。调用方无需再做"这是最新数据还是历史数据"的判断，因为统一的摄入模型使得索引数据通常既是最新的，也是完整的。

这种一致性正是关键所在。集成了转账查询的团队，可以直接加入余额和 NFT 持仓查询，无需学习新的请求模式，同一个地址适用于所有三个方法。

Alchemy 目前为 Stellar 提供的能力

Stellar 作为一等公民网络运行在 Alchemy 上，与其他所有链共享同一个 API key 和工具链：

• 正在迈向一级验证的验证者基础设施，包括分布在不同地理位置的全节点验证者和公开历史归档
• 提供 99.99% 正常运行时间和全球冗余的 RPC 与 websocket 支持
• 主网和测试网上三个索引化 Data API，分别用于转账历史、代币余额和 NFT 持仓
• 经 SOC 2 Type II 认证的基础设施，已处理超过 1 万亿美元的链上交易

开始使用

• 创建一个 key，在控制台调用 Stellar 主网或测试网
• 在 Stellar API quickstart 中查找转账、余额和 NFT 方法的参考文档
• 如有更大规模需求或企业级需求，请联系我们

常见问题

Alchemy 是否运营自己的 Stellar 基础设施？

是的。Alchemy 正在 Stellar 上搭建一级验证，运行分布在不同地理位置的全节点验证者，参与共识并发布公开历史归档。RPC、websocket 和 Data API 都运行在同一套基础设施之上，因此你读取的 Stellar 数据来自一个参与网络运营的提供商，而非第三方索引器。

支持哪些网络？

Stellar 主网和测试网都支持。worker 按网络独立扩缩容，因此两者的规模各自独立配置，一个网络上的负载激增不会影响另一个网络。

我还需要运行自己的索引器吗？

不需要。这些 API 返回完整索引化的转账历史、余额和持仓数据，因此你无需运行 Galexie、维护回填流程，也无需为了支撑资产组合或历史记录展示而自己保持一份 ledger 数据副本的同步。

Soroban 代币是如何处理的？

一个专用的分类器会同时解析经典 Stellar 资产和 Soroban 智能合约代币的持仓情况，因此单次持仓查询就能同时反映这两种模型，无需你自己进行对账整合。

这和 Soroban RPC 或 Horizon 有什么不同？

Soroban RPC 只暴露近期一小段区间的 ledger 数据，Horizon 则以原始数据单元的形式返回历史数据，需要你自己组装。而 Data API 能在一次调用中，针对全部历史数据返回索引化的、以地址为中心的答案。