ethereum/pm

Ethereum Core Devs Meeting 79 Agenda

Souptacular opened this issue · 12 comments

Souptacular commented

Ethereum Core Devs Meeting 79 Agenda

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 #1
  4. @karalabe's RPC spec issue
  5. Review previous decisions made and action items
    • Call 78
  6. Next call
Souptacular commented

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

  • 👍1
karalabe commented

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 commented

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

shemnon commented

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 commented

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.

  • 👍1
karalabe commented

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.

  • 👍5
tvanepps commented

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 commented

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 commented

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

shamatar commented

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 commented

Closed in favor of #150