Ethereum Core Devs Meeting 79 Agenda

[Souptacular]

Ethereum Core Devs Meeting 79 Agenda

• Meeting Date/Time: Friday 24 January 2020, 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream

Agenda

1. Eligibility for Inclusion (EFI) EIP Review
   1. UNGAS
   2. EIP-2464 (eth/65)
   3. EIP-2348 (Validated EVM contracts)
   4. EIP-2456 (Time Based Upgrade Transitions)
   5. EIP-1962 (EC arithmetic and pairings with runtime definitions)
   6. EIP-1559 (Fee market change for ETH 1.0 chain)
2. Testing updates
3. EIPIP (EIP Improvement Proposal) Meeting AllCoreDevs Meeting 8 Agenda #1
4. @karalabe's RPC spec issue
5. Review previous decisions made and action items
   • Call 78
6. Next call

[Souptacular]

Tim Beiko will be running this meeting. For the EIPIP item, Pooja or anyone else who was in attendance can speak on it if they want. Otherwise, it was a success and we have a repo with videos, notes, and agendas set up: https://github.com/ethereum-cat-herders/EIPIP

[karalabe]

I have an new EIP for extending eth again with 2 3 tiny messages (GetPooledTransactions, NewPooledTransactions, PooledTransactions). It should help drastically reduce bandwidth consumption across the entire network by allowing a proper tx propagation mechanism to be implemented vs. the current broadcast everything to everyone all the time.

I've already posted it to the all core devs channel, people replying until now like it. Unless someone vehemently opposes, we'd like to roll it out in the next Geth release (no fork needed, only a backward compatible networking change).

ethereum/EIPs#2464.

---

Edit: @cburgdorf suggested we do a separate (new) reply message instead of reusing the existing Transactions message. This keeps the protocol a bit more obvious and makes it easier to pile request IDs on top afterwards. Updated the EIP accordingly.

[shemnon]

I'd like to add a second review of Validate EVM contracts to the EFI review (ethereum/EIPs#2348)

[shemnon]

Also, a second review for ethereum/EIPs#2456 - time based upgrade transitions. I don't recall any serious issues, so if all goes well should it go to EFI?

[carver]

I don't recall any serious issues, so if all goes well should it go to EFI?

I'm 👎 on an implementation that requires looking up a bunch of historical headers to decide which VM version applies to a given header.

[karalabe]

Hit an interesting RPC spec issue. When requesting the pending block, the spec states the number returned should be null. We changed that in Geth too (and immediately got people complaining). Parity implements it as null too.

I think the spec is wrong. While the notion of the pending block is indeed a bit weird, I think having the actual number in there is important, because transaction executions included in the pending block depend on number. Since they do have access to the number, that's contextual info used while building the pending block, so we shouldn't just swallow it to adhere to a random spec.

[tvanepps]

will there be any additional discussion on EIP 1559? now that the Magician's thread has gone live and there has been time to review it

[MadeofTin]

Let’s have a discussion around unGAS and how best to proceed given the situation with Parity. If we can also have it early in the call as Alexey is only able to attend the first hour and it will be important to include him. UnGAS would help with the transistor is to Stateless Ethereum.

[karalabe]

Could you paste a link to the ungas EIP/threads for a readup?

[MadeofTin]

https://ethereum.corepaper.org/compatibility/forward/#remove-gas-observables-and-better-error-handling

The proposal ^

Context with Eth1.X
https://blog.ethereum.org/2020/01/17/eth1x-files-digest-no-2/

I wasn’t able to find any threads on Ethmagicans or EthResear.ch

[shamatar]

Small update on EIP1962:

• EIPs repo is updated with links to the single source of truth
• Gas schedule will be updated to 30Mgas/second on my reference machine as a mean value between ecrecover and PAIR precompiles based values
• recent optimizations made Rust and C++ code 20-30% faster, so there is a built-in security margin now (gas schedule will not account for recent optimizations)
• @saitima has made a Go version of the precompile (x86-64 only due to assembly for now) that is as fast as Rust one and we do fuzzy testing of it now
• there is an idea how to make Go code for all the platforms without templates and with great performance
• after Go implementation is fuzzy tested there will be an ABI update that will give the following convenience:
  • no need for modular reduction for scalar values for multiplications (e.g. when you get a large hash value and will not need to do “mod” operation)
  • subgroup checks will become optional. All the operations I would imagine (Snarks, BLS signatures) have some pairing points hardcoded, so it’s not necessary to check for their subgroup as it can be done either separately (using multiplication) or off-chain. For large fields and groups such checks take 50% of computation time (e.g. MNT4-753 curve)

Update:

Go implementation repo

[timbeiko]

Closed in favor of #150