El rastreador DevX señala brechas de compatibilidad de Dijkstra en 110 herramientas de Cardano

La evaluación pública mapea dependencias en 206 herramientas e identifica los cambios ascendentes necesarios para la compatibilidad con Dijkstra. Sus hallazgos cubren versiones específicas de software probadas contra la versión preliminar de cardano-node 11.2.0.

By SongMarketCap

Updated:

Cardano News - El rastreador DevX señala brechas de compatibilidad de Dijkstra en 110 herramientas de Cardano

La Cardano DevX Initiative ha publicado un rastreador público de preparación para el hard fork Dijkstra, clasificando 110 herramientas como “Breaks after HF” en su evaluación del 1 de noviembre. La designación identifica una brecha de compatibilidad en el código publicado de una herramienta o en sus dependencias. Input Output destacó el rastreador en su último informe semanal de desarrollo.

El mapa conecta los hallazgos con el código fuente, las incidencias de desarrollo y los resultados de pruebas, mostrando qué componentes necesitan cambios y qué otras herramientas dependen de ellos.

La evaluación de Dijkstra abarca 206 herramientas de Cardano

DevX revisó un catálogo de 268 herramientas e incluyó 206 cuyo código distribuido interactúa con partes del protocolo afectadas por Dijkstra. De las 62 herramientas excluidas, 41 carecían de código fuente público, 18 no tocaban interfaces o estructuras cambiadas, y tres coincidían solo a través de pruebas o ejemplos.

La evaluación publicada enumera 110 herramientas como “Breaks after HF”, nueve como “In progress”, cuatro como “Ready for HF” y cuatro como “Target component”. Otras 45 permanecen no verificadas, mientras que 34 se apartaron con motivos documentados, incluidos abandono o uso limitado.

“Ready for HF” significa que una herramienta ha publicado su propio soporte y no tiene dependencias sin resolver rastreadas por la evaluación. “Not verified” significa que no se ha confirmado ninguna brecha de compatibilidad, pero la herramienta no ha obtenido un resultado satisfactorio. DevX etiqueta los datos como en revisión y sujetos a cambios.

Las dependencias ascendentes definen el orden de las correcciones

El rastreador modela 19 pasos ascendentes que podrían eliminar barreras de dependencias para 82 herramientas. Su secuencia propuesta prioriza las herramientas adicionales que cada paso desbloquearía después de que se hayan abordado las dependencias anteriores.

Los primeros cinco pasos implican cardano-db-sync, Blockfrost, Ogmios, Koios y Kupo. En conjunto, esos cambios eliminarían las barreras rastreadas para 45 de las 82 herramientas. Blockfrost y Koios dependen de db-sync, mientras que Kupo depende de Ogmios.

Algunos proyectos también requieren cambios en su propio código, por lo que actualizar solo una dependencia no completaría su migración. El mapa distingue esos casos de las herramientas que esperan totalmente el soporte ascendente. Sus clasificaciones describen las revisiones examinadas; las versiones posteriores deben evaluarse frente a esa instantánea.

[NEWSBREAK]

Los resultados del devnet guían el seguimiento de los mantenedores

Después de que se etiquetó cardano-node 11.2.0, DevX volvió a ejecutar la evaluación contra la versión preliminar. Los 39 resultados de tiempo de ejecución que podían compararse en versiones idénticas de componentes coincidieron con la evaluación anterior.

La actualización pasó cardano-c y Plutarch a estado listo tras sus lanzamientos de soporte para Dijkstra. Adder pasó a in progress, mientras que el nodo, la CLI, la submit API y cardano-testnet se clasificaron como target components porque forman parte de la propia versión de referencia.

Cardano-node 11.2.0 sigue siendo una versión preliminar cuyas notas de lanzamiento aún no recomiendan su uso en mainnet. Probar contra ella no constituye la activación de la era Dijkstra.

El siguiente paso anunciado por DevX es enviar paquetes de diagnóstico a los mantenedores de componentes con fallos de devnet confirmados, incluidos Ogmios, Kupo, db-sync, Pallas, CML y gOuroboros. Cada paquete está destinado a documentar el fallo, proporcionar pasos de reproducción e identificar las herramientas bloqueadas por él.