-
Notifications
You must be signed in to change notification settings - Fork 325
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 151 Agenda #675
Comments
We'd like to propose a new JSON-RPC endpoint |
I'd like to mention the KZG Ceremony briefly just to build awareness as we wrap up the second audit and move towards the public contribution period |
Some EthereumJS takes on Shanghai HF planning:
Regarding a potential Shanghai HF in March:
Potential HF timing and scope ideas:
These are just some ideas. We are likely ok with other options as well. 🙂 |
if we do settle on pushing EOF and/or 4844 to a future fork after Shanghai then I would ask client devs to consider EIP-2537 to go along w/ withdrawals |
If we can do a minimal upgrade with Withdrawals, with a fast timeline for ~March, I think it can benefit all of ethereum:
To do this, I think it's important to NOT feature-creep the hardforks as much as possible, and just do Withdrawals first, and then 4844+EOF.
|
A couple of other Engine API things to raise if there is a time: |
Not saying it shouldn't go in, but I disagree that it's widely tested. Afaik (happy to be shown otherwise) the only usable implementation for it is in ethereum-js / hardhat right now. |
As a Solidity rep I'd also like to ask EIP-663 to be considered for inclusion with EOF. tl;dr: it's a very small change that would bring immediate huge benefits for every high level EVM language, and it has support from Solidity, Vyper and Huff. The main argument against it so far has been the need for immediate arguments, which becomes trivial with EOF. I can talk more about it if needed. |
@holgerd77 @protolambda - thanks for your thoughts re: the multi-fork planning. Will make sure we cover this, first by discussing what we should have in a fork centered around withdrawals (@ralexstokes we'll bring up BLS as part of the Shanghai CFI'd EIPs), and then what commitments we can make for the following fork. @mkalinin I've added the Engine API issues for after this during the call. @leonardoalt I've added an agenda item about EIP-663 as well. As a heads up, though, we try and avoid CFI'ing an EIP on the first call it is brought up so people generally have at least two weeks to review them more deeply and aren't surprised that something "snuck in" CFI. |
Sure, that makes sense. What I wanted to bring up was mostly that it was actually agreed for Constantinople already in the past, but needed immediate arguments which wasn't available then. If EOF goes in, and considering the above, I think it makes sense to include 663 too. |
@timbeiko to be fair EIP-663 was brought up last call too, but it didn't fit the call time. And it was actually "EFI" back in 2019 (meetings #74 to #79) 😅 |
Not sure if the selfdestruct topic will be discussed, but a proposal from 2 weeks ago now has an EIP merged: EIP-6046: Replace SELFDESTRUCT with DEACTIVATE. |
Thanks for the context, @axic! Added 6046 as well. |
Please see the thread or shanghai planning for the status. As of today it is merged in 3/5 clients and PRs out on Besu (waiting for clarity before reviewing cc @shemnon) and Erigon And those implementations are well tested, there was even a CTF deployed on a testnet |
My view of the targeted timeline, please correct me if it's off (NOT a promise of dates): Dec 8th: today. Remaining EOF work ASAP. Maybe do withdrawals-only testing till holidays to derisk optionality of EOF. So TLDR:
Also, 1153 IMO is stable and well tested, was a bit unclear during ACD, and should be included in Shanghai IMO, but with the current minimalist mindset it will probably have to go into the next HF along with 4844 (and maybe EOF if that's not ready by start January). |
Cross-posting discord R&D message: Note that we aim for a fast turn-around with Cancun, ideally in May/June, 4844 is a critical improvement for ethereum and so far we were aiming/building towards Shanghai already. So we should continue the already ongoing 4844 testnet efforts, and need client support insofar it does not delay Withdrawals. I believe Cancun should be open for additional proposals, but IMO by start of February every proposal should meet the same support/testing as 4844 to go into Cancun. E.g. EIP-1153 would be a good candidate, or EOF if it slips in January. |
Could we add a brief discussion/note on tests? Currently, the EOF EIPs are changing rather fast (weekly, if not faster). There are test PRs open in This would help the ecosystem a lot. There are many clients currently which have (internal) tests regarding these EIPs. I find myself writing tests on my own to test against the spec. But this is essentially doing work multiple times: if I want to implement EIP |
@jochem-brouwer will paste your comment in the next call's agenda: #700 |
Meeting Info
#allcoredevs
Discord channel shortly before the callAgenda
getPayloadBodiesByRangeV1
to #146 execution-apis#218The text was updated successfully, but these errors were encountered: