Sharding means splitting one big system into smaller pieces, called shards, so that no single machine has to store or process everything. Blockchains borrowed the idea from databases: instead of every node checking every transaction, groups of nodes each handle one part. Ethereum planned to split its chain into shard chains, then dropped that plan for a rollup-centric roadmap and now shards only data, through “blobs” (live since March 2024) and PeerDAS sampling (live since 3 December 2025). NEAR, TON and Polkadot use their own forms of sharding.
Read a few explainers on sharding and you will find them describing an Ethereum with dozens of shard chains, a launch “coming in 2023” and 100,000 transactions per second. None of that describes Ethereum today. The core idea of sharding is simple, but the way blockchains actually use it has changed a lot since most of those pages were written. This guide explains what sharding is in plain English, where it came from, how it works on a blockchain, what Ethereum really does now, which other networks shard, and what the trade-offs are. All dates and figures were checked on 14 October 2026.
What is sharding?
Sharding is a way to scale a system by splitting its data and work into smaller pieces, called shards, that are handled in parallel by different machines. Each shard holds only part of the whole, so each machine does less, and adding shards adds capacity.
A simple picture: a library with one librarian who must find every book for every visitor gets slower as the queue grows. Split the shelves into sections, give each section its own librarian, and many requests are served at the same time. The catch is the same in a library and a blockchain: when a request needs books from two sections, the librarians have to coordinate.
Where sharding comes from: databases
Sharding started as a database technique, and that is still what most searches for the word are about. Microsoft’s Azure documentation defines database sharding as “a method of horizontal scaling that splits a database into independent shards”, where each shard holds a subset of the data and the shards together act as one logical database.
A field called the shard key decides which shard each record lives on, and the application uses it to send reads and writes to the right place. Azure lists four common strategies:
| Strategy | How records are placed | Main trade-off |
|---|---|---|
| Hash sharding | The shard key is run through a hash function, which spreads records evenly | Related records can end up on different shards, so range queries get slower |
| Range sharding | Records are grouped by ranges of the key, such as customer ID 1 to 10,000 | Popular ranges can become hotspots |
| Directory sharding | A lookup table maps each key to a shard | Flexible, but the lookup adds complexity and overhead |
| Geo-sharding | Records are split by the user’s location | Lower latency and help with data-residency rules, usually paired with replication |
Source: Microsoft Azure, “What is database sharding?” (checked 14 October 2026).
What is a shard used for? In a database, a shard is used to keep each server’s dataset small enough to query quickly and to let you add capacity by adding servers rather than buying one ever-bigger machine. In a blockchain, a shard is used to give a group of nodes a slice of the network’s state or data, so the whole network can do more than any one node could.
How sharding works in a blockchain
On a classic blockchain such as Bitcoin, every full node downloads, stores and re-executes everything. That is what makes the chain hard to cheat, and it is also why throughput is limited: the network can only go as fast as an ordinary node can keep up.
Sharding breaks that rule on purpose. The general pattern, described in Vitalik Buterin’s 2017 Sharding FAQ and in the designs that followed, looks like this:
- Split the state or data. Accounts, contracts or transaction data are divided into shards. On NEAR, for example, every account belongs to one shard, and its balance, contract code and storage all live there.
- Assign nodes to shards. Each shard gets its own group of validators. To stop an attacker from crowding into one shard, validators are drawn at random from the whole pool.
- Process shards in parallel. Each shard handles its own transactions at the same time as the others.
- Pass messages between shards. When a transaction touches two shards, it is usually split into a debit on one and a credit on the other, linked by a receipt. NEAR’s documentation describes exactly this: a receipt names the receiving account, and the protocol routes it to the right shard.
- Tie it together. Some shared layer (a main chain, relay chain or masterchain, depending on the network) records the shards’ results so everyone agrees on one overall state.
Execution sharding vs data sharding
Not all blockchain sharding splits the same thing. The difference matters, because it is where most explainers go wrong about Ethereum.
| Execution (state) sharding | Data sharding | |
|---|---|---|
| What is split | Accounts, contracts and the work of running transactions | Only the storage and checking of data that other systems publish |
| Who runs transactions | Each shard runs its own | Rollups (layer 2s) run them; the base chain guarantees their data was published |
| Hard part | Cross-shard transactions and keeping each shard secure | Proving data is available without every node downloading all of it |
| Examples (as of 14 October 2026) | NEAR (Nightshade), TON (shardchains) | Ethereum (blobs and PeerDAS) |
Does Ethereum use sharding? What changed
Ethereum does not split execution into shard chains, and it no longer plans to. It shards data instead. ethereum.org’s scaling documentation says sharding “was on the Ethereum roadmap for a long time”, but that the rapid development of layer 2 rollups and the invention of Danksharding “has led the Ethereum community to favour rollup-centric scaling instead of scaling by sharding”. The Danksharding roadmap page is blunter: “Shard chains are no longer part of the roadmap” (page last updated 24 June 2026, checked 14 October 2026).
In practice, rollups such as optimistic and zero-knowledge rollups execute transactions off the main chain, then post their transaction data back to Ethereum so anyone can check or rebuild their state. Ethereum’s job is to make that data cheap to publish and certain to be available. That is what its “sharding” now means.
Step 1: Proto-danksharding (EIP-4844), March 2024
The Dencun upgrade activated on Ethereum mainnet at epoch 269568 on 13 March 2024 at 13:55 UTC, according to the Ethereum Foundation’s announcement. Its headline change was EIP-4844, also called proto-danksharding, which added “blob-carrying transactions”.
- A blob is a 128 KiB chunk of data (4,096 field elements of 32 bytes each, per the EIP-4844 specification).
- Smart contracts cannot read blob contents, only a small cryptographic commitment to them (a KZG commitment).
- Blobs have their own fee market, separate from regular gas, priced with an EIP-1559-style rule.
- Nodes delete blobs after 4,096 epochs, about 18 days, per ethereum.org. Rollups only need the data to be available long enough for anyone to check it.
- At launch the target was 3 blobs per block and the maximum 6.
EIP-4844 calls itself a “stop-gap”: it introduced the transaction format full sharding would use, but every node still downloaded every blob. Nothing was actually sharded yet.
Step 2: PeerDAS (EIP-7594) in the Fusaka upgrade, December 2025
The real data sharding arrived with Fusaka, which activated on mainnet at epoch 411392 on 3 December 2025 at 21:49:11 UTC, according to the Ethereum Foundation’s Fusaka announcement. Its main feature is PeerDAS (EIP-7594), Peer Data Availability Sampling.
PeerDAS extends each blob with erasure coding (extra redundant data that lets missing pieces be rebuilt), then splits the result into columns. Each node keeps and checks only some columns and samples others from its peers every slot. Per the EIP, with current parameters a node downloads about one eighth of the blob data, and the full data can be rebuilt from any 50% of the columns. So nodes no longer need to hold everything for the network to know the data is there. That is sharding in the original sense: each node handles a slice.
Because nodes do less work per blob, Ethereum could then raise blob limits through small “blob parameter only” (BPO) forks:
| Upgrade | Mainnet date (UTC) | Blob target / max per block |
|---|---|---|
| Dencun (EIP-4844) | 13 March 2024 | 3 / 6 |
| Pectra | Before Fusaka | 6 / 9 |
| Fusaka (PeerDAS) | 3 December 2025 | 6 / 9 (unchanged; enables later increases) |
| BPO1 | 9 December 2025 | 10 / 15 |
| BPO2 | 7 January 2026 | 14 / 21 |
Sources: Ethereum Foundation Dencun and Fusaka mainnet announcements; EIP-4844; ethereum.org Fusaka page for the Pectra target (all checked 14 October 2026).
Step 3: Full danksharding, still years away
The end goal is full Danksharding, which ethereum.org describes as raising the blob count per block to 64 and spreading the job of verifying blobs across subsets of nodes, with a stated target of “more than 100,000 transactions per second”. ethereum.org also says “Full Danksharding is several years away” (checked 14 October 2026). Treat the 100,000 figure as a design target, not something Ethereum does today.
Which blockchains use sharding?
Several networks run execution sharding today, each in its own way. Statuses below are from each project’s own documentation, checked 14 October 2026.
| Network | Design | What is split | Status note |
|---|---|---|---|
| Ethereum | Danksharding (blobs + PeerDAS) | Data availability only; rollups execute | PeerDAS live since 3 December 2025; full Danksharding not yet |
| NEAR | Nightshade | State and processing; each account lives on one shard | Nightshade 2.0 with stateless validation live on mainnet as of 22 August 2024, with 6 shards at that date |
| TON | Masterchain plus workchains split into shardchains | The basechain’s accounts and transactions | Shard count set dynamically by network load |
| Polkadot | Relay chain plus parachains | Each parachain has its own state transition logic | Parachains secured by the relay chain’s validators; auctions replaced by coretime |
NEAR: Nightshade
NEAR’s sharding design is called Nightshade. In NEAR’s August 2024 announcement, “both the state and processing are divided among shards”. Nightshade 2.0 added stateless validation: validators no longer keep a shard’s full state locally, but receive a “state witness” with just the data needed to check each change. NEAR’s validator documentation says each top validator is normally assigned to one shard to produce its chunks (a block’s per-shard piece), while other validators check chunks without tracking shards. The August 2024 post put the count at 6 shards, with more planned; check NEAR’s explorer for today’s number.
TON: shardchains that split on demand
TON’s documentation describes a masterchain that holds global configuration and system contracts, and a basechain (workchain 0) that hosts most accounts and “can be split into shardchains for scalability”. The number of shards “is determined dynamically based on the current network load”, and each shard is internally a separate blockchain. For developers, the main visible effect is extra latency on messages that cross shards.
Polkadot: parachains as shards
Polkadot’s documentation says its “sharded network allows for parallel transaction processing”, with each shard (a parachain) able to run its own state transition function. Parachains propose blocks to the relay chain’s validators, who check availability and validity before finalising them, so each parachain gets security from Polkadot’s shared validator set instead of building its own. Parachains now get block space by buying coretime rather than winning slot auctions (Polkadot docs, last updated 29 June 2026).
Sharding vs layer 2 rollups
Both aim to raise capacity, but at different layers. Sharding changes the base chain itself (layer 1) so its work is split across node groups. Rollups leave the base chain alone, run transactions elsewhere, and use the base chain for security and data. ethereum.org files them as “onchain scaling”, which “requires changes to the Ethereum protocol”, versus “offchain” solutions that do not.
Ethereum’s current answer combines the two: rollups for execution, data sharding to make the rollups cheap. Two related terms often come up alongside sharding: the sequencer, which orders a rollup’s transactions, and the sidechain, a separate chain with its own security that only connects to the main chain. For now, the key point is that a sidechain is not a shard. A shard shares the main network’s validators and security, while a sidechain does not.
The risks and trade-offs of sharding
Is blockchain 100% safe? No system is, and sharding adds its own attack surfaces. The main ones:
- Single-shard takeover. If each shard is secured by only a slice of the validators, an attacker needs far less stake or hash power to dominate one shard than the whole network. The 2017 Sharding FAQ describes this attack and the standard defence: assign validators to shards at random from the full pool, so an attacker would need a large share of the entire pool to have a realistic chance of controlling any one shard.
- Data availability. A block producer could publish a block but withhold its data, so nobody can check it. Erasure coding and sampling, the approach Ethereum’s PeerDAS now uses, exist to catch this without every node downloading everything.
- Cross-shard complexity. Transactions that touch several shards need receipts and extra rounds, which adds latency and gives developers more ways to make mistakes.
- Implementation risk. Sharded protocols are more complex than single-chain ones, and complexity is where bugs hide. For applications built on any chain, an independent review still matters; see what a smart contract audit actually covers.
Sharding also does not automatically mean lower fees for you. Fees depend on demand, each network’s fee rules and, on Ethereum, on how rollups price blob space.
Three claims about sharding that are out of date
Among the ranking pages reviewed for this guide (checked 14 October 2026), these were the most common errors:
- “Ethereum 2.0 will run dozens of shard chains.” Shard chains were dropped from the roadmap; Ethereum now shards data, not execution.
- “Sharding goes live on Ethereum in 2023.” Data sharding arrived in stages: blobs in March 2024 and PeerDAS in December 2025. Full Danksharding has not shipped.
- “Sharding gives Ethereum 100,000 TPS.” That is ethereum.org’s target for full Danksharding, not a current figure.
What this means for you
If you just want the concept: sharding is “split the work so no single machine does everything”, first in databases, now in blockchains. If you are comparing blockchains, ask what each one actually shards (execution, data or both), how validators are assigned to shards, and how cross-shard transactions work, rather than relying on throughput headlines. If you are building on Ethereum, sharding reaches you through rollups and blob fees, not through shard chains you deploy to.
If you are hiring a team to build on a sharded or rollup-based chain, the questions in how to vet a blockchain development studio apply directly. For how rollups and other on-chain finance fit together, read what DeFi is, and browse more plain-English explainers in Guides. How this site sources and dates its facts is set out in the methodology.
