提現於 3 月 18 日停滯 14 分鐘

1. 摘要

On 2026-03-18 between 14:08:22 UTC and 14:22:11 UTC,我們的一個以太坊熱錢包停止處理提現。 1,847 筆提現請求排隊 停滯 14 分鐘;錢包恢復後,所有交易均正常完成。客戶資金始終沒有處於風險之中,也沒有任何客戶被重複扣費。我們公開這份說明,是因為我們欠用戶一個交代。

2. 時間線

• 14:08:22 — 熱錢包 A 以 nonce 412,387 提交提現交易。
• 14:08:34 — 以太坊區塊 22,107,402 出塊;交易確認。
• 14:09:11 — 區塊 22,107,402 被重組(3 個區塊的重組,源於競爭性驗證者提案)。
• 14:09:18 — 交易回到內存池;我們的錢包守護進程仍認為它已確認(對重組通知緩存未命中)。
• 14:09:30 — 守護進程提交下一筆 nonce 為 412,388 的交易。內存池拒絕它:nonce 412,387 仍未完成。
• 14:09:30 → 14:22:00 — 守護進程每 30 秒重試一次,全部被拒。沒有告警觸發,因為守護進程將"nonce 過低"歸類為用戶錯誤,而非基礎設施錯誤。
• 14:22:00 — 值班工程師注意到交易儀表盤上的桑基圖顯示 ETH 提現 12 分鐘以上為零;發送告警。
• 14:22:11 — 手動重新廣播 nonce 412,387,清空隊列。

3. 根本原因

兩個原因:

1. 我們的鏈重組觀察服務與錢包守護進程運行在同一節點上。當守護進程開始針對被拒交易反覆重試時,觀察服務因 CPU 被佔用而餓死,大約 15 秒未能收到鏈重組通知。
2. 我們針對"錢包守護進程卡住"的告警規則基於提交次數,而非有效吞吐。當時提交一直在進行(也一直被拒),所以從計數上看一切正常。

4. 我們做了哪些改變

• 鏈重組觀察服務已遷移至獨立主機,並使用獨立的 JSON-RPC 連接。不再與守護進程共享 CPU。
• 告警從 submissions/min to effective_throughput / submissions。如果提交持續進行卻沒有任何交易被確認,該比率會跌至 0.1 以下,告警將在 60 秒內觸發。
• 提現隊列儀表盤新增了一個"nonce 卡住"小組件,對值班團隊與交易儀表盤一同可見。
• 操作手冊已更新,人工重廣播 nonce 改為需要兩名工程師簽字的 90 秒標準動作,不再是耗時 4 分鐘的臨時操作。

5. 影響與善意補償

1,847 筆提現平均被延遲 9 分鐘。我們對每一筆卡住的交易退還了網絡手續費(在受影響帳戶中合計約 4,200 美元),並向每位受影響客戶發放了一張可在下一次入金時使用的一次性費用豁免券。受影響客戶在事件解決後 90 分鐘內收到了相關郵件通知。

6. 我們堅持的做法

公開發佈事故覆盤的本能。我們本可以把這件事壓下來 — 直接受影響的客戶只有 1,847 名,鏈重組本身就足以為延遲提供"合理推諉",我們的 SOC 2 框架在此也並不強制要求披露。但選擇公開,意味着交易團隊會讀到、做市商會讀到,下一位值班工程師在掉進同一個陷阱之前也會讀到。