Ethereum Core Devs Meeting 120 Agenda

[timbeiko]

Meeting Info

• August 20, 2021, 14:00 UTC
• Duration: 90 minutes
• Youtube Stream: https://youtu.be/rlIgpf2V4ks
• Zoom: To be shared on #allcoredevs Discord server shortly before the call

Agenda

• Merge updates EIP-3675: Upgrade consensus to Proof-of-Stake #361
  • Consensus API design space
• London Retrospective (link)
• Limiting account nonce: EIP 2681 vs. 3338 see comments 1, 2
• EIP-1352, see comment
• eth/65 deprecation eth: drop eth/65, the last non-reqid protocol version go-ethereum#23120
• EIP-3607, core: check if sender is EOA go-ethereum#23303
• Announcements:
  • Geth hotfix v1.10.8
  • JSON RPC spec reviews JSON RPC Endpoints execution-apis#56
  • Repository / discord renaming from eth1/eth2 to execution/consensus, link
  • Stateless Ethereum: Verkle Trie Gas Costs for Code Chunks #377

[lightclient]

Can we come to consensus on EIP-2681 vs. EIP-3338 (limiting account nonce)?

[MicahZoltu]

Re: 2681/3338:
2^64-1 is a natural bound for 64-bit integer systems (not JavaScript).
2^52 is a natural bound for 64-bit floating point systems (JavaScript).

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.

[poojaranjan]

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.

[alita-moore]

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?

[timbeiko]

@alita-moore sure 👍 Is there somewhere to point people to?

[alita-moore]

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

[timbeiko]

That would be great, @alita-moore 😄

[shemnon]

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.

[timbeiko]

Sure @shemnon 👍

[alita-moore]

@timbeiko here is the issue with the relevant links ethereum/execution-apis#56

[timbeiko]

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

[axic]

Re: 2681/3338:
2^64-1 is a natural bound for 64-bit integer systems (not JavaScript).
2^52 is a natural bound for 64-bit floating point systems (JavaScript).

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?

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

[vorot93]

TL;DR Should we bend over for JavaScript special needs?

I think not.