# 以太坊核心开发者会议更新 010⛓ By [EthereumCN](https://paragraph.com/@ethereumcn-2) · 2022-03-28 --- 来源 | [AllCoreDevs Updates](https://tim.mirror.xyz/M_3JZXBkvXnr3W1222WIDo1ipMuFymszjH-FP40CO5c) 作者 | Tim Beiko 摘要 👀 ----- 自一月份以来，发生了很多事情，以至于我一直在努力找时间把它们写下来。以下是本次更新的重点： * 最新的合并测试网 Kiln 已经启动。在上面进行的 PoS 过渡揭示了一些实现上的问题，现在所有人都把工作重心放在合并测试上🛠 * 下一次的以太坊升级上海升级在拟定中，计划中有 EVM 升级、信标链提款、L2 费用减少等 🌃 * 以太坊执行层的可执行规范正在顺利进行。下一步：协调 EL+CL 的升级过程 📜 * 协议公会，一个为客户端开发者和研究员提供基于通证的补偿倡议，现在有超过 100 个成员，并很快推出试点 💰 Kiln 测试网🔥🧱 ------------ 继 Kintsugi 后，Kiln 测试网[最近也启动了](https://blog.ethereum.org/2022/03/14/kiln-merge-testnet/)了。根据在 Kintsugi 测试网上发现的临界情况，Kiln 加入了一些变更和重命名到合并规范。尽管合并的规范现在看上去几乎接近最终版了，在 Kiln 上运行的过渡在各个客户端中浮现了实现上的问题。团队现在正加倍努力进行测试，以确保所有实现都是安全和稳定的。Danny 在[最新的 Finalized 更新](https://blog.ethereum.org/2022/03/23/finalized-no-34/)里谈到了这点。 假设没有发现重要的问题，Kiln 将是最后一个发布的新公共测试网。下一步，一旦我们对客户端的实现和基础设施/工具的准备情况感到满意，我们将在现有的测试网 (像 Ropsten、Goerli、Sepolia 等) 进行合并。 与每次升级一样，我们将在升级后监测测试网，以确保它们是稳定的。一旦我们确信测试网按预期运行，我们将为以太坊主网计划过渡！ 虽然我们已经很接近合并了，而且这对整个社区来说是一个非常令人兴奋的时刻，但过渡能安全进行比任何目标日期更重要，是合并的头等大事。这是迄今为止以太坊进行的最复杂的升级。我们不想出错 😁. 一旦决定了，测试网和主网升级的时间线将会在各社区宣传渠道公布，例如每周以太坊进展 ([This Week in Ethereum](https://weekinethereumnews.com/))、Eth2 进展更新 ([What's New in Eth2](https://eth2.news/))、以太坊基金会博客 ([the EF blog](https://blog.ethereum.org/)) 等。目前任何声称是目标日期的都是错的，因为我们还没定这个日期。在接下来的几个月里，要对潜在的诈骗/虚假公告保持额外的警惕！ ### 关于难度炸弹💣 在去年的 [Arrow Glacier](https://blog.ethereum.org/2021/11/10/arrow-glacier-announcement/) 升级中，难度炸弹被推迟了，预计今年六月在网络上能感受到难度炸弹的影响。[这篇贴文](https://ethresear.ch/t/blocks-per-week-as-an-indicator-of-the-difficulty-bomb/12120/7)在追踪它的进展情况。虽然在我们需要推迟难度炸弹前实现 PoS 过渡是最好的，但有三点值得注意： 1. 炸弹对出块时间的影响是渐进的。这意味着一旦开始感到到它了，就将有 4 — 8周的时间出块会变慢，但不是急剧变慢 (大概 14 - 17 秒)。 2. 在过去，当要推迟难度炸弹，我们会选择推迟 6 个月左右，因为我们通常计划在那时进行下一次的网络升级。也就是说，关于难度炸弹要推迟多久是没有硬性规定的。如果推迟一、两个月比推迟 6 个月更合适，这也是完全可以的。 3. 同样，安全的合并 >>> 快速的合并。我们希望过渡能顺利进行，以太坊的稳定和安全是我们最关心的。 上海升级🌃 ------ 如上一次更新所说的，随着合并的规范基本接近冻结，我们已经开始了上海升级的计划工作。[这里](https://github.com/ethereum/execution-specs/blob/master/network-upgrades/mainnet-upgrades/shanghai.md)是升级的规范。这次升级暂定有三项重大变更，以及一些小项。下面逐一深入说明！ ### EVM 对象格式⚙️ 研究员和客户端开发者多年来一直努力在不破坏现有合约的情况下改进 EVM。去年，Ipsilon 团队想到了一个聪明的解决方案：给有特定标识符的合约提供新功能，而现有的合约按原样执行。这现在以 EVM 对象格式 (EVM Object Format) 为人所知，简称 EOF。 在[伦敦升级](https://www.ethereum.cn/Eth1.x/london-testnets-announcement/)里，我们通过拒绝以 0xEF 字节开头的新合约的部署来保留这个标识符的部分。在伦敦升级被激活前，有些以这个字节开头的合约被部署了，但现在已经不能这样做了，我们可以给前缀 `0xEF` 添加第二个字节 (被称为 Magic Byte)，得到一个我们可以保证不被任何合约使用的序列。 [EIP-3540](https://eips.ethereum.org/EIPS/eip-3540) 对这个内容进行了详细描述，并强调了该方法的第一个实际好处：代码与数据的分离，这有利于链上代码验证。这还为引入新合约代码部分类型铺平道路，这有助于实现现在看来很复杂的功能，例如[账户抽象](https://eips.ethereum.org/EIPS/eip-4337)、[EVM 里的控制流](https://eips.ethereum.org/EIPS/eip-4200)以及 [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074)。 [EIP-3670](https://eips.ethereum.org/EIPS/eip-3670) 是 3540 的配套 EIP，它引入部署时 EOF 合约的代码验证。 ### 信标链提款🏧 上海升级的另一个主要功能是激活信标链提款。经过几份提案后，我们得出了一个客户端团队都满意的设计：[EIP-4895: Beacon chain push withdrawals as operations (信标链作为系统操作的推式提款)](https://eips.ethereum.org/EIPS/eip-4895)。 这个[元规范](https://notes.ethereum.org/@ralexstokes/Skp1mPSb9)概述了整个运作流程。从高层次来说，在每个 slot 里，信标链都会处理一定数量的全额或部分提款。这些提款会在收据里被追踪，这些收据包含每笔提款的数额、目标地址和唯一的索引。作为区块创建和验证过程的一部分，这些提款随后会在执行层上分发出去，与今天工作量证明分发给矿工一样。 对于在共识层上需要做出的多个变更有一个[追踪问题](https://github.com/ethereum/consensus-specs/issues/2758)，这个内容现在已经在 `consensus-specs` (共识层规范) 的仓库里了。部分提款的选项将允许验证者提出他们获得的奖励，同时保持在链上有做验证者所需的 32 个 ETH，继续赚取奖励。 ### L2 费用减少 📉 我们希望纳入上海升级的最后一个大事项是减少在二层的费用。因为二层会在一层发布交易数据 (和/或证明)，终端用户的交易费用有很大一部分来自一层的数据存储。分片为二层发布数据提供一个更便宜的替代方案，然而尽管这个提案似乎已经定下来了，完整的分片实现还没有准备好。 同时，现在有两个可用选项可以减少这些开销：在主网上降低 `CALLDATA` 的开销，或“proto-sharding” 实现，这个方案会在以太坊上引入一种新的交易类型，被称为分片 blob 交易 (Shard Blob Transactions)。 #### 降低 CALLDATA 开销 降低在 L2 上的交易费用的最简单方式就是降低在 L1 上存储数据的开销。 [EIP-4488](https://eips.ethereum.org/EIPS/eip-4488) 提议这样做，把 `CALLDATA` 的开销从每字节 16 gas 下调到 3 gas。存储开销的减少会转化为更低的二层费用\[1\]。 尽管降低 gas 开销本身是个简单的变更，但它会带来一些次级效应。首先，增加区块里的 `CALLDATA` 会导致更大的区块容量。为了平衡这点，这个 EIP 提出在一个区块里需要有一个 `CALLDATA` 最大数量的上限。第二，即使有了这个上限，这个 EIP 也会加快执行层上历史链数据的增长速率。为了解决这个问题，我们需要开发频带以外的数据检索，并像 [EIP-4444](https://eips.ethereum.org/EIPS/eip-4444) 提议般，在以太坊 P2P 网络里对历史数据存储的保证需要改变\[1\]。 虽然历史链数据的增加本来就会逐渐发生，纳入这份 EIP 意味着它部署后我们需要更加迫切地处理这个问题。另外，这个 EIP 基本没什么内容可以在完整分片中得到重复使用。它主要是一个临时的解决方案。也就是说，这个 EIP 是一个相对简单的实现变更，并确实能明显地降低 L2 的费用。 #### 分片 blob 交易 另一个提案是 [EIP-4844](https://eips.ethereum.org/EIPS/eip-4844) \[2\]，它使我们更靠近完整的分片部署。与信标链提款一样，这个提案也有一个[元规范](https://hackmd.io/@protolambda/eip4844-meta)，链接到共识层规范和其他资源。 从高层次来说，这个新交易类型会包含对数据 blob 的承诺，该承诺会在信标链广播。这个提案可以被认为是要给“小型分片”提案，它不依赖于数据可用性采用，网络的每个节点都需要验证 blob 里的数据。就像在完整分片里，这些数据 blob 只保证在网络的一定时间内可用，而不是永远存储。为了使节点要求还是可管理的，blob 数据被限制在 1MB/slot 而不是在完整分片里的 16mb/slot。 EIP-4844 将为完整的分片实现奠定必要的基础。值得注意的是，所有未来的变更都只会发生在共识层。从执行层的角度来看，分片只是启动和运行！ 一直在这个 EIP 上努力的 Optimism 团队推出一个提供这个 EIP 概览的[网站](https://www.eip4844.com/)，它汇总了各种规范链接，并放了社区对这个 EIP 的积极反应。 * * * \[1\] 由于 L2 交易定价还涉及其他构成，这个减少不会是完整的 5 倍。Optimisim 的[这篇文章](https://help.optimism.io/hc/en-us/articles/4411895794715-Transaction-fees)对 L2 费用的构成有很好的解释。而且，ZK rollup 不会像 Optimistic rollup 般从这个 EIP 获益。 \[2\] EIP-4488 (降低 `CALLDATA` 开销) 和 EIP-4844 (分片 blob 交易) 作为竞争提案，它们的 EIP 号也太相似了吧 😅 * * * ### 小型改进✨ 除了这三个大型变更，上海升级还在考虑进行一些小型改进，即 * [EIP-3651](https://eips.ethereum.org/EIPS/eip-3651) 提议降低访问 `COINBASE` 地址的 gas 开销，修正 [EIP-2929](https://eips.ethereum.org/EIPS/eip-2929) 的疏忽 * [EIP-3860](https://eips.ethereum.org/EIPS/eip-3860) 提议给 `initcode` 的大小设限，并引入给这个字段的 gas 计量。 * [EIP-3855](https://eips.ethereum.org/EIPS/eip-3855) 提议新增操作码 `PUSH0`，把 0 推入 EVM 堆栈。 此外，还有其他几个 EIP 被提议进行升级 (参阅[这个](https://github.com/ethereum/pm/issues?q=is%3Aissue+is%3Aopen+shanghai)粗略列表)。EOF、提款和减低二层费用已经使得上海成为迄今为止最大的升级之一，所以我们需要非常认真得斟酌纳入内容的优先次序。 一旦我们开始实现和测试各种 EIP，我们将更加清楚我们是否有额外的能力去实现其他提案。当然，在此之前，我们仍然需要先完成合并！ 以太坊执行层规范 (EELS)📜 ----------------- 正如你可能已经注意到了，上海的几个提案现在同时跨执行层和共识层。在过去，在不同的层上我们使用不同程序来引入变更。 在执行层上，[核心 EIP](https://eips.ethereum.org/core) 包含变更的规范。《以太坊黄皮书》是网络的参考规范，但往往在升级被部署了后才会更新黄皮书，有时会有更大的延迟。这意味着执行层的有效规范往往是“黄皮书 + EIP X、Y、Z”。 在共识层上，用作参考的是一个[可执行的规范](https://github.com/ethereum/consensus-specs/)，变更会直接在上面详细说明。然后，该规范就可以用于为变更生成测试。 因此，虽然社区能很好地理解执行层的流程 (并提供一个易于参考的变更描述)，从技术角度来说，这并不理想。相反，尽管共识层的流程在技术上更简洁，但对于更广泛的社区来说更难理解。幸运的是，在 EELS 上的工作已经开启了：以太坊执行层的可执行规范！ 在执行层和共识层上都有可执行的规范，这将使我们能够协调两层的变化流程。仍然有许多问题需要解决，但关于如何能最好地迁移的对话已经开始了。在 [Ethereum Magicians 论坛这里的讨论](https://ethereum-magicians.org/t/core-eips-in-an-executable-spec-world/8640/8)是专属这个话题的。尽管 EELS 仍然在开发中，我们可能可以在上海升级里用上它，与目前的流程并行。 希望执行层和共识层流程的合并会比实际的执行层和共识层合并更简单😅。 协议公会💰 ------ 最后但并非最不重要的，我想谈谈协议公会 (Protocol Guild, PG)，它现在已经有一个[完整的解释网站](https://protocol-guild.readthedocs.io/en/latest/)。对协议维护者的补偿是最近一个热门话题，PG 希望参与解决这个问题。_充分披露：我是 PG 成员并将从中获得资金。_ 你可以把补偿想成有三类：基本工资、激励和潜在的上升空间。目前，客户端开发者和研究员的基本工资是他们各自的雇主解决的。尽管他们有些会以股权形式提供激励，但以太坊基金会去年公布了其 39,000 个 ETH 的[客户端激励计划](https://blog.ethereum.org/2021/12/13/client-incentive-program/)，以确保所有客户端团队在以太坊上都有重大利益。 PG 与基本工资和激励计划不同，因为它旨在使其成员可以出现在基于 ETH 的各种项目通证上，而不是 ETH 本身。公会由协议工程师、研究员和很多协调协议工作的人组成，例如我自己。现在大概有 100 名成员。 简单来说，公会允许赞助者捐赠代币，然后随着时间推移，代币会给到接受者。接收者集是可以更新的，这使得新的贡献者可以定期被加进来，而已经觉得厌倦的人也可以定期被移除。 这个公会是一个早期实验，但如果成功了，可以成为对像 Gitcoin 和追溯性公共产品资助这种专注于底层的倡议的补充。 在[Gitcoin grant](https://gitcoin.co/grants/4832/protocol-guild) 的成功后，PG 的下一步是测试智能合约架构。与此同时，将开始寻找初始捐赠者。我们的计划是用有限的捐款运行 PG 一年，以确保技术和治理部分都顺利进行。希望这个试点都能证明我们可以在以太坊上创建新的机制来协调公共产品和资金！ 后续工作✅ ----- 我们的首要任务还是合并，并重新把重点放在测试上。在接下来的一个月里，我们希望能最终敲定实行，运行多个短期的开发者测试网，并从应用、基础设施和工具提供商收集反馈。其他事情 (上海升级、执行层规范、协议公会) 也应该在同时继续推进。 请期待一两个月后的更新，同时，我们也将有机会在 [Devconnect](https://devconnect.org/schedule) 上面对面讨论所有这些问题——阿姆斯特丹见👋🏻！ ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系[eth@ecn.co](mailto:eth@ecn.co)进行授权。 --- *Originally published on [EthereumCN](https://paragraph.com/@ethereumcn-2/010)*