You are reading an excerpt from our free but shortened abridged report! While still packed with incredible research and data, for just $20/month you can upgrade to our FULL library of 50+ reports (including this one) and complete industry-leading analysis on the top crypto assets. 

Becoming a Premium member means enjoying all the perks of a Basic membership PLUS:

• Full-length CORE Reports: More technical, in-depth research, actionable insights, and potential market alpha for serious crypto users
• Early access to future CORE ratings: Being early is sometimes just as important as being right!
• Premium Member CORE+ Reports: Coverage on the top issues pertaining to crypto users like bridge security, layer two solutions, DeFi plays, and more
• CORE report Audio playback: Don’t want to read? No problem! Listen on the go.

Sharding 101

Sharding is the term for horizontally partitioning a database and does not create more burden for the average user. In this sharding model, validators are assigned to specific shards and only process and validate transactions in that shard. In Ethereum's planned sharding model, validators are randomly selected. Every shard has a (pseudo) randomly-chosen committee of validators that ensures it is (nearly) impossible for an attacker controlling less than ⅓ of all validators to attack a single shard. 

​​After the switch to Proof-of-Stake, sharding is the next significant hard fork upgrade on Ethereum’s roadmap. Just like the Merge, the sharding plan has evolved over time and may continue to change between now and implementation. 

Sharding is the partitioning of a database (or blockchain) into subsections. Rather than building layers atop one another (e.g. L2s or Bitcoin’s Lightning Network), sharding scales out or horizontally without a hierarchy or layered structure. Doing so does not create more burden for the average user. 

Original diagram by Hsiao-wei Wang, design by Quantstamp

Shards will be divided among nodes so that every individual node is doing less work. But collectively, all of the necessary work is getting done—and more quickly. More than one node will process each individual data unit, but no single node has to process all of the data anymore. 

To further grok a sharded blockchain architecture, it is critical to understand the role nodes play in a blockchain and the resource burden over time. Nodes (typically) perform three tasks in a decentralized blockchain:

1. Compute: Process new transactions
2. Consensus: Relay valid blocks to the other nodes in the network
3. Storage: Store the state/history of the entire network 

However, each of these activities places an increasing demand on nodes. As the volume of transactions increases, more computing power is required to process them. Relaying transactions and blocks increases network bandwidth requirements. As the amount of data to store increases, more storage is required.

In sharded blockchains, each shard stores only its local state and only relays transactions associated with its state. While this does reduce the resource load on nodes and improves scalability, it introduces increased complexity in the form of cross-shard interoperability. All the shards must know where all/specific states reside at all times and coordinate in validator selection/slashing. Designs like Ethereum and Polkadot have a Beacon/Relay chain at the center to help coordinate these things.

Complications with Sharded Designs

A significant advantage of sharding is the reduction in storage requirements for each node, since validators need only store information pertaining to their assigned shard rather than the entire blockchain state. This could potentially lower the barriers to node operation, allowing a broader user base to participate in network validation processes, thereby enhancing decentralization.

However, the implementation of blockchain sharding necessitates critical decision-making in several areas:

1. Partitioning Logic: Sharding a blockchain extends beyond the simplistic division of applications across different shards. One must decide whether to distribute only transaction processing or to include the storage of distinct portions of the blockchain's state within the shards' responsibilities.

2. Collation: Aggregating the data from various shards into a cohesive whole presents another challenge. This assembly might occur on a beacon chain or a similar overarching structure. The economic aspect of recording shard block information is also paramount to consider.

3. Communication: Inter-shard data and asset transfer is another pivotal concern. Consider a scenario where an individual needs to interact with a decentralized application (dApp) residing on a different shard than their account. Facilitating such cross-shard transactions is crucial for user experience and network functionality.

The primary models to address these challenges are synchronous and asynchronous sharding. Synchronous sharding necessitates that transactions involving multiple shards be processed concurrently or within the same timeframe. Asynchronous sharding, conversely, allows the originating shard to process the transaction first, followed by the recipient shard processing the confirmation and crediting the transaction thereafter.

Lastly, security considerations are paramount. A shard, by virtue of having fewer validators than the entire blockchain, is inherently more susceptible to attacks. What would require a majority control in an unsharded blockchain translates to a much smaller number in a sharded environment, raising the stakes for maintaining robust security protocols within each shard.

Understanding the intricacies of sharding is essential for stakeholders within the blockchain industry. These decisions impact not only the scalability and efficiency of a blockchain but also its robustness and decentralization—key qualities that define the value and trustworthiness of blockchain networks.

Homogenous Execution Sharding

In the realm of blockchain technology, strategies to amplify the capabilities of networks are of paramount importance. Homogeneous execution sharding emerges as one such strategy, distinguished by its potential to enhance throughput and network capacity. This methodology divides the blockchain's transaction processing labor across a multitude of smaller, autonomous units known as shards. These shards independently process transactions and manage their discrete state, operating concurrently to foster parallel transaction execution. The overarching aim is to escalate network capacity and expedite transaction processing.

NEAR

Prominent alternative Layer 1 (Alt-L1) chains such as NEAR have integrated homogenous execution sharding. NEAR, in particular, employs a variant known as Nightshade, which distributes the transaction processing task among various validator subsets. This system enables each shard to generate segments of the forthcoming block—referred to as chunks—that are subsequently incorporated and solidified within the NEAR main blockchain.

  Simplified Visualization of Execution Sharding.

Nightshade takes a step away from the Beacon Chain model of sharding. In Beacon chains, multiple blockchains are secured by different validators, with each chain being its shard. This creates separation within the overall security of the total system as validators are separated per chain (shard). So, if there are 10 shards in a system with each shard having its validator, to achieve the same level of security as a non-sharded chain, each shard requires 10x the validators.

Contrasting Beacon Chain and Nightshade. Source: NEAR Protocol

Instead, Nightshade operates as a single blockchain, as each block contains all transactions from all shards while simultaneously adjusting all shards' whole states. No one node downloads the full state of the network. This is how the NEAR protocol performs dynamic sharding.

This has three advantages that benefit NEAR:

• There’s less opportunity for the network to fork, granting higher security
• The network operates faster as participants are only responsible for their shards
• Increased cross-shard composability

Nightshade lists the transactions within a block and splits them into chunks (one chunk:one shard). Generally, NEAR ideally has one chunk per block, though it's possible that chunks are missing due to network delays. This functionality corresponds with DoomSlug in ensuring that blocks can still be validated and added to the chain even when data is missing.

Despite the apparent efficiency gains, homogeneous execution sharding is not without its drawbacks. Notably, it poses security concerns as the network becomes fragmented into smaller validator subsets, potentially compromising network decentralization. Additionally, the reduction in economic value at stake for individual shards could pose a risk to the network's crypto-economic security.

As we explore the implications of such technologies, it is crucial to adopt a critical lens. While scalability solutions like homogeneous execution sharding offer promising avenues for enhancing network performance, they must be carefully weighed against potential security vulnerabilities. The cryptocurrency community must continue to scrutinize and refine these technologies, ensuring that scalability does not come at the expense of the foundational principles of security and decentralization that underpin blockchain technology.

Heterogenous Execution Sharding

The evolution of blockchain technology has given rise to innovative scaling solutions, among which heterogeneous execution sharding stands out. This approach interlinks multiple independent blockchains—each with distinct consensus protocols, state models, and functionalities—into a single interoperable network. By doing so, it allows each individual blockchain to preserve its unique features while potentially leveraging the security and scalability of the larger ecosystem. Polkadot (v1) and Cosmos are two notable projects that implement this advanced design.

Polkadot

Polkadot's (v1) infrastructure exemplifies heterogeneous execution sharding, comprising a central Relay Chain, various Parachains, and Bridges to ensure interoperability and communication across different blockchains. The Relay Chain is the backbone of the Polkadot network, overseeing security, consensus, and cross-chain transactions. Validators on this chain are pivotal, tasked with transaction validation and block production.

Parachains are autonomous blockchains tethered to the Relay Chain, reaping the benefits of its security and consensus capabilities while retaining the autonomy to operate with their own state models and consensus algorithms. These Parachains are designed to serve specific use cases through their customized functionalities.

The Bridges in the Polkadot framework facilitate connections to external blockchains, such as Ethereum, allowing for seamless asset transfers and communication between these networks and Polkadot.

The Polkadot network facilitates cross-chain communication and enables interoperability by connecting multiple blockchains into one unified network. There is the main Relay chain and subsequent Parachains.

Source: Messari

Polkadot’s goal is to use an asynchronous heterogeneous network model to scale horizontally. Blockchains are designed for specific applications and run on different virtual machines. Polkadot allows these blockchains to interoperate when needed. Developers can use the Polkadot infrastructure to create custom blockchains that have a larger design space for decentralized applications and assets. Building your project on a custom blockchain has three fundamental advantages over designing it as a set of smart contracts. 

1. Isolating the custom blockchain from other chains increases performance. It’s not bogged down by unrelated activity on the network. When needed, you can bridge to the other chains.
2. Minimizes and makes fees predictable. You can design a customizable fee structure for your blockchain applications. This minimizes transaction risk from high traffic levels on the Polkadot network. This is critical for mainstream adoption, as high fees are one of the barriers to entry for using permissionless networks.
3. Validators can be customized for your blockchain. This can help your chain be compliant in regulated jurisdictions like the EU where GDPR applies. You can set the validators to have high-performance hardware requirements or use specific proofs to qualify as validators.

A distinctive aspect of Polkadot is its Nominated Proof-of-Stake (NPoS) consensus mechanism on the Relay Chain, which enhances network security. Validators on this chain are elected by the community stakeholders and are responsible for validating transactions and creating blocks. Parachains, on the other hand, are at liberty to employ varying consensus mechanisms, managed by entities known as collators, to meet their individual needs. A crucial attribute of Polkadot’s architecture is the shared security model where all parachains collectively benefit from the robust security protocols of the Relay Chain.

Understanding the architecture and functionality of such advanced blockchain scaling solutions is essential for stakeholders in the cryptocurrency space. These mechanisms are designed not only to scale the networks but also to maintain interoperability, security, and decentralization, aligning with the core tenets of blockchain technology. As the ecosystem continues to mature, the exploration and refinement of these solutions remain a critical focus for developers and investors alike.

Cosmos

The Cosmos Hub is a PoS chain that serves as the primary hub for routing transactions and data between Cosmos blockchains called zones. Hubs are the largest, most liquid zones in the ecosystem.  Zones are application-specific chains built using Cosmos SDK. Using the hub and zone model, any zone can send information to a connected hub, and then that hub can send the information to any of the other connected zones. Because hubs act as routers or middlemen between zones, they are also responsible for maintaining the global state (token balances) across all Zones.

Image credit: Cosmos website 

Zones plug into hubs, which route and validate the transactions passed between different zones in exchange for fees. They connect to a Hub via a two-way peg, similar to Ethereum and side chains like Polygon. When a valid cross-chain transaction is submitted on the IBC, the token on the original chain is (essentially) frozen/burned while the receiving chain mints the equivalent amount on new tokens. 

Image credit: Cosmos blog

The primary limitation in Cosmos’ architecture is this lack of shared security, making zones vulnerable. For example, a token pegged from one app-chain to another via IBC can be stolen by a malicious majority of source-chain validators. This issue aims to be addressed with the introduction of Interchain Security (discussed later) sometime in 2022/2023.

Cosmos' protocol architecture prioritizes app-chain sovereignty and purposely diminishes the role and power of the Cosmos Hub. With this design, the Cosmos ecosystem ensures continuity across all chains and removes a single point of failure. With several hubs, the failure of one would not be sufficient to bring down the entire system.