Enlace a la versión doblada al español
Además aquí está la transcripción completa, traducida y revisada para el Canal Cardano Castellano
Transcripción completa
Doblaje al español de “On Alternative Clients and Nodes”
Publicado en el canal de Youtube de Charles Hoskinson el 1 de Septiembre de 2025
Hola, este es Charles Hoskinson transmitiendo en vivo desde la cálida y soleada Colorado. Feliz Día del Trabajador a todos. Es 1 de septiembre de 2025. Haré un video rápido para hablar de algo sobre lo que quiero asegurarme de que no se malinterprete. Hice un AMA, creo que ayer o anteayer, no recuerdo. Y en el AMA hablé sobre la diversidad de clientes. Y ahora de repente hay gente que está viniendo a Twitter que está construyendo clientes alternativos y que se está volviendo loca por algunas de las declaraciones y tratando de tergiversar esas declaraciones. Así que voy a asegurarme de que todos entiendan muy bien mi posición oficial y que no nos desviemos ni un poco de eso. Por eso estoy haciendo un video dedicado solo a esa posición. Así que dice: puedes estar enojado con la CF y está bien, pero no traigas la diversidad de clientes a esto porque la gente lo cree. ¿De acuerdo? Nunca hice eso.
La diversidad de clientes es crucial. Ethereum lo sabe. Solana lo sabe. Todos lo saben. No es alguna característica elegante. Es la base de la descentralización. Puedes argumentar que no trae usuarios, pero hay un límite a lo que los desarrolladores pueden construir sin tener la opción de personalizar sus nodos. Esa es una afirmación verdadera. Y que los desarrolladores no puedan superar ese límite se traduce directamente en que los usuarios no puedan usar Cardano. Y afirma que de alguna manera StarStream es un producto de Dingo o que se beneficia de él. Las tarifas de Babel se benefician directamente de Dolos. Es como, sí, es cierto que usan este tipo de cosas. Bien, así que déjenme dejarlo registrado sobre esto y voy a sacar mi pequeño pizarrón para ustedes.
No estoy en contra de la diversidad de clientes. Siempre hubo desde el principio un plan para la diversidad de clientes. Vivimos en el mundo de los hechos, no de los sentimientos. Entonces, ¿cuál es la evidencia de eso? Bueno, la evidencia son las especificaciones formales. Una especificación formal no es un cliente. Una especificación formal es código independiente, un plano independiente de implementación, de lo que es Cardano. ¿De acuerdo?
Básicamente, esto es cómo construirlo. Entonces, todo el punto de tener especificaciones formales es para la diversidad de clientes. ¿Por qué? Porque si no tienes una especificación formal, entonces el código es la especificación. En otras palabras, el nodo Haskell sería la especificación. Entonces, lo más importante en la diversificación de clientes es un conjunto completo y comprensible de planos para Cardano. E incluso podemos tener planos en múltiples lenguajes. Ahora bien, no tienes que escribir una especificación en un lenguaje formal. Puedes escribir especificaciones en muchos lenguajes diferentes. Puedes escribirlas en TLA. Puedes escribirlas en AGDA. Puedes escribirlas en Coq. Puedes escribirlas en Lean. Puedes escribirlas en Markdown si quieres.
Pero sí tiene que tener algún tipo de rigor y ambigüedad limitada o, si hay ambigüedad, tiene que saber dónde está y dejarlo al desarrollador. Y el punto es evitar particiones de red y el punto es asegurar interoperabilidad. Es por eso que haces estas cosas.
Ahora, el plan original que tuve para la diversidad de clientes en aquel entonces, cuando solo existía Intersect y todos todavía trabajaban juntos, era tener un comité técnico de dirección y un comité de dirección de producto en Intersect y entregar todo el código fuente que estaba en IO, lo cual hicimos, a los GitHub de Intersect. Luego tener un grupo diverso de personas en el comité técnico y en el comité de producto de la comunidad que están construyendo productos y proyectos. Así que los Blink Labs, los TX Pipes y los demás. Y la idea es que comenzarías la diversificación teniendo a muchas más personas alrededor de la tecnología del proceso CIP y de las especificaciones y del propio código del nodo Haskell porque tiene el 100% de la base instalada.
Luego, una vez que los planos estuvieran bien y en los lenguajes que se hubieran acordado, miraríamos dos cosas al mismo tiempo. Lo primero que miraríamos es lo mismo que IBM hizo con el proyecto Fabric, donde tienes un 1.x. ¿De acuerdo? Entonces habría nodo Cardano y al mismo tiempo iniciarías una iniciativa para un —vamos a usar rojo— iniciarías una iniciativa para Cardano 2.x y correrían en paralelo. ¿De acuerdo?
Entonces, seguirías haciendo actualizaciones a Cardano y luego en la otra pista construirías un beta y en algún punto se encuentran en funcionalidad. ¿De acuerdo? Así que se intersectan y dicen: bien, en este lanzamiento ambos lados tienen el mismo conjunto de características. Esto es en realidad lo que estamos haciendo ahora con la billetera Lace. Tenemos la billetera Lace y tiene todas estas diferentes versiones y luego la billetera Lace versión 2.x está en construcción. Se van a intersectar en paridad de funciones en noviembre, más o menos, y Lace 2.0 tiene cosas nuevas, a saber, habilita móvil y habilita escritorio.
La idea detrás de Cardano 2 es que las personas que estarían involucradas en el diseño de esa nueva infraestructura serían provenientes del comité técnico y del comité de producto. Esto no tiene que ser el mismo lenguaje que Cardano. De hecho, la idea que tuvimos es que lo escribiríamos en Rust y lo haríamos una construcción de arquitectura de microservicios. ¿De acuerdo? Entonces podría ser un nodo poliglota, lo que significa que admitiría y habilitaría múltiples lenguajes.
Ahora, al tener ambos, lo primero que podríamos hacer es garantizar que la especificación sea correcta, porque eliminaría toda la ambigüedad de la especificación formal. Y luego crea un buen plano, puedes ir de dos a n si quieres. ¿De acuerdo? Y ahora que tienes una buena especificación y has logrado que dos implementaciones independientes trabajen entre sí, es inmensurablemente más fácil hacer la tercera y la cuarta y la quinta. Porque gran parte de la dificultad es tratar de lograr esa paridad de funciones y verificar que las cosas son correctas y obtener una especificación correcta.
Eso es lo que queríamos hacer. Lo que terminó sucediendo es que en lugar de hacer eso, se creó otra organización llamada Pragma y se convirtió en una conglomeración de constructores y simplemente comenzaron a crear sus propios nodos. Link tenía Dingo y Harmonic está trabajando en uno y todos estos nodos no están contribuyendo activamente a las especificaciones que hemos escrito.
Bien, entonces, ¿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 tienen que trabajar juntos. Así que, como mínimo, los equipos de desarrollo tienen que coordinarse. Entonces no hubo financiamiento de la fundación para la coordinación. No hubo financiamiento provisto por ningún actor para la coordinación. Así que Input Output pagó por reunir a la gente en un taller de diversidad de nodos y tenemos una relación económica con algunos de los constructores del lado de Pragma como Sundae y TXPipe y otros, y lo que hemos hecho es simplemente contratar gente para trabajar con nosotros y lo que estamos tratando de hacer ahora es asegurarnos de tener un conjunto completo de especificaciones. Lo que intentamos hacer también es asegurarnos de que todos los nodos funcionen entre sí.
De hecho, Input Output está usando algunos de los nodos diversos en su pila de productos. Concretamente, con Blockfrost, actualmente están integrando Dolos, que es un nodo de datos, en el diseño de nodo completo que tenemos para un nodo completo Mithril que se está construyendo como reemplazo del Daedalus de escritorio.
Bien. Así que, en realidad, valoramos el trabajo que hacen los otros constructores. Creemos en la diversidad de clientes. Pensamos que es algo muy necesario. Nuestra frustración ha sido mayormente que normalmente se hace el proceso de uno a dos y, al principio con Ethereum, hicimos eso. Gavin Wood tenía el cliente en C++ y Jeff Wilchie tenía el cliente en Go. Bien, lo cual nos permitió verificar independientemente la especificación y había dos especificaciones principales: el documento amarillo de Ethereum y la otra especificación era el conjunto de pruebas del EVM que la fundación Ethereum publicó.
Incluso usamos ese conjunto de pruebas para nuestro cliente en Scala para Mantis en aquel entonces. Así que creemos en la diversidad de clientes. Pensamos que la diversidad de clientes es algo importante. Hay formas en que puedes hacerlo que no son adversariales y no crean fricción y hay formas en que puedes hacerlo que crean un alto costo de coordinación y mucho retrabajo.
La política trabajó en una dirección particular y la creó de una forma particular. Ya sabes, no te quejas de eso, lo arreglas. Pero que nadie diga que pensamos que es una mala idea tener clientes competidores y múltiples clientes como lo demuestra el hecho de que desde el principio lo planificamos con especificaciones y porque queríamos que se hiciera de una forma responsable y segura desde el principio también queríamos hacer algo como esto.
De hecho, Cardano 2 quise hacerlo en 2020. Teníamos los contratos iniciales de 5 años desde 2015 hasta 2020 y queríamos empezar a trabajar en la siguiente versión. Elegimos Haskell como la primera versión porque era la forma más sencilla de adherirse a una especificación rígida. Pero siempre tuvimos un plan para ser más de un lenguaje. De hecho, tuvimos un grupo en Rust y un grupo en Scala y construimos una versión en Rust de Cardano. Eso es lo que ejecutó la red de pruebas incentivada y las versiones antiguas de Catalyst. Se llama proyecto Jormugandr. Y en el lado de Scala, estábamos experimentando con usar Scala como un posible nodo permanente para poder llevar Cardano al ecosistema Java.
¿Qué pasó? Nos atascamos con la entrega de características y todo tomó mucho más tiempo y fue mucho más difícil y no planificamos tan bien como pudimos haberlo hecho y entregamos en un período de 24 meses todo desde Shelley hasta contratos inteligentes y tuvimos que lidiar con todas las consecuencias posteriores de esas dos cosas gigantescas seguidas por las consecuencias posteriores de la gobernanza y ahora finalmente estamos digiriendo todo eso.
Finalmente estamos en el último gran hito que es Basho y ya lo hemos conceptualizado con los CIP y Hydra y todas estas otras cosas. Y sabemos cómo hacer Leios y sabemos cómo hacer Hydra y hemos estado avanzando. La idea es que una vez que tienes todo ese paradigma establecido, tienes un conjunto final de especificaciones y luego puedes empezar a construir mucha diversidad de clientes a partir de todas las lecciones aprendidas.
Algunas personas quisieron adelantarse un poco al grupo. Está bien. Es solo que en algún momento tienen que llamar a casa para asegurarse de que sus clientes hablen con nuestros clientes, porque el 100% de la red sigue corriendo en el nodo Haskell. Así que si no haces eso, creas una partición y destruyes cualquier atisbo de interoperabilidad y creas problemas de seguridad.
Otra cosa en la que queríamos trabajar es en la idea de un cliente certificado. Así que un cliente certificado básicamente sería una marca de seguridad y calidad donde si tienes una especificación, un auditor puede verificar que tu nodo o cliente sigue esa especificación y, por lo tanto, está certificado, porque la gente a menudo pregunta cuál es el cliente “oficial” de Cardano.
Y mi respuesta es que no hay ninguno, pero me gustaría clientes certificados, donde se cree evidencia de que esos clientes siguen la especificación. Suena bastante simple, ¿verdad? Así que esa fue otra razón por la que quería un proceso como este, porque lo primero en certificarse entonces sería el Cardano 2.x y así tendríamos un proceso de certificación construido al mismo tiempo que se construyen las versiones finales de la especificación.
Luego, cuando financias cosas en el presupuesto, lo que puedes hacer es decir, bien, vamos a pagar por características. Vamos a pagar por la base. La base son todas las características fundamentales del sistema. Y luego vamos a pagar por la certificación. Realmente no tiene mucho sentido pagar solo por un conjunto de características si no funciona con Cardano. Y no tiene sentido hacerlo funcionar con Cardano para tener características nuevas, interesantes y diferentes si no es seguro o no hay garantía de que en realidad esté siguiendo la especificación.
Tienes que tener las tres cosas para que ese cliente sea correcto. Entonces, la esperanza era que cuando la gente pidiera financiamiento de Catalyst, obtuvieran financiamiento para las tres cosas, o cuando pidieran financiamiento del tesoro, obtuvieran financiamiento para las tres cosas. No tenemos un programa de certificación. No está construido. He estado tratando de construirlo y hemos estado trabajando muy diligentemente y duro. Esta es una de las razones por las que hemos pedido creo que más de una docena de veces poder unirnos a Pragma.
Hasta ahora no hemos podido porque esa sería la cosa por la que abogaríamos. Realmente nos importa la interoperabilidad. Realmente queremos vivir en un entorno multicliente. Pensamos que es algo bueno para la descentralización. Es algo bueno para encontrar errores en la especificación y estas características independientes que son diferentes de las características estándar desde interfaces hasta otras cosas en el nodo Haskell. Tiene sentido tener esa diversidad de clientes.
Eso significa que tenemos que hacerlo de una manera responsable. Si todos forman parte del mismo comité técnico y de producto, todos tienen derecho a ser escuchados. Si tienes comités fragmentados, no hay comunicación o hay comunicación limitada detrás de las decisiones del día a día que la gente está tomando. ¿En qué se traduce eso? Más dinero, tiempos de entrega más lentos y una mayor probabilidad de un defecto o un problema de seguridad.
Es un hecho. Si la gente no coordina y no habla entre sí, esas cosas surgen. Y una tentación más fuerte de acelerar la entrega de características y la entrega de la base para destacarse o ganar adopción. Si eres más rápido al mercado, entregas más cosas, mayor es la probabilidad de que puedas obtener más adquisición de clientes. Pero si no certificas, es a costa de la calidad. Y hemos visto esto en muchos otros ecosistemas.
Por eso quería pasar de uno a dos a n. Y quería empezar con un grupo independiente de personas todas en un mismo lugar con una organización basada en miembros. Y todos trabajarían juntos y lo sacarían adelante. Originalmente, la Fundación Cardano se suponía que debía ser esa organización basada en miembros. Reitero esto una y otra vez porque es relevante para esta historia en particular, en que ellos habrían controlado el comité de dirección técnica, el comité de dirección de producto y el código fuente.
Sería irresponsable ceder ese código para siempre al titular de la marca registrada, al titular del CIP o a una junta que no es responsable ni electa. Porque si toman decisiones arbitrariamente, como expulsarte del comité de dirección técnica, no tienes recurso y no hay forma de que puedas controlar eso.
Mientras que en una organización basada en miembros, tienes una junta elegida por la comunidad. Es simplemente sentido común y es buena gobernanza, razón por la cual incluso las grandes compañías, compañías Fortune 500, tienden a usar la Fundación Linux, la Fundación Apache, otras, para facilitar este tipo de cosas. Así que Intersect fue creada como un respaldo y tomó bastante tiempo porque muchas de las personas que habrían sido formativas e increíblemente útiles en la gobernanza de Intersect, en lugar de ser parte de Intersect para ayudar a descubrir cómo construir un comité técnico adecuado, literalmente fueron y crearon una organización diferente basada en miembros.
Así que eso fue una muerte cerebral. Básicamente hirió la capacidad de Intersect de navegar y crecer y convertirse en una organización verdaderamente independiente y vibrante. No nos mató. Solo nos ralentizó. Y ahora Intersect es vibrante. Tiene una gran membresía. Están ocurriendo muchas cosas maravillosas. La mayoría de la junta será elegida por la comunidad antes de fin de año. Estamos comenzando a ver independencia y crecimiento en el comité de dirección técnica y el comité de dirección de producto y Pragma e Intersect están trabajando muy bien juntos.
Tomó un tiempo, tomó alrededor de un año para que esa coordinación sucediera y creo que la gente de Pragma está operando de buena fe y simplemente tienen diferencias de opinión y frustraciones previas y cosas así. En algunos casos esas frustraciones fueron altamente alentadas por la CF para ser expresadas plenamente a través de su código y proyectos.
Pero es muy importante que la gente entienda que Input Output no tiene ningún deseo de ver a Cardano continuar como una monocultura detrás de Haskell. Nuestro deseo siempre ha sido un entorno multicliente. Empecé mi carrera de esa manera con Ethereum en 2014 con el cliente en C++ y el cliente en Go.
Intentamos hacerlo de la manera correcta con una especificación formal. Algunas cosas sucedieron que ralentizaron la capacidad de ir multicliente. Pero tuvimos tres equipos de lenguaje diferentes, un equipo Scala, un equipo Rust y un equipo Haskell. Y tratamos muy duro de coordinar y equilibrar todas las diferentes demandas desde demandas comerciales hasta demandas de entrega de características, demandas de investigación, demandas de desarrollo de protocolo y obviamente la política y burocracia entre las diferentes organizaciones.
De hecho, prueba de ello, la primera organización que tuvo la oportunidad de crear una MBO fue la CF. Eligieron la Fundación Linux. El acuerdo que nos dieron después de contratar a Dirk fue que Input Output no tendría permitido unirse al proyecto de código abierto. Tenemos esto documentado en actas con una llamada con la junta de la CF si alguna vez intentaran negarlo.
Ese fue el acuerdo. Yo personalmente no podía unirme o participar e Input Output por extensión no podía unirse y participar en el comité de dirección técnica en el desarrollo del futuro de Cardano. Ese fue el acuerdo que negociaron después de un año de esfuerzo, lo que significó que tuvimos que volver a la mesa de dibujo y Emurgo e Input Output lo asumieron y luego crearon Intersect y pedimos repetidamente a la CF que se uniera.
La CF tenía preocupaciones de que Intersect fuera una organización híbrida con fondos en las Islas Caimán y operaciones en Wyoming. Intentábamos explicarles que Joe Biden estaba intentando matar a la industria de las criptomonedas y que quizás no era una buena idea dejar todos los fondos de Intersect en Estados Unidos dado el entorno geopolítico. Y luego intentaron decir que no había camino para unirse a Intersect mientras ellos tenían una conexión con las Caimán. Desde Suiza tuvieron el descaro de decir esto.
Así que eligieron no unirse a la junta directiva. Ahora son miembros de Intersect. Tomó bastante tiempo que llegaran ahí. De nuevo, esto negó la participación completa en la dirección técnica y la dirección de producto, lo que ralentizó este plan de llevar los planos donde debían estar y llevar los clientes donde debían estar para que pudiéramos llegar a una diversidad de nodos responsable.
Pero de nuevo, IO está usando un producto de TXPipe para Lace y Blockfrost también, que es una compañía de IO. Y seguimos organizando talleres de diversidad de nodos y tenemos una gran relación de trabajo con todos los miembros de Pragma en este punto y seguimos construyendo con ellos y pensamos que son buenos actores actuando de buena fe. Pero sentí que era importante contextualizar cómo llegamos aquí y asegurarme de que mis declaraciones no se malinterpreten porque continuamente se malinterpretan. Tal vez a propósito, tal vez no, pero es realmente, realmente importante que no lo sean.
No es fácil estar en el epicentro de un ecosistema. Hay mucho en juego. Hay millones de personas. Hay mucho ida y vuelta y solo estamos tratando de hacerlo. Tenemos el CIP para Leios. Ahora tenemos que lograr que esos miembros de Pragma contribuyan a ese CIP. Quiero sus nombres en él porque van a tener que construirlo junto con nosotros. Si quieres construir otro nodo, genial. No estás en el viaje por un 20%. Estás en el viaje completo. Ya sea que llueva o nieve o haga sol, ya sea que tengas el techo abajo o haga un frío helado y tu calefactor se rompió, estás en el viaje.
Así que tienen que ser parte de ese CIP. Es muy importante. Están actuando de buena fe. Están trabajando con nosotros y creo que ese será el resultado del proceso. Luego no solo tienen que escribir el CIP con nosotros desde que publicamos el primer borrador, luego tienen que construirlo. No creo que los nodos alternativos tengan suficientes recursos para poder construir Leios en 2026. Esa es mi opinión. Dirijo una compañía de software desde hace más de 10 años y he cometido muchos errores con plazos incumplidos y esfuerzos sin suficientes recursos. Esa es mi opinión dada la complejidad de Leios incluso después de las simplificaciones.
Podría estar equivocado, pero si tengo razón, lo que eso significa es que no podrán lanzar sus nodos alternativos en 2026 si nosotros logramos tener Leios completamente codificado e integrado en el nodo Haskell, a menos que la red quiera esperarlos, lo que significaría que no tendremos Leios en 2026.
El remedio sería financiamiento adicional para ellos si su intención es lanzar comercialmente estos nodos y llevarlos a producción o retrasar Leios. Esos son tus remedios. Así que cuando vienes a mí y me dices que Charles está retrasando Leios y que Charles no está entregando Leios o que IO no está entregando Leios.
Déjame ser muy claro. Actualmente estamos destinando recursos a un modelo de desarrollo 24/7 de seguimiento del sol, lo que significa que tendremos desarrolladores en múltiples continentes en turnos escalonados. Así que trabajan durante el día, la noche y los fines de semana para escribir código en Haskell para el nodo Haskell para Leios. Este es el programa más urgente que tenemos.
Verás esto reflejado en los commits de GitHub y las marcas de tiempo asociadas con ellos y la velocidad del código. Cualquier persona en la división de ingeniería que dijo que no queremos hacerlo o que no creemos que sea posible ha sido reasignada o despedida y se están incorporando nuevas personas cuyo único propósito es hacer esto porque es absolutamente necesario competitivamente que logremos tener Leios. Ha sido retrasado demasiado tiempo. Lo necesitamos en el protocolo. Y lo has visto con ciertas firmas siendo terminadas y nuevas firmas siendo incorporadas que son más ágiles. No fue fácil. No es una decisión fácil.
Algunas de estas personas eran amigos míos. Pero esto es un negocio y este es un ecosistema. Solo puedo controlar eso. No puedo controlar nodos alternativos. Y cuando los admitimos en aras de la diversidad, algo tiene que ceder. Si están con recursos insuficientes y no tienen a las personas adecuadas, no podemos creer razonablemente que serán capaces de implementar rápidamente funciones complejas, si somos intelectualmente honestos.
Entonces, el remedio es o bien que se queden fuera, lo que significa que mientras ellos continúan trabajando, tú no instalas ni adoptas esos nodos, aumentar sus recursos, o que todos nosotros retrasemos. Lo cual entonces plantea la pregunta, ¿para qué hacemos desarrollo 24/7 si al final del día terminamos y se queda en un estante durante un año? ¿Y qué le decimos al ecosistema en su conjunto? Simplemente no construyan en Cardano durante 2026. No viene una actualización.
Si tuviéramos un comité de dirección técnica donde todas las personas relevantes estuvieran en un mismo lugar, podríamos tener una conversación filosófica, económica y estratégica. Al estar separados y no estar en el mismo lugar, no podemos, y solo ocasionalmente podemos tener decisiones de coordinación. Esta es otra razón por la que lo que ha sucedido ha sido competitivamente dañino para el ecosistema Cardano. Realmente no mejora la descentralización porque esas cosas, ahora mismo, aunque se estén construyendo, no tienen cuota de mercado ni adopción. ¿De acuerdo? Y eventualmente lo tendrán a medida que se activen sus conjuntos de características. Pero es muy poco probable que vayan a obtener una mayoría o incluso una minoría fuerte en 2026 de la base instalada. Tal vez lo hagan. Veremos, tal vez no.
También crea un ambiente adversarial donde la gente tiene que ir a justificar instalar su nodo para atacar a los desarrolladores Haskell que están entre los más talentosos y con más antigüedad en nuestro ecosistema. Tienes que comparar y contrastar. Y las innovaciones del nodo Haskell tienen que ser disminuidas o minimizadas de alguna manera para que estos otros nodos ganen cuota de mercado. De lo contrario, ¿por qué cambiarías a una cosa nueva?, a menos que resuelva un problema muy particular.
Así que es mejor trabajar juntos y coordinarse para que no nos volvamos inadvertidamente adversarios y digamos cosas que son dañinas e hirientes y que expulsen a la gente. Es un gran costo de coordinación. Es un gran gasto, y cuando financiaron a IO, una de las cosas por las que pagaron fue para que siguiéramos en el rol de coordinador jefe y reuniéramos a la gente para bien o para mal y tratáramos de lograr que hablen entre sí y cooperen entre sí sin importar lo que se diga en Twitter.
Así que esa era parte de la financiación implícita que estaba detrás del trato blockchain, la financiación del tesoro. Así que lo haremos y seguiremos teniendo talleres de diversidad de nodos. Seguiremos trabajando con otras personas. Seguiremos trabajando en las especificaciones. Seguiremos trabajando en los CIPs y seguiremos avanzando. Y creo que dentro de unos pocos años tendremos todos estos componentes donde tienen que estar y habrá entre tres a cinco clientes activos en el ecosistema Cardano.
Seguiremos invirtiendo en la Fundación Haskell. Seguiremos invirtiendo en el nodo Haskell. Creemos que Haskell es un buen lenguaje, especialmente dado el compromiso de 10 años que hemos tenido y las innovaciones que hemos hecho y seguiremos invirtiendo en una implementación en Rust. Se llama Proyecto Acropolis y está construyendo esa arquitectura de microservicios del nodo Rust y mi esperanza es eventualmente una unificación a largo plazo del marco de cadenas asociadas y el nodo Rust para Cardano. Así usamos un marco para eso. Para que las cadenas asociadas puedan beneficiar a Cardano. Para que el desarrollo de Midnight pueda beneficiar directamente al desarrollo de Cardano en lugar de estar segregados y diferentes.
Así que ahí es donde estamos. Y cada vez que veo algo como esto en Twitter que tiene el potencial de ser malinterpretado o inflamatorio de alguien que está construyendo directamente uno de estos nodos, es muy importante que nos aseguremos de que todos estemos en la misma página. Input Output no está en contra del entorno multinodo multicliente. Input Output está tratando de facilitar eso. Tuvimos una diferencia de opinión sobre la estrategia para llegar allí. Dimos la bienvenida a la gente a esa estrategia. Otros actores entraron y decidieron convencer a la gente de girar hacia una estrategia diferente. Así que estamos donde estamos y no me toca a mí escoger dónde caen las cartas. ¿De acuerdo? Juegas las manos que tienes.
Y entonces la pregunta que ahora hacemos es cuál es el resultado que queremos. El resultado que quiero es que Leios se lance el próximo año, encontrar un camino para hacerlo. Que el nodo Haskell continúe creciendo en su velocidad, eficiencia y conjunto de características. Que innovaciones importantes como StarStream y Midgard se abran camino hacia Cardano para que podamos obtener componibilidad y escalabilidad masiva de ello. Que haya un despliegue eficiente del ecosistema de cadenas asociadas para que podamos atender todas las necesidades de Bitcoin DeFi y XRP DeFi y también me gustaría que hubiera de tres a cinco clientes con horizonte, es decir, dentro de 12 a 24 meses puedan empezar a competir.
Por nuestro lado en Input Output, cuando instales la billetera Lace una vez que tengamos un grado razonable de seguridad allí, espero que podamos llegar a un concepto de cliente certificado, le daremos a cada usuario de Lace la opción de qué backend quiere instalar, ya sea el nodo Haskell si quieren hacer un nodo completo o un Rust o un TypeScript o un Go u otros porque hay otros nodos que la gente está construyendo. Así que me emociona darle la opción al usuario y dejar que lo hagan. Y francamente creo que Dolos con una integración Mithril va a ser el primer nodo completo que despleguemos a través de Lace en el espíritu de diversidad de clientes.
A largo plazo, me gustaría ver una segregación entre empresa y minorista. Entonces, el lado empresarial, me gustaría ver tecnologías como Linkerty y Kubernetes y Kafka usadas como un arnés para contener microservicios que se ejecutan en contenedores. Y eso significa que puedes escalar horizontalmente y tienes autorreparación con tiempo de actividad 24/7. Así que puedes ejecutar en múltiples sistemas al mismo tiempo y usar eso para empresa. Así que echagnes, backends de DAPP y SPOS’s.