Ethereum Core Devs Meeting 109 Agenda

[timbeiko]

ACD 109: April 2, 2021

Note, with DST ending, the meeting time may be different in your region. Please double-check the meeting time in the section below. UTC time does not "move".

Meeting Info

• April 2, 2021, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/V-Qz4UN6Z88
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

1. Berlin Updates
   • Rinkeby fork updates #248
   • Mainnet fork April 14th
   • EthCatHerders Community Call
2. London Updates
   • Client implementation updates
3. Shanghai & The Merge Proposals:
   • Shanghai delayed with focus on merge #278
     • "Merge sprint" from mid-April to mid-May
   • Shanghai in October (no merge) #267
4. EIP Discussions
   1. EIP-3403 - Partial Removal of Refunds #277
   2. BASE FEE Opcode #270
   3. EIP-3074 - AUTH and AUTHCALL opcodes #260
   4. EIP-2537 - Precompile for BLS12-381 curve operations #269
   5. EIP-2327 - BEGINDATA #262
   6. EIP-2677 - Limit size of initcode #271
   7. EIP-2935 - Save historical block hashes in state #279
   8. [Aleady in London] EIP-3238 - Difficulty Bomb #256
      • Need to agree on pushback period
5. [Announcement] EVM working group For 109 agenda: EVM working group #292

[timbeiko]

(example comment):

I would like to discuss XYZ on this call, more information can be found in issue #999

[timbeiko]

Removed EIP-3322 from the agenda because it was agreed on ACD 108 not to include in London. See #266 (comment)

[evertonfraga]

Berlin is out of the door for most testnets right now. Could we aim to move EIPs 2930 and 2929 from Preview to Last Call and then Final?

[timbeiko]

@evertonfraga good point! @holiman @MicahZoltu could you please move EIPs 2718, 2929 and 2930 to Last Call? We should move them to Final in the call after.

[gcolvin]

@timbeiko Whether it comes before or after the merge, I think a clear candidate for a future "feature" fork is to pull together our outstanding EVM proposals into a coherent whole.

I've re-opened an EVM group on the Magician's as a place to start on these and others.

• EVM encapsulation format
• EVM384
• List of EVM features potentially worth removing
• EIP-3337: Frame pointer support for memory load and store operations
• EIP-3336: Paged memory allocation for the EVM
• EIP-2930: Optional access lists
• EIP-2327: BEGINDATA
• EIP-2315: Simple Subroutines for the EVM
• EIP-1153: Transient storage opcodes
• EIP-1051: Overflow checking for the EVM
• EIP-616: SIMD Operations for the EVM
• EIP-615: Subroutines and Static Jumps for the EVM

[jochem-brouwer]

retracted

[CryptoBlockchainTechnologies]

The same thing is also caused by for instance EIP1559, which had an old reference implementation based upon a much older spec in it for a long time.

Why does the EIP not have a security process?

I agree. 1559 presents a huge security risk due to the major changes in base fees calculations and burning. The later has never been done before for any crypto currency. I found the admission in the EIP alarming that they have no idea what impact fee burning will have. I would have expected at least two seperate audits before 1559 was accepted since there are different security risks associated with those two.

1559 lists four securiry concerns, none of which had formal audits, why? Also it may help to understand the guidelines (not sure there are any) if we can list EIPs that have been audited before in the past and why? I will start the list:

• 1057 - Not sure why it had to be audited but it was
• I am sure there are others someone help me here

[holiman]

Why does the EIP not have a security process?

EIPs have a security section. It's expected that EIPs are vetted in various discussion forums, and the implementations vetted, tested, audited, just like every single thing that ever touches how clients reach consensus.

Take EIP2929 for instance, these access lists could maybe lead to some very sophisticated behavior where an attacker can use the gas used after a message call to determine if a slot was already accessed in a prior call or not (I can't think of a case where this would be useful, but EIP2929 leaks some info on touched storage slots by the gas schedule, based upon if the slot was on the warm slots or not).

Yes. So do you think that behaviour is worse, from a security perspective, than the unbounded state growth which is a clear and present DoS vector against all nodes on the network? And if so, how come you have not raised this in the discussion-forums, or ACD channel or call?

I find it also disturbing to know that the YoloV3 testnet to test Berlin hardfork on did not include any EIP2315 (subroutines) transactions

2315 was fuzzed quite a lot. It was also again fuzzed in the first testnet. The idea behind the feature-testnets was to test the features, yolov3 focused on 2930 and 2929, which were new. We didn't focus on the non-features. I think the amount of people who actually sent transactions on yolov3 can be counted on one hand. With fingers to spare.

In general I think we should move to a much more secure EIP process, where there are several stages of security considerations and upgrades in terms of testing (first some basic tests, then when two clients think they are OK, implement ethereum/tests, and also audit these tests to ensure that they cover each case).

Does that mean "the geth team should set up more testnets, and the test-team should work harder", or does it mean "we'll take more responsibility for cross-client testing going forward".

Sorry if I sound angry, I felt a bit personally attacked here, and I probably should have not responded right now. It's a bit annoying that when we do find issues, it's more or less "ok, thanks, fixed, let's move on", while when something slips through it's a lot of high and mighty outrage about "the process".

[timbeiko]

A few more comments:

Why are these EIPs not on the right status? This looks kind of sloppy to me and signals that there either is no management or there is no interest to keep these EIPs updated.

The challenge here is that EIP authors are the only people who can update their EIPs, so there is a limit to what "management" can do.

take EIP1559 for instance, a few transactions together with their expected signatures and hashes would already be a great help to implement these

Those tests are not written yet, and they typically are done later in the upgrade process. We are about to work on them, and I had planned to ask about them on tomorrow's call.

[vbuterin]

I agree. 1559 presents a huge security risk due to the major changes in base fees calculations and burning. The later has never been done before for any crypto currency.

It's worth noting that there has been unprecedentedly extensive economic review and audits on EIP 1559's economics, including concerns about the consequences of burning (this is of course separate from the question of whether the code correctly implements the economics, but that's not a bigger problem for this EIP than for any other). This all happened throughout 2019 and 2020. So I don't see any good reason to reopen that can of worms. Technical tests of the spec/code should of course be done as with any EIP.

[vbuterin]

EIP-2935 - Save historical block hashes in state #279

On this topic, one thing to keep in mind is that with an accelerated merge this is probably not worth it, because the beacon chain already stores historical beacon roots in the beacon state, and so the first post-merge fork that adds a BEACONBLOCKROOT opcode can easily provide similar functionality.

[CryptoBlockchainTechnologies]

It's worth noting that there has been unprecedentedly extensive economic review and audits on EIP 1559's economics, including concerns about the consequences of burning (this is of course separate from the question of whether the code correctly implements the economics, but that's not a bigger problem for this EIP than for any other). This all happened throughout 2019 and 2020

I am not aware of any formal audits done for 1559 by third party independant agencies and where the funding came from. Can you elaborate more, perhaps provide some links to the formal audit reports and shed some light on the third party auditors and who funded the audits?

When I did a google search for Ethereum audits I came up with this for 1057, could not find anything on 1559. https://leastauthority.com/static/publications/LeastAuthority-ProgPow-Algorithm-Final-Audit-Report.pdf

Can you provide a likewise audit of 1559?

I also found 2.0 has been audited so that makes two audits that I know of, well actually only one for Eth 1.0
https://leastauthority.com/static/publications/LeastAuthority-Ethereum-2.0-Specifications-Audit-Report.pdf

Found this on Discord 1559-fee-market

Perhaps Micah has a great point. This is where the distrust of miners and the EIP process began and continues to this day with 1559 being implemented without the same dick move requiring an audit, using Micah's elegant words

It also seems there was money allocated for a formal audit from the grant @timbeiko was this ever done?

.