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.

[axic]

The question around ewasm came up ad-hoc, but here is the link to the "precompiles in ewasm" discussion: ewasm/design#104

[cheeselord1]

I'm strongly in favor of including EIP 1087 in Constantinople. Several contracts with high usage on ETH (e.g. Augur, Bancor, etc) have inflated gas costs today because they repeatedly edit the same storage values. Implementing EIP 1087 will make these types of contract calls more feasible on the blockchain

[jpritikin]

What happened to https://eips.ethereum.org/EIPS/eip-999 Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4? At least can we get EIP 999 as an option so users can decide whether to activate it or not in the next hard fork?

[shahankhatch]

I'm very excited to announce here that we at PegaSys are planning on releasing our open source mainnet-compatible Ethereum client, Pantheon, at DevCon 4!

Our Java client will meet the requirements of a well-behaved peer: able to synchronize the entire chain through all of the hard forks, mine blocks, and propagate pending transactions. The client will also be developer-friendly, supporting common dApp development (e.g. Truffle and web3) and deployment use cases. This means that the client will support the JSON-RPC APIs used by popular clients (e.g. eth, net, debug, admin, etc.), but not technologies such as Whisper or Swarm. We are focusing on functionality, robustness, and modularity.

We will be providing more information in the coming weeks, and we will also continue to increase our community involvement.

[bobsummerwill]

Brilliant news, @shahankhatch! Many congratulations. This has been quite the labor of love for you and PegaSys. I am sure that Pantheon will be carrying a major chunk of the ETH mainnet soon enough. I hope to be there in Prague to witness "the birth" :-)

https://twitter.com/BobSummerwill/status/1017900957034614784

[lrettig]

Closing in favor of #51