Parámetros técnicos de la red ISBE
Este documento recoge los parámetros operativos relevantes para los equipos que desarrollan y despliegan casos de uso sobre la red blockchain de ISBE. Incluye únicamente información necesaria para conectarse, desplegar contratos y operar de forma correcta en los entornos públicos (pre, pro).
La red ISBE está basada en Hyperledger Besu y utiliza el mecanismo de consenso QBFT, totalmente compatible con EVM.
Los parámetros de esta página corresponden a la Red Main (UseCase) de ISBE, la red abierta al despliegue de casos de uso, en sus dos entornos públicos: ISBE Mainnet e ISBE Testnet.
ISBE se concibe como un conjunto de redes. El resto de redes de la infraestructura tienen su propia configuración y no están cubiertas aquí; su documentación se publicará cuando estén disponibles para despliegues de terceros.
Entornos públicos
| Nombre público | Entorno | Propósito | Chain ID |
|---|---|---|---|
| ISBE Mainnet | pro | Producción | 33073 |
| ISBE Testnet | pre | Preproducción e integración | 11073 |
Los valores presentados en este documento pueden evolucionar según:
- Entorno (pre, pro): cada entorno puede tener configuración específica
- Fase del proyecto: los parámetros pueden evolucionar entre entregas
- Actualizaciones de red: mejoras, optimizaciones y hard forks posteriores al despliegue inicial
Los valores de este documento están verificados y son la fuente de referencia; ante cualquier duda o discrepancia, confirma con el equipo de infraestructura ISBE.
1. Cliente y versión
La red ejecuta:
- Cliente: Hyperledger Besu
- Versión recomendada: 26.7.1 (actualizada según entrega del proyecto)
- Compatibilidad: EVM (Ethereum Virtual Machine)
- Consenso: QBFT (QBFT es la evolución de IBFT 2.0)
- Algoritmo hash: Keccak-256 (estándar Ethereum)
Besu es un cliente empresarial mantenido por la Linux Foundation, con soporte para redes permissioned y configuración flexible de QBFT.
La versión específica de Besu puede variar según el entorno y la fase del proyecto (MVP, R1, R2). Consulta con el equipo de infraestructura ISBE para la versión exacta de tu entorno.
2. Consenso: QBFT
La red ISBE utiliza QBFT (evolución mejorada de Istanbul BFT 2.0), un mecanismo tolerante a fallos bizantinos donde:
- Un conjunto de validadores propone y firma bloques.
- El bloque sólo es válido si alcanza un quorum de firmas.
- El sistema permite tolerar nodos caídos o no honestos dentro de los límites de BFT.
Parámetros de consenso configurados:
- Block period: 2 segundos (tiempo entre bloques)
- Epoch length: 30000 bloques (para rotación de validadores)
- Request timeout: 4 segundos (timeout de propuestas)
Características relevantes para los casos de uso:
- No existe minería: el consenso es determinístico.
- El tiempo de bloque es estable (2 segundos configurados).
- El comportamiento de las transacciones es predecible.
- No existe reorganización profunda de cadena (reorgs mínimos).
3. Forks de EVM activos
La activación de forks se realiza por timestamp, mediante los campos correspondientes del bloque config del génesis.
| Fork | ISBE Testnet | ISBE Mainnet |
|---|---|---|
| Shanghai | ✅ | ✅ |
| Cancun | ✅ | ✅ |
| Prague | ✅ 10/08/2026 | ✅ 18/08/2026 |
| Osaka | ✅ 27/08/2026 | ✅ 02/09/2026 |
Todas las activaciones se realizaron a las 08:00 UTC de la fecha indicada.
Qué aporta Prague
Prague habilita, entre otros, los precompilados de curva BLS12-381 (EIP-2537), el histórico de hashes de bloque en almacenamiento (EIP-2935) y las transacciones set-code (EIP-7702).
Qué aporta Osaka
Osaka trae tres cambios con impacto directo para quien desarrolla sobre ISBE:
P256VERIFY(EIP-7951): precompilado de verificación de firmas sobre la curva secp256r1 (P-256) en la dirección0x0000000000000000000000000000000000000100. Permite verificar on-chain firmas generadas por Secure Enclave, TPM, WebAuthn/passkeys y tarjetas criptográficas, sin implementar la curva en Solidity.- Tope de gas por transacción (EIP-7825): ver el apartado de límite de gas.
- Cotas superiores en
MODEXP(EIP-7823).
Cómo comprobar el fork activo de un nodo
geth attach -exec "admin.nodeInfo.activeFork" <rpc-url> devuelve el nombre del fork en vigor. geth attach -exec "admin.nodeInfo.protocols.eth" <rpc-url> muestra el bloque config completo, con los timestamps de cada fork.
4. Tiempo de bloque
El tiempo de generación de bloque configurado en ISBE es:
- Tiempo de bloque: 2 segundos (parámetro
blockperiodseconds) - Variabilidad: muy baja (consenso determinístico)
- Adecuado para:
- Protocolos de notarización
- Smart contracts de uso general
- Integraciones backend con latencia predecible
Este block time puede ajustarse si la red requiere optimizaciones posteriores, pero los casos de uso deben diseñarse considerando que la escritura en blockchain nunca es instantánea y siempre implica latencia estructural (mínimo 2 segundos para confirmación).
5. Límite de gas y coste de transacción
ISBE, al ser una red permissioned basada en Besu, no utiliza un token económico. Por lo tanto:
- No existen costes económicos por transacción.
- El gas se usa únicamente como mecanismo de control de ejecución.
- Las transacciones deben incluir un límite de gas razonable para evitar operaciones excesivamente pesadas o bucles infinitos.
Límites configurados
| Límite | Valor | Origen |
|---|---|---|
| Gas por bloque | 30.000.000 (0x1C9C380) | Parámetro gasLimit del génesis |
| Gas por transacción | 16.777.216 (2²⁴) | EIP-7825, activo desde el hard fork Osaka |
| Precio mínimo de gas | 1 Gwei (1000000000) | Parámetro minGasPrice del génesis |
| Tamaño máximo de contrato | 24.576 bytes | Parámetro contractSizeLimit del génesis |
Desde la activación de Osaka, ninguna transacción puede declarar un gasLimit superior a 16.777.216 unidades (2²⁴, aproximadamente 16,7 millones). Es un límite del protocolo introducido por EIP-7825 y es independiente del límite de gas por bloque: aunque el bloque admita 30.000.000, una transacción individual que supere 16.777.216 será rechazada.
Si tus scripts de despliegue fijan gasLimit por encima de ese valor, fallarán. Revisa la configuración de Hardhat, Foundry o de la librería que uses. Para despliegues de contratos complejos, un valor de 10.000.000 es un punto de partida razonable.
Esto permite desplegar contratos complejos sin restricciones artificiales, pero se recomienda evitar:
- Operaciones que no puedan dividirse y que se acerquen al tope de 16.777.216 gas.
- Contratos con almacenamiento masivo en un solo bloque.
- Lógica interna innecesariamente pesada.
6. Chain ID y Network ID
La Red Main (UseCase) de ISBE utiliza un Chain ID distinto por entorno. El Network ID coincide con el Chain ID en cada caso. Ver la tabla de Entornos públicos al principio de esta página.
- Las transacciones firmadas deben incluir el Chain ID exacto de tu entorno.
- Los wallets y librerías EVM deben configurarse con el
chainIdcorrespondiente de la tabla canónica. - Frameworks como Hardhat o Foundry deben usar ese mismo valor en su configuración.
Confirma siempre con el equipo de infraestructura ISBE el Chain ID exacto asignado a tu caso de uso antes de configurar tus herramientas de desarrollo.
7. Tipos de endpoints RPC
Cada entorno expone un único endpoint compatible con Ethereum JSON-RPC, servido por el Filtering Proxy del Cliente ISBE:
-
HTTP RPC: utilizado para todas las interacciones backend (lecturas, escrituras)
- Puerto estándar: 8545 (del Filtering Proxy, no del nodo Besu directamente)
- APIs habilitadas:
ETH,NET,QBFT - CORS habilitado para desarrollo
-
WebSocket RPC: no disponible. El acceso directo al puerto del nodo Besu (propio o compartido) no está permitido por motivos de cumplimiento RGPD; todo el tráfico RPC debe pasar por el Filtering Proxy, que únicamente expone HTTP RPC.
Parámetros de configuración RPC:
--rpc-http-enabled
--rpc-http-host=0.0.0.0
--rpc-http-port=8545
--rpc-http-api=ETH,NET,QBFT
--rpc-http-cors-origins="all"
--host-allowlist="*"
Los casos de uso recibirán las URLs finales de sus endpoints cuando se active su nodo de ejecución o acceso a nodo compartido.
8. Reglas de permisionado
La red es permissioned: cada nodo debe incluirse en la lista de nodos autorizados para unirse al P2P.
El permisionado afecta únicamente a:
- Nodos de ejecución (propios de un caso de uso).
- Nodos validadores y bootnodes (gestionados por ISBE).
El permisionado no afecta a las dApps: cualquier aplicación puede conectarse al RPC asignado sin necesidad de formar parte del P2P.
9. Límites operacionales recomendados
Para garantizar un uso correcto de la red:
- Evitar enviar más de 10–20 transacciones por segundo desde una misma cuenta sin coordinación previa.
- Esperar confirmación de bloque antes de iniciar procesos dependientes.
- Diseñar smart contracts siguiendo patrones de eficiencia:
- Evitar almacenamiento redundante.
- Usar eventos en lugar de almacenar logs internos.
- No hacer loops dependientes de tamaño dinámico sin control.
10. Configuración adicional de nodos
Los nodos ISBE utilizan los siguientes parámetros adicionales de Besu:
Networking:
- Puerto P2P: 30303 (TCP/UDP)
- Host P2P: configurable según despliegue
Métricas:
- Métricas habilitadas por defecto
- Puerto métricas: 9545
- Host métricas:
0.0.0.0
Logging:
- Nivel por defecto:
INFO
Rutas personalizables:
--data-path: Ruta del directorio de datos del nodo--genesis-file: Ruta del archivo genesis.json--node-private-key-file: Ruta de la clave privada del nodo
11. Resumen de parámetros
| Parámetro | Valor |
|---|---|
| Cliente | Hyperledger Besu 26.7.1 |
| Consenso | QBFT (evolución de IBFT 2.0) |
| Tiempo de bloque | 2 segundos |
| Gas por bloque | 30.000.000 gas |
| Gas por transacción | 16.777.216 gas (2²⁴) — EIP-7825, desde Osaka |
| Precio mínimo de gas | 1 Gwei |
| Tamaño máximo de contrato | 24.576 bytes |
| Coste económico | Ninguno |
| Compatibilidad | Ethereum/EVM |
| Chain ID / Network ID | Distinto por entorno — ver sección 6 |
| Puerto RPC HTTP | 8545 |
| Puerto P2P | 30303 |
| Puerto Métricas | 9545 |
| APIs RPC | ETH, NET, QBFT |
| Red | Permissioned |