接下来的讨论似乎没有沿着这条路线前进，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)