干货

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

曾汨   |     |   2081 次阅读

编者注:本文首发于公众号 “因雨成歌”,EthFans 经授权转载。

背景

以太坊的柏林硬分叉 [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 年前,大多数物理机和虚拟机都以某种形式(非原生地)提供这些操作。』

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

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

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

半公开领域的争吵

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

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

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

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

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

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

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

接下来的讨论似乎没有沿着这条路线前进,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 专业知识的尊重,但批判了他的无礼态度,每个人应当都对自己有高标准,即使在情绪冲动时。而关于议事流程,他认为『先例并不是一定要遵守的。流程系统已经崩溃了,需要根本的改善。』

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

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

而此前关于『DRAFT』的讨论得到了 Pawel Bylica 的回应,他认为他甚至不知道这个提案被接受了,他以为还在讨论呢,关于 EIP 的状态,应当提供 RSS Feed 样式的接口订阅,以帮助大家了解自己关心的 EIP 的变更(不是每个人都会有时间关心每个 EIP,每次 ACD)。

这似乎给了 lightclient 灵感。

一次完美的总结

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

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

3 月 5 日,lightclient 作出了最终陈述 [6],非常精彩,全文翻译如下:

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

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

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

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

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

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

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

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

如何制定公共政策

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

  1. 公共政策的内容
  2. 公共政策的决策
  3. 治理程序的完备

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

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

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

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

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

再议无准入(permissionless)的系统

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

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

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

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

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

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

[2]https://github.com/ethereum/pm/issues/263

[3]https://eips.ethereum.org/EIPS/eip-2315

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

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

[6]https://github.com/ethereum/EIPs/pull/3309

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

(完)


原文链接: https://mp.weixin.qq.com/s/7lXzB8oheAKo45X1cq2Oow
作者: 姚翔


你可能还会喜欢:

改进以太坊网络的升级流程

一种 EIP 流程改进思路

以太坊治理的全景

 
0 人喜欢