Skip to content
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 79 Agenda #148

Closed
Souptacular opened this issue Jan 18, 2020 · 13 comments
Closed

Ethereum Core Devs Meeting 79 Agenda #148

Souptacular opened this issue Jan 18, 2020 · 13 comments

Comments

@Souptacular
Copy link
Contributor

Souptacular commented Jan 18, 2020

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 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
Copy link
Contributor Author

Souptacular commented Jan 18, 2020

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
Copy link
Member

karalabe commented Jan 20, 2020

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
Copy link
Contributor

shemnon commented Jan 21, 2020

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

@shemnon
Copy link
Contributor

shemnon commented Jan 21, 2020

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
Copy link

carver commented Jan 21, 2020

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
Copy link
Member

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
Copy link
Collaborator

tvanepps commented Jan 23, 2020

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
Copy link
Contributor

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
Copy link
Member

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

@MadeofTin
Copy link
Contributor

MadeofTin commented Jan 24, 2020

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
Copy link

shamatar commented Jan 24, 2020

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
Copy link
Collaborator

Closed in favor of #150

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants