A full node checks the protocol rules needed to accept the chain it follows instead of accepting a block merely because another service reports it. For Bitcoin, this includes transaction spending rules and block validity. It can reject an invalid block even when that block claims substantial proof of work. Independent validation is different from merely holding a large database, and it is also different from creating blocks. A nonmining user can operate a full node.

A pruned Bitcoin node can validate blocks and then discard older block files while retaining the information required for continued operation. It therefore need not serve every historical block to other users. An archive configuration on a smart-contract network may preserve additional historical state for queries that a standard full node cannot answer directly. For example, checking a balance at a very old block can require different retained data from checking the latest balance. These are service and storage distinctions, not interchangeable labels for trust.

A merchant using its own validating node can decide whether a payment appears in the chain that its chosen rules accept. That reduces dependence on an explorer's interpretation. It does not guarantee the merchant's wallet is secure, make private keys safe on an infected computer, or eliminate all network-level attacks. Reliable operation still requires suitable software, synchronization, connectivity, and maintenance. Describe the client and observation time when presenting node-derived evidence, particularly when comparing conflicting histories or investigating a recent reorganization.