What Are Nodes?

In the general sense, a node can be described as a point of connection within a larger system or network. However, when it comes to distributed ledger technology, we must understand that nodes behave in a more dynamic manner than contemporary client-server networks (e.g. the internet). This is because client-server networks use centralized servers to fulfill incoming requests from connecting nodes such as computers (often referred to as a client) whereas peer-to-peer networks used on blockchains do not. In fact, rather than relaying server data from one node to another, client-server networks allow nodes to only catch data from the network. This means that nodes cannot directly reciprocate requests to other nodes without a central server. This unilateral relationship, often referred to as a feeder/leecher, is what separates these types of nodes from the ones you encounter on blockchains. There, a node can both send (fulfill a request) and receive (request) information about and to the network and its participants, facilitating decentralized communication across the blockchain.

What Are The Functions of A Node?

In brief, nodes allow entities such as you and me to connect to a blockchain without the need for an intermediary. They are the backbone of Peer-2-Peer networks and, depending on the node in question, are vital for the consensus mechanism used by distributed ledger technology.

Consensus is the process used by blockchains to verify the history and validity of transactional data. Depending on the blockchain, if enough nodes in a network have reached an agreement (or consensus), this transactional data is either sent to miners (for PoW) or simply added to the ledger. Although ‘transactional data’ frequently relates to monetary transactions, this term is loosely used when it comes to blockchain. It can be as simple as moving cryptocurrencies from one wallet address to another, and as complex as storing data relating to an entire supply chain. 

Blockchains like the XRPL use a combination of protocols like the Peer & ‘gossip’ protocol to link independent yet related servers (or nodes). Once enough servers are connected to one another, the network can begin proposing and validating transactions, all the while maintaining the shared state of the ledger.

What Are The Most Common Types of Nodes?

Although the terminology of nodes is blockchain-dependent, the most commonly known are full and light nodes. On the Bitcoin Network, full nodes carry a copy of the blockchain’s entire transactional history, including all of its blocks. They verify the accuracy & validity of the transactions and relay the information to all other full nodes operating in the network. Consequently, in order to keep the network operating in a stable manner, these nodes need to be running 24/7.

Light nodes, on the other hand, are pieces of software connected to the Bitcoin Network (e.g wallets). These nodes perform similar functions to full nodes but cannot enforce any rule changes on the network. As such, they cannot participate in the consensus mechanism of the blockchain. Instead, they use the data of full nodes to check the authenticity of transactions in order to interact with the blockchain. Compared to their full node counterparts, these nodes only need to hold part of the relevant transaction history (often referred to as block headers). Although this makes them more cost-effective, they are still dependent on full nodes that ultimately need to establish a final consensus.

An important type of node that needs to be mentioned is the miner node. If enough full nodes have validated a proposed set of transactions on the Bitcoin Network, they will relay the data to a bigger pool of validated transactions. Miner nodes pick up the data from this pool and, through the proof-of-work mechanism, attempt to compile them into blocks. Once a block has been formulated, it is then presented back to the full nodes that undergo a similar validating process by comparing the results to the predicated rules of the network. Only once enough full nodes have reached consensus will the block be added to the blockchain.

Although the XRPL uses a similar node terminology (under the names of historical & validator nodes), it does not operate in the exact same manner. For instance, it does not need miners to confirm pending transactions. Instead, validator nodes settle transactions within instants using the consensus mechanism before relaying the information back to the ledger. In addition, when creating a server/node on the XRPL, an entity has the ability to configure how much historical data it requires to sustain its server type. For example, if you are running a Development Machine Server, you may require much less history than if you are running a Hub Server (check out more about XRPL servers here). If a server requires more historical data than it holds, it can simply reach out to other peers in the network to fill its gaps through the use of the XRPL’s Peer Protocol. All-in-all, the configuration flexibility of the XRPL allows servers all over the world to build in an inexpensive yet highly catered way, without being dependent on full history nodes.

What Is The Unique Node List on The XRPL?

Since running a validator node does not require an entity to invest in expensive hardware, anyone can create a validator node/server on the XRPL. Upon inception, each server independently builds its own version of the ledger, before comparing its results to validator nodes. Consequently, choosing the correct node/validator list as a referral is essential when launching a server on the ledger. In comes the Unique Node List.

The Unique Node List is a set of trusted validators that a participant trusts to be legitimate. In other words, UNLs are lists of legitimized validators that, as the name suggests, validate ledger versions by comparing incoming results to their own ledgers through the consensus mechanism. If a validator in this list approves of the independently built versions proposed by other ledgers, they will relay this information to other validating entities and update the ledger. These validators are usually selected on the basis of their “performance, proven identities, and responsible IT policies” and can, therefore, mostly be trusted to perform their due diligence on the network. If a server wishes to connect to these UNLs, they can refer back to the default lists of high-quality validators published by Ripple, the XRP Ledger Foundation, and Coil. You can view a complete list here.

The public nature of these lists allows community members to see which validators have consistently been providing reliable information, giving them ample information to make the right choice when building a server on the XRPL. Although these lists act as a type of recommendation for servers, they are not mandatory since each participant can choose their own validator(s) when setting up a server on the XRPL.

Want To Learn More?

Head over to https://xrpl.org/