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)