Sui公链事件引发行业反思:1.6亿美元挑战区块链底层共识

关于Sui公链事件的深度反思

前言

近期发生的事件揭示了资本的胜利,而非用户的利益。这对行业发展而言可能是一种倒退。

比特币与Sui的发展方向呈现出鲜明对比,每当出现动摇去中心化的行业举动时,人们对比特币的信仰就会愈发强烈。

世界需要的不仅仅是更好的全球化金融基础设施,更需要始终为一部分人保留自由空间。

回顾历史,曾经联盟链比公链更受欢迎,主要是因为它符合当时的监管需求。如今联盟链的式微,恰恰说明单纯遵从监管需求并不能满足真实用户的需求。失去了被监管的用户,监管工具也就失去了存在的意义。

1. 事件背景

2025年5月22日,某公链生态中最大的去中心化交易所遭遇黑客攻击,导致流动性急剧下降,多个交易对价格崩塌,损失超过2.2亿美元。

事件主要时间线如下:

  • 5月22日上午:黑客攻击导致2.3亿美元损失,交易所紧急暂停合约并发布公告
  • 5月22日下午:黑客跨链转移约6000万美元,剩余1.62亿美元仍在原链上
  • 5月22日晚间:官方确认资金已被冻结,准备开始归还流程
  • 5月23日:交易所开始修复漏洞并更新合约
  • 5月24日:公链开源PR,解释将通过别名机制与白名单进行资金回收
  • 5月26日:启动链上治理投票,提议是否执行协议升级、将黑客资产转至托管地址
  • 5月29日:投票结果公布,超过2/3验证节点权重支持
  • 5月30日-6月初:协议升级生效,指定交易哈希被执行,黑客资产被转移

2. 攻击原理

攻击主要利用了交易所智能合约中的整数溢出漏洞。攻击者首先通过闪电贷借出大量代币,导致交易池价格暴跌99.90%。随后,攻击者在极窄的价格区间内创建流动性头寸。

攻击核心在于交易所用于计算所需代币数量的函数存在整数溢出问题。攻击者声称添加巨额流动性,但实际只投入少量代币。由于溢出检测条件错误,系统严重低估了所需代币数量,使攻击者以极低成本获得了巨量流动性。

技术上,这个漏洞源于智能合约中使用了错误的掩码和判断条件,导致大量值都能绕过检测。左移操作后高位数据被截断,系统只收取极少代币就认为获得了巨大流动性。

事件发生后,官方采取了"冻结"和"追回"两个阶段的应对措施:

  • 冻结阶段:通过拒绝列表和节点共识完成
  • 追回阶段:需要链上协议升级、社区投票和执行指定交易绕过黑名单

3. 公链的冻结机制

该公链内部存在特殊的拒绝列表机制,实现了本次黑客资金冻结。此外,其代币标准也有"受监管代币"模式,带有内置冻结功能。

此次应急冻结利用了这一特性:验证者节点在本地配置文件中快速添加了被盗资金相关地址。理论上每个节点运营者都可以自行修改配置更新黑名单,但为确保网络一致性,基金会作为最初的配置发布方进行了集中协调。

基金会首先官方发布含黑客地址的配置更新,验证者按默认配置同步生效,从而让黑客资金在链上暂时被"封印"。这背后实际上存在高度的集中化因素。

为从冻结资金中解救受害者,公链团队随后推出了白名单机制补丁。这允许将特定交易预先加入"免检名单",使这些交易可以跳过所有安全检查,包括签名、权限、黑名单等。

需要注意的是,白名单补丁并不能直接转移黑客资产;它只是赋予某些交易绕开冻结的能力,真正的资产转移仍需合法签名或额外系统权限模块来完成。

相比之下,行业主流的冻结方案往往发生在代币合约层面,且由发行方多签控制。以某稳定币为例,其合约内置黑名单函数,发行公司可将违规地址冻结。这种方案需要多重签名在链上发起冻结请求,多签达成一致后才真正执行,因而存在执行延迟。

虽然这种冻结机制有效,但统计表明多签流程常会出现"空窗期",给不法分子留下可乘之机。

相比之下,本次事件中的冻结发生在底层协议级别,由验证者节点集体操作,执行速度远快于普通合约调用。这套模式下,要执行得够快,就意味着这些验证者节点本身的管理是高度统一的。

4. 公链的"转账式回收"实现原理

更令人惊讶的是,该公链不仅冻结了黑客资产,还计划通过链上升级"转移回收"被盗资金。

5月27日,交易所提出社区投票方案,要求对协议进行升级,将被冻结的资金发送到多重签名托管钱包中。基金会随即发起链上治理投票。

5月29日,公布投票结果,约90.9%权重的验证者支持该方案。官方宣布,一旦提案通过,"所有在两个黑客账户中被冻结的资金将无需黑客签名而被一并收回到一个多签钱包"。

无需黑客签名,这是区块链行业前所未有的修复方式。

从官方的GitHub PR可知,协议引入了地址别名机制。升级内容包括:在协议配置中预先指定别名规则,使得某些允许的交易可以将合法签名视作来自黑客账户发送。

具体来说,将要执行的救援交易哈希列表与目标地址(即黑客地址)绑定,任何签署并发布这些固定交易摘要的执行者都被视为有效的黑客地址拥有者发起了交易。对这些特定交易,验证者节点系统会绕过拒绝列表检查。

从代码层面看,公链在交易验证逻辑中加入了新的判断:当一笔交易被黑名单拦截后,系统遍历其签名者,检查是否满足别名规则。只要存在某个签名者满足条件,即标记这笔交易被允许通过,忽略之前的拦截错误,继续正常打包执行。

5. 观点

1.6亿美元,撕开了行业最深的底层信仰

这次事件虽然风波可能很快过去,但其采用的模式不会被遗忘,因为它颠覆了行业基础,也打破了区块链在同一套账本下不可篡改的传统共识。

在区块链设计中,合约就是法律,代码就是裁判。但这次事件中,代码失效,治理干预,权力凌驾,形成了"投票行为裁决代码结果"的模式。

正是因为该公链此次直接挪用交易的做法,与主流区块链处理黑客问题的方式存在巨大差异。

这不是第一次"篡改共识",但却是最静默的一次

从历史上看:

某公链2016年因重大事件曾通过硬分叉回滚转账来弥补损失,但这一决定导致了链的分裂,过程备受争议,但最终由不同群体形成不同的共识信仰。

比特币社区同样经历过类似技术挑战:2010年的价值溢出漏洞被开发者紧急修复并升级共识规则,彻底抹除了约184亿枚非法生成的比特币。

这些都是采用硬分叉模式,将账本回滚到问题发生之前,然后用户可以自行决定在哪套账本体系下继续使用。

与之前的硬分叉相比,这次事件中公链没有选择分裂链条,而是通过协议升级加配置别名的方式精准针对本次事件。这样做保持了链的连续性和大部分共识规则不变,但同时也表明底层协议可以被用来实施针对性的"救援行动"。

问题在于,历史上的"分叉式回滚"是用户选择信仰;而这次的"协议式修正"是链替用户做了决定。

"非你所掌控的私钥,非你所有的币"这一理念在该公链上被瓦解:即便用户私钥完整,网络仍可通过集体协议变更来阻止资产流动并重定向资产。

如果这成为未来区块链应对大型安全事件的先例、乃至被认为是可以再次遵守的惯例,那么"当一条链能为了正义打破规则,它也就有了打破任何规则的前例。"

一旦有一次"公益抢钱"的成功,下次就可能是"道德模糊地带"的操作。

那会发生什么?

黑客确实偷了用户的钱,那么群体投票,就可以抢走他的钱吗?

投票依据的是谁的钱多还是人多呢?如果钱多者胜利,那刘慈欣笔下的终产者将很快到来;如果是人多者胜利,那么群体乌合之众也就声浪迭起。

在传统制度下,非法所得不受保护是非常正常的,冻结与划转都是传统银行的常规操作。

但是从技术理论上无法进行这点,不就是区块链行业的发展根源吗?

现在行业合规的大棒在持续发酵,今天可以为了黑客冻结、修改账户余额,那明天可以为地缘因素、矛盾因素,去做任意的修改。如果链成为地区性的部分工具,那行业的价值也就被大幅压缩,充其量就是另一套更不好用的金融系统而已。

这也是坚定行业的原因:"区块链不是因为不能冻结才有价值,而是因为即便你恨它,它也不为你改变。"

监管大势所趋,链能否守住自己的灵魂?

曾几何时,联盟链比公链更受欢迎,就是因为它满足那个时代的监管需求。如今联盟链的式微,其实也就意味着单纯遵从此需求,并不是真实用户的需求。失去了被监管的用户,那又需要监管工具吗?

从行业发展角度看:

"高效的中心化",它是区块链发展的必经阶段吗?如果去中心化的最终目标是保障用户利益,那我们能否容忍中心化作为过渡手段?

"民主"这个词,在链上治理语境中,其实是代币加权的。那么如果黑客持有大量代币(或某天自治组织被黑,黑客控制票权),是否也可以"合法投票洗白自己"?

最终,区块链的价值,不在于能不能冻结,而在于即便群体有能力冻结,也选择不这么做。

一条链的未来,不由技术架构决定,而由它选择守护的那套信仰来决定。

此页面可能包含第三方内容,仅供参考(非陈述/保证),不应被视为 Gate 认可其观点表述,也不得被视为财务或专业建议。详见声明
  • 赞赏
  • 6
  • 分享
评论
0/400
Blockblindvip
· 07-10 20:20
资本家还是一如既往的贪婪呢
回复0
token_therapistvip
· 07-08 18:47
看穿本质 牛市头单杀完就跑
回复0
GateUser-4745f9cevip
· 07-08 09:38
真自由才是生存底线!
回复0
Floor_Sweepervip
· 07-08 09:37
赢麻了 btc就是赢家通吃呗
回复0
DegenApeSurfervip
· 07-08 09:30
资本疯狂割韭菜咯
回复0
notSatoshi1971vip
· 07-08 09:30
牛市吹牛 熊市修仙
回复0
交易,随时随地
qrCode
扫码下载 Gate APP
社群列表
简体中文
  • 简体中文
  • English
  • Tiếng Việt
  • 繁體中文
  • Español
  • Русский
  • Français (Afrique)
  • Português (Portugal)
  • Bahasa Indonesia
  • 日本語
  • بالعربية
  • Українська
  • Português (Brasil)