# 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
1155

Read more

7732 - Late Payload Commitment

It feels like we've been endlessly discussing various slot restructuring designs. Unfortunately, I have one more design to offer. Apologies in advance. Where we Stand After months of exploring different designs, the best available option appears to be EIP-7732 with a small modification for dual-deadline PTC. The only unknown at this point, is whether builder withhold timing games are a serious threat to protocol stability. This class of attacks, which we may call reveal timing games rather than the commit timing games we are used to, is possible in any design where there is a time delta between the moment transactions are committed to, and the moment all components of the block are revealed. Right now this topic is under-researched, and we are currently exploring it. If payload reveal timing games are found to pose unacceptable stability risks — and if mitigating them introduces prohibitive trade-offs — I propose this alternative which mitigates these attacks while preserving most of the positive properties of EIP-7732. Specification - A Small Shift in the Design

7/21/2025
Slot Restructuring Tradeoff Matrix

Property 7732 Block Auction Single Deadline PTC 7732 Block Auction Dual Deadline PTC Payload Block Separation noPTC EIP-7886 EIP-7886 + PTC 7732 Slot Auction Single Deadline PTC 7732 Slot Auction Dual Deadline PTC Max Scaling / Lowest Latencies

7/20/2025
In Defense of Trustless Builder Payments

There is a common mental model for EIP-7732 which splits the proposal into three main components: Payload-Block Separation PTC Committee Trustless Builder Payments At this stage in the discussion, many core-developers are on board with the first two components. See my earlier writing if you would like to understand why. Some core-developers are more concerned about trustless builder payments and would advocate for this to be removed from Glamsterdam. As far as I can tell, there are a few main criticisms of the on-chain trustless builder payment mechanism:

7/19/2025
Dubious Math Around Builder Reveal Timing Games

The Problem at Hand An under-researched topic has emerged in the discussion of EIP-7732 around builders playing reveal timing games to exercise an option. Here's an example to illustrate the basic idea: Suppose at time $t=0$ three things happen: The builder places a trade to sell $Q$ ETH on a DEX at price $P_0$ at the top of their block. The builder's block is chosen by the proposer. The builder places a trade to buy $Q$ ETH on a CEX at a price $P < P_0$ to pocket the arbitrage. Suppose at time $t = Δt$ later two things happen:

7/18/2025
Read more from ethDreamer
Published on HackMD