Skip to main content

General Architecture of the ISBE Network

This document describes the logical architecture of the ISBE blockchain network from the point of view of use case participants. It does not go into detail about Terraform, Helm, or Kubernetes, but rather how the network is organized and what implications it has for the dApps that connect to it.

1. Goal of the Architecture​

The ISBE infrastructure provides:

  • An EVM-compatible blockchain network based on Hyperledger Besu.
  • A permissioned environment where only authorized nodes can participate.
  • Clear separation between environments (dev / pre / pro) to isolate testing and production.
  • Stable access points so that use cases can:
    • Deploy smart contracts.
    • Send transactions.
    • Consult network status.

The goal of this architecture is for use case teams not to have to manage their own blockchain infrastructure, but rather to consume a network managed and monitored by the ISBE infrastructure team.

2. High-Level Vision​

At a very high level, the ISBE network consists of:

  • One or more Besu networks (by environment).
  • A set of validator nodes, which maintain the IBFT 2.0 consensus.
  • Permissioner nodes / bootnodes, which control which nodes can join.
  • Regular nodes, where use case applications connect.
  • Auxiliary services:
    • Block explorer (Blockscout).
    • Monitoring (Prometheus / Grafana).
    • Infrastructure logs and metrics.

Use cases always interact through regular nodes (their own or managed by ISBE), never directly with the validators.

Architecture Diagram​

Diagram Legend:

ColorComponentDescription
🔴 RedPermissioner NodesControl which nodes can join the P2P network
🟡 YellowValidator NodesExecute IBFT 2.0 consensus and generate blocks
🔵 BlueRegular NodesAccess point for use cases (read/write)
🟢 GreenAuxiliary ServicesBlockscout (explorer) and Monitoring (Prometheus/Grafana)
⚪ GraydApp ApplicationsBackends, frontends, and integration services

Interaction Flow:

  1. Use Cases (dApps) → Connect via RPC/WebSocket to a Regular Node

    • Can use a shared node managed by ISBE
    • Or deploy and operate their own regular node

  2. Regular Nodes → Request access via P2P to the Permissioners

    • Must be previously authorized (permissioning process)
    • Public IP and enode must match the request

  3. Permissioners → Authorize and connect with the Validators

    • Maintain the list of authorized nodes
    • Guarantee that only verified entities participate

  4. Validators → Execute IBFT 2.0 consensus with each other

    • Propose and sign blocks (~2 seconds per block)
    • Maintain global blockchain state consistency

  5. Auxiliary Services → Observe and monitor the network

    • Blockscout: Block and transaction explorer
    • Monitoring: Health metrics, performance, and alerts

3. Environments (dev / pre / pro)​

The infrastructure distinguishes three main environments:

  • ISBE-DEV
    Early development and testing environment.
    Used to validate initial technical integrations, deployment tests, and controlled load tests.

  • ISBE-PRE
    Pre-production environment.
    Replicates production conditions with a very similar configuration, but without impact on real data.
    Recommended environment for final testing before moving to production.

  • ISBE-PRO
    Production environment.
    Only mature, versioned, and previously validated use cases from dev and pre are deployed here.
    Operation is more restricted and subject to change policies and maintenance windows.

Each environment has its own independent Besu network, with its own set of validators, regular nodes, and associated services.

4. Main Network Components​

4.1 Validator Nodes​

  • Execute Hyperledger Besu IBFT 2.0 consensus.
  • Responsible for:
    • Proposing and validating blocks.
    • Maintaining blockchain state consistency.
  • Managed by the ISBE infrastructure team.
  • Not used to deploy contracts or to expose RPC to third parties.

For use cases, validators are transparent: their existence only matters in terms of network reliability and performance.

4.2 Permissioner Nodes / Bootnodes​

  • Maintain the list of nodes authorized to join the network.
  • Publish necessary information for regular nodes to connect (enodes, etc.).
  • Guarantee that only nodes belonging to authorized entities are part of the P2P topology.

Use cases do not interact directly with these nodes: permissioning is processed through the procedure described in despliegue-nodos/solicitud-permisionado.md.

4.3 Regular Nodes​

  • Nodes used by use cases to:
    • Deploy smart contracts.
    • Send transactions.
    • Consult state, event logs, balances, etc.
  • Can be:
    • Nodes managed by ISBE and offered as a service.
    • Nodes deployed and operated by each participating entity, following authorization.

At the dApp level, interaction is performed via standard Ethereum RPC/WS endpoints (e.g., HTTP RPC and WebSocket).

5. Segregation Model by Use Cases​

The architecture is designed to support multiple use cases on the same network, maintaining a certain degree of logical isolation:

  • Main isolation is done at the level of:
    • Smart contracts (address space and permissions).
    • Accounts and keys used by each project.
  • Optionally, dedicated regular nodes can be deployed for a specific use case, so that:
    • Traffic from that use case does not affect others.
    • Logs, metrics, and alerts configuration is adapted to its needs.

In all cases, there is a single Besu network per environment, shared, but with good practices of logical and operational segregation.

6. Relation with Other Infrastructure Components​

The Besu network is not isolated: it integrates with other key ISBE components:

  • Blockscout
    Block and transaction explorer connected to the Besu network, allowing to:

    • Browse blocks, transactions, and contracts.
    • Verify deployments and events.

  • Monitoring and Alarms
    Node metrics (validators and regular) are exposed to monitoring systems (Prometheus / Grafana) to:

    • Control network health.
    • Detect incidents.
    • Analyze performance.

  • Application Layers (dApps, APIs, frontends)
    Use cases connect to the blockchain network from:

    • Backends (APIs).
    • Integration services.
    • Frontends that directly consume RPC/WS endpoints.

Only common components are described in this infrastructure documentation. Specific details for each use case are documented in their respective functional and technical artifacts.

7. What This Implies for Use Cases​

For a use case team, the general network architecture implies:

  • No need to deploy or maintain validators.
  • No need to know details of Kubernetes, EKS, or Terraform.
  • It is necessary to:
    • Know the assigned RPC/WS endpoint.
    • Manage their own keys and accounts securely.
    • Respect usage policies and deployment best practices.

Specific details on how to connect to the network and what parameters to use are described in the documents:

  • docs/infraestructura/despliegue-nodos/requisitos.md
  • docs/infraestructura/despliegue-nodos/instalación-nodo-regular.md
  • docs/infraestructura/faq.md