Sharding and Danksharding in Ethereum: How EIP-4844 Improves Layer 2 Scaling

The two bottlenecks of blockchain throughput

Public blockchain throughput is not limited by one single factor. To scale safely, a network must answer two questions. First, can state transitions be verified efficiently? Second, can everyone who needs the data fetch it and reconstruct the state? The first question is about execution. The second is about data availability.

Execution is the process of applying transactions to the current state and producing a new state. A normal Ethereum transaction changes balances, storage, nonces, logs, or contract state. If Ethereum tried to execute every global application interaction directly on the base layer, fees would rise whenever demand grows. That is what rollups are designed to avoid.

Data availability is different. Even if rollups execute transactions off-chain, they still need to publish enough data for others to reconstruct what happened. Without that data, users cannot independently verify balances, produce exit proofs, challenge invalid claims in optimistic systems, or rebuild state if the operator disappears. A rollup that proves or claims a state transition but hides the data behind it can leave users dependent on the operator.

Ethereum’s roadmap treats those two bottlenecks separately. Rollups handle execution scale. Ethereum improves data bandwidth for rollups. Blobs, Proto-Danksharding, Danksharding, and PeerDAS belong to the second part of the roadmap. They are not about making the EVM execute more transactions directly. They are about making Ethereum a stronger, cheaper data availability layer for rollups.

Execution integrity

Execution integrity means users can trust that a state transition followed the rules. Optimistic rollups rely on fraud proofs and challenge windows. ZK rollups rely on validity proofs. Both approaches move computation away from the base layer while keeping a route for Ethereum to reject invalid state.

Data availability

Data availability means the transaction data or state-diff data required to reconstruct rollup state is accessible. If that data is missing, a proof may still be valid, but users can lose practical recoverability. This is why rollup scaling depends so heavily on cheap data publication.

Settlement and finality

Ethereum settlement gives rollups a neutral base for deposits, withdrawals, proof verification, and finality. When a rollup posts data and a valid proof or claim to Ethereum, users can rely on Ethereum’s consensus and validator set rather than trusting a single rollup operator.

Classic sharding versus Ethereum’s rollup-centric roadmap

Classic sharding originally meant splitting the blockchain into many execution shards. Each shard would process its own transactions and maintain its own state. In theory, this allows parallel throughput because many shards can execute different transactions at the same time.

The problem is complexity. Cross-shard communication is hard. If one DeFi transaction needs state from multiple shards, the protocol must coordinate atomicity, ordering, liveness, and security across different execution environments. Validators must handle shard assignments. Developers must reason about asynchronous state. Users must understand where assets live. Bridges between shards become part of the normal execution model.

Ethereum’s roadmap changed because rollups became a better execution-scaling path. Instead of building many base-layer execution shards, Ethereum can keep one unified settlement and consensus layer while rollups compete on execution. Rollups can run EVM-equivalent environments, zkVMs, app-specific runtimes, high-performance sequencers, gaming environments, and specialized DeFi systems without forcing Ethereum’s base layer to execute all of them.

Why classic execution sharding was difficult

Execution sharding increases the number of places where state can live. That creates cross-shard transaction problems. If a user wants to swap an asset on one shard using collateral from another shard, the protocol needs to coordinate state changes safely. This can introduce delays, fragmented liquidity, complicated developer tooling, and new attack surfaces.

Why rollups simplified the scaling plan

Rollups move execution complexity out of the base layer. Ethereum does not need to directly execute every rollup transaction. It only needs to verify proofs or claims and make data available. This lets rollups innovate quickly while Ethereum remains a credible settlement layer.

Why data bandwidth became the center of the roadmap

Once rollups handle execution, the base layer’s biggest scaling task becomes data. Rollups must publish their batch data somewhere users can access. If that data is too expensive, L2 fees stay high. If it is too weakly available, users face recoverability risk. Danksharding is Ethereum’s answer to this data bottleneck.

Proto-Danksharding and EIP-4844: what blobs changed

EIP-4844 introduced a new type of Ethereum transaction that carries blobs. A blob is a large data object intended mainly for rollups to publish batch data. The key point is that blob data is not ordinary EVM calldata. It uses a separate data path and a separate fee market, which lets rollups post data more cheaply than relying entirely on calldata.

Before blobs, rollups often posted batch data as calldata. Calldata is available to the EVM and historically has been expensive because it is part of Ethereum’s general transaction data model. Rollups paid significant costs just to publish the data users needed for reconstruction and verification. EIP-4844 changed that by giving rollups a purpose-built data resource.

Proto-Danksharding is called “proto” because it implements the early blob transaction format without full Danksharding capacity and full sampling. It is the bridge between the old calldata-heavy rollup world and the future data-sampling world. It gives rollups cheaper data today while keeping the design forward-compatible with later Danksharding upgrades.

Blobs are opaque to the EVM

Blob data is not meant to be read directly by smart contracts like calldata. Contracts can work with commitments and related metadata, while rollup nodes and indexers fetch the actual blob data through the consensus data path. This separation helps reduce the load on EVM execution.

Blobs are temporary at the protocol layer

Blobs are designed for availability during a retention window, not permanent storage forever. That is a feature, not a flaw. Rollups need the data long enough for honest participants to download, reconstruct, archive, challenge where needed, and support exits. Long-term archival becomes the responsibility of rollups, indexers, explorers, data providers, and other ecosystem services.

Commitments anchor blob data

Blob data is tied to blocks using cryptographic commitments. These commitments let the protocol and rollup infrastructure refer to the data without making every byte part of EVM execution. The commitment structure is part of the bridge between large rollup data and compact verification.

Why EIP-4844 lowered L2 fees

For many rollups, data publication was a major cost. If the cost of publishing batch data falls, the cost per L2 transaction can fall too. The effect depends on blob demand, rollup compression, batching strategy, proof design, and how much of the fee reduction the rollup passes to users.

Blob fee market and rollup economics

Blobs have their own fee market. That matters because rollup data demand no longer competes directly with ordinary EVM execution gas in the same way calldata did. When blob demand rises, the blob base fee rises. When blob demand falls, the blob base fee falls. This lets Ethereum price data bandwidth more directly.

A separate blob fee market gives rollups a cleaner cost signal. If blob prices are low, rollups may post smaller batches more frequently, improving latency. If blob prices rise, rollups may compress harder, wait longer between batches, or optimize proof and data strategies. Over time, rollups compete not only on execution speed but on data efficiency.

Why blob pricing matters to users

Users feel blob pricing through L2 fees. If a rollup spends less to publish data, it can reduce transaction fees or improve responsiveness. The exact result depends on each rollup’s fee model, sequencer economics, competition, and demand.

Why blob pricing matters to rollups

Rollups must decide when to publish, how much data to include, how aggressively to compress, and how to balance latency against cost. A rollup that waits for huge batches may reduce data cost per transaction but worsen user latency. A rollup that posts constantly may improve UX but pay more during congestion.

Compression becomes a competitive advantage

Efficient rollups reduce the bytes required per transaction. This can involve better encoding, state diffs, transaction aggregation, proof recursion, batching heuristics, and application-specific data formats. Lower bytes per transaction means less blob space consumed.

Blob congestion can still happen

A separate blob market does not mean blob fees are always low. If many rollups, airdrops, high-volume apps, or market events compete for blob space, blob fees can rise. The difference is that congestion is more contained within the data market rather than fully merging with ordinary L1 execution demand.

What is Danksharding?

Danksharding is Ethereum’s broader design for scaling data availability. It moves beyond the initial blob transaction format toward much higher blob capacity and data availability sampling. The goal is to let Ethereum support many rollups publishing large amounts of data without requiring every validator or node to download and store all data permanently.

The name can be confusing because Danksharding is not classic execution sharding. It does not mean dozens of separate Ethereum execution shards with independent proposers. Instead, it keeps a unified block structure while scaling blob data. The base layer remains focused on consensus, settlement, and DA.

One proposer, many blobs

Danksharding keeps the idea of one proposer for a slot rather than many independent shard proposers. This simplifies block construction and avoids some cross-shard MEV and coordination problems that classic sharding would introduce.

More data without making every node heavy

The challenge is increasing blob capacity without forcing every node to download every blob fully. If running a node becomes too expensive, Ethereum becomes more centralized. Data availability sampling is the mechanism intended to let smaller nodes participate in availability checks without carrying the full data burden.

Proto-Danksharding versus full Danksharding

Proto-Danksharding introduced blobs and a blob fee market. Full Danksharding aims for much larger blob bandwidth with mature sampling and related networking improvements. The roadmap is incremental because Ethereum cannot safely jump to massive data throughput without proving that clients, validators, networks, and operators can handle it.

Data availability sampling and PeerDAS

Data availability sampling is the core technique that makes high blob capacity more realistic. Instead of every validator downloading every byte of every blob, validators sample small pieces of erasure-coded data. If enough random samples are available across the network, the protocol can gain strong confidence that the full data was available.

PeerDAS, or peer-to-peer data availability sampling, is an important roadmap step because it brings sampling closer to the actual peer-to-peer layer. The goal is to scale data bandwidth while keeping validator and node requirements manageable.

Erasure coding

Erasure coding expands data into redundant chunks. The original data can be reconstructed from a sufficient subset of chunks. This means the network can tolerate some missing pieces. If an attacker withholds a large portion of the data, random samplers are likely to notice because many sampled chunks will fail.

Random sampling

Validators and nodes request random chunks. The randomness makes it difficult for a malicious block builder or data withholder to hide exactly the pieces that nobody will check. With enough independent sampling, the network gains statistical confidence that the blob data was available.

Light-client friendliness

The long-term benefit is that lower-resource participants can contribute to availability checks. A light client may not download every blob, but it can still sample enough to gain confidence. This helps decentralization because data verification does not become limited to large data-center operators.

Why sampling is probabilistic

Sampling gives high probability, not the same kind of guarantee as every node downloading every byte. That is acceptable when the probability of missing withheld data becomes extremely low under the protocol’s assumptions. The design must choose sampling rates, erasure coding parameters, networking rules, and validator responsibilities carefully.

Proposer-builder separation, MEV, and inclusion lists

As Ethereum blocks carry more data and as MEV strategies become more complex, block construction becomes specialized. Proposer-builder separation is a design pattern that separates the role of building a profitable block from the role of proposing it to the network.

In a basic validator model, the validator chosen for a slot might need to construct the best block. That can create centralization pressure because sophisticated block construction requires infrastructure, private order flow, MEV search, simulation, latency optimization, and blob packing. PBS lets specialized builders compete to construct blocks, while proposers select among bids.

Why PBS fits Danksharding

Danksharding increases the importance of block-building efficiency. Builders must reason about execution payloads, blob payloads, MEV, fee markets, inclusion constraints, and network propagation. Separating proposers from builders can reduce the need for every validator to run advanced block-building infrastructure.

MEV centralization risk

MEV can centralize around actors with better order flow and infrastructure. If only a few builders dominate block construction, censorship and economic extraction become serious concerns. PBS does not eliminate MEV risk, but it gives the protocol a cleaner structure for addressing it.

Inclusion lists

Inclusion lists are designed to help censorship resistance by letting proposers specify transactions that should be included. This matters because a builder that maximizes profit might ignore low-profit or politically sensitive transactions. Inclusion lists can give proposers a way to enforce minimum inclusion expectations.

Why this matters for rollups

Rollups depend on timely posting of proofs, claims, batch commitments, and blob data. If builders or proposers censor rollup submissions, L2 users can experience delays, withdrawal problems, or higher costs. PBS and inclusion mechanisms are therefore part of the scaling UX, not only validator economics.

Implications for optimistic rollups, ZK rollups, Validium, and Volition

EIP-4844 and Danksharding matter to every rollup category because they target the cost of data. Whether a rollup is optimistic or ZK, it needs data availability. The exact reason differs, but the need remains.

Optimistic rollups

Optimistic rollups need data so challengers can reconstruct state and detect invalid transitions during the challenge window. If the data is unavailable, challengers cannot reliably dispute fraud. Blob data lowers the cost of publishing that information while preserving the ability for honest actors to watch the system.

ZK rollups

ZK rollups post validity proofs that show state transitions are correct. But users still need data to reconstruct state, generate proofs, and understand their balances. The proof does not remove the need for data. Blobs reduce the cost of giving users that recoverability.

Validium systems

A Validium posts validity proofs but keeps data outside the settlement layer. Cheaper blobs can change the decision boundary. Some teams may keep low-value high-volume activity in Validium mode while moving more important settlement data back to Ethereum blobs because the cost becomes acceptable.

Volition systems

Volition systems can benefit from blobs by using rollup mode for high-value activity and off-chain DA for bulk traffic. As blob capacity increases, more transactions may move into stronger DA mode without fee shock. That can improve user safety while preserving low-cost options.

Rollup competition

Lower data costs do not automatically make all rollups equal. Rollups will still compete on execution speed, prover performance, sequencer decentralization, bridge safety, fee pass-through, compression efficiency, developer tooling, and application liquidity.

Security considerations and tradeoffs

Proto-Danksharding does not rewrite the EVM. It adds a data lane for rollups. That means the main security questions are about blob availability, retention, networking, commitments, client behavior, rollup archival, and bridge design.

Availability window

Because blobs are temporary at the protocol layer, rollups must fetch and archive their own data within the availability window. If a rollup fails to archive relevant blob data, it can create long-term reconstruction problems. This is an operational responsibility, not a theoretical detail.

Commitment integrity

Blob commitments tie data to blocks. Rollups and clients must verify that the data they archive matches the commitments included on-chain. A broken archival pipeline can corrupt history even if the base protocol behaved correctly.

Network bandwidth and denial of service

More blobs mean more transient data moving through the peer-to-peer network. Clients need bandwidth management, rate limits, peer diversity, and monitoring. If blob traffic overwhelms nodes, decentralization suffers.

MEV and censorship

Rollup submissions can be censored or delayed. Forced inclusion and inclusion-list mechanisms matter because L2 users need confidence that their transactions, withdrawals, and proof submissions can eventually reach Ethereum.

Bridge and exit safety

Bridges must treat blob commitments and rollup data as part of the withdrawal security path. Users should know whether the data needed for an exit was archived, whether proof generation is possible, and what fallback exists if the rollup operator fails.

Node operations after EIP-4844

EIP-4844 affects node and infrastructure operations because blobs add transient data load. The data is not permanent in the same way as calldata, but nodes still need to receive, verify, propagate, and serve blob data during the retention window.

Bandwidth planning

Node operators need enough network capacity to handle blob traffic without harming peer connectivity or block propagation. As blob capacity increases over the roadmap, bandwidth planning becomes more important.

Short-term storage

Blobs require storage during the availability window. Operators should monitor disk usage, cleanup behavior, client settings, and failure logs. Temporary does not mean free.

Client diversity

Client diversity remains essential. Blob logic, networking behavior, commitment verification, and sampling features all add implementation complexity. A bug in one dominant client can become a network-level risk if too many operators rely on it.

Monitoring

Operators should monitor blob import times, missing blob warnings, peer counts, bandwidth pressure, disk pressure, client errors, and blob fee spikes. L2 teams should also monitor whether their posted blobs were fetched and archived correctly.

User experience: fees, throughput, and migration paths

For everyday users, the most visible impact of EIP-4844 is lower L2 fees when blob data is cheaper than calldata. But the deeper impact is that L2s can post more often, support more activity, and design better fee markets. Cheaper data can make rollups feel faster and more predictable.

Lower L2 fees

Data publication is a major component of rollup cost. When that cost falls, transfers, swaps, mints, and app interactions can become cheaper. Fee savings vary by rollup because each system has its own batching, compression, sequencer, and fee pass-through model.

Lower latency through smaller batches

If posting data is cheaper, rollups can sometimes post smaller batches more frequently. That reduces waiting time for users. However, rollups must still balance proof generation, blob fees, sequencer economics, and settlement frequency.

More app-specific rollups

Lower DA costs make app-specific rollups more practical. Games, exchanges, social networks, enterprise ledgers, creator platforms, and high-volume consumer apps can build their own execution environments while relying on Ethereum for settlement and data.

Security tier choices

Some systems may combine blobs with off-chain DA through Validium or Volition designs. Users may see choices between stronger rollup-mode data and cheaper external data. The interface should explain those choices clearly, especially for withdrawals and high-value actions.

Engineering playbook for Layer 2 teams

EIP-4844 gave rollups a cheaper data lane, but using it well requires engineering discipline. A rollup must optimize its data pipeline, proof pipeline, archival pipeline, bridge pipeline, and user communication together. Treating blobs as a simple fee discount misses the operational complexity.

Move from calldata-heavy posting to blob-aware posting

Rollups need data pipelines that build blob transactions, track commitments, monitor inclusion, and recover gracefully when blob markets are congested. The system should avoid hardcoding assumptions that break as blob parameters change over future upgrades.

Optimize compression and batch format

Compression directly affects blob usage. Rollups should profile transaction encoding, state-diff formats, signature aggregation, account abstraction overhead, proof data, and application-specific compression. Every saved byte can reduce fees at scale.

Archive blob data independently

Rollups must not depend on the Ethereum network to store blob data forever. They should run their own archival systems, support independent archive providers, and make data accessible to users, auditors, explorers, and watchtowers.

Design exits around archived data

Exits should be tied to data that users can access. If a user cannot get the data needed to produce an exit proof, the rollup has a practical recoverability problem. Exit design must be tested under operator failure, indexer failure, proof delay, and L1 congestion.

Support forced inclusion

Forced inclusion gives users a route when the sequencer censors them. It is especially important for withdrawals, emergency exits, and governance actions. A scaling system is not only measured by cheap transactions when the sequencer behaves. It is measured by what users can do when the sequencer does not.

How Danksharding changes Validium and Volition decisions

Danksharding does not eliminate external data availability systems. It changes the cost comparison. If Ethereum blob data becomes cheaper and more abundant, more rollups may choose stronger on-chain DA for actions that were previously too expensive. At the same time, games, social apps, and high-frequency systems may still use external DA for bulk traffic.

Validium after cheaper blobs

A Validium stores data outside Ethereum to reduce cost. If blob costs keep falling, some Validium use cases may shift toward rollup mode for higher-value assets. But off-chain DA will still appeal to extremely high-throughput or low-value activity where every cent matters.

Volition after cheaper blobs

Volition becomes more attractive because it lets systems mix modes. A protocol can use Ethereum blobs for withdrawals, collateral, governance, and settlement, while using external DA for game actions, social activity, or order updates. As blob capacity grows, more actions can move toward stronger DA.

Security by default

The safer design is to default high-value activity into stronger DA and allow lower-cost modes only where the failure mode is acceptable. Users should not accidentally put critical assets into weak recoverability paths because the interface pushed them toward the cheapest option.

Common mistakes in Danksharding and EIP-4844 discussions

The first mistake is saying that blobs are simply cheaper calldata. Blobs are a different data resource. They are not meant to be read directly by the EVM in the same way calldata is, and they are not permanent storage at the protocol layer.

The second mistake is assuming lower L2 fees mean all rollup risk disappears. Blobs reduce data costs, but users still need safe bridges, honest or challengeable state transitions, robust sequencers, good archival, and clear exits.

The third mistake is treating Danksharding as classic execution sharding. Danksharding is focused on data availability for rollups, not splitting Ethereum into many independent execution shards.

The fourth mistake is forgetting archival. If blob data is temporary at the protocol layer, rollups must archive it. A rollup that fails to preserve its own data can create user and indexer problems later.

The fifth mistake is ignoring blob fee congestion. Blob markets can still become expensive when demand spikes. Rollups need adaptive batch strategies and transparent user fee estimates.

The sixth mistake is assuming PBS solves censorship automatically. PBS can reduce some centralization pressure, but censorship resistance still needs inclusion mechanisms, monitoring, and fallback paths.

The seventh mistake is ignoring Validium and Volition context. Cheaper blobs change the economics of external DA, but they do not remove the need to explain DA tradeoffs to users.

TokenToolHub workflow for researching Ethereum scaling

TokenToolHub readers can use Ethereum scaling research to evaluate Layer 2 claims more carefully. A low-fee network is not automatically safe. A ZK proof is not automatically enough. A bridge can still be weak. A rollup can still have centralized sequencing. A Validium can still face data withholding. The right research process asks what each layer guarantees.

