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，替身字段会被彻底移除；旧列表自然失效。
所以，等于这个功能临时加进来，很快就要删掉，未来如果想要再用替身，还是要完整走一遍流程。
所以后面不能【随意用】，而是可以【重走流程再用】。