Saltar al contenido principal
Chile Stake Po [CHIL]

Blog

Leios llega a mainnet: así será el camino con Dijkstra

Redacción CardumenRedacción CardumenCardano

Samurái Musashi con sus dos espadas (tachi y kodachi) saliendo de un dojo hacia el amanecer. Ilustración de la serie Leios de ChileStakePo.

# Leios llega a mainnet: así será el camino con Dijkstra

En agosto te contamos qué es Ouroboros Leios y por qué es la apuesta de Cardano para escalar. Terminamos con una aclaración honesta: por entonces Leios vivía en una red de pruebas (testnet), no en mainnet, y no había fecha.

Hoy ya hay camino. El 20 de octubre de 2026, Input Output (IOG) publicó cómo Leios llegará a mainnet: junto con el próximo hard fork (bifurcación dura), Dijkstra. La promesa es grande: multiplicar el rendimiento de Cardano sin tocar su seguridad. Pero lo primero que hay que entender es que no es un interruptor. Es un camino por etapas, con votos de gobernanza en cada tramo. En esta entrega te explicamos qué viene y qué mejora de rendimiento trae.

Qué es Dijkstra

Dijkstra es el nombre del próximo hard fork de Cardano. Un hard fork actualiza las reglas del protocolo: todos los nodos se pasan a la versión nueva y, desde ese punto, la red opera con reglas distintas.

Dijkstra trae a Leios, pero no viene solo. En el mismo paquete llegan:

  • Nested transactions (CIP-0118): transacciones que pueden contener otras (swaps atómicos sin DEX y fees pagados en otros tokens).
  • Account enhancements: enviar ada directo a una dirección de cuenta, lo que permite cobrar una fracción del piso actual de 1 ada.
  • Guard scripts: chequeos compartidos que se ejecutan una vez por transacción, en lugar de que cada DApp los pague por separado.
  • Plutus V4: la actualización de contratos inteligentes que habilita estas capacidades.
  • Recompensas de staking retirables libremente: retiras tus recompensas cuando quieras, y la delegación a un DRep pasa a ser una decisión aparte.
  • Pledge leverage: un parámetro que conecta las recompensas del pool con cuánto pledgea su operador.

Estos cambios llegan con el fork y no dependen de que Leios alcance sus metas de rendimiento. Leios es una pieza del paquete, no todo el paquete.

El camino en cinco pasos

IOG describe el rollout en cinco hitos, y el orden importa:

  1. Actualización de la constitución. Se agregan guardrails para los nuevos parámetros de Dijkstra, para que la gobernanza pueda cambiarlos después del fork.
  2. Hard fork Dijkstra. Cardano pasa a las reglas nuevas, incluido Leios.
  3. Registro de llaves BLS. Los operadores de stake pool (SPO) registran las llaves con las que votarán en los endorser blocks.
  4. Ejercicios de carga en mainnet. Ráfagas de tráfico planificadas para medir cómo viajan los endorser blocks y los votos por la red real.
  5. Aumento de throughput. Al menos dos actualizaciones de parámetros, respaldadas por la evidencia de mainnet y por votos de gobernanza.
Diagrama oficial de IOG del recorrido de Leios hacia mainnet: actualización de la constitución, hard fork Dijkstra, registro de llaves BLS, ejercicios de carga y aumento de throughput.
El recorrido de Leios hacia mainnet en cinco etapas. Imagen: Input Output (IOG).

La clave es la distinción: el hard fork hace que el protocolo esté disponible; el registro de BLS hace posible la votación; y las actualizaciones de parámetros deciden cuánto trabajo puede manejar Leios. Ese aumento de capacidad no necesita otro hard fork.

Por qué Praos tiene un techo

Para entender qué cambia, hay que entender por qué Cardano hoy tiene un límite.

Hoy Cardano usa Ouroboros Praos. En promedio, un pool gana el derecho a producir un bloque cada 20 segundos. Para que Praos funcione dentro de sus supuestos de seguridad, cada bloque nuevo debe llegar al resto de la red antes de que sea probable que se produzca el siguiente. Mainnet deja unos 5 segundos para esa entrega.