For L2 users

Check whether the network is a rollup, Validium, Volition, sidechain, or another hybrid design. Review withdrawal assumptions. Check whether the app explains blob posting, finality, bridge waiting periods, and exit risk. Low fees are useful, but only when the recovery path is clear.

For bridge researchers

Scaling and bridge risk are connected. A bridge must understand the rollup’s data path, proof system, and withdrawal design. Use the TokenToolHub Bridge Helper to support bridge-safety research when comparing cross-chain routes, withdrawal assumptions, and settlement paths.

For token researchers

Tokens inside L2 ecosystems still need token-level review. Use the TokenToolHub Token Safety Checker as an early scan step before interacting with unfamiliar assets, then review the L2’s data availability and bridge assumptions separately.

For builders

Use TokenToolHub Advanced Guides to study adjacent topics such as rollup risk, bridges, account abstraction, formal verification, post-quantum planning, MEV, sequencer design, and data availability. Scaling systems should be designed as a full pipeline, not as isolated modules.

Glossary

Final verdict: Danksharding makes Ethereum a stronger data layer for rollups

Sharding in Ethereum has evolved. The original vision of many execution shards gave way to a rollup-centric roadmap because rollups are a cleaner way to scale execution while preserving Ethereum as a unified settlement layer. That changed the main bottleneck. If rollups execute off-chain, Ethereum’s most important scaling job becomes cheap, reliable, verifiable data availability.

EIP-4844 was the practical turning point. By introducing blob transactions, Ethereum gave rollups a separate data resource that is cheaper than relying on calldata for batch publication. This lowered L2 costs, improved the economics of frequent batch posting, and prepared the network for future Danksharding upgrades.

Danksharding extends the same logic. It aims to increase blob capacity dramatically while using data availability sampling to avoid forcing every node to download every byte. PeerDAS pushes that sampling model into the peer-to-peer layer, helping Ethereum scale data bandwidth while preserving decentralization.

The roadmap also changes how rollups compete. The winners will not only be the rollups with the lowest nominal fees. They will be the ones that use blobs efficiently, archive data responsibly, provide clear withdrawal paths, design sequencers with censorship resistance, manage proof latency, communicate finality honestly, and protect users during failure states.

The practical conclusion is simple. Ethereum scaling is now a data-availability story as much as an execution story. Blobs made rollups cheaper. Danksharding and PeerDAS aim to make rollup data far more scalable. But users and builders still need to ask hard questions: where is the data, who archives it, how are exits generated, what happens if blob fees spike, how does the sequencer behave, and how does the bridge protect users? Those questions separate real scaling from cheap-looking risk.

FAQs

TokenToolHub resources

Use these TokenToolHub resources to continue learning about Ethereum scaling, rollups, bridges, smart contract infrastructure, data availability, and safer Web3 research.

• TokenToolHub Blockchain Technology Guides
• TokenToolHub Advanced Guides
• TokenToolHub Bridge Helper
• TokenToolHub Token Safety Checker
• TokenToolHub AI Learning Hub
• TokenToolHub Community
• TokenToolHub Subscribe

Further learning and references

Use these references to study EIP-4844, blobs, Danksharding, PeerDAS, data availability, proposer-builder separation, and rollup scaling from primary Ethereum sources.

• EIP-4844: Shard Blob Transactions
• Ethereum data availability documentation
• Ethereum Danksharding roadmap
• Ethereum PeerDAS roadmap
• Ethereum proposer-builder separation roadmap
• Ethereum scaling roadmap
• Ethereum zk-rollup documentation
• Ethereum optimistic rollup documentation
• Ethereum consensus specifications
• EIP-7892: Blob Parameter Only Hardforks

This guide is for educational research only and is not financial, legal, tax, investment, cybersecurity, validator, bridge, or engineering advice. Ethereum scaling, blobs, rollups, bridges, data availability, node operations, and withdrawal systems involve technical and economic risks. Review official documentation, audits, client releases, governance updates, and live network conditions before relying on any scaling system with meaningful value.