背景

以太坊的柏林硬分叉[1]预计在4月14日执行，其首个测试网Ropsten将在3月10日执行部署。而在距离测试网部署前5天柏林硬分叉的内容竟然发生了变更，3月5日的第107次核心开发者会议（以下简称ACD）上，EIP-2315被全体通过移除出升级列表，而这距离其被列入升级列表仅仅过了14天。

为什么EIP-2315在发射前最后一刻哑了火，究竟发生了什么问题？这还要从一个提案[2]说起。

多方争论

3月3日，lightclient 发表该提案，回顾了EIP-2315的复杂历史，并从技术和社会共识层面提出了反对的理由。在技术层面，他指出点出了Solidity团队的两位成员在推特上表达了对此提案的反对，并给出了合理的推测——由于solidity编译器占据了绝大多数市场，如果solidity团队不利用这一提案，则大部分智能合约都不会使用这一特性。与此同时，EVM的复杂性却大大增加了，看起来似乎得不偿失。在共识层面，lightclient 认为其作用有限，同时反驳了“这是为未来升级的铺垫”。他认为即使是作为未来转变的基础EIP，也必须有自己独特的用处。因为如果一个EIP本身没有好处，而只是未来“好处”的垫脚石，未免风险太大。在升级前临时刹车是不寻常的事情，lightclient 对其可能造成的困扰表示了歉意。

提案的提出者 gcolvin 很快提出了反对。首先，他不同意流程上的妥协，认为“核心开发者确定了的升级列表是不能更改的”，否则会造成不好的先例。从技术上，他解释了这一提案的初心，他认为 solidity 团队的反对是没有道理的，因为他们没有反对过对此提案的分析。同时，即使他们反对也不能说明什么，因为 Vyper （另一个智能合约编译器）团队表示会采用这一新的特性，智能合约不仅仅是solidity 一家说了算。他还指出在此提案已投入太多心血，目前没有看到一条『他未曾反驳』或『可以影响升级』的反对意见。

Vyper 团队表示也许这对 solidity 团队现阶段没有用，但他们是会采用的，并期待已久。『只要有一个编译器团队愿意使用，就没有理由不实施』。

Tim Beiko（以太坊核心开发者会议（ACD）的协调人）总结了各客户端团队的意见。Geth团队希望等待ACD的决议，而其它客户端团队（Netherland、OpenEthereum、Besu）则表示对保留2315无异议（需要特别指出，Geth客户端的占有率超过80%）。

看起来谁也不服谁，但在ACD召开之前，2315就被无异议地移除了。是不是很奇怪？

EIP-2315到底是什么

（如果你不懂技术可以跳过这一节，不影响理解本文的主要观点）

EIP-2315[3]:为EVM引入简单的子程序。子程序是计算机领域的一个基本概念，可以认为是程序的一个子集或片段，可以让一段代码逻辑被重复调用。子程序和函数有区别，函数有返回值，且一般不显式地修改全局变量，而子程序没有返回值，且是对全局变量进行操作。子程序对简化代码有许多好处，这也正是EIP-2315的提出动机。EVM目前不支持子程序，但可以通过操作程序计数器来实现这一功能。提案的作者 gcolvin 在『动机』章节阐述了他的理由。『 在过去的30年里，计算机行业一直在与这种复杂性和开销作斗争，并在提供直接支持子程序的原生操作符方向上取得了进展。至少追溯到50年前，大多数物理机和虚拟机都以某种形式（非原生地）提供这些操作。』 (责任编辑：admin)