删除eip-2315：柏林以太坊升级前的紧急制动

背景

以太坊的柏林硬叉预计将于4月14日实施，其**测试网络ropsten将于3月10日部署。不过，在测试网部署前5天，柏林硬叉的内容发生了变化。在3月5日举行的第107次ACD会议上，eip-2315被从升级列表中删除，这距离它被列入升级列表仅14天。

为什么eip-2315在发射前的**一刻沉默了？发生什么事了？我们必须从一个提议开始。

许多方面争论不休

3月3日，lightclient发布了该提案，回顾了eip-2315的复杂历史，并从技术和社会共识层面提出了反对理由。在技术层面，他指出，SOLid团队的两名成员在twitter上表达了对该方案的反对，并给出了合理的推测，由于SOLid编译器占据了绝大部分市场，如果SOLid团队不利用该方案，大多数智能合约将不会使用该功能。同时，EVM算法的复杂度大大提高，似乎得不偿失。在共识层面，lightclient认为自己的作用是有限的，并驳斥“这是为未来升级做准备”。他认为，即使作为未来转的基础，EIP也必须有自己独特的用途。因为如果一个EIP本身没有好处，而只是未来“好处”的垫脚石，那就太冒险了。升级前的临时刹车是不寻常的，lightclient为可能造成的麻烦道歉。

提案的发起人戈尔文很快提出了反对意见。首先，他不同意在程序上的妥协。他认为“核心开发者确定的升级名单是不能更改的”，否则会造成不好的先例。从技术上讲，他解释了提案的初衷。他认为SOLidity小组的反对是不合理的，因为他们没有反对对提案的分析。而且，即使他们反对，也无法解释什么，因为Vyper（另一个智能合约编译器）团队将采用这一新功能，智能合约不仅仅是SOLidity家族说了算。他还指出，这项建议投入了太多的精力，目前“他没有反驳”或“会影响升级”都没有异议。

Vyper团队表示，在现阶段，它可能对SOLidity团队没有用处，但他们将采用它，并等待了很长时间。”只要编译器团队愿意使用它，就没有理由不实现它。

以太坊核心开发人员会议（ACD）的协调员Tim beiko总结了客户团队的观点。gETH团队希望等待ACD的决定，而其他客户团队（NETHerland、Openem、besu）则不反对保留2315（应该注意的是gETH客户的份额超过了80%）。

似乎没有人会同意任何人的意见，但在ACD之前，2315被无异议删除。这不奇怪吗？

什么是eip-2315

（如果您不了解这项技术，可以跳过本节，这不影响对本文要点的理解。）

Eip-2315：介绍一个简单的EVM子程序[3]。子程序是计算机领域的一个基本概念。它可以看作是程序的一个子集或片段，可以使一段代码逻辑被反复调用。子程序不同于函数。函数有返回值，通常不显式修改全局变量。子例程没有返回值，对全局变量进行操作。子程序在简化代码方面有许多优点，这也是eip-2315的动机所在。EVM目前不支持子程序，但可以通过操作程序计数器来实现这一功能。提案的作者gcolvin在“动机”一章中解释了他的理由在过去的30年里，计算机行业一直在与这种复杂性和开销作斗争，并在提供直接支持子程序的本机运算符方面取得了进展。至少在50年前，大多数物理和虚拟机都以某种形式（非本地）提供了这些操作。』

在不了解子程序内涵的情况下，我们可以从上下文中得出几个结论：

1在函数级，子程序不提供新的函数，而是提供一种更简单的实现方法。
。目前，以太坊不支持子程序，但计算机行业支持。如果您想问，子程序提供了什么好处，它的成本是多少？原生支持会给以太坊带来多少改进，还是仅仅是一种技术上的理想？Eip-2315似乎解释不清楚。它只是提供了一些新的运算符，使EVM在本机上支持子例程。

好的，事实上，这些技术细节对于今天的讨论并不重要。

半公开争吵

我将GitHub和以太坊研究者论坛定义为开放领域，因为每个人都可以不受限制地阅读和参与讨论，并且可以使用电子邮件和RSS阅读器等互联网基础设施与他们进行交互。不和谐的信道和电报的公共组可以称为半公共域。虽然它可以无需访问就加入，但其协议相对封闭，与互联网基础设施的集成度较差，搜索引擎无法检索到它。

