# Decouple peerDAS Activation from Fusaka Increasing blob capacity is undeniably Ethereum's top priority. While Pectra introduces a 2x capacity increase, many rollups are projecting a 20x increase in blobspace demand by 2025. To support the growth of L2 ecosystems without stifling their momentum, we must proactively scale capacity as demand increases. One critical step toward this is the adoption of [blob parameter-only forks (BPO forks)](https://ethereum-magicians.org/t/blob-parameter-only-bpo-forks/22623), which I believe are essential. In addition to BPO forks, I propose decoupling PeerDAS activation from Fusaka. This would allow us to adjust the hard fork schedule to meet evolving demands. Instead of following a rigid schedule like this (example, not an actual timeline): ``` March (pectra) -> 6 blob target October (fusaka) -> 48 blob target + EOF ``` We could adopt a more incremental approach (again, illustrative timeline): ``` March (pectra) -> 6 blob target June (peerDAS) -> 12 blob target August -> 24 blob target October (fusaka) -> 48 blob target + EOF ``` ## Trade-Offs and Benefits While this approach requires more frequent testing cycles—a clear trade-off—it may ultimately be worth it to ensure Ethereum remains competitive in the evolving rollup ecosystem. An additional advantage is that it enables a more conservative target during the initial deployment of PeerDAS. Conservative targets are particularly valuable when the first deployment carries higher risks compared to subsequent increases in blob capacity. This strategy isn’t new; we’ve taken similar steps in the past (e.g., the transition to Electra and then Pectra). Starting conservatively allows client teams to: * Optimize PeerDAS implementations as we scale. * Identify and address bottlenecks incrementally. * Gather valuable mainnet data to better understand PeerDAS behavior and inform decisions about future blob capacity expansions.
Last changed by  
 
ethDreamer
987

Read more

Glamsterdam's Hidden Gem: EIP-7732

Before last week's Berlinterop, I would never have expected that I would be recommending EIP-7732: Enshrined Proposer-Builder Separation as the network's highest priority, worthy of taking the spot as Glamsterdam's headliner. Enshrined Proposer Builder Separation (ePBS) was originally designed primarily to enable a trust-free (no off-chain relay requirement) exchange between proposers and builders. This motivation took a major hit years ago when researchers realized that it isn't possible to completely eliminate the incentive to use out of protocol software/relays. Yet another complication arose when we considered possible futures in which proposers want to make alternative agreements with builders (for example slot auctions) that the enshrined mechanism doesn't support. In such a future, these proposers would necessarily go out-of-protocol to make these agreements, seemingly undermining the whole purpose of ePBS. The last thing we wanted to do as core devs is to spend a significant amount of engineering resources to bring this market on-chain, only to have most proposers use out-of-protocol software anyway. No solution to these concerns has been found in the years since they were originally raised. So then why in the world would I recommend EIP-7732 as Glamsterdam's headliner? Because to my surprise, it turns out that EIP-7732 has a number of properties which best position Ethereum for our three strategic initiatives: Scale L1: higher gas limits & L1-zkEVM Scale L2: more blobs Improve UX: lower latencies, faster finality, pre-confs This becomes particularly clear if one takes a slightly longer view of Ethereum for more than one fork down the road. If we do EIP-7732 (and maybe also FOCIL) in Glamsterdam, then we can do shorter slots in H*. 7732 enables us to have shorter slots than any alternative proposal. And for a given slot time we can have more blobs, and bigger blocks than any alternative proposal. And by doing it in this order (7732 first), we can achieve this vision faster and with less technical debt than any other ordering.

6/24/2025
Read more from ethDreamer
Published on HackMD