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 three main categories of nodes:

  • Validator nodes
    Maintain IBFT 2.0 consensus and generate blocks.

  • Permissioner nodes / bootnodes
    Control entry authorizations to the P2P network.

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

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 IBFT 2.0 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. Permissioner Nodes (Bootnodes)​

Permissioner nodes 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 permissioners.
  • Only need to follow the solicitud-permisionado.md procedure if they wish to set up their own regular node.
  • In most scenarios, they will use regular nodes managed by ISBE, without needing to go through the permissioning process.

4. Regular Nodes​

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

  • State reading.
  • Sending transactions.
  • Event listening via WebSocket.
  • 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).
  • Expose JSON-RPC and WebSocket endpoints.
  • Can connect via HTTP(s) or WSS depending on environment configuration.

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 Regular Node​

It can be recommended if:

  • The use case generates high traffic.
  • Intensive real-time events are needed.
  • 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. Observer Nodes (if enabled)​

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, but they could be enabled in scenarios of:

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

6. Comparative Summary​

Node TypeMain RoleRPC ExposureOperatorUse by Use Cases
ValidatorIBFT consensus, block generationNoISBE TeamNo
PermissionerP2P access controlLimitedISBE TeamNo
RegularBlockchain read/writeYesISBE / ParticipantYes
ObserverIntensive read (optional)Yes (read-only)ISBE / ParticipantOptional