Contexto de la controversia y la postura de Hoskinson
Charles Hoskinson, el visionario detrás de Cardano, abordó recientemente las interpretaciones erróneas sobre su posición en la diversidad de clientes dentro del ecosistema del protocolo. A través de una comunicación en video a finales de septiembre, Hoskinson reiteró que la diversidad de clientes ha sido un objetivo intrínseco del diseño de Cardano desde sus inicios. Su intervención busca desviar la atención de las tensiones generadas en redes sociales, que, según él, obstaculizan la colaboración en desarrollos clave como Leios.
Hoskinson enfatizó: “No estoy en contra de la diversidad de clientes. Siempre hubo un plan para la diversidad de clientes desde el comienzo. Vivimos en el mundo de los hechos, no de los sentimientos”. Esta declaración subraya la importancia de basar las discusiones en principios técnicos y objetivos de diseño del protocolo.
La diversidad de clientes: un pilar de la descentralización
Para Charles Hoskinson, la diversidad de clientes no es una característica opcional, sino un requisito fundamental para la consecución de la descentralización. Afirmó que esta perspectiva es compartida por otras grandes redes como Ethereum y Solana. “La diversidad de clientes es crucial. Ethereum lo sabe. Solana lo sabe. Todo el mundo lo sabe. No es una característica elegante; es el fundamento de la descentralización”, explicó. Además, destacó cómo esta diversidad permite a los desarrolladores una mayor flexibilidad y elección en la implementación, lo que a su vez impulsa la innovación y la capacidad del protocolo.
La claridad de Hoskinson surge en respuesta a publicaciones de equipos de clientes alternativos en X (anteriormente Twitter), que, según él, tergiversaron sus comentarios en una sesión reciente de Preguntas y Respuestas (AMA). Su objetivo es alinear las expectativas y fomentar una visión unificada para el progreso de Cardano.
Especificaciones formales como cimientos
El núcleo de la argumentación de Hoskinson reside en la confianza de Cardano en las especificaciones formales. Él las describe como el “modelo independiente del código y de la implementación” del protocolo. Subrayó la importancia de estas especificaciones al afirmar: “Si no tienes una especificación formal, entonces el código es la especificación”. Este principio es la razón por la cual IOHK, la empresa detrás de Cardano, invirtió masivamente en especificaciones rigurosas que permiten la coexistencia de múltiples clientes interoperables.
Hoskinson aclaró que estas especificaciones pueden materializarse en diferentes formalismos, siempre y cuando mantengan un alto nivel de rigor y control de la ambigüedad. Ejemplificó que pueden escribirse en TLA, Agda, Lean o incluso Markdown, siempre que cumplan con la precisión necesaria.
Estrategia de diversificación y ‘Cardano 2.x’
Hoskinson reveló una estrategia de diversificación en dos vías que, según él, propuso originalmente para asegurar una expansión “responsable”:
- Mantenimiento del nodo actual: Continuar desarrollando y manteniendo el nodo de Cardano basado en Haskell.
- Implementación independiente: Construir una segunda implementación, denominada “Cardano 2.x”, desarrollada en Rust con una arquitectura de microservicios.
El plan es que ambos nodos operen en paralelo hasta alcanzar la paridad de características, similar a la intersección prevista para Lace 1.x y Lace 2.x. La segunda base de código en Rust no solo validaría las especificaciones sino que también reduciría la ambigüedad, pavimentando el camino para escalar “de dos a n” clientes.
No obstante, el ecosistema tomó un camino más fragmentado, con equipos como Pragma desarrollando sus propios nodos sin una contribución directa a las especificaciones originales. Hoskinson advirtió que esta divergencia aumenta el riesgo de partición de la red y eleva los costos de coordinación si los equipos no se alinean en las especificaciones y pruebas. “¿Cómo evitas cosas como una partición de red y cómo aseguras la interoperabilidad entre pares? Es mucho más difícil. Los equipos deben trabajar juntos”, señaló. Para contrarrestar esto, IOHK organizó un “taller de diversidad de nodos” y está integrando componentes de terceros, como Dolos de Blockfrost, en el diseño del nodo completo.
El impacto en Leios y la financiación de nodos alternativos
El punto central de la discusión fue Leios, la futura arquitectura de escalado de Cardano, que Hoskinson calificó como el “programa más urgente” de la empresa. IOHK ha reestructurado y aumentado su personal para lograr un desarrollo “24/7” del nodo Haskell para Leios, incluso con reasignaciones o terminaciones internas del personal que no estaban alineados con esta visión.
Sin embargo, Hoskinson expresó dudas sobre la capacidad de los equipos de clientes alternativos para integrar el soporte de Leios el próximo año. “No creo que los nodos alternativos tengan los recursos suficientes para construir Leios en 2026… Si tengo razón, eso significa que no podrán lanzar sus nodos alternativos en 2026 si logramos codificar e integrar completamente Leios… a menos que la red quiera esperarlos”, argumentó. La solución, en su opinión, pasa por una mayor financiación para estos equipos o aceptar un retraso en el lanzamiento de Leios.
Programa de clientes certificados y visión a futuro
Para evitar la fragmentación y los retrasos indefinidos, Hoskinson propuso la creación de un programa de “clientes certificados”, vinculados directamente a las especificaciones. Afirmó: “Me gustaría clientes certificados donde se genere evidencia de que esos clientes siguen la especificación y, por lo tanto, están certificados”. Este modelo permitiría estructurar el presupuesto en torno a las características base, la nueva funcionalidad y la certificación, con solicitudes a Catalyst o al tesoro cubriendo estos tres aspectos.
De esta manera, se evitaría financiar características que podrían no ser interoperables o no cumplir con los estándares de seguridad. La certificación también respondería a la pregunta recurrente sobre un “cliente oficial”.
De cara al futuro, Hoskinson reafirmó una hoja de ruta multi-cliente basada en “Project Acropolis”, un nodo políglota de microservicios basado en Rust, diseñado para unificar el marco de cadenas asociadas con el stack principal de Cardano. Visualiza despliegues “empresariales” con microservicios orquestados por Kubernetes y nodos “minoristas” que combinen componentes ligeros como Dolos con Mithril para acelerar la sincronización de nodos completos en menos de una hora. También mencionó la modernización de la red, incluyendo posibles capacidades de pub/sub para cadenas asociadas y dApps, aunque reconoció la complejidad de re-implementar el stack de mini-protocolos de Cardano en otros lenguajes.
Llamado a la unidad en el ecosistema
El mensaje central de Hoskinson fue un llamado a reducir los conflictos en redes sociales y a refocusarse en la entrega técnica y los incentivos compartidos. “Nos hemos enamorado un poco demasiado del drama y un poco demasiado del comportamiento adversarial”, advirtió, señalando que las interpretaciones malintencionadas y las disputas internas podrían crear un “infierno tóxico” que ahuyente a los constructores.
Estableció dos “líneas rojas” personales: acusaciones de conducta criminal y la malversación de fondos destinados a la comunidad. Fuera de esto, se mostró abierto a críticas sobre su personalidad o la compañía. También refutó las narrativas de un bajo rendimiento crónico de Cardano, citando su tiempo de actividad histórica, aunque reconoció las dificultades de 2022-2023 y los retrasos en la entrega de características. Destacó el progreso del ecosistema, que ha entregado hitos como contratos inteligentes y gobernanza en 24 meses, y que ahora está “digiriendo” estas etapas antes de la fase de escalado Basho y Leios.
El video concluyó con un optimismo pragmático de que Leios podría ser el “gran unificador” que alinee a los equipos de clientes en torno a un paradigma compartido, siempre que el ecosistema se comprometa nuevamente con la coordinación, la disciplina en las especificaciones y el respeto mutuo. “El resultado que quiero es que Leios se lance el próximo año… que el nodo Haskell siga creciendo… y también me gustaría que de tres a cinco clientes sean horizontales, lo que significa que en 12 a 24 meses puedan empezar a competir”, afirmó.
Finalmente, reiteró que IOHK tiene la intención de presentar la elección de cliente a los usuarios finales: “Una vez que tengamos un grado razonable de seguridad… daremos a cada usuario de Lace la opción de qué backend quieren instalar… porque me emociona dar al usuario la elección”.
