Input Output propone activar Leios tras el hard fork Dijkstra y avanzar con cautela: el primer objetivo es multiplicar entre tres y cinco veces la capacidad de datos de transacciones de Cardano, mientras que una meta posterior de hasta 10 o 15 veces dependerá de pruebas en la red principal y nuevas votaciones.
***

• La primera etapa de Leios busca entre tres y cinco veces la capacidad actual de Cardano; llegar a 10 o 15 veces exigiría más pruebas y aprobaciones.
• Para activar el sistema, los operadores de pools deberán registrar claves de votación BLS y reunir una proporción de stake cercana al 90% o 95%.
• Las pruebas de MusashiNet alcanzaron casi seis veces el techo de Praos, pero la propia actualización advierte que esos resultados no reflejan demanda real de usuarios.

🚨 Cardano apunta a multiplicar por 3 a 5 su capacidad de datos con Leios, tras el hard fork Dijkstra.

Llegar a 10-15 veces dependerá de pruebas en mainnet y votaciones.

MusashiNet rozó 6 veces el techo de Praos, pero sus resultados no reflejan demanda real. pic.twitter.com/ZHR3hujYQf

— Diario฿itcoin (@DiarioBitcoin) October 20, 2026

Cardano prepara Leios para aumentar su capacidad con un despliegue gradual

La actualización Leios de Cardano apunta a elevar inicialmente entre tres y cinco veces la capacidad actual de procesamiento de datos de transacciones, con la posibilidad de avanzar después hacia una escala de 10 a 15 veces. Input Output presentó un despliegue por etapas que conecta la disponibilidad del protocolo con el hard fork Dijkstra, el registro de claves de votación de los stake pools, pruebas de carga en la red principal y decisiones de gobernanza sobre los parámetros.

El plan no fija una fecha para activar Dijkstra ni plantea que la capacidad máxima llegue de inmediato. La propuesta separa la actualización técnica de la activación efectiva de Leios y de los aumentos posteriores, que dependerán de mediciones en mainnet y de votaciones comunitarias; además, el rendimiento se expresa en datos de transacciones por segundo, no en una cantidad uniforme de operaciones.

El hard fork habilitará el protocolo, pero no activará Leios por sí solo

Según la hoja de ruta difundida el 20 de octubre, Leios llegará junto con el hard fork Dijkstra, que pondrá a disposición las funciones necesarias para el nuevo sistema. Después, los operadores de stake pools deberán generar claves de votación BLS y registrarlas mediante certificados de pool actualizados. Cada registro comenzará a regir en el siguiente límite de época, por lo que la incorporación de los operadores será un paso separado de la actualización de software.

La distinción importa porque instalar Dijkstra no bastará para que la red procese tráfico con Leios. La estimación actual exige que las claves registradas representen aproximadamente entre el 90% y el 95% del stake delegado, un margen considerablemente superior al 75% de stake activo que el sistema requiere para certificar un bloque endosante. Ese margen busca compensar la posible ausencia de pools desconectados o lentos al responder.

Los certificados BLS permiten combinar en un solo certificado las firmas de cientos de pools, en lugar de tratar cada voto como un elemento aislado. Leios necesita esos votos para certificar bloques endosantes, que contienen referencias a transacciones pendientes de procesamiento. Input Output calcula que la participación podría involucrar aproximadamente a los 500 o 900 pools principales, aunque el umbral preciso depende de parámetros que todavía se están finalizando.

Los pools que no registren una clave BLS podrán seguir produciendo bloques Praos, pero no podrán votar sobre los bloques endosantes de Leios. La actualización señala que el registro de las claves no necesita una votación independiente de los representantes delegados ni del Comité Constitucional. Así, la preparación depende de que una proporción suficiente de operadores complete el procedimiento, además de los pasos de gobernanza requeridos para modificar el protocolo.

La capacidad crecerá por etapas y con aprobación comunitaria

Antes de Dijkstra, Input Output prevé una actualización constitucional que definirá los nuevos parámetros y los límites dentro de los cuales la gobernanza podrá cambiarlos. La preparación de esas salvaguardas corresponde al Comité de Parámetros de Intersect, mientras que el equipo de Plutus actualizará el script encargado de hacerlas cumplir. La intención es que las futuras propuestas de rendimiento operen dentro de reglas previamente aprobadas.

Los umbrales de aprobación varían según la decisión. La enmienda constitucional requiere el apoyo de representantes delegados que representen el 75% del stake y de dos tercios del Comité Constitucional. Para el hard fork, los requisitos indicados son el 60% del stake de los DReps, el 51% del stake de los operadores de stake pools y dos tercios del comité.

Los aumentos posteriores de rendimiento también tendrán que superar una votación: requieren el respaldo del 67% del stake de los DReps, el 51% del stake de los operadores de pools y dos tercios de los miembros del comité. Una vez que Leios esté activo, la hoja de ruta contempla ráfagas controladas de tráfico en mainnet para medir entrega de bloques, velocidad de votación, confiabilidad de los certificados y margen de procesamiento disponible en los nodos.

El techo actual de Praos, cercano a 4,5 kilobytes de transacciones por segundo, sirve como referencia para las metas anunciadas. Aplicar los multiplicadores previstos equivale a unos 13,5 a 22,5 TxkB/s en la etapa inicial y entre 45 y 67,5 TxkB/s en la posterior. Estas medidas describen volumen de datos: el número de transacciones que caben en ese flujo depende del tamaño de cada operación.

Las pruebas en MusashiNet mostraron avances y también fallas

En un informe de ingeniería del 20 de agosto, el equipo de Leios reportó que MusashiNet alcanzó un pico de 26,8 TxkB/s, frente a un techo de 4,51 TxkB/s para Praos en mainnet. La relación equivale aproximadamente a 5,94 veces esa referencia, un resultado de prueba que supera el multiplicador inicial planteado para el despliegue, aunque no demuestra por sí mismo el desempeño que tendrá la red principal bajo condiciones reales.

