你的应用总会遇上「冻结」,提前把它设计进去
来源:dev.to — 2026-11-05
📋 概述
上周币安在约二十分钟内损失约 63 亿美元,几小时内稳定币发行方冻结了其中约 30 亿美元,币安暂停了所有人的提现,链上分析公司则公开标记了攻击者的比特币钱包。作者认为大多数开发者不会运营这么大的交易所,但几乎每个加密应用都会碰到这几套机制之一:热钱包、带黑名单的稳定币、来自被标记地址的充值、「提现已暂停」的横幅,而每一种都是产品必须刻意设计处理的状态。他给出几条工程建议:定时检查热钱包是否被 EIP-7702 委托(委托账户的代码前缀固定为 0xef0100),一变就告警;付款前先查发行方黑名单(USDC 叫 isBlacklisted,USDT 叫 isBlackListed,只差一个字母),查不到就退回用 eth_call 模拟转账并把 revert 当作此刻不可付;把被污染充值当成正常状态处理,给用户明确提示而不是通用失败;并让冻结期的界面文案可解释。
🔑 核心要点
- 63 亿美元在二十分钟内消失,随后约 30 亿美元被发行方冻结、提现被暂停——冻结是常态而非异常。
- EIP-7702 让外部账户指向合约代码,前缀固定为 0xef0100,所以热钱包是否被委托用一次 getCode 就能查。
- 黑名单函数名只差一个字母:USDC 是 isBlacklisted,USDT 是 isBlackListed,写错就永远查不到。
- 查不到黑名单时退回 eth_call 模拟转账,把 revert 当成「此刻不可付」。
- 面向用户要说人话:「这个地址无法接收 USDT」胜过通用失败提示,更胜过一次卡住的提现。
💡 金句
“If your app sends stablecoins, an address can become unpayable at any moment.”
译:如果你的应用会发稳定币,那么任何一个地址都可能在某一刻变得无法收款。
👍 0
👎 0
← 返回 dev.to 首页