Thread by @TimBeiko

.@ethereum #AllCoreDevs starting in ~15 minutes

Agenda: github.com/ethereum/pm/is…
Stream:

Lots to cover, and I'll be back here after the call for a summary 😁

One note: Berlin is happening on mainnet soon 🇩🇪 If you haven't updated your node, do it now 😁

https://twitter.com/TimBeiko/status/1372961775390322689

Ok here we go!

First up on the call was Berlin updates 🇩🇪 The Rinkeby fork went well, nothing to report. The mainnet fork block is going to happen on April 14/15, see a countdown here: goto.etherscan.com/block/countdow…

We'll have a livestream prior to the fork with @EthCatHerders to watch it go live. You can learn more about that here:

https://twitter.com/EthCatHerders/status/1377637235512729606

Then, we moved to updates about London 🇬🇧

Currently, we have a Besu, Nethermind and Geth implementation in sync on a testnet using the latest version of the EIP (with EIP-2718 transaction envelopes, i.e. a "post-Berlin compatible" implementation).

We uncovered an issue on the testnet regarding transaction receipts, so we'll need to fix that and then start a new one.

Note, the Geth implementation is being worked on by @lightclients from the ConsenSys Quilt team. A draft PR is up, and a proper PR will be opened against Geth when ready. Draft PR: github.com/quilt/go-ether…

The @ConsenSysQuorum team is working on adding proper reference tests to 1559.

Once we have the fix for the receipts, we'll deploy a first client integration testnet to start testing potential EIPs for London. To move away from the YOLO naming scheme, @lightclients proposed using the names of geological fault lines 😁

So... our first integration testnet is called Aleut en.wikipedia.org/wiki/Aleutian_…

A draft spec for the network is available here: github.com/ethereum/eth1.…

We then moved on to discussing Shanghai, and whether to focus on the merge right after London or not. There was a lot of discussion here, so I recommend watching the livestream for nuance, but I'll highlight some of the points made.

First, obviously, there is a strong desire from the community to see the merge happen fast. This is a major consideration, everyone agrees.

Second, if we want to hit the July deadline for London (and 1559), we need to be very mindful about how many other things we include: every additional EIP could delay the upgrade, and we don't want that.

Third, there are a lot of EIPs which have had significant effort put into them, or are simply pretty easy to do, and if we do the merge before them we delay them for several months at best.

So, the tradeoff is that if we focus on the merge post London, there is increased pressure to squeeze things into London, which risks delaying London, which is not really possible due to the difficulty bomb 😅

On top of that, client teams already have a _lot_ to focus on: Berlin, London, the Merge, performance improvements, networking changes, etc.

If we add too many things to that pile, we risk repeating the EIP-2315 fiasco, where something gets accepted and then removed at the last minute because we ended up not following it closely enough.

And, of course, not all teams can move at the same speed: TurboGeth is working on a new client from scratch, OpenEthereum is still in the process of being transitioned over to new maintainers, etc. so we need to be mindful of that if we want to maintain client diversity.

So, with that being discussed, we then looked at the various EIPs that were being proposed to try and assess their likelihood for London integration testnets.

First up was EIP-3403, which disables gas refunds except in a few cases. @willmorriss4 read a statement on the call explaining why he is against the EIP. Strongly recommend watching for the details.

A few people on the call asked for a text version of his statements so they could analyze/respond to them better.

One core argument is that Ethereum actually could support much larger blocks, even post-1559 and so 3403 isn't needed, and it removes the incentive to clear state.

The counter to that is obviously that Ethereum nodes _cannot_ support blocks effectively 4x larger than today, and even larger than that if the gas limit is raised post-Berlin.

Full disclosure: 3403 & its alternatives will make things like GasToken impossible, and would obviously mean the value of existing gas tokens would go to ~0. William has previously stated being a GasToken market maker: ethereum-magicians.org/t/eip-3298-rem…

Next up was EIP-3198, which proposes to add a BASE FEE opcode along with EIP-1559. There were no objections against it, and it is a very small change 👍🏻 It will be included alongside 1559 in the Aleut devnet.

(Good thing I write these tweets - I originally forgot to include it on the Github spec. It's there now 😁)

Next up on the call was EIP-3074, which has been a hot topic these past few weeks! @_SamWilsn_ and @lightclients first gave an overview of the EIP and a progress update from the past few weeks.

The EIP has strong community support because it enables a lot of very useful UX patterns, such as sponsored transactions, combining "Approve" and "Send" transactions for ERC20 tokens, etc.

On the other hand, the EIP does introduce new security assumptions: you would allow a trusted signer full control over your account.

The EIP champions have detailed the threat models of the EIP here: hackmd.io/@matt/BknnAnyNu

Nevertheless, on the call, a few core developers raised objections to it due to security implications.

@realLedgerwatch was strongly opposed to doing it now given the EIP changes a fundamental property of how Ethereum signatures work, and that understanding it thoroughly takes time.

Recalling the earlier discussion about client team priorities, this is another team that will require intense scrutiny by core developers. Someone on the call jokingly called this EIP the "real SUDO opcode", referencing this April Fools' EIP: github.com/ethereum/EIPs/…

OTOH, @VitalikButerin mentioned that multi-operation transaction will become more and more common as people start using multisignature/social recovery wallets, so in practice we are headed to a world with 3074-like trust guarantees.

And, again, a ton of projects have expressed strong support for the EIP, and the championing team has reached organized community calls to collect feedback and is already writing extensive testing for it.

Core developers said they would feel slighly more comfortable if security auditors could review the EIP, and we'll be looking into that.

Also, right after the call, @danfinlay from MetaMask wrote a post addressing some of core devs' concerns and supporting 3074: ethereum-magicians.org/t/eip-3074-aut…

Note: I haven't had time to read it yet 😅

3074 note for those interested in trying it out:

https://twitter.com/_SamWilsn_/status/1378035932281106434

Next up was EIP-2537, the BLS precompile. There was an update given about gas prices and potential new libraries that could be used. Also, the EVM team shared an update about EVM384: notes.ethereum.org/--JjliY8T_-qId…

The sentiment seems to have shifted from whether we should do either 2537 or EVM384 to how we can potentially do both.

One past concern with the BLS precompile was the lack of cryptographic expertise by core devs. Given that it's been used in Eth2 extensively now, this risk is somewhat mitigated as we have Eth2 devs with experience using the library.

While this would be a nice to have now, it becomes much more useful post-Merge with sharding.

No decision was made with regards to next steps on this.

Then, we briefly discussed EIP-2327, which would add a BEGINDATA opcode. This EIP is still in flux, and there are other potential changes to the EVM are related to it. To try and align all those, @greg_colvin has revived an old @EthMagicians thread: ethereum-magicians.org/t/evm-evolutio…

The last EIP we discussed was EIP-2677, which proposes to limit the size of INITCODE. There was general agreement towards it, but it was noted we should do more investigation about whether it would break anything currently on mainnet.

We had two more EIPs which we didn't have time to discuss. First, EIP-2935, which proposes to add the historical block hashes to the state. We will discuss that one next call.

Second was EIP-3238, which pushes back the difficulty bomb. This has to go in London, but by how far we push back the bomb is still TBD. This will be largely determined by the scope and timing of Shanghai, so we'll revisit it once that is settled.

And as a last thing on the call, we agreed to the scope of the Aleut devnet, which I've linked to previously.

That was it! We got (almost!) got through this massive list which had been there for a few calls😅 Next calls shouldn't have as many discussion items as we'll only bring things up with significant updates.

Happy Easter/Passover everyone, and see you in two weeks 👋🏻🐣

https://mobile.twitter.com/TimBeiko/status/1378053244333686784