Over the next few weeks, the London upgrade will be activated across Ethereum testnets: Ropsten will come first, around June 24th, then Goerli is scheduled for June 30th and finally Rinkeby will upgrade July 7th [0]. A list of the specific upgrade blocks and London-compatible client versions can be found here. If you haven't already done so, now is the time to upgrade your testnet node!
After the testnet forks, we expect to run tests where we bombard the networks with transactions to ensure that everything is working smoothly. Once client developers are confident in London's deployment across testnets, a block for the mainnet fork will be set. Because of the difficulty bomb, this realistically needs to happen in the next 300,000 to 400,000 blocks.
If you are a project building on Ethereum which will be affected by London, and EIP-1559 specifically, here are a few things you should review:
The JSON RPC specification, which details several changes made in London such as:
baseFeePerGas
field to the block header;maxFeePerGas
& maxPriorityFeePerGas
fields to 1559-style transactions;effectiveGasPrice
in the receipt of these transactions;eth_feeHistory
endpoint, which will allow wallets to more easily provide gas estimates based on recent historical data. Details here.The 1559 Wallet Cheatsheet, which provides context on non-consensus changes related to EIP-1559 and best practices for supporting the EIP. Specifically, it includes:
maxPriorityFeePerGas
(f.k.a Tip
) and how to set it in periods of high or low congestion;As always, if you are a project who is affected by EIP-1559 or London more generally, you can reach the client teams via Discord.
With that said, London is here
While most client teams have been focused on London and Altair, progress hasn't stopped on the Merge.
First, it now has a proper specification on the consensus (a.k.a. eth2) side! While it is still under active development, you can follow the changes in the eth2.0-specs repository.
On the execution (a.k.a. eth1) side, you can expect an overview of the required changes
The reason for the different approach is the difference in formats for the specification between the consensus (eth2) and execution (eth1) layers.
While Ethereum was originally specified in the Yellowpaper, its math-heavy syntax makes it a difficult medium to specify changes in. Instead, we typically use Core EIPs to specify the changes to protocol rules. These are then retroactively fed back into the Yellowpaper.
On the other hand, specifications for Ethereum 2.0 started as markdown files, and gradually evolved to the current python executable specification. Needless to say, having two different processes is far from ideal!
Hence, one auxillary initiative to the Merge is to create executable specifications for the execution layer, which match the format of the eth2.0-specs repository. This way, not only would we have a common specification format for the entire Ethereum protocol, but we could also generate automated tests from the specification. This is still early, but the Quilt team has opened a PR with an initial implementation
As mentioned in previous updates, even though The Merge will be the main focus post-London & Altair, some thought is already going into the next execution-layer upgrade: Shanghai.
The upgrade could happen either before or after The Merge, depending on which is ready in December, which is when the difficulty bomb will need to be pushed back again. While no specification for the upgrade exists yet and no EIPs have been formally accepted, two candidates are EIP-3074 and EIP-3540.
This proposal aims to give smart contracts much more flexibility in how they can interact with users' addresses. @lightclient, one of the EIP's authors, has a great thread summarizing the key benefits.
Once concern with the EIP was that it changes some security assumptions, specifically about what address msg.sender
represents, and the breadth of actions a smart contract can take on behalf of a user account. Two audits of the EIP were commissioned to explore these security considerations: one by Least Authority, looking at the EIP itself, and one by Dedaub, looking at how 3074 would impact currently deployed contracts.
Least Authority's full audit is available here, and auditors shared a summary of their findings on the last AllCoreDevs call (starting at 1:07:00). Dedaub, who discussed their audit on the call after Least Authority, also shared and summarized their report on Twitter.
While no decision was made about 3074 on the call, these audits help clarify the security tradeoffs involved in adopting the EIP. In parallel to this, an alternative to 3074 has been proposed on Ethereum Magicians and will be discussed on this week's AllCoreDevs.
This proposal relies on EIP-3541, which was included in London. It introduces "an extensible and versioned container format for the EVM with a once-off validation at deploy time." This would help better separate code from data, which clients both currently validate at runtime.
This change would help with a variety of use cases, such as layer 2 code validation, multi-byte opcodes, potentially deprecating JUMPDEST
, and more.
A more complete overview and roadmap was recently shared by Alex Beregszaszi, one of the EIP's authors.
Assuming time permits, this may be discussed on the next AllCoreDevs call. If not, it likely will be in the call after that.
That's it! Keep an eye out for the London Mainnet Announcement blog post at blog.ethereum.org in the coming weeks, and expect another update about one month from now
Published on June 22, 2021
[0] Kovan's date has not been set yet, and will likely happen after mainnet. Relatedly, OpenEthereum will be deprecated after London. For more details, see this post.