Thread by @TimBeiko

We just wrapped up @ethereum #AllCoreDevs 😁

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

Recap below 👇🏻

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

First, we had status updates from the Calaveras devnet. It was spammed with transactions this week, and uncovered some minor issues in Besu and Nethermind, which either have already been fixed or are being done so today/early next week 💪🏻

Then, we went through a bunch of open issues related to JSON RPC support for EIP-1559. The first was where the "effective gas price" of a transaction (the amount actually paid by the txn) should be stored. We agree to have that in the txn receipt, and updated the JSON RPC spec.

You can see @lightclients's PR here: github.com/ethereum/eth1.…

The second was how to adapt eth_call to the various parameters that are introduced by EIP-1559. @peter_szilagyi had a PR for Geth which was very thorough and other clients agreed to follow a similar approach: github.com/ethereum/go-et…

For reference, here are all the cases/behaviours that are considered, which barely fit in a single screenshot 😅

Lastly, there was an open question about how client should return estimates for the priority fee (a.k.a. tip). Right now, a lot of wallets rely on the suggested gas prices returned by clients, but post-1559 a simple return value may not be the best approach.

If we return a single value, as was suggested by adding an `eth_maxPriorityFeePerGas` endpoint, it may lead to people overpaying because they rely on a value which may be out of date or biased by recent high prices.

Instead, clients can return data about the gas used and priority fees paid in recent blocks, which will allow wallets to know whether the network is in a state of congestion or not, and what the minimum acceptable priority fees are if there is no congestion.

We agreed to go forward with this approach, described in more details here gist.github.com/zsfelfoldi/473…, with one change: we will cap the number of blocks for which this data can be returned, in order for the API to be light-client friendly.

And that was the last of the JSON RPC issues for 1559 (*touches wood*) - clients should all be on the same page now 😁

Then, @dankrad brought up an issue w.r.t. an underspecification in the Yellowpaper. The current behaviour around how a transaction initiated with a private key for a non-EOA is currently undefined.

In other words, _if_ someone had the private key to an address where a smart contract was, they could initiate a transaction for it. While the odds of this are very low (2^80), they are much higher than the odds of finding a specific private key (2^160).

In the worst case, someone could "mine" for a key + contract pair, deploy a contract which would look innocent, and eventually steal the funds from it. While this attack is _possible_, it is estimate to require the same hashrate as ~1 year of BTC mining, or ~10B$

Luckily, the fix is simple: we can reject transactions from senders if their address has bytecode associated to it. The fix is described in EIP-3607: github.com/ethereum/EIPs/…

Along with being simple, the fix does not require a hard fork, as it only restricts the current validity rules (i.e. is a soft fork). Clients agreed that this behaviour should be implemented and made canonical.

Before it is implemented, we will run a full sync of the chain to be sure such an attack has never happened before, and update the test suite + yellowpaper to support this. Then, clients will implement it when they see fit. Geth said they may implement it prior to London, but TBD

There was strong pushback against this affecting London timelines, which was our next subject 😁

With all clients comfortable with their 1559 implementation, we agreed it made sense to set testnet blocks now. Some of the JSON RPC changes mentioned at the beginning may come after the testnet forks, but all the consensus-related changes for 1559 are ready to go!

Clients all think they can have a release ready sometime next week, so we'll have the first testnet fork 7-10 days after that. The fork blocks + dates have been added to the London spec: github.com/ethereum/eth1.… 🇬🇧🎉

You can expect a post on blog.ethereum.org next week with the versions for each client which will support London on testnets.

IMPORTANT NOTE: the mainnet block will be chosen after we see testnets forking smoothly, and hence will require another client upgrade.

And that was it for London 🇬🇧 Next on the call we had an update on the EIP-3074 audits 😁

First, @lightclients gave some background on EIP-3074. I recommend watching the livestream for it, or reading his excellent tweet thread:

https://twitter.com/lightclients/status/1371911245561917441

@LeastAuthority then shared the findings from their audit. The report is not available yet, but should be shortly.

The whole commentary is worth watching, but one conclusion was that 3074 invokers, if we can assume them to be safe (i.e. simple, formally verified, audited, etc.) can be thought of as "wallet extensions" and have a similar security profile as wallets.

Then, the second auditing firm, @dedaub, who analyzed the impact on current smart contracts, shared their thoughts. They had previously also done so on Twitter:

https://twitter.com/dedaub/status/1403083441772638211

Again, the livestream is worth watching for nuance, but their main takeaway is shared here:

https://twitter.com/dedaub/status/1403083459988537350

The audits seem to address some of the security concerns that had previously been raised by @mhswende and others. Given that London is not done yet, and that the picture is unclear for what comes after with the merge and/or Shanghai, it is still to decide on 3074's next steps.

To be clear, though, there is still some pushback (e.g. see this exchange:

https://twitter.com/lightclients/status/1403383142300278792

) and the EIP's champions explicitly said they don't want this to be included because everyone ends up exhausted from debating it.

Once we are a bit farther along with planning future upgrades and that people have had time to read + digest the audits, we'll be discussing this again on the call.

And with this, we were at time. We had time for two quick announcements. First, it seems there were some issues on Goerli. It seems like they may have been caused by Nethermind and were being fixed on the call. Last block seems recent (goerli.etherscan.io/block/4951357), which is good!

Lastly, the @EthCatHerders and @nethermindeth are running a survey to better understand the future requirements of client developers in terms of tools and documentation.

If that's you, your answers would be helpful. You can answer here: docs.google.com/forms/d/e/1FAI… 😁

And that was it, see you on the next call, on June 25th, 14:00 UTC. By then, London will already be live on Ropsten 🇬🇧