Transcripción al español de “Road to a Polyglot Ecosystem for Cardano”
Publicado en el canal de Youtube de Charles Hoskinson el 26 de Septiembre de 2022
Enlace a la versión doblada al español
Hola a todos, este es Charles Hoskinson, transmitiendo en vivo desde la cálida y soleada Colorado, siempre cálida, siempre soleada, a veces Colorado. Hoy es 26 de septiembre de 2022. Quería hacer un video para discutir un tema muy importante, algo en lo que pasé la mayoría de la semana pasada, de alguna manera discutir, o está conectado con ello. Así que, como muchos de ustedes saben, hay una gran cantidad de trabajo ocurriendo detrás de escena acerca de construir el andamiaje para una organización basada en miembros, que básicamente sirve como centro de gravedad, que agrega la comunidad, como que determina la voluntad de la comunidad, aparecer con estrategias para ayudarlos ahí, y animar a la gente a ejecutarlas. La parte genial de ello es que es una manera para que todo el mundo comparta su voz. Ahora, la voz funciona de muchas maneras diferentes, está Twitter, Reddit, Telegram, también hay software. Y si vamos a ser un ecosistema saludable necesitamos llegar a un punto donde tenemos un ecosistema políglota, que efectivamente significa que hay múltiples clientes, ejecutándose simultáneamente, con diferentes equipos de desarrolladores, diferentes filosofías, diferentes lenguajes, y francamente diferentes USPs. Así que está este asunto de “¿cuál es el cliente canónico de Cardano?”, y es una pregunta muy similar a “¿cuál es el cliente canónico de billetera de Cardano?”, y la respuesta debería ser “ninguno”. En su lugar, la respuesta debería ser que estamos de acuerdo en estándares, y esos estándares tienen un marco de testeo robusto, y luego tenemos dos tipos de clientes en billeteras, certificadas y no certificadas. Lo que decidí es realizar un video detrás de la encuesta que hizo Rick McCraken, el bueno y viejo Rick, que él creó para nosotros. Tiene una encuesta hipotética, “Si dcSpark presenta una propuesta Catalyst por 8 millones de dólares para construir para otra implementación del nodo Cardano en Rust, y la hace de código abierto, ¿cómo votarías?” y mucha gente dijo “sí, eso es interesante, yo votaría que sí”, es una pregunta justa. Esto es algo en lo que de hecho hemos estado pensando durante mucho tiempo. Comenzamos aquí, este es un proyecto del legado, de la Unión Europea, llamado Priviledge, de hecho recibimos dinero para trabajar junto Guard Time, IBM Research, Universidad Tartu, TV, Universidad de Solano, Universidad de Edimburgo, y aquí estamos nosotros Input Output. Nuestra contribución a ello fue esta idea de aquí, blockchains actualizables, de Nico, Aggelos, Dionisys. Básicamente tuvimos una larga conversación acerca de cómo uno crea un ecosistema donde obteneś seguridad, buena especificación, gran testeo, pero al mismo tiempo tenés múltiples clientes. Así que, detrás de escena hemos estado trabajando con un lenguaje llamado Agda, básicamente es súper Haskell, creamos un montón de infraestructura, estamos comenzando a movernos en esa dirección donde vamos de infraestructura hipotética a infraestructura aplicada. Aquí hay una especie de video de pizarra blanca, manténganse ahí porque vamos a hablar de un montón de cosas, ok.
Básicamente lo que queremos hacer con la MBO, organización basada en miembros, tendrá esta idea de, perdón, mí bloc está actuando un poco raro, tendrá esta idea de CTFs, o compañeros técnicos Cardano, algo así. Y, básicamente estas son personas que trabajan en el núcleo y vienen de la comunidad, así que son miembros de la comunidad, más personal. Así que no pertenecen a una compañía particular, pero en su lugar son prestados de la organización basada en miembros o de hecho trabajan para ella. Pero en cualquier evento, básicamente lo que podemos hacer es que podemos tener este núcleo Agda y eso sería una referencia. Ahora, no es producción, ok, ese no es su punto, no es igual a producción. Producción es lo que ustedes muchachos tienen ahora con Daedalus, tiene toda clase de código extra, toda clase de cosas extra. Básicamente el punto de esa producción es asegurar que tu cliente es muy rápido, cosas como rápido, ya sabés, seguro, cosas de compatibilidad, habrá cosas fuera de especificación, osea cosas propietarias que son construidas dentro de ese ecosistema particular, etc. Por ejemplo, si dcSpark hace su propio cliente yo imagino que probablemente construirían algo de infraestructura especial para conectarla a la billetera Flint, hacerlo un proceso fácil, mientras que como referencia no haría eso. Y sería lo mismo para nosotros, para un nodo, si lo comercializamos probablemente lo conectaríamos a Lace, porque querés una buena experiencia de usuario, no es realmente de lo que se trata una especificación. Así que la idea es que la CTF mantendrá un núcleo, y serían capaces de muy rápidamente enlazar el proceso CIP a un núcleo formal. Luego lo que ocurre, al final del embudo CIP, mientras atravesás todas las etapas del CIP, los CIPs son propuestas de mejora Cardano. Al final de embudo llegás a un punto donde decís “especifiquémoslo”, y debido a que será una especificación formal, con un núcleo activo, lo que podés hacer es realizar una extracción de código. Lo que hace es que la especificación te da código que puede servir como referencia para testeo.
Como que todavía estamos juntando estas piezas, haremos una gran presentación formal. Pero la idea básica es que tenés tu núcleo activo, tenés tu código de referencia extraído. Y luego tendrás un poco de otras cosas, tendrás tu sistema de actualización de referencia, ok, y tendrás tus certificados de billetera y luego finalmente tendrás tu criptografía central, porque la gente probablemente no debería estar desplegando su propia criptografía, deberíamos consolidar en ello, para tener las cosas realizadas. Esto de aquí serviría como marco de referencia para el núcleo Cardano. En paralelo necesitarías algo para las utilidades, infraestructura e integraciones, ese es un tema diferente, esas son cosas como Rosetta, dbSync, etc. Pero por el momento hablamos acerca de clientes en competencia, esta es la manera de realizarlo. Luego podés tomar el cliente Haskell, y decir “hey, ya no es canónico, el cliente Haskell es sólo el cliente Haskell”, luego podés tener un cliente Rust, un cliente Typescript, etc, etc. Luego está esta pregunta de si están certificados o no. Podés tener algunos que son certificados y podés tener otros que no.
La idea básica es que el núcleo activo tendrá un pequeño equipo, quizás de cinco a diez, y como he dicho una combinación de CTFs que básicamente están trabajando para la MBO, y luego desarrolladores que contribuyen desde IO, gente de dcSpark. Básicamente mantienen un sistema de actualización de referencia, mantienen un conjunto de código de referencia extraído, probarán propiedades acerca de él, también mantendrán una certificación de billetera, más la criptografía central del sistema. Luego, si alguien quiere construir un cliente, vos la comunidad, tenés que tener esa pregunta de “¿cómo se que mí cliente es seguro, cómo se que mí cliente está en cumplimiento con el protocolo, que es interoperable, cómo se que el combinador de bifurcación dura funcionará para ese cliente?”, osea que cuando se dispara una actualización todos los clientes actualizan, etc. Hay un montón de preguntas que tendrás como miembro de la comunidad. Efectivamente lo que hace un proceso de certificación es que te da la agilidad de competencia, pero te da la seguridad de estándares. Lo que es realmente bonito es que este núcleo activo, debido a que no es producción, aquí es realmente donde está todo el tiempo del desarrollador. Podés hacer cosas durante semanas aquí, quizás meses, y aquí haces cosas durante años. Porque al final del arco íris tenemos que testearlo en muchas diferentes plataformas, tenés que asegurar la compatibilidad, aquí es todo acerca de decir que tenés un estándar ubicuo, queremos asegurarnos que todo el mundo está siguiendo eso.
Así que aquí es a dónde me gustaría moverme, luego IO estaría feliz de continuar si tenemos bien las económicas, el cliente Haskell, luego podemos agregar mucho más a él, hacerlo menos canónico y más un cliente comercial. Y me gustaría ver una dura competencia, me encantaría ver a dcSpark de hecho siendo el custodio de un nodo completo, un cliente Rust. Y de hecho me gustaría ver al menos un cliente imperativo como un cliente Typescript o cliente Dart, o algo así, para traer tecnologías web, alternativamente sería genial hacer Python, porque pienso que tiene un montón de valor pedagógico, teniendo un cliente Python en nuestro ecosistema. Luego básicamente todos contribuímos a unos pocos CTFs para el núcleo, y luego esto da algo de dentadura al proceso CIP, porque el último paso del proceso CIP sería especificar cosas dentro del núcleo. Ya tenemos una extremadamente eficiente extracción de código, de hecho James Chapman y otros en nuestro ecosistema son extremadamente buenos en esto, han escrito muchos artículos al respecto, ha crecido un montón como buen marco para este tipo de cosas. Luego podemos hablar un montón acerca de qué estándares de seguridad deberían existir. Luego si sos un desarrollador de billetera, dicen “¿qué es una billetera oficial, qué debería ser listado en Cardano.org como billetera recomendada o en cualquier otro de los medios, que son bastante grandes?”. Básicamente podés crear un auto testeo que dice “cualquiera que está certificado es listado en cardano.org”, es así de simple.
Ahora, ¿cuánto tardaría en levantarse esto?, bueno estamos trabajando muy duro para levantar ese MBO, intentar obtener tantos miembros como sea posible, teniendo a la comunidad en todas las juntas, habrá geniales cosas de votación y otras cosas, hay toneladas de cosas de gobernanza en camino, Voltaire está con un pesado pesado desarrollo. En paralelo hemos estado trabajando con nuestro grupo de métodos formales estableciendo estas cosas, hay un montón de emoción en IO en este momento, acerca de esta idea. Mí esperanza es establecer un equipo tan rápido como sea posible para comenzar a hablar de cómo se vería un núcleo activo bajo un nuevo repositorio, que es controlado por la organización basada en miembros. Hay un montón de gente que quería realizar esto hace mucho tiempo, han trabajado hacia ese fin, Todavía tenemos una pregunta interesante acerca de infraestructura de utilidad e integraciones, osea el futuro de dbSync, GraphQl, el futuro de Rosetta, el explorador blockchain, Smash, hay un montón de cosas, y también hay un montón de cosas geniales de la comunidad como TX Pipe, Scrolls, este tipo de cosas. Creo que merecen nuestra justa consideración.
Sería bonito si tenemos una noción de dos tipos de compañeros técnicos. Así que tenés algunos que trabajan en infraestructura de utilidad e integraciones y otros que trabajan en el núcleo. Tener alguna idea de grupos de proyectos y programas que comprometerían recursos a un montón de estas cosas de la comunidad, y luego Catalyst también puede financiar eso. También podría haber bonitas contribuciones de compañías en el ecosistema Cardano, donde contribuyen CTFs para trabajar en ello. Nosotros ciertamente lo haremos, pero da un bonito lugar para infraestructura canónica o estándares de infraestructura de utilidades que básicamente está operando bajo un modelo de núcleo abierto. Así que la gente lo tomaría como lo hace con Firefly, comercializarlo a su propia manera.
Pero espero que ayude a todo el mundo, sólo para resumir, espero que no haya sido demasiado complejo. Pero la idea es que querés como un plano, ese plano te da algo de criterio de aceptación. Luego tendrías múltiples opiniones y esas opiniones son los clientes. Ahora, ¿quién debería construir el plano?, bueno, eso debería ser construído y ser canónico por la comunidad. Básicamente establecés el núcleo activo y luego lo que hacés es que los titulares de Ada voten, dirán “ok, este es el Cardano canónico”, y esa es la fuente de verdad. Así que incluso si el cliente Haskell, por ejemplo, está fuera de especificación, tendríamos que cambiar el código para realizar la especificación con ello. Lo que es genial es que han habido tantos avances para métodos formales, que de hecho esto se está convirtiendo en un proceso bastante liviano. Ahora, hay un aviso, si querés realizar métodos formales, como prueba por simulación entre la referencia y la producción, ese es un proceso súper pesado, toma años realizarlo, pero sólo escribir una especificación no es tan difícil y de hecho hay un video encantador de la comunidad TLA Plus, realizado por Leslie Lamport, lo que él hizo es, es un ganador del premio Turing, como Silvio Micali, como que inventó los sistemas distribuidos. Leslie inventó un lenguaje llamado TLA Plus para trabajo de especificación, luego hacer extracción de código, es un lenguaje más liviano pero un montón de los ingenieros en Microsoft, incluso hay un libro llamado Practical TLA, utilizan esto en producción para el equipo XBox, descubrieron problemas de memoria, lo utilizan para Azure, lo utilizan a través de la infraestructura y realmente ayuda a limpiar su código, crea una fuente de verdad a través de muchos miles y miles de ingenieros. La mayoría de las compañías grandes tiene alguna forma de lenguaje de especificación para realizar todas estas cosas. Otra cosa es que el lenguaje de especificación también podría ser extendido para especificación de contratos inteligentes.
En resumen, espero que ayude a todo el mundo a razonar esto, creo que nunca ha habido un momento más emocionante para Cardano, supongo que la computadora se tildó ahí por un segundo. De todos modos, nunca ha habido un momento más emocionante para Cardano, estoy bastante feliz con la forma en que se están moviendo las cosas. Nos estamos acercando mucho a hacer las cosas de una manera completamente diferente, es como la base de años de investigación, comenzamos con subvenciones de la Unión Europea, científicos jugando durante años en estas cosas, un montón de trabajo de métodos formales, la gente simplemente se acostumbró a rápidas y fáciles actualizaciones, se acostumbraron a un montón de magia que tiene Cardano, para hacer que eso continúe trabajando como ustedes muchachos están acostumbrados, pero teniendo un ecosistema políglota, necesitás alguna fuente de verdad y luego estándares para certificación. Porque para la gente pagando por los servicios, no puede ser subjetivo, tiene que ser objetivo. Así que la única manera de realizarlo, en mí mirada, es tener una organización basada en miembros, un programa de compañeros técnicos, tener un grupo de mantenedores de especificaciones centrales que básicamente toman los CIPs y los convierten en especificaciones, y eso como que se convierte en el cimiento para que la gente certifique contra ello. Luego los detalles particulares de implementación como la utilización de Protobufs, esta cosa o la otra, eso realmente no importa mucho. Lo que realmente importa es que adhieras a ciertas directrices acerca de seguridad, rendimiento, así como también un paquete de testeo canónico, ese paquete de testeo, al igual que el que mantiene la Fundación Ethereum para la EVM, es como una fuente de verdad para los diferentes clientes que uno produce. Pero tenemos que ir más allá de ello, necesitamos un estándar para un sistema de actualización descentralizado, así que el combinador de bifurcación dura tiene que ser abstraído y portado, para que pueda ser conectado a múltiples bases de código, y necesitamos algo de adhesión a ello, para que tengamos fáciles actualizaciones durante el camino.
Así que en esta coyuntura, creo que la mejor utilización del dinero, si ustedes muchachos van a enviar más de 8 millones a dcSpark, es tenerlos trabajando en infraestructura de utilidad e integraciones, necesitamos eso urgentemente, necesitamos mejores herramientas de desarrollo, necesitamos cosas como lo que han realizado con Flint, que su versión de dbSync sea escalada, y definitivamente deberían ser financiados para eso. Para clientes canónicos, creo que el primer paso es tener realizado el cliente Agda, tendremos una gran propuesta para ello, hablaremos de ello en Noviembre, mientras juntos desplegamos el MBO el próximo año tendremos una propuesta para que ese equipo llegue a donde tiene que ir, ciertamente nosotros compartiremos nuestra justa parte de recursos, al igual que otros que están muy emocionados. Creo que muy rápidamente podemos llegar a una especificación de cimientos para un montón del gran trabajo que ha sido realizado. Luego tiene un montón de sentido que se forme un consorcio, y que ese consorcio habla durante los próximos cinco años acerca de cómo realizamos grandes innovaciones, tener un montón de competencia con esas innovaciones, osea que haya muchos equipos de desarrolladores.
Así que sos una de las personas a las que le gustaría construir especificaciones y estándares, mantené en mente que habrá una gran oportunidad para hacer eso. Si sos una de las personas que quiere construir clientes competitivos, pensás que tu compañía es genial, entonces también contactanos, porque sería bonito realizar un consorcio para todas estas cosas.
Así que de todos modos, espero que esto ayude a todo el mundo a pensar al respecto, siempre quieren razonar cuidadosamente acerca de estas cosas. Gracias Rick por establecer la encuesta, comenzó una conversación que yo creo que es muy necesaria, acerca de cómo continuamos descentralizando. Parte de ello es a través de gobernanza, parte de ello es a través de gobernanza en cadena, más votación, parte de ello es asegurándonos que continuamos creciendo el nivel de descentralización de los operadores de stake pools, así que un montón de trabajo tiene que ser realizado para facilitar eso. Parte de ello son herramientas de votación más fáciles, pero también parte de ello es más descentralización entre los equipos de desarrollo. El problema es que cuando obtenés más descentralización terminás en una situación donde si no lo gestionás de manera correcta, no podés actualizar fácilmente, porque el problema de coordinación se vuelve demasiado difícil. Así que necesitás una fuente de verdad y un estándar para seguir, alguna forma de estructura social, un programa de certificación que obliga a la gente a seguir. Y si tenés toda esa infraestructura, de hecho yo soy bastante optimista de que seremos capaces de mantener nuestra velocidad de innovación, pero al mismo tiempo de repente tener más de tres o cuatro clientes compitiendo, mordiéndose entre sí, y hemos construído un gran marco para ello. Así que gracias a todos por escuchar, espero que ayude, muchachos los veré pronto.