Full Node (DA)

A full node downloads and stores the entire blockchain ledger. This includes every transaction's data, block headers, and the Merkle root for each block. This complete dataset is essential for verifying that all data for a new block is available for download, preventing data withholding attacks where a block producer might publish only block headers.

Unlike light clients, a full node does not trust other nodes. It independently executes all transactions from the genesis block to the current tip, rebuilding the entire state trie. This allows it to verify the correctness of the chain's state and detect invalid transactions or blocks, ensuring the integrity of the data it attests is available.

For scalability, modern DA layers like Celestia or EigenDA use Data Availability Sampling. Here, a full node doesn't download the entire block. Instead, it randomly samples small chunks of the erasure-coded data. If a sufficient number of samples are successfully retrieved, it can probabilistically guarantee the entire block data is available.

A primary function is to serve data to light clients and Layer 2 rollups. Rollup sequencers post transaction data to the DA layer, and full nodes ensure this data is persistently stored and retrievable. This allows anyone to reconstruct the rollup's state and challenge invalid state transitions.

The node enforces the network's consensus protocol (e.g., Tendermint, Ethereum's proof-of-stake). It validates block signatures, checks for slashing conditions, and rejects blocks that do not follow the protocol rules. This governance role is foundational for the security of the DA layer itself.

Running a full node requires significant resources, which is a key trade-off for its trustlessness.

• Storage: Requires terabytes of SSD space for full history.
• Bandwidth: Constant data upload/download for syncing and serving.
• Compute: CPU power for validating proofs and executing transactions. This creates a barrier to entry but ensures a decentralized, robust network.

The primary duty is to store the complete blockchain history, including all transaction data. This makes it the authoritative source for data availability sampling (DAS). Light clients or other nodes query the full node to retrieve specific blocks or transactions, verifying that data has not been withheld.

Upon receiving a new block, a full node performs full validation. This includes:

• Verifying cryptographic signatures and consensus rules.
• Ensuring the block's data is fully present and correctly formatted.
• Checking that transactions are valid and non-conflicting. Once validated, it propagates the block to the peer-to-peer network.

A critical role in modular architectures (e.g., rollups). The full node provides the raw transaction data for blocks. This allows light clients using DAS to request random chunks of data. If the full node cannot provide the data, it proves data unavailability, triggering a challenge period or halting the chain.

By independently validating all rules, the full node enforces the blockchain's consensus protocol. It rejects invalid blocks, preventing network splits and ensuring all honest nodes agree on the canonical chain. This decentralized validation is the bedrock of security and liveness.

Not all full nodes store the entire history forever.

• Archival Node: Stores all historical data from genesis. Essential for data availability services and deep historical queries.
• Pruned Node: Validates fully but deletes old transaction data after a certain point, keeping only recent state and block headers. It maintains security but not full data availability for old blocks.

Running a full node demands significant resources, creating a trade-off between decentralization and participation.

• Storage: Requires terabytes for archival nodes on mature chains like Ethereum.
• Bandwidth: High for syncing and propagating large blocks.
• Compute: Needed for continuous validation of cryptographic proofs and state transitions.

A Light Node or Light Client downloads only block headers, not the full transaction data. It relies on Full Nodes to provide cryptographic proofs (like Merkle proofs) to verify specific transactions, enabling operation on resource-constrained devices like phones and browsers.

Data Availability Sampling (DAS) is a technique where light nodes randomly sample small chunks of block data to probabilistically verify that a Full Node has made all data available. This is a core innovation enabling scalable and secure data availability layers without requiring all participants to download everything.

A Data Availability Committee (DAC) is a trusted group of entities that cryptographically attest to the availability of transaction data, acting as an alternative to a decentralized network of Full Nodes. Rollups often use DACs for lower-cost data availability, trading some decentralization for efficiency.

An Archival Node is a type of Full Node that stores the entire historical state of the blockchain, not just recent blocks. While a standard Full Node (DA) might prune old transaction data after verification, an Archival Node retains everything, serving as a complete historical ledger for queries and analysis.

A Validator Node is responsible for participating in consensus to produce new blocks. In modular architectures, a Validator Node on the consensus layer may rely on a separate network of Full Nodes (DA) to ensure the transaction data for those blocks is published and available for verification.

Erasure Coding is a data redundancy technique used by data availability layers. A Full Node (DA) encodes block data into expanded pieces, so the network can reconstruct the entire dataset from a subset of pieces. This allows light clients to perform Data Availability Sampling with high confidence.