【治理与技术】从技术角度解析黑名单与wrap

【治理与技术】从技术角度解析黑名单与wrap | Ecency

币乎封面.jpg
给 EOS LaoMao 投票，请认准我们的主网节点ID：eoslaomaocom

2018 年 10 月 22 日（周一）晚 8 点，EOS Alliance - Serenity 小组就《ECAF 呼吁 BP 改变冻结账户的方式》这篇文章所涉及的内容进行讨论，会议讨论将涉及 EOS 的黑名单机制以及 wrap 合约的部署及后续应用。同时 EOSLaoMao 节点从技术角度也跟大家做一个简短的分享和探讨。

会议通知

会议流程

参会人员一览

会议主要内容

这次会议主要是跟大家普及分享两个主要内容，第一是在逻辑上讲述黑名单和 wrap 的技术原理；第二是 ECAF 为什么提出 BP 执行 order 的方式需要做出改变。

本次会议的主要内容由来自 EOSLaoMao 的赵余给大家带来。

黑名单和 wrap 合约

为什么会有黑名单这个功能？大家可能听得比较多的诸如“ECAF 出了新的 order 需要 BP 去执行”，又比如新的 order 会经常出现“blacklist”这个关键词。

ECAF order 的来源是这样的：由受害者账户向 ECAF 发起仲裁申请，ECAF 负责取证和验证工作，验证无误之后 ECAF 会发出附带证据的 order 给到 BP 供 BP 参考执行。截止目前 ECAF 下的所有 order 都属于“临时冻结”，主要是为了保护被黑客攻击的账户的资金不被继续挪动。而 EOS 内建的黑名单功能恰好可以满足让特定账户资金无法挪动的需求，因此 BP 选择使用黑名单功能来“执行” ECAF 的order。

黑名单功能目前应用最多的场景，是协助 ECAF “临时冻结”部分账户以达到临时保护这部分账户的目的，尽管这（可能）并不是黑名单功能的设计初衷。

让被盗的资产有机会先做冻结处理，为下一步追回被盗资产增加可能性。它同时也能让 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 社区正在积极探索各种各样的替代性完善方案。

首先，社区做了一些提高黑名单机制的易用性，降低黑名单管理成本的辅助工具。

（一）EOS LaoMao 在主网上部署了一个黑名单合约，将黑名单数据及时在链上更新，让BP能够及时获取最新的配置；

（二）同时 EOS LaoMao 也开发了黑名单插件，降低 BP 之间在黑名单问题上的沟通以及黑名单配置校验和更新的成本；

（三） EOS Liquid 提供了相关插件（heardbeat plugin），周期性地（默认每五分钟）将出块节点的黑名单数据更新到 EOS 链上，方便 BP 之间互相比对。

为什么会有 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 会把发自这批账户的任何交易包含到新的区块。很像是一个“先有鸡还是先有蛋”的问题。

投出真正有价值的BP意义

作为 EOS 代币的持有者更多地应该给为生态真正做贡献的 BP 投票。惩恶扬善的机制，值得每一个参与者去讨论和思考。我们呼吁每个持币人都能珍惜手中的投票权，只有这样，才会有更多负责任的公正节点出现在排名靠前的位置，EOS 生态才能更安全、更健康、更繁荣。

如对 BP 或者社区有不满的地方可以进行公开的讨论和提出切实可行的办法，或者提出值得表扬、值得加强的地方。去中心化的社区里面，好的机制是需要公开探讨才能得出的。只有当每一个持币者珍惜自己手中的权力，才能对社区产生好的影响，从而降低 EOS 网络的风险。

精彩问答

Yin：解禁后是否可以只实现某种权限，其他功能不影响？

赵余：这是一个好提议，不过能不能到账户层面，后续还需要研究一下。做黑名单上线也是为了能有约束力在上面，我们之前没有把李嘉图合约的内容放在服务器里面，导致后面有一些情况不能规范。

Yin：假如 BP 犯了错，不需要负责吗？

赵余：只能说处于非常模糊的阶段，没有明确的惩罚措施

遁一：这么多币都锁着，怎么处理呢？

赵余：我们做了很多可以减轻这方面工作量的工具，但是未来冻结后需要处理的量会增加，目前也不明确 ECAF 真正会怎么选择。现在是卡在加黑名单的人已经是互相依赖的关系了。

遁一：15 个 BP 多签同意就可以执行了

赵余：为真正有价值的 BP 投票，降低全网的风险，看长期的效益

David：已经有的公约版本就有提到丢币可以找仲裁，现在是想要15个 BP 同意通过就可以执行了吗？

赵余：系统合约要升级，其中一个 BP 提案，其他 BP 多签，15个 BP 同意就可以执行了。

David：目前没有 wrap 的情况下，是相对好的想法。有没有一个可能，全面 15个 BP 共同作恶，没有太大的共识，制衡 BP 手上享有的权利。

何：能不能加高门槛，在3.0版本上可以做更细节的讨论。丢币盗币是否能通过仲裁来解决，这是其中一个小组的讨论，所以要看3.0版本细节中的内容，改进 wrap 的提案。

赵余：不管3.0会不会用技术引入的机制，但是不做财产保险而是账号保险，这是一个新思路

遁一：也就是黑客搞 15个 BP 就可以了

赵余：所有 BP 的安全怎么保证，最后其实是需要有其他机构来进行评审。攻击 BP 和攻击算力，大家还是要监视 BP，负责任地投出应该投的票，另外就是，作恶的事情需要公开讨论。

David：3.0 现在还没有定下来，要是同意今天讨论的看法，接下来我们可以为此提案做些什么努力呢？

赵余：治理的讨论，需要有技术原理的普及，这是非常必要的，因为需要用技术层面来落地。麒麟测试网和主网几乎是镜像的关系，之前在我们已经麒麟测试网上重新部署了合约，但还没有做 restake 的部署。

Achilles：BP 需要服从 ECAF 的指令

赵余：大部分 BP 是看 ECAF 的指令做事情的。之前有 200 万的资产被盗，ECAF 还没出 order，就有 BP 提前加了黑名单。ECAF 发的 order 没有让你加黑名单，他们不会要求你的过程做法是什么，但是他们需要的结果是让这些账户不能进行交易。所以只要做到，其实是不违背 ECAF 的初衷的。我认为在技术上是有方案的可以解决的，使用多签的形式。

David：有什么样的方案是安全可靠的，可以让社区知道，对 BP 这样的行为是可预知的。

Yvonne：治理希望可以从技术的角度来落地，不管是对 BP 还是其他方面。

广墅：15 个 BP 同意，马上就能生效黑名单呢？

赵余：黑名单是每个 BP 的行为，现在要看 ECAF 的 order，有的 BP 会跟不上

Yin：是不是可以存在一个 tool 或者智能合约，BP 选择之后可以自动执行。

赵余：黑名单+黑名单插件，就可以实现了。黑名单的更新都是 ECAF 操作的。