Pm: Ethereum Core Devs Meeting 66 Agenda

[timbeiko]

Ethereum Core Devs Meeting 66 Agenda

• Meeting Date/Time: Friday 26 July 2019 at 14:00 UTC
• Meeting Duration 1.5 hours
• YouTube Live Stream
• Istanbul Roadmap
• EIP Readiness Spreadsheet

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
   
   
   
   • Call 64
   
   
   • Call 65
   
   
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]

Is the meeting date/time correct?

[timbeiko]

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

[shamatar]

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]

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

[timbeiko]

Closed in favor of https://github.com/ethereum/pm/issues/116. Notes from the call available here: https://github.com/ethereum/pm/blob/a0c3a021bee9ae8c6a3d7a216afd374de6c88582/All%20Core%20Devs%20Meetings/Meeting%2066.md