Skip to main content

Node Types in the ISBE Network

The ISBE network is based on Hyperledger Besu and uses a defined set of nodes with differentiated roles. This separation ensures consensus stability, permissioning control, and use case operability.
This document describes the types of nodes present in ISBE environments (dev, pre, and pro) and their role within the network.

1. Overview​

In the ISBE network, there are four main categories of nodes:

  • Validator nodes
    Maintain QBFT consensus and generate blocks.

  • Bootnodes
    Control entry authorizations to the P2P network.

  • Execution nodes
    Nodes used by use cases to interact with the network.

  • Archive nodes
    Store the complete chain history for traceability and audit.

All nodes operate under the Hyperledger Besu client, with the same version and base configuration, changing only their functional role.

2. Validator Nodes​

Validator nodes are responsible for:

  • Executing QBFT consensus.
  • Proposing and validating blocks.
  • Ensuring global network state consistency.
  • Maintaining ledger availability and reliability.

Key Features​

  • They do not expose RPC for general use.
  • They do not allow contract deployment or transaction execution from external applications.
  • They are managed exclusively by the ISBE technical team.
  • Their number is limited and stable over time to ensure controlled and predictable consensus.

What This Implies for Use Cases​

Use cases do not interact directly with validators. The existence of these nodes is transparent, but critical for:

  • Block time stability.
  • Deterministic transaction confirmation.
  • Absence of deep reorganizations.

3. Bootnodes​

Bootnodes maintain:

  • The official list of authorized nodes to participate in the P2P network.
  • Information on enodes, libp2p addresses, and metadata necessary for connection.
  • The minimum topology structure required for the network to function correctly.

Specific Functions​

  • Verifying that the node wanting to join is authorized.
  • Publishing discovery information for new nodes.
  • Preventing unauthorized nodes from entering the network.

What They Imply for Use Cases​

Use case teams:

  • Never interact directly with bootnodes.
  • Only need to follow the solicitud-permisionado.md procedure if they wish to set up their own execution node.
  • In most scenarios, they will use execution nodes managed by ISBE, without needing to go through the permissioning process.

4. Execution Nodes​

Execution nodes are the natural interaction point for use cases.
They allow standard Ethereum ecosystem operations:

  • State reading.
  • Sending transactions.
  • Smart contract deployment.

Operational Features​

  • Run exactly the same Besu client as validators, but without a consensus role.
  • Can be operated:
    • By the use case itself (dedicated node).
    • By ISBE (shared node for several teams).
  • RPC access, in both cases, must go through the ISBE Client's Filtering Proxy, never directly to the Besu node's port, to ensure GDPR compliance.
  • The Filtering Proxy only exposes a JSON-RPC (HTTP) endpoint; it does not offer WebSocket under any modality.

Variable Use Case Parameters​

If a use case deploys its own node, it must provide in the permissioning process:

  • Node public IP: <NODE_IP>
  • Node name: <Node_Name>
  • Enode generated by Besu

When It Is Advisable to Have Your Own Execution Node​

It can be recommended if:

  • The use case generates high traffic.
  • A higher level of isolation must be guaranteed.
  • The team wants to fully monitor its transactions and local state storage.

In simpler cases, the shared node provided by ISBE is sufficient.

5. Archive Nodes​

Archive nodes store the complete chain history (every block and state since genesis), unlike execution nodes, which can prune older data.

Key Features​

  • Recommended —not mandatory— in the Ideal network infrastructure configuration; not included in the Minimum configuration (see Infrastructure Requirements).
  • Require more resources than an execution node (higher RAM and disk) due to the complete history.
  • Enable full traceability and regulatory audit capability.
  • Expose a WebSocket endpoint (port 8546) for strictly internal use, consumed by Blockscout to index blocks and events. It is not an endpoint accessible by use cases.

What This Implies for Use Cases​

Use cases do not interact directly with archive nodes. Their function is to serve as a data source for Blockscout and internal audit/analytics systems.

6. Observer Nodes (optional, non-standard)​

In some Besu deployments, "observer" or "read-only" nodes are enabled, whose purpose is:

  • Consulting state without exposing writing.
  • Mirroring blockchain information for analysis, audits, or dashboards.

In ISBE, these nodes are not part of the standard operation nor of the four main categories, but they could be enabled in scenarios of:

  • Advanced monitoring.
  • Analytical services with a high volume of queries.
  • State reproduction outside the main cluster.

7. Comparative Summary​

Node TypeMain RoleRPC ExposureOperatorUse by Use Cases
ValidatorQBFT consensus, block generationNoISBE TeamNo
BootnodeP2P access controlLimitedISBE TeamNo
ExecutionBlockchain read/writeYes, via Filtering ProxyISBE / ParticipantYes
ArchiveComplete chain historyInternal (WS, Blockscout only)ISBE TeamNo (indirect via Blockscout)
ObserverIntensive read (optional, non-standard)Yes (read-only)ISBE / ParticipantOptional