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 “Behind the Blockchain Part I: Bridging Innovation and Implementation”
Publicado en el canal de Youtube de IOHK el 16 de Octubre 2024
Hay dos problemas muy difíciles en la informática: uno es la distribución, es decir, los problemas de redes, y el segundo es la seguridad, demostrando que algo funciona correctamente. Estamos en la intersección de estos dos problemas, estamos tratando con un sistema distribuido y necesitamos un alto nivel de seguridad para él.
Y encontrar buenos nombres.
Sí, esa es la parte más difícil, encontrar un buen nombre pegajoso.
La pregunta es ¿qué es la innovación, de qué se trata? Probablemente se trate de crear artefactos, aumenten la confianza en que lo que se propone, eventualmente funcionará en producción.
Soy Nicolas Biri, soy de Francia. Me uní a IO hace dos años, antes trabajaba en una organización de transferencia de investigación en Luxemburgo durante más de 15 años. Soy el director actual de arquitectura de software en IO, lo que significa que tengo una visión general de todas las piezas de software que estamos construyendo en IO, y trabajo en estrecha colaboración con arquitectos para diseñar estas piezas de software y ayudarles a resolver sus problemas a diario.
Lo que discutimos hoy es la relación entre investigación, innovación e implementación. La mayor parte de nuestro trabajo proviene de la investigación, la idea de identificar un problema e intentar encontrar una nueva forma de abordarlo y proporcionar buenos resultados para la comunidad Cardano.
Por lo general, lo que hacemos es básicamente revisar por pares los resultados de investigación, lo que significa que son resultados validados por la comunidad, y a partir de ahí necesitamos evaluar si estos resultados de investigación son viables cuando observamos el ecosistema Cardano, obviamente podríamos intentar saltar directamente a la implementación, pero eso es muy arriesgado, ya que muchas de estas ideas no se aplican en el mundo real. Entonces, lo que hacemos es básicamente tener esta capa de innovación en el medio que trata de cerrar la brecha, ver si una idea es viable y tiene sentido y, si es así, pasar a la fase de implementación. El objetivo de la innovación es, de hecho, intentar, primero, ver si funciona y, segundo, proporcionar suficiente evidencia y orientación para que el equipo de implementación pueda construir sobre eso.
Soy Christian Badertscher, investigador y conferencista en criptografía y blockchain, y director de estrategia y planificación de investigación en Input Output. Como parte de mi rol, realizo investigaciones en criptografía y sistemas blockchain con temas centrados en mejorar el ecosistema Cardano y también en avanzar en la industria o la tecnología en general. Como director en el departamento, me aseguro de que la estrategia de la empresa esté alineada con las líneas de investigación que seguimos, fomentando nuevos emprendimientos cuando sea necesario y supervisando el progreso, con la intención de mantenernos innovadores, proactivos y de invertir nuestro tiempo de la manera más prometedora.
Bueno, no comienza con la investigación en sí, comienza con una declaración del problema, porque construir sistemas seguros es una tarea bastante difícil. Entonces, hay que evaluar los requisitos, como la seguridad, descentralización, eficiencia, y, hasta cierto punto, estos son requisitos contradictorios. Primero tenemos que averiguar dónde estamos ahora y cuál es el problema que estamos tratando de resolver. Para esto, como dijiste muy bien, comienza con la investigación, porque, en la mayoría de los casos, no podemos simplemente tomar un componente de la estantería, si estamos innovando, simplemente no existe aún. Con suerte, alguien más ya abordó la cuestión y podemos empezar tal vez desde un artículo de investigación existente y mejorarlo, pero a menudo también tenemos que comenzar desde cero. Entonces, vamos a la pizarra y tratamos de ser creativos, inventando algo que nadie haya pensado antes.
Soy Sandro Coretti Drayton, investigador en IOG. Desarrollo nuevos protocolos para blockchains, tal vez para hacerlos más seguros, para aumentar el rendimiento o reducir el tiempo de liquidación, en general para hacer las cosas más escalables. Soy originaria de Suiza. Hice mi doctorado en Zurich y luego fui a Nueva York para un postdoctorado, y después me uní a IOG.
En realidad, solo se trata de lo que mencioné antes, como alguien que no es ingeniero de software como yo, hay como tres niveles diferentes para escribir software. Uno es el software del tipo Microsoft, donde sabes que tiene que funcionar, y luego tal vez un software que, ya sabes, es más relacionado con la seguridad, en el que tienes que defenderte de una entidad maliciosa. Mientras que en Microsoft no hay nadie atacando Microsoft. Así que, sí, entendiste mi punto, claro. Y luego estamos haciendo algo aún más desafiante. Estamos construyendo un sistema distribuido.
Soy Arnaud Bailly, francés y llevo trabajando en IO un poco más de tres años, principalmente como arquitecto principal en varios proyectos de desarrollo, mayormente en la escalabilidad de Cardano,que es un área grande. Primero, comencé en el proyecto Hydra junto con otros dos colegas, luego en Mithril, que también está prosperando actualmente. Y, más recientemente, desde finales del año pasado, me uní a los proyectos de Innovación en IO, en los que me concentro en el protocolo Peras. En este proyecto también soy el arquitecto principal, pero es un equipo pequeño, y estamos tratando de cerrar la brecha entre la investigación y la implementación, acortando el ciclo de vida desde una idea de investigación hasta una especificación implementable y un prototipo.
Lo interesante y desafiante en el trabajo que estamos haciendo son las interacciones complejas. Hay requisitos contradictorios, y también una especie de tensión entre los problemas que son desafiantes e interesantes desde un punto de vista científico, expandiendo el conocimiento y planteando la cuestión de si puedes hacer X o Y, y si el algoritmo puede lograr eso. Luego está el problema práctico que la gente intenta resolver con Cardano, la tensión que intentamos resolver, ya que el problema de escalar un sistema como Cardano es realmente desafiante porque deseas escalar una red global que es descentralizada y distribuida, como mencionaste, Sandro. Y esto no es trivial, ya que uno de los ejemplos que siempre se menciona cuando hablamos de blockchain y lo comparamos con sistemas reales es Visa o Mastercard, que procesan 500 o 1000 transacciones por segundo a escala global. Claro, eso es cierto, pero hay un solo servidor de Visa. Por supuesto, tienen centros de datos, pero eso es muy diferente de lo que intentamos hacer, porque la idea detrás de blockchain, que es muy importante, descentralizar. Creo que el esquema de descentralización añade uno o dos grados de complejidad.
La característica de actualizabilidad, no podés actualizar como Visa. Debe ser seguro desde el inicio, y debe haber evidencia de su seguridad. Necesitamos confianza en esa seguridad, un proceso transparente que muestre por qué estamos seguros de ello, y esa evidencia debe ser entendida por la comunidad.
Especialmente con blockchain y todo lo que puede fallar, porque una vez que rompés tu blockchain, hay algunas excepciones, pero si algo sale terriblemente mal, se fue, toda la idea de la distribución del poder se va porque tendrían que unirse para decidir cómo solucionarlo. Hay ejemplos famosos de blockchains que han fallado y la gente tuvo que unirse y decidir cómo arreglarlo.
En el campo de la informática, los dos problemas más difíciles suelen ser la distribución, osea asuntos de red y la seguridad, probar que algo está funcionando correctamente. El problema es que nos encontramos en la intersección de estos dos problemas: estamos lidiando con un sistema distribuido y necesitamos un alto nivel de seguridad para él.
Y encontrar buenos nombres… sí, esa es la parte más difícil, encontrar un nombre pegajoso
Supongo que la idea de hoy también es dar algunos ejemplos sobre cómo moldeamos la relación entre investigación, innovación e implementación. Creo que hemos tomado el ejemplo de Peras para discutirlo. Christian, ¿quieres contarnos un poco sobre qué es Peras?
Entonces, cuando analizamos los sistemas de blockchain, una de las características principales es la liquidación de transacciones y, a menudo, en muchas aplicaciones, quisiéramos que esto suceda rápido, con tiempos de confirmación breves, antes de que el café se enfríe, por decirlo así. Exacto, el pago debería hacerse antes de que el café se enfríe. Ahora, cuando observamos varios diseños de sistemas de blockchain, existen las blockchains del tipo Nakamoto, que son muy robustos, pero tienden a liquidarse un poco más lento. Es decir, tienes que esperar, y la probabilidad de que una transacción falle disminuye a medida que se agregan más bloques a la cadena, pero el tiempo de liquidación es una cuestión interesante si, con ese diseño, manteniendo la seguridad en este modelo de participación dinámica, ¿aún podemos mejorar la seguridad?. ¿Podemos romper esta aparente barrera de tener que esperar un buen tiempo para liquidar una transacción, o existe una estructura superpuesta que podríamos imponer para reducir los tiempos de liquidación y lograr que las transacciones se confirmen en mucho menos tiempo?
Para dar un poco más de contexto, existen formas de alcanzar una finalización más rápida. Puedes usar protocolos del tipo BFT, y la diferencia entre esos y, por ejemplo, Ouroboros, que aspira a ser un protocolo que se usará por mucho tiempo, es que estos protocolos del tipo BFT no tienen una propiedad llamada autocuración. Ouroboros está diseñado para ser resistente contra un atacante que controle menos del 50 % del stake, y, aun si esto se viola o si el adversario en algún momento tiene la mayoría de la participación en el sistema, la situación vuelve a la normalidad porque algunos participantes honestos estaban fuera de línea y vuelven al sistema, Ouroboros puede “curarse” a sí mismo, es decir, puede volver a operar normalmente.
Los protocolos del tipo BFT no tienen esta propiedad, y por eso Cardano quiere quedarse con Ouroboros. Como dijo Christian, ver si podemos mejorar el tiempo de liquidación.
Creo que la autocuración es crucial. En este mundo dinámico donde las partes pueden unirse o salir y el sistema no siempre está activo, puedes tener períodos en los que la participación disminuye temporalmente. Si tienes mala suerte, los participantes no disponibles podrían ser muchos de los que sostienen el sistema, lo cual deja al adversario en una situación de control mayoritario hasta que la parte honesta se recupere y vuelva en línea. En ese momento, no necesitas consenso externo; quieres que el sistema sepa cómo autocurarse.
Creo que es muy interesante relacionar ese problema también desde un punto de vista práctico, porque creo que, personalmente, como ingeniero, me ayuda mucho a relacionarlo. Cuando observas un protocolo en un papel de investigación, suele ser muy abstracto, tenés un montón de preguntas. En la práctica, lograr una liquidación más rápida en el contexto de Cardano también tiene un impacto directo en los usuarios, porque si eres un usuario y realizas una transacción, ya sea un pago pequeño o grande, si la transacción se puede considerar liquidada en minutos, horas o días, hace una gran diferencia y afecta el nivel de riesgo.
Para volver a la analogía con el sistema bancario central, la liquidación en el sistema financiero actual está garantizada por los bancos y, en última instancia, por los estados. Aquí, no hay un ente central que garantice la liquidación. Si hago una transacción en la blockchain con Nicolás y le compro una bicicleta, le envío Adas y hago una transacción en Cardano, pero si mi transacción es falsa o duplico el gasto, y ya tengo la bicicleta de Nicolás, no hay nadie a quien llamar. No hay una autoridad central a la que apelar.
Creo que todos hemos tenido la experiencia de comprar algo en línea, y en algún momento alguien obtiene tu número de tarjeta de crédito y lo usa para hacer un pago en otra parte del mundo. Entonces te llega un débito en tu cuenta y puedes llamar a tu banco y decir “esto no soy yo”. Proporcionas pruebas, y ellos lo revocan, incluso tienen seguros para ello. Nosotros no tenemos eso aquí.
Es interesante ver cómo eso afecta a las personas y cuáles son los compromisos. Creo que esa es también una parte importante de la interacción que tenemos entre la investigación, la ingeniería y transferirlo a la innovación. En especial, en el caso de la escalabilidad, nunca viene gratis. Entonces, ¿cómo se traduce la liquidación rápida en más restricciones o recursos necesarios en el mundo real, y cuáles son las compensaciones, cómo pueden esas compensaciones ser aceptadas?
Una cosa positiva de nuestro enfoque basado en evidencia es que permite ver estas compensaciones que mencionaste. En investigación, tomamos el problema y decimos: “¿Cuáles son los supuestos que podemos considerar válidos? ¿asumir una buena red? ¿Hay una mayoría honesta?”, esto, lo otro. Hay muchas suposiciones criptográficas que queremos hacer, y una vez que construyes este modelo y describes lo que abstrajiste de la realidad —ya que modelar todo es prácticamente imposible— debes enfocarte en los detalles más importantes y documentarlo, porque otras personas deben entender tu proceso de pensamiento. Entonces, puedes formalizar esos requisitos que queremos tener o esos dos requisitos o los que sean necesarios o los objetivos que tu sistema debería cumplir. Si estos son contradictorios, debemos encontrar un compromiso; no es blanco o negro. Algunos sistemas se enfocan más en dos de cuatro requisitos, o algo similar. Esos son las famosas compensaciones que enfrentamos. Una vez que hay un modelo, teóricamente puedes comprender que debe existir un límite y no intentamos perseguir lo inalcanzable, sino entender el espacio. Por eso, el modelado al inicio es fundamental para entender dónde están los límites,
Es interesante que digas que el modelo necesariamente tiene que simplificar la realidad, porque en gran medida lo que hacemos en innovación es empezar a introducir más y más realidad en el diseño original para asegurarnos de que, cuando introducimos estos elementos y restricciones externas que forman parte de un software real, las propiedades que se han descrito en un artículo de investigación sigan teniendo sentido, siendo relevantes para lo que hacemos. Esto suele venir acompañado de otras compensaciones que quedan fuera en el artículo y que se vuelven más relevantes cuando intentamos aplicar lo que has construido y crear un sistema real.
Creo que por eso existen los niveles de preparación de software. Como que reflejan este proceso: comenzamos en la pizarra y siempre queremos proporcionar evidencia, por lo que debemos documentarlo para que otros lo comprendan.
De hecho, también es el caso de que a veces, al intentar hacer más concretas las suposiciones de nuestros artículos, descubrimos nuevos problemas de investigación interesantes para nosotros. Un ejemplo es que los artículos que describen, por ejemplo, el protocolo Ouroboros, asumen una red muy simplificada. Es decir, introduces un bloque o una cadena completa en una interfaz y luego hay un límite de tiempo fijo. La idea es que todo se entrega en un tiempo fijo, delta, el famoso Delta. Sin embargo,por supuesto esto no ocurre en la realidad, y resulta que no puedes simplemente crear un protocolo de consenso súper bonito y luego ejecutarlo sobre un modelo de red que no existe. Puedes crear una capa de consenso segura contra un adversario, pero luego el nivel de red, que debe implementarse en los mismos nodos que ejecutan el consenso, no se puede ignorar al atacante ahí. Recientemente, escribimos un artículo en el que analizamos formalmente la seguridad también para la capa de red.
También un tipo similar de problema con el diseño inicial de Peras, en realidad, y quiero decir, hubo un problema con el tamaño del certificado y la cantidad de certificados que tenía que pasar a través de la red en la versión inicial de Peras, y eso es algo que realmente muestra el valor del proceso de innovación. Porque mientras Arnaud estaba trabajando con su equipo en el prototipo de Peras, este fue uno de los primeros problemas que encontraron al construir el prototipo, volviendo en el círculo.
Creo que esto ocurre incluso antes del prototipado, y ahí es donde se vuelve interesante en términos de todo el proceso y cómo las diversas partes se unen y qué es lo que intentamos lograr y encontrar.Un prototipo ya es algo bastante involucrado; tienes que hacer un prototipo, y aunque el protocolo, quiero decir, Peras es un protocolo relativamente simple, al menos lo era; ahora se está volviendo un poco más complicado, pero comparado con otros protocolos, sigue siendo bastante simple. Pero aun así, escribir un protocolo y hacerlo lo suficientemente convincente, ya sabes, es como… diría que la analogía que podríamos usar aquí es como ser un escultor. Si eres como Rodin, un famoso escultor francés (y todos conocemos las esculturas famosas de Rodin en bronce), el problema es que Rodin no simplemente hacía un molde, vertía el bronce y listo. No funciona de esa manera. Rodin hizo varios modelos, y los modelos eran de yeso, algunos quizás de arcilla, otros con diferentes materiales, y en algún momento la forma se fue aclarando para él. Así, tienes todas las esculturas famosas de otros, y el proceso es el mismo: encontrar el modelo adecuado.
En el caso al que aludes, Nicolás, se trata realmente de esta idea de buscar, en lugar de hacer un prototipo, lo cual llevaría más tiempo, especialmente si quieres simular toda la red. Entonces, intentamos simular o encontrar analíticamente el modelo de toda la red y el comportamiento en general. Y para eso tenemos esta metodología, que también ha sido documentada en algunos artículos, llamada Delta Q. La idea de Delta Q es realmente una de las herramientas que usamos para intentar comprender el comportamiento de algunas partes del protocolo en su totalidad sin necesidad de construir un prototipo, que sería algo que consumiría mucho tiempo.
Ese es un muy buen punto, en realidad; todo el proceso se trata de intentar fallar lo más rápido posible. Quiero decir, el éxito es genial; estaría muy feliz si pasamos de la investigación a la implementación sin problemas y sin necesidad de volver a un paso anterior. Pero en muchos casos, enfrentamos problemas de implementación o de diseño que necesitamos resolver, y cuanto antes los abordemos, menos costoso será para todos. Tener este tipo de problemas en producción sería un desastre; abordarlos en la implementación es costoso, pero abordarlos durante la fase de innovación suele ser bastante económico. Simplemente intentamos simular algo y, si falla, podemos hablar con ustedes y buscar soluciones.
Es por eso que no es un modelo de cascada; es muy interactivo. Una vez que tenemos este modelo matemático, intentamos demostrar o diseñar una solución, y luego intentamos probarla. Hacemos muchas suposiciones porque eso facilita la demostración de la seguridad del diseño en sí. Pero al mismo tiempo, la ingeniería, hay muchas similitudes. Cuándo funciona para ustedes y cuando funciona para investigación, para nosotros, si hacemos suposiciones razonables, informadas también por ustedes, que está bien hacer. Pero luego la prueba tiene que avanzar, tenemos que escribirla. Como dijiste, queremos como hablar un lenguaje estándar, escribimos todo en artículos para mostrar cómo lo modelamos, cuál es la solución y lo que queremos lograr. Así, se convierte en una historia coherente, y luego lo sometemos a revisión por pares para que otras personas puedan evaluarlo y aumentar la confianza en el resultado. Esto es solo un paso, pero, por supuesto, al final queremos algo que funcione.Y fue un muy buen ejemplo con el tamaño del certificado que mencionaste, sí.
Siento que esta vez hay un nuevo nivel de fortalecimiento de la conexión entre nuestra investigación teórica y el producto final. Según lo entiendo —y si me equivoco, siéntete libre de corregirme—, por ejemplo, para el Ouroboros actual hubo un artículo de investigación, ¿verdad? Y luego se hizo una implementación basada en la comprensión de las personas sobre el artículo de investigación, y luego hubo algunas pruebas formales sobre ello, pero de hecho, no necesariamente sobre lo que está en funcionamiento actualmente. Y esta vez, nuestra forma de trabajar es que, cuando tenemos el artículo, acudimos a ustedes, les explicamos nuestras ideas y ustedes realmente modelan esto formalmente, capturando en un lenguaje formal nuestro modelo, nuestro protocolo. De hecho, fui testigo de una hora de “magia” en París hace unas semanas, donde, en el momento, ustedes escribieron algo así como un analizador o compilador para nuestro pseudocódigo para traducirlo directamente a sus métodos formales, ¿verdad? E incluso nuestra demostración con lápiz y papel, hasta cierto punto, puede ser verificada con esto.
Sí, creo que eso es interesante porque es algo que no mencionamos, es otra pieza del rompecabezas y algo que hemos estado impulsando fuertemente con IOG y en general con la comunidad de Cardano. Algo que a veces es difícil para la comunidad en general, y para aquellos que no están realmente inmersos en estos temas, de captar, pero creo que es importante tener esta mentalidad sobre formalizar las cosas, porque cuando escribes algo en papel y pasas por todo el proceso de revisión por pares en conferencias y revistas científicas, y todo eso… aún queda el paso que va de esto al código que realmente se ejecuta en mi computadora o en la tuya, y puede ser bastante complejo. Y el paso de formalizar el modelo en el lenguaje… en la empresa estamos bastante enfocados en Agda estos días y creo que eso… bueno, es una especie de apuesta en cierto sentido, porque todavía, no muchas empresas ni muchas áreas están realmente invirtiendo fuertemente en formalización, pero la formalización es realmente una forma de pasar de algo que es investigación y desarrollo y un concepto escrito informalmente, la palabra formal sea una palabra peligrosa. La mayoría de la gente piensa que porque tiene ecuaciones es formal. Pero para nosotros formal significa que tu ecuación en realidad es un código que está verificado, verificado por una máquina. Creo que más que formal, está la cuestión de si está verificado por humanos o por máquinas. Y creo que llegar al punto donde lo ideal sería, y es genial que menciones eso Sandro, pero aún en el primer paso, una dirección ideal sería poder trabajar en las ideas desde el punto de vista de la investigación científica y de criptógrafos, y en paralelo trabajar en la formalización, para que cuando tengas la publicación, tus ideas estén respaldadas por un modelo formal que está verificado por la máquina y quizá no totalmente verificado por máquina, porque los modelos en los que trabajamos son muy complejos, pero una vez que tienes este modelo formal verificado por máquina, modelo formal, tienes la semilla de la cual se pueden derivar otros modelos que te lleven a la producción.
Pero es algo en lo que estamos mejorando de hecho, porque si tomamos Peras como ejemplo, no lo escogimos al azar; elegimos Peras porque comenzamos a trabajar en él en el nivel de innovación antes de que el artículo saliera, tratando de reducir el tiempo del ciclo desde la innovación hasta la implementación al tomar el paso de innovación lo antes posible, para que también podamos proporcionarte retroalimentación antes de que el artículo saliera, tratando de acortar el tiempo de iteración para pasar por todo el proceso. Así que eso es también algo que, en mi opinión, es muy interesante en la forma en que estamos evolucionando dentro de IO. Exactamente, y, quiero decir, la pregunta es ¿qué es innovación? ¿O de qué trata la innovación? Probablemente se trata de producir artefactos que aumenten la confianza en que lo que proponemos que eventualmente funcionará en producción, ¿verdad? Y, como dijiste, el artículo de investigación está bastante lejos de un sistema listo para producción. Entonces, ¿cómo llegas ahí? Y esto es innovación; se trata de artefactos que muestran simulaciones, formalizaciones, los muestran bajo, ya sabes, básicamente en circunstancias del laboratorio, pero también en simulaciones o incluso en prototipos en el tipo de entorno en el que esperaríamos medir estadísticas sobre su desempeño. Así que respaldado por artículos de investigación, este paquete completo es innovación, ¿verdad? Tomar una idea, una declaración de problema y tener un rastro de resultados que sean útiles para llegar a un sistema listo para producción.