0xTodd🟥🟨🟦
SUI 被盗事件后续——SUI 更新了一个什么样的代码来取回资产呢？ 下面这次硬分叉核心思路只有一句话：把「黑客地址」彻底封禁，再在协议里临时声明一个“替身签名人”，只允许 1-2 笔特定的“赎回交易”通过验证，把钱转走。 1.替身交易如何实现？ 具体来说就是两步走： 第一步，新增参数 SUI 在 签名校验层 verify_sender_signed_data_message_signatures 新增参数 aliased_addresses，做了一个替换。 简单来说 aliased 就是替身地址。 第二步，在 deny check 打开豁口。 指定只有“替身+指定哈希”才放行 这两步合起来的效果是： 任何普通交易 → 仍被 deny list 拦截； 只有【替身声明】中那笔赎回交易、且签名人是替身，才能绕过封禁继续执行。 目前，SUI 已经把黑客地址里的钱，通过【替身代签名】的方式取了出来。 这里和我们之前分析的帖子的预测是一致的。 2. 有没有“公投”逻辑？ 在这组 PR 里完全没有出现任何与链上投票、DAO 治理或“公投”相关的代码。 没有选择全民公投，最终还是代议制解决了问题，拥有 2/3 总质押权重的验证者们主动升级，把上述代码给合并了。 当然了，Sui 当前的治理模型，本来侧重于【验证者治理】而【非持币者治理】。 客观来说，虽然有些中心化，但是遇到应急事件，基金会+验证者合议是最快路径。 3.那基金会以后能不能随意再用“替身”？ 让我们先来看看，如何再次构造替身交易？ 首先，必须重新升级协议版本 替身地址写死在 v 83 的初始化代码里。未来若想再加别的映射，必须发布新的代码，并让 ≥ 2/3 总质押权重的验证者主动升级。 如果节点拒绝升级，旧代码里根本没有对应条目，替身就不会生效。 其次，白名单限制了“交易哈希” 【替身代码】只列出那两笔赎回交易。即使有人拿着同一把私钥再签别的交易，也通不过校验。 最后，生存期短 源码里已写等网络整体升级到 v 86，替身字段会被彻底移除；旧列表自然失效。 所以，等于这个功能临时加进来，很快就要删掉，未来如果想要再用替身，还是要完整走一遍流程。 所以后面不能【随意用】，而是可以【重走流程再用】。
预览
评论 0