Bitget 如何借助 Alchemy 为 1.25 亿用户提供交易所服务

当加密交易所确认用户的充值是否真正上链时,容不得"大概"。Bitget 是一家服务超过 1.25 亿用户的全球交易所和 web3 生态系统。它将充值和提现验证视为关键的金融基础设施。为了消除这一环节中的单点故障,Bitget 接入了 Alchemy 业界领先的 RPC APIs。

方案:多层充值验证

Bitget 的大部分区块链读取请求运行在自建节点上,这让团队能够直接掌控核心基础设施。在涉及用户资金转移的流程上,Bitget 将这种掌控力与独立确认结合起来:通过第三方节点服务商交叉核验自有节点返回的数据,只有在多个数据源一致时才会确认充值到账。

随着业务规模扩大,Bitget 团队决定增强这一确认层的稳健性。两个因素决定了团队的需求:

• 自建全节点只保留近期较短时间范围内的区块,大约是最近 128 个区块,因此仅靠自建节点无法提供团队重建早期交易或从区块中提取内部交易所需的归档和溯源数据。
• 现有第三方服务商在流量高峰期会返回限流错误,而这恰恰是充值确认最关键的时刻。

为了在这两方面都提升标准,Bitget 接入了 Alchemy,看中的是其性能和可靠性,能够在 Bitget 最为敏感的业务流程上保持确认的快速与稳定。

方案:冗余、可靠的基础设施

Bitget 的架构刻意设计为冗余:自建节点承担大部分流量,两家独立的第三方服务商负责确认涉及用户资金的数据。整体分为三层:

独立验证层

Bitget 将充值和提现确认流量路由至 Alchemy,作为对自有节点的并行核验。当两个独立数据源结果一致时,交易所便可放心地确认充值到账。如果其中一个数据源受限或不同步,另一个仍能正常响应。正是这一层消除了 Bitget 想要解决的单一服务商风险。

归档与溯源层

由于 Bitget 自有节点只保留较短的区块窗口,团队依靠 Alchemy 的归档深度和溯源方法来重建交易细节并提取内部交易,使用的调用包括 trace_block、debug_traceBlockByNumber、eth_getBlockReceipts 和 eth_getLogs。这些数据是自建基础设施在结构上无法提供的。

多链覆盖层

Bitget 通过单一服务商验证一系列不断扩大的网络上的活动,包括 BNB Smart Chain、Bitcoin、Base、Arbitrum、zkSync 等,其中 Alchemy 的 Bitcoin API 支持覆盖了最难妥善运维的非 EVM 链。亚太地区的覆盖是决策考量的一部分,Alchemy 在东京的布局与 Bitget 流量的主要来源地相匹配。

结果:30 天内超过 2500 万次请求,零错误

在最近的 30 天窗口期内,Bitget 在 9 条网络上向 Alchemy 发送了超过 2500 万次请求。借助 Alchemy,Bitget 在充值验证上实现了更高的安全标准,使这一关键环节能够独立核验,而不再依赖任何单一节点数据源。

最终,Bitget 选择 Alchemy 是出于以下考虑:

• 链和地区覆盖: 一家服务商即可覆盖 EVM 链加 Bitcoin,包括自建节点无法提供的归档和溯源数据,以及贴近 Bitget 流量来源的亚太地区覆盖。
• 大规模下的可靠性: 在确认用户资金这一工作负载上,经数千万次请求验证过可靠性的服务商。
• 把复杂基础设施做好: 溯源和内部交易方法、Bitcoin RPC 以及高吞吐量支持——这些都是自建节点基础设施中难以运维的部分。
• 文档和支持: 在评估和集成过程中建立了直接、响应迅速的合作关系。

在 Bitget 用来验证用户资金的同一套区块链基础设施上构建你的应用。立即开始,或 联系我们的团队。