以太坊上海升级确认开放质押提款

在上一次 ACD的电话会议中，以太坊的开发者们一致同意把 EIP的核心名单列入上海的升级计划。从 ACD呼叫#148发出的全部电话录音如下。值得一提的是，从这一核心 EIP清单中，开发者们一致认为，上海的更新计划包括了抵押 ETH的提款方案，但是并未保证将 EOF或proto-danksharding包含在一起，直至后面两项建议的代码修改。尤其是 EOF，开发者们在上海升级 EIP的一小部分中是否能完成 EOF，或者把 EOF的整个远景都与上海的 EOF联系起来。

EOF执行

Hedera公司的首席软件工程师 DannoFerrin在上海 EOF的执行情况召开了一次电话会议。他解释道，开发者们往往会把大部分 EIP与 EOF实现联系起来，并在一个较大的更新中进行绑定。开发人员正在考虑将 EOF的 EIP 3540,EIP3670,EIP4200,EIP4750等 EOF的上海升级。关于EIP5450是否应该列入 EOF有关的代码变更清单，开发人员们仍然有不同意见。

EL客户小组的 Andrew Ashikhmin也表达了对 Solidity智能合同语言小组能否全面支持并实现全部4项（或者5项） EIP的关注。Ashikhmin强调，在上海，要确保在启动 EIP之前， Solidity团队已经准备好了这些 EIP的实施。GethEL客户小组的 Marius van der Wijden同意， Ashikhmin在一个电话会议中说：“这是一个必需的健壮性测试。”

Proto-Dance

随后，开发者们将继续探讨proto-danksharding的发展。与 EOF实施方式不同，仅有一个 EIP与Proto-danksharding代码变更相关，也就是EIP4844‌。Diederik Loerakker （也就是“Protolambda”）是 OP实验室的一名研究员，他说还有很多关于EIP4844的问题需要商榷。以太坊基金会的 Ansgar Dietrichs表示，在上海，有些事情是设定 blob的最低价和减少 blob的吞吐量。这些要做的事情在 Github Linux中进行了汇总。

禁止Self-Destruct和其它可能的 EIP

当开发者为上海的升级做好 EOF和proto-danksharding工作的时候，开发者们已经初步同意将另外四个 EIP合并到以太坊的下一次升级中去。

1、EIP4758‌，禁止在以太坊上的“selfdestruct”运算代码：开发者们在最后一次 ACD会议上讨论了禁止操作代码的问题。这个操作码是少数几个用 gas部署的传统操作代码中的一个，但是网络的存储费用却没有上限。独立开发者 MicaZoltu强调，一些以太坊中的活跃的智能合同仍然在使用 selfdestruct操作代码，如果关闭它，就会破坏这个功能。Tim Beiko说，在这种特定的边界条件下，也许还有其他的解决方案，而以太坊基础设施也需要扩大。

2、EIP1153‌，暂存操作代码增加： Uniswap和 Optimism小组的代表介绍了一种具有说服力的应用实例，其性能与传统的以太坊中的存储操作代码一样，但在每次交易之后都会删除。有很多原因可以激发瞬间储存，就像 Optimism的 Mark Tyneway所说，节省 gas的费用。单是 Uniswap，该 EIP可以为用户节省每年约300万美元的 gas费用。另外，采用暂时性存储代替传统存储可以帮助以太坊降低技术负债。Uniswap和 Optimism团队为在多种以太坊客户机中建立这种代码变更的实施做出了很多努力，并且建立了一个完整的 EIP测试包。Daniel Lehrner, Besu （EL）客户小组的 Daniel Lehrner向外界的开发者发出了请求，希望他们能够完成EIP1153。尽管这样，并不是所有的开发者都觉得增加了EIP1153的测试负荷是值得的。Geth开发者 Marius van der Wijden提醒说，EIP1153将会影响 EOF相关的 EIP的筹备工作，并且会导致 EOF的复杂性。不过，范德威登说，他仍然对增加测试工作中的代码变化保持“观望态度”。开发者们同意在 Uniswap和 Optimism团队中的外部开发者的协助下，对EIP1153进行了测试，使之能与上海的升级相结合。

3、EIP2537‌，增加 BLS预编译： AlexStokes，以太坊 Foundation，向以太坊中加入 BLS预编译的好处。Stokes解释道，这其中有许多理由，其中包括能够创建更加安全的加密认证、更好的以太坊信标链的互用性，以及更多的分散式质押池。Van der Wijden认为，加入 BLS预编译是一种重大的代码修改，而且比 EOF执行和EIP1153都要优先。不过，因为EIP2537的实现需要大量的测试，范德威登说，他对添加这种代码的修改会延迟上海的升级。以太坊基金会的杰里德•沃辛格说，他正致力于开发一种能提供比 EIP 2537更容易实现的并行 EIP。为了上海的升级，开发者们一致同意对EIP2537进行研究，并开始降低 BLS的预编数目。

4、EIP2294‌：最后，谷歌的软件工程师 Zainan Victor Zhou，对 EIP 2294进行了简化，仅对以太坊链 ID字段的字节进行了限定，这也就是在硬分叉之后，通常用来辅助发现节点。VictorZhou在一个电话会议上说，随着将来以太坊的分块和多链的发展，这个用例将越来越大，越来越重要。为了避免有人想要将其它类型的资料储存到链ID域中， Victor Zhou要求明确地将链号 ID的尺寸捆绑起来。所有的开发者都认为这个变化是非常重要和容易实施的。MicahZoltu强调，这种代码修改仅要求软分叉，也就是说，以太坊客户机团队可以在不同的时间线上实现变更，而不会调整具体的区块高度。对于在呼叫的末尾，是否将链号的 ID控制在64或256位，也有过一些讨论。Tim Beiko鼓励开发者们在 Discord聊天中进行脱机的讨论，并且用非同步的方式来计算这些数据。

随着上海升级计划的 EIP名单越来越多，开发者们也在优先选择哪些 EIP以外的 EIP问题上意见不一。一名以太坊基金会的开发者，化名“lightclient”，建议坚持开放取款，并且只将其他重要的 EIP作为优先事项，不管是proto-danksharding, EOF实现，或者在电话会议中所建议的四种 EIP中的一种。Tim Beiko相信，在下次的升级中，将 EOF实现、proto-danksharding、 BLS预编译、增加暂时的存储操作代码都是不切实际的。因为没有足够的时间， Beiko建议上海的升级计划，并且鼓励开发者们在下次的 ACD电话会议中，为上海提升除抵押 ETH提取以外的首要任务做好准备。