# Network Participation

Participation in a blockchain network can take many different forms. Readers are by now likely most familiar with the role and operation of nodes that participate in the consensus process. We've also touched on the actions of nodes that produce transactions but do not generate blocks. In practice, blockchain systems will typically make design decisions that allow nodes to operate under various requirements or environmental constraints. Nodes may, for example, be able to disable unnecessary features or even switch into special operational modes for resource-constrained environments. These accessibility improvements often have a significant impact on design decisions.

Nodes that download and execute all transactions are usually called "full nodes." Miners almost always run full nodes as to quickly process any incoming blocks and speed up their production of new blocks. Full nodes have the important quality of self-sufficiency in that they store all information necessary to ascertain the validity of any given transaction. Many users choose to operate full nodes as to guarantee an up-to-date view of activity on a network. Node software will typically allow users to disable certain features, mining capability for example, if the user deems these features unnecessary. Users can in this way perhaps operate nodes that receive data from the network but do not actively send data to other nodes.

Some blockchain systems make a distinction between full nodes and so-called "archival nodes." When this is the case, full nodes include the ability to remove, or "prune," information after some specified period of time. Most software that exposes this functionality will only prune data no longer necessary to process new transactions and is therefore considered stale. A UTXO-based system may, for instance, allow nodes to remove spent UTXOs that can, as a result, no longer be used within new transactions. However, as old information can become relevant in the event of a chain fork, software usually defines a large threshold of, say, 1000 blocks that must be appended to a block before its stale data can be pruned.

Archival nodes then refer to those that do not prune information after a certain period of time. These nodes must often store an order of magnitude more information than non-archival counterparts. Within the context of Eth1, for illustration, full nodes store several hundred gigabytes of data whereas archival nodes store a whooping several terabytes. Archival nodes are commonly used by services like "block explorers" that provide users with the the ability to quickly search or parse blockchain data. These services may additionally elect to modify node software in order to collect useful, but not essential, information in a process called "instrumentation." Modifications of this sort can give much greater insight into a network in exchange for a significant increase in data storage requirements.

Archival nodes and full nodes can easily expand beyond the reach of resource constrained environments like older laptops and even modern phones. At several hundred gigabytes, full nodes simply demand too much to be feasibly deployed on certain devices. Many blockchain systems make deliberate design decisions to support operation modes that trade off resource requirements for some reduction in security. These "light client" protocols typically aim to consume data at a rate logarithmic to the size of the entire blockchain. Light clients can therefore participate in the network and store only data on the order of a few gigabytes.

One common approach to light client support requires a distinction between "block header" and "block body" components to a block. Within these systems, a block header represents a concise description of the contents of the block body. Specifically, the header will typically contain the roots of Merkle trees that contain the full list of, for example, transactions within the block body. Light clients can download specific pieces of information within a block by requesting a Merkle proof of inclusion for that particular data point. Light clients can therefore be sure that some information was included within a block at a cost of only the size of the Merkle proof. However, these clients cannot ascertain the validity of a block without access to the block's full contents. Light clients must instead use the Proof-of-Work for a block as a proxy for its validity.

Distinctions between various types of clients can often be somewhat arbitrary. This is particularly apparent among full nodes that choose to enable or disable different software features. That said, the general definition of full, archival, and light clients can be found in many blockchain systems. New designs introduced in Eth2 only serve to blur any dividing lines further. Eth2 aims to use these changes to improve flexibility and, as a result, expand the platforms from which Eth2 is accessible.