Schedule Fusaka on Ethereum mainnet

[yperbasis]

on December 3, 2025, 09:49:11pm UTC
BPO1 December 9, 2025, 02:21:11pm UTC
BPO2 January 7, 2026, 01:01:11am UTC

See https://notes.ethereum.org/@bbusa/fusaka-bpo-timeline, ethereum/consensus-specs#4689 and eth-clients/mainnet#11.

DefaultOsakaBlobConfig was removed because it's the same as DefaultPragueBlobConfig, so there's no need to set it explicitly.

[somnergy]

• The forkid_test seems to be missing the right values for Osaka, BPO1, BPO2 fork_id
• Is the getConfig API finished, and does it agree with other clients?
  @yperbasis
  cc @antonis19 @taratorio @mh0lt @canepat

(Ignore if already addressed, I only just saw this)

[taratorio]

• The forkid_test seems to be missing the right values for Osaka, BPO1, BPO2 fork_id
• Is the getConfig API finished, and does it agree with other clients?
  @yperbasis
  cc @antonis19 @taratorio @mh0lt @canepat

(Ignore if already addressed, I only just saw this)

What do you mean by missing? The test checks that the last fork_id is 0x07c9462e (as per the doc) - that is BPO2 which comes after BPO1 which comes after Osaka. Calculating the last fork id depends on the values for the previous fork ids so can't arrive at the same values if the previous ones are not correct. So correctness is proven. But would not hurt to add explicit tests for bpo1 and Osaka fork ids before bpo2.

getConfig API work is finished yes.

[taratorio]

@somnergy #18091

[somnergy]

What do you mean by missing? The test checks that the last fork_id is 0x07c9462e (as per the doc) - that is BPO2 which comes after BPO1 which comes after Osaka. Calculating the last fork id depends on the values for the previous fork ids

Yeah, it's a valid argument. It's also always better to be very explicit, even unnecessarily explicit, when it comes to config.
Thanks for the added intermediate checks.