Light Node

A light node's primary security model relies on the honest majority assumption regarding the full nodes it queries. It cannot independently verify if data has been withheld (data availability problem). To mitigate this, it uses fraud proofs (in optimistic rollups) or data availability sampling (in modular architectures like Celestia) to increase confidence that data is published.

The core security mechanism for light nodes (e.g., in Bitcoin) is Simplified Payment Verification (SPV). The node downloads and verifies the chain of block headers, which contains the Merkle root of all transactions. To prove a transaction's inclusion, a full node provides a Merkle proof. Security rests on the computational hardness of the header chain's Proof-of-Work, making header forgery economically infeasible.

Light nodes are vulnerable to eclipse attacks, where a malicious actor isolates the node by controlling all its peer connections. This allows the attacker to feed the node false headers and data. Mitigations include:

• Randomized peer selection from a large, diverse peer set.
• Using anchor blocks or checkpoints from trusted sources.
• Network-level protections against sybil attacks.

The key trade-off for light nodes is sacrificing absolute security for minimal resource use. A Bitcoin light node stores ~50 MB of headers versus ~500 GB for a full node. However, this comes with costs:

• Increased latency when querying for proofs and state.
• Dependence on remote peers for data, which can be censored or slow.
• Inability to validate consensus rules beyond header chain validity.

In Proof-of-Stake (PoS) systems like Ethereum, light clients verify using sync committees and signature aggregates. A randomly selected committee of validators signs block headers, allowing the light client to trust a small, constantly changing group. This model replaces PoW's computational security with cryptographic security based on the stake's economic value, requiring robust committee sampling and anti-correlation measures.

Light nodes enable blockchain access for resource-constrained devices, which defines their security perimeter. Examples include:

• Mobile wallets (e.g., MetaMask Mobile using Infura as a light client gateway).
• IoT sensors submitting data to a blockchain.
• Cross-chain bridges that run light clients of foreign chains (e.g., IBC light clients). Security is application-dependent, often involving trust in the service provider or relay network.

A full node is a blockchain client that downloads, validates, and stores the entire history of the blockchain. It serves as an authoritative source of truth, independently verifying all transactions and blocks against the network's consensus rules. This is in direct contrast to a light node, which relies on full nodes for data.

• Primary Function: State validation and block propagation.
• Resource Intensive: Requires significant storage, bandwidth, and computational power.
• Network Role: Acts as a backbone peer, providing data to light nodes and other clients.

Simplified Payment Verification (SPV) is the core cryptographic method that enables light node functionality. Introduced in the Bitcoin whitepaper, it allows a client to verify that a transaction is included in a valid block without downloading the entire blockchain.

• Mechanism: Verifies the Merkle proof linking a transaction to a block header.
• Trust Assumption: Assumes the majority of the network's hash power is honest, as it trusts the chain with the most accumulated proof-of-work in its headers.
• Key Enabler: Makes lightweight wallets and mobile blockchain access practical.

A block header is an 80-byte data structure that cryptographically summarizes the contents of a block. It is the only data a light node downloads and stores. The header contains the critical information needed for SPV.

• Key Components: Previous block hash, Merkle root of transactions, timestamp, nonce, and difficulty target.
• Light Node Reliance: By chaining headers, a light node can follow the longest proof-of-work chain and verify transaction inclusion via the Merkle root.
• Security Property: Any change to a block's transactions invalidates the Merkle root, breaking the header chain.

A Merkle tree is a cryptographic data structure that efficiently summarizes all transactions in a block. A Merkle proof is the minimal set of hashes needed to prove a specific transaction's membership in that tree.

• Function: Enables efficient and secure verification of large data sets.
• Light Node Use Case: A full node provides a Merkle proof to a light node, which uses it along with the block header's Merkle root to verify a transaction's inclusion.
• Example: Verifying a single payment in a block with 10,000 transactions requires only ~log₂(10,000) hashes.

An archival node is a full node that retains the entire historical state of the blockchain, including the state (account balances, contract storage) for every block since genesis. It provides a superset of full node functionality.

• Data Scope: Stores the full chain and all historical state snapshots.
• Contrast with Pruned Node: A pruned full node deletes old state data after validation, while an archival node preserves it.
• Resource Demand: Requires the highest storage capacity, often multiple terabytes for mature chains like Ethereum.

Client diversity refers to the distribution of network participants across different software implementations (clients). A healthy ecosystem requires a mix of full nodes, light nodes, and archival nodes running on varied client software to avoid single points of failure.

• Risk of Centralization: If >33% of nodes run the same client software, a bug could cause a chain split.
• Light Node's Role: Increases network participation and decentralization by lowering the barrier to entry.
• Ecosystem Health: Measured by the distribution of client types and software implementations across the network.