Zcash匹配漏洞致THORChain18个节点保证金合计被罚约140 RUNE

ZEC匹配漏洞让18份THORChain保证金买单

18名节点运营者正在为Zcash处理漏洞付出代价:链上数据显示,一次金库罚没从他们的THORChain保证金中扣除了约140枚THORChain (RUNE)。风波发酵期间,THORChain(RUNE)价格在24小时内波动了4.3%。用户端毫发无损:所有进出Zcash的兑换者都拿到了资产,损失完全落在以RUNE为抵押、为Zcash原子交换结算提供后盾的金库背后的运营者身上。THORChain于10月19日星期一发布官方公告确认了此次事件,称Zcash集成中的一个出站匹配问题触发了金库罚没。问题出在协议为出站交易配对目标地址的方式上:一个Zcash TEX地址(一种只接收屏蔽转账的目标类型)与其对应的透明地址本应是同一个去处,协议却把它们当成两个独立地址,配对逻辑因此失效。匹配失败后,金库承担了这笔损失,金库背后的保证金随之被罚。事件发生后,原生ZEC交易已被冻结,协议表示在v3.21.0版本发布修复之前将维持暂停。这次罚没有波及用户价值,兑换者全身而退,这正是保证金机制的初衷:运营者锁定RUNE作抵押,就是为了让金库出问题时先砸自己的本金。此处的故障是软件问题而非盗币,被罚的18名运营者是唯一蒙受损失的一方。约140枚RUNE摊到18份保证金上,单家损失不算大,但时机颇为微妙:据协议自己的网络状态报告,9月其活跃节点数刚从87个增至103个。

修复随v3.21.0发布。发行说明写道,所有出站匹配现在统一走同一个共享目标比较器,Zcash TEX地址与其匹配的透明地址被视为同一目的地,发往TEX地址的ZEC出站按透明交易排队。待NU6.3网络升级生效后,透明ZEC出站将在全网切换为v6签名,该变更由HALTSIGNINGZEC控制开关把关,激活高度定在28,366,100,THORChain预计在10月23日星期五13:40(UTC)前后到达;说明强调区块高度为准,时间只是估算。节点运营者必须运行携带安全补丁的私有二进制文件,不得自行从源码构建。ZEC并非v3.21.0针对的唯一暂停业务。Solana链上出现新型交易后其交易被叫停,此版本使其得以重启。同一版本还修复了近期针对Rujira的FIN合约攻击背后的应用层缺陷,重新开放因状态膨胀而暂停的限价兑换,并修正SwapKit联盟手续费分账,让多家集成方能够重新启用THORChain。无备注兑换将按动态定价对抗垃圾交易,备注槽位越满注册成本越高,Mimir可控制其重新开放。门罗币则被排除在v3.21之外,其修复排入v3.21.1,日期未定。对一个新集成而言,这个时机相当尴尬:ZEC资金池是THORChain (RUNE)最新的资金池之一,2026年8月25日的v3.20升级刚让门罗币和Zcash接近激活,原生ZEC流动性池于10月初上线。v3.20还重新引入了对Solana、Base和BNB的支持。此前在2026年5月发生1070万美元漏洞攻击后,网络经过为期39天、共11个阶段的安全整改,于6月23日重新开放。v3.21还带来了保证金提供者流式收益功能,可将其保证金收益的一部分直接发送至钱包;该功能在Mimir启用前保持关闭。

保证金机制吸收了软件故障

对照协议自身的复盘来看,这次事件更多反映的是THORChain的损失吸收次序,而非Zcash本身。在跨链桥反复掏空用户资金的行业里,这次故障把成本压给了18名被罚的运营者,所有兑换者分文未损,机制按设计运转。以代币计损失不大,约140枚RUNE分摊在18份保证金中,但它发生在活跃节点从87个增至103个之后数天,意味着每笔未来金库差错背后压着的保证金资本更多了。协议公告中没有任何向被罚运营者退款的内容;他们的回本之路要靠节点收益,起点正是v3.21交到他们手中的流式收益。