Skip to main content

Arquitectura general de la red ISBE

Este documento describe la arquitectura lógica de la red blockchain de ISBE desde el punto de vista de los participantes en los casos de uso. No entra en detalle de Terraform, Helm o Kubernetes, sino en cómo está organizada la red y qué implicaciones tiene para las dApps que se conectan a ella.

1. Objetivo de la arquitectura​

La infraestructura de ISBE proporciona:

  • Una red blockchain EVM-compatible basada en Hyperledger Besu.
  • Un entorno permissioned donde solo nodos autorizados pueden participar.
  • Separación clara entre entornos (dev / pre / pro) para aislar pruebas y producción.
  • Puntos de acceso estables para que los casos de uso puedan:
    • Desplegar smart contracts.
    • Enviar transacciones.
    • Consultar estado de la red.

El objetivo de esta arquitectura es que los equipos de casos de uso no tengan que gestionar infraestructura blockchain propia, sino consumir una red gestionada y observada por el equipo de infraestructura de ISBE.

2. Visión de alto nivel​

A muy alto nivel, la red ISBE se compone de:

  • Una o varias redes Besu (según entorno).
  • Un conjunto de nodos validadores, que mantienen el consenso IBFT 2.0.
  • Nodos permisionadores / bootnodes, que controlan qué nodos pueden unirse.
  • Nodos regulares, donde se conectan las aplicaciones de los casos de uso.
  • Servicios auxiliares:
    • Explorador de bloques (Blockscout).
    • Monitorización (Prometheus / Grafana).
    • Logs y métricas de infraestructura.

Los casos de uso interactúan siempre a través de nodos regulares (propios o gestionados por ISBE), nunca de forma directa con los validadores.

Diagrama de arquitectura​

Leyenda del diagrama:

ColorComponenteDescripción
🔴 RojoNodos PermisionadoresControlan qué nodos pueden unirse a la red P2P
🟡 AmarilloNodos ValidadoresEjecutan consenso IBFT 2.0 y generan bloques
🔵 AzulNodos RegularesPunto de acceso para casos de uso (lectura/escritura)
🟢 VerdeServicios AuxiliaresBlockscout (explorador) y Monitorización (Prometheus/Grafana)
⚪ GrisAplicaciones dAppBackends, frontends y servicios de integración

Flujo de interacción:

  1. Casos de Uso (dApps) → Se conectan mediante RPC/WebSocket a un Nodo Regular

    • Pueden usar un nodo compartido gestionado por ISBE
    • O desplegar y operar su propio nodo regular

  2. Nodos Regulares → Solicitan acceso mediante P2P a los Permisionadores

    • Deben estar autorizados previamente (proceso de permisionado)
    • IP pública y enode deben coincidir con la solicitud

  3. Permisionadores → Autorizan y conectan con los Validadores

    • Mantienen la lista de nodos autorizados
    • Garantizan que solo entidades verificadas participan

  4. Validadores → Ejecutan consenso IBFT 2.0 entre sí

    • Proponen y firman bloques (~2 segundos por bloque)
    • Mantienen la coherencia del estado global de la blockchain

  5. Servicios Auxiliares → Observan y monitorizan la red

    • Blockscout: Explorador de bloques y transacciones
    • Monitorización: Métricas de salud, rendimiento y alertas

3. Entornos (dev / pre / pro)​

La infraestructura distingue tres entornos principales:

  • ISBE-DEV
    Entorno de desarrollo y pruebas tempranas.
    Se utiliza para validar integraciones técnicas iniciales, pruebas de despliegue y pruebas de carga controladas.

  • ISBE-PRE
    Entorno de preproducción.
    Replica las condiciones de producción con una configuración muy similar, pero sin impacto sobre datos reales.
    Es el entorno recomendado para pruebas finales antes de pasar a producción.

  • ISBE-PRO
    Entorno de producción.
    Sólo se despliegan aquí casos de uso maduros, versionados y validados previamente en dev y pre.
    La operación está más restringida y sujeta a políticas de cambio y ventanas de mantenimiento.

Cada entorno tiene su propia red Besu independiente, con su propio conjunto de validadores, nodos regulares y servicios asociados.

4. Componentes principales de la red​

4.1 Nodos validadores​

  • Ejecutan el consenso IBFT 2.0 de Hyperledger Besu.
  • Son responsables de:
    • Proponer y validar bloques.
    • Mantener la coherencia del estado de la blockchain.
  • Están gestionados por el equipo de infraestructura de ISBE.
  • No se usan para desplegar contratos ni para exponer RPC a terceros.

Para los casos de uso, los validadores son transparentes: su existencia sólo importa en términos de fiabilidad y rendimiento de la red.

4.2 Nodos permisionadores / bootnodes​

  • Mantienen la lista de nodos autorizados a unirse a la red.
  • Publican la información necesaria para que los nodos regulares se conecten (enodes, etc.).
  • Garantizan que sólo nodos pertenecientes a entidades autorizadas formen parte de la topología P2P.

Los casos de uso no interactúan directamente con estos nodos: el permisionado se tramita a través del procedimiento descrito en despliegue-nodos/solicitud-permisionado.md.

4.3 Nodos regulares​

  • Son los nodos que usan los casos de uso para:
    • Desplegar smart contracts.
    • Enviar transacciones.
    • Consultar estado, logs de eventos, balances, etc.
  • Pueden ser:
    • Nodos gestionados por ISBE y ofrecidos como servicio.
    • Nodos desplegados y operados por cada entidad participante, previa autorización.

A nivel de dApp, la interacción se realiza vía endpoints RPC/WS estándar de Ethereum (por ejemplo, HTTP RPC y WebSocket).

5. Modelo de segregación por casos de uso​

La arquitectura está pensada para soportar múltiples casos de uso sobre la misma red, manteniendo cierto grado de aislamiento lógico:

  • El aislamiento principal se hace a nivel de:
    • Smart contracts (espacio de direcciones y permisos).
    • Cuentas y claves utilizadas por cada proyecto.
  • Opcionalmente, se pueden desplegar nodos regulares dedicados a un caso de uso concreto, de forma que:
    • El tráfico de ese caso de uso no afecte a otros.
    • La configuración de logs, métricas y alertas esté adaptada a sus necesidades.

En todos los casos, se trata de una única red Besu por entorno, compartida, pero con buenas prácticas de segregación lógica y de operación.

6. Relación con otros componentes de la infraestructura​

La red Besu no está aislada: se integra con otros componentes clave de ISBE:

  • Blockscout
    Explorador de bloques y transacciones conectado a la red Besu, que permite:

    • Navegar por bloques, transacciones y contratos.
    • Verificar despliegues y eventos.

  • Monitorización y alertas
    Métricas de los nodos (validadores y regulares) se exponen a sistemas de monitorización (Prometheus / Grafana) para:

    • Control de salud de la red.
    • Detección de incidencias.
    • Análisis de rendimiento.

  • Capas de aplicación (dApps, APIs, frontends)
    Los casos de uso se conectan a la red blockchain desde:

    • Backends (APIs).
    • Servicios de integración.
    • Frontends que consumen directamente endpoints RPC/WS.

En esta documentación de infraestructura sólo se describen los componentes comunes. Los detalles específicos de cada caso de uso se documentan en sus respectivos artefactos funcionales y técnicos.

7. Qué implica esto para los casos de uso​

Para el equipo de un caso de uso, la arquitectura general de la red implica:

  • No es necesario desplegar ni mantener los validadores.
  • No es necesario conocer detalles de Kubernetes, EKS o Terraform.
  • Sí es necesario:
    • Conocer el endpoint RPC/WS que se le asigne.
    • Gestionar sus propias claves y cuentas de forma segura.
    • Respetar las políticas de uso y las buenas prácticas de despliegue.

Los detalles concretos sobre cómo conectarse a la red y qué parámetros utilizar se describen en los documentos:

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