Como los bloques deben viajar dentro de ese presupuesto, no pueden crecer indefinidamente. El resultado es un techo de throughput de unos 4,5 TxkB/s (kilobytes de transacciones por segundo). Praos alcanza para la demanda normal, pero un lanzamiento concurrido, un airdrop o un movimiento de mercado puede llenar la cola. Y ajustar solo los parámetros de Praos sube el techo hasta cierto punto, no más.

Hay un segundo problema en los picos: la mempool de un nodo Praos guarda unas dos bloques de transacciones. Cuando se llena, deja de aceptar nuevas y las wallets tienen que reintentar hasta que haya espacio. Ese tiempo de espera ocurre antes de que la transacción entre a la mempool, así que las mediciones de inclusión no capturan la demora real que siente la gente.

Qué cambia Leios

Leios mantiene los bloques de Praos (los llama ranking blocks) y suma una segunda pieza: los endorser blocks.

Cuando las transacciones pendientes superan lo que cabe en un ranking block, el productor puede anunciar un endorser block. Un endorser block no contiene las transacciones: contiene una lista ordenada de referencias a transacciones. Los nodos toman esa lista, ven cuáles transacciones ya tienen en su mempool y descargan las que faltan.

Después viene la votación. Al inicio de cada época, los pools más grandes por stake ocupan asientos en un comité de votación (CIP-164 habla de unos 900 asientos, que representan ~99% del stake activo). El comité valida el endorser block y, si cada transacción es válida, firma un voto con su llave BLS.

Cuando llegan votos que representan al menos el 75% del stake activo, las firmas se combinan en un certificado de unos cientos de bytes. Un ranking block posterior incluye ese certificado, y las transacciones del endorser block entran al ledger.

Además de los bloques, Leios agranda la mempool. CIP-164 reserva espacio para al menos dos ranking blocks más dos endorser blocks. Esa cola más grande hace que, durante un pico, la transacción se quede esperando dentro de la red en lugar de que la wallet tenga que reintentar el envío una y otra vez. Y cuando el tráfico supera lo que Praos puede procesar, el mayor rendimiento acorta el tiempo entre el envío y la inclusión de la transacción.

Sobre los tiempos: una transacción que cabe directo en un ranking block se incluye tan rápido como hoy. Una que pasa por un endorser block llega al ledger en unos 45 a 60 segundos.

El aumento por etapas, no de golpe

Leios arranca con parámetros conservadores y crece por etapas. El objetivo inicial es unas 3 a 5 veces el techo actual de 4,5 TxkB/s — es decir, entre 13,5 y 22,5 TxkB/s. Al menos dos actualizaciones de parámetros posteriores apuntan a unas 10 a 15 veces — entre 45 y 67,5 TxkB/s. Para quien usa la red, eso se traduce en más transacciones por bloque, confirmaciones más rápidas y comisiones que se mantienen bajas sin importar la demanda. Más allá de eso, manda la demanda, lo que necesiten los builders y la economía de operar la red.

¿Por qué por etapas? Porque mainnet tiene condiciones que una red de pruebas no puede reproducir: unos 2.700 pools registrados, repartidos por continentes, con hardware, software y conexiones distintas, y valor real en juego. MusashiNet (la red de pruebas de Leios) probó mucho, pero no todo.

También hay un motivo económico. Hoy más del 85% de las recompensas por época vienen de la Reserve, y esa contribución se reduce época a época. Con el tiempo, las comisiones importarán más, y CIP-164 estima que haría falta un tráfico sostenido de unos 50 a 70 TxkB/s para cubrir costos solo con comisiones. Leios abre una ruta hacia ese nivel de actividad, aunque no crea la demanda por sí mismo.

Cada aumento lo vota la gobernanza: los representantes delegados (DRep) con 67% del stake, los SPO con 51% y el Comité Constitucional con 2/3. El fork en sí requiere 60% de los DRep y 51% de los SPO.

Qué puedes hacer para prepararte

  • Si operas un pool: corre un nodo listo para Dijkstra, participa en la votación del hard fork y registra tu llave BLS después de la actualización.
  • Si eres DRep: vas a evaluar la actualización de la constitución, el hard fork y cada aumento de parámetros.
  • Si construyes (wallets, exchanges, SDKs, indexers, dApps): prueba la release de Dijkstra en los testnets públicos y sigue la capacidad que la gobernanza realmente apruebe.

Fuentes

Etiquetas: , , ,