Skip to content
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 53 Agenda #70

Closed
5chdn opened this issue Jan 5, 2019 · 18 comments
Closed

Ethereum Core Devs Meeting 53 Agenda #70

5chdn opened this issue Jan 5, 2019 · 18 comments

Comments

@5chdn
Copy link
Contributor

5chdn commented Jan 5, 2019

Ethereum Core Devs Meeting 53 Agenda

Agenda

  1. Constantinople postponement
    • difficulty bomb update
    • how to mitigate the SSTORE net gas metering security issue
    • how and when to redo the hard fork
    • post-mortem: how did this happen? how do we prevent it from happening again?
  2. Roadmap
    a) Constantinople - what next?
    b) ProgPoW Hardfork Decision
    c) Istanbul Hardfork Roadmap
    d) Outlook: PoS finality gadget on PoW chain (Serenity)
  3. Testing Updates (time allowing)
  4. Client Updates (time allowing)
    a) Geth
    b) Parity Ethereum
    c) Aleth/eth
    d) Trinity/PyEVM
    e) EthereumJS
    f) EthereumJ/Harmony
    g) Pantheon
    h) Turbo Geth
    i) Nimbus
    j) Mana/Exthereum
  5. Research Updates (time allowing)
  6. Working Group Updates (time allowing)
    a) State Rent
    b) EWasm
    c) Pruning/Sync
    d) Simulation
@kevinsimper
Copy link

Hi @5chdn, the youtube link goes to the 52 livestream :) Is that correct?

@Souptacular
Copy link
Contributor

@kevinsimper I have updated the link.

@karalabe
Copy link
Member

karalabe commented Jan 16, 2019

Food for thought about the postponing:

Independent of what the actual fix to SSTORE will be, we'll have an issue that the original rule set is already active on Ropsten and Rinkeby under the name Constantinople (not sure about Kovan and the other PoA networks). If we change the meaning of the Constantinople fork to some new feature set, it will be a mess wrt the testnets. Clients (at least Geth for sure) would need to introduce further splitting logic to differentiate between testnet-constantinople and mainnet-constantinople (which still messes up privatenet-constatinople, needing some user configurability).

My alternative suggestion - that would keep the fork semantics clean - is to keep the Constantinople feature set as it is currently and introduce whatever fix we dream up in an Istanbul fork. Ropsten and Rinkeby can fork a second time (they must either way, otherwise the EVM on the testnet will behave differently than on mainnet), and mainnet can do a double fork Constantinople + Istanbul at the same block.

This would allow mainnet and the testnets to keep the same semantic meaning of the named forks. It's also the classical fork procedure we've always done, so every client will support it without any extra code modifications or behavioral splitting needed. Furthermore it would also allow us to keep all the existing Constantinople tests and just extend the suite with a new fork, instead of remaking everything.

@ghost
Copy link

ghost commented Jan 16, 2019

@karalabe Referring your thought there will be no Constantinople upgrade on mainnet until Istanbul is being finalized right?

@karalabe
Copy link
Member

@naikmyeong Not sure we're talking about the same Istanbul. My proposition is analogous to renaming Constantinople to Constantinople 1 and have the fix in Constantinople 2, where testnets only need to apply Constantinople 2 now, but mainnet would apply both 1 and 2 at the same block.

However, to avoid the naming confusion of Constantinople 1 and Constantinople 2 after clients already defined what Constantinople means, my recommendation is to keep Constantinople 1 as Constantinople and use a meaningful name for Constantinople 2, which can be either Istanbul or anything else really.

My suggestion has nothing to do with any previously discussed hard forks that were named Istanbul.

@5chdn
Copy link
Contributor Author

5chdn commented Jan 16, 2019

FYI ethereum/EIPs#1701

@ghost
Copy link

ghost commented Jan 16, 2019

I understand, I agree for having Constantinople 2 as a bug fix of Constantinople 1, and I suggest having a same time period that we've already had with Constantinople 1.

@5chdn
Copy link
Contributor Author

5chdn commented Jan 16, 2019

Independent of what the actual fix to SSTORE will be, we'll have an issue that the original rule set is already active on Ropsten and Rinkeby under the name Constantinople (not sure about Kovan and the other PoA networks). If we change the meaning of the Constantinople fork to some new feature set, it will be a mess wrt the testnets. Clients (at least Geth for sure) would need to introduce further splitting logic to differentiate between testnet-constantinople and mainnet-constantinople (which still messes up privatenet-constatinople, needing some user configurability).

