--- title: "Sharding" path: "/contents/tech/core-concepts/sharding" bannerImage: "https://j9ytchrzkvqpcul7.public.blob.vercel-storage.com/e422e714-5031-4217-8839-9c0639213561.jpg" version: "1.2.0" author: "Hydrate" createdAt: "2026-02-03T14:15:59.077Z" updatedAt: "2026-03-16T18:25:43.979Z" --- # Sharding **Sharding** [ /ˈʃɑːdɪŋ/ ] is a method of [partitioning a database](https://www.mongodb.com/docs/manual/sharding/) [horizontally](https://towardsdatascience.com/database-terminologies-partitioning-f91683901716) across separate servers to improve scalability, performance and data availability. In the context of DLTs, sharding refers to the process of [dividing the network's computational and storage workload across multiple smaller groups of nodes](https://www.radixdlt.com/blog/sharding-in-radix), called shards, each responsible for processing a subset of the network's transactions and storing a portion of the global state. ## Background The primary goal of sharding in DLTs is to [increase the overall throughput and capacity of the network](https://vitalik.eth.limo/general/2021/04/07/sharding.html) without sacrificing decentralization or security. By allowing multiple shards to process transactions in parallel, sharding aims to overcome the limitations of ‘full replication’ where [every node must process and store all transactions](https://vitalik.eth.limo/general/2021/04/07/sharding.html). Sharding has gained significant attention in the blockchain community as a potential solution to the [scalability trilemma](/contents/tech/core-concepts/blockchain-trilemma), which posits that blockchain systems can only achieve two out of three desirable properties: scalability, security, and decentralization. By implementing sharding, projects such as NEAR, MultiversX and Radix aim to maintain high levels of security and decentralization while dramatically improving scalability. The concept of sharding in DLTs extends beyond simply partitioning data; it encompasses complex mechanisms for [ensuring data availability, cross-shard communication, and maintaining overall network consistency](https://www.radixdlt.com/blog/breakthrough-in-consensus-theory-scaling-defi-without-breaking-composability). ## Technical Fundamentals Sharding is a concept borrowed from traditional database systems and adapted for use in distributed ledger technology. ### Database Sharding In traditional database systems, [sharding is a method for distributing data across multiple machines](https://www.mongodb.com/docs/manual/sharding/). It involves breaking a large database into smaller, more manageable partitions called shards. Each shard contains a subset of the data and is stored on a separate server. This approach allows for horizontal scaling, where additional servers can be added to increase capacity and performance. There are two main types of database sharding: 1. $1 2. $1 ### Application to Blockchain and Distributed Ledgers In the context of blockchain and distributed ledgers, sharding involves [dividing the network's computational and storage workload across multiple smaller groups of nodes](https://www.radixdlt.com/blog/sharding-in-radix), each responsible for processing a subset of the network's transactions and storing a portion of the global state. The key difference in blockchain sharding is that it must maintain the security and decentralization properties of the network while improving scalability. This involves complex mechanisms for ensuring data availability, cross-shard communication, and maintaining overall network consistency. [Radix, for example, implements a unique approach called "pre-sharding"](https://www.radixdlt.com/blog/sharding-in-radix), where the network launches with a maximum number of shards (2^64 or approximately 18.4 quintillion) already in place. This allows for future scalability without needing to change the fundamental structure of the network as it grows. ### Key Goals: Scalability, Decentralization, Security The primary objectives of implementing sharding in distributed ledgers are: 1. $1 2. $1 3. $1 The challenge in implementing sharding lies in achieving all three of these goals simultaneously, effectively addressing the scalability trilemma that has long plagued blockchain networks. ## Types of Sharding Sharding in distributed ledger technology can be implemented in various ways, each focusing on different aspects of the network's operation. The main types of sharding are network sharding, transaction sharding, and state sharding. These approaches can be used individually or in combination to achieve the desired scalability improvements. ### Network Sharding Network sharding involves [dividing the network nodes into smaller groups, each responsible for a subset of the network's tasks](https://www.radixdlt.com/blog/sharding-in-radix). In this approach, nodes within a shard communicate more frequently with each other than with nodes in other shards. This can reduce the overall network communication overhead and improve efficiency. Radix, for example, implements a form of network sharding where [each node maintains as many shards as it can handle, dropping shards that are too resource-intensive](https://www.radixdlt.com/blog/sharding-in-radix). This allows even low-powered devices to participate in the network, promoting decentralization. ### Transaction Sharding Transaction sharding involves [distributing the processing of transactions across different shards](https://vitalik.eth.limo/general/2021/04/07/sharding.html). In this approach, each shard is responsible for processing a subset of the total transactions in the network. This allows for parallel processing of transactions, potentially increasing the overall throughput of the network. One challenge with transaction sharding is ensuring that [transactions that depend on each other or affect the same state are processed correctly](https://www.radixdlt.com/blog/sharding-in-radix). Radix addresses this by using a deterministic process to assign transactions to shards based on the public keys involved, ensuring that related transactions are always processed in the same shard. ### State Sharding State sharding is perhaps the most complex form of sharding. It involves [dividing the global state of the network (i.e., the full record of all accounts and their data) across multiple shards](https://vitalik.eth.limo/general/2021/04/07/sharding.html). Each shard maintains only a portion of the global state, which can significantly reduce the storage and computational requirements for individual nodes. However, state sharding introduces challenges in cross-shard communication and maintaining consistency across the network. [Ethereum 2.0's sharding plan](https://vitalik.eth.limo/general/2024/05/23/l2exec.html), for instance, initially focused on data sharding rather than full state sharding to mitigate some of these challenges. The implementation of state sharding often requires sophisticated techniques such as [fraud proofs or zero-knowledge proofs (ZK-SNARKs) to ensure the validity of cross-shard transactions](https://vitalik.eth.limo/general/2021/04/07/sharding.html) and maintain the overall security of the network. ## Security Considerations While sharding offers significant scalability benefits for distributed ledger systems, it also introduces new security challenges that must be carefully addressed. This section explores the key security considerations in sharded systems and the solutions proposed to mitigate these risks. ### **Single-Shard Takeover** One of the primary security concerns in sharded systems is the potential for an attacker to take over a single shard. In a traditional blockchain, an attacker typically needs to control a majority of the network's resources to carry out an attack. However, in a sharded system, [an attacker might only need to control a majority within a single shard to cause damage](https://vitalik.eth.limo/general/2021/04/07/sharding.html). [Random sampling for validator assignment](https://vitalik.eth.limo/general/2021/04/07/sharding.html) has been suggested to prevent targeted attacks on specific shards. ### **Data Availability** Ensuring data availability is crucial in sharded systems. If data becomes unavailable, it can lead to [stalled chains or even allow for ransom attacks on specific user data](https://vitalik.eth.limo/general/2021/04/07/sharding.html). This is particularly challenging in a sharded environment where not all nodes have access to all data. Proposed solutions are: 1. $1 2. $1 ### **Cross-Shard Transaction Atomicity** Maintaining atomicity for transactions that span multiple shards is a significant challenge. [Ensuring that all parts of a cross-shard transaction are executed correctly or all fail](https://www.radixdlt.com/blog/breakthrough-in-consensus-theory-scaling-defi-without-breaking-composability) is crucial for preserving the integrity of the system. Different projects have proposed various solutions: 1. $1 2. $1 These mechanisms aim to ensure that cross-shard transactions are executed correctly and atomically, maintaining the consistency of the overall system. ### **Adaptive Adversaries** Sharded systems can be vulnerable to adaptive adversaries who can quickly [compromise or shut down specific nodes in real-time](https://vitalik.eth.limo/general/2021/04/07/sharding.html). This poses a particular threat to systems that rely solely on committees for security. ## History and Development The concept of sharding in distributed ledgers has evolved significantly over time, with various approaches proposed and refined to address the scalability challenges of blockchain networks. This section traces the history and development of sharding from early proposals to modern implementations. ### Early Proposals (2015-2017) The idea of applying sharding to blockchain systems began to gain traction in the mid-2010s: - In 2015, a team at the National University of Singapore (NUS) [proposed an early Byzantine Fault Tolerant (BFT) sharding approach](https://vitalik.eth.limo/general/2021/04/07/sharding.html#what-are-some-moderately-simple-but-only-partial-ways-of-solving-the-scalability-problem). - [Ethereum](https://ethereum.org)'s Vitalik Buterin [started discussing sharding concepts for Ethereum as early as 2016](https://vitalik.eth.limo/general/2021/04/07/sharding.html#improving-sharding-with-better-security-models). - Other early conceptual work included proposals like ["puzzle towers" by Dominic Williams](https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html#how-do-you-actually-do-this-sampling-in-proof-of-work-and-in-proof-of-stake), which aimed to combine proof-of-work with sharding. These early proposals often [focused on sharding either transaction processing or state, but not both](https://vitalik.eth.limo/general/2021/04/07/sharding.html#what-are-some-moderately-simple-but-only-partial-ways-of-solving-the-scalability-problem), which limited their potential scalability gains. ### Evolution of Approaches (2018-2020) As research in sharding progressed, more comprehensive approaches began to emerge: - Radix's initial consensus protocol, [Tempo](/contents/tech/research/tempo-consensus-mechanism), was [designed to be sharded from the start](https://www.radixdlt.com/blog/tempo-consensus-lessons-learned). It used a novel approach called "logical clocks" for consensus. - Zilliqa, launched in 2019, [implemented a form of transaction sharding](https://vitalik.eth.limo/general/2021/04/07/sharding.html#what-are-some-moderately-simple-but-only-partial-ways-of-solving-the-scalability-problem). - The concept of ["quadratic sharding" was developed](https://vitalik.eth.limo/general/2021/04/07/sharding.html#sharding-through-random-sampling), aiming to scale both processing power and storage capacity. - Researchers began to address key challenges such as [cross-shard transactions and data availability](https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html#how-can-we-facilitate-cross-shard-communication). During this period, [the focus shifted towards creating more secure sharding models that could maintain decentralization](https://vitalik.eth.limo/general/2021/04/07/sharding.html#improving-sharding-with-better-security-models). This included the development of techniques like: - [Data availability sampling](https://vitalik.eth.limo/general/2021/04/07/sharding.html#scalable-verification-of-data-availability) - [Fraud proofs and zero-knowledge proofs for scalable verification](https://vitalik.eth.limo/general/2021/04/07/sharding.html#scalable-verification-of-computation) ### Modern Implementations (2021-present) Recent years have seen more concrete implementations and refined approaches to sharding: - [Ethereum 2.0](https://vitalik.eth.limo/general/2021/04/07/sharding.html) initially focused on data sharding rather than computation sharding. [The original plan involved creating 64 separate shard chains](https://vitalik.eth.limo/general/2021/04/07/sharding.html), each capable of processing transactions and smart contracts independently. - [Other projects like Near Protocol have implemented their own versions of sharding](https://vitalik.eth.limo/general/2021/04/07/sharding.html#recap-how-are-we-ensuring-everything-is-correct-again). Modern sharding approaches often combine multiple techniques to achieve scalability while maintaining security: - [Using committees with random sampling for shard management](https://vitalik.eth.limo/general/2021/04/07/sharding.html#sharding-through-random-sampling) - [Implementing cross-shard communication protocols](https://vitalik.eth.limo/general/2017/12/31/sharding_faq.html#how-would-synchronous-cross-shard-messages-work) - [Leveraging Layer 2 solutions like rollups in conjunction with sharding](https://vitalik.eth.limo/general/2021/04/07/sharding.html#recap-how-are-we-ensuring-everything-is-correct-again) ## Sharding in Radix Radix has developed an integrated sharding and consensus architecture specifically designed for hyper-scalability of its decentralized network. In Radix’s case, sharding applies to both data availability and transaction execution as both functions are performed by nodes. ### Ledger **Pre-Sharding** The current [Radix Mainnet (Babylon)](/contents/tech/releases/radix-mainnet-babylon) is sharded into a fixed number of [2^256](https://www.talkcrypto.org/blog/2019/04/08/all-you-need-to-know-about-2256/) shards. Responsibility for validating shards is undertaken by groups of validators called [shard groups](/contents/tech/core-concepts/shard-groups), which [may grow or shrink dynamically in response to load demand](https://youtu.be/FZWT3j9XHMI). Currently, the number of shard groups is capped at one but this will be lifted with Radix’s forthcoming [Xi’an](/contents/tech/releases/radix-mainnet-xian) release. Pre-sharding is in contrast to the [dynamic adaptive state sharding](https://coinmarketcap.com/academy/glossary/adaptive-state-sharding) model adopted by Shardeum, MultiversX, and NEAR, where shards are added incrementally as required. While sharding can improve scalability, an ad hoc approach to sharding leads to substantial difficulties as any changes to the shard structure require reorganizing the entire network - a time consuming and expensive process. The larger the sharded ledger grows, the more problematic this becomes. Ad hoc sharding also complicates queries and data lookups within the ledger. By sharding the data randomly, it becomes much harder to locate specific transactions or data points since they could be stored anywhere. This slows down queries as more extensive searches are required. ### **Deterministic Shard Indexing** Shards on Radix are indexed deterministically by public keys. This means that the shard index for any address can be calculated by taking the [modulo](https://en.wikipedia.org/wiki/Modulo) of the public key over the shard space. si=mod piSs=shard indexp=public keyS=total shard spacesi​=Smodpi​​s=shardindexp=publickeyS=totalshardspace​ By deterministically grouping related data into the same shard, Radix avoids the need for expensive data reorganization as the network grows. This creates four major advantages: 1. $1 2. $1 3. $1 4. $1 ### Network Security A key challenge in sharding distributed ledgers is ensuring sufficient security and node coverage across all shards. If some shards have much fewer nodes than others, it creates vulnerabilities. Radix employs several techniques to maintain security across its sharded network: 1. $1 2. $1 3. $1 4. $1 Together, these mechanisms ensure Radix can securely scale to an exponentially growing shard space without running into coverage gaps or centralization issues. The network organically self-regulates to distribute validation across shards. ### **[Cerberus Consensus](https://arxiv.org/abs/2008.04450)** *Main article: *[*Cerberus*](/contents/tech/core-protocols/cerberus-consensus-protocol) Radix's [Cerberus consensus](https://learn.radixdlt.com/article/what-is-cerberus) protocol introduces ‘braided’ sharding to [atomically compose](/contents/tech/core-concepts/atomic-composability) transactions across shards. Cerberus shards transaction validation while braiding validation across shards to enforce system-wide transaction ordering and prevent double-spending. This unique braided architecture ensures that Radix can securely scale transaction throughput across a sharded network of effectively unlimited size.