以太坊核心开发者执行最新会议摘要:新CL代码规范、Devnet-10启动条件,以及区块延迟分析
CL 规范 1.4.0-beta.3 版本的更改将在下一个开发网络 Devnet-10 上进行测试。
原文标题:Ethereum All Core Developers Consensus Call #120 Writeup
原文作者:Christine Kim
原文来源:galaxy
编译:Luccy,BlockBeats
上一次会议
在 10 月 19 日,以太坊开发人员齐聚 Zoom 参加了 All Core Developers Execution (ACDE) Call #120 会议。ACDE 电话会议是一个每两周举行一次的系列会议,由以太坊基金会研究员 Danny Ryan 主持,开发人员在会上讨论和协调对以太坊共识层(CL)的更改。本周,开发者们主要关注以下议题的进展:
1. CL 规范的 1.4.0-beta.3 版本;
2. Devnet-10 的启动条件;
3. Gajinder Singh 对 blob 延迟进行分析,他是一位维护 Lodestar 和 EthereumJS 客户端的软件开发者。
召唤(The Summoning)
Danny Ryan 宣布发布了 Cancun/Deneb(Dencun)升级的新 CL 代码规范,被称为「召唤」。这个版本在 CL GitHub 仓库中被正式标记为 1.4.0-beta.3 版本,主要包含两个变更:
1. 主网 KZG 配置:完成了以太坊可信设置仪式输出所需的格式化工作,并将其包含在最新的 CL 规范发布中。
2. 新的八卦规则:Teku 开发者 Enrico Del Fante 创建了一个新的八卦规则,以确保 CL 节点不会传播超过每个区块最大 blob 数量的 blob,目前规范中定义的每个区块的 blob 数量为六个。这将确保验证者不能用超过每个区块六个 blob 的无效消息垃圾邮件网络。
Devnet-10
CL 规范 1.4.0-beta.3 版本的更改将在下一个开发网络 Devnet-10 上进行测试。然而,Devnet-10 的启动还有一些障碍。以太坊基金会的 DevOps 工程师 Barnabas Busa 表示,他仍在等待客户端团队发布新的软件版本。一旦这些准备就绪,Busa 希望在 10 月 20 日(周二)的某个时候启动下一个开发网络。
使用化名「Potuz」的 Prysm 客户端的开发者指出,最新的 CL 规范中包含的主网 KZG 配置在对「go-kzg」进行更改之前无法合并到 Geth 和 Prysm 中。「go-kzg」是一个单独的代码仓库,将 KZG 承诺方案实现到 Go 编程语言中。开发者们在电话会议上对 go-kzg、Geth 和 Prysm 仓库之间的依赖关系表示了失望。这并非 Potuz 和其他开发者第一次提出关于使用 KZG 库进行 EIP 4844 的挑战。
以太坊基金会的 DevOps 工程师 Parithosh Jayanthi 表示,开发者可以在没有主网 KZG 配置和新客户端发布的情况下启动 Devnet-10,但这意味着开发者不会在 Devnet-10 上测试任何新代码,而是在 Devnet-9 上重新测试发布的代码。
本周,在 Devnet-9 上,开发者们发现了 CL 客户端实现中的一个问题。以太坊基金会测试团队的 Mario Vega 解释称,验证者未能正确处理无效的数据块(blob)。Vega 介绍说,如果验证者恶意地将有效的数据块广播给部分节点,而将无效的数据块广播给其他节点,那么接收到无效数据块的节点将无法追踪链的头部。为了解决这个问题,已经创建了一个 hive 测试,以便轻松复制这些条件并针对新的客户端发布进行测试。这将使开发者能够立即了解他们针对该问题的修复是否有效。
关于【以太坊核心开发者执行最新会议摘要:新CL代码规范、Devnet-10启动条件,以及区块延迟分析】的延伸阅读
Web3 世界的「云安全验证」—— 盘点 EigenLayer 生态知名的 AVS 项目
EigenLayer是一个在以太坊上创建的技术协议,引入了再质押功能。截至2024年6月5日,已有超过530.9万个ETH在EigenLayer上进行再质押。通过EigenLayer,用户可以再次获得资产奖励,开发人员可以利用已质押的ETH启动新的主动验证服务。该文档介绍了多个基于以太坊的互操作性协议,包括连接Layer2的共享排序工具、安全协调层、互操作层和去中心化的证明者网络。这些协议都使用EigenDA作为数据存储层,并提供技术文档供参考。其中,Restaked Rollup是EigenLayer的新型主动验证服务项目,Caldera和Celo也使用EigenDA作为数据存储层,提供技术框架和模块化功能。此外,还介绍了使用EigenDA的Layer2网络,如Cyber、LayerN和Mantle。EigenDA是一个模块化的Layer2网络,专注于成为web3应用程序的社交层。Polymer Labs开发的协议结合了Optimism堆栈的结算功能和Cosmos SDK的互操作性功能,使用EigenDA作为数据存储层。Versatus是世界上第一个Stateless Rollup,助力去中心化应用的开发。
火星财经加密周报 | 6月7日
本周欧盟选举开始,加密行业监管政策可能受影响。Tether CEO担心欧盟MiCA稳定币要求会对市场产生负面影响。RoaringKitty可能清算其GME股票头寸,Solana币价增长受益于Meme币交易活动。特朗普竞选团队收到近3亿美元捐款,西班牙90%的World ID持有者支持Worldcoin回归。加密专家密切关注欧盟选举对MiCA、DeFi、NFT等领域的影响。比特币可能因CPI创新高和降息预期上涨,ETH表现落后。Blast提醒DApp在6月25日前分配所有Gold和Points给用户。Bitget Launchpad项目BWB投入总人数增长,IO.NET初始总供应量为5亿枚。五月加密市场大多数指标下跌,但以太坊质押收入上涨,NFT市场交易额下降。加密货币可以解决人类挑战,DeFi夏季最新更新包括Ethena、Etherfi、Karak等项目。Notcoin交易量增加,L2争斗白热化,市场流动性改善,Meme板块吸引资金流入,NFT市场情绪低迷。Shardeum、Merlin和0G Labs与多家合作伙伴合作推进去中心化项目发展。
关于这个问题,Enrico Del Fante 提到,当某个区块包含一个或多个与区块中现有 blob 承诺不匹配的索引的 blob 时,在特定情况下,Teku 客户端将不会导入这个区块。以太坊基金会研究员 Dankrad Feist 指出,故意提议包含无效 blob 的区块的验证者除了可能增加以太坊点对点网络的计算负担并导致接收区块的部分验证者与网络失去同步之外,并没有其他好处。Feist 强调,这种行为没有经济收益,即使验证者这样做,以太坊点对点层的额外计算负担也将受到每个区块最大 blob 数量的限制。
尽管如此,为了阻止验证者采取这种行为,开发者们正在讨论可能添加一个新的削减条件。新的削减条件将试图监控区块中无效 blob 的包含情况,以阻止验证者故意给点对点层带来压力。然而,由于改变以太坊验证者经济学所需的研究和分析成本很高,Ryan 建议在 Dencun 之后的下一个升级 Prague/Electra 的背景下进一步讨论这个提议。
Ryan 补充指出,开发者可以在 Dencun 的 CL 规范中为这种情况设定适当的行为,即使 blob 索引与区块承诺不匹配,验证者仍应导入区块。他认为,由于验证者没有经济动力去以 Del Fante 描述的方式传播含有无效 blob 的区块,这种非理性行为可能导致的网络负担最大程度地受到每个区块最大 blob 数量的限制。因此,对 CL 规范进行微小修改应该足以在短期内解决问题,同时开发者可以考虑未来升级的更持久性解决方案,如新的削减条件。
Jayanthi 与 Ryan 再次确认,在开发者在客户端设置主网 KZG 配置并解决 Mario Vega 提出的问题之前,Prysm 客户端上至少不会启动 Devnet-10。Ryan 强调,关于新的削减条件的讨论仅在 Prague/Electra 升级的背景下进行,而不是 Dencun,并且关于导入包含无效 blob 的区块的 CL 规范的更改不应成为启动 Devnet-10 的障碍。Prysm 和 Lighthouse 客户端团队的代表表示,他们将在 10 月 20 日(明天)为他们的软件发布更新。
区块延迟分析
在 10 月 14 日(星期六)的一次分享中,以太坊客户端 Lodestar 和 EthereumJS 的维护者 Gajinder Singh 分享了关于基于八卦传播的 blob 数量与区块导入延迟之间关系的新分析。Singh 指出,在他对 Devnet-9 的实验中,验证者接收到的 blob 数量越多,区块的延迟就越明显地增加。
下表总结了 Singh 的发现。第一列列出了完整区块到达的百分比,而表格中的数值表示导入区块所需的秒数。
区块导入延迟(以秒为单位)与区块中包含的 blob 数量之间的关系。图源: Gajinder Singh, Twitter
Singh 在推特上表示,虽然每个区块中只有一个 blob 产生的延迟可以忽略不计,但任何高于两个的数字都会引入显著的延迟。Dankrad Feist 表示,Singh 的分析数据与他在以太坊主网上传播大区块的实验结果非常不同。Feist 断言:「看起来这些数据不可能是正确的」,并补充说,由于 blob 是与区块并行处理的,所以将 blob 处理的延迟加到区块时间上是一种不准确的方式来预测主网上区块传播时间。Singh 关于带有 blob 的区块传播的预测可以在
Singh 在 Twitter 上表示,尽管每个区块中只有一个 blob 产生的延迟可以忽略不计,但任何高于两个的数字都会引入显著的延迟。然而,Dankrad Feist 指出,Singh 的分析数据与他在以太坊主网上传播大区块的实验结果有很大差异。Feist 断言:「这些数据看起来不可能是正确的」,并补充说,由于 blob 是与区块并行处理的,因此将 blob 处理的延迟加到区块时间上来预测主网上区块传播时间是一种不准确的方式。Singh 关于带有 blob 的区块传播的预测可以在这里找到。Feist 称 Singh 的分析「过于悲观」。
尽管存在分歧,Feist 和 Ryan 都认为 Singh 的分析确实值得其他客户端团队借鉴。Ryan 鼓励其他 CL 团队尝试在 Devnet-9 上重现 Singh 的实验,看看他们是否能得到相似的数据和结果。如果有关于引入 blob 后区块延迟的新数据,Ryan 建议在下周的 ACDE 电话会议上重新讨论这个议题。
免责声明:本文仅代表作者个人观点,不代表链观CHAINLOOK立场,不承担法律责任。文章及观点也不构成投资意见。请用户理性看待市场风险,以及遵守所在国家和地区的相关法律法规。
图文来源:Christine Kim,如有侵权请联系删除。转载或引用请注明文章出处!
标签:以太坊