The discussion around scalability remains a central topic within the cryptocurrency community. Incidents such as the CryptoKitties congestion, which brought the Ethereum network to a standstill for days, highlighted a crucial reality: major public blockchains in their current form cannot scale effectively.
So what approaches is the community adopting? Two primary solutions have emerged. The first involves off-chain methods, also known as Layer 2 scaling, where certain transactions are processed outside the main blockchain, interacting with it only when necessary. The second approach involves fundamental changes to the protocol's design to tackle inherent issues of parallel processing. Unfortunately, many protocol developers often find these challenges daunting.
Even though Ethereum is still in its early stages, the community includes many technically skilled individuals, and innovation is occurring at an astonishing pace. It’s easy to assume that only the most expert developers are qualified to tackle major issues like scalability—but this mindset can be limiting. The truth is, the community is eager to assist anyone willing to contribute, including you! This article breaks down the sharding approach currently being developed by Ethereum’s core team, addresses existing limitations, and explores pathways for improvement. By the end, you'll have a solid foundation to explore the topic further. Who knows—you might even build the first sharding client!
With the number of transactions on Ethereum continually rising, the need for scaling is urgent. Let’s dive in.
What Is Sharding?
Currently, every node operating on the Ethereum network must process every transaction broadcast across the system. This design offers high security through extensive validation of each block, but it also means the entire blockchain can only operate as fast as a single node—not the combined power of all nodes. At present, transactions on the Ethereum Virtual Machine (EVM) are not parallelized; each is executed serially across the entire network.
This leads to what is known as the blockchain trilemma: a blockchain can have at most two of the following three properties:
- Decentralization
- Scalability
- Security
So how can we break this trilemma to incorporate scalability into the current model? Can’t we just increase block size or, in Ethereum’s case, raise the gas limit to improve throughput? While that might work in theory, increasing these parameters also raises the hardware requirements for running nodes. This could lead to greater centralization, as only those with high-performance machines could participate—ultimately creating higher barriers to entry.
A more intelligent approach is the concept of blockchain sharding. This involves partitioning the entire state of the network into smaller segments called shards, each maintaining its own independent state and transaction history. In such a system, specific nodes process transactions only for specific shards, allowing the overall transaction throughput across all shards to be much higher than what's possible on a single chain (as is the case today).
Before we explore how a sharded blockchain operates in practice, let’s review some essential terminology:
- State: The complete set of information that describes the system at any point in time. In Ethereum, this refers to the current balances, smart contract code, and nonces associated with each account. Each transaction transforms the current state into a new state.
- Transaction: An action initiated by a user that alters the system’s state.
- Merkle Tree: A data structure that cryptographically hashes large amounts of data. Merkle trees allow efficient and secure verification of whether a specific piece of data is part of the structure.
- Receipt: A byproduct of a transaction that is not stored in the system state but is maintained in a Merkle tree for easy verification. For example, Ethereum’s smart contract logs are stored as receipts in a Merkle tree.
With these concepts in mind, let’s examine how Ethereum 2.0 is designed to work.
How Ethereum Sharding Works
A sidechain called the Beacon Chain will be created, which stores its block hashes on the main chain. This sidechain will operate as a pure Proof-of-Stake system implementing Casper FFG (Friendly Finality Gadget). It will also provide a distributed source of randomness, enabling the construction of a sharding framework on top.
One significant challenge in sharded blockchains is the risk of single-shard takeover attacks, where an attacker gains control of the majority of validators in one shard to submit invalid collation blocks. How can this be mitigated?
Ethereum’s Sharding FAQ suggests randomly sampling validators for each shard. This prevents validators from knowing in advance which shard they will be assigned to. Each shard is allocated a large pool of validators, and the subset that actually validates transactions is chosen randomly from this pool.
First, a Validator Registration Contract will be deployed on the main chain. Users will burn 32 ETH to become validators on the sidechain. The Beacon Chain will periodically check registered validators, queuing those who have burned ETH. This chain will serve as the coordination mechanism for the sharding system, providing distributed pseudorandomness essential for selecting validator committees for each shard. The randomness must be public and verifiable to ensure the sampling is mandatory and cannot be manipulated.
Within each shard, certain nodes known as proposers will be responsible for creating cross-links on the Beacon Chain. These cross-links are special structures containing vital information about the shard.
A typical cross-link includes:
- Identification of the shard (e.g., Shard 10)
- The latest state of the shard before transactions are applied
- The new state of the shard after transactions are applied
- Digital signatures from at least two-thirds of the collators in the shard, confirming the validity of the shard block
But what happens when transactions occur across shards? For example, if I send funds from an address in Shard 1 to an address in Shard 10, how is this handled? The ability for cross-shard communication is critical—otherwise, the system offers little innovation.
One proposed method uses receipts. Here’s how a cross-shard transaction could work:
- A transaction is sent on Shard 1, deducting 100 ETH from Raul’s balance.
- A receipt—not stored in the state but in a Merkle tree—is created and easily verifiable.
- A transaction including the Merkle receipt as data is sent to Shard 10. Shard 10 checks whether the receipt has not yet been spent.
- Shard 10 processes the transaction, adding 100 ETH to Jim’s balance. It also records that the receipt from Shard 1 has been spent.
- Shard 10 generates a new receipt that can be used in future transactions.
This may sound complex, but the good news is that these mechanics will be handled at the protocol level. For Solidity developers and end-users, the experience will remain largely unchanged. Sharding will operate behind the scenes, allowing developers to continue their workflows without needing to understand the underlying complexity.
Beyond Scaling: Super-Quadratic Sharding and Exponential Growth
Looking further ahead, Ethereum may implement super-quadratic sharding—essentially a system of shards within shards. While this adds significant complexity, the potential for scalability is enormous. Such an architecture could drive transaction costs down to negligible levels and provide a more versatile foundation for a new generation of applications.
Frequently Asked Questions
What is the main goal of sharding?
Sharding aims to significantly improve Ethereum’s transaction throughput by partitioning the network into smaller, manageable pieces called shards. Each shard processes its own transactions, enabling parallel processing and higher overall capacity.
How does sharding enhance security?
Validators are randomly assigned to shards, reducing the risk of malicious takeovers. The use of cross-links and cryptographic proofs ensures that only valid state transitions are committed across shards.
Will developers need to rewrite smart contracts for sharding?
No. Sharding is implemented at the protocol level and is designed to be backward-compatible. Developers can continue writing smart contracts as they do today, without any changes required.
What is the Beacon Chain’s role?
The Beacon Chain coordinates the entire sharding system, managing validators, generating randomness for shard assignment, and ensuring consensus across shards via cross-links.
How are cross-shard transactions handled?
Cross-shard transactions use receipts stored in Merkle trees. These receipts are verified between shards to ensure assets can be moved securely without double-spending.
When will sharding be fully implemented on Ethereum?
Sharding is part of the Ethereum 2.0 roadmap, which is being rolled out in phases. Full implementation is expected to take place over the next few years, following thorough testing and community consensus.
Getting Started with Sharding
Interested in contributing? Start by exploring the Beacon Chain, which will serve as the backbone of Ethereum’s Proof-of-Stake and sharding system. This chain will manage validators, perform global sampling, and maintain consistency across all shard states.
For those looking to delve deeper, the following resources are invaluable:
- The official Ethereum Sharding FAQ provides a comprehensive overview of concepts and implementation details.
- Explore Go-language implementations of sharding to understand low-level mechanics.
- Research summaries and specs offer updated insights into ongoing developments and architectural plans.
👉 Explore advanced scaling strategies
The evolution toward a scalable Ethereum is a collective effort. By understanding the principles of sharding, you’re better equipped to participate in—or even lead—the next wave of blockchain innovation.