柏林升级前移除 EIP-2315,以太坊该如何制定公共政策?柏林升级前移除 EIP-2315,以太坊该如何制定公共政策? 2020.10.28 上海以太坊社区聚会 Eth2 圆桌记录

EIP-2315 被列入柏林升级并不符合流程,以太坊治理程序不够完善的问题需要引起关注。

原文标题:《移除 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 年前,大多数物理机和虚拟机都以某种形式(非原生地)提供这些操作。」

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

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

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

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

看来事情的发展倾向于取消 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 没有反思为什么出现这种情况,而是简单将「草稿」改成「审议」,颇有种打那指那的洒脱。此外,有两次会议缺少会议记录,是否应当有人需要问责?

第三层是治理程序。本文无意探讨以太坊的治理这一宏大问题,仅从本次事件的吉光片羽中找出关于 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 在核心开发者会议纪要中甚至没有提到这一事件,更不要说反思了。

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

Click to rate this post!
[Total: 0 Average: 0]

人已赞赏
名家说每日优选行情分析

Kava 5 主网升级完成,详解主要功能及 HARD 跨链货币市场Kava 5 主网升级完成,详解主要功能及 HARD 跨链货币市场 一张图读懂:盘点支持比特币支付薪水的大型企业

2021-4-9 16:19:23

名家说每日优选行情分析

美联储主席警示疫情状况,货币政策将如何影响比特币市场?美联储主席警示疫情状况,货币政策将如何影响比特币市场? 碳排放与环保 未来比特币挖矿的最大威胁 或是杞人忧天 如何应对

2021-4-9 16:19:45

0 条回复 A文章作者 M管理员
    暂无讨论,说说你的看法吧
个人中心
购物车
优惠劵
今日签到
有新私信 私信列表
有新消息 消息中心
搜索