PeerDAS sampling and divergent rollup responses to Fusaka upgrade

The Fusaka upgrade arrived on December 3, 2025, to scale the Ethereum data availability layer. EIP-7594 introduced PeerDAS to replace the old method of blob distribution. This protocol uses column subnets and erasure coding to manage data. The system extends every blob by 2x through erasure coding. This extension allows a node with 50% of the data to recover the entire blob. PeerDAS removes the requirement for every node to participate in every blob subnet. Instead, nodes maintain a deterministic set of column subnets based on their node ID. This approach scales the maximum extended blob count from 32 to 64 or even 128. The 68% bandwidth reduction in blobs and the 23% compression in sequencer costs necessitated these changes. The combination of the 68% bandwidth reduction in blobs and the 23% compression in sequencer costs forced Optimism to redesign its fault proof logic while Arbitrum chose to recalibrate its BOLD challenge period. I find the divergence in how these two rollups handle data constraints to be the most striking part of this upgrade cycle. PeerDAS relies on the discovery of sampling peers and the actual peer sampling process. Nodes find compatible families to pair together. These nodes then reliably cover the assigned column subnets. Earlier testing during the Dencun fork showed that block arrival time was 10% worse when a slot contained 6 blobs compared to 1 blob. In that period, the p95 case for blob propagation was approximately 4 seconds.

Rollup divergence in the face of new constraints

Optimism and Arbitrum reacted differently to the new data constraints. Optimism engineers redesigned their fault proof system to handle the 68% bandwidth reduction. They needed to optimize how they process transaction batches under the new limitations. Arbitrum opted for a different strategy. The team recalibrated the BOLD challenge period to account for the 23% compression in sequencer costs. These two rollups now operate under different structural assumptions. You should observe how these architectural differences impact transaction finality on each chain. The Ethereum network currently processes between 13 and 20 transactions per second. The long term goal for the roadmap includes 100,000 transactions per second. Does the shift in rollup architecture threaten the long term stability of the Ethereum settlement layer? Other rollups use different compression methods. Base reduced posted data by 37%. Starknet announced compression methods that reduce data size by 5x. Arbitrum achieved a 5% reduction in data posting size. Previous blob usage data from 2024 indicates that rollups often shift toward smaller transaction batches with higher issuance rates during price surges. Before June 1 of that year, 52% of blocks lacked any blobs. After June 1, 34% of blocks lacked any blobs. The mean transaction rate increased from 0.76 to 1.33 per block.

Technical specifications of the Fusaka upgrade

The Fusaka upgrade integrates the Osaka and Fulu updates. It includes the BPO fork via EIP-7892. This fork modifies three specific blob parameters: the target value, the maximum value, and the base fee adjustment factor. This allows the network to adjust blob capacity in small increments. It removes the need for major hard forks to increase capacity. EIP-7825 limits the gas used in any single transaction. EIP-7934 adds a 10 MB Recursive Length Prefix block size limit. This limit prevents denial-of-service attacks. The block gas target grew from 45 million to 60 million. EIP-7917 makes the proposer schedule for the next epoch fully deterministic via the beacon root. This helps rollups achieve fast finality. EIP-7951 adds the secp256r1 pre-compilation for native P-256 signature support. This allows wallets to use device-level biometrics for logins. EIP-7642 extends the historical data expiration mechanism. This helps clients discard old data and speeds up synchronization for new validators. EIP-7939 provides an opcode for calculating leading zeros. EIP-7823 and EIP-7883 repriced the MODEXP pre-compilation to prevent heavy cryptographic calls from halting the block. This transition to the Verge and Purge stages also depends on these improvements. The Verge focuses on lighter-weight clients. The Purge focuses on clearing old history.

Throughput scaling and validator risks

The current throughput relies on the efficiency of PeerDAS. The system uses erasure coding to extend blobs. This extension creates a 2D matrix in the future stage of the upgrade. This change will allow the blob count to reach 256 per block. The 60 million gas limit accommodates the growing data load. I think the increased complexity of the PeerDAS sampling window creates a risk for smaller nodes. The BPO fork makes blob growth more flexible. The Ethereum network functions as a high-capacity settlement engine for the L2 ecosystem.