在未来几周内，伦敦升级将在测试网启动。JSON RPC 的变更已经文档化了，还有项目可用于添加 1559 支持的参考手册；
“合并” 的 eth2 部分已经有成熟的规范了。eth1 部分的相似文档在撰写中，且还会有一份可执行的规范；
尽管还没有作出决定，但上海升级的两份候选 EIP 都有了进展：EIP-3074 的审计报告已出， EIP-3540 有了路线图
在未来几周内，伦敦升级将会在测试网启动：第一个是 Ropsten 测试网，大约在 6 月 24 日，然后是 Goerli 测试网，计划在 6 月30 日，最后是 Rinkeby 测试网，将在 7 月 7 日升级。如果你还没升级你的测试网节点，现在是时候了！
在测试网分叉后，我们预期会进行一些测试，用大量交易轰炸网络，以确保在这样的条件下网络依然运行正常。当客户端开发者觉得伦敦升级在各个测试网上的部署都没有问题了，我们就会确定主网分叉的区块高度。考虑到难度炸弹所在的大约区块高度，主网实际上需要在未来 300,000 到 400,000 个区块里进行分叉。
如果你的项目是建在以太坊上，且会受伦敦升级，尤其是 EIP-1559 影响，以下是你应该审阅的内容：
JSON RPC 规范，其中详细说明了在伦敦升级中的几处变更，例如：
添加了字段 baseFeePerGas （译者注：每单位 gas 的基本费用) 到区块头；
添加了字段 maxFeePerGas (译者注：每单位 gas 的费用上限) 和 maxPriorityFeePerGas (每单位 gas 的小费) 到 1559 式交易；
在这些交易的收据里添加了字段 effectiveGasPrice (译者注：交易实际支付的 gas 费用)；
HSC虎符智能链联合TP钱包的联名NFT即将重启:据官方消息，HSC联合TP钱包的联名NFT 即将重启，由于NFT领取次序将对后续联名挖矿的算力和空投TPT产生直接影响，请大家于8月2日 21:00 准时登陆进入TokenPocket钱包新品区的多链矿工Dapp进行领取，本次NFT限时免费。
虎符智能链HSC是一条去中心化高效节能公链，坚持“技术过硬+玩法创新+生态可持续”之路，和开发者一起构建开放共享共荣的公链2.0生态。[2021/8/1 1:27:56]
添加字段 eth_feeHistory (译者注：gas 费用历史数据) 到终端，使钱包更容易根据近期的历史数据提供 gas 预估值。详情看这里。
1559 钱包参考手册 (1559 Wallet Cheatsheet)，解释了与 EIP-1559 相关的非共识变更，提供了支持这份 EIP 的最佳实践。它具体包括：
Calaveras 开发者测试网的说明，现在应用可以用它来测试伦敦升级的内容
maxPriorityFeePerGas （即小费）涉及的多个函数，以及如何在拥堵和不拥堵的情况对其进行设置；
关于如何顺滑地将用户迁移到 1559 式交易的指南
一如既往地，如果你的项目会受 EIP-1559，或更广泛地受伦敦升级影响，你可以在 Discord 联系客户端团队。
也就是说，伦敦升级要来了?
当大多数客户端团队专注于伦敦和 Altair 升级时，“合并”的进展并没有停止。
首先，在共识层 (即 eth2) 部分已经有了成熟的规范！它的开发工作仍在如火如荼地进行中，你可以在 eth2.0-specs 库里关注内容的更新。
在执行层部分 (即 eth1)，将会有一份关于所需变更的概述。?
它将作为一份“主文档”，能链接到更细化的规范变更，这些规范变更会以相应的格式呈现 (例如，EIP 用于引入新的操作码)。
采用不同方法的原因是共识层 (eth2) 与执行层 (eth1) 之间的规范格式是不一样的。
虽然以太坊的规范格式一开始是黄皮书，但其大量数学语构的特点使其难以说明变更。相反，我们通常使用核心 EIP (Core EIPs) 来说明协议规则的变更。这些内容又再反馈到黄皮书上。
另一方面，以太坊 2.0 的规范一开始是用 markdown 文档来写，逐渐发展成现在用可执行的 python 规范。不用说，存在两套不同的方法是远不够理想的！
因此，“合并”的一个辅助举措是为执行层创建可执行的规范，与 eth2.0-specs 库的格式相匹配。这样，我们不仅可以为整个以太坊协议提供一个共同的规范格式，还能从规范生成自动化测试。这仍处于早期，Quilt 团队已经开了一个 PR，有一个初步的实现 ?
如之前的更新提到的，尽管“合并”是伦敦和 Altair 升级后的工作重点，开发者已经对下一次执行层的升级——上海升级有想法了。
这次升级会在“合并”之前或之后进行，取决于二者在 12 月的准备情况，因为届时难度炸弹需要再次被推迟。尽管这次升级目前还没有规范，也没有 EIP 被正式纳入，但有两份候选的：EIP-3074 和 EIP-3540。
这份 EIP 旨在让智能合约在与用户地址互动上有更多的灵活性。这份 EIP 作者之一的 @lightclient 发的推文很好地总结了它的主要裨益。
有人担心这份 EIP 会改变一些安全假设，特别是关于msg.sender 代表的地址，以及智能合约可以代表用户账户采取的行为广度。两家审计机构受委托研究这份 EIP，以探索这些安全忧虑：Least Authority 负责研究这份 EIP 本身；Dedaub 负责研究 EIP-3074 会如何影响当前部署了的合约。
这是 Least Authority 的完整审计报告，审计者在最新的一次核心开发者会议里分享了他们研究成果的总结 (从 1:07:00 开始)。在该次会议里，Dedaub 也在 Least Authority 的分享后讨论了他们的审计结果，在推特上分享和总结了他们的报告。
尽管在该次会议里没有对 3074 作出任何决定，这些审计结果有助于澄清纳入这份 EIP 所涉及的安全权衡。同时，有人在 Ethereum Magicians 论坛上提出了 "3074 的替代方案" ，这将在本周的核心开发者会议上讨论。
此提案依附于已被纳入伦敦升级的 EIP-3541。它引入“一种用于 EVM 的可扩展、版本化容器格式，在部署时进行一次性验证。”这将有助于更好地分离代码与数据，两者现在客户端都需要在运行时间验证。
这个变更对多种用例都有所裨益，比如二层网络的代码验证、多字节操作码，可能会弃用 JUMPDEST 等。
这份 EIP 作者之一的 Alex Beregszaszi 最近分享了一个更完整的概述和路线图。
如果时间允许的化，下一次的核心开发者会议会讨论这份 EIP。如果时间不允许的话，可能是再下一次会议。
更新到这里就结束了！请留意未来几周在blog.ethereum.org 上发布的伦敦主网升级公告，以及大约一个月后的以太坊核心开发者会议更新。?
发布于 2021 年 6 月 22 日
Kovan 测试网的升级日期还未定，很可能是主网升级之后。以及，OpenEthereum 客户端在伦敦升级后会被弃用。
来源 | AllCoreDev Updates
作者 | Tim Beiko
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。