Ethereum Core Devs Meeting 64 Agenda

[lrettig]

Ethereum Core Devs Meeting 64 Agenda

• Meeting Date/Time: Friday 5 July 2019 at 06: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. Review previous decisions made and action items
2. EIPs
   a) EIP 2124: Fork identifier for chain compatibility checks
   b) EIP 1962 Update
   c) EIP 2025
   d) EIP 1679: Hardfork Meta: Istanbul
   See also the dependency map by James Hancock and the EIP readiness spreadsheet.
3. Working Group Updates
4. Testing Updates
5. 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
6. EWASM & Research Updates (only if they are posted in the comments below)

[timbeiko]

@lrettig isn't the time supposed to be 22:00UTC on July 4th, as per the last call?

[lrettig]

@timbeiko the notes say 6:00 UTC! Which is it? CC @Souptacular

Are we going clockwise or counter-clockwise? 🤓

[timbeiko]

Oh, I thought we had agreed to go -16h first, then -8h, but I may be wrong. I can double-check the livestream.

[shemnon]

I think we went -8 first so that Europe would have a morning call and US would get the middle of the night treatment before europe.

[timbeiko]

That's true! @lrettig you were right :-)

[lrettig]

Updated - we'll get a 2am viewing party going in NYC 🍾

[shemnon]

Now that we have two accepted EIPs, we need to have a discussion on reference tests. When they need to be available, staffing, is there enough time, do the current reference tests allow for the testing we need? For example, the json will need a new "version" field, but that should be trivial, right?

[fubuloubu]

Won't be able to make this one, but the following one it would be good to discuss chain ID stuff.

[shamatar]

I have some updates on 1962 and can finally present a work from the first hands

[axic]

@AlexeyAkhunov realistically, do you think it is worth pursuing any of the state rent proposals for Istanbul (the October release deadline)?

[karalabe]

I'd like to bring up a ~networking EIP we've been working on with @fjl. It doesn't touch consensus, just makes network peering more robust by defining a forkid that peers can advertise and cross validate, allowing them to more easily decide if a remote peer will be useful or not (same chain, same forks).

The EIP only defines this fork identifier, it does not care how it is exchanged between peers. The reason is to keep the schema definition separate from networking details (we'd include it in the eth handshake and enr too, but those require their own EIPs, so better keep this one short).

We would definitely like to include a preliminary version of this in Geth v1.9.0 to see how helpful it is; and I don't think many people here care much about networking experiments, especially ENR and discovery v5 extensions, but we though we should nonetheless mention it if anyone wishes to discuss it before we roll it out in its current form.

• Current EIP text (not yet merged, not even in draft): https://github.com/ethereum/EIPs/blob/9f8e59d0f39418df350811be8cb02fa7be14d3a3/EIPS/eip-2124.md
• EIP PR: EIP 2124: Fork identifier for chain compatibility checks EIPs#2124

[shamatar]

Spec for EIP1962 is largely complete and describes ABI, basic validity checks and gas estimation approach. It's not yet fully implemented in the code, but now code will follow the spec instead of the opposite.

https://github.com/matter-labs/eip1962/blob/master/SPECIFICATION.md

[MadeofTin]

I'd like to give an update to https://eips.ethereum.org/EIPS/eip-2025. And some context and motivation on my proposal

[gcolvin]

Pulling off of Gitter:
@MadeofTin EIP-615 ’s long history has left it in an ambiguous state via your chart.

• There is an aleth reference implementation from 2016 that has not been maintained.
• I have a fork of aleth with EIP-615 re-enabled that does build and pass existing tests, but it is bit behind the spec and not ready to merge into master or deploy on the testate. The aleph team can judge how much time they would need to finish the job.
• It did not go through Last Call when it should have because there was a time when Core EIPs did not go through that process.
• It has been under discussion in the community for a long time, saw a lot of review as an EIP issue, was formally specification by @seed, and has been under review on the Magicians for three months.
• If we still do want a Last Call we need to schedule it. I am unavailable the week of July 15.

Regardless, I'm wanting to get to some consensus fairly soon as to whether we are moving this forward, whether in this fork or a later one.