Ethereum Core Devs Meeting 65 Agenda

[Souptacular]

IMPORTANT: All EIPs are on the chopping block for Istanbul at the next meeting unless there is a reference implementation or the champion can successfully argue one is not needed. EIPs not included in Istanbul are pushed back and can be reintroduced at the next fork.

Ethereum Core Devs Meeting 65 Agenda

• Meeting Date/Time: Thursday 18 July 2019 at 22:00 UTC (NOTE: Going forward, call times will rotate -8 hours each call)
• Meeting Duration 1.5 hours
• YouTube Live Stream
• Istanbul Roadmap

Agenda

1. Istanbul EIPs Chopping Block
   • EIP-615
   • EIP-1344 vs. EIP-1965
     • Can we make a decision on EIP-1344 independently of EIP-1965?
   • EIP-1283
     • There was an AMA with no further questions about the EIP.
   • EIP-1962
   • EIP-2028
   • EIP-2024
   • Other EIPs under consideration
     • State Rent EIPs
     • ProgPow
     • Others
   • Everything else gets pushed from Istanbul?
   • Update EIP-1679: Istanbul Meta
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. Review previous decisions made and action items
5. Adding "Security Considerations" to EIP-1
6. Working Group Updates
7. Testing Updates
8. 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
9. EWASM & Research Updates (only if they are posted in the comments below)

[CPSTL]

Agenda Item Request: Formally discuss whether or not we should be including ProgPow into Istanbul. If we do add it in and something comes up along the way before the hardfork, we can simply just pull it.

[gluk64]

Agenda Item Request: status update on alternative implementation of EIP1962 in C++.

[fubuloubu]

So meetings are no longer every other Friday?

[shamatar]

Initial PR for EIP1962 into Parity is complete (link). For Geth two options will be provided over the next two weeks:

• Add building of Rust code into the pipeline and use Rust implementation
• Alternative C++11 self-contained implementation for use with CGO

Plans:

• Complete gas metering procedure (1 week)
• Generate more initial vectors for fuzzy-testing (1 week, along with gas metering)
• 16+ CPU-months of fuzzy testing using libfuzzer and honggfuzz

[tintinweb]

Agenda Item Request: Discussing the EIP process template and process modification to manifest security in the EIP process by adding mandatory "Security Considerations" to EIP-1 (and EIP-x template). This has been presented at the coredevs meeting in berlin this spring. Discussion, presentation etc. are linked in the pull-request at ethereum/EIPs#1963. This is only a minor modification to add the section to the template and require proposals to provide security considerations (initially intentionally lax) analogue to the same RFC process.

[lrettig]

So meetings are no longer every other Friday?

They are. It's -8 hrs per call, modulo 24, I think :)

[timbeiko]

@Souptacular the actions items linked are the wrong one (call #63 and not #64)

[fubuloubu]

It's -8 hrs per call, modulo 24

Modulo 24 which timezone though? This meeting is only on Friday during the day for those in Asia and the South Pacific

[timbeiko]

@fubuloubu the goal was to never have it be on a Saturday for anyone, so it rotates from 14:00 UTC Friday, 6:00UTC Friday and 22:00UTC Thursday, and then back to 14:00 UTC Friday.

[GuthL]

EIP2028 would like to present our results on the call. Could we be added to the agenda?

[shemnon]

If we are going to discuss ProgPOW add the need for a hash multiplier for ProgPOW total difficulty to the agenda: https://ethereum-magicians.org/t/eip-progpow-a-programmatic-proof-of-work/272/13?u=shemnon

But in my opinion this is less important than discussing reference tests and the other already discussed EIPs, so place it on the agenda appropriately.

[timbeiko]

Following last AllCoreDevs, and inspired by an idea that @MadeofTin gave me, I pinged all the attendees from the previous call and asked them what the Top 3 things they'd like to see discussed on the call were.

8 attendees answered, and here are their compiled answers. Hopefully this can influence the agenda so that most of the time is spent discussing these issues.

1. "How we work towards Istanbul": what EIPs are included, excluded and other roadmap considerations. These EIPs were mentioned explicitly:
   1. EIP-615
   2. EIP-1344 vs. EIP-1965
      • Can we make a decision on EIP-1344 independently of EIP-1965?
   3. EIP-1283
      • There was an AMA with no further questions about the EIP. Should it move to Accepted?
   4. EIP-1962
   5. State Rent EIPs
   6. Other EIPs
      • ProgPow?
      • EIP-2028?
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. See "Comment by Alexey" below for details.
3. Conformance Testing
4. Gas costs improvements that help developers today

Comment by Alexey: I would like to introduce this idea that, regardless of whether EIPs are accepted or not, part of their implementation that "loosens" up the code, should be done anyway. It means that instead of EIP implementations bringing all the complexity with them, some of the complexity is eliminated upfront. This is a new concept, but I think it is quite important to promote.

[fubuloubu]

Re: EIP-1344 vs. EIP-1965, as I said before I won't be able to make the meeting until almost 1.5 hours into the call. Calls usually go this long, so if I am needed to make a decision on EIP-1344 I will try to attend. If not, if someone could inform me via Gitter when that decision is made, it would help me out immensely so I am not rushing to join the call to find out everyone had already left. Thanks!

[valuead]

is there a testnet?
is the network needs validators?

[sorpaas]

Given EIP-1702: Which of the Istanbul EIPs live only in version 1 code? Which live in version 0 and version 1 code?

Regarding this, in the call we'll basically want to discuss two options:

1. Treat old versions as "immutable" -- define a new version each time we do a hard fork. This will be really good to ensure backward compatibility. And because older versions are not changed, clients may be able to make more assumption of the versions to simplify the design. The drawback is that we'll get 2 new versions per year.
2. Treat versions the same as how we do semantic versioning. Deploy a new version when a feature qualify as a "major release", and only change existing versions when a feature is "minor release" or "patch release". I'm okay with this, but I have worries about all the gas reduction EIPs for Istanbul -- I cannot convince myself that they won't have backward compatibility issues.

If we decide on (2), then we may not have a new version this time, because most Istanbul EIPs (except EIP-615 and state rents) are minor changes. However, I do want to propose that we ensure account versioning is implemented in all the clients and include it in Istanbul testing, because it allows people to write EIPs with the assumptions that we have account versioning, which in many situations will greatly simplify things (for example, state rent EIPs' new account RLP fields).