|
gcolvin 的情绪似乎有些缓和，但仍在强调 ACD 的决议不可推翻。在他看来，流程就是为了防止「最后时刻的噪音」，这被 Alexey 反对。 此时，Vyper 团队表示他们会使用子程序带来的新特性。Micah 认为这不是什么安全性问题，而仅仅是 Solidity 一个团队不使用它而已，因此没必要在最后时刻推翻流程。lightclient 也表示接受。 而此前关于「DRAFT」的讨论得到了 Pawel Bylica 的回应，他认为他甚至不知道这个提案被接受了，他以为还在讨论呢，关于 EIP 的状态，应当提供 RSS Feed 样式的接口订阅，以帮助大家了解自己关心的 EIP 的变更（不是每个人都会有时间关心每个 EIP，每次 ACD）。 这似乎给了 lightclient 灵感。 一次完美的总结3 月 4 日，lightclient 整理了 EIP-2315 事件的 时间线，详细梳理了此提案生命流程中的所有大事件。该提案首次被列入讨论是 ACD 80，最后一次讨论是 ACD 96，跨度 7 个月。但最终并没有达成结论。尽管第 98 和 100 次 会议 没有会议记录，所以无法确定是否讨论了限制跳转的问题。（但 lightclient 后来重听了整个会议（总计约 4h），确认了并未讨论这一议题。） chriseth 赞美了 lightclient 总结的时间线，这印证了他的印象即此提案从未被真正地接受过。此外，他重新陈述了对此提案目标的质疑，由于缺少静态分析的专家参与，且该提案可能无法起到减少 gas 消耗的目标。 3 月 5 日，lightclient 作出了 最终陈述，非常精彩，全文翻译如下： 随后，lightclient 敲下了法官的重锤。 这项建议已被 ACD 107 接受。EIP-2315 将从柏林移除。 gcolvin 也作出了自己的总结，他回顾了自己的心路历程，并对自己的鲁莽表示歉意。在最后，他指出了核心开发者的使命：「我希望这种可悲的事态发展能够引发严肃的反省--我们已投身于一个目前市值 1730 亿美元的网络的研究、开发和管理。我不知道有多少业务在这个网络上运行，也不知道它支持了多少人的生活。我们必须学会像专业人员一样操作。」 如何制定公共政策事情似乎告一段落，但这次事件的影响是深远的。如果以太坊的开发者不能从中吸取教训，那这类事情一定会再次发生。公共政策的讨论可以分为几个层次。
第一层是公共政策的内容是否具有「结果正义」。公共政策的目标是什么，其内容是否可以实现声称的目标，尤其是技术上是否具有可行性。实现这个目标会让多少人受益，让多少人受损，是否有其它实现方式？在一层，主要需要相关领域的专家对技术可行性及其效用进行评估。在此案例中，几位技术专家的讨论还是比较充分的，他们通过论坛、聊天工具展开了长期的探讨，虽然谈不上多高效，也谈不上有多么深入。直接在 ACD 这类全员会议上展开专业问题的讨论，显然不是什么好的决定。尤其是针对「子程序」的用例，「基准测试数据」等具体问题，并没有讨论清楚。 (责任编辑：admin) |