以太坊开发者会议回顾：坎昆升级、硬分叉与布拉格

作者：Christine Kim Galaxy研讨副总裁；编译：秦晋 碳链价值

2024年1月4日，以太坊开发人员齐聚Zoom for All Core Developers Execution (ACDE) Call #178 上。ACDE电话会议通常由以太坊基金会协议负责人Tim Beiko主持，是一个开发人员评论和协调以太坊履行层（EL）改变的双周系列会议。本周的会议由一位网名为「Lightclient」的匿名Geth EL开发人员主持。开发人员再次承认了Cancun/Deneb（Dencun）晋级的接下来三个公共测验网激活日期。他们还评论了 Dencun之后的下一个硬分叉晋级Prague/Electra中代码更改（EIPs）的优先事项。

Dencun更新

假日期间没有对Dencun晋级进行详细更新。自12月21日前次ACDE 电话会议以来，客户端团队一直在为Goerli 测验网预备新版别。因为之前因Prysm导致晋级测验延迟，Geth开发者Marius van der Wijden 要求Prysm客户端团队提供他们切开新版别的最新发展。Prysm开发者Terence Tsao证实，Prysm团队将在下周预备好Goerli 硬分叉的新版别。不过，针对Goerli的版别将是一个「预发布」版别，这意味着它不会是推荐在以太坊主网上运用的Prysm版别。在Goerli硬分叉之后，Prysm团队方案发布另一个版别，其间包括某些更改和更新，推荐用户在主网上运行，并在Sepolia或Holesky测验网进步行测验。

虽然Tsao标明Prysm团队对Goerli硬分叉激活日期为1月17日感到满足，正如ACDE #177上评论的那样，但他主张在Goerli硬分叉之后再确定Sepolia和Holesky硬分叉激活日期。自ACDE #177以来，以太坊基金会协议支撑负责人Tim Beiko已为Goerli、Sepolia和Holesky 这三个以太坊公共测验网提出了公共测验网分叉时刻。主张的分叉激活时刻如下：

Goerli--2024年1月17日--纪元231680--时刻戳1705473120

Sepolia--2024年1月30日--纪元132608--时刻戳1706655072

Holesky--2024年2月7日--纪元29696—时刻戳1707305664

Lightclient问询Prysm之外的其他客户端团队是否赞同Beiko提出的 Goerli硬分叉激活时刻。参加电话会议的所有客户端团队（包括Geth、Lodestar、Lighthouse、Teku和Besu）都承认，他们以为机遇不错，最迟下周就能为Goerli节点操作员发布版别。Lighthouse客户端团队指出，鉴于他们仍在测验其客户端的某些网络功用，他们发布的版别或许与Prysm相同是预发布版别。

Dencun时刻线不合

随后，Lightclient就Sepolia和Holesky测验网的主张激活时刻展开评论。一位网名为「Potuz」的Prysm开发者（化名）主张暂缓确定主网之前终究两个测验网的晋级日期。「咱们应该尽量不要现在就许诺日期，因为Goerli的作业或许并不顺利，从那里回来是个问题。添加一个具有正确纪元的新版别，不做任何改动是很简单的。删去一个版别并修正过错则是个问题。这比几周的时刻要长得多，」Potuz标明。

Lightclient着重说，客户端团队在Goerli硬分叉一周后才需求发布新版别，因而，除非在1月24日或之后在Goerli上发现晋级问题，否则不一定要删去新版别。Geth开发者Marius van der Wijden标明，他以为为Sepolia和Holesky测验网设定日期并没有什么害处，因为假如Goerli上出现问题，开发者能够随时更改日期。

以太坊基金会DevOps工程师巴纳巴斯-布萨（Barnabas Busa）在 Zoom谈天室中写道，在他看来，只要在承认Goerli的版别正常运行后，才有必要为Sepolia和Holesky 的晋级发布新版别。一位网名为「Sean」的Lighthouse开发者赞同这一观念，他说开发者能够为Sepolia硬分叉设定一个「暂定」日期，但在1月30日之前应该先看看Goerli的发展状况。

Potuz主张在Goerli和Sepolia 硬分叉激活之间添加一周的测验时刻，基本上用两周时刻进行剖析，而不是三周。他说，添加一周的测验时刻能够让客户端发行版「浸泡」几天，然后客户端团队才需求为下一次测验网晋级再次切开新版别。「两周时刻太近了。这便是我要指出的问题。」Potuz弥补说，假如Goerli客户端发行版得到了充分的剖析和测验，那么在Sepolia和Holesky硬分叉激活之间或许不需求三周的周转时刻。

Potuz的观念引发了争议。以太坊基金会的安斯加-迪特里希斯（Ansgar Dietrichs）称，晋级的第一个公共测验网激活与晋级的主网激活之间的时刻通常是开发者的「截止时刻」，不需求延伸。不过，Dietrichs也指出，关于延伸测验网晋级间隔时刻的愿望，开发者应该在硬分叉布景下更认真地评论，而不仅仅是Dencun晋级。Dietrichs说：「假如有人期望有一个更绵长的过程，那么咱们应该在有时刻的时候评论这个问题，而不是在硬分叉之前。」

Lightclient赞同Dietrichs的观念，以为假如早在10月份就进行评论，开发者很或许会对延伸Dencun的测验网时刻表更加宽恕。Lightclient说：我以为还有一部分原因是，咱们想在去年秋天完结晋级，所以现在咱们真的在努力完结这一方针，我以为咱们的时刻表组织应该更活跃一些。

坚持活跃的时刻表

依据开发者在电话会议上分享的观念，以太坊基金会DevOps工程师 Parithosh Jayanthi 主张将Sepolia硬分叉晋级推迟一周左右，并将 Sepolia硬分叉的日期定在Goerli晋级之后的1月25日ACDE电话会议上。Marius van der Wijden对立完全依赖ACDE电话来从头评论测验网晋级激活的日期。他说：「我真正期望防止的是，咱们不得不再打一次 All Core Devs电话来承认日期，」他弥补说：我讨厌再打一次 All Core Devs电话，仅仅为了说「好把，Sepolia现在能够开端了。」而现在咱们必须等候两周，才能够真正开端完结Sepolia。

为了安慰各方的心情，Geth开发者Guillaume Ballet主张为Sepolia硬分叉创立两套暂定日期，假如Goerli硬分叉的结果是活跃的，开发者能够坚持运用其间一套日期；假如Goerli硬分叉的结果是消沉的，开发者能够运用另一套日期。但是，Lightclient和Dietrichs都对立这个想法，因为在开发者为Sepolia硬分叉设定新的时刻表之前，必须先对Goerli上的过错和问题的性质进行评价。

顺便说一句，以太坊基金会测验团队的一位网名为「Danceratopz」的化名开发者问询，开发者是否想等评价完Goerli测验网络上的blob过期问题后再晋级Sepolia。作为布景常识，blob过期指的是在大约两周后从以太坊状态中删去blob数据。

来自Lighthouse的Sean和Besu团队的Justin Florentine都拥护在主网激活Dencun之前，先在三个测验网之一上评价blob到期状况。Florentine着重说，在测验网上等候blob到期也将有利于第二层Rollup协议团队和运用开发人员为Dencun晋级做好预备。来自 Lighthouse的Sean说，虽然在Goerli上调查blob过期并不是必要的，但这或许是延伸Sepolia和Holesky之间测验期的一个原因，这样开发人员和第二层团队就能够在Sepolia上经历整个blob生命周期。电话会议上，其他开发人员没有明确赞同Sean的主张。

