Ethereum Core Devs Meeting 50 Agenda

[lrettig]

Ethereum Core Devs Meeting 50 Agenda

Meeting Date/Time: Friday 23 November 2018 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Livepeer Stream Link

Constantinople Progress

Agenda

1. Document being mentioned on Coindesk.
2. Testing
3. Client Updates
4. Research Updates
5. Constantinople/Ropsten HF, hardfork timing
6. ProgPoW Update

[5chdn]

Constantinople

• Just putting down an updated block number for discussion:
  • 7090939 (January 16, 2019, 12pm UTC @ 14 sec block time)
  • 7068475 (January 16, 2019, 12pm UTC @ 15 sec block time)
• According to the Constantinople Tracker, all clients are ready now 🎉

Stureby PoW-Testnet

• Scope: Redo the Constantinople hard-fork transition
• Genesis/Chainspec: https://gist.github.com/5chdn/baf0eb40cbaff5a90befc52815d6950b
• Dashboard http://boot.stureby.ethdevops.io/
• TODO: pool(s), fork monitor

Görli PoA-Testnet

• Now supported by four clients (Geth, Parity*, Pantheon, Nethermind) https://stats.goerli.net/
• We could discuss a potential deprecation and replacement of Ropsten after Constantinople next year

[lrettig]

Just putting down an updated block number for discussion: ~ 7078690 (January 16, 2019, 12pm UTC)

Since this has come up a few times recently, here's the conversation we had in AllCoreDevs a few weeks ago about forking on timestamp instead of block number. My understanding of the reasons against doing so:

• Block number is simpler and harder for miners to game. "eth hashrate base is big enough you can't accelerate the fork by anything statistically significant."
• We could have a situation where an uncle block has a newer timestamp and therefore different fork rules than the canonical head
• "All current tools for configuration uses block numbers (test generators, hive configuration, evmlab randomtest generator). All tests would need regeneration, and fork configuration params and logic in clients would need rewriting" (@holiman)

What have I missed?

Is there any value in continuing this debate or are we satisfied that block number is the only option?

[kylerchin]

The biggest thing I'm watching is the fork date and block numbers. If we can get that established, and maybe a bit on sharding progress, then my needs are met. See everyone on Friday morning! 😋

On Wed, Nov 14, 2018, 5:24 AM Lane Rettig ***@***.***> wrote: Just putting down an updated block number for discussion: ~ 7078690 (January 16, 2019, 12pm UTC) Since this has come up a few times recently, here's the conversation we had in AllCoreDevs <https://gitter.im/ethereum/AllCoreDevs?at=5bca0f35c08b8b30673d9864> a few weeks ago about forking on timestamp instead of block number. My understanding of the reasons against doing so: - Block number is simpler and harder for miners to game. "eth hashrate base is big enough you can't accelerate the fork by anything statistically significant." - We could have a situation where an uncle block has a newer timestamp and therefore different fork rules than the canonical head - "All current tools for configuration uses block numbers (test generators, hive configuration, evmlab randomtest generator). All tests would need regeneration, and fork configuration params and logic in clients would need rewriting" ***@***.*** <https://github.com/holiman>) What have I missed? Is there any value in continuing this debate or are we satisfied that block number is the only option? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#62 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHMJ5huvdLusZ5TeBk9kxsj3mbAeTVVrks5uvBl8gaJpZM4YXWaY> .

-- From Kyler Chin

[salanki]

ProgPoW update please

[gcolvin]

https://docs.google.com/document/d/1IB3oKuH5mryyhmVHE9r3aR6bK2pJCoJgAtiCYTEieh4/edit?usp=sharing

[holiman]

I won't make the call today. Some updates:

• Two evm fuzzers are (still) running. No new issues found in the last couple of weeks.
• One testcase found by fuzzing has now been added to the tests-repo. It affected geth and ethereumJ (at least), and concerned EXTCODEHASH in a fairly complex edgcase scenario.
• Hive is currently down for maintenance, I have some hopes that we'll get it working again during the day. Hive has been moved into the ethereum org (https://github.com/ethereum/hive/), and a new geth-team member @FrankSzendzielarz have been working on improving it further, with a test-suite for p2p networking as well as support for more advanced multi-cllient test suites.

[5chdn]

https://docs.google.com/document/d/1IB3oKuH5mryyhmVHE9r3aR6bK2pJCoJgAtiCYTEieh4/edit?usp=sharing

where was this and how to get into these meetings?

June 1, 2019: target for hardfork

what is this about?

[lrettig]

Closing in favor of #64