For Parity this is not an issue. We can turn on and off EIPs separately. On Kovan we only use a subset of Constantinople anyways. Regarding Ropsten, we are talking about a potential deprecation anyways. Time for a new testnet?

However, we need to find a way to patch existing networks anyways in case other mainnets activates Constantinople already.

@ghost
Copy link

ghost commented Jan 16, 2019

For Parity this is not an issue. We can turn on and off EIPs separately. On Kovan we only use a subset of Constantinople anyways. Regarding Ropsten, we are talking about a potential deprecation anyways. Time for a new testnet?

Didn't you said that Goerli will replace Ropsten? 😂

@lrettig
Copy link
Contributor

lrettig commented Jan 16, 2019

For Parity this is not an issue. We can turn on and off EIPs separately

We need to consider UX here as well. I wouldn't want to require users to run parity with a complex commandline flag, or a config file, just to sync mainnet or one of the main testnets. I'm with @karalabe's proposal here, it sounds like the most straightforward.

@lrettig
Copy link
Contributor

lrettig commented Jan 16, 2019

Quick recap on the difficulty bomb: as discussed in meeting 49:

  • Block times will begin to increase in Jan
  • Expected to reach 30s block times in May
  • Could be as early as early April if hashpower declines ~20-25%
  • Will hit faster than last year

It looks like block times have just begun to tick up. Since the math was done it appears that hash power has come down by about 20%, so my best forecast at the moment is that we'd hit 30s block times in late April.

@tayvano
Copy link

tayvano commented Jan 16, 2019

Based on commentary around reddit / twitter / forums, the most pressing questions. These are basically expansions on the bullet points listed in # 5 of OP.

  1. What will be done for EIP 1283?

  2. Timeline for new fork?

    • I personally strongly recommend picking a date on this call, based on what is determined in point 1
    • Most armchair estimates range between 2-6 weeks
    • If devs could be fairly explicit in the things that affect this timeline, would help on comms side, especially if timeline is longer rather than shorter (e.g. tests need to be re-written, testnets need to be dealt with, etc.)
  3. How did this happen? Why wasn't it detected sooner?

  4. Testnet plan

    • There has been a surprising amount of commentary on this

@rfikki
Copy link

rfikki commented Jan 16, 2019

There should be a discussion surrounding the issue for how upgrading will be dealt with in the future. We would not want to establish a base line that allows future manipulation of the upgrade process by nefarious actors. One offending EIP, should not delay without "good cause" the upgrade timing of other non-offending EIP's that were scheduled during the same upgrade instance of the platform. Otherwise, one can manipulate how and when other included EIP's are deployed or not deployed. We should not set a bad precedent, otherwise we should expect bad actors to manipulate the upgrade process in the future.

@pegahcarter
Copy link

@rfikki do you think the reentry article was intentionally withheld until the day before the fork? In a way, the article was a test of how responsive the primary ETH developers are and it shows that all you need is one well-timed article to change the entire ETH development timeline.

@rfikki
Copy link

rfikki commented Jan 16, 2019

Nope, @cartercarlson I do not think the article was intentionally withheld. I am making a point that in the future anyone that wants to manipulate the process knows based on this instance that they may be able to do so from how this scenario was handled.

@peterbitfly
Copy link

FYI: Results of our survey regarding ProgPoW & a general PoW change. So far out of ~2400 votes (mostly miners), 82% are in favor of moving to a different PoW algorithm (45% are for ProgPoW, 34% are for another ASIC resistant algorithm, 3% are for another ASIC friendly algorithm) and only 18% are in favor of sticking with ethash.

https://twitter.com/etherchain_org/status/1084349056883802112

@chfast
Copy link
Member

chfast commented Jan 18, 2019

Aleth update:

  1. Aleth 1.5.0 released for Constantinople, then 1.5.1 released for ConstantiNOPEle.
  2. The Aleth 1.5 contains a separated bootnode: aleth-bootnode. More improvements in p2p discovery area are coming in next releases.

@Souptacular
Copy link
Contributor

Closing for #73

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

12 participants