|
原文标题：《移除 EIP-2315: 以太坊柏林升级前的紧急刹车》 以太坊的 柏林硬分叉 预计在 4 月 14 日执行，其首个测试网 Ropsten 将在 3 月 10 日执行部署。而在距离测试网部署前 5 天柏林硬分叉的内容竟然发生了变更，3 月 5 日的第 107 次核心开发者会议（以下简称 ACD）上，EIP-2315 被全体通过移除出升级列表，而这距离其被列入升级列表仅仅过了 14 天。 为什么 EIP-2315 在发射前最后一刻哑了火，究竟发生了什么问题？这还要从一个 提案 说起。 多方争论3 月 3 日，lightclient 发表该提案，回顾了 EIP-2315 的复杂历史，并从技术和社会共识层面提出了反对的理由。在技术层面，他指出点出了 Solidity 团队的两位成员在推特上表达了对此提案的反对，并给出了合理的推测——由于 solidity 编译器占据了绝大多数市场，如果 solidity 团队不利用这一提案，则大部分智能合约都不会使用这一特性。与此同时，EVM 的复杂性却大大增加了，看起来似乎得不偿失。在共识层面，lightclient 认为其作用有限，同时反驳了「这是为未来升级的铺垫」。他认为即使是作为未来转变的基础 EIP，也必须有自己独特的用处。因为如果一个 EIP 本身没有好处，而只是未来「好处」的垫脚石，未免风险太大。在升级前临时刹车是不寻常的事情，lightclient 对其可能造成的困扰表示了歉意。 提案的提出者 gcolvin 很快提出了反对。首先，他不同意流程上的妥协，认为「核心开发者确定了的升级列表是不能更改的」，否则会造成不好的先例。从技术上，他解释了这一提案的初心，他认为 solidity 团队的反对是没有道理的，因为他们没有反对过对此提案的分析。同时，即使他们反对也不能说明什么，因为 Vyper （另一个智能合约编译器）团队表示会采用这一新的特性，智能合约不仅仅是 s olidity 一家说了算。他还指出在此提案已投入太多心血，目前没有看到一条「他未曾反驳」或「可以影响升级」的反对意见。 Vyper 团队表示也许这对 solidity 团队现阶段没有用，但他们是会采用的，并期待已久。「只要有一个编译器团队愿意使用，就没有理由不实施」。 Tim Beiko （以太坊核心开发者会议（ACD）的协调人）总结了各客户端团队的意见。Geth 团队希望等待 ACD 的决议，而其它客户端团队（Netherland、OpenEthereum、Besu）则表示对保留 2315 无异议（需要特别指出，Geth 客户端的占有率超过 80%）。 看起来谁也不服谁，但在 ACD 召开之前，2315 就被无异议地移除了。是不是很奇怪？ EIP-2315 到底是什么EIP-2315: 为 EVM 引入简单的子程序。子程序是计算机领域的一个基本概念，可以认为是程序的一个子集或片段，可以让一段代码逻辑被重复调用。子程序和函数有区别，函数有返回值，且一般不显式地修改全局变量，而子程序没有返回值，且是对全局变量进行操作。子程序对简化代码有许多好处，这也正是 EIP-2315 的提出动机。EVM 目前不支持子程序，但可以通过操作程序计数器来实现这一功能。提案的作者 gcolvin 在「动机」章节阐述了他的理由。「 在过去的 30 年里，计算机行业一直在与这种复杂性和开销作斗争，并在提供直接支持子程序的原生操作符方向上取得了进展。至少追溯到 50 年前，大多数物理机和虚拟机都以某种形式（非原生地）提供这些操作。」 (责任编辑：admin) |