# Blob-Parameter-Only (BPO) forks Source: https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623 Kiwi News: https://news.kiwistand.com/stories/Blob-Parameter-Only-BPO-forks?index=0x67ae3504eb96c7abbda16367fdc8ad16a091bc60ddb310051023ae453c88a4d30959ef8c Submitted by macbudkowski.eth on 2025-02-13 UTC, 2 upvotes, 2 comments ## Summary Blob-Parameter-Only (BPO) forks are proposed as a framework for safely and continuously scaling Ethereum blobs, authored by Sam McIngvale, Mark Tyneway and Proto. BPO forks are simple Ethereum forks that change only the blob target and blob limit, aiming to scale in smaller, more regular increments and share the operational burden of hard forks across L1 and L2 teams. The authors propose three conditions for a BPO fork: solo staker minimum bandwidth requirements are agreed upon, the blob increase is provably shown not to increase solo staker reorgs, and blobs are sustainably congested. They cite growing consensus around 50Mbps download and upload for solo stakers not using MEV-boost, and suggest a blob increase is safe if the trailing 30-day p999 block size plus the new blob data fits within that bandwidth. ## Article Blob-Parameter-Only (BPO) forks TL;DR: a framework to safely and continuously scale blobs via Blob-Parameter-Only (BPO) forks Sam McIngvale (@sammcingvale), Mark Tyneway (@tynes), Proto (@protolambda) BPO forks BPO forks are simple Ethereum forks that only change two parameters: blob targets and blob limits. BPO forks give Ethereum flexibility to safely scale blobs in smaller, more regular increments and they give builders confidence that Ethereum will continuously grow its capacity. Ethereum hard forks carry a high operational cost/ burden. One goal of BPO forks is to share that burden across both L1 and L2 teams. If we can agree on a BPO fork outline, we and other members of the Optimism Collective will lean-in as much as possible to help shepherd these forks forward and scale Ethereum. A simple framework for BPO forks There are two generally agreed upon priorities with blobs: 1) ensure solo stakers with limited bandwidth can continue to produce blocks, and 2) provide DA scale to L2s to keep tx costs competitive. More flexibility to tweak blob parameters will help Ethereum thread the needle between the two. We propose three conditions for a BPO fork: Solo staker minimum bandwidth requirements are generally agreed upon The proposed blob parameter increase can be provably shown to not increase solo staker reorgs Blobs are sustainably congested Solo staker bandwidth requirements There is growing consensus around 50Mbps download and upload speed for solo stakers not using MEV-boost. We look forward to helping solidify alignment around the right long-term bandwidth requirements for solo stakers and continuously re-evaluate due to changing conditions. Blob parameter increase is safe for solo stakers Upload bandwidth mostly varies based on block size. Therefore, a blob parameter increase should be considered safe for solo stakes if the trailing 30d p999 block size plus the size of data given the new blob target fit within the solo staker bandwidth requirements. Francis from Base has a useful framework for calculating solo staker upload bandwidth requirements. Blobs are sustainably congested Average blob count per block is pegged to the blob target for at least 10 days. See anytime since Nov 1, 2024. We’d love feedback on how best to bring BPO forks to Ethereum to safely scale blobs! More details here: https://docs.google.com/document/d/1XpV-5BrC2IuNFpRAjvZ8OXmK2YLIbuFMEZpDzziJTvs/edit?usp=sharing ## Comments **macbudkowski.eth**: I know we now don't share these infra posts much, but decided to share this because it's pretty easy to follow, and very optimistic for scaling Ethereum. **tim**: To your credit, at least in this one it is also clearly communicated what is the content of the post etc, so it‘s readable.