gcolvin 的情绪似乎有些缓和，但仍在强调 ACD 的决议不可推翻。在他看来，流程就是为了防止『最后时刻的噪音』，这被 Alexey 反对。

此时，Vyper 团队表示他们会使用子程序带来的新特性。Micah 认为这不是什么安全性问题，而仅仅是 Solidity 一个团队不使用它而已，因此没必要在最后时刻推翻流程。lightclient 也表示接受。

而此前关于『DRAFT』的讨论得到了 Pawel Bylica 的回应，他认为他甚至不知道这个提案被接受了，他以为还在讨论呢，关于 EIP 的状态，应当提供 RSS Feed 样式的接口订阅，以帮助大家了解自己关心的 EIP 的变更（不是每个人都会有时间关心每个 EIP，每次 ACD）。

这似乎给了 lightclient 灵感。

一次完美的总结

3 月 4 日，lightclient 整理了 EIP-2315 事件的时间线 [4]，详细梳理了此提案生命流程中的所有大事件。该提案首次被列入讨论是 ACD 80，最后一次讨论是 ACD 96，跨度 7 个月。但最终并没有达成结论。尽管第 98 和 100 次会议没有会议记录 [5]，所以无法确定是否讨论了限制跳转的问题。（但 lightclient 后来重听了整个会议（总计约 4h），确认了并未讨论这一议题。）

chriseth 赞美了 lightclient 总结的时间线，这印证了他的印象即此提案从未被真正地接受过。此外，他重新陈述了对此提案目标的质疑，由于缺少静态分析的专家参与，且该提案可能无法起到减少 gas 消耗的目标。

3 月 5 日，lightclient 作出了最终陈述 [6]，非常精彩，全文翻译如下：

看来事情的发展倾向于取消 EIP-2315，所以我长话短说。

支持 EIP-2315 部署在柏林的人的论据来自核心开发者会议过去关于接受这个 EIP 的决议。我们有办法通过流程避免当下的状况，并让生活变得更简单。可只有当人们设计并实施时，这些流程才是密不透风的。人类都会犯错，这些错误随时随地都有可能表现出来。我们没有必要成为自己创作品的受害者。

在此流程中出现了一个错误，EIP-2315 不该被接受。早在 ACD 81，Geth 团队就要求提供基准测试的结果，以证明此 EIP 所声称的收益。基准测试一直没有人做。在 ACD 84 中，@Souptacular 动议将 EIP 移至『接受 (Accepted)』。@tkstanczak 重申，如果存在这样的用例（改进的 codegen +静态分析），他就会支持提案。在没有找到符合这两个条件的用例时，此提案被列入了柏林升级。在 ACD 86 中，@MadeofTin 承认，考虑到关于规范的持续争论，将 EIP 转为『接受』还为时过早。甚至在几个月后，在我能找到的最后一次 ACD 电话中提到 EIP 的时候，@Souptacular 指出，围绕着这个规范还有一些悬而未决的问题。@gcolvin 表示会在魔术师论坛中线下解决，但并没有解决。

在整个过程中，几乎每一步骤中，@axic、@chfast 和 @chriseth 都在表达对该提案的担忧。他们写了一份分析，并向 EIP 开了一个 PR，以避免跳入和跳出子程序——这可能是对 EIP 最强烈的抱怨。不幸的是，由于某些原因，他们在去年秋天减少了对 EIP 的参与，因此这个提案设法在柏林的备审清单上停留了几个月的时间。这让那些不参与讨论其可行性的人以为这个 EIP 代表了正统性。流程本该保证反对者的抱怨得到解决，但事实并非如此。如果他们能继续与之抗争，那就更好了，但他们没有。他们已经花了几个月的时间去斗争--这个流程本应把此 EIP 搁置，除非讨论解决。 (责任编辑：admin)