以太坊的半开放研究领域主要中心化在ETH研发的discord服务器上，大多数研究者可以对开放领域的信息进行检索、聚类和分析，但对半开放领域的投入较少，尤其是与财富效应关系不大的领域。显然，不仅是普通的研究人员，而且核心开发人员，例如SOLidness团队成员，很少参与这里的讨论。他们在推特上发表了反对eip-2315的论点。迈卡说：“为什么人们反对推特上的EIP？“，”；

Gcolvin对此表示强烈反对重启eip-2315的讨论。他认为，经过一年的充分讨论，就“适当论坛”达成了共识。在最初的讨论中，团结小组没有表示强烈反对。现在在twitter上反对是他们的自由，但这毫无意义。此外，他认为在这个过程中还存在一些问题：“稳固没有派代表去ACD”。遗憾的是，他们没有参与最终决策，但这不会影响eip-2315的决策。如果有什么可以改进的地方，那就是会议的议程，讨论这个话题的时候应该邀请相关的代表（显然，他也认为扎实可以提高决策能力，因为团队没有参与**的讨论，这使得这个过程不合适。

盖特客户的负责人彼得也表达了他的愤怒。他认为在**一刻改变升级要求是可怕的。既然代码和测试已经完成，世卫组织将重新测试并确保所有代码都可用。他认为，如果ACD决定推迟柏林的升级，这是可以接受的。在不保证原有升级计划的情况下删除eip-2315是不可接受的。

客户同意。他认为，如果你想在“推迟柏林升级”和“保留一个无用的EIP来修改EVM的核心功能”之间做出选择，**选择短期的痛苦。同时，如果eip-2315被移除，他愿意帮助重新测试。

维塔利克说，推迟柏林会议是不可接受的。

同时，SOLidness团队的Chris指出，他对EIP的现状感到困惑，因为它仍然是“草稿”。一个EIP草案怎么会包含在升级列表中？jameshancock说，这确实令人困惑，应该更好地管理这些状态，以便没有时间参与ACD的人也可以知道每个EIP的状态变化。

下面的讨论似乎不符合这一思路。亚历克赛、克里斯和维塔利克讨论了eip-2315中涉及的动态跳跃。彼得说，在这一点上，他已经删除了2315和成功同步，但这并不保证其他客户端也会工作。

Lightclient敦促大家尽快达成共识。他同意从柏林撤走eip-2315，原因仍基于内容。他认为，这项建议不会达到所声称的好处，但如果多数人同意可以继续，他就不应该反对这项建议。但是，由于“SOLid编译器的使用率远远超过了其他工具，而且他们的开发人员认为这个方案是无用的”，所以我们应该更仔细地对待这个方案。

Tkstanzak（荷兰的开发者）认为这甚至会导致“损害”，因为“无用的代码增加了EVM的复杂性，降低了它的运行速度，而且没有人声称要使用它”。这句话激怒了格考文，他说：“**。”不幸的是，我们有麻烦了。我们必须花一些时间来弄清楚为什么我们处于这种状况，但现在我们必须根据现有的信息作出最适当的决定。不幸的是，这个提议并没有让tkstanzak和gcolvin接受。他们开始了对话。对话的焦点是“是否有人真的愿意使用这一提议？“，”；

Gcolvin强调“子程序本身”是子程序的用例。如果有人反对这个建议，应该在过去两年的“以太坊魔术师论坛”的讨论中提出，固本团队甚至应该对ACD提出异议。

Tkstanzak认为，从来没有人给出过该提案的优点（例如，它可以将坚固性的效率提高到2%）。2020年1月，他向格索尔文提出要求，但没有继续讨论。在过去的两年里，他一直在等待这个问题的答案，没有人告诉他柏林什么时候会来。因此，柏林的延迟并不是什么大问题，因为除了eip-2929之外，没有特别重要的提案。他高度赞扬gcolvin是EVM的专家，但如果没有迹象表明他将利用他来提高可靠性或其他编辑，他为什么要对这个建议有如此高的信心？

他还做了一个很长的类比，大致意思是，汽车发动机的每一次设计更新都应该有一个很好的理由，但“这项技术从上世纪70年代就开始应用于飞机发动机”并不是一个合适的理由。因此，如果eip-2315的拆除将推迟柏林的升级，那么它必须是相同的。但他相信，我们可以在不拖延升级的情况下很好地取消这一提议。

提姆·贝科得出了两个结论。在未来的过程中，我们应该（1）明确每个EIP的需求方和原因，（2）应该更广泛地讨论ACD以提前收集异议。

在这个时候，哈德逊，在过去五年中的ACD协调员，澄清了他的立场，在这个沟通。他首先表达了对格考文专业知识的尊重，但批评了他的不礼貌态度。每个人都应该有一个高标准的自己，即使他是在冲动的情绪。至于程序，他认为“不必遵守先例”。工艺系统已经崩溃，需要根本性的改进。“，”；

戈尔文的情绪似乎有所缓和，但他仍然强调，ACD的决议不能被推翻。在他看来，这个过程是为了防止“**一刻的噪音”，而亚历克赛对此表示反对。

此时，Vyper团队表示他们将使用子例程带来的新特性。迈卡不认为这是一个安全问题，只是一个团队没有使用稳固性，所以没有必要在**一刻逆转这个过程。Lightclient也意味着接受。

PAWEL bylica对先前关于“草案”的讨论作了答复。他甚至不知道这个提议被接受了。他以为还在讨论中。至于EIP的现状，我们应该提供RSS feed风格的界面订阅，帮助人们了解自己关心的EIP的变化（不是每个人都有时间关心每一个EIP和ACD）。

这似乎启发了lightclient。

完美的总结

3月4日，lightclient整理了eip-2315事件的时间线[4]，并详细梳理了本方案生命过程中的所有重大事件。该提案最初在ACD80中讨论，**在ACD96中讨论，历时7个月。但最终没有得出结论。虽然第98次和第100次会议没有会议记录[5]，但不确定是否讨论了限制跳跃的问题。（但是，lightclient后来听取了整个会议（总共大约4个小时），并确认没有讨论该问题。）；

克里斯称赞lightclient的总结时间表，这证实了他的印象，即该提议从未被真正接受。此外，他重申了他对提案目标的怀疑。由于缺乏参与静态分析的专家，建议可能达不到降低燃气消耗的目的。

3月5日，lightclient做了**的陈述[6]，非常精彩

看来事态的发展往往会取消eip-2315，所以我长话短说。

在柏林部署eip-2315的理由来自于核心开发者大会过去关于接受eip的决定。我们有办法通过这个过程避免目前的状况，让生活更轻松。但只有当人们设计和实现时，这些过程才是密封的。所有人都会犯错误，而这些错误可以随时随地表现出来。我们不必成为自己创造的牺牲品。

此过程中发生错误，不应接受eip-2315。早在acd81，gETH团队就要求基准测试结果来证明EIP所声称的好处。基准测试从未做过。在ACD 84中，@souptcular将EIP移动到“accepted”。@Tkstanczak重申，如果有这样一个用例（改进的CodeGen+静态分析），他将支持这个提议。当没有发现满足这两个条件的用例时，这个提议被包含在柏林升级中。在acd86中，@made of tin承认，鉴于目前对该规范的争论，将EIP转变为“接受”还为时过早。甚至几个月后，当我能找到的**一个ACD调用中提到EIP时，@souptcular指出，围绕该规范仍然存在一些悬而未决的问题。@格考文说他会在魔术师论坛下解决这个问题，但他没有解决。

几乎在整个过程的每一步，@axic、@chfast和@chrisETH都表达了他们对这项提议的担忧。他们写了一份分析报告，并向EIP发布了一份PR，以避免跳入和跳出子程序——这可能是对EIP最强烈的投诉。不幸的是，由于某种原因，他们在去年秋天减少了对EIP的参与，因此这项提议在柏林的等待名单上保留了几个月。这使得那些不参与讨论其可行性的人认为EIP代表了正统。这个过程应该确保反对者的投诉得到解决，但事实并非如此。如果他们能继续战斗就更好了，但他们没有。他们已经战斗了几个月了——除非讨论，否则这个过程应该搁置EIP。

我不擅长抱怨这个EIP的技术方面，所以不适合评论。我希望@Alexey akhunov的想法结合@chfast的分析可以让你承认这个EIP是否有用仍然值得怀疑。虽然这是一个非常不寻常的提议，但它不是一个“个人问题”。我由衷地为干扰表示歉意。我打算在未来尽我所能避免这种情况再次发生。希望我们能够作为一个团体进行进一步的建设性对话，以改进EIP进程。

然后，lightclient击倒了法官的锤子。

该提案已被ACD 107接受。Eip-2315将从柏林撤走。

格考文也作了自己的总结。他回顾了自己的心路历程，并为自己的鲁莽道歉。**，他指出了核心开发者的使命：“我希望这一可悲的发展能够引起认真的反省——我们致力于一个目前市值1730亿美元的网络的研究、开发和管理。我不知道这个网络上有多少企业在运营，也不知道它能支撑多少人的生活。我们必须学会像专业人士一样操作。』

如何制定公共政策

事情似乎已经结束，但这一事件的影响是深远的。如果以太坊的开发者不能从中吸取教训，这种事情还会再次发生。公共政策的讨论可以分为几个层次。

1公共政策的内容

第一个层次是公共政策的内容是否具有“结果正义”。公共政策的目标是什么，其内容能否达到所宣称的目标，特别是在技术上是否可行。有多少人会从这个目标中受益，又有多少人会因此受苦？有没有其他的方法来实现它？首先，需要相关领域的专家对技术可行性和有效性进行评估。在这种情况下，几个技术专家的讨论就足够了。他们通过论坛和聊天工具进行了长期的讨论，虽然效率和深度都不高。在ACD会议上直接讨论专业问题显然不是一个好的决定。特别是，诸如“子程序”和“基准数据”的用例等具体问题没有得到明确的讨论。

第二个层次是公共政策的决策。也就是说，公共政策的执行是否符合“程序正义”，是否征求了足够的意见，是否通过了适当的表决，是否预留了足够的公示时间，避免侵害一些人员的利益。显然，ACD应该在没有达成共识的情况下负责将eip-2315纳入升级清单。特别是当有人怀疑eip-2315仍然是“草稿”时，过程组织者Pooja没有思考为什么会发生这种情况。相反，他只是简单地将“草稿”改为“审查”，这是相当自由和容易的。另外，应该有两个会议纪要要问责吗？

第三个层次是治理过程。本文无意讨论以太坊事件的治理大问题，只是从事件的吉祥之光中寻找对EIP在线进程的建议。例如，如何确定EIP的优先级？每一个EIP都需要一个支持者来推动。是否有必要指定一个对手来跟踪进展并不断提出建议？当ACD会议讨论特定的EIP时，是否应该召集所有相关的技术专家和开发团队？显然，eip-2315事件反映出现有的治理过程存在巨大缺陷。如果我们能召集坚实的团队成员参与ACD讨论，我们就不会让这种荒谬的事情发生。公共政策不仅需要专家的意见，更需要考虑多重利益的平衡。它还需要在合理的过程中作出决定，以确保效率而不犯错误。

显然，以太坊并不好。治理过程不完善，实施随意，使得对内容的讨论效率低下，无法深入，使制度建立在沙丘之上。

但与绝大多数区块链社区相比，以太坊已经是喜忧参半。

未经许可进入系统

在讨论非接入系统时，通常从“技术角度”出发，即普通人能否运行网络的所有节点，参与整个网络的技术共识。例如，任何人都可以跟踪和验证比特币和以太坊从出生之日起的所有历史。在追查这起事件的过程中，我深深地体会到，在信息层面，也要保持整个网络“不通”，让一个新进入者了解整个社会的来龙去脉。

以太坊怎么样？总之，就像今天的以太坊全节点一样，它可以同步所有的历史，但是成本太高，对硬件的要求也非常高。

如果研究人员想知道以太坊近年来是如何推广的，ACD和所有EIP讨论都是重要的参考资料，将在网上播放，并留下视频和会议记录（虽然漏掉了几个问题，但也漏掉了会议序列号）。此外，以太坊研究者论坛和以太坊魔术师论坛都是重要的讨论阵地。最近，以太坊凯瑟德斯对EIP的解读也非常精彩。一般来说，对于一个研究者来说，材料是相对充足的。然而，这些材料过于琐碎，缺乏结构化的安排。例如，如果你想知道EIP在哪些会议上被讨论过，谁发表了相关的意见，以便梳理研究背景和进行咨询，你需要花费大量的时间去查询。

此外，大量的信息散落在discord、reddit、各种AMA、GitHub评论区、个人博客中，大多数研究者无法有足够的精力和敏感度来跟踪这些。换句话说，同步这些历史太难了。以eip-2315为例，有多少人能解释它的起源和发展？如果lightclient没有理清时间线并提取“eip-2315从未被接受”的事实，那么这个错误的决定可能伴随着柏林升级。Tim beiko甚至没有在核心开发者会议记录中提到这个事件，更不用说反思了。

柏林经历了许多战争。幸运的是，这次得救了。感谢上帝的祝福。