相反，Lightclient在电话会议上问询开发人员是否愿意坚持Beiko提出的时刻表，即1月30日晋级Sepolia，一周后的2月7日晋级 Holesky。因为开发人员没有更多的不赞同见，Lightclient标明开发人员将坚持本来的时刻表。Potuz在Zoom谈天中写道，他期望在2月7日一起晋级Sepolia和Holesky测验网，而不是提早一周晋级前者。在通话后的Discord音讯中，Lightclient再次承认Dencun的测验网时刻表暂时保持不变。

Prague/Electra

接下来，开发人员评论了Dencun之后的下一次晋级（Prague/Electra）应优先考虑哪些EIP。Marius van der Wijden说，开发人员应集中精力完结Prague/Electra的默克尔树晋级，而不是其他EIP。他对这一观念弥补了两点注意事项，首先是默克尔树的预备状况。正如在 ACDE #177上所评论的，开发人员正方案召开一次专门的ACDE电话会议，深入探讨默克尔树的施行细节及其硬分叉晋级的预备状况。

Van der Wijden说到的第二个注意事项是将EL上的晋级与一致层（CL）解耦的才能。Van der Wijden 说到，CL上有一些「高优先级、超级紧急」的EIP，或许需求比EL上的默克尔树晋级更快地施行。「我以为重要的是，一致层人员要评论他们是否有必要对这些[紧急]改变进行硬分叉，是否能够在没有EL参加的状况下完结，或许是否需求EL 参加，而咱们无论怎么都需求进行联合硬分叉，然后我能够接受一个较小的硬分叉」。van der Wijden 说：「所以，默克尔树绝对是重中之重，咱们应该在考虑到这两点的状况下推进它。」

以太坊基金会研讨员安斯加-迪特里希斯（Ansgar Dietrichs）在Zoom 谈天室中写道，他「激烈对立」将Prague/Electra晋级要点放在默克尔树上，因为考虑到默克尔树所需的代码更改的复杂性，这很或许意味着晋级要推迟到2025年。Nethermind客户端开发人员Lukasz Rozmej也赞同Dietrichs的观念。Rozmej说：「我的经验告诉我，状态的从头规划是十分困难的，而且需求十分长的时刻，」他弥补说，「虽然我以为默克尔树十分好，而且正在取得巨大进步，但我以为假如咱们只重视默克尔，下一次硬分叉至少需求一年乃至更长的时刻。因而，我的主张是，或许会专心于一些较小的硬分叉，一起每个团队都会致力于默克尔，并为这个主题分配适当的资源、作业量、脑力，无论你怎样称呼它。」

聚集默克尔

关于Prague/Electra应专心于默克尔仍是优先考虑比默克尔更快发布的较小代码改变，开发人员定见不一。Ballet着重，在他看来，「不存在小分叉」，开发者在施行默克尔之前等候的时刻越长，施行以太坊状态更新的难度就越大。Tomasz K. Stańczak也是Nethermind客户端的开发者，他主张采纳一种雄心壮志的方法，许诺采用比Prague/Electra或许包括的更多的EIP。[让咱们]运用团队的才能，在这一年里，咱们必须证明咱们能够应对最大的应战。假如默克尔终究向团队标明，到3月份有越来越多困难堆积起来，那么人们或许会再次提出疑问，并说「好吧，默克尔下课」。但咱们会持续运用咱们将包括在内的一套相当不错的其他EIP，Stańczak说道，他指定除默克尔之外，Prague/Electr还或许包括的其他一些重要EIP，如与质押、从头质押与账户抽象相关的EIP。

Lightclien在答复Stańczak的问题时说，开发人员在许诺采用一套EIP之后，或许很难持续评论Prague/Electra中应该包括哪些EIP，而其间一个EIP（指默克尔）是「一个需求18到24个月的项目」。Erigon客户端的开发者安德鲁-阿西克明（Andrew Ashikhmin）拥护在布Prague/Electra分叉中发布较小的EIP，并一起开发默克尔，以便在之后的分叉中运用。Ballet拥护Stańczak的主张，即在Prague/Electra 中要点开发默克尔，假如发现其施行过程中存在重大问题，需求更多时刻来处理，则将其从晋级中删去。

聚集CL晋级

关于将EL(履行层)和CL（一致层）晋级解耦的问题，Potuz说到，Prague/Electra只要一个EIP提议只需求对CL进行更改。「唯一的改变是取消了认证索引委员会......以及所有其他改变，即使是那些看起来只触及CL的改变，如 Max EB，也取决于EL的其他改变。因而，我以为朴实的CL分叉是不会发生的。至少，我以为今年不会，下一年也不会。咱们没有满足的纯CL提案，」Potuz说。

尽管如此，Ansgar Dietrichs仍是说，有些EIP主要是以CL为中心的晋级，只需求对EL稍作改动，EL客户端团队就能够轻松履行。这些 EIP仍需求EL和CL协调硬分叉。Dietrichs随后弥补说，他以为从CL方面来看，数据可用性采样（DAS）是EIP 4844之后最重要的代码改变。Dietrichs和Lightclient就DAS是否需求硬分叉来完结存在一些不合。

重视EOF和其他EIP

一位网名为「Rodiazet」的化名开发者在以太坊基金会的Ipsilon团队作业，该团队致力于以太坊虚拟机（EVM）的研讨。作为布景，EOF 是EVM Object Format的缩写，是对EVM的一系列改进，最初被考虑纳入Cancun/Deneb晋级中。

除默克尔外，开发人员还提出一些其他EIP供考虑，如EIP 5920（PAY 操作码）和EIP 2537（BLS12-381曲线操作的预编译）。Prague/Electra候选EIP的完好列表能够在以太坊魔术师网站上的晋级元线程中找到。虽然大多数开发者都拥护在Cancun/Deneb会议之后在某种程度上优先考虑默克尔，但现在还不清楚在多大程度上默克尔应被优先用于Prague/Electra，而不是那些在2024年能够更快、更简单完结的小型 EIP。Lightclient着重，开发者无需在本周的电话会议上就Prague/Electra的内容做出终究决议。他主张在即将举行的ACDE电话会议上持续评论该主题。

随后，开发人员很快谈到了Prague/Electra主题中尚未在通话中评论的EIP，包括但不限于以下EIP：

EIP-7002：履行层可触发退出

EIP-7549：将委员会索引移至认证之外

EIP-3074：AUTH和AUTHCALL操作码

EIP-6110: 在链上提供验证器存款

EIP-6913: SETCODE指令

EIP-7377: 搬迁业务

EIP-4444：履行客户端中的绑定历史数据

EIP-6404：SSZ买卖根

EIP-6465：SSZ提取根

EIP-6466：SSZ 收据根

EIP-7212：预编译secp256r1的曲线支撑

有关对上述EIP的看法的详细概述，请参阅YouTube上发布的完好通话录音。

正式确定EIP 7587

终究，以太坊基金会研讨员Carl Beekhuizen重提了有关EIP 7587的评论，该评论将保存一组预编译地址，供第二层协议运用。Beekhuizen 问询开发人员怎么才能最好地将EIP正式化，使其成为一个信息性的 EIP，为往后的以太坊治理流程创立规范。Nethermind开发者Ahmad Bitar主张将EIP纳入EIP 1文件，该文件概述了EIP流程的指导方针。Lightclient主张在以太坊魔术师网站进步一步评论这个论题，并在下一次ACDE电话会议上依据需求从头评论这个论题。

此时快讯

【OpenAI和微软遭集体诉讼，被指控窃取他人作品训练AI模型】金色财经报道，近日，美国著名非小说类作家Nicholas A. Basbanes和Nicholas Gage联手发起集体诉讼，指控OpenAI和微软在未经许可的情况下，利用包括原告作品在内的海量版权内容训练其大型语言模型 (LLM)，侵犯了包括原告在内的众多作家的知识产权，该诉讼指控OpenAI和微软的行为构成“对版权作品的恶意大规模窃取”。（财联社）