Discussion Topic for Hardfork Meta - BPO1 upgrade.
This EIP-xxxx captures its activation time, blob parameter changes, canonical configuration and historical references.
Blob-Parameter-Only (BPO) upgrades are parameter-only network upgrades (similar in nature to Ice Age forks) and have started deploying independently following the Fusaka upgrade.
While EIP-7892 defines the mechanism for scaling Ethereum’s blob capacity, there is currently no EIP that documents what changed in each BPO instance, when it was activated, and which parameter values were applied. Today, this information is fragmented across client repositories, HackMDs, coordination notes, and release artifacts.
This Meta EIP aims to provide a lightweight, durable reference for:
Each BPO should be represented as a Meta EIP, to easily document the timing and parameters a BPO uses. We should avoid living registries that need to be maintained.
Creating a Meta EIP is fairly lightweight, and previous BPOs can be used as a template, with only the parameters changing. I’d suggest creating BPO3.
Whilst my preference is without a space, i.e. BPO1, which is what I use for Ethereal news (e.g. Ethereal news weekly #2 | Ethereal news following the example of Week in Ethereum News of using minimal additional characters), I would be led by ethPandaOps here.
Thank you for the thoughtful review and for sharing your suggestion. I really appreciate you taking the time to look through this.
I also checked with the ethPandaOps team, and they indicated they do not have a strong preference either way. Given that, aligning with the existing specification feels like the most consistent path forward.
Thus, I’d keep the proposal as-is. As defined in EIP-7892
BPO forks SHOULD be named using the convention bpo<index>, where <index> starts at 1.
Aligning with the naming standard specified in the “required” EIP helps ensure consistency and clarity across client implementations, documentation, and ecosystem tooling.
That said, thank you again; your feedback is very much appreciated.
Configuration-wise the only changes are the activation timestamp and the relevant parameters (max and target blobs, and the fee fraction constant). So although these are technically forks one could also think of these as updated configurations.
As an alternative which I would support more would be a living document with all BPO forks.
I fear if we add all these meta EIPs for BPOs, and if there are say 9 of these in the future, then the meta EIP section will look only like BPO forks (which are not super interesting from the changes necessary per client (a few constants) - of course, increasing blob capacity requires a lot of engineering ) and I think most users will think that those are somewhat annoying and should not be there (or grouped under BPO forks, or thus in a separate EIP which documents all BPO forks)
Thanks @jochem-brouwer for your review and thoughtful comments & suggestions.
My reasoning for having a separate Meta EIP per upgrade is more influenced by precedent, particularly the Ice Age–related forks such as Muir Glacier, Arrow Glacier, and Gray Glacier. These were parameter-only upgrades, yet each was documented with its own Meta EIP.
BPO has only recently been introduced, and developers are understandably being cautious, adjusting parameters according to a defined formula. While BPO-style upgrades provide flexibility to modify parameters as needed, I expect the system to stabilize over time, which may naturally lead to less frequent upgrades in the future (i.e., not necessarily having many BPO Meta EIPs each year).
Additionally, the parameter changes are not strictly unidirectional; the same flexibility allows values to be reduced if and when required. Given this, I see value in recording each change in a separate file, ideally with accompanying rationale, to preserve clarity, traceability, and historical context.
I did consider the alternative of maintaining a single Living Meta EIP and appending a new row for each upgrade. However, historically, EIP editors have been cautious about using EIPs as living registries. That said, I would be open to this approach if there is broad agreement among the editors.
) and I think most users will think that those are somewhat annoying and should not be there (or grouped under BPO forks, or thus in a separate EIP which documents all BPO forks)