SOLID:移除EIP-2315：以太坊柏林升级前的紧急刹车

作者：因雨成歌

背景

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

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

多方争论

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

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

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

TimBeiko的协调人）总结了各客户端团队的意见。Geth团队希望等待ACD的决议，而其它客户端团队则表示对保留2315无异议。

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

数据：一巨鲸从Gearbox移除1000万枚USDC后存入Aave并借入1000枚ETH:金色财经报道，据PeckShield监测，czsb.eth地址从Gearbox USDC池中移除1000万枚USDC流动性，之后存至AaveV2后借入1000枚ETH（约合127万美元），并将这些ETH转入币安。[2022/12/13 21:41:44]

EIP-2315到底是什么

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

无需了解子程序的内涵，从上下文中也可以得出几个结论：

1.在功能层面，子程序并没有提供新的功能，而是提供了更简便的实现方法。2.目前以太坊不原生支持子程序，而计算机行业是支持的。如果要问，子程序到底提供了什么好处，它的代价又是什么？原生支持究竟会为以太坊带来多少提升，还是说仅仅是一个技术理想？EIP-2315似乎并没有解释清楚，它只是给出了一些新的操作符，让EVM原生支持子程序。

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

半公开领域的争吵

我把github、以太坊研究者论坛定义为公开领域，因为每个人都可以不受限制地阅读和参与讨论，并可以使用邮件、RSS阅读器等互联网基础设施与之交互。而discord的频道、telegram的公开群组则可称作半公开领域。尽管无需准入就可以加入，但由于其协议相对封闭，与互联网基础设施的集成较差，且无法被搜索引擎检索。

以太坊研究的半公开领域集中在『EthR&D;』的discord服务器上。大部分研究者可以做到对公开领域信息的检索、聚类和分析，但对半公开领域则投入相对较少，尤其是当它和财富效应关系较小时。显然，不仅普通研究者是这样，核心开发者们——例如solidity的团队成员也极少参与这里的讨论，他们在推特上发表了对EIP-2315的反对论点。Micah表示不解：『为什么人们要在推特上反对EIP？』

OpenSea：支持X2Y2强制征收版税，已将其从黑名单中移除:金色财经报道，据 X2Y2 在社交媒体披露，该 NFT 市场将恢复强制征收版税策略并表示：“我们曾经认为处理版税的最佳方式是给创作者和交易者双方选择的权利，但在借鉴其同行 OpenSea 的做法后决定恢复强制征收版税。”X2Y2 补充称，他们已经使用删除了所有新上架的“灵活版税”设置。OpenSea 随后回复支持 X2Y2 的做法，并表示已经将 X2Y2 从其 OperatorFilter 黑名单中移除。[2022/11/21 7:51:44]

gcolvin在discord上对重启EIP-2315的讨论表示了强烈的反对，他认为这已经被充分讨论并在『合适的论坛』上达成了共识，长达一年之久。Solidity团队在当初的讨论中并未表示强烈的反对，现在他们在推特上反对是他们的自由，但已经没有意义了。此外，他认为在流程上存在一些问题，『Solidity没有派代表参加ACD』，很遗憾他们没有参与最终决策，但这不会影响EIP-2315的决策，如果说有可改进的地方，那就是会议议程，应当在讨论议题时邀请相关代表。

Geth客户端的负责人Peter也表达了自己的愤怒。他认为在最后时刻去改变升级需求是可怕的，由于代码和测试都已经完成，谁来重新测试，并且保证所有代码可用。他认为，如果ACD决定推迟Berlin升级，这还可以接受。在保证原升级时间表的情况下删除EIP-2315是不可接受的。

lightclient表示同意。他认为如果要在『推迟Berlin升级』和『保留一个无用却会修改EVM核心功能的EIP』中选择，那还不如选择短痛。同时，如果要删除EIP-2315，他愿意帮助重新测试。

Vitalik表示，推迟Berlin不可接受。

与此同时，solidity团队的Chris指出，他对此EIP的状态表示疑惑，因为它仍然是『DRAFT』，一个草案EIP怎么已经列入了升级列表了呢？JamesHancock说，这确实令人困惑，应当更好地管理这些状态，让没有时间参加ACD的人也可以知道每个EIP的状态变更。

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

火币全球站将于10月16日移除部分交易对:火币全球站宣布将于10月16日16:00移除以下交易对：APPC/ETH，MTX/ETH，PORTAL/ETH，SOC/ETH，STK/ETH，TOS/ETH。持有以上资产的用户可选择其他交易对进行交易。[2020/10/13]

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

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

动态 | BitMEX质疑币安期货合约文档涉嫌抄袭，赵长鹏予以回应并进行修改/移除:BitMEX发推称：“祝贺币安推出期货合约。很高兴看到您喜欢阅读我们的文档，就像我们喜欢编写文档一样。”。BitMEX首席执行官Arthur Hayes转发了推文且@赵长鹏，并称：你可以做得更好。附赠的图片文字显示：“- 我可以抄你的作业吗？- 可以啊，但要稍微改变一下，这样看起来就不那么明显了。”疑似暗指币安期货合约测试网相关文档涉嫌抄袭BitMEX。 对此，赵长鹏回应称：真是抱歉。我们在尽职调查中忽略了这一点（没有自己阅读BitMex文档）。我们会尽快修改/删除。同时附上了币安期货A平台的官方文件链接。[2019/9/4]

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

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

gcolvin的情绪似乎有些缓和，但仍在强调ACD的决议不可推翻。在他看来，流程就是为了防止『最后时刻的噪音』，这被Alexey反对。

此时，Vyper团队表示他们会使用子程序带来的新特性。Micah认为这不是什么安全性问题，而仅仅是Solidity一个团队不使用它而已，因此没必要在最后时刻推翻流程。lightclient也表示接受。

而此前关于『DRAFT』的讨论得到了PawelBylica的回应，他认为他甚至不知道这个提案被接受了，他以为还在讨论呢，关于EIP的状态，应当提供RSSFeed样式的接口订阅，以帮助大家了解自己关心的EIP的变更。

这似乎给了lightclient灵感。

一次完美的总结

3月4日，lightclient整理了EIP-2315事件的时间线，详细梳理了此提案生命流程中的所有大事件。该提案首次被列入讨论是ACD80，最后一次讨论是ACD96，跨度7个月。但最终并没有达成结论。尽管第98和100次会议没有会议记录，所以无法确定是否讨论了限制跳转的问题。，确认了并未讨论这一议题。）

公告 | Pundi X：将于5月11日从总供应量中永久移除约69亿枚NPXSXEM和75亿枚NPXS:5月4日，Pundi X官方发布消息称，2019年第一季度的NPXS和NPXSXEM代币移除将于5月11日进行。移除数量分别为：NPXSXEM：6,952,786,956.99（约69亿枚）；NPXS：7,592,770,954.46（约75亿枚），一共将从总供应量中永久移除14,545,557,911.45（约145亿枚）代币。[2019/5/4]

chriseth赞美了lightclient总结的时间线，这印证了他的印象即此提案从未被真正地接受过。此外，他重新陈述了对此提案目标的质疑，由于缺少静态分析的专家参与，且该提案可能无法起到减少gas消耗的目标。

3月5日，lightclient作出了最终陈述，非常精彩，全文翻译如下：

看来事情的发展倾向于取消EIP-2315，所以我长话短说。

支持EIP-2315部署在柏林的人的论据来自核心开发者会议过去关于接受这个EIP的决议。我们有办法通过流程避免当下的状况，并让生活变得更简单。可只有当人们设计并实施时，这些流程才是密不透风的。人类都会犯错，这些错误随时随地都有可能表现出来。我们没有必要成为自己创作品的受害者。

在此流程中出现了一个错误，EIP-2315不该被接受。早在ACD81，Geth团队就要求提供基准测试的结果，以证明此EIP所声称的收益。基准测试一直没有人做。在ACD84中，@Souptacular动议将EIP移至『接受(Accepted)』。@tkstanczak重申，如果存在这样的用例，他就会支持提案。在没有找到符合这两个条件的用例时，此提案被列入了柏林升级。在ACD86中，@MadeofTin承认，考虑到关于规范的持续争论，将EIP转为『接受』还为时过早。甚至在几个月后，在我能找到的最后一次ACD电话中提到EIP的时候，@Souptacular指出，围绕着这个规范还有一些悬而未决的问题。@gcolvin表示会在魔术师论坛中线下解决，但并没有解决。

在整个过程中，几乎每一步骤中，@axic、@chfast和@chriseth都在表达对该提案的担忧。他们写了一份分析，并向EIP开了一个PR，以避免跳入和跳出子程序——这可能是对EIP最强烈的抱怨。不幸的是，由于某些原因，他们在去年秋天减少了对EIP的参与，因此这个提案设法在柏林的备审清单上停留了几个月的时间。这让那些不参与讨论其可行性的人以为这个EIP代表了正统性。流程本该保证反对者的抱怨得到解决，但事实并非如此。如果他们能继续与之抗争，那就更好了，但他们没有。他们已经花了几个月的时间去斗争--这个流程本应把此EIP搁置，除非讨论解决。

我对关于此EIP的技术方面的抱怨并不擅长，因此不适合发表评论。希望@AlexeyAkhunov的想法结合@chfast的分析，足以让诸位承认这个EIP是否有用仍是存疑的。虽然这是一个极不寻常的提议，但并非是『私人问题』。我对于造成的干扰表示诚挚的歉意。我打算今后尽自己的努力，避免这种情况再次发生。希望我们能够作为一个团体进行进一步的建设性对话，以改善EIP流程。

随后，lightclient敲下了法官的重锤。

这项建议已被ACD107接受。EIP-2315将从柏林移除。

gcolvin也作出了自己的总结，他回顾了自己的心路历程，并对自己的鲁莽表示歉意。在最后，他指出了核心开发者的使命：『我希望这种可悲的事态发展能够引发严肃的反省--我们已投身于一个目前市值1730亿美元的网络的研究、开发和管理。我不知道有多少业务在这个网络上运行，也不知道它支持了多少人的生活。我们必须学会像专业人员一样操作。』

如何制定公共政策

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

公共政策的内容

公共政策的决策

治理程序的完备

第一层是公共政策的内容是否具有『结果正义』。公共政策的目标是什么，其内容是否可以实现声称的目标，尤其是技术上是否具有可行性。实现这个目标会让多少人受益，让多少人受损，是否有其它实现方式？在一层，主要需要相关领域的专家对技术可行性及其效用进行评估。在此案例中，几位技术专家的讨论还是比较充分的，他们通过论坛、聊天工具展开了长期的探讨，虽然谈不上多高效，也谈不上有多么深入。直接在ACD这类全员会议上展开专业问题的讨论，显然不是什么好的决定。尤其是针对『子程序』的用例，『基准测试数据』等具体问题，并没有讨论清楚。

第二层是公共政策的决策。即公共政策的推行是否符合『程序正义』，是否征询了足够多人员的意见，是否经过了合适的表决，是否留有足够多公示时间以避免侵犯到部分人员的利益。很显然，此次事件中，ACD在提案没有得到共识的情况下就将EIP-2315列入升级列表，应负有重大责任。尤其当有人质疑EIP-2315的状态还是『草稿』时，流程组织者Pooja没有反思为什么出现这种情况，而是简单将『草稿』改成『审议』，颇有种打那指那的洒脱。此外，有两次会议缺少会议记录，是否应当有人需要问责？

第三层是治理程序。本文无意探讨以太坊的治理这一宏大问题，仅从本次事件的吉光片羽中找出关于EIP的上线流程的建议。譬如，如何判定EIP的优先级？每个EIP除了需要一个支持者，一直推进，是否还需要指定一个反对者，始终跟踪进度并持续提出建议？ACD会议讨论具体的EIP时，是否应召集所有相关的技术专家和开发者团队到场？很显然，EIP-2315事件反映出现有治理程序存在巨大缺陷。如果在ACD讨论时，能叫上solidity团队成员参与，就不会让这么荒诞的事情发生。公共政策既需要专家的意见，也需要考虑多方利益的均衡，更需要在合理的流程下达成决策，这样才能在保证效率的情况下不至于犯错。

很显然，以太坊做得算不上好。治理程序不够完善，执行更是信马由缰，这让针对内容的讨论低效且无法深入，让系统建立在沙丘上。

但相比于绝大多数区块链社区，以太坊这已经是幸福的烦恼了。

再议无准入(permissionless)的系统

我们一般讨论无准入系统时，往往是从“技术视角”切入的，即普通人是否可以运行网络的全节点，并参与整个网络的技术共识。例如，任何都可以从诞生之日起，追踪并验证比特币和以太坊的所有历史。在追踪这一事件的过程中，我深刻意识到在信息层面，也需要让整个网络保持『无准入』，这样一个新加入的人才能理解整个社区从哪里来，要到哪里去。

以太坊究竟做得怎么样呢？简而言之，就和今天的以太坊全节点一样，可以同步所有历史，但成本太高，对硬件的要求也很高。

如果一个研究者想知道以太坊这些年是如何推进的，ACD和所有EIP的讨论都是重要的参考资料，这些都会在线直播，并且留下视频和会议记录。此外，以太坊研究者论坛和以太坊魔术师论坛都是重要的讨论阵地，近来EthereumCatHerders关于EIP的解读也非常精彩。总体来说，对于一个研究者来说，素材是比较充分的。然而，这些素材过于琐碎，缺少结构化的整理。例如，想知道某一个EIP在哪些会议中被讨论过，以及哪些人曾经发表过相关意见，以便梳理研究脉络和请教，就需要研究者花费大量时间去查询。

此外，散落在discord、reddit、各类AMA、github评论区、个人博客上的信息浩如烟海，大部分研究者无法有足够的精力和敏锐度去追踪这些。换而言之，要同步这些历史太难了。以EIP-2315为例，有几个人能说得清楚它的来龙去脉？若不是lightclient把时间线梳理清楚，并且提炼出『EIP-2315从未被接受过』的事实，这个错误的决定可能就浑水摸鱼伴随着柏林升级进行了。而TimBeiko在核心开发者会议纪要中甚至没有提到这一事件，更不要说反思了。

柏林曾经受过多次战争的苦难，好在这一次它被拯救了，唯有感谢上苍保佑。

https://github.com/ethereum/eth1.0-specs/blob/master/network-upgrades/berlin.md

https://github.com/ethereum/pm/issues/263

https://eips.ethereum.org/EIPS/eip-2315

https://github.com/ethereum/pm/issues/263#issuecomment-790381273

https://github.com/ethereum/pm/issues/263#issuecomment-790910171

https://github.com/ethereum/EIPs/pull/3309

https://hackmd.io/@timbeiko/acd-update-001

标签：ETH以太坊DITSOLIDether币价格以太坊币怎么挖矿的StarCreditsMOSOLID

中币交易所热门资讯