Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ethereum Core Devs Meeting 111 Agenda #301

Closed
timbeiko opened this issue Apr 16, 2021 · 9 comments
Closed

Ethereum Core Devs Meeting 111 Agenda #301

timbeiko opened this issue Apr 16, 2021 · 9 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Apr 16, 2021

ACD 111: April 23, 2021

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

Meeting Info

Agenda

  1. London Updates
    1. Aleut status & next steps
    2. Effort vs. Value of proposed EIPs:
    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
Copy link
Member

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

@timbeiko
Copy link
Collaborator Author

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

@lightclient
Copy link
Member

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
Copy link
Collaborator Author

@lightclient added 👍

@poojaranjan
Copy link
Contributor

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

Do you want to refer #295?

@timbeiko
Copy link
Collaborator Author

Yes, good catch, thanks!

@timbeiko
Copy link
Collaborator Author

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
Copy link

holiman commented Apr 23, 2021

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
Copy link
Collaborator Author

Closed in favor of #302

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants