A crosslink is a cryptographic attestation, signed by a committee of validators, that confirms the finality of a block within a shard chain and links it to the beacon chain (or main chain). This mechanism is central to the security model of sharded Proof-of-Stake (PoS) systems like Ethereum 2.0 (the consensus layer), where it enables the beacon chain to maintain a secure, aggregated summary of all shard states without processing every transaction. The process of creating a crosslink is often referred to as finalizing a shard block.
LABS
Glossary
Crosslink
A crosslink is a cryptographic proof in a sharded blockchain that attests to the inclusion and finality of a shard's block data within the main beacon chain.
Chainscore © 2026
definition
BLOCKCHAIN CONSENSUS
What is Crosslink?
A crosslink is a fundamental data structure in sharded blockchain architectures that provides cryptographic proof of the inclusion of a shard's block in the main chain's state.
The creation of a crosslink involves several steps. First, a committee of validators is randomly assigned to a specific shard. These validators attest to the validity of a proposed shard block. Once a supermajority (typically two-thirds) of the committee agrees, their signed attestations are aggregated into a single attestation. This aggregated data bundle, which includes the shard block root and the committing epoch, is then included in a beacon block, creating the official crosslink. This acts as a checkpoint, making the shard block extremely difficult to revert.
Crosslinks are critical for enabling secure cross-shard communication. Because a crosslink provides a finalized, globally recognized state root for a shard, other shards or the execution layer can trust this information when interacting with it. For instance, a transaction on one shard can safely reference or trigger an action on another shard only after the relevant state has been crosslinked. This design prevents double-spending across shards and ensures data availability is confirmed before state changes are considered permanent.
It is important to distinguish crosslinks from other bridging mechanisms. While a crosslink is an intra-protocol consensus object for linking shards within a single blockchain network (like Ethereum), an interoperability bridge is an inter-protocol solution connecting separate, sovereign chains (like Ethereum and Polygon). Crosslinks are natively secured by the network's validator set, whereas external bridges often introduce additional trust assumptions or cryptographic models.
how-it-works
BEACON CHAIN MECHANISM
How Crosslinks Work
Crosslinks are a core consensus mechanism in Ethereum's proof-of-stake system, enabling the Beacon Chain to finalize data from shard chains.
A crosslink is a set of cryptographic signatures from a committee of validators that attests to and finalizes the state of a shard chain block on the Beacon Chain. This process is the primary method by which the Beacon Chain, the coordination layer, learns about and secures the state of the individual shard chains in Ethereum's scaling architecture. By aggregating these attestations, crosslinks create a verifiable and immutable record, ensuring data availability and consistency across the fragmented network.
The crosslinking process occurs in discrete epochs. During each epoch, a pseudo-randomly selected committee of validators is assigned to each shard. These validators validate the proposed shard block and create an attestation, which includes a vote for the block's head and the shard's current state. The Beacon Chain's consensus algorithm, Casper FFG, then uses these aggregated attestations to justify and finalize the shard's state. This finality means the data is permanently cemented and cannot be reverted without slashing a significant portion of the validator stake.
Crosslinks are fundamental for enabling data availability sampling and rollup scalability solutions. Once a shard block is crosslinked, its data is considered available and finalized on the Beacon Chain. Layer 2 rollups can then trustlessly reference this data to prove the state of their own chains. This mechanism shifts security from individual shards to the collective validator set of the Beacon Chain, preventing isolated shards from being compromised and ensuring the entire system's integrity relies on the main chain's economic security.
key-features
BEACON CHAIN MECHANICS
Key Features of Crosslinks
Crosslinks are the fundamental mechanism by which the Beacon Chain finalizes shard data, enabling Ethereum's sharded architecture. They are attestations from committees that a shard block is valid and ready for inclusion in the canonical chain.
01
Shard Data Finalization
A crosslink is a set of signatures from a committee of validators attesting that a specific shard block is valid and can be referenced by the Beacon Chain. This process finalizes shard data onto the main chain, making it part of Ethereum's canonical history. Without crosslinks, shard chains would operate in isolation.
- Committee Attestation: A randomly selected group of validators votes on shard block validity.
- Inclusion: The Beacon Chain records the crosslink, finalizing the shard block's state root.
02
Committee-Based Security
Crosslink security relies on cryptoeconomic security derived from the Beacon Chain's validator set. For each shard and slot, a pseudo-random committee of at least 128 validators is assigned to produce the crosslink. This design ensures:
- Decentralization: No single validator controls crosslink creation.
- Scalability: Many committees can operate in parallel across different shards.
- Finality: A sufficient number of honest validator signatures is required for a crosslink to be accepted.
03
Link to Consensus (Finality Gadget)
Crosslinks are integral to Ethereum's Casper FFG (Friendly Finality Gadget) consensus. A shard block is not considered finalized until a crosslink for it is included in a finalized Beacon Chain checkpoint. This creates a strong cryptographic link:
- Two-Phase Finality: Beacon Chain epochs achieve 'justified' then 'finalized' states.
- Crosslink Inclusion: A shard block is finalized only when its crosslink is referenced within a finalized checkpoint on the Beacon Chain.
04
Enabling Data Availability
The primary function of crosslinks in Ethereum's rollup-centric roadmap is to guarantee data availability. When a crosslink is created, it commits to the data root of a shard block (blob of data). This allows Layer 2 rollups (like Optimism, Arbitrum) to post their transaction data to shards, knowing it is permanently available and verifiable. Key for validity proofs and fraud proofs.
05
Distinction from Attestations
It is critical to distinguish a crosslink from a simple attestation. All crosslinks are built from attestations, but not all attestations become crosslinks.
- Attestation: A validator's vote for a Beacon Chain head block and a shard block.
- Crosslink: The aggregated result of enough committee attestations for a specific shard and epoch, recorded on-chain. Think of attestations as votes and the crosslink as the certified election result.
06
Evolution with Danksharding
The concept evolves with Proto-Danksharding (EIP-4844) and full Danksharding. In this new design, the focus shifts from executing shard chains to providing cheap blob data space.
- Blob-Carrying Transactions: Crosslinks will attest to the availability of data blobs.
- Data Availability Sampling (DAS): Light clients can verify blob availability without downloading all data.
- Simplified Role: Crosslinks become attestations of data availability for blobs, streamlining the sharding architecture.
primary-functions
CROSSLINK
Primary Functions
A crosslink is a cryptographic proof that finalizes a shard or sidechain block within a beacon chain's consensus, enabling secure interoperability and data availability across a sharded blockchain.
01
Shard Block Finalization
A crosslink is the primary mechanism for finalizing shard block data onto the main chain (beacon chain). It acts as a cryptographic commitment, proving that a specific shard block has been approved by a committee of validators. This process:
- Anchors shard state to the main chain's security.
- Enables the beacon chain to track the canonical history of all shards.
- Is essential for the data availability of shard transactions.
02
Committee-Based Attestation
Crosslinks are created through a distributed attestation process. A randomly selected committee of validators on the beacon chain:
- Verifies the validity of a proposed shard block.
- Collectively signs an attestation, which includes a vote for the shard's head block.
- Once a sufficient supermajority of the committee agrees, the attestation forms a crosslink, finalizing that shard block epoch.
03
Enabling Cross-Shard Communication
By providing a finalized, globally agreed-upon reference point for each shard's state, crosslinks are the foundation for secure cross-shard transactions. They allow one shard to trustfully verify events or state changes that occurred on another shard. This is critical for:
- Composability of applications across shards.
- Asset transfers between different shard chains.
- Building a unified, scalable blockchain ecosystem.
04
Data Availability Proof
A crosslink serves as a cryptographic guarantee that the data for a shard block is available for download. This is a core requirement for rollups and data availability layers. The beacon chain's consensus on the crosslink header assures all network participants that the underlying transaction data can be reconstructed, enabling secure and trust-minimized bridging of off-chain data.
05
Epoch Alignment & Finality
Crosslinking is tied to the epoch boundary of the beacon chain (every 32 slots, or ~6.4 minutes in Ethereum). Not every shard slot gets crosslinked every beacon chain slot. The system is designed so that, over time, every shard block is eventually crosslinked, achieving economic finality for shard data by leveraging the full security of the beacon chain's validator set.
06
Contrast with Sidechain Bridges
Unlike traditional bridges that rely on external multisigs or federations, a native crosslink is a consensus-level primitive. It is produced by the protocol's own validators as part of their core duties, offering superior security assumptions. This distinguishes sharding architectures (e.g., Ethereum's earlier design) from standalone sidechains connected via smart contract bridges.
visual-explainer
BLOCKCHAIN CONSENSUS MECHANISM
Visualizing the Crosslink Process
An explanatory guide to the crosslink, a fundamental data structure for shard coordination in Ethereum 2.0 and similar sharded blockchains.
A crosslink is a cryptographic proof, embedded in a beacon chain block, that attests to the finality of a specific shard block within a sharded blockchain architecture. This mechanism is the cornerstone of shard chain security, allowing the main beacon chain to maintain a lightweight, verifiable record of the state and history of all parallel shards without processing their transactions directly. The process involves a committee of validators from the beacon chain being assigned to a shard to produce and verify these attestations.
The crosslink creation process follows a strict sequence. First, validators in a shard committee reach consensus on a proposed shard block. They then collectively produce a signed attestation, which is a vote containing the shard block's root hash and other metadata. This attestation is broadcast to the beacon chain network. Finally, beacon chain block proposers aggregate these attestations and, once a sufficient supermajority is collected, permanently record the resulting crosslink in a beacon block, finalizing the referenced shard block.
This architecture provides critical security guarantees. By requiring a large, randomly selected committee of validators to sign off on a shard block, it becomes computationally infeasible for an attacker to finalize invalid or conflicting shard states. The beacon chain acts as a settlement layer, where crosslinks serve as indisputable checkpoints. This design enables horizontal scaling (sharding) while preserving the security derived from the entire validator set, preventing individual shards from being vulnerable to smaller, isolated attacks.
In practical terms, visualizing data flow helps clarify the abstraction. User transactions occur on a specific shard chain. That shard's validators package them into a block and attest to it. Their votes are bundled into an attestation and sent upward to the beacon chain. The beacon chain's consensus algorithm, Casper FFG, uses these aggregated votes to justify and then finalize the crosslink. Once finalized, the state root in the crosslink can be trusted by other shards or layer-2 systems for secure cross-shard communication.
The evolution from crosslinks to data availability sampling in later Ethereum upgrades highlights its foundational role. Initially, crosslinks contained full shard state commitments. The Danksharding roadmap simplifies this: crosslinks now attest primarily to the availability of shard data blobs, while Ethereum Execution Clients handle verification. This shift optimizes for rollup-centric scaling, but the core function—using beacon chain consensus to securely reference and finalize shard data—remains the critical bridge in a modular, scalable blockchain.
ecosystem-usage
CROSSLINK
Ecosystem Usage & Examples
Crosslinks are a core data structure in sharded blockchain architectures, enabling secure and verifiable communication between shards. Their primary function is to provide a cryptographic summary of a shard's state to the main chain, or beacon chain.
02
Cross-Shard Transaction Verification
Crosslinks enable trust-minimized verification of events across shards. For example, a decentralized application (dApp) on Shard A can reliably confirm that a payment was finalized on Shard B by checking for a corresponding crosslink in the beacon chain. This is foundational for cross-shard composability, allowing assets and state to move securely between execution environments.
03
Data Availability Proofs
The data referenced in a crosslink, often via Merkle roots, allows light clients and other shards to verify that specific transaction data is available without downloading the entire shard history. This is critical for fraud proofs and validity proofs in scaling solutions, ensuring the network can detect and challenge invalid state transitions.
04
Committee-Based Security
Crosslinks are not created by a single entity. A randomly selected committee of validators (e.g., 128+ in Ethereum) must collectively sign the attestation. This design:
- Distributes trust and prevents a single point of failure.
- Makes it economically prohibitive to create a fraudulent crosslink.
- Aligns security with the overall proof-of-stake consensus of the beacon chain.
05
Contrast with Sidechain Bridges
A crosslink is a native, consensus-level primitive, unlike most cross-chain bridges. Key differences:
- Security Source: Crosslinks derive security from the main chain's validators. External bridges often have their own, smaller validator sets.
- Latency: Crosslinks are finalized as part of regular consensus, while bridge confirmations can have variable delays.
- Trust Model: Crosslinks are cryptographically verifiable by any network participant, reducing reliance on external trust assumptions.
06
Evolution in Ethereum's Roadmap
The concept and implementation of crosslinks have evolved. Initially central to the sharding design, Ethereum's Danksharding roadmap (via EIP-4844 and beyond) has shifted focus. The role of crosslinks for data availability is being superseded by data availability sampling (DAS) and blob-carrying transactions, where the beacon chain directly accepts and attests to large data blobs without persistent shard chains.
security-considerations
CROSSLINK
Security Considerations
Crosslinks are critical data structures that finalize shard block data into the Beacon Chain, but their creation and validation introduce specific security challenges.
01
Data Availability & Withholding Attacks
A malicious shard committee could create a valid crosslink but withhold the underlying shard block data, preventing reconstruction of the shard's state. This is mitigated by Data Availability Sampling (DAS) and Erasure Coding, requiring only a subset of honest nodes to recover the full data.
02
Committee Manipulation & Grinding
An attacker could attempt to influence the random beacon committee selection to gain a disproportionate number of malicious validators in a shard committee. The protocol counters this with RANDAO and VDFs (Verifiable Delay Functions) to ensure unbiased, unpredictable, and non-manipulable committee assignments.
03
Finality & Chain Reorgs
While a crosslink provides a degree of finality for shard data, deep chain reorganizations on a shard could theoretically invalidate a crosslink before it is finalized on the Beacon Chain. The Casper FFG finality gadget and the finalized checkpoint process on the Beacon Chain provide strong, economic guarantees against such reorgs.
04
Network-Level Attacks (Eclipse & Delay)
Attackers could target the P2P gossip network to eclipse honest validators in a committee or delay the propagation of shard block attestations. This could prevent or stall crosslink formation. Robust peer-to-peer protocols and attestation aggregation deadlines are key defenses.
05
Long-Range Attacks & Weak Subjectivity
A new node syncing the chain from genesis cannot cryptographically distinguish a canonical chain from a fabricated alternative history that includes fake crosslinks. This is addressed by Weak Subjectivity Checkpoints, where nodes rely on a recent, socially-verified finalized state as a trusted starting point.
06
Implementation Bugs & Consensus Client Diversity
Bugs in the crosslink logic within a consensus client (e.g., Lighthouse, Prysm) could lead to chain splits or finality failures. Client diversity is crucial; no single client implementation should command a supermajority of the network to mitigate systemic risk from a single codebase flaw.
DATA STRUCTURE COMPARISON
Crosslink vs. Related Concepts
A comparison of the Crosslink data structure with related concepts for finality and data availability in blockchain architectures.
| Feature | Crosslink (Ethereum 2.0 / Consensus Layer) | Block Header | Checkpoint |
|---|---|---|---|
Primary Function | Attests to a shard block's inclusion in the Beacon Chain for cross-shard consensus. | Contains the Merkle root of a single block's transactions and state. | A justified or finalized epoch boundary block on a single chain. |
Scope & Granularity | Shard-level. References a specific shard block. | Block-level. Specific to a single block on its chain. | Epoch-level. Marks a specific slot (every 32nd block) on a single chain. |
Data Commitment | Commits to the shard block body root and beacon chain state root. | Commits to the transaction root, state root, and receipts root. | Commits to the block root of a specific epoch boundary slot. |
Finality Role | Mechanism for achieving cross-shard finality when included in a finalized Beacon Chain checkpoint. | Provides block-level validity but not inherent finality on its own. | Represents a point of canonical finality for its specific chain. |
Architectural Layer | Consensus Layer (Beacon Chain). A consensus object. | Execution Layer. A core blockchain component. | Consensus Layer. A finality gadget component (Casper FFG). |
Dependency | Depends on the Beacon Chain's finality for its own validity and finality. | Depends on the consensus rules of its native chain for validity. | Depends on a supermajority of validator votes for justification and finalization. |
Cross-Chain / Cross-Shard Role | Core mechanism for secure cross-shard communication and state references. | None. Confined to its native chain. | None. Confined to its native chain, though used as a finality anchor. |
CROSSLINK
Frequently Asked Questions
Crosslinks are a core data structure in sharded blockchain architectures, acting as cryptographic checkpoints that synchronize shard chains with the main Beacon Chain.
A crosslink is a cryptographic proof, or a reference, that finalizes a shard block's state and includes it in the Beacon Chain of a sharded blockchain. It works by having a committee of validators on the Beacon Chain attest to the validity of a specific shard block. Once a sufficient supermajority of the committee signs off, a crosslink is created, permanently anchoring that shard block's data to the main chain. This mechanism enables the Beacon Chain to track the state of all shards without processing their transactions directly, which is fundamental for achieving scalability through sharding.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall