Cross-Shard Communication

Transactions between shards are not atomic; they execute in distinct, non-overlapping steps. A typical flow involves:

• Locking or burning an asset on the source shard.
• Proving the action via a cross-link or receipt.
• Unlocking or minting the corresponding asset on the destination shard. This introduces latency but is essential for maintaining shard independence and scalability.

Shards must cryptographically prove the state of a transaction to other shards. This is often achieved via:

• Merkle Proofs: Lightweight proofs of inclusion in a shard's block header.
• Cross-Links: Periodically committed summaries of a shard's state to a central beacon chain or main chain, which acts as the trust anchor for all communication. The beacon chain does not process transactions but secures the system by finalizing shard block headers.

Two primary models define how shards interact:

• Synchronous Calls: The calling shard pauses until a response is received from the destination shard (complex and rare due to latency).
• Asynchronous Messages: The dominant model. A contract on Shard A sends a message (e.g., a receipt) that a contract on Shard B can later act upon. This is analogous to inter-process communication (IPC) in distributed systems.

Achieving atomic cross-shard transactions (where all parts succeed or fail together) is a significant challenge. Solutions involve:

• Two-Phase Commits: A coordinator manages a prepare/commit cycle across shards.
• Hashed TimeLock Contracts (HTLCs): Used in payment channels, they enable atomic swaps by using hash locks and timeouts.
• Yanking: Some protocols allow temporarily 'yanking' state into a single shard for an atomic operation before returning it.

A receiving shard must verify that the state it's reading from another shard is available and valid. This is secured by:

• Data Availability Sampling (DAS): Light nodes randomly sample small pieces of shard data to ensure the full data is published.
• Fraud Proofs: If a node detects invalid state transitions in a shard block, it can create a succinct proof to challenge it on the beacon chain, slashing the malicious validator.

Different blockchains implement cross-shard communication with distinct architectures:

• Ethereum 2.0 (Danksharding): Uses a beacon chain for consensus and blob-carrying transactions for data availability, with execution validated via fraud proofs.
• NEAR Protocol: Uses a nightshade model where shards produce chunks that form a single block; cross-shard calls are asynchronous with a 1-2 block delay.
• Polkadot: Parachains communicate via Cross-Consensus Message Format (XCM) messages relayed through the central Relay Chain.

The most common model where shards operate independently and communicate via asynchronous message passing. A transaction on Shard A can trigger a cross-shard call, which posts a receipt or event. A separate transaction on Shard B must then be submitted to read this receipt and execute the dependent action.

• Pros: Simpler shard design, higher concurrency.
• Cons: Requires multiple steps, breaking atomicity; users must pay gas on both shards.
• Example: Ethereum's beacon chain and execution shards communicate asynchronously via the consensus layer.

A model where a single transaction can atomically read and write state across multiple shards within the same block. This requires a coordinator or a global lock manager to orchestrate the transaction's execution path.

• Pros: Provides atomic cross-shard composability, simplifying developer experience.
• Cons: Increases latency and complexity; requires shards to be tightly synchronized, which can reduce throughput.
• Example: Some research proposals, like Omniledger, use a byzantine shard atomic commit (BAC) protocol for synchronous commits.

A specific implementation of asynchronous communication where the responsibility for proving and relaying information between shards falls on the client or a relayer. The originating shard produces a state proof or receipt, which must be submitted as proof to the destination shard.

• Key Mechanism: Relies on Merkle proofs or verkle proofs to cryptographically verify the state of another shard.
• Example: Ethereum's cross-shard transactions via the beacon chain use this model, where execution clients relay proofs.

A model where dedicated smart contracts or light clients on each shard act as bridges, continuously verifying and relaying the block headers or state roots of other shards. This creates a trust-minimized communication channel.

• Function: A light client on Shard B verifies headers from Shard A, allowing Shard B's contracts to trustlessly verify events from Shard A.
• Use Case: Essential for cross-shard DeFi composability and asset transfers.
• Example: The Ethereum 2.0 design uses the beacon chain as a central state root relay for all execution shards.

A protocol guaranteeing that a transaction affecting multiple shards either succeeds on all or fails on all, preventing partial execution. This is typically achieved via a two-phase commit (2PC) protocol or similar distributed consensus mechanism.

• Process: Involves a prepare phase (locks resources) and a commit phase (executes).
• Challenge: High latency and vulnerability to shard failures during the prepare phase.
• Implementation: Complex and rarely used in production sharding due to performance trade-offs.

A modern approach where rollups (Layer 2s) act as de facto shards, and communication occurs through their shared Layer 1 settlement layer (e.g., Ethereum Mainnet). Cross-rollup communication uses the L1 as a secure messaging hub.

• Mechanism: Rollup A posts a message and proof to L1; Rollup B reads and verifies it from L1.
• Advantage: Leverages L1 security without requiring individual shards to verify each other directly.
• Examples: ZK-rollups communicating via verified state roots on L1; bridges like Nomad and Axelar use similar hub-and-spoke models.

A communication model where a transaction is finalized on the source shard before a message is sent to the destination shard. This is simpler to implement but requires complex client-side logic to manage multi-step transactions and potential failures.

• Key Trait: Transactions are not atomic across shards.
• Example: Early Ethereum 2.0 (now Ethereum) beacon chain proposals used this model for simple transfers.
• Challenge: Requires receipts or proofs to be passed between shards, and the client must track the state of a multi-shard operation.

A model where a transaction affecting multiple shards is processed and finalized atomically across all involved shards simultaneously. This provides a simpler developer experience but imposes significant coordination overhead and latency.

• Key Trait: Atomic composability across shards.
• Mechanism: Often uses a coordinator or a two-phase commit protocol.
• Drawback: Performance is limited by the slowest participating shard, reducing scalability benefits.

Ethereum's sharding design uses the beacon chain as the system's coordination and consensus layer. Cross-shard communication is facilitated through crosslinks, which are references to shard block headers included in the beacon chain.

• Mechanism: Shards publish state roots to the beacon chain. A light client on one shard can verify proofs of inclusion from another shard's state.
• Current State: The original data sharding plan evolved into Danksharding, which uses data availability sampling and blobs for scaling, with execution handled by Layer 2 rollups.

NEAR's Nightshade sharding model treats each shard (or chunk) as a part of a single logical block. Chunk-only producers create parts of the block for their specific shard, which are then aggregated into a single block by a block producer.

• Key Trait: Synchronous cross-shard transactions within a single block.
• Mechanism: All shard states are included in every block, allowing transactions to read and write to multiple shards atomically in one block finality.
• Benefit: Provides a seamless, atomic experience for developers and users.

Zilliqa implements network sharding where the network is divided into committees of nodes, each processing a subset of transactions. Cross-shard communication is handled via a DS (Directory Service) committee that coordinates the overall network state.

• Mechanism: The DS committee finalizes microblocks from each shard into a final transaction block.
• Trait: Primarily designed for scaling transaction throughput, with cross-shard calls requiring explicit messaging between shard committees.
• Legacy: One of the first production sharded blockchains.

Harmony uses a sharding architecture with a beacon chain and multiple shard chains. It employs a Kademlia-based routing for cross-shard communication, where transactions are routed directly between the relevant shards.

• Mechanism: Uses epoch-based reshuffling of validators for security. Cross-shard transactions create receipts on the source shard, which are then consumed on the destination shard.
• Focus: Emphasizes fast finality (2 seconds) and uses Verifiable Random Function (VRF) for committee selection.

A cross-shard transaction must execute atomically across multiple shards. The primary risk is partial execution, where operations succeed on one shard but fail on another, leading to inconsistent state or fund loss. This is mitigated via two-phase commit protocols or asynchronous finality mechanisms, but these add latency and complexity. For example, a DeFi swap involving assets on Shard A and Shard B could leave a user's funds locked if the transaction is not atomic.

Shards must prove to other shards that referenced data (e.g., a transaction receipt or state root) is valid and available. Data availability attacks occur when a shard withholds necessary data, preventing the verification of cross-shard messages. Solutions involve erasure coding and fraud proofs, where honest nodes can challenge invalid state transitions. The security of the entire system depends on the liveness and honesty of a sufficient number of nodes in each shard to guarantee data availability.

In a sharded system, an attacker may only need to compromise a single shard's validator set to disrupt cross-shard operations, a scenario known as a 1% attack (if the attacker controls >33% of a single shard's stake). This is less costly than attacking the entire network. Compromising a shard allows for double-spending within that shard and forging invalid receipts for cross-shard communication. Defenses include random and frequent re-shuffling of validators between shards and higher staking requirements per shard.

Cross-shard communication relies on message passing over the underlying peer-to-peer network. This exposes the system to network-level attacks like eclipse attacks (isolating a node), Sybil attacks, and delay attacks (intentionally delaying message delivery). High or unpredictable latency can cause timeouts in cross-shard protocols, leading to failed transactions. Secure and efficient gossip protocols and direct peer connections between shard committees are critical countermeasures.

Light clients or users who do not run a full node for every shard face a significant challenge: how to trustlessly verify cross-shard transactions. They must rely on cryptographic proofs (like Merkle proofs) of state inclusion and validity. This increases the complexity of client software and the size of proofs that must be transmitted. Inadequate verification can lead to clients accepting fraudulent cross-shard state transitions, breaking the security model for non-full-node participants.

In monolithic blockchains, composability is synchronous—smart contracts can call each other within the same block. In sharding, composability becomes asynchronous due to communication delays between shards. This breaks many existing DeFi and application patterns, as a contract on Shard A cannot atomically depend on the immediate, finalized state of a contract on Shard B. This forces developers to build with complex, error-prone asynchronous programming models, increasing the attack surface for logic bugs and race conditions.

An independent partition of a blockchain's state and transaction processing load. Each shard maintains its own subset of accounts, smart contracts, and transaction history, operating with a distinct set of validators. Sharding aims to achieve horizontal scaling by parallelizing execution, with cross-shard communication required for interoperability between these partitions.

Two primary models for partitioning blockchain data and computation:

• State Sharding: The network's global state (account balances, contract storage) is divided across shards. This is complex but offers the highest scalability potential.
• Execution Sharding: The computational load of processing transactions is parallelized, but each node may still store a full copy of the state. Cross-shard communication patterns differ significantly between these models.

The timing model for messages between shards:

• Asynchronous: Shards operate independently; a transaction on Shard A can initiate a message to Shard B, but the result is not immediately available. This offers higher performance but complicates application logic.
• Synchronous: The system provides the illusion of atomicity across shards within a single block, often at the cost of higher latency and protocol complexity.

A critical distinction in interoperability:

• Cross-Shard: Communication between partitions of a single, coherent blockchain protocol (e.g., shards in Ethereum). It is natively supported by the protocol with shared security and finality.
• Cross-Chain: Communication between entirely separate, sovereign blockchains (e.g., Ethereum and Avalanche). This requires bridges or interoperability protocols, which introduce distinct trust and security assumptions.