我们的节点基础设施

1st Node API 返回的每一条响应,都由我们自行部署和运维的硬件直接提供——链路中没有中间经销商,也没有你看不见的共享速率限制。以下是驱动整个集群的真实配置,以及我们为其设定并持续对标的指标。

< 40 ms
p50 RPC 延迟

同区域内的热缓存读取(eth_getBalance、eth_call)。

< 250 ms
p99 RPC 延迟

单区域高负载下的冷归档读取。

99.9%
可用性 SLO

按链统计的近 30 天滚动端点可用率。

Genesis
归档深度

归档层链路自区块 0 起的完整历史状态。

EU · US
区域节点

Anycast 路由至最近的健康副本。

N+1
冗余

每条链至少运行两个相互独立的节点。

节点集群与归档覆盖

归档节点运维成本高昂,因此覆盖范围往往是服务商悄悄偷工减料的地方。我们对每条链都如实标注:archive 表示自创世区块起的完整历史状态,full 表示不带深度 trace 的完整未剪枝节点。

客户端层级Trace 支持
EthereumETHErigon + Lighthousearchive
ArbitrumETHNitro (archive)archive
OptimismETHop-geth + op-nodearchive
BaseETHop-geth + op-nodearchive
PolygonPOLBor + Heimdallarchive
BNB Smart ChainBNBbsc-getharchive
AvalancheAVAXAvalancheGo (C-Chain)archive
BitcoinBTCBitcoin Core + txindexarchive
TRONTRXjava-tron (full)full
TONTONton-http-api + validatorarchive

我们如何运维

自有裸金属,而非经销转售

集群中的每个节点都是我们自行部署和运维的裸金属硬件。我们不代理任何托管式 RPC 服务商,因此在你的请求与链之间没有第三方,也不存在你无法察觉的共享速率限制。

真实归档,如实标注

归档节点成本高昂,许多服务商会悄悄剪枝历史数据,并对旧状态查询返回 404。我们声称提供完整归档之处即运行完整归档,凡属仅 full-node 层级的链路均予以标注,因此 trace 与历史状态查询要么正常可用,要么被明确记录为不可用。

默认冗余

每条链背后至少运行两个相互独立的节点,并配备健康检查驱动的故障切换。节点重新同步或主机故障时,流量会被引流至健康副本,客户端不会感知到任何中断。

实测数据,而非口头声称

延迟与可用性由外部探针持续采样,而非从状态页照抄。上述数字是我们为集群设定的目标,一旦被突破即触发告警。

我们如何测量

延迟分位数由外部探针持续采样:探针针对各区域端点发起具有代表性的读取请求;可用性则为每条链近 30 天内健康检查成功次数的滚动占比。上述数字是我们在被突破时会触发告警的 SLO 目标,而非一次性的最佳截图。

充值、拿密钥、上线。

自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵,简单调用很便宜。

获取 API 密钥