Transcripción al español de un fragmento de “Post-Roadmap Comments and Some Reddit Questions”
Del minuto 09:00 al 27:22 del video original
Publicado en el canal de Youtube de Charles Hoskinson el 6 de Junio de 2019
Agradecemos la contribución del buscador AMA de adatainment.com por ayudar a encontrar preguntas relevantes
Ir a la versión doblada al español
Han habido preguntas acerca de priorizaciones y no priorizaciones y tambíen acerca de la dirección de la arquitectura de Cardano, una de las cosas que apareció es la discusión acerca de qué vamos a hacer con KEVM y IELE y el marco K en general. Esta fue una de las investigaciones de alto riesgo / alto rendimiento, tenemos varias partes de investigación de alto riesgo / alto rendimiento en la agenda. Una fue Ouroboros, todo el concepto de “¿puedes hacer prueba de participación?”, eso fue de muy alto riesgo, no estaba completamente decidido en el ecosistema si era incluso teóricamente posible, cuando le preguntas a la gente de prueba de trabajo, del lado de Bitcoin, incluso hoy siguen diciendo que no es posible.
Así que en 2015 esta era una gran pregunta abierta y han habido algunos proyectos que hicieron cosas pero fueron cosas sin rigor o a escala masiva, hay comunidades que no estarán de acuerdo pero el hecho de que ninguna criptomoneda de las top 15 o 20 estaban ejecutándose en un sistema de prueba de participación fuera de unos pequeños ejemplos que entraban y salían, te inclina el estados de las cosas. Decidimos invertir una enorme cantidad de dinero, tiempo y esfuerzo tratando de lograr esa investigación de alto riesgo / alto rendimiento. Esa parte del proyecto fue abrumadoramente exitosa, no sólo debido a Ouroboros, ahora estamos delante de todos en términos de un estable y hermoso diseño para prueba de participación y estamos en la fase de sintonía fina y en los detalles, donde hay un montón de gente que aún continúa explorando su espacio de diseño y tratando de darse cuenta las formas óptimas de realizar las cosas.
Misión cumplida diría yo con ese hilo de investigación, hay un grado de inevitabilidad y determinismo ahí, donde las cosas que queríamos hacer serían realizadas, eso es asombroso. Lo segunda investigación de alto riesgo / alto rendimiento fue este concepto de cadenas laterales e interoperabilidad a través de estructuras cómo NiPoPoWs y cadenas laterales de prueba de participación, esta fue otra de las ideas de alto riesgo / alto rendimiento porque puedes terminar pasando años sólo pensando maneras de hacer esto y esto toma mucho pensamiento profundo y es un objetivo muy amplio y en movimiento porque básicamente lo que quieres lograr con esto es este concepto de “me enviaste una transacción de una cadena local o externa, osea de esta criptomoneda o de otra, yo no tengo la blockchain, sólo tengo una pequeña cantidad de información y de alguna forma igual quiero tener la misma seguridad que una persona que posee toda la blockchain de ese activo y pueda verificar que el activo no se ha gastado dos veces y el activo existe”. Si puedes resolver este problema obtendrás clientes livianos asombrosos, realmente ayudas en el lado de la escalabilidad y además poder hablar con un montón de sistemas y trabajar en una manera mucho más natural.
Este ha sido uno de los pilares del proyecto, algo que exploramos mucho y otra vez es investigación de alto riesgo / alto rendimiento y gracias al duro trabajo de Dionysis Zindros y Aggelos Kiayias y de un montón de nuestros colaboradores con los que hemos hecho investigación y hemos tenido profundas discusiones de detalles, también sentimos que esa dirección tiene un grado de inevitabilidad, como la investigación de prueba de participación, estoy muy contento con eso.
El tercer pilar de alto riesgo / alto rendimiento fue este concepto de construir una idea modelo de programación para criptomonedas, es algo que tiene mucho sentido, no sólo para los contratos inteligentes, pero también para como los contratos inteligentes interactuarán con el mundo más amplio. No se trata sólo de escribir código Solidity y hacerlo funcionar en Ethereum, ese es el corazón de una Dapp, es también el hecho de que la aplicación va a estar hablando con cosas que viven fuera de una blockchain, hay cosas que viven en tu computadora, en un servidor de confianza, en una federación de servidores o quizás una confederación de blockchains todas hablándose. Así que esta este concepto de código onchain y offchain que de alguna forma tienes que reconciliar y tienes que averiguar cómo construir aplicaciones donde tengo determinismo y predictibilidad donde la necesito y ese es un gran problema, si no lo hacemos bien tienes cosas como el Dow Hack o el Parity Hack, además arroja temas de rendimiento y escalabilidad y este tipo de cosas.
Ok ¿Cómo de hecho vas a construir el sistema dónde no solamente puedes resolver todas las cosas y puedes obtener exactitud simétrica pero tambíen el sistema tiene un rendimiento razonable para todos los usuarios, no sólo un grupo en particular o para una ventana de tiempo particular, pero cuando vas de mil a diez mil a cien mil a un millón, etc que las cosas se muevan en la dirección correcta? Todo el mundo está obteniendo un rendimiento razonable y nosotros implícitamente sabíamos esto, por ejemplo tenemos Netflix, tenemos Google, Amazon, Facebook y estos servicios gigantes que a pesar del hecho de tener de millones a billones de usuarios y a pesar del hecho de que estos usuarios realmente están llevando estos sistemas a sus límites, son muy intensivos, subiendo videos, transmitiendo contenido, haciendo decenas de miles de búsquedas todo el tiempo, igualmente, de alguna forma obtienes una experiencia bastante buena.
Así que la clave es poder tomar esas ideas y lecciones y ponerlas dentro de un modelo que de alguna forma es descentralizado y preserva tu confianza y tu privacidad y este tipo de cosas. Es un gran desafío, así que los cimientos de todo esto es tu modelo computacional y tus lenguajes de programación en los que escribes tus contratos inteligentes. Nosotros tomamos un enfoque muy pragmático, o puedes estar del lado funcional del mundo o puedes estar del lado imperativo del mundo. Puedes mirar a lenguajes como Java y C++ y JavaScript o Python o puedes mirar lenguajes cómo Lisp, Haskell, Camel, Clouser, etc. Lo que dijimos es, tenemos suficiente dinero, exploremos ambos caminos y tratemos de innovar en esos espacios con un ojo primeramente en exactitud formal y segundo teniendo una bonita huella hacia la amplia escala de interoperabilidad, porque al final del día los desarrolladores van a querer escribir en lenguajes con los que se sientan confortables y familiares dentro de su dominio. Nos gustaría que usen las herramientas, que usen las cosas que les interesan.
Un equipo liderado por Phil Wadler y luego por Manuel Chakravarty, junto con Phil Wadler y muchos otros, exploraron el lado funcional del mundo y están entre las personas más calificadas del mundo para explorar eso, porque crearon lenguajes de programación funcional como Haskell y han estado en el espacio por más de 30 años y colectivamente el equipo tiene más de 100 años de experiencia, así que ese equipo tuvo ideas como usar una plantilla de Haskell, implementar DSL para las cosas onchain. En el caso de Marlowe es un DSL Turing incompleto para modelar contratos financieros y en el caso de Plutus es un lenguaje de programación Turing completo con todo el poder pero mucho más liviano que Haskell y permitamos al código offchain ser un más viejo lenguaje de programación con mucha historia, tradición y herramientas alrededor de él. Y la idea es que este modelo de dos capas es algo que se ejecuta on y offcchain, el onchain es DSL y el offchain es un lenguaje de programación de propósito general, sería una buena plantilla si podemos jugar en ese dominio y obtenemos un montón de poder, somos capaces de escribir especificaciones formales para contratos, será fácil de aproximarse y seremos capaces de usar propiedades de testeo y modelos de chequeo y todas estas herramientas que necesitas o deberías usar cuando estás escribiendo código de alta seguridad. Los contratos inteligentes quizás sean la definición del código que debería ser de alta seguridad, si es código que será muy utilizado en una configuración muy hostil, eso es conciso con una bien definida lógica de negocio detrás de él, ese es código que deberías verificar.
Así que ese lado del proyecto ha sido abrumadoramente exitoso, nos tomó dos años para realmente llegar a un punto donde sabíamos el camino exacto para atravesarlo, pero ahora vemos progreso consistente semana a semana, mes a mes. No solo estamos innovando ahí, sino que estamos mejorando el estado de la situación en el mundo de programación funcional, no sólo para las criptomonedas sino en general. Por ejemplo, IOHK esta activamente contribuyendo a los desarrolladores desde el esfuerzo Haskell a Web Assembly, puedes tomar código Haskell, código Plutus y compilarlo para ser ejecutado en Web Assembly. También estamos contribuyendo activamente al programa GHCJS lo que significa que puedes tomar código Haskell y convertirlo en JavaScript. Estos son esfuerzos vitales así que puedes desplegar tu código offchain, tu nodo en el explorador y otros lugares y esa infraestructura que estamos construyendo puede trabajar con aplicaciones web sin tener que ser traducidas o reportadas, simplemente funciona a través de una cadena de compilación que puedes experimentar con Rust y otros lenguajes. Ese trabajo viene muy bien y estamos validando que ese modelo funciona a través de Hackathons así que estamos llevando lo que tenemos y se lo damos a los desarrolladores, obtenemos retroalimentación de ellos acerca de a dónde nos dirigimos, estamos viendo una gran aceleración ahí.
Segundo, en el otro lado, el lado imperativo, no es muy difícil innovar ahí porque es un espacio muy amplio y hay mucho por hacer, pero no quisimos sólo hacer algo como por ejemplo una nueva máquina virtual y decir “tenemos una nueva máquina virtual” o tomar una fracción de una máquina virtual existente como la de Java o mirar a Web Assembly y de alguna forma traducir con un modelo gas y decir que tenemos algo como lo que Ethereum está tratando de hacer. En ese caso particular queríamos explorar algo un poco más general y amplio y es por eso que realmente estamos enamorados del marco de trabajo K e ideas que el equipo de Gregorio ha tenido con runtime verification. Otra vez, siendo investigación de alto riesgo / alto rendimiento, demos un paso atrás, tiremos el dado y veamos cuán lejos podemos llevar esta investigación. Pusimos un capital de unos pocos millones de dólares para mejorar K, estamos escribiendo K y Haskell, explorando técnicas y conceptos como compilación semántica y también tratando de mejorar el rendimiento del código generado por máquina.
Ha habido éxito ahí pero no fue lo suficientemente lejos para nosotros como proyecto para sentirnos cómodos diciendo que para el 2020 esta colección de tecnología será viable para consumerización y definitivamente llevará al mercado una asombrosa experiencia para los desarrolladores. Así que tuvimos que dar un paso atrás y decir que la estrategia debía ser cambiada un poco. Los conceptos son grandiosos, este concepto de decir que puedes escribir en cualquier lenguaje de programación, escribir las semánticas de ese lenguaje de programación y luego, de repente, a través de la magia del espacio de la compilación semántica, todos los programas escritos en ese lenguaje pueden ser compilados para funcionar el la máquina virtual IELE, eso sería mágico, porque significa que para tener soporte para tu lenguaje de programación todo lo que tengo que hacer es simplemente escribir la semántica de ese lenguaje una vez y guardarla digamos en la blockchain y de repente todos esos programas pueden funcionar en mi sistema. Es un juego en el que con el tiempo puedo dar soporte a cientos y eventualmente miles de lenguajes de programación. Además, nunca tengo que reescribir mis compilaciones cuando actualizo el núcleo de la máquina virtual, sólo tengo que actualizar las semánticas del caso para esa máquina virtual y de alguna forma todo se ocupa de sí mismo.
Esto todavía sigue en investigación activa, en la academia, en runtime verification y hay otros participantes que han sido testigo del poder de K. Quad Stamp por ejemplo está usando K para especificar formalmente cosas como el ERC20, la especificación 21 y además Elrond que es un proyecto que creo está basado en Romania recientemente escribió un backend K, así que pueden explorar la máquina virtual K para EVM y explorar IELE, etc.
Estamos en buenos términos con estos proyectos y hablamos con ellos y mientras reducimos la prioridad de esa corriente igual lo estaremos siguiendo, pero para ser claros la interoperabilidad con KEVM, con IELE, con Solidity esta no es una cosa dura de hacer, lo hemos explorado con la testnet CL de Cardano, lo ejecutamos el año pasado, hemos escrito Mantis, sabemos cómo escribir una máquina virtual Ethereum desde cero, lo hemos hecho dos veces. No será difícil para nosotros traccionar eso dentro del apilamiento por el bien de la interoperabilidad. Y si este es un deseo que la comunidad tiene realmente no tomará mucho esfuerzo, dinero o tiempo, así que decidimos focalizarnos en dónde tenemos la mayor explosión para nuestro dinero en términos de innovación, del lado funcional y traer algo nuevo al espacio y traer todo un nuevo grupo de desarrolladores dentro del espacio para así poder obtener grandes experiencias y grandes aplicaciones de eso.
Y del otro lado, KEVM y IELE, no se están yendo, básicamente ha sido reducida su prioridad y los examinaremos más adelante. Todo el espacio se está moviendo rápido del lado imperativo, tenemos muchas opciones y francamente no necesitamos escribir nuevo código, simplemente podemos tomar algunas de las mejores prácticas del mercado y traerlas por el bien de la interoperabilidad si esto es una alta prioridad.
Esta es la naturaleza de estos proyectos, a veces cuando estás haciendo investigación de alto riesgo / alto rendimiento, algunas de las investigaciones funcionan realmente bien, por ejemplo el caso de las cadenas laterales y prueba de participación. Otras investigaciones toman más de dos años para tener una visión clara de a dónde tienes que ir, es lo que pasó con Plutus, luego funcionó muy bien. Y otra investigación es tan poderosa y amplia que en algunos casos no sabes bien a dónde tienes que ir y te das cuenta de que quizás no darás en el blanco.
Así que ahí es donde estamos, en términos de Rina ese es otro ejemplo de investigación de alto riesgo / alto rendimiento que hemos estado haciendo y lo que hicimos es reducir el alcance a algo que sentimos que podemos implementar en el plazo 2020. El equipo de red de IOHK ha trabajado por más de un año implementando este concepto de mini protocolo y en algún punto lanzaremos una bonita pieza de documentación explicando cómo funciona este diseño. Lo que hicimos fue aislar muchas de las cosas que pensamos que son realmente grandes innovaciones en el espacio del protocolo y tratar de aplicarlas a la necesidad del espacio de las criptomonedas. También examinamos muy cuidadosamente las necesidades de Ouroboros y las cosas particulares que tendrás que hacer para lograr buen rendimiento y que funcione bien y fuimos capaces de extraer eso y ponerlo en un apilamiento de red para Cardano. Si estás interesado en eso tenemos un repositorio Github donde ese código fue escrito, creo es Ouroboros network o Cardano network, no me acuerdo exactamente el repositorio pero si miras los repositorios lo encontrarás. Hemos visto mucho progreso y muchas grandes ideas ahí asi que no obtuvimos todo de Rina, no reescribimos toda la internet, pero obtuvimos un montón de valor a través de la exploración y es lindo traccionar eso dentro de un sistema de producción real y ver eso en la vida real por que de hecho nadie hizo eso, Rina está desde el 2008 y nadie realmente implementó Rina en sistema de producción y esta es la primera vez que a alguien le gustó o fue inspirado por ideas de el, ha sido traido a algo bastante grande y significante.
Hay otras áreas en las que hemos estado explorando para innovar, por ejemplo tenemos que pensar mucho acerca de incentivos, de pools de participación, de actores racionales para el sistema. Aquí es donde tenemos cosas como el proceso CIP que tenemos que desplegar, cosas como la votación, el sistema de tesoro, hemos escrito varios documentos del sistema de tesoro, pensamos mucho acerca de la votación y hay equipos especializados dentro de IOHK que están haciendo exactamente lo que estábamos haciendo con Plutus, donde teníamos un manager de producto para investigación y desarrollo, básicamente llevándolo a un punto donde teníamos una línea de ejecución clara y Bin Zhang es el equivalente a Manuel Chakravarty del lado de votación y tesoro, mucho progreso ha sido logrado ahí.
Como con todas las cosas, todos estos hilos, sin importar si estamos hablando de cosas realizadas como la prueba de participación a campos azules abiertos a investigación y desarrollo, es un esfuerzo de largo plazo, lanzas algo pero siempre hay algo más que hacer, siempre está el próximo paso.