黑名单和 wrap 合约
为什么会有黑名单这个功能？大家可能听得比较多的诸如“ECAF 出了新的 order 需要 BP 去执行”，又比如新的 order 会经常出现“blacklist”这个关键词。
ECAF order 的来源是这样的：由受害者账户向 ECAF 发起仲裁申请，ECAF 负责取证和验证工作，验证无误之后 ECAF 会发出附带证据的 order 给到 BP 供 BP 参考执行。截止目前 ECAF 下的所有 order 都属于“临时冻结”，主要是为了保护被黑客攻击的账户的资金不被继续挪动。而 EOS 内建的黑名单功能恰好可以满足让特定账户资金无法挪动的需求，因此 BP 选择使用黑名单功能来“执行” ECAF 的order。
黑名单设计的目的，是协助 EOS 链上进行治理。
让被盗的资产有机会先做冻结处理，为下一步追回被盗资产增加可能性。它同时也能让 BP 及时处置在智能合约层面上的高危漏洞，这其中包括系统合约和第三方合约，即先使用黑名单功能将有漏洞的功能暂时屏蔽，后续再进行修复，修复完成之后再开放相关功能。
EOS 黑名单功能理解起来非常简单：出块节点（top 21 BP）配置了黑名单之后，可以阻止特定账户发出的任何交易（包括但不限于转账交易）。
比如 ECAF 发的 order 里有个黑客账户 A 需要被“冻结”，只需要排名前 21 的出块节点将账户 A 加到各自的黑名单里，就可以实现“冻结”的目的。但这里有两个问题：
一、黑名单配置要想 100% 生效，前 21 个 BP 必须全部配置。
二、前 21 个 BP 是动态的，随时可能有新的节点被投到 21 名。
在最近的使用案例中，如上面所提到的那样，黑名单功能主要还是用于ECAF方面，协助EOS 的链上治理，同时 BP 们也多次通过该功能协作修复了系统合约或大或小的问题。
功能进一步完善的必要性
上文提及到两个问题，说明黑名单功能并不是一个可以完全胜任链上治理工作的机制。现实情况是，ECAF 的 order 发布时间无法预估，同时 BP 社区又是一个全球化的社区，黑名单配置更新不及时的情况难免发生。一旦出现前 21 BP 黑名单配置不一致的情况，就存在被“部分”加到黑名单的账户里的资产被黑客继续挪动的风险，这是黑名单机制决定的。另一种情况是 standby 节点在黑名单配置没更新的情况下，获得了新的投票支持，变成了前 21 个出块节点，黑客就变得有机可乘。因为黑客会一直尝试转移被黑的账户里的资产，如果有任意一个出块节点没有配置最新的黑名单，那么就会给黑客留下可以转账的时间窗口。
因此我们说，黑名单机制并不是一个可以用来很好地协助链上治理的工具。EOS 社区正在积极探索各种各样的替代性完善方案。
为什么会有 wrap 的存在
EOS 区别于其他区块链，是一条带有链上治理的公链，wrap 合约基于 DPOS 能够做出紧急的处理。在受害者提供充分证据的情况下，治理层面的操作因此能够执行并完善。最后，当出现 bug 和一些漏洞的时候，BP 可以更加高效地作出处理。
值得指出的是，BP 并没有因为 wrap 合约的部署而获得新的权限。
从软件工程角度理解的话，wrap 是一个方便的工具（没有 wrap 也可以执行类似的操作，但过程复杂，且很难追踪和监督，参见代码）。wrap 的出现是把一个本来就可以实现的操作，封装得更好用同时也更易于追踪了。也就是说即使没有 wrap 合约，BP 也可以用其他方式执行同等权限的操作。
wrap 是如何与黑名单功能结合的
为了解决黑名单机制很容易失效的问题，部分 BP 节点基于 wrap 合约提出了多种不同的方案。其中的一个方案是先把黑名单账户里面全部的 EOS 资产的账户分别质押到黑名单账户上（delegatebw 操作）。如此一来，即使再出现前 21 个 BP 黑名单配置更新不及时的情况，黑客能做的能做的操作也只是解除质押（undelegate），而大家都知道，解除质押的 EOS 要等 3 天之后才会到账，届时才可以执行转出操作。这样的话，就给了黑名单账户受害者争取到比较充足的时间窗口及时发现这类异常操作，留给他们处理资产归属和申请仲裁的机会。
上述提案其实有一个逻辑问题，就是 BP 虽然可以使用 wrap 合约将黑名单账户的 EOS 资产进行抵押操作，但该操作必须要被包含到新的区块中去才算生效。但是，由于所有的 BP 都把这批账户加到自己的黑名单配置里了，也就不会有任何 BP 会把发自这批账户的任何交易包含到新的区块。很像是一个“先有鸡还是先有蛋”的问题。
END
image
网友评论