原文标题：《Ethereum All Core Developers Call #149 Writeup》
原文作者：Christine Kim
原文编译：隔夜的粥
2022 年 11 月 10 日，以太坊开发人员齐聚第 149 次全体核心开发者 (ACD) 电话会议，这次 ACD 电话会议由以太坊基金会的 Tim Beiko 主持，本周，开发人员讨论了与 EVM 对象格式 (EOF) 以及 proto-danksharding 相关的代码更改进展，以实现合并后以太坊网络的首次重大升级（称为上海）。在这次电话会议期间，开发者们还讨论了其他四项可能纳入上海升级的 EIP。虽然每个提案确实为以太坊带来了一些独特的优点及好处，但开发者们对优先考虑纳入哪些 EIP 的问题，仍存在较大的争议。除了上海升级的讨论之外，开发人员还简要谈到了抗审查性的话题，以及为了网络可扩展性而对以太坊的抗审查特性进行的潜在权衡。
在之前的 ACD 电话会议中，以太坊开发人员同意将 EIP 的核心列表纳入上海升级。 来自 ACD Call #148 的完整通话记录在这里。 值得注意的是，从这份核心 EIP 列表中，开发人员同意将质押 ETH 提款提案纳入到上海升级之内，但并没有承诺在同一升级中纳入 EOF 或 proto-danksharding，直到后两个提案的代码更改得到进一步充实。 特别是关于 EOF 的话题，开发人员一直在犹豫是通过上海升级的一小部分 EIP 部分实现 EOF，还是尝试将 EOF 的全部愿景捆绑在上海之后的以太坊升级中。
Hedera 首席软件工程师 Danno Ferrin 就本周关于上海 EOF 实施进展的电话会议进行了更新。他解释说，开发人员倾向于尽早将与 EOF 实现相关的大多数 EIP 捆绑到一次大型升级中。开发者考虑在上海升级中纳入与 EOF 实施相关的 EIP 有 EIP 3540、EIP 3670、EIP 4200 以及 EIP 4750。对于是否应将 EIP 5450 纳入与 EOF 相关的代码更改列表，开发者之间仍存在着分歧。
Erigon 执行层 (EL) 客户端团队的 Andrew Ashikhmin 也对 Solidity 智能合约语言团队是否能够完全支持和实施所有四个（或可能五个）EIP 表示担忧。 Ashikhmin 强调，在承诺在上海升级激活这些 EIP 之前，首先要确认 Solidity 团队已为这些 EIP 实现做好了准备。Ashikhmin 在电话会议上表示，这是「一项必要的健全性检查」， Geth EL 客户端团队的 Marius van der Wijden 对此表示赞同。
然后，开发人员继续讨论了 proto-danksharding 的最新发展。 与 EOF 实现不同，只有一个 EIP 是与 proto-danksharding 代码更改相关联的，即EIP 4844。Diederik Loerakker（通常被称为「Protolambda」）是 OP Labs 的研究员，据他表示，仍有一些与 EIP 4844 相关的事项正在讨论中。以太坊基金会的 Ansgar Dietrichs 补充说，其中一些事项与设置 blob 交易的最低价格以及降低上海升级的 blob 交易吞吐量有关。这些待办事项在Github 上有总结。
在开发人员为上海升级准备 EOF 以及 proto-danksharding 工作的同时，开发人员初步同意继续研究其他四个 EIP，以纳入以太坊的下一次升级。
1、EIP 4758，禁用以太坊上的「selfdestruct」操作码：开发人员重新审视了上次 ACD 电话会议中关于禁用操作码的对话，该操作码被开发人员广泛认为是在智能合约以及去中心化应用（dapps）中使用的不良做法。该操作码是为数不多的遗留操作码之一，这些操作码的部署 gas 成本固定，但网络的存储成本可能不受限制。独立开发人员 Micah Zoltu 重申道，以太坊上的某些活动智能合约仍在使用 selfdestruct 操作码，禁用该操作码将破坏功能。 Tim Beiko 表示，对于这些特殊的边缘情况，可能会有一些变通办法，并且需要以太坊基金会进行更多的社区扩展。
2、EIP 1153，临时存储操作码的添加：Uniswap 和 Optimism 团队的代表提出了一个令人信服的案例来引入临时存储操作码，它的行为与以太坊上的常规存储操作码相同，除了这两个新操作码TLOAD和TSTORE的值将在每次交易后被丢弃。瞬时存储的动机有很多，正如 Optimism 的 Mark Tyneway 所解释的那样，其中之一是节省 gas 成本。仅在 Uniswap 上，这个 EIP 就有可能为用户每年节省 300 万美元的 gas 成本。此外，使用临时存储而不是常规存储将有助于减少以太坊的技术债务。 Uniswap 和 Optimism 团队做了大量工作来帮助在多个不同的以太坊软件客户端中创建此代码更改的实现，并为 EIP 构建了一个全面的测试套件。 Besu (EL) 客户端团队的 Daniel Lehrner 对外部开发人员为实现 EIP 1153 准备工作的呼吁表示感谢。即便如此，并非所有开发人员都认为纳入 EIP 1153 所带来的额外测试负载是值得的。 Geth 开发人员 Marius van der Wijden 警告说，EIP 1153 可能会干扰正在进行的 EOF 相关 EIP 的准备工作，并造成复杂性。尽管如此，van der Wijden 表示，他对增加对代码更改的测试工作仍持「观望态度」。开发人员同意在 Uniswap 和 Optimism 团队的外部开发人员的帮助下继续测试 EIP 1153，以便将其纳入上海升级。
3、EIP 2537，添加 BLS 预编译：以太坊基金会的 Alex Stokes 介绍了将 BLS 预编译添加到以太坊的优点。 Stokes 解释说，这有很多原因，包括创建更安全的密码学证明的能力、与以太坊信标链更好的互操作性以及去中心化质押池增加的功能。 Van der Wijden 同意添加 BLS 预编译是一项重要的代码更改，甚至可能优先于 EOF 实施以及 EIP 1153。但是，由于实施 EIP 2537 需要进行大量测试，van der Wijden 表示他担心增加这一代码更改将推迟上海升级。以太坊基金会的 Jared Wasinger 提到，他正在研究一个并行的 EIP，它可以提供比 EIP 2537 更简单的实现路径。开发人员同意研究 EIP 2537 并开始减少不同 BLS 预编译的数量，以便可能纳入上海升级。
4、EIP 2294：最后，Google 的软件工程师 Zainan Victor Zhou 介绍了 EIP 2294，其代码更改比较简单，只是简单地限制了以太坊的链 ID 字段的字节大小，即传统上用于帮助硬分叉后的节点发现。 Victor Zhou 在电话会议上表示，由于以太坊未来可能会出现分片和多链，链 ID 的用例将变得更大、更重要。为了防止人们试图在链 ID 字段中存储其他类型的数据来利用该字段，Victor Zhou 呼吁对链 ID 大小进行显式绑定。所有开发人员都同意这一更改很重要，而且易于实现。 Micah Zoltu 强调称，这样的代码更改只需要软分叉，这意味着以太坊客户端团队可以在各自的时间线上实施更改，而无需为更改协调特定的区块高度。关于是否在调用结束时将链 ID 大小限制为 64 位或 256 位，开发者们也进行了一些讨论。 Tim Beiko 鼓励开发人员离线讨论，并在 Discord 聊天中异步计算出数字。
基于计划在上海升级中纳入的 EIP 列表在不断增加，开发人员对于优先考虑纳入核心列表之外的哪些 EIP 存在着分歧。 一位化名为「lightclient」的以太坊基金会开发人员提议坚持开放提款，并仅优先考虑另一个主要的 EIP，无论是 proto-danksharding、EOF 实施还是电话会议上提出的四个 EIP 之一。 Tim Beiko 认为，在下一次升级中尝试捆绑 EOF 实现、proto-danksharding、BLS 预编译以及添加临时存储操作码是不现实的。 由于会议时间不足，Beiko 提出了上海升级规划的讨论，并鼓励开发人员准备在下一次 ACD 电话会议期间讨论上海升级除了质押 ETH 提款之外的最高优先事项。
在关于上海升级的谈话中，独立以太坊开发者 Micah Zoltu 提出了一个关于以太坊抗审查的重要讨论事项。 Zoltu 解释说，几乎没有以太坊用户会运行自己的节点来执行交易，人们都依赖于 Infura 或 Alchemy 等中心化服务，而这些服务会积极审查来自特定国家的用户，并审查以太坊上的去中心化应用（dapps），例如 Tornado Cash。尽管开发人员正在努力通过 EIP 4844 提高以太坊的可扩展性，但在降低运行以太坊节点成本以及鼓励更大程度地保证以太坊抗审查方面缺乏努力。以太坊 Teku (CL) 客户端团队的开发人员 Mikhail Kalinin 提议在实施 EIP 4844 后专注于降低运行以太坊节点的成本。来自 Erigon 的 Andrew Ashikhmin 则认为，以太坊开发人员可以同时关注这两者。 而 Ansgar Dietrichs 表示，出于务实的原因，以太坊开发者应在短期内为实现可扩展性而牺牲抗审查性，并在长期内专注于抗审查性。
以太坊基金会研究员 Dankrad Feist 的观点则是， EIP 4844 对节点运营商运营成本的边际增加可以忽略不计，并且不会对以太坊的抗审查特性造成实质性损害。 Feist 还补充说，大多数以太坊用户不运行自己的节点不是因为成本，而是因为用户体验差。 Diederik Loerakker 表示，为了创造更高水平的去中心化，扩容应该是以太坊开发人员的优先事项，因为像 EIP 4844 这样的代码更改将使以太坊的使用成本更低，并为世界各地更多的人降低进入壁垒。
Nethermind EL 客户端团队的 Lukasz Rozmej 还质疑 EIP 4844 是否会对以太坊的抗审查性产生负面影响，因为理论上许多交易将在 L2 rollup 上执行。 Zoltu 解释说，虽然 EIP 4844 可能会让验证者在未来更难审查单笔交易，但目前 L2 rollup 的操作是中心化的，因此是可审查的。在结束这次讨论时，Tim Beiko 表示，改善运行以太坊节点的用户体验应该是社区向前发展的重点领域。 Beiko 建议与以太坊核心开发人员相邻的开发团队应帮助简化以太坊节点的运行，并努力让普通用户更容易访问它。
除了以上的内容，以太坊开发人员在这次电话会议上尚未讨论到一些事项，它们包括：
Engine API 规范改进提案：Teku 开发者 Mikhail Kalinin 为改进以太坊的 Engine API 规范创建了一个提案。作为背景，Engine API 是一种软件，使以太坊节点的 EL 和 CL 客户端之间能够轻松通信。对 Engine API 的拟议更改，可能会放到下周四的以太坊 CL 会议上进行讨论。
上海「Core」 vs 原型开发者测试网：为上海升级测试 EIP 将需要创建多个专用测试网络。山东（Shandong）是以太坊基金会 JavaScript 团队推出的一个测试网络，除了一些与 EOF 实现相关的 EIP 外，其已实现了 EIP 4895、EIP 3860、EIP 3651 以及 EIP 3855。在接下来的几次 ACD 电话会议中，开发人员将协调创建更多专用测试网络，供客户端团队测试上海升级 EIP。
Ropsten 测试网结束日期：Afri Schoeden 是维护以太坊测试网络 Goerli 的开发人员之一，他提出了一个提案，在计划的时间线上启动和弃用以太坊测试网络。这是为了回应应用开发人员和基础设施提供商对多个以太坊测试网络被弃用的沮丧情绪。开发人员被鼓励在这个以太坊魔术师论坛贴中分享他们关于如何负责任地弃用像 Ropsten 这样的公共以太坊测试网络的想法。
声明：此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。本网站所提供的信息，只供参考之用。
