Ethereum Core Devs Meeting 111 Agenda

[timbeiko]

ACD 111: April 23, 2021

Note: this is an off-schedule meeting to focus on planning for the London Upgrade.

Meeting Info

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

Agenda

1. London Updates
   1. Aleut status & next steps
   2. Effort vs. Value of proposed EIPs:
      • EIP-3403 EIP-3403 - Partial Removal of Refunds #277
      • EIP-3074 Proposal to include EIP-3074 in London #260
      • EIP-2537 BLS-12381 London Inclusion #269
      • EIP-2677 Proposal to include EIP 2677 ( Limit size of initcode) in London #271
   3. London Timing London Timing #245 (comment)
2. Other Discussion Items
   1. EIP-3521
   2. Resetting the CFI status between network upgrades Proposal to have "Considered for Inclusion" reset after each upgrade #295
      • CFI status for the proposed London EIPs.

[lightclient]

I was thinking we decided in #293 to go ahead and accept EIP-3198 officially into London?

[timbeiko]

Argh, yes @lightclient my bad: deleted it from the wrong list when copy pated. Updating now!

[lightclient]

Time permitting, I'd like to introduce EIP-3521 for potential London inclusion. It is a very minor tweak to EIP-2930 that will make it much more economical for common uses.

[timbeiko]

@lightclient added 👍

[poojaranjan]

@timbeiko
"Resetting the CFI status between network upgrades #205"

Do you want to refer #295?

[timbeiko]

Yes, good catch, thanks!

[timbeiko]

On ACD 110, I said I would follow up with the different client teams to get their thoughts on the complexity and value of the various potential London EIPs, along with their preferred timelines for the upgrade. After talking with them, here are some takeaways:

1. All teams except one explictly favored a smaller scope for London, with the other not being sure, but generally wanting to limit the amount of new EIPs which get introduced into the protocol;
2. One team felt strongly about having London happen in July to minimize the risks of delays leading to increased block times caused by the difficulty bomb; another team felt that the July timeline was a stretch, but wanted to aim for it and worst-case delay by a few weeks rather than aim for August and add more things (which could delay things even farther);
3. Most teams agreed that if we keep London small in scope, it should be possible to work on another small "feature fork" in parallel to the merge without delaying it (like we did/are doing with Berlin/London and London/The Merge). There is still some uncertainty, but the rayonism hackathon should help remove the bulk of it;
4. More specifically, here are the opinions gathered about the four EIPs that are being considered:
   • EIP-2677: very small, but no one pushed for it, and it would cause some testing overhead for London. Rough consensus seems to be not including it into London.
   • EIP-2537: changing the library to blst would require additional fuzz testing, and chaging gas prices would require additional benchmarks. No strong opposition, but no one pushing to add it to London. Suggested to include into another feature fork or even alongside the merge. Rough consensus seems to be not including it in London, but it being a valuable EIP to include shortly after.
   • EIP-3403: no opposition to including it if it is helpful security-wise to deploy alongside 1559. Some concerns were raised with regards to adding even more edge cases "at the boundaries of the EVM", which is where most consensus failures seem to happen. Some people would prefer to completely remove refunds (e.g. EIP-3298), while others said we should consider re-thinking the gas refund vs. gas execution mechanism alltogether. It was recognized that doing the latter would be impossible for London, and it did not seem like anyone would want to block 3403 for not being perfect. Rough consensus seems to be that we should include it if we feel it reduces risks associated with 1559 or perhaps as a "stepping stone" towards a better gas refund reform.
   • EIP-3074: Most varied opinions: some teams very in favor, others opposed. Those in favor agree this would be a useful feature, but none of them wanted to push for London inclusion, either on the grounds that the EIP is still too recent, that 1559 is already a large enough change for a single hard fork or that they would like to see the results of a security audit, and give the community the time to digest them. Even those opposed said they could potentially be convinced by a security audit to include it in a future fork. Rough consensus seems to be that we should not inlcude it in London, but strongly consider it for another feature fork shortly after (assuming people are happy with the audit results).

Based on these conversations, teams seem to favor something close to the "July London" timeline here. If we decide to go along with this, the decisions we need to take are:

1. Do we include EIP-3403?
2. Are we happy with the difficulty bomb pushback period proposed by EIP-3238?
3. What do we want to see before we are comfortable setting fork blocks for London?

[holiman]

Regarding the off-schedule ACD calls, I think maybe we should consider not making too many decisions on them. It's fine to do an off-schedule call now and then, e.g. for making discussions go forward and/or do planning, but I think it may be good to hold for the "regular" slot for any hard decisions.

[timbeiko]

Closed in favor of #302