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 cuatro categorías principales de nodos:
-
Nodos validadores
Mantienen el consenso QBFT y generan los bloques. -
Bootnodes
Controlan las autorizaciones de entrada a la red P2P. -
Nodos de ejecución
Son los nodos que utilizan los casos de uso para interactuar con la red. -
Nodos de archivo
Almacenan el histórico completo de la cadena para trazabilidad y auditoría.
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 QBFT.
- 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. Bootnodes
Los bootnodes 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 bootnodes.
- Sólo necesitan seguir el procedimiento de
solicitud-permisionado.mdsi desean levantar un nodo de ejecución propio. - En la mayoría de escenarios, utilizarán nodos de ejecución gestionados por ISBE, sin necesidad de pasar por el proceso de permisionado.
4. Nodos de ejecución
Los nodos de ejecución 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.
- 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).
- El acceso RPC, en ambos casos, se realiza obligatoriamente a través del Filtering Proxy del Cliente ISBE, nunca directamente al puerto del nodo Besu, para garantizar el cumplimiento RGPD.
- El Filtering Proxy solo expone un endpoint JSON-RPC (HTTP); no ofrece WebSocket bajo ninguna modalidad.
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 de ejecución propio
Puede ser recomendable si:
- El caso de uso genera mucho tráfico.
- 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 de archivo
Los nodos archive almacenan el histórico completo de la cadena (todos los bloques y estados desde el génesis), a diferencia de los nodos de ejecución, que pueden podar datos antiguos.
Características clave
- Recomendado —no obligatorio— en la configuración Ideal de infraestructura de red; no incluido en la configuración Mínima (ver Requisitos de infraestructura).
- Requieren más recursos que un nodo de ejecución (mayor RAM y disco) debido al histórico completo.
- Habilitan trazabilidad total y capacidad de auditoría regulatoria.
- Exponen un endpoint WebSocket (puerto 8546) de uso estrictamente interno, consumido por Blockscout para indexar bloques y eventos. No es un endpoint accesible por casos de uso.
Qué significa esto para los casos de uso
Los casos de uso no interactúan directamente con los nodos archive. Su función es servir de fuente de datos a Blockscout y a los sistemas internos de auditoría y analítica.
6. Nodos observadores (opcional, no estándar)
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 ni de las cuatro categorías principales, 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.
7. Resumen comparativo
| Tipo de nodo | Rol principal | Exposición RPC | Operador | Uso por casos de uso |
|---|---|---|---|---|
| Validador | Consenso QBFT, generación de bloques | No | Equipo ISBE | No |
| Bootnode | Control de acceso P2P | Limitada | Equipo ISBE | No |
| Ejecución | Lectura/escritura de blockchain | Sí, vía Filtering Proxy | ISBE / Participante | Sí |
| Archivo | Histórico completo de la cadena | Interna (WS, solo Blockscout) | Equipo ISBE | No (indirecto vía Blockscout) |
| Observador | Lectura intensiva (opcional, no estándar) | Sí (read-only) | ISBE / Participante | Opcional |