Welcome to another AllCoreDevs update
12 965 000
, there are several watch parties organized 📺Next week, as you are hopefully aware by now, London will be hitting the Ethereum mainnet! The upgrade will go live on block 12,965,000
, which both Etherscan and Ethernodes currently estimate for about 3am PT on August 5th.
If you run an Ethereum node, now is the time to update it! You can find a list of London-compatible client versions here.
One thing you may notice in the link above is the mention of a consenus issue on the Ropsten network. The issue is detailed thoroughly in the postmortem, but here is a TL;DR:
gasLimit
multiplied by its maxFeePerGas
.
baseFeePerGas
is equal to maxFeePerGas
).maxFeePerGas
before transfering, but not after, which caused some clients to erroneously accept the transaction, and others to reject it [0].Within a few hours, the issue was identified and a fix was implemented in clients. The affected teams then put out a new release over the next day.
After this incident, the question of whether we should delay London further was brought up. While no client team asked for this before releasing their updated software, and no one mentioned wanting to do so on the subsequent AllCoreDevs call, it mentionned in other forums that this should have perhaps been done.
I re-opened this discussion on the AllCoreDevs discord. There, only one of the client teams thought we should delay the upgrade because of this. While delaying can seem like the "obvious" choice, a few reasons against delaying that were mentioned were:
Of course, only time will tell whether this was the right call and if a potentially more extreme delay (e.g. "cancel London, delay the difficulty bomb and re-assess from scratch") would have been worth it. The rough consensus across client teams was that this bug did not warrant such drastic measures, and that additional testing and monitoring of the upgrade should suffice.
As a reminder, if you believe you've found an issue with London, payouts for bounties submitted at bounty.ethereum.org are doubled until the fork 💰
Finally, if you would like to help prevent such bugs in the future, the EF is hiring an additional test engineer. The role is fully remote, has a flexible schedule, and will have you work with both the EF's testing team and core developers across the various client teams! You can apply here.
If you'd like to follow along the London upgrade, there are a few different watch parties which are planned next week:
The Merge now has an EIP! EIP-3675 describes the changes required to the execution layer (eth1) to be ready for the merge. It is a companion to the merge
folder in the consensus layer (eth2) specification.
The most noteworthy thing about EIP-3675 is probably its brevity. The amount of changes required to the execution layer for the merge are, by design, minimal. This means that disruption to existing applications should be few and far between. In other words, smart contracts should just keep running as-is, and, behind the scenes, the consensus algorithm will be changed from proof of work to proof of stake.
That being said, there are still some changes. Here is a high-level summary:
ommersHash
and ommers
(no ommer blocks under PoS);extraData
(redundant given graffiti
in the beacon chain);difficulty
+ mixHash
+ nonce
(used in PoW).DIFFICULTY
: given on the changes above, theDIFFICULTY
opcode will always return 0
post-merge;BLOCKHASH
: the pseudorandomness provided by this opcode becomes (even) less secure after the merge due to the properties of proof of stake.The EIP has yet to be merged as a draft, but it is still worth familiarizing yourself with if you are building on Ethereum. We are still early enough in the process that significant changes can be considered if they are well justified!
On the last AllCoreDevs, Mikhail Kalinin, the author of EIP-3675, presented the EIP to the client teams. After a technical discussion of it, a more high-level discussion of the roadmap from here to the merge took place.
It is worth watching the call/reading the notes for context, but, in short, we agreed to the following:
While we are of course mindful of the desire to see the merge happen ASAP, when working on London, several projects mentioned that they would have liked a longer delay between when the consensus changes were done and the mainnet activation. This way, more iterations can be done on things like APIs before the changes hit mainnet and the initial client behavior gets cemented, for better or worse.
On a related note, this has sparked a conversation about how we should name all of these upgrades. If you'd like to chime in, a thread is open on Ethereum Magicians 🧙🏻♂️
And that was it! Expect another upgrade towads the end of the summer, once London is out and we are in the weeds of implementing the merge ☀️
Published on July 29, 2021
[0] Note: the transaction still had enough ETH in its account to be executed at the current baseFeePerGas
. The maxFeePerGas
was set very high, so if the baseFeePerGas
had been much higher, it may not have had enough ETH to be executed. If that was the case, the transaction would have failed another validity check.