Data Integrity

A 51% attack occurs when a single entity or coalition gains control of more than 50% of a blockchain network's mining hash rate or staking power. This majority control allows them to:

• Double-spend coins by reorganizing the blockchain.
• Censor transactions by excluding them from blocks.
• Halt block production, preventing network finalization. This attack is economically prohibitive on large networks like Bitcoin or Ethereum but remains a risk for smaller Proof-of-Work chains.

A replay attack happens when a valid transaction broadcast on one blockchain network is maliciously or accidentally re-broadcast and executed on a separate, forked network. For example, a transaction signed for the Ethereum mainnet could be replayed on the Ethereum Classic chain if the transaction format is identical. Protection involves:

• Implementing unique chain IDs in transaction signatures.
• Using nonce values that are specific to each chain.

The data availability problem questions how network participants can be sure that all data for a new block (especially in layer-2 rollups) has been published and is accessible. If a block producer publishes only a block header and withholds transaction data, nodes cannot verify the block's validity, potentially allowing invalid state transitions. Solutions include:

• Data availability sampling, where nodes randomly check small chunks of data.
• Erasure coding to reconstruct data from samples.
• Dedicated data availability committees or layers.

An invalid state transition is a change to the blockchain's state that violates the network's consensus rules. This is the core failure that consensus mechanisms and cryptographic proofs are designed to prevent. It can result from:

• A malicious validator producing a block that creates coins from nothing.
• A smart contract bug that allows unauthorized balance changes.
• A faulty client implementation incorrectly applying transaction logic. Networks use fraud proofs (optimistic rollups) or validity proofs (ZK-rollups) to detect and reject these transitions.

A long-range attack targets Proof-of-Stake (PoS) systems where an attacker acquires private keys from validators that staked in the distant past (e.g., years ago). Using these keys, they can create an alternative blockchain history from that old point, potentially making it the canonical chain if it has a higher apparent weight. Defenses include:

• Weak subjectivity checkpoints that clients trust.
• Slashing for validators that sign conflicting blocks, even far in the past.
• Stake decay models that reduce the power of old keys.

A Sybil attack involves a single adversary creating many fake identities (Sybil nodes) to gain disproportionate influence over a peer-to-peer network. In blockchain contexts, this can undermine:

• Peer discovery, by flooding the network with malicious nodes.
• Consensus mechanisms, if identity is cheap to create (mitigated by Proof-of-Work or stake requirements).
• Governance voting in DAOs, if voting power is per-address. The attack is mitigated by requiring a costly resource (hash power, stake, or verified identity) to participate meaningfully.

To prevent manipulation, networks aggregate data from multiple independent nodes. Chainlink uses a decentralized oracle network (DON) where multiple nodes fetch data, and the median of their responses is used, making it expensive to attack. Pyth Network aggregates price data from over 90 first-party publishers (like exchanges and market makers) and uses a confidence interval to represent uncertainty.

Oracle networks maintain on-chain reputation systems that track node performance metrics like response accuracy, latency, and uptime. Smart contract developers can use these scores to select high-quality node operators. This creates a competitive market where nodes are incentivized to be reliable. UMA's Optimistic Oracle uses a dispute mechanism where data is assumed correct unless challenged, placing the burden of proof on challengers.

Authoritative data providers cryptographically sign their data at the source. Oracle nodes then deliver these signed payloads on-chain. Smart contracts can verify the signatures against known public keys, ensuring the data originated from the approved provider. This is common for data from institutions like Brave New Coin or Kaiko, and is a core component of oracle designs like Witnet and Band Protocol.

Full nodes and light clients use Merkle proofs to verify the integrity of blockchain state without downloading the entire chain. A state root, stored in the block header, acts as a cryptographic commitment to the entire global state (account balances, smart contract code, and storage).

• Example: A wallet can prove a user's ETH balance by providing a Merkle path from the leaf (account data) to the root in the latest block header.

A core component of data integrity, ensuring that the data behind a new block is actually published to the network and can be downloaded. Data Availability Sampling (DAS) allows light nodes to probabilistically verify that all data is available by sampling small, random chunks.

• Purpose: Prevents block producers from withholding transaction data, which could lead to fraudulent state transitions.

Scalability solutions like rollups rely on these cryptographic mechanisms to maintain data integrity off-chain.

• Fraud Proofs (Optimistic Rollups): Allow any verifier to challenge and prove an invalid state transition, relying on a dispute period.
• Validity Proofs (ZK-Rollups): Provide a cryptographic proof (ZK-SNARK/STARK) with every batch, mathematically guaranteeing the correctness of state changes before they are finalized on-chain.

Blockchains provide a tamper-evident ledger where data, once confirmed, cannot be altered without consensus. This is used for:

• Supply Chain: Recording provenance and transfer of goods.
• Document Notarization: Creating timestamped, immutable hashes of documents on-chain (e.g., using Bitcoin's OP_RETURN or Ethereum calldata).
• Decentralized Identity: Anchoring verifiable credentials to an immutable public ledger.

The consensus mechanism is the ultimate guarantor of data integrity, ensuring all honest nodes agree on a single, canonical history.

• Proof of Work: Integrity is secured by the cumulative hashing power; altering past blocks requires redoing the work.
• Proof of Stake: Integrity is secured by staked economic value; finality mechanisms (e.g., Casper FFG) provide explicit, irreversible checkpoints for the chain's history.

Two related but distinct concepts in blockchain data integrity.

• Immutability: The practical inability to change recorded data. In blockchains, it's achieved through cryptographic linking (hashes) and decentralized consensus. Altering a past block would require re-mining all subsequent blocks, a computationally infeasible task on robust networks.
• Finality: The guarantee that a validated block/transaction is permanent and will not be reversed. Probabilistic finality (Bitcoin) means confidence increases with each new block. Absolute finality (some PoS chains) means the block is instantly finalized by the consensus protocol. Finality strengthens the guarantee of immutability.