EIP-8136: When Ethereum's PeerDAS Gets Cell-Level Precision for Data Columns
EIP-8136 proposes cell-level deltas for PeerDAS data column broadcasts, tracking changes at ~4 KB cell granularity instead of re-broadcasting entire 128 KB columns. The Data Propagation Efficiency Score of 6.25/10 reveals significant bandwidth savings but implementation complexity and rollback fragility temper enthusiasm.
The proposal surfaced in early August 2026, with the granular confidence of a networking optimization that knows it targets a specific bottleneck. EIP-8136 introduces cell-level deltas for PeerDAS data column broadcasts—enhancing how Ethereum's peer-to-peer data availability sampling (PeerDAS) propagates data by tracking changes at the individual cell level rather than the entire column level. The goal: reduce redundant network traffic when only a small portion of a data column changes between blocks.
That was the networking. Then came the question of whether cell-level granularity is worth the complexity when column-level broadcasting already functions.
What EIP-8136 Actually Proposes
PeerDAS (Peer Data Availability Sampling) is Ethereum's mechanism for ensuring that blob data—large data payloads posted by rollups—is available across the network without requiring every node to download everything. The network divides blob data into columns, and validators sample random columns to verify availability.
The Current Column-Level Approach:
- Full Column Broadcast: When a blob is updated, the entire data column is re-broadcast to peers
- Redundant Traffic: If only 5% of a column changed, 95% of the broadcast is duplicate data
- Bandwidth Waste: Particularly severe for rollups that post frequent small updates
- Client Overhead: Peers must process and validate entire columns even when changes are minimal
The Cell-Level Delta Solution:
- Granular Tracking: Data columns are divided into cells (subdivisions); only changed cells are broadcast
- Delta Encoding: Each broadcast contains only the cells that differ from the previous state
- Bandwidth Reduction: Estimated 40-60% reduction in PeerDAS network traffic
- Efficient Validation: Peers apply deltas to existing state rather than reconstructing entire columns
Key Metrics at a Glance
| Metric | Current (Column-Level) | Post-Cell-Level-Deltas | Improvement |
|---|---|---|---|
| PeerDAS Broadcast Size | 128 KB per column | ~50-75 KB per column | 40-60% reduction |
| Network Traffic per Blob | ~4 MB | ~1.6-2.4 MB | Same proportional reduction |
| Validator Bandwidth Usage | 300 GB/month | 120-180 GB/month | 40-60% reduction |
| Delta Computation Overhead | None | ~2% CPU increase | Marginal cost |
| Rollback Complexity | Column-level | Cell-level | More granular but complex |
| Implementation Complexity | Standard | Medium | Changes to gossip and storage |
The Proprietary Data Propagation Efficiency Score (DPES)
I've developed a framework to evaluate whether cell-level delta encoding delivers enough efficiency to justify changes to PeerDAS's networking and storage layers:
Formula: DPES = (Bandwidth Savings × 0.3) + (Network Scalability × 0.25) + (Implementation Simplicity × 0.25) + (Rollback Safety × 0.2)
EIP-8136 Assessment:
| Factor | Score | Analysis |
|---|---|---|
| Bandwidth Savings | 8/10 | 40-60% reduction is significant for networking layers |
| Network Scalability | 7/10 | Enables more rollups and higher blob throughput |
| Implementation Simplicity | 5/10 | Complex delta tracking; affects gossip, storage, and validation |
| Rollback Safety | 5/10 | Cell-level rollbacks are harder to reason about and test |
| Total DPES | 6.25/10 | Good proposal but implementation complexity tempers enthusiasm |
A score of 6.25 indicates the proposal is worthwhile but not essential. The bandwidth savings are real, but they must be weighed against the complexity of tracking cell-level state across a distributed network.
The Three Networking Realities
The proposal is technically sound, but it faces practical challenges that no delta encoding can resolve:
Reality 1: The Bandwidth Problem Is Already Being Addressed
Ethereum's networking team has multiple parallel optimizations in flight: subnet sampling, blob compression, and improved peer selection. EIP-8070 (Sparse Blobpool) targets similar bandwidth savings through custody-aligned sampling. Cell-level deltas are one of several approaches, and it is not clear they are the best. The networking working group must evaluate whether delta encoding outperforms alternatives that require less state tracking.
Reality 2: Cell-Level State Is Fragile
Tracking state at the cell level introduces a new class of bugs: missed deltas, out-of-order application, corrupted cell indexes. If a peer receives deltas out of order, or misses a single delta broadcast, its local state diverges from the network. Detecting and repairing such divergence requires additional protocol complexity. Column-level broadcasting, while inefficient, is simple and robust. Cell-level deltas trade reliability for efficiency—a calculation that depends on failure tolerance.
Reality 3: Rollups May Not Need Frequent Small Updates
The primary beneficiaries of cell-level deltas are rollups that post frequent small updates. But rollup economics already favor batching: posting fewer, larger updates reduces fixed costs per blob. As blob fees stabilize, rollups may naturally batch more data per post, reducing the frequency of small updates that cell-level deltas optimize for. The proposal optimizes for a use pattern that may diminish over time.
Competitive Landscape: Data Availability Propagation
| Approach | Chain/System | Granularity | Bandwidth Reduction | Production Status |
|---|---|---|---|---|
| Column-Level Broadcast | Ethereum (current) | 128 KB columns | Baseline | Production |
| Cell-Level Deltas | Ethereum (proposed) | ~4 KB cells | 40-60% | Draft |
| Subnet Sampling | Ethereum (research) | Column subsets | 50-70% | Research |
| Data Availability Sampling | Celestia | 2D matrix | 90%+ | Production |
| Erasure Coding | Various L2s | Shard-level | 50-80% | Production |
| Direct Peering | Research | Custom | 40-60% | Research |
Cell-level deltas deliver competitive bandwidth reduction but face strong alternatives. Celestia's 2D sampling achieves higher compression with a simpler security model. Subnet sampling may deliver similar gains with less state tracking complexity. The cell-level approach is viable but not obviously superior.
Scenario Analysis: Three Futures for Cell-Level Deltas
Scenario A: Glamsterdam Integration (35% probability)
- EIP-8136 is bundled with Glamsterdam as a PeerDAS enhancement
- Coordinated with other networking changes to amortize hardfork risk
- Rollup developers adopt cell-aware data posting patterns
- Becomes standard for post-Glamsterdam blob propagation
Scenario B: Post-Glamsterdam Rollout (35% probability)
- Networking team prioritizes Glamsterdam stability first
- EIP ships as standalone PeerDAS upgrade 6-12 months later
- Requires separate testing cycle but lower coordination risk
- Slower adoption but cleaner implementation
Scenario C: Alternative Supersedes (30% probability)
- Subnet sampling or erasure coding advances prove more efficient
- Cell-level delta benefits are achieved through different mechanism
- EIP becomes reference material but never activates
- Networking improvements continue without delta encoding complexity
The Bottom Line
EIP-8136 proposes a technically sound optimization that would reduce PeerDAS network traffic by tracking changes at the cell level. The 40-60% bandwidth reduction would matter for validators operating on constrained connections and for the network's ability to scale blob throughput as rollup adoption grows.
But Ethereum's PeerDAS layer is not a blank slate. It is a production system already handling live rollup data. Cell-level deltas add state tracking complexity that must be implemented correctly across all consensus clients, tested under network partitions, and secured against delta manipulation attacks. The question is not whether cell-level tracking saves bandwidth. It is whether the savings justify the permanent complexity cost.
The researchers did careful work. The delta encoding is elegant. The savings are measurable. But PeerDAS already functions. The network already scales. And alternatives may achieve similar gains with simpler mechanisms. The race is between EIP-8136 and the networking working group's next optimization.
This EIP might ship. It might help validators and rollups. But it is not the revolution Ethereum needs. It is a networking refinement that must prove itself against simpler competitors before earning a place in the protocol.
TL;DR
- What: EIP-8136 proposes cell-level deltas for PeerDAS data column broadcasts, tracking changes at ~4 KB cell granularity instead of re-broadcasting entire 128 KB columns
- The Score: Data Propagation Efficiency Score of 6.25/10—significant bandwidth savings but implementation complexity and rollback fragility temper enthusiasm
- The Reality: Multiple alternative optimizations in flight; cell-level state tracking introduces new bug classes; rollup economics may shift toward batching, reducing delta value
- The Comparison: 40-60% reduction vs Celestia's 90%+ with 2D sampling and simpler security model
- Outlook: Most likely (35%) is Glamsterdam bundling; post-Glamsterdam rollout (35%) or supersession by alternatives (30%) are equally probable
Sources
- EIP Repository - EIP-8136 - August 2026 cell-level delta proposal
- Ethereum Research Forum - PeerDAS - Technical discussions on data availability sampling
- Ethereum Consensus Specs - PeerDAS and networking standards
- Lighthouse Networking Documentation - Consensus client PeerDAS implementation
- Celestia Documentation - Alternative data availability sampling approach
- Client Diversity Dashboard - Execution and consensus client distribution
- Ethereum Foundation Roadmap - Official protocol development priorities
Zain Tran is TotesTek's Ethereum Ecosystem Columnist & Accountability Reporter. He writes about Ethereum, ETH, smart contracts, DeFi, Layer 2 networks, staking, validators, and the real-world consequences of technical and financial failure.