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 66 Agenda #113

Closed
timbeiko opened this issue Jul 23, 2019 · 5 comments
Closed

Ethereum Core Devs Meeting 66 Agenda #113

timbeiko opened this issue Jul 23, 2019 · 5 comments

Comments

@timbeiko
Copy link
Collaborator

timbeiko commented Jul 23, 2019

Ethereum Core Devs Meeting 66 Agenda

Agenda

  1. Istanbul EIPs go/no-go
    • EIP 1344
    • EIP 1283/1706/2200
    • EIP 1057
    • EIP 1962
    • Other EIPs to consider for Istanbul
  2. EIP Refactoring
    • Given EIP-1702: Which of the Istanbul EIPs live only in version 1 code? Which live in version 0 and version 1 code?
    • Proactive refactoring of the client implementations to make EIPs more simple, and reduce their conflicts.
  3. Conformance Testing
  4. Testnet Upgrade Block Number
  5. Review previous decisions made and action items
  6. Next Network Upgrade
  7. Working Group Updates
  8. Testing Updates
  9. Client Updates (only if they are posted in the comments below)
    a) Geth
    b) Parity Ethereum
    c) Aleth/eth
    d) Trinity/PyEVM
    e) EthereumJS
    f) EthereumJ/Harmony
    g) Pantheon
    h) Turbo Geth
    i) Nimbus
    j) web3j
    k) Mana/Exthereum
    l) Mantis
    m) Nethermind
  10. EWASM & Research Updates (only if they are posted in the comments below)
@fubuloubu
Copy link

fubuloubu commented Jul 23, 2019

Is the meeting date/time correct?

@timbeiko
Copy link
Collaborator Author

@fubuloubu it wasn't. Thanks for the catch! Updated.

@shamatar
Copy link

Results and points for EIP1962:

  • Separate into 7 precompiles for corresponding operations (proposed by @shemnon), need developers consensus on what can be called "standard practice" for it
  • Fuzzy testing on 32 core machine over 6 days, 16M iterations per hour. Found few mistakes, but those were parsing related. Will result in making Rust implementation ABI parser more in style of stateful parser from C++ for convenience
  • Proposal for Istanbul:
    • Use universal codebase and universal gas metering policy
    • Whitelist 7 pairing friendly curves for use with "Pairing" and "G2_" operations. Those can be easily whitelisted by comparing first 100 bytes in the input. "G2_" ops do not contain non-trivial edge cases compared to "G1_*", but are useless on non-pairings curves, so can be whitelisted too
    • Keep "G1_*" operations universal for any curve. Those have only 1 possible edge case in arithmetic and it's covered

@axic
Copy link
Member

axic commented Jul 26, 2019

@holiman can we get some discussion/decision on EIP-1884?

@timbeiko
Copy link
Collaborator Author

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

4 participants