Ethereum Core Devs Meeting 42 Agenda

[Souptacular]

Ethereum Core Devs Meeting 42 Agenda

Meeting Date/Time: Friday 07/13/18 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Livepeer Stream Link

Agenda

1. Testing
2. Client Updates
3. Research Updates
4. Post EIP 1011 (Hybrid Casper) Spec Plans
   1. Now that EIP 1011 is deprecated, is there still the interest among client developers to have a joint testnet, a Ropsten-successor if you want to put it like that?
   2. If yes, and I assume most of us are interested in some effort like this, how could it look like if not like the hybrid Casper proposal?
   3. What smaller steps can/should we take in the meantime while waiting for casper+sharding? (can we just call it "shasper" now?)
5. Possibly changing network Id in Constantinopole (or, alternatively, the format of the handshake message to make it backwards-incompatible).](Ethereum Core Devs Meeting 42 Agenda #50 (comment))
6. Constantinople hard fork timing and what to include (continuing conversation from last call).
   a. EIP 145: Bitwise shifting instructions in EVM: pretty well-formed, but not 100% implemented or tested.
   b. EIP 210: Blockhash refactoring.
   d. EIP 1052: EXTCODEHASH Opcode.
   e. EIP 1087: Net gas metering for SSTORE operations.
   f. EIP 1014: Skinny CREATE2.
   g. Delay ice age?

Proposed Constantinople Timeline
Finalize EIPs that are being implemented: July 13th
Client implementation: July 16th - August 13th
Testing: August 13th - September 10th
Testnet: September 10th - October 1st
Launch: October 8th

This is not final and there will likely be changes. I am soliciting feedback from client devs and testers who will be working on this.

Please provide comments to add or correct agenda topics.

[Daft-Wullie]

typo in the date, should probably be 07/13/18 unless the EF is also secretly working on a time machine.

[lrettig]

Thanks :) updated

[benjaminion]

Better 2018-07-13 if we care about being ISO standard and non-bizarre-US-date-format friendly.

Just sayin' :-).

[Or in full, 2018-07-13T14:00Z, but that's a bit fussy]

[5chdn]

I have a question worth discussing at the next meeting. EIP 1011 (Hybrid Casper) seems not to happen for reasons that were mentioned in Ethereum research circles. I'm not strictly following it but what I want to figure out is, if we do not work on a hybrid Casper as discussed in EIP 1011 now, there won't be any progress on a joint testnet anymore. I don't see sharding and Casper-as-a-Shard to be ready anytime soon. So, actual question:

1. Is there still the interest among client developers to have a joint testnet, a Ropsten-successor if you want to put it like that?
2. If yes, and I assume most of us are interested in some effort like this, how could it look like if not like the hybrid Casper proposal?

I want to understand if there is anything we could start working on towards a joint testnet that could be useful for any future main net usage.

[lrettig]

Tag @AlexeyAkhunov who brought up something similar at ECDC - what smaller steps can/should we take in the meantime while waiting for casper+sharding? (can we just call it "shasper" now?)

[Souptacular]

@5chdn @lrettig Adding to agenda.

[Souptacular]

In order to get the conversation started I created this proposed timeline:

Proposed Constantinople Timeline
Finalize EIPs that are being implemented: July 13th
Client implementation: July 16th - August 13th
Testing: August 13th - September 10th
Testnet: September 10th - October 1st
Launch: October 8th

This is not final and there will likely be changes. I am soliciting feedback from client devs and testers who will be working on this.

[cheeselord1]

Are we including an ice age delay (and an accompanying mining reward reduction) in the Constantinople hard fork? My understanding is that blocktimes will start being impacted in early 2019

[AlexeyAkhunov]

I suggest changing network Id in Constantinopole (or, alternatively, the format of the handshake message to make it backwards-incompatible). This would allow removing some of the DAO hard fork kludge code from the clients by more cleanly separating from Ethereum Classic network. This change does not strictly require a hard fork, but it does require coordination from all the client impementations. I also see if as a stepping stone for the migration to the new peer discovery protocol and other improvements in p2p

[AlexeyAkhunov]

Regarding Constantinople timeline: I suggest that we demand that each client implements retesteth RPC methods. This would enable us creating a suite of conformance tests for every EIP in the list, and the time line would include steps like:

Finalize EIPs that are being implemented: July 13th

All clients have retesteth interface: Aug 13th

Each EIP has at least 1 reference implementation: Sep 13th

Conformance tests are ready for every EIP: Oct 13th

Specification is finalised for every EIP: Oct 27th

Client implementations and testing: Nov 27th

Testnet: Dec 13th

Launch: Jan 27th

[holgerd77]

Some pre-notes on testing / timeline

I would agree with @AlexeyAkhunov that there should be a stronger emphasis on the tests in the timeline. Are these more or less ready for Constantinople (@winsvega)? I would say that the client dev 4-weeks period should only start once tests are 90%+ finalized.

I have doubts that this should already rely on the retesteth tool, since this still has a Prototype and WIP note. Think this is too early and clients already have their custom test setup in place. Seems to me that this would give unnecessary additional time pressure for implementation. Does this add any functional benefit? Or is this just a unified interface?

State of EthereumJS VM

Can't join todays call, some estimate of the EthereumJS VM state:

We are more-or-less fully passing the current over-time updated Byzantium tests and have done some initial work on Constantinople. My estimate would be that we could have an implementation ready within 2-3 month - also depending on some external circumstances.

Role of EthereumJS VM:

The EthereumJS VM is not currently building the basis of a consensus-critical client, but is relevant for developers to test for Constantinople compatibility in tools like Remix or Truffle/Ganache.

[winsvega]

Please list the EIPs which are confirmed for the Constantinople hf.
So far I saw that only bitwise shift is approved. What else?

[5chdn]

@winsvega I think that's the optimal outcome of this call.

[AlexeyAkhunov]

I also suggest that instead of trying to "approve" the list of EIPs for Constantinople hard fork, we instead work on the individual candidate EIPs and release (hard fork) them when they are ready. Current process of bundling changes in the big releases is based on the assumption that doing hard forks is hard, but why? Because we don't cleanly separate the old and the new network - this could be fixed by the practice of changing network Id in each fork. Because we start with underspecified EIPs and figure out the details in a rush just before the fork - this could be fixed by having EIP maturing process include mandatory rough reference implementation (enough to produce conformance tests), conformance tests, and only then full spec. If some more work is done to figure out underspecified and unimplementable things before the final spec, implementation of EIPs in all clients could be a much more straightforward process. If an EIP has a lot of good preparatory work behind it, it should be given some priority in consideration for the hard fork.