Berlin timing

[q9f]

Update, these are the final numbers:

Based on the discussion in #245, another proposal may be to have the first testnet fork sooner. All clients are already syncing on YOLOv3, so we could do something like:
Scenario D HF Date
Ropsten 10 Mar 2021
Goerli 17 Mar 2021
Rinkeby 24 Mar 2021
Mainnet 14 Apr 2021
This gives a longer delay between Berlin and London (say London happened mid-July, that's a full 3 months), and it also gives 3 weeks from now for the first testnet to fork.

Potential block numbers:

* Ropsten `9_812_189` (10 Mar 2021)

* Goerli `4_460_644` (17 Mar 2021)

* Rinkeby `8_290_928` (24 Mar 2021)

* Ethereum `12_244_000` (14 Apr 2021)

Math

Original post/conversation below this line.

---

I think we should discuss Berlin timing again because nothing materialized since the last ACD and this should have higher priority than the London timing. Copy-pasta from discord:

Scenario A: Berlin Mainnet March Rollout

• Ropsten: Feb/24, TimeRemaining 1045200s, CurrentBlock 9_648_023, BlockTime 13.8s, TargetForkBlock 9_723_762 (est.)
• Goerli: Feb/24, TimeRemaining 1045200s, CurrentBlock 4_269_595, BlockTime 15.0s, TargetForkBlock 4_339_275 (est.)
• Rinkeby: Feb/24, TimeRemaining 1045200s, CurrentBlock 8_059_600, BlockTime 15.0s, TargetForkBlock 8_129_280 (est.)
• Kovan: Feb/24, TimeRemaining 1045200s, CurrentBlock 23_434_222, BlockTime 5.3s, TargetForkBlock 23_631_429 (est.)
• (5 weeks buffer)
• Mainnet: Mar/31, TimeRemaining 4072740s, CurrentBlock 11_841_026, BlockTime 13.1s, TargetForkBlock 12_151_922 (est.)

Scenario B: Berlin Staged Testnet Rollout

• Ropsten: Feb/24, TimeRemaining 1045200s, CurrentBlock 9_648_023, BlockTime 13.8s, TargetForkBlock 9_723_762 (est.)
• Goerli: Mar/03, TimeRemaining 1649940s, CurrentBlock 4_269_595, BlockTime 15.0s, TargetForkBlock 4_379_591 (est.)
• Rinkeby: Mar/10, TimeRemaining 2254680s, CurrentBlock 8_059_600, BlockTime 15.0s, TargetForkBlock 8_209_912 (est.)
• Kovan: Mar/17, TimeRemaining 2859480s, CurrentBlock 23_434_222, BlockTime 5.3s, TargetForkBlock 23_973_746 (est.)
• (6 weeks buffer)
• Mainnet: Apr/21, TimeRemaining 5887020s, CurrentBlock 11_841_026, BlockTime 13.1s, TargetForkBlock 12_290_416 (est.)

This is already next week though... can run the numbers again but at some point we would have to make a decision instead of pushing this from meeting to meeting.

[holgerd77]

Since Yolo v3 is still in very active movement (just restarted three days ago triggered by @holiman) I think it is safe to give this a minimal extension estimate (so: not a timeline but just an estimate how this is minimally delayed based on the facts right now):

• 1 week until clients get on board on the restarted testnet Wednesday Feb/24
• 2 weeks running Yolo v3 and see if things are stable Wednesday Mar/10
• Buffer of 2 weeks assuming there is 1 issue found between clients Wednesday Mar/24
• Settling the dust, one week client preparation time to include a new HF block for Ropsten Wednesday Mar/31

=> Minium Ropsten start date: Wednesday Mar/31

Just as some calculation for orientation (I find this personally still a bit (too) ambitious, but might be doable if we focus).

[q9f]

Ok, like this?

Scenario C	HF Date	Time Remain	Current Block	Block Time	Target HF Block
Ropsten	31 Mar 2021	3718560	9673839	13.8	9943300
Goerli	7 Apr 2021	4323300	4292979	15	4581199
Rinkeby	14 Apr 2021	4928100	8082975	15	8411515
Kovan	21 Apr 2021	5532900	23499420	5.3	24543363
Mainnet	12 May 2021	7347240	11867428	13.1	12428286

[holgerd77]

Yes, when seeing this and going a step back I think this might even be a good balance on timing needs so that we are not getting too close to #245 and a somewhat realistic timelime for implementation if everyone focuses.

[timbeiko]

Added to the agenda, @q9f !

[timbeiko]

@holgerd77 re:

2 weeks running Yolo v3 and see if things are stable Wednesday Mar/10

Why do we want that before forking the testnets? IIRC, we've used the yolo networks in the past to just test that clients can sync to each other, and we've fuzzed them a bit with transactions. I don't think this needs to take 2 weeks.

Re:

Buffer of 2 weeks assuming there is 1 issue found between clients Wednesday Mar/24
Settling the dust, one week client preparation time to include a new HF block for Ropsten Wednesday Mar/31

I think maybe we can do something like set the fork block once all clients sync to each other, for 3 weeks in the future. WDYT? IMO 1 week to put out a release and distribute it after a bug has been found is short, so I think the best we can do is plan for the "happy case" where clients are all in sync, and then have clients put out a release with a block 2-3 weeks in the future.

[holgerd77]

plan for the "happy case" where clients are all in sync

I am always a fan of planning for the "non-happy case". 😄 In the JavaScript team we perceive EIP-2718 and EIP-2930 as rather complex from an implementation PoV, currently doing the implementation (ethereumjs/ethereumjs-monorepo#1048) and I would think that having 1-2 more issues with these EIPs (not for us isolated but between teams) - maybe also along some edge cases in the specs - is rather likely than not, also judging from the current discussions on ACD.

A buffer has also the advantage that it reduces the cost of additional delay planning - especially for such short periods like 2-3 weeks or so. We already had this often in the past and there is a substantial coordination effort here in case (additional calls, new client releases, (public) communication), also to note a not-so-optimal outer perception if there are too many delays.

But at the end I am also fine with the happy-case planning and the 3-weeks-in-the-future date setting for the first testnet fork. 🙂

[timbeiko]

FWIW, my preferred approach would be something like Scenario C, without Kovan happening in parallel, given OE will deal with it post-Berlin (link). So it would look something like:

Scenario C	HF Date	Time Remain	Current Block	Block Time	Target HF Block
Ropsten	31 Mar 2021	3718560	9673839	13.8	9943300
Goerli	7 Apr 2021	4323300	4292979	15	4581199
Rinkeby	14 Apr 2021	4928100	8082975	15	8411515
Mainnet	5 May 2021	7347240	11867428	13.1	TBD

This gets us on mainnet 1 week earlier, and will give us a ~2 month window between Berlin and London hitting mainnet.

[timbeiko]

Based on the discussion in #245, another proposal may be to have the first testnet fork sooner. All clients are already syncing on YOLOv3, so we could do something like:

Scenario D	HF Date
Ropsten	10 Mar 2021
Goerli	17 Mar 2021
Rinkeby	24 Mar 2021
Mainnet	14 Apr 2021

This gives a longer delay between Berlin and London (say London happened mid-July, that's a full 3 months), and it also gives 3 weeks from now for the first testnet to fork.

[q9f]

Based on the discussion in #245, another proposal may be to have the first testnet fork sooner. All clients are already syncing on YOLOv3, so we could do something like:
Scenario D HF Date
Ropsten 10 Mar 2021
Goerli 17 Mar 2021
Rinkeby 24 Mar 2021
Mainnet 14 Apr 2021

This gives a longer delay between Berlin and London (say London happened mid-July, that's a full 3 months), and it also gives 3 weeks from now for the first testnet to fork.

Potential block numbers:

• Ropsten 9_812_189 (10 Mar 2021)
• Goerli 4_460_644 (17 Mar 2021)
• Rinkeby 8_290_928 (24 Mar 2021)
• Ethereum 12_244_000 (14 Apr 2021)

Math

 9694006 + 27221 * 60 / 13.8 =  9812358.17391304347826086957
 4311045 + 37300 * 60 / 15.0 =  4460245
 8101037 + 47378 * 60 / 15.0 =  8290549
11887875 + 77613 * 60 / 13.1 = 12243354.38931297709923664122

[q9f]

Diff bomb: https://eips.ethereum.org/EIPS/eip-3238

[holgerd77]

TBH I am not a fan of closing this already, can't we keep this open as a reference PR until all dates have been executed upon (or what would be an alternative go-to place to look up these numbers)?

There will also likely be (some) continued need for discussions around block numbers, additional comments on timeframe concretizations, and the like. All this would be suited to happen here.