从清算风暴到云宕机：加密基础设施的危机时刻
原文标题：Crypto Infrastructure is Far From Perfect
原文作者：YQ，加密 KOL
原文编译：AididiaoJP，Foresight News
亚马逊网络服务再次遭遇重大中断，严重影响了加密基础设施。美国东一区域（北弗吉尼亚数据中心）的 AWS 问题导致 Coinbase 以及包括 Robinhood、Infura、Base 和 Solana 在内的数十个其他主要加密平台瘫痪。
AWS 已承认影响 Amazon DynamoDB 和 EC2 的「错误率增加」，这是数千家公司所依赖的核心数据库和计算服务。这次中断为本文的中心论点提供了即时、鲜明的验证：加密基础设施对中心化云服务提供商的依赖造成了系统性漏洞，这些漏洞在压力下反复显现。
这个时机具有严峻的启发性。就在 193 亿美元的清算连锁事件暴露了交易平台层面的基础设施故障十天后，今天的 AWS 中断表明问题已超出单个平台，延伸至基础性的云基础设施层。当 AWS 出现故障时，级联影响会同时波及中心化交易平台、具有中心化依赖的「去中心化」平台以及无数其他服务。
这不是孤立事件，而是一种模式。以下分析记录了 2025 年 4 月、2021 年 12 月和 2017 年 3 月发生的类似 AWS 中断事件，每次都导致主要加密服务瘫痪。问题不在于下一次基础设施故障是否会发生，而在于何时发生以及触发因素是什么。
基础设施过载与速率限制
交易平台 API 实施速率限制以防止滥用和管理服务器负载。在正常操作期间，这些限制允许合法交易同时阻止潜在攻击。在极端波动期间，当成千上万的交易者同时尝试调整头寸时，这些相同的速率限制就成了瓶颈。
CEX 将清算通知限制为每秒一个订单，即使在每秒处理数千个订单时也是如此。在 10 月的连锁事件期间，这造成了不透明。用户无法确定实时的连锁严重程度。第三方监控工具显示每分钟有数百次清算，而官方数据源显示的要少得多。
API 速率限制阻止了交易者在关键的第一小时内修改头寸，连接请求超时，订单提交失败。止损单未能执行，头寸查询返回过时数据，这种基础设施瓶颈将市场事件转变成了运营危机。
传统交易平台为正常负载加上安全余量来配置基础设施。但正常负载与压力负载截然不同，日均交易量无法很好地预测峰值压力需求。在连锁事件期间，交易量激增 100 倍或更多，对头寸数据的查询增加 1000 倍，因为每个用户同时检查其账户。
自动扩展的云基础设施有所帮助，但无法即时响应，启动额外的数据库读取副本需要数分钟。创建新的 API 网关实例需要数分钟。在那几分钟内，保证金系统继续基于来自过载订单簿的损坏价格数据来标记头寸价值。
链上故障：区块链协议的局限性
条形图比较了不同事件中的停机时间：
· Solana（2024 年 2 月）：5 小时 - 投票吞吐量瓶颈
· Polygon（2024 年 3 月）：11 小时 - 验证器版本不匹配
· Optimism（2024 年 6 月）：2.5 小时 - 定序器过载（空投）
· Solana（2024 年 9 月）：4.5 小时 - 交易垃圾邮件攻击
· Arbitrum（2024 年 12 月）：1.5 小时 - RPC 提供商故障
Layer 2：定序器瓶颈
但 Layer 2 解决方案引入了新的瓶颈。Optimism 在 2024 年 6 月当 25 万个地址同时申领空投时经历了一次中断。定序器在将交易提交给以太坊之前对交易进行排序的组件不堪重负，用户有几个小时无法提交交易。
这次中断表明，将计算移至链下并不能消除基础设施需求。定序器必须处理传入交易，对它们进行排序，执行它们，并为以太坊结算生成欺诈证明或 ZK 证明。在极端流量下，定序器面临着与独立区块链相同的扩展挑战。
必须保持多个 RPC 提供商的可用性。如果主提供商故障，用户应无缝故障转移到备选方案。在 Optimism 中断期间，一些 RPC 提供商保持功能，而其他则故障。钱包默认连接到故障提供商的用户无法与链交互，即使链本身仍然在线。
AWS 中断已反复证明加密生态系统中存在集中的基础设施风险：
· 2025 年 10 月 20 日（今日）：美国东一区域中断影响 Coinbase，以及 Venmo、Robinhood 和 Chime。AWS 承认 DynamoDB 和 EC2 服务错误率增加。
· 2025 年 4 月：区域性中断同时影响币安、KuCoin 和 MEXC。当其 AWS 托管的组件故障时，多个主要交易所变得不可用。
· 2021 年 12 月：美国东一区域中断导致 Coinbase、Binance.US 以及「去中心化」交易平台 dYdX 瘫痪 8-9 小时，同时影响亚马逊自己的仓库和主要流媒体服务。
· 2017 年 3 月：S3 中断阻止用户登录 Coinbase 和 GDAX 达五小时，同时伴有广泛的互联网中断。
模式很清楚：这些交易平台在 AWS 基础设施上托管关键组件。当 AWS 经历区域性中断时，多个主要交易平台和服务同时变得不可用。用户在中断期间无法访问资金、执行交易或修改头寸，而这恰恰是市场波动可能要求立即采取行动的时候。
扩展仍然是根本问题
这些事件揭示了一个一致的模式：系统为正常负载配置资源，然后在压力下灾难性地失败。Solana 有效处理了常规流量，但在交易量增加 10,000% 时崩溃。以太坊 Gas 费保持合理，直到 DeFi 采用引发拥堵。Optimism 的基础设施运行良好，直到 25 万个地址同时申领空投。币安的 API 在正常交易期间功能正常，但在清算连锁期间受到限制。
2025 年 10 月的事件在交易所层面展示了这种动态。在正常操作期间，币安的 API 速率限制和数据库连接足够，但在清算连锁期间，当每个交易者同时尝试调整头寸时，这些限制就成了瓶颈。旨在通过强制清算保护交易所的保证金系统，通过在最糟糕的时刻创造强制卖方，放大了危机。
自动扩展对阶跃函数式的负载增加提供的保护不足。启动额外的服务器需要数分钟，在那几分钟内，保证金系统基于来自稀薄订单簿的损坏价格数据来标记头寸价值，等到新容量上线时，连锁反应已经传播。
为罕见的压力事件过度配置资源在正常操作期间耗费资金。交易所运营商为典型负载进行优化，接受偶尔的故障作为经济上合理的选择。停机的成本外部化给用户，他们在关键市场变动期间经历清算、交易卡住或无法访问资金。
