Skip to content

Different node types and classes

Abstract

This subsection describes the different types and classes of nodes and displays their attributes.

Motivation

To operate a blockchain network it is important to know the different node types and classes and how to use them correctly.

There are several ways to operate a node. To get an overview of all possible ways.

Dividing nodes and members in different types and classes allows one to use design patterns like principle of least privilege or efficient resource handling.

Elaboration

The following is an overview of the different types and classes of a node (the list is not exhaustive):

Types

  • Full Node
    • Stores full blockchain data.
    • Participates in block validation, verifies all blocks and states.
    • All states can be derived from a full node.
    • Serves the network and provides data on request.
  • Light Node
    • Stores the header chain and requests everything else.
    • Can verify the validity of the data against the state roots in the block headers.
    • Useful for low capacity devices.
  • Service Node
    • Todo
  • Forensic/audit/witness Node
    • Todo
  • Validator Node:
    • Relevant for networks that use a validation based consensus (e.g. DASH, Tendermint)
    • Propose and vote on new blocks
    • Different ways exists how to incentivise correct behavior for validator nodes, e.g. Proof of Stake or exclusion from the network
  • Mining node:
    • Relevant for networks that use a Proof of Work based consensus (for consortium changes often in combination with Proof of Stake consensus)
    • Proposes new blocks to the network
    • Needs access to full chain
  • Observer Node: todo
  • Other Node: todo
  • Bootnode:
    • Node that collects and maps addresses of nodes in the blockchain network
    • Serves up to date addresses to new nodes that want to connect to the network
    • Only for address exchange, does not participate in block validation, etc.
  • Static node:
    • Full node with static DNS name or IP address.

Classes

Depending on the point of view, these types can be further classified. (The following list is not comprehensive and can also be understood as an opinionated view)

Technical view:

  • Nodes that keep the full blockchain:
    • Full node
    • Archive node
  • Nodes that keep part of the blockchain:
    • Light node
    • Boot node
  • Nodes that create new blocks
    • Validator nodes
    • Mining nodes

Service view:

  • Network support:
    • Boot node
    • Static node
  • Blockchain data provider:
    • Full node
    • Archive node
    • Boot node
    • static node
  • Block production:
    • Validator node
    • Mining node
  • Consumers:
    • Light nodes

A drawback: There is too much fragmentation in the types and classes of nodes. There is no standard implementation because most blockchains are designed for a special use case (running dapps for public usage or offering a registry for self sovring identities in public or private networks) but all projects are oriented towards the technology. This makes it very cluttered.

Unresolved issue: Standardisation of the types and classes of nodes and the related compatibility of the block chain as a whole.

References to best practices, examples

The ethereum documentation can serve as an example for the types of nodes.

If you want to run your own node, you should understand that there are different types of node that consume data differently. In fact, clients can run 3 different types of node - light, full and archive. There are also options of different sync strategies which enables faster synchronization time. Synchronization refers to how quickly it can get the most up-to-date information on Ethereum's state.

Full node

  • Stores full blockchain data.
  • Participates in block validation, verifies all blocks and states.
  • All states can be derived from a full node.
  • Serves the network and provides data on request.

Light node

  • Stores the header chain and requests everything else.
  • Can verify the validity of the data against the state roots in the block headers.
  • Useful for low capacity devices, such as embedded devices or mobile phones, which can't afford to store gigabytes of blockchain data.

Archive node

  • Stores everything kept in the full node and builds an archive of historical states. Needed if you want to query something like an account balance at block #4,000,000.
  • These data represent units of terabytes which makes archive nodes less attractive for average users but can be handy for services like block explorers, wallet vendors, and chain analytics.
  • Syncing clients in any mode other than archive will result in pruned blockchain data. This means, there is no archive of all historical state but the full node is able to build them on demand.

We can look at the Sovrin Steward Technical and Organizational Policies as an example implementation for node classes:

A Steward Node: * MUST be available to run as a Validator Node or Observer Node on any of the formal ledgers that make up the Sovrin Network.

We can also take a look at the Hyperledger Besu documentation as an example of the use of bootnodes:

Using Bootnodes is a method for initially discovering peers. Bootnodes are regular nodes used to discover other nodes.

Bootnodes and static nodes are parallel methods for finding peers. Depending on your use case, you can use only bootnodes, only static nodes, or both bootnodes and statics nodes. For example, you run multiple nodes on MainNet (discovery using bootnodes), but want to ensure your nodes are always connected (using static nodes).

Bibliography of selected references

Steward Technical and Organizational Policies

Hyperledger Besu

Ethereum

RFC-1007
Authors: David Maas, Mirko Mollik, Ingo Keck
Status: work in progress
Last modified: 2020-09-09