Skip to content

Conversation

@yperbasis
Copy link
Member

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.

@yperbasis yperbasis merged commit cfb2e0a into main Oct 31, 2025
17 checks passed
@yperbasis yperbasis deleted the yperbasis/fusaka_on_mainnet branch October 31, 2025 14:14
yperbasis added a commit that referenced this pull request Oct 31, 2025
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.
yperbasis added a commit that referenced this pull request Oct 31, 2025
mh0lt pushed a commit that referenced this pull request Nov 4, 2025
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
Copy link
Member

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

@taratorio
Copy link
Member

(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
Copy link
Member

@somnergy #18091

@somnergy
Copy link
Member

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.

taratorio added a commit that referenced this pull request Dec 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants