Ethereum Core Devs Meeting 149 Agenda

[timbeiko]

Meeting Info

• November 10, 2022, 14:00 UTC
  • • ⏰ DST note: double check your local time for this call, as it may have shifted with Daylight Savings Time starting.
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/ZZx7d14vE10
• Zoom: shared on #allcoredevs Discord server shortly before the call

Agenda

• Shanghai Planning #450 (comment)
  • EOF updates
  • EIP-4844 updates
  • Increasing Operational Cost of Running an Ethereum Node
• Shanghai Candidate EIPs discussions
  • EIP-4758
  • Proposal to include EIP-1153 in Shanghai #438
  • Proposal to add EIP-2537 (BLS Precompile) to Shanghai #343
  • Proposal to add EIP-2294 to Shanghai  #645
• Engine API spec improvement proposal execution-apis#321
• Shanghai "Core" vs prototypes devnet
• Other topics
  • Ropsten sunset date (and testnet sunsetting generally)
  • Executable Specs
  • https://github.com/ethereum/execution-spec-tests/

[marioevz]

I would like to add an introduction to the work that is being done on https://github.com/ethereum/execution-spec-tests/, to get everybody on board to what is developing regarding the execution spec tests, and also gather some feedback.

[xinbenlv]

Propose to add to the agenda: EIP-2294 for bounding chainId #645

[q9f]

Ropsten sunset date

I would also discuss the other testnets because this caused some frustration previously.

Proposal: https://ethereum-magicians.org/t/proposal-predictable-ethereum-testnet-lifecycle/11575

[timbeiko]

@q9f thanks! added to the agenda, but bumped to the end given this will likely require a bit more discussion than just agreeing on a date for Ropsten, and I want to make sure we cover updates to specs/tests formats on the next call. At the very least, we can point people to the thread and have a longer conversation on the next call if needed!

[mkalinin]

If we have a time I would like to quickly go over the recent proposal on Engine API spec improvement ethereum/execution-apis#321

[MicahZoltu]

I would like to talk about the elephant in the room on this call: Increasing Operational Cost of Running an Ethereum Node

Ethereum has an operational cost problem and I estimate 0% of Ethereum users (rounded to nearest integer) actually run their own node. This means the other ~100% of users are utilizing centralized services, many of which actively censor. Lately we have seen a lot of discussion about "scaling", and this usually results in making the operational cost problem worse, lowering that 0% to a smaller 0%. EIP-4844 is a prime example of this in that it will increase both network bandwidth and disk requirements of operating a node notably. I'm concerned that we "lost the plot" somewhere along the way and are now worried about attracting users rather than building censorship resistant software.

The common argument I see is "we'll fix the operational cost problem later", usually with references to verkle trees and stateless, but very often in software "later" never comes, or it comes too late. We are already seeing active censorship throughout the stack on Ethereum (MEV relays, RPC providers, app frontends, etc.) and I think that we should be focusing all of our efforts on addressing those problems and actively pushing back against changes that make the problem worse until such time as we have addressed the operational cost and censorship issues. This would mean devoting more resources to verkle trees, statelessness, Portal Network, EIP-4444, CR Lists, internal refactoring, etc. and less time on proposals like EIP-4844 which focus on scaling at the cost of operational costs.

[xinbenlv]

@MicahZoltu I quite resonate. I deeply worry the censorship is only to increase if we didnt prioritze it soon

[timbeiko]

@mkalinin - added to the agenda 👍

@MicahZoltu thanks for bringing this up! I've added it to end of the agenda, but like for the broader testnet proposal, I think there's a risk we aren't able to cover it with the attention it deserves on this call. That said, this is an important topic, and I think perhaps if we time box it, we could move it up the agenda (and then have a longer conversation on the subject later as well). Curious what you think is the best approach here!

[MicahZoltu]

@timbeiko I think it is important to discuss the issue prior to deciding on 4844. If we delay talking about this issue, then I fear there is a good chance that 4844 will go in without really being challenged, which aligns with how we have been going about this problem for the last several years (perpetually kicking the can down the road).

I brought it up in this agenda (rather than the previous one) because I was under the impression that this was the call where we would try to figure out what is actually going into Shanghai, and I think talking about the inoperability of Ethereum clients is an important part of that discussion that shouldn't be skipped because it is uncomfortable/not-fun.

I'm fine with any solution that gets the developers actually talking about the issue, whether that be timeboxing or something else, as long as we get people seriously thinking about our priorities and intentionally making the call to continue to sacrifice client usability for scalability (and other features) rather than having it happen as an unintended side effect.

[AlexeyAkhunov]

In my opinion, withdrawals is the only change that needs to happen as soon as possible - to establish the liquidity of BETH and help small validators run their nodes - because currently they are disadvantaged due to the illiquidity of their rewards. Larger entities have access to longer funding and credit, and can wait, smaller operators - less so.

All other things should be prototyped but they can be rolled out after that one

[xinbenlv]

@AlexeyAkhunov emm, good point.

If I read it correctly, if node operating cost is a main source of disasvantage for smaller node runner and causing more centralization, the economic opportunity cost to run a node without ability to withdraw adds to that disadvantage for smaller node runner. Is it a correct understanding?

[AlexeyAkhunov]

If I read it correctly, if node operating cost is a main source of disasvantage for smaller node runner and causing more centralization, the economic opportunity cost to run a node without ability to withdraw adds to that disadvantage for smaller node runner. Is it a correct understanding?

Yes, correct

[timbeiko]

@MicahZoltu that makes sense, appreciate the extra context. Bumped it up in the agenda so that we can have the discussion prior to making any decisions about Shanghai scope.