Shard: Definition, Sharding Architecture, and Implications for DLT Scalability
Definition
A shard is a partition of a distributed ledger network that processes and stores a subset of the network’s total transactions and state. Sharding is the process of dividing a single logical ledger into multiple parallel shards, each operating as a semi-independent chain with its own set of validators and transaction processing capacity. By distributing the transaction load across multiple shards, the network’s aggregate throughput increases approximately proportionally with the number of shards, enabling scalability beyond the limits of a single-chain architecture where every validator must process every transaction.
How Sharding Works
In a non-sharded (monolithic) blockchain, every node in the network processes every transaction and maintains a copy of the entire ledger state. This design provides strong security and consistency guarantees but limits throughput to the capacity of a single node — the network can only process as many transactions as a single validator can handle.
Sharding breaks this constraint by partitioning the network into groups of validators, each responsible for a specific shard. Transactions are assigned to shards based on criteria such as the sender’s address, the smart contract being called, or a random assignment function. Validators within each shard process only the transactions assigned to their shard, enabling parallel transaction processing across the network.
The state of the network is similarly partitioned, with each shard maintaining only the portion of the global state relevant to its transactions. A shard processing transactions for accounts with addresses beginning with “0x0” through “0x3” would maintain the state for those accounts, while another shard handles “0x4” through “0x7”, and so on.
Each shard runs its own consensus mechanism to agree on the ordering and validity of transactions within the shard. The security of each shard depends on the number and distribution of validators assigned to it — a shard with too few validators would be vulnerable to attack by an adversary who concentrates resources on that shard.
Cross-Shard Communication
The most significant technical challenge in sharding is cross-shard communication — enabling transactions that involve state on multiple shards. If a user on shard A wants to send tokens to a user on shard B, the transaction must be coordinated across both shards to ensure atomicity (both the debit on shard A and the credit on shard B complete, or neither does).
Several approaches to cross-shard communication have been developed. Asynchronous cross-shard transactions process the source shard component first, producing a receipt that is later consumed by the destination shard. This approach is simpler to implement but introduces latency, as the transaction is not fully complete until both shards have processed their respective components.
Synchronous cross-shard transactions attempt to process both shard components simultaneously, using locking or reservation mechanisms to ensure atomicity. This approach reduces latency but introduces complexity and potential for deadlocks when multiple cross-shard transactions compete for the same state.
Relay chains serve as coordination layers that manage cross-shard communication, routing messages between shards and ensuring the consistency of cross-shard state transitions. Polkadot’s relay chain and Cosmos’s inter-blockchain communication (IBC) protocol are examples of coordination mechanisms that facilitate cross-shard (or cross-chain) interaction.
Data Availability
Data availability is a critical concern in sharded systems. Each shard stores only its own portion of the global state, which means that the complete state of the network is distributed across all shards. If a shard withholds its data — either through malice or failure — the affected portion of the global state becomes inaccessible, potentially disrupting transactions and preventing verification.
Data availability sampling (DAS) is a technique that addresses this concern by enabling validators to probabilistically verify that a shard’s data is available without downloading the entire dataset. Validators sample random portions of the shard’s data and check their availability, with the probability of detecting data withholding increasing with the number of samples. If a shard cannot provide the requested samples, the network treats its data as unavailable and takes corrective action.
Ethereum’s Sharding Approach
Ethereum’s sharding strategy has evolved significantly from its original vision. The initial plan envisioned multiple execution shards, each processing smart contract transactions independently. The current approach, known as danksharding, focuses on data availability sharding rather than execution sharding.
In the danksharding model, shards provide additional data bandwidth for rollups rather than executing transactions directly. Rollups process transactions off-chain and post compressed transaction data to the sharded data layer, where it is available for fraud proofs (optimistic rollups) or validity verification (zk-rollups). This rollup-centric approach concentrates execution in the Layer 2 environment while using sharding to expand the data capacity of Layer 1.
Proto-danksharding (EIP-4844), an intermediate step toward full danksharding, introduced blob transactions — a new transaction type that carries large data payloads at reduced cost — providing immediate scalability benefits for rollups.
Relevance to Swiss Institutional DLT
For Swiss institutional applications, sharding is primarily relevant as a scalability mechanism for the public blockchain networks that underpin tokenised assets, decentralised finance, and interoperability infrastructure. The scalability requirements of Swiss financial market infrastructure are substantial, and sharding — whether in its execution or data availability form — contributes to meeting these requirements.
Permissioned institutional DLT networks may also employ sharding-like partitioning to improve throughput and manage data access. In a consortium network serving multiple institutions, transactions can be partitioned by business line, geography, or counterparty, with each partition processed independently while maintaining the ability to settle cross-partition transactions.
The security implications of sharding — particularly the risk of shard takeover by an adversary who concentrates resources on a single shard — must be assessed by Swiss institutional users evaluating DLT platforms that employ sharding. The validator rotation mechanisms, economic security thresholds, and data availability guarantees of the sharding implementation determine whether it meets the resilience requirements applicable to institutional infrastructure.
Donovan Vanderbilt is a contributing editor at ZUG DLT, covering distributed ledger technology law, regulation, and institutional adoption from Zurich. The Vanderbilt Portfolio AG provides research and analysis on Swiss digital asset infrastructure.