El equipo describió una fase Tierra de 41 días, con más de 127.000 bloques y 63 pools registrados. La carga combinó generación sintética de tráfico con operadores participantes, por lo que las cifras representan el rendimiento de una testnet y no una medición de la demanda de clientes. La diferencia limita lo que puede concluirse sobre la experiencia cotidiana de los usuarios o la capacidad sostenible de la mainnet.

El informe también registró problemas de implementación: fugas de memoria, bifurcaciones de cadena, sincronizaciones detenidas y una interrupción de la red causada por tratar un certificado inválido como un error fatal. El equipo afirmó que corrigió esas fallas. Para el despliegue en mainnet, el plan comienza con configuraciones conservadoras, dado que la red reúne cerca de 2.700 pools registrados con diferencias en equipos, conexiones y configuraciones.

Leios conserva los bloques de clasificación de Praos y añade bloques endosantes cuando el volumen pendiente supera lo que un bloque de clasificación puede transportar. Input Output estima que las transacciones procesadas mediante los bloques endosantes llegarán al ledger en aproximadamente 45 a 60 segundos. El diseño busca aumentar el flujo sin reemplazar la estructura existente de Praos, pero la hoja de ruta condiciona los siguientes ajustes a resultados medidos en la red activa.

Las métricas de aplicaciones no representan toda la actividad de Cardano

En una publicación separada del 20 de octubre, Cardano indicó que 21 de las 103 aplicaciones listadas en su sitio habían habilitado el seguimiento de transacciones. Los proyectos aparecen en el leaderboard una vez que activan esa función, que está abierta a todas las aplicaciones construidas en la red. La proporción equivale a cerca del 20,4% de las aplicaciones incluidas en ese listado.

La cifra describe la adopción del mecanismo de seguimiento, no el volumen total de operaciones del ecosistema. En particular, no permite inferir cuántas transacciones procesan las otras 82 aplicaciones ni concluir que esos proyectos carezcan de actividad. El dato debe leerse como una medida del alcance del leaderboard, no como un censo completo del uso de Cardano.

La actualización también aborda la economía de la red. Input Output afirmó que más del 85% de las recompensas por época proviene actualmente de la Reserva de Cardano y citó una estimación de CIP-164 según la cual los ingresos por comisiones necesitarían un tráfico sostenido de aproximadamente 50 a 70 TxkB/s para alcanzar el punto de equilibrio. La firma describió Leios como una vía para acercarse a ese nivel de actividad, pero advirtió que el protocolo no generará demanda por sí mismo.

La preparación de Dijkstra ya avanzó mediante versiones de software separadas: la versión 11.1.1 del nodo, publicada en septiembre según el reporte, abordó cuestiones operativas antes de entregas posteriores destinadas a incorporar funciones de la nueva era. La hoja de ruta de Intersect en dos fases situó Linear Leios en la primera y Peras en una actualización aparte prevista para el segundo trimestre de 2027; sus fechas son estimaciones sujetas a pruebas y gobernanza.

Dijkstra incluirá funciones que no dependen de la meta final de Leios

La actualización Dijkstra contempla otros cambios además del despliegue de Leios: transacciones anidadas, mejoras de cuentas, scripts de guardia, Plutus V4, recompensas de staking de retiro libre y un parámetro de apalancamiento de pledge. Según Input Output, esas características llegarán con el hard fork y no dependen de que Leios alcance sus objetivos posteriores de capacidad. La separación permite distinguir las mejoras asociadas a la nueva era de los aumentos de rendimiento aún sujetos a pruebas.

El plan se apoya en el hard fork van Rossem del 18 de julio, que llevó la mainnet a la versión 11 del protocolo, tras pruebas y aprobación de los órganos de gobernanza, según informó Intersect. Ese antecedente ofrece contexto sobre el proceso de actualización, pero no establece una fecha para Dijkstra ni resuelve los pasos pendientes de activación. La actualización de octubre tampoco presentó un calendario definitivo para el nuevo hard fork.

Para elevar la capacidad tras la activación, cada propuesta deberá incluir mediciones de la configuración anterior y someterse a los umbrales de gobernanza aplicables. Input Output sostiene que los límites de Leios podrán cambiarse sin otro hard fork si las propuestas respetan las salvaguardas constitucionales aprobadas. En la práctica, el rendimiento objetivo dependerá tanto de la capacidad técnica medida como de que representantes y operadores respalden cada modificación.

Por ahora, el escenario anunciado combina una primera meta de tres a cinco veces la capacidad de referencia con una posibilidad posterior de llegar a 10 o 15 veces. Las pruebas en MusashiNet ofrecen un antecedente alentador, pero la propia hoja de ruta reserva a la mainnet y a la gobernanza la decisión sobre cuánto ampliar el sistema. El despliegue también deja claro que aumentar el espacio disponible para transacciones no garantiza que aparezcan usuarios ni tráfico suficiente.

Imagen original de DiarioBitcoin, creada con inteligencia artificial, de uso libre, licenciada bajo Dominio Público.

Este artículo fue escrito por un redactor de contenido de IA y revisado por un editor humano para garantizar calidad y precisión.

ADVERTENCIA: DiarioBitcoin ofrece contenido informativo y educativo sobre diversos temas, incluyendo criptomonedas, IA, tecnología y regulaciones. No brindamos asesoramiento financiero. Las inversiones en criptoactivos son de alto riesgo y pueden no ser adecuadas para todos. Investigue, consulte a un experto y verifique la legislación aplicable antes de invertir. Podría perder todo su capital.

Suscríbete a nuestro boletín