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

大多数生产环境的工作负载在共享区块链 RPC 基础设施 上运行良好。但仍有一小部分无法满足需求：某交易台与 sequencer（rollup 的交易排序服务）之间的往返延迟决定了其订单能否落入下一个区块；某安全公司的模拟引擎需要运行一个自定义 EVM 追踪器，而任何共享服务商都不会托管这种追踪器；某受监管的金融科技公司的合规团队不会批准与其他客户的工作负载共享硬件。

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

Dedicated 是同样的基础设施，但只为一个租户提供服务。相同的 RPC 技术栈、相同的数据服务、相同的 API，但容量、主机和运行时都归你所有。像 Blockaid 这样的团队使用 Alchemy Dedicated Clusters 来保护超过 3120 亿美元的资产,满足其客户所要求的性能和一致性。

正是这种区别,使得 dedicated 对一小部分工作负载来说物有所值,也使得 shared 成为其他所有人的正确默认选择。值得思考的问题不是 dedicated 是否更好,而是你的工作负载是否已经超出了 shared 基础设施的设计范围。

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

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

一个典型的集群包括:

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

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

什么时候工作负载需要专属基础设施?

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

自定义追踪器和二进制文件

EVM 追踪器是用于检测交易执行过程的函数,可提取内部调用轨迹、存储读取、结构化日志和回滚原因。标准追踪器,例如 callTracer 和 prestateTracer,能覆盖大部分分析需求。而安全工具、模拟引擎和取证平台需要更多:与其内部模式匹配的自定义 JavaScript 追踪器,或经过修改、能暴露共享服务商从不开放的执行状态的 geth 和 erigon 二进制文件。

在共享主机上运行这些追踪器,对主机和租户而言都不安全。这正是模拟和安全服务商运行专属集群的原因。

区域绑定延迟

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

高频交易、预言机数据源以及 MEV 搜索者(通过交易排序方式提取价值的机器人)正是在这些差距上展开竞争。专属集群让客户可以将节点池部署在与 sequencer 或消费方相同的区域。

监管隔离

一些合规框架要求使用单租户计算资源。围绕客户数据隔离的 SOC 2 Type II 控制项、特定的银行与券商监管制度,以及大型金融机构内部的风险审查,往往都指向同一个要求:不应有其他客户的工作负载运行在同一主机上。

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

无上限的查询范围

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

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

一份便捷的决策参考:

如果某个工作负载不符合以上四种专属场景中的任何一种,那么共享基础设施几乎总是更便宜、更简单、上线更快的选择。

专属集群是如何工作的?

专属集群的架构可以归结为六个选择:还有谁在同一台机器上运行、机器部署在哪里、部署多少台、如何就状态达成一致、运行什么软件,以及如何计费。

单租户隔离

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

隔离带来的实际意义在于它排除了什么。共享主机上的"吵闹邻居"无法拖累客户的尾部延迟,因为根本没有邻居;来自其他租户的旁路信道泄露也无法触及客户的进程;合规审查人员可以直接指向一项有文档记录的控制措施,而不是仅凭"我们相信服务商会把工作负载分隔开"。

区域部署

客户端到 RPC 节点的延迟受网络距离限制。对大多数应用流量来说,这一点是感知不到的。但对于频繁发出延迟敏感型请求的工作负载而言,让节点更靠近技术栈、用户、sequencer 或验证者,可能就是产品具备竞争力与运行迟缓之间的差别。

我们服务 197 个国家的客户,Dedicated Clusters 让你把节点池部署在工作负载需要的区域,无论是按主要用户所在地区各部署一个集群,还是与特定 rollup 的 sequencer 同地部署一个集群。这需要权衡运维成本:区域越多,需要监控、打补丁和付费的集群也越多。大多数工作负载只需要一到两个区域。

N+1 冗余与故障转移

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

更棘手的问题是当负载超出集群能力时会发生什么。有两种真实场景会触发这种情况:链拥堵,即因为链上活动繁忙导致集群请求量激增;以及客户流量高峰,例如某次营销活动、某个事件或某项集成上线导致的流量激增。一个按稳态负载配置容量的集群在面临大规模流量高峰时可能会被限速。

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

区块级一致性

负载均衡池中的不同节点在几百毫秒内可能对最新区块产生分歧:最快的节点已看到区块 N,最慢的节点还停留在 N-1。对于查询余额的钱包来说,这察觉不到;但对于通过不同节点两次读取同一区块、却获得不一致状态的交易机器人来说,这是一个真实的 bug。

区块级一致性意味着集群在整个节点池中返回一致的链状态视图,使有状态的客户端不会读到过时或冲突的数据。这样做的代价是集群需要在正确性和速度之间同时优化,这对于依据最新链状态做出决策的工作负载尤为重要。

自定义追踪器和二进制文件

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

模拟、取证和分析类产品正是建立在这种能力之上,其价值来自提取标准追踪器接口无法暴露的执行状态。没有专属运行时,这类产品就无从存在。

基于容量的定价

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

这种模式适合具有可预测峰值负载、且在按请求计费下会以规模消耗大量共享计算单元的工作负载。在专属集群上,额外一次请求的边际成本为零,直到工作负载达到集群上限。超过某个针对特定工作负载的阈值后,基于容量的定价甚至在计入专属模式解锁的其他能力之前,就可能比按请求计费更便宜。

什么时候 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,几分钟内即可开始发送请求。

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

Dedicated 集群是同样的基础设施,只是专门针对你的工作负载。如果 shared 基础设施能满足需求,就继续使用 shared。如果你的工作负载恰好是少数无法满足需求的那一类,联系我们的团队。

常见问题

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

共享 RPC 在一套托管集群上运行众多客户,而专属区块链基础设施则为单一工作负载预留运行时、容量和数据路径。API 接口可以保持不变,但 dedicated 额外提供单租户隔离、自定义运行时选项、区域化部署以及基于容量的定价。

可以在专属 Ethereum 节点上运行自定义追踪器吗?

可以。专属集群是单租户的,因此可以运行共享端点无法托管的自定义追踪器。除了标准的 callTracer 和 prestateTracer,专属运行时还允许部署你自己的 JavaScript 追踪器,或经过修改的 geth 或 erigon 二进制文件,以暴露标准接口不提供的执行状态。这正是安全、模拟和取证团队运行 dedicated 的原因。他们的产品依赖于共享基础设施在全局锁定的追踪能力。

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

不总是。私有 RPC 端点可以指共享基础设施上针对客户的专用 URL 或访问策略。专属基础设施则更进一步:节点池及其支撑运行时都专门为单一客户的工作负载预留。

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

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

Dedicated 和 shared 基础设施可以同时运行吗?

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

专属集群的定价是怎样计算的?

专属集群的定价基于预置容量,而非按请求使用量计算。具体价格取决于所选的链、节点类型、吞吐量、区域以及所包含的能力。对于持续高负载的工作负载而言,固定容量定价可能比按请求计费更容易预估成本。

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

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