比特币交易平台

比特币交易平台
比特币交易平台_比特币价格走势_比特币挖矿_如何购买比特币_比特币最新价格

删除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中,@[email protected],如果有这样一个用例(改进的CodeGen+静态分析),他将支持这个提议。当没有发现满足这两个条件的用例时,这个提议被包含在柏林升级中。在acd86中,@made of tin承认,鉴于目前对该规范的争论,将EIP转变为“接受”还为时过早。甚至几个月后,当我能找到的最后一个ACD调用中提到EIP时,@souptcular指出,[email protected]��说他会在魔术师论坛下解决这个问题,但他没有解决。

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

我不擅长抱怨这个EIP的技术方面,[email protected] [email protected][email protected]�的提议,但它不是一个“个人问题”。我由衷地为干扰表示歉意。我打算在未来尽我所能避免这种情况再次发生。希望我们能够作为一个团体进行进一步的建设性对话,以改进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甚至没有在核心开发者会议记录中提到这个事件,更不用说反思了。

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





上一篇:美国国税局数字项目计划使用人工智能跟踪加密货币交易
下一篇:丁佳永:比特币价格延续震荡 以太坊能否上行破位2100

相关推荐