Skip to main content

Tipos de nodos en la red ISBE

La red ISBE se basa en Hyperledger Besu y utiliza un conjunto definido de nodos con roles diferenciados. Esta separación garantiza la estabilidad del consenso, el control del permisionado y la operatividad de los casos de uso.
Este documento describe los tipos de nodos presentes en los entornos ISBE (dev, pre y pro) y cuál es su función dentro de la red.

1. Visión general​

En la red ISBE existen tres categorías principales de nodos:

  • Nodos validadores
    Mantienen el consenso IBFT 2.0 y generan los bloques.

  • Nodos permisionadores / bootnodes
    Controlan las autorizaciones de entrada a la red P2P.

  • Nodos regulares
    Son los nodos que utilizan los casos de uso para interactuar con la red.

Todos los nodos operan bajo el cliente Hyperledger Besu, con la misma versión y configuración base, cambiando únicamente su rol funcional.

2. Nodos validadores​

Los nodos validadores son los responsables de:

  • Ejecutar el consenso IBFT 2.0.
  • Proponer y validar bloques.
  • Garantizar la coherencia del estado global de la red.
  • Mantener la disponibilidad y confiabilidad del ledger.

Características clave​

  • No exponen RPC para uso general.
  • No permiten el despliegue de contratos ni la ejecución de transacciones desde aplicaciones externas.
  • Están gestionados exclusivamente por el equipo técnico de ISBE.
  • Su número es limitado y estable a lo largo del tiempo para asegurar un consenso controlado y predecible.

Qué significa esto para los casos de uso​

Los casos de uso no interactúan directamente con los validadores. La existencia de estos nodos es transparente, pero crítica para:

  • La estabilidad del block time.
  • La confirmación determinista de transacciones.
  • La ausencia de reorganizaciones profundas.

3. Nodos permisionadores (bootnodes)​

Los nodos permisionadores mantienen:

  • La lista oficial de nodos autorizados a participar en la red P2P.
  • La información de enodes, direcciones libp2p y metadatos necesarios para la conexión.
  • La estructura de topología mínima requerida para que la red funcione correctamente.

Funciones específicas​

  • Verificar que el nodo que se quiere unir está autorizado.
  • Publicar información de descubrimiento para nuevos nodos.
  • Evitar que nodos no autorizados entren en la red.

Qué significan para los casos de uso​

Los equipos de casos de uso:

  • Nunca interactúan directamente con los permisionadores.
  • Sólo necesitan seguir el procedimiento de solicitud-permisionado.md si desean levantar un nodo regular propio.
  • En la mayoría de escenarios, utilizarán nodos regulares gestionados por ISBE, sin necesidad de pasar por el proceso de permisionado.

4. Nodos regulares​

Los nodos regulares son el punto natural de interacción para los casos de uso.
Permiten realizar operaciones estándar del ecosistema Ethereum:

  • Lectura del estado.
  • Envío de transacciones.
  • Escucha de eventos mediante WebSocket.
  • Despliegue de smart contracts.

Características operativas​

  • Ejecutan exactamente el mismo cliente Besu que los validadores, pero sin rol de consenso.
  • Pueden estar operados:
    • Por el propio caso de uso (nodo dedicado).
    • Por ISBE (nodo compartido para varios equipos).
  • Exponen endpoints JSON-RPC y WebSocket.
  • Pueden conectarse mediante HTTP(s) o WSS según configuración del entorno.

Parámetros variables del caso de uso​

Si un caso de uso despliega su propio nodo, deberá proporcionar en el proceso de permisionado:

  • IP pública del nodo: <IP_NODO>
  • Nombre del nodo: <Nombre_nodo>
  • Enode generado por Besu

Cuándo conviene tener un nodo regular propio​

Puede ser recomendable si:

  • El caso de uso genera mucho tráfico.
  • Se necesitan eventos en tiempo real de forma intensiva.
  • Debe garantizarse un nivel de aislamiento superior.
  • El equipo quiere monitorizar completamente sus transacciones y almacenamiento local del estado.

En casos más simples, el nodo compartido proporcionado por ISBE es suficiente.

5. Nodos observadores (si se habilitan)​

En algunos despliegues Besu se habilitan nodos “observadores” o “read-only”, cuyo propósito es:

  • Consultar el estado sin exponer escritura.
  • Hacer mirroring de la información blockchain para análisis, auditorías o dashboards.

En ISBE estos nodos no forman parte de la operativa estándar, pero podrían habilitarse en escenarios de:

  • Monitorización avanzada.
  • Servicios analíticos con alto volumen de consultas.
  • Reproducción de estado fuera del cluster principal.

6. Resumen comparativo​

Tipo de nodoRol principalExposición RPCOperadorUso por casos de uso
ValidadorConsenso IBFT, generación de bloquesNoEquipo ISBENo
PermisionadorControl de acceso P2PLimitadaEquipo ISBENo
RegularLectura/escritura de blockchainSíISBE / ParticipanteSí
ObservadorLectura intensiva (opcional)Sí (read-only)ISBE / ParticipanteOpcional