Cardano entra en una etapa decisiva de desarrollo con cuatro versiones del nodo, una red pública de pruebas y ventanas tentativas para el hard fork Dijkstra entre finales de 2026 y marzo de 2027.
***
- La primera fase de Dijkstra busca llevar Nested Transactions y Linear Leios a la red principal antes de terminar 2026.
- Cardano-node-11.2 incorporará el conjunto de funciones de Dijkstra para pruebas, pero no será el candidato del hard fork ni incluirá los elementos de Leios.
- La ventana de confianza moderada para activar Dijkstra va del 5 de diciembre de 2026 al 4 de enero de 2027, pero la de alta confianza se extiende hasta marzo de 2027.
🚨 Cardano prepara Dijkstra para 2026-2027
La fase 1 busca llevar Nested Transactions y Linear Leios a Mainnet antes de acabar 2026.
Node 11.2 será para pruebas. 11.3, candidato al hard fork. 12.0, versión final prevista.
Ventanas: 5 dic 2026-4 ene 2027 y 24 feb-26 mar 2027. pic.twitter.com/5NEjYKHNib
— Diario฿itcoin (@DiarioBitcoin) September 7, 2026
Cardano prepara hitos clave para Dijkstra entre finales de 2026 y 2027
Cardano se encamina hacia una etapa de desarrollo especialmente relevante con la evolución de la era Dijkstra, una actualización que incorporará nuevas capacidades para la red y exigirá coordinación entre operadores, desarrolladores y participantes de la gobernanza. El plan contempla un despliegue en dos fases, con Nested Transactions y Linear Leios como primeros componentes, seguido por Peras en una actualización posterior dentro de la misma era.
De acuerdo con la información difundida por Intersect, el objetivo actual consiste en llevar la primera fase a la red principal antes de que termine 2026, aunque el calendario todavía depende de pruebas técnicas y de la preparación del ecosistema. La segunda fase, centrada en Peras, tiene como referencia el segundo trimestre de 2027 mediante un hard fork intra-era, es decir, un cambio de protocolo que ocurriría sin inaugurar una nueva era.
Una actualización dividida en dos fases
Dijkstra representa un conjunto amplio de cambios para Cardano, por lo que su despliegue se organizó de manera incremental en lugar de concentrar todas las funciones en una única activación. La primera fase reunirá Nested Transactions y Linear Leios, mientras que Peras quedará programado para una etapa posterior, una separación que busca facilitar las pruebas y reducir la complejidad operativa.
Nested Transactions forma parte de las capacidades que los desarrolladores podrán comenzar a evaluar en entornos de prueba, junto con Plutus V4 y CIP-50, una propuesta de mejora de Cardano incluida en el nuevo conjunto de funciones. Linear Leios, en cambio, está estrechamente relacionado con el consenso y la producción de bloques, por lo que sus componentes requieren una evaluación específica dentro de la infraestructura del nodo.
Intersect señaló que el trabajo actual avanza en tres frentes: el desarrollo del software del nodo, la preparación de las herramientas utilizadas por proyectos y operadores, y la adaptación general del ecosistema. Esa coordinación resulta importante porque una actualización de protocolo no depende únicamente del código central, sino también de que los participantes tengan tiempo para probar, actualizar y detectar incompatibilidades.
La separación entre funciones disponibles para pruebas y componentes destinados al candidato de lanzamiento permitirá que Cardano avance de forma gradual. El diseño también ofrece a los desarrolladores un espacio para experimentar con las nuevas herramientas antes de que exista una decisión definitiva sobre la activación en Mainnet, sin convertir cada prueba temprana en una confirmación de fecha.
El calendario de versiones del nodo
El primer lanzamiento señalado en el cronograma es Cardano-node-11.1.1, previsto para el 7 de septiembre y destinado a su uso en Mainnet. Esta versión elimina el sistema de rastreo heredado y corrige problemas conocidos relacionados con Genesis, por lo que funciona como una actualización de mantenimiento y preparación antes de las versiones con las capacidades de Dijkstra.
Cardano-node-11.2, previsto para septiembre, tendrá el conjunto de funciones de Dijkstra listo para pruebas. Sin embargo, no será el candidato de lanzamiento del hard fork y no incluirá los elementos de Leios, porque estos se encuentran vinculados principalmente con el consenso y la producción de bloques, sin impedir por ello la evaluación de las demás funciones.
La versión 11.3 está prevista para llegar durante el mes siguiente o los dos meses posteriores, según el calendario presentado, y será el candidato de lanzamiento capaz de atravesar el hard fork. A diferencia de 11.2, esta versión deberá contener toda la funcionalidad de Dijkstra, incluido Leios, de modo que su preparación representará un punto de control técnico más exigente para el ecosistema.
Cardano-node-12.0 será, de acuerdo con la convención de nombres descrita, la versión definitiva del nodo correspondiente al hard fork, aunque todavía no existe un calendario determinado para su lanzamiento. La secuencia 11.1.1, 11.2, 11.3 y 12.0 muestra una progresión desde la limpieza de componentes heredados hasta la versión final, pero no elimina la posibilidad de ajustes derivados de las pruebas.
Redes de prueba, talleres y gobernanza
Después del lanzamiento de Cardano-node-11.2, Cardano habilitará públicamente DijkstraNet para iniciar las pruebas y el desarrollo del conjunto de funciones de la nueva era. Esa red funcionará en paralelo con MusashiNet, que continuará enfocada en probar y evaluar el desarrollo de Leios junto con las funciones de Dijkstra que se estén implementando en DijkstraNet.
La existencia de dos redes de prueba permitirá separar tareas sin aislar completamente los componentes del proyecto. DijkstraNet servirá para revisar funciones como Plutus V4, Nested Transactions y CIP-50, mientras MusashiNet mantendrá el trabajo específico sobre Leios, una división que puede aportar señales más claras sobre el comportamiento de cada área antes de la decisión final.
El calendario también incluye dos talleres sobre diversidad de nodos, con una primera cita en Singapur durante TOKEN2049 el 6 de octubre y una segunda en Londres los días 13 y 14 de noviembre. Estos encuentros forman parte de los esfuerzos de coordinación técnica, ya que una red distribuida necesita evaluar distintas implementaciones, configuraciones y condiciones operativas antes de una modificación importante.
Los participantes en la gobernanza deberán prestar atención además a las enmiendas constitucionales relacionadas con Dijkstra que se presenten públicamente. Tras una recalibración del plan técnico, Intersect situó la ventana de confianza moderada para la posible promulgación del hard fork entre el 5 de diciembre de 2026 y el 4 de enero de 2027, mientras la ventana de alta confianza se extiende del 24 de febrero al 26 de marzo de 2027.
Qué deben vigilar los participantes
Para los operadores de grupos de participación, el primer paso será seguir las versiones del nodo y las instrucciones de actualización que acompañen cada lanzamiento. La preparación no se limita a instalar software, porque también exige comprobar el comportamiento de la infraestructura, revisar compatibilidades y participar en pruebas que puedan revelar problemas antes de una activación en Mainnet.
Los desarrolladores de aplicaciones tendrán un interés particular en las funciones relacionadas con Plutus V4, Nested Transactions y CIP-50, ya que esas herramientas pueden modificar la forma en que se diseñan y prueban determinados productos dentro del ecosistema. No obstante, la disponibilidad de una función en una red de pruebas no equivale a una garantía de activación inmediata ni a una promesa de rendimiento en la red principal.
Los representantes delegados, conocidos como DReps, y otros participantes de la gobernanza deberán seguir tanto las discusiones técnicas como las propuestas de enmienda constitucional. En este proceso, las fechas anunciadas deben interpretarse como ventanas de planificación y no como una confirmación inamovible, especialmente porque la ventana de alta confianza comienza después de la ventana moderada y se extiende hasta marzo de 2027.
La principal señal para los próximos meses será la transición desde las versiones preparatorias hacia Cardano-node-11.3, el candidato previsto para el hard fork, y posteriormente hacia la versión definitiva 12.0. Si las pruebas de DijkstraNet y MusashiNet avanzan sin obstáculos críticos, Cardano podrá acercarse a la primera fase de la actualización; si aparecen problemas, el propio esquema incremental ofrece margen para ajustar el calendario antes de la activación.
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
Artículos Relacionados
Blockchain
XRP Ledger multiplica por 43 el valor de sus activos tokenizados en seis trimestres
Curiosidades
Elizabeth Holmes vuelve al centro del escándalo con un documental secreto de A24
IA
Artificial Analysis cambia su índice tras las dudas sobre la puntuación de GPT-6 Astra
Europa