专属区块链基础设施的工作原理

大多数生产环境的工作负载在共享区块链RPC 基础设施上运行良好。但少数工作负载不行。比如某交易台,它到 sequencer(rollup 的交易排序服务)的往返延迟决定了订单能否被打包进下一个区块;某安全公司的模拟引擎需要运行自定义 EVM tracer,而任何共享服务商都不会托管;某受监管的金融科技公司,其合规团队不会批准与其他客户工作负载共享硬件。

对于这些工作负载,答案是专用区块链基础设施。

Dedicated 是同样的基础设施,只是范围限定为单一租户。相同的 RPC 技术栈,相同的数据服务,相同的 API,但容量、主机和运行时都是你独占的。像 Blockaid 这样的团队使用 Alchemy Dedicated Clusters,以其客户所需的性能和一致性保护了超过 3120 亿美元的资产。

这一区别正是 dedicated 对少数特定工作负载物有所值、而 shared 对其他所有人来说是正确默认选项的原因。真正值得问的问题不是 dedicated 是否更好,而是你的工作负载是否已经超出了 shared 基础设施的设计范围。

什么是专用区块链基础设施?

专用区块链基础设施是一个单租户的 RPC 和索引集群:一组区块链节点、路由基础设施和数据服务,运行在为单一工作负载保留的硬件上。默认情况下,其 API 接口与共享基础设施相同,因此现有集成无需修改代码即可迁移。定制是在这一接口基础上的扩展,而非替代:自定义 tracer 和二进制文件、可选地区,以及按容量计费而非按请求计费。

一个典型的集群包括:

• 一组该链的全节点,规模按客户的峰值请求速率加一个额外节点配置,以便在节点重启期间故障转移不会丢失流量,也就是所谓的 N+1 模式。
• 可选的存档节点,用于访问历史状态,提供从创世区块开始的完整状态,而不仅仅是近期区块。
• 位于节点池前端的边缘代理和负载均衡器,作为路由层,接收每一个请求并决定由哪个节点处理。
• 一套可观测性技术栈,通常是暴露节点健康状态、请求延迟和错误率的 Grafana 仪表盘。
• 一条通往共享基础设施的故障转移路径,用于应对集群未按此规模配置的流量峰值。

这套基础设施的形态与共享服务商内部运行的基础设施相同,区别在于租约:dedicated 意味着容量专属承诺给一个客户,运行时由该客户自行配置,数据路径不与任何其他客户的工作负载共享。

什么样的工作负载需要专用基础设施?

有四种工作负载模式会超出共享基础设施的能力范围。

自定义 tracer 和二进制文件

EVM tracer 是用于插桩交易执行的函数,它们提取内部调用轨迹、存储读取、struct log 和 revert 原因。标准 tracer,比如 callTracer 和 prestateTracer,能覆盖大多数分析场景。而安全工具、模拟引擎和取证平台需要更多:符合其内部 schema 的自定义 JavaScript tracer,或经过修改的 geth 和 erigon 二进制文件,后者能暴露共享服务商从不暴露的执行状态。

在共享主机上运行这些代码,对主机和租户来说都不安全。这也是模拟和安全类厂商运行专用集群的原因。

地区绑定的延迟

对于大多数应用流量而言,多几跳网络延迟是察觉不到的。但对于每秒发出数十次请求、并且在意每一次请求的工作负载来说,客户端、节点与 sequencer 之间的物理距离可能决定一笔交易能否及时上链。

高频交易、oracle 数据源,以及 MEV 搜索者(通过交易排序方式获利的机器人)正是在这些边际差异上竞争。专用集群让客户可以将节点池部署在与 sequencer 或消费者相同的地区。

监管隔离

一些合规框架要求单租户计算环境。SOC 2 Type II 中关于客户数据隔离的控制项、某些银行和券商监管制度,以及大型金融机构的内部风险审查,往往会归结到同一个要求:任何其他客户的工作负载都不应运行在同一台主机上。

共享基础设施的设计本身就是让多个客户运行在相同主机上,而专用基础设施不是。

无边界的查询范围

共享 RPC 服务商会限制 eth_getLogs 的查询范围,以保护集群免受查询轰炸的影响。这对于读取用户近期交易记录的钱包来说没有问题,也是为什么大多数分析类工作负载会路由到带索引的 Data API,而不是直接使用原始的 eth_getLogs。

但对于需要扫描大范围历史原始日志的浏览器、索引器和链上分析团队来说,这个限制就成了瓶颈。专用集群可以取消该限制,因为这个限制本身是为了保护其他租户,而在单租户集群上并没有其他租户需要保护。

一个简单的判断参考:

如果某个工作负载不符合这四种 dedicated 模式中的任何一种,共享基础设施几乎总是更便宜、更简单、上线更快的选择。

专用集群是如何运作的?

专用集群的架构归结为六个方面的选择:同一台机器上是否还有其他人在运行、机器部署在哪里、部署多少台、它们如何就状态达成一致、运行什么软件,以及如何计费。

单租户隔离

单租户意味着客户的节点运行在为该客户工作负载保留的计算资源上。实际操作中,合规审查通常要求提供工作负载隔离、访问控制、可审计性和密钥管理方面的文档。

隔离带来的实际意义在于它排除了什么:共享主机上的"嘈杂邻居"无法拖累客户的尾部延迟,因为根本没有邻居;其他租户的旁路信道泄漏也无法波及客户的进程;合规审查人员可以指向一份有据可查的控制措施,而不是"我们相信服务商会把工作负载隔离开"。

地区部署

客户端到 RPC 节点的延迟受网络距离约束。对于大多数应用流量而言,这一点感觉不到。但对于频繁发出延迟敏感请求的工作负载,将节点部署得更靠近技术栈、用户、sequencer 或验证者,可能就是产品有竞争力和产品迟缓之间的差别。

专用集群允许客户自行选择地区。常见模式是为每个主要用户地理区域部署一个集群,或者为特定 rollup 部署一个与其 sequencer 同地区的集群。这样做的代价是运维层面的:地区越多,需要监控、维护和付费的集群就越多。大多数工作负载只需要一到两个。

N+1 冗余与故障转移

专用集群运行的容量是客户目标容量加一个备用节点。如果任何节点出现降级或重启,流量会转移到备用节点上,客户不会察觉到任何异常。这就是 N+1 模式,是任何需要在单节点故障时维持可用性的服务的标准形态。

更棘手的问题是当负载超出集群承载能力时会发生什么。这有两种真实场景会触发:链拥堵,即由于链上活动繁忙导致集群请求量激增;以及客户流量激增,比如某次营销活动、某个事件或某个集成上线带来的流量。为稳态负载配置的集群,在遇到大流量峰值时可能会被限流。

对此有两种架构方案。一种是按峰值配置集群容量,这意味着大部分时间要为闲置容量付费。另一种是自动故障转移到共享基础设施:当集群饱和时,流量会溢出到服务商的共享集群,而不是返回 429 错误。客户使用的 API、认证方式和响应格式保持不变。故障转移是更高效的方案,但它要求专用基础设施服务商同时运营一流水准的共享基础设施。

区块级一致性

在一个负载均衡的节点池中,不同节点对最新区块的认知可能会有几百毫秒的差异——最快的节点看到的是区块 N,最慢的节点还停留在 N-1。对于查询余额的钱包来说,这察觉不到。但对于通过不同节点两次读取同一区块、却得到不一致状态的交易机器人来说,这就是一个真正的 bug。

区块级一致性(block-perfect consistency)意味着集群在整个节点池中返回一致的链上状态视图,使有状态的客户端不会读到陈旧或冲突的数据。其代价在于集群需要同时为正确性和速度进行优化,这在工作负载需要基于最新链上状态做决策时最为重要。

自定义 tracer 和二进制文件

在专用运行时环境中,客户可以运行自定义 JavaScript tracer、部署经过修补的 geth 版本、更换客户端,或者修改共享服务商全局固定的客户端配置。共享服务商无法开放这一能力,因为更改客户端版本或配置会影响主机上的每一个租户。

这正是模拟、取证和分析类产品所依赖的能力。这些产品的价值来自提取标准 tracer 接口无法暴露的执行状态。没有专用运行时环境,这类产品就无从谈起。

按容量计费

共享基础设施按请求计费,通常以每次调用的计算单元为单位,较重的方法会有倍数系数。专用基础设施按集群计费:无论客户发送多少请求,承诺容量对应的都是固定月费。

这种模式适合负载峰值可预测、否则会在规模化时大量消耗共享计算单元的工作负载。在专用集群上,只要工作负载没有触及集群上限,每多发一次请求的边际成本就是零。超过某个特定于工作负载的阈值后,按容量计费甚至在不考虑 dedicated 解锁的其他能力的情况下,也可能比按请求计费更便宜。

什么时候 shared 是正确的默认选择?

在 shared 和 dedicated 之间做选择时,有三点需要考虑。关于这些权衡的更深入分析,可参见我们关于如何在 Node RPC 与 Dedicated Clusters 之间做选择的概述文章。

Dedicated 本身并不会让 RPC 技术栈变得更快

底层的 RPC 技术栈是相同的,所以在空闲系统上做单次请求的基准测试并不能说明全部问题。当集群被部署得更靠近工作负载时,dedicated 能改善延迟;而在持续高负载下,当隔离性保护了 P99(最慢的 1% 请求)时,dedicated 能提升可预测性。

关于各服务商共享 RPC 性能的最新公开数据,可参见 Alchemy 的RPC 服务商基准测试。

多地区的 shared 可能比单地区的 dedicated 更抗打击

一次导致单地区集群宕机的区域性云服务中断,对于全球分布的共享集群来说几乎不会有影响。务实的部署方式是:在关键地区使用 dedicated,同时以 shared 作为全局默认方案。

四种模式的判断标准是严格的

如果工作负载不满足自定义运行时、地区要求、监管隔离或查询范围限制这四种情形中的任何一种,那么 shared 就是更便宜、更简单、通常也更可靠的选择。转向 dedicated 通常是被迫的选择,而不是偏好。

Alchemy 如何支持专用区块链基础设施?

大多数工作负载一开始就使用 shared,并且会一直用下去。我们的 RPC API 和 Data API 运行在与 dedicated 相同的 Cortex 平台上,提供免费额度,无需签约,也没有最低使用量要求。从控制台获取一个 API key,几分钟内就能开始发送请求。

当工作负载触及以上四种模式中的任何一种——自定义 tracer、地区要求、监管隔离或查询范围限制——Alchemy Dedicated Clusters 能在相同的基础设施上提供单租户容量。我们支持自定义 tracer 和二进制文件、地区化部署、带自动故障转移到 shared 的 N+1 冗余、区块级一致性、从第一天起就提供的 Grafana 仪表盘,以及面向受监管环境、符合 SOC 2 Type II 标准的基础设施。定价基于已配置的容量,而非按请求使用量计费,因此负载可预测的团队可以按固定月度基础设施成本进行规划。

Dedicated 集群是同样的基础设施,只是针对你的工作负载做了范围限定。如果 shared 基础设施能满足需求,就继续使用 shared。如果你的工作负载正是少数无法用 shared 满足的情况之一,联系我们的团队。

常见问题

专用区块链基础设施和共享 RPC 有什么区别?

共享 RPC 在一套托管集群上运行多个客户的流量。专用区块链基础设施则为单一工作负载保留运行时、容量和数据路径。API 接口可以保持不变,但 dedicated 增加了单租户隔离、自定义运行时选项、地区化部署以及按容量计费的方式。

专用基础设施和私有 RPC 端点是一回事吗?

不完全一样。私有 RPC 端点可能只是共享基础设施上针对客户的专属 URL 或访问策略。而专用基础设施则更进一步:节点池以及支撑运行时都专属于一个客户的工作负载。

什么情况下团队应该避免使用专用基础设施?

如果工作负载不需要自定义二进制文件、监管隔离、特定地区部署,或异常大范围的原始查询,就应避免使用专用基础设施。在这些情况下,共享 RPC 通常更简单、更便宜、弹性更好、上线也更快。

Dedicated 和 shared 基础设施可以同时使用吗?

可以。大多数使用 Dedicated Clusters 的团队采用混合方案:对有硬性要求的链或工作负载使用 dedicated,其余场景使用共享 RPC。由于两者的 API 一致,在两者之间迁移工作负载主要是端点和路由层面的决策。

专用集群的定价方式是怎样的?

专用集群按已配置的容量计费,而非按请求使用量。定价取决于链、节点类型、吞吐量、地区以及所包含的能力。对于持续高负载的工作负载而言,固定容量定价往往比按请求计费更易于预测。

专用集群的部署速度有多快?

部署所需时间取决于链、客户端、地区和配置需求。当需求较为标准时,一些集群可以很快部署完成。而更复杂的配置,比如自定义二进制文件、特殊硬件或新地区部署,则需要更多的规划时间。