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 149 Agenda #652

Closed
timbeiko opened this issue Oct 27, 2022 · 14 comments
Closed

Ethereum Core Devs Meeting 149 Agenda #652

timbeiko opened this issue Oct 27, 2022 · 14 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Oct 27, 2022

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

@marioevz
Copy link
Member

marioevz commented Nov 1, 2022

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

xinbenlv commented Nov 1, 2022

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

@q9f
Copy link
Contributor

q9f commented Nov 7, 2022

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

timbeiko commented Nov 7, 2022

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

mkalinin commented Nov 8, 2022

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

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

xinbenlv commented Nov 9, 2022

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

@timbeiko
Copy link
Collaborator Author

timbeiko commented Nov 9, 2022

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

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

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

xinbenlv commented Nov 9, 2022

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

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

@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.

@timbeiko
Copy link
Collaborator Author

Closed in favour of #662

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

7 participants