New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ethereum Core Devs Meeting 42 Agenda #50

Closed
Souptacular opened this Issue Jun 29, 2018 · 20 comments

Comments

Projects
None yet
@Souptacular
Member

Souptacular commented Jun 29, 2018

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).](#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

This comment has been minimized.

Show comment
Hide comment
@Daft-Wullie

Daft-Wullie Jun 29, 2018

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

Daft-Wullie commented Jun 29, 2018

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

@lrettig

This comment has been minimized.

Show comment
Hide comment
@lrettig

lrettig Jun 29, 2018

Collaborator

Thanks :) updated

Collaborator

lrettig commented Jun 29, 2018

Thanks :) updated

@benjaminion

This comment has been minimized.

Show comment
Hide comment
@benjaminion

benjaminion Jul 5, 2018

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]

benjaminion commented Jul 5, 2018

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

This comment has been minimized.

Show comment
Hide comment
@5chdn

5chdn Jul 12, 2018

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.

5chdn commented Jul 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@lrettig

lrettig Jul 12, 2018

Collaborator

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?)

Collaborator

lrettig commented Jul 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Jul 12, 2018

Member

@5chdn @lrettig Adding to agenda.

Member

Souptacular commented Jul 12, 2018

@5chdn @lrettig Adding to agenda.

@Souptacular

This comment has been minimized.

Show comment
Hide comment
@Souptacular

Souptacular Jul 12, 2018

Member

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.

Member

Souptacular commented Jul 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@cheeselord1

cheeselord1 Jul 12, 2018

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

cheeselord1 commented Jul 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@AlexeyAkhunov

AlexeyAkhunov Jul 13, 2018

Contributor

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

Contributor

AlexeyAkhunov commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@AlexeyAkhunov

AlexeyAkhunov Jul 13, 2018

Contributor

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

Contributor

AlexeyAkhunov commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@holgerd77

holgerd77 Jul 13, 2018

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.

holgerd77 commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@winsvega

winsvega Jul 13, 2018

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

winsvega commented Jul 13, 2018

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

@5chdn

This comment has been minimized.

Show comment
Hide comment
@5chdn

5chdn Jul 13, 2018

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

5chdn commented Jul 13, 2018

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

@AlexeyAkhunov

This comment has been minimized.

Show comment
Hide comment
@AlexeyAkhunov

AlexeyAkhunov Jul 13, 2018

Contributor

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.

Contributor

AlexeyAkhunov commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@axic

axic Jul 13, 2018

Member

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

Member

axic commented Jul 13, 2018

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

@cheeselord1

This comment has been minimized.

Show comment
Hide comment
@cheeselord1

cheeselord1 Jul 13, 2018

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

cheeselord1 commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@jpritikin

jpritikin Jul 13, 2018

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?

jpritikin commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@shahankhatch

shahankhatch Jul 13, 2018

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.

shahankhatch commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@bobsummerwill

bobsummerwill Jul 13, 2018

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

bobsummerwill commented Jul 13, 2018

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

This comment has been minimized.

Show comment
Hide comment
@lrettig

lrettig Jul 15, 2018

Collaborator

Closing in favor of #51

Collaborator

lrettig commented Jul 15, 2018

Closing in favor of #51

@lrettig lrettig closed this Jul 15, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment