Try   HackMD

AllCoreDevs Update 005 ⛓

Welcome to another AllCoreDevs update

Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

TL;DR
Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

  • London is going live on block 12 965 000, there are several watch parties organized 📺
  • A bug was found (and fixed!) on Ropsten. Relatedly, the EF is hiring an additional test engineer. Apply here 🛠
  • The Merge now has an EIP: EIP-3675 📝
  • We're considering a few different roadmap scenarios, but all of them include getting merge testnets up and running ASAP 💪🏻

London 🇬🇧

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.

Ropsten Bug
Image Not Showing Possible Reasons
  • The image file may be corrupted
  • The server hosting the image is unavailable
  • The image path is incorrect
  • The image format is not supported
Learn More →

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:

  • In May, we added some extra checks to the 1559 spec to prevent certain types of spam attacks;
  • One of those checks asserted that a transaction's sending account should always have at least as much ETH as that transaction's gasLimit multiplied by its maxFeePerGas.
    • This ensures that transactions sent always have enough ETH to cover their "worst case" scenario (e.g. when baseFeePerGas is equal to maxFeePerGas).
  • For this check to be valid, it needs to happen on the account balance after whatever amount is being sent by the transaction has been deducted from the balance.
  • The spec had the checks in the right order, but was unclear about the fact that the amount was subtracted from the account, so some clients implemented the check based on the initial account balance.
  • A transaction sent on Ropsten had enough ETH to cover the 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:

  • The difficulty bomb: after block 13.1m, the impact of the difficulty bomb will start being more noticeable, and it is unclear if delaying for such a short time would have had a major impact;
  • The nature of the fix: the fix to the bug is technically a soft fork (e.g. a tightening of the protocol rules). This means that as long as the majority of miners upgrade, they will never produce a block that non-upgraded, London-compatible, nodes reject;
  • The risk of having two London blocks: conversely to the above, if we did change the London block and some nodes did not upgrade, then those nodes would fork earlier than the "new" London.

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.

Watch Parties 📺

If you'd like to follow along the London upgrade, there are a few different watch parties which are planned next week:

  • Aug 2, 14:00 UTC: Ethereum Cat Herders' community call 😸
    • This call will have several of the core developers and EIP champions to go over the various changes coming in the upgrade;
  • Aug 3: Bankless's Eve of EIP-1559 panel 🏦
    • Hosted by yours truly, this panel will cover 1559 in depth, with some of the researchers and implementers who worked on it;
  • Aug 4/5 Ethstaker London Launch Party 🎉
    • If you want to watch the upgrade go live alongside other community members, this is the place to be!

The Merge ☀️

EIP-3675 📝

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:

  • Block header: several fields will be set to "0", or their appropriately encoded equivalent, they are:
    • 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, the
    DIFFICULTY 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!

Roadmap 🗺

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:

  1. Ship London;
  2. Focus on The Merge, and get to live testnets;
  3. Based on the amount of non-consensus work expected on the testnets (e.g. JSON RPC APIs, infrastructure support, etc.), either:
    • Merge ASAP (unlikely unless there was a security reason to do so);
    • Have a network upgrade where only the difficulty bomb gets delayed and merge shortly after;
    • Have a network upgrade which introduces new EIPs and give the community an extended period of time to interact with the testnets.

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.