📘

You can read full article on our blog: "Node: A to Z"

Regarding Nodes

Nodes are the basic unit of a computer network. They play a role in organizing data within a network and delivering that data to other nodes or users. All decentralized applications (dApps) on a blockchain, such as MetaMask, need to access data from that blockchain in order to respond to user requests, i.e. querying token balances, sending transactions, or receiving block data.

In simpler terms, we can say that every node is an independent computer that runs blockchain client software.

Think about all the cells making up the human body– red blood cells, skin cells, bone cells, muscle cells, stem cells. Each with a different name and different role to play. The reason it can be so hard to define nodes in one sentence is that roles vary depending on the blockchain network and context.

Types of Nodes

1. Classified By Data Availability

Nodes can be classified into three or four main categories based on how they maintain the blocks and states. Depending on this classification, the functionalities and roles provided by each node can vary.

I. Full Nodes (most common)

A full node stores all transactions that have been executed on the blockchain, recording all blockchain data from the very first block (commonly referred to as the ‘Genesis block’) up until the most recent block. This node type is characterized by the fact that it continuously synchronizes blockchain data to keep itself up to date.

Full nodes essentially act as a gateway for receiving the latest transactions from other nodes, or passing on the transactions received from users onto other nodes. Since a full node contains all of its own records, it is capable of verifying certain transactions without any assistance from other nodes.

However, this also means the disk space required to operate a full node is substantial. Downloading the entire dataset can also take a considerable amount of time.

II. Archive Nodes

An archive node is an enhanced implementation of a full node that not only stores the same data as full nodes, but also retains all previous states of the blockchain. While a typical full node excludes states that existed before the most recent 128 blocks (in the case of Ethereum), an archive node preserves the state of all blocks. It’s therefore possible to query past balance information via the History Methods, or to view all blocks and re-run their entire transaction history.

Archive nodes are typically operated by entities with specific purposes that require querying arbitrary historical data. For example, they may need to request a token balance from a previous state, track the activity of a particular user, or re-run a transaction’s history.

However, operating archive nodes requires even higher technical expertise and operational costs than operating full nodes. For instance, running an Ethereum archive node currently requires storing over 14TB of data. And it’s critical to ensure that the synchronization state is always maintained properly to prevent data corruption (which takes a much longer time to recover from).

*Query: A request from a client (user) to the database for a specific piece of data.
*History Method: Used to acquire the historical record of all blocks including block headers, block bodies, uncle blocks and transaction receipts.

III. Light Nodes

The requirement to maintain all this data in order to participate in a blockchain network can be a major constraint on network expansion or mass adoption. On the other hand, if all a node has to do is simply propagate data to the network and process user requests, its main role is to act as an intermediary.

This is exactly what light nodes do: they only contain certain data from blocks, namely the block headers*. This means they can propagate transactions but cannot validate them alone as validator nodes do, so they usually rely on full nodes for individual verification. Although this dependency on external data verification is disadvantageous, the low operating cost is a significant benefit.

📘

Concept of light nodes

The concept of light nodes comes from Bitcoin. Back then, they were known as a Simplified Payment Verification (SPV) nodes or lightweight nodes, characterized by maintaining only a subset of the blockchain and verifying transactions via SPV.

*Block header: Each block consists of a block header and block body. The block header and block body compare information to check for any tampering. For example, the Bitcoin block header contains the hash values of the current and previous block, the version of Bitcoin that created the block, the Merkle root, timestamp, current mining difficulty, and nonce. The content stored in the header may vary depending on the network.

IV. Pruned Nodes

When dealing with nodes built using the Cosmos SDK, you’ll often encounter the term “Pruned Node.” Pruned nodes, as the name suggests, refers to the pruning of data. Instead of preserving all blockchain data like full nodes, this type has the ability to selectively store the data it needs.

Nodes with special pruning conditions, such as “keep only a few blocks, or a few state” are classified as pruned nodes. According to this criterion, pruned nodes with certain conditions can actually resemble full and archive nodes, as well as light nodes– which we’ll get to next.

*Cosmos SDK: A generalized framework that simplifies the process of building dApps on Cosmos.

2. Classified By Purposes

Nodes can also be categorized based on the reason for their existence on the network, i.e. what role they play.

I. RPC Node

RPC nodes come up most often in services that provide Node API. It generally refers to a full node that has the capability to respond to Remote Procedure Call (RPC) requests.

📘

Remote Procedure Calls (RPCs)

Remote Procedure Calls (RPCs) serve as a form of communication that enables a program (client) to request a service from a program located on another computer (server) on a network. In other words, it's a software communication protocol that a program can use to request something from a program on another computer without having to understand the network's technical details. RPC allows processes on remote systems to be called in the same way as local processes.

For instance, a dApp usually needs to query or update blockchain data to provide its services. In this scenario, based on the RPC client-server model above, the dApp is a client and the server acts as an RPC node.

*Node API Service: A service that allows dApp developers to use the blockchain platform by accessing data directly, without having to operate a node themselves.

II. Validator Node

A validator node is a full node that possesses the ability to validate new transactions submitted to a specific chains’ mempool*. To accomplish this, it holds a private key that allows it so sign transactions, thereby marking them as valid. This service is rewarded every time a new block is created.

The term and concept of a validator node are primarily found in consensus algorithms based on Proof-of-Stake (PoS). In blockchains that utilize Proof-of-Work (PoW) — like Bitcoin — these nodes are typically referred to as “mining nodes.” You can learn more about mining nodes here.

*Mempool: A list of pending transactions that have been submitted to the network, but not yet confirmed and added to a block on the blockchain.

III. Seed Node

A seed node, put simply, acts as a phonebook within a blockchain network. In order for a new node to join the network, it must connect to one of the seed nodes, which will provide it with a list of IP addresses of active nodes on the network. Once the new node receives this list, it is able to start synching with the network.

In this way, the seed node provides the resources to connect to the network but doesn’t have the configuration of a typical node. Its primarily role being IP tracking, all it needs to do is maintain constant connection. Although it is referred to as a node, it’s easier to conceptualize these as an address book that redirects nodes.

📘

Seed Node and Boot node

The term "seed node" was first introduced on the Bitcoin network; within Ethereum-compatible chains, they're usually referred to as Bootnodes and perform the same function.

As we’ve seen above, nodes that perform various roles within the network can be classified into full, archive, or light based on the amount or type of data they contain. For example, a node that has all the data to fulfill its role of responding to RPC requests can be described as both an RPC node and full node.

Why do developers need a node provider?

Developers often rely on node providers to reduce costs and simplify their development workflow.

Running individual nodes and managing the storage of block data can be financially and operationally demanding. Node providers, such as All That Node, offer a solution to these challenges.

Node provider services function by accessing block data through APIs. Developers can easily retrieve blockchain data by submitting the request string to the prompt, without the need for intricate node setup and management processes. This streamlined approach saves time and effort, allowing developers to focus on their core development tasks.