接下来的讨论似乎没有沿着这条路线前进，Alexey、Chris 和 Vitalik 对 EIP-2315 所涉及的动态跳转展开了讨论。Peter 此时表示，他已移除 2315 并成功同步了，但这并不能保证其它客户端也奏效。

lightclient 催促大家尽快达成共识，他赞成在 Berlin 移除 EIP-2315，理由仍然是基于内容上的。他认为此提案并不能实现声称的好处，但如果大多数人同意可以继续，本不应该反对提案。然而由于「Solidity 编译器的使用率远远超出其它工具，而他们的开发者认为这个提案是无用的」，因此应当更谨慎地对待此议案。

tkstanzak (Netherland 的开发者) 认为这甚至会导致「严重损害 (damage)」，原因是「无用的代码增加了 EVM 的复杂性，拖慢了它的运行速度，没有任何人声称会使用他」。这种表态激怒了 gcolvin，他说「混蛋。(Bullshit.)」lightclient 显然对这种气氛不安并试图维持秩序，「很不幸我们有麻烦了，我们得花点时间搞清楚我们为什么会搞成这样，但现在我们得根据现有信息作出最合适的决定。」很不幸这种提议并没有让 tkstanzak 和 gcolvin 买账，他俩展开了一组对话。* > 对话的重心在于「是否有人真正愿意使用此提案？」 gcolvin 强调，「子程序本身」就是子程序的用例，如果任何人反对这个提案，应该在过去两年的「以太坊魔术师论坛」的讨论中提出，而 solidity 团队更应该在 ACD 上提出反对。而 tkstanzak 认为从来就没有人给出过该提案的优点（例如可以提升 solidity 的效率，达到 2%），2020 年 1 月，他就这么问过 gcolvin，但并没有继续讨论下去了。在过去的两年里，他一直在等待这个问题的答案，而且一直没有人告诉他 Berlin 什么时候会来。因此，Berlin 的延期也没什么大不了的，因为其中除了 EIP-2929 外也没有什么特别要紧的提案。他给予了 gcolvin 高度的赞誉，认为他是 EVM 的专家，但如果没有任何表示会使用他提升 Solidity 或其余编辑器，那么为什么要对这个提案有如此高的信心呢？他还打了个很长的比方，大致的意思是汽车发动机的每一次设计更新都应该有充分的理由，而「70 年代飞机发动机就已经使用这个技术了」不是一个合适的理由。因此，如果移除 EIP-2315 会推迟 Berlin 升级，那也不得不这样，但他有信心大家并不需要推迟升级，也能很好地移除该提案。

Tim Beiko 做了两点总结，在今后的流程中，应当（1）明确每个 EIP 的需求方及理由（2） ACD 的讨论应当更加广泛，以提前收集反对意见。

此时，Hudson，过去 5 年里 ACD 的协调人，阐明了他对此次沟通的立场。他首先表示了 gcolvin 专业知识的尊重，但批判了他的无礼态度，每个人应当都对自己有高标准，即使在情绪冲动时。而关于议事流程，他认为「先例并不是一定要遵守的。流程系统已经崩溃了，需要根本的改善。」 (责任编辑：admin)