干货

ENS 的深度剖析

月亮🌛   |     |   2901 次阅读

ENS bug 报告和进度

关于事后的记录:对文件和事件的深度剖析来查找问题的所有根本原因,并做一些修改以防止再次发生此类问题。比起分配责任等问题,他们更专注于事件背后的技术问题以及来防止再次发生的可采取技术措施。

回顾

ENS 是建立以太坊区块链之上的分布式的命名系统。原来定于3月14日 pi day 发布

ENS由三个主要组件,注册表(registry),解析器(resolvers)和 注册服务(registrars) 组成。 只有 ENS 注册表是系统的核心不可变的部分; ENS 解析器最终由用户实现,注册服务(registrars)是在 ENS 中拥有名称并根据部分规则分配子域的智能合约。

最初的ENS部署包括ENS注册表,注册服务(registrars)使用拍卖系统分配名称的“.eth”子域名,并且注册服务(registrars)反向解析以太坊的地址。

所有三个组件都应提前部署,.eth注册器配置为在Unix时间戳1489431415(2017-03-13 18:56:55 UTC)上生效。 注册服务(registrars)在预期时间上线,由于ENS团队成员按预期工作做了检查,故意使注册DApp故障了一段时间,

不久之后,社区成员向ENS 开发团队 报告了 bug ,用户在拍卖期间进行投标的注册服务(registrars)出现了潜在问题。 这些问题会消除 Vickrey 拍卖过程的一些重要保护措施,并使部分参与者有不公平的优势。 这个问题很快得到验证,并为此设计了一个方案,同时为已经投标收回押金的人提供了一个解决措施。

通过Skype紧急召开会议,会议主要目的是审查拟议的修复和恢复路径,并将几个Ethereum成员和社区开发人员也纳入审核。 所有人都认可修复似乎可以解决这个问题,并且恢复过程也会起作用。

dapphub表示,尽管他们认为补丁是健全的并且对智能合约的最后审查也没有出现其他任何明显问题,除非得到进一步审查,否则他们认为不可以继续发布并建议推迟发布,。

ENS团队测试了bug加上从审阅者收到的反馈、他们对代码的了解以及考虑部署修复的相对容易性,ENS团队最终决定继续发布,并向ENS受托人发送提案以替换原来的和修订的.eth注册服务(registrars)。 该提案很快被批准,替换注册服务(registrars)的发布日期设置为 2017-03-14 23:59:59。 新的发布日期以及第一个错误和其修复的报告也已公开宣布。

再次上线不久,出现了Github 上报出的第二个问题,参拍者尽管账户余额不足,但仍然可以在拍卖中获胜。 在经过审查后确定了确实存在这个问题,ENS 正式宣布被关闭。

事件线

UTC的时间点.

• 2017-01-10: Nick Johnson 提交PR 35(一个意外的引入了这两个问题的重构)。 但是单元测试没有遇到任何问题。
• 2017-03-11:ENS 智能合约部署和配置
• 2017-03-13 19:09: 社区成员“EthHead”通过 Gitter 通道向ENS团队报告了揭标时间还可以出价的问题
• 2017-03-13 19:10至2017-03-14 02:09:ENS团队讨论和解决问题。
• 2017-03-14 02:09:召开会议审查并且同意修复。
• 2017-03-14 05:31:2017-03-14 23:59:59 批准修复和部署
• 2017-03-14 07:42:ENS主要负责人通过电子邮件通知并批准注册服务(registrars)转为新智能合约。
• 2017-03-14 10:10:由第四个主要负责人批准转换并且生效。
• 2017-03-14 12:55:Github Issue #49,提交详资金不足的错误
• 2017-03-14 13:48:ENS团队决定推迟发布。 ENS主要负责人通过电子邮
件发送并批准了停用新注册服务(registrars)的提案。
• 2017-03-14 02:40:第四个主要负责人批准提案,注册服务(registrars)被禁用

影响

当用户直接投标后,大约八(8)个以上的用户押金被锁定在原始的.eth注册服务(registrars)中。 这个数字之所以非常低是因为招标DApp还未启用。 大部分用户的押金将在原来的显示周期显示出价时立即恢复,为了实现这一点,ENS团队故意超出了他们可以识别的所有投标。 剩余资金将在ENS重新发布后或一年后恢复。

大约23个以上以太币用于支付调用.eth注册服务(registrars)智能合约的 gas 花费

延迟ENS的发布

根本原因

缺乏覆盖性单元测试

虽然注册服务(registrars)有一套单元测试,但这种测试并不全面,单元测试是由不同作者在智能合约之后编写的。 所以不能确保所有代码路径或事例得到彻底的覆盖。

单元测试虽然可以捕获bug,但是他们对智能合约的后期状态不充分的评价,造成了机会的流失。

代码审查不足

智能合约的改变是引入了在Pull Request中对bug的审查,但审查没有检测出错误。 所以在将来对关键代码更改时的审查需要更加谨慎,以确保不会走向相反的方向。

正规、独立审查的缺失

一些社区成员在部署测试网络时非常规的审查了注册服务(registrars)智能合约,从而导致出现了几个错误。 Martin Swende在发布前不久也进行了一次审查,在时间限制的基础上同样进行了非正式的审查。
没有进行独立,全面的审计。

bug赏金流程指示不清晰

社区中没有明确表明ENES是否涵盖在Ethereum基金会的bug赏金流程中。
如果已经公布了ENS的涵盖范围,则可能会在该过程的较早阶段更多地关注代码,从而导致在可以轻松找到bug并且解决而不影响发布。

拒绝取消发布

在第一个错误发现之后发布应该被推迟,以提供更多的时间来评估智能合约和确定是否存在其他的相关错误。 决定继续发布的部分原因是错误的认为第一个错误是一次性错误,还有部分原因是希望迎合最初定好的发布日。

以后如果在他们看来有必要采取取消这样的行动,那么可以通过独立的股东直接取消发布来减轻带来的损害。

发布的“关注放大”效应

还要注意发布的“关注放大”效应。 我们认为bug发生的重要原因是对发布代码投入了过多的关注。 如果提供了ENS bug赏金流程,那么可以更好的利用这些关注。

由于公开发布引起的普遍关注代码,导致发布可能需要推迟,但是“更长”的发布可能需要更长的时间才能发现bug,这样的话他们会出现更多的损失。

实时升级的困难

在注册服务(registrars)的发展过程中,为了从一个注册服务(registrars)转移到另一个注册服务(registrars),要求用户采取行动有意识的做出选择, 之所以上述过程可行是因为注册服务(registrars)完全控制了用户押金的状况; 通过要求用户主动地输入来保证如果代码发生变化,他们可以作出明智的选择。

然而通过排除简单自动化转移到新的规则,这使得即时升级的部署变得复杂化。 未来应该努力探索在不需要明确的用户操作情况下,做出更改而不影响用户押金的注册逻辑实用性这个方向

解决方向

分离基金

由于注册服务(registrars)专门将存放押金与非常有限API的单独“契约”智能合约分开,因此不会出现问题可导致用户资金的损失。

禁用 DApp

DApp没有启用投标的事实意味着只有存放押金的用户才能通过控制台或者他们自己的代码直接与注册服务(registrars)进行联系。 这大大限制了押金的数额。

反之,禁止开放拍卖会导致在不能接受投标的注册服务(registrars)的拍卖中浪费更少的gas。

主要负责人

当确定问题时,ENS 迅速行动尽可能在有限的时间表上执行对ENS的更改,从而大大减少了bug的影响。

措施 负责人 状态
为拍卖registrar列举用例和边缘案例,并确保每一个都被单元测试所覆盖。 Nick Johnson 进行中
委员会由dapphub进行正式独立审计,并且由Martin Swende进行内部审计 Nick Johnson 进行中
宣布ENS将覆盖着bug赏金系统用以找出在审查中没有找到的bug Nick Johnson 进行中
确定向两个ENS发布bug的发现者发送bug赏金的奖金 Nick Johnson, Martin Swende 进行中
讨论实施和记录什么构成“showstopper”发布bug的标准 Ethereum, dev team 进行中
评估结构变化对registrar的可行性,以便在未来bug的情况下更容易升级。 ENS team 进行中

翻译:MakoShan

 
3 人喜欢