Thread by @TimBeiko

First @ethereum #AllCoreDevs of 2021 starting in ~15 minutes 🎉

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

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

Starting the call with YOLOv3 updates!

Nethermind going first: EIP-2929 now passes all tests, and they are waiting for some final specification decisions for EIP-2930 & 2718. Everything is ready 👍🏻

Besu: everything is implemented, and the team is working on testing for 2930 ✅

OpenEthereum: everything should be ready 🎉

Geth: EIP-2930/2718 is still remaining, and then there are still a few small issues to fix. @lightclients is leading the implementation, and says it should be up to spec. Going into the details on the call now about the final tweaks 📺

There's also an update from EthereumJS: they are hoping to have a client ready for the testnets!

Given how far we are in the process, it's worth asking if we want to even deploy YOLOv3 or go to public testnets directly.

@peter_szilagyi says that could prevent the major testnets from breaking, and @mhswende says it's now pretty easy to launch the YOLO networks.

So we agree to keep YOLOv3. It will probably still take a few weeks to get the network set up because Geth needs to merge the EIP-2930/2718 PR and most of the tooling to deploy YOLO networks is geth-based.

So the next steps are:
1. Geth team merging the PR
2. James following up with all the other client teams to make sure they are ready for fuzzing once YOLOv3 is up
3. Setting up YOLOv3

Next up on the agenda is evm384 updates. @Shamatar had a questions on the agenda about performance, specifically the overhead of using the EVM vs. precompiles.

In short, even if the new evm384 opcodes are cheap gas-wise, the gas that is spent on "control flow" for curve operations ends up being more expensive than a full call to a precompile.

@chfast says the team is working on this, and shares the technical details on the call 👀

And now, we're having a lot of back and forth about the security & performance tradeoffs of various approaches to add BLS support. Worth watching the livestream for the nuance 📺

The gist of what @Shamatar is trying to get here is a standardized approach to adding cryptographic precompiles.

@mhswende is skeptical we can have such a formal approach and it should be more on a case by case basis.

The downside is this is obviously that implementers can "do all the work" and feel like it gets rejected for subjective reasons.

Re: BLS specifically, one thing that would increase Geth's confidence is seeing a slower rate of change in the libraries' codebase and seeing them used in the wild for a longer time.

Given that this topic comes up frequently on AllCoreDevs, I wonder if it may not be worth it to have a separate call/track to discuss precompile/crypto primitives.

It seems like there is _some_ interest for this, but it's also not only a technical issue, but a process one: how do we reject things? how do we make that clear to folks working on potential improvements to the protocol?

We've tabled the discussion for now. The @EthCatHerders will try and coordinate a crypto primitive breakout room as a next step.

Next up is an EIP by @VitalikButerin: EIP-2937 (github.com/ethereum/EIPs/…), which adds a SET_INDESTRUCTIBLE opcode.

Here's the gist of the EIP:

The first question is "why we don't remove self-destruct instead"? The short answer is that some contracts could break (e.g. a vault that could only issue a refund using self-destruct).

The longer answer, by @_SamWilsn_, is the above, and that SET_INDESTRUCTIBLE is backwards compatible and simpler, so we could likely do it quicker than removing SELF_DESTRUCT.

It is worth noting that adding SET_INDESTRUCTIBLE doesn't preclude eventually removing SELF_DESTRUCT.

@mhswende adds that removing SELF_DESTRUCT could also break a lot of upgradability patterns for some contracts.

(Side note: the self destruct vs. set indestructible answer was by @adietrichs, not Sam:

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

)

And last up on the agenda, is Hudson sharing that he will be stepping down from facilitating the AllCoreDevs calls. He had previously shared it on Twitter here (

https://twitter.com/hudsonjameson/status/1341081879013969925

) and is giving more explanations on the call. Worth watching!

Hudson will be staying on facilitating the calls until Berlin is shipped. In the meantime, I'll be ramping up part time and focused on finding someone to replace me at @ConsenSysQuorum.

The one thing I've started to do is having chats with folks about how AllCoreDevs can be improved. If you have strong opinions about this, please reach out and we'll schedule a chat 😁 DMs are open.

One more announcement from @poojaranjan19: the @EthCatHerders will be having two Peep an EIP calls to cover Berlin EIPs, one on Jan 15th to cover EIP-2929 & 2930 and one on Jan 20th to cover EIP-2315.

The recordings are then uploaded to Youtube: youtube.com/playlist?list=…

And one more, @vorot93 shared the link to a previous EIP that advocated to remove SELF_DESTRUCT: github.com/ethereum/EIPs/…

ethereum-magicians.org/t/eip-for-disa…

And that's it! The next call is scheduled for Jan 22nd, 14:00 UTC. See you then 👋🏻