-
Notifications
You must be signed in to change notification settings - Fork 322
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 120 Agenda #370
Comments
Re: 2681/3338: Neither are realistically reachable by anyone. Making one of these assertions just makes it easier to reason about the system and for new client developers and integrators to choose appropriate types for this field when working with it internally. |
Because (EIP-2681 vs. EIP-3338) may not be added to the network upgrade, I would appreciate a discussion (followed by documentation in EIP-1?) on the process to move Core proposals like this for the future reference. |
The JSON RPC work is coming to a head. We need many reviews (at least one per endpoint) for all 5 clients. @DockBoss has created pull requests in the execution-apis repo with the edgecases pertaining to several endpoints with more to follow. In order to maximize throughput it would be good to get someone from every client who can be very responsive to review / comment on edgecases over the next month or so. I spoke with Tomasz about this and he recommended I bring it up here. Can we put this on the agenda? |
@alita-moore sure 👍 Is there somewhere to point people to? |
I can create an issue and collect the relevant PRs into there if it would help. |
That would be great, @alita-moore 😄 |
Can we also add eip-1352 (reserve 0x0->0xffff for precompile and system contracts) to the discussion since we are talking about nonce limits too? The actual technical impact now is the cold/warm gas charge. Nethermind and Besu both had consensus bugs in the ephemeral testnets related to counting precompiles wrong for Berlin and this would limit the impact going forward. I'll actually call in for this. |
Sure @shemnon 👍 |
@timbeiko here is the issue with the relevant links ethereum/execution-apis#56 |
Last minute addition to the agenda, but I've spoken with client teams over the past two weeks, and here's a summary of their thoughts on how London went, and what their priorities are for the next ~6 months: https://hackmd.io/@timbeiko/london-retro |
To put this into perspective all this originates from EIP-1985 where we wanted to put upper bounds to a lot of fields. 2681 was the first item split out as an experiment to see how long it takes to finalise it. The proposed 64-bit limited is already enforced by geth, so no code change is needed. @MicahZoltu raised that limiting it for floating points would help JavaScript tools, but also require an actual code change to clients. One could argue that for nonce this can make sense, as many of the transaction are generated by JavaScript-based systems. One must note however that JavaScript has native bigint support for a while now. An argument against this is that where do we stop? There are many other fields which are 64-bit today in "Eth1" and should we keep JavaScript in mind for all of these? What about beacon chain related fields?
The next step for this particular EIP would be creating a consensus test, where an account is preset to an artificially high nonce. We can agree this is not going to happen on mainnet, but having a test would ensure that every client complies. |
TL;DR Should we bend over for JavaScript special needs? I think not. |
We have everything in |
I'm OK with just officially saying nonce is a IMO js implementors can choose to use a limit of |
Pushed the change here: ethereum/EIPs#3750 |
Closed in favor of #379 |
Meeting Info
Agenda
The text was updated successfully, but these errors were encountered: