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 II: From Research to Reality”
Publicado en el canal de Youtube de IOHK el 17 de Octubre 2024
Uno de los beneficios de tener este tipo de trabajo de ingeniería e investigación bajo un mismo techo es que es mutuamente beneficioso. Intentamos resolver algo, tenemos una idea, la redactamos, tal vez en un informe técnico, y luego recibimos retroalimentación diciendo que esto no funciona en la práctica; funciona en teoría, pero no en el mundo real. Esto es muy fructífero…
Seamos honestos, ¿qué hacemos con nuestros informes o qué les hacemos?
Bueno, esa es una buena pregunta. Necesitamos hacer varias cosas. Primero, para mí, es realmente un proceso de traducción porque no somos investigadores, y creo que deberíamos enfatizar que existen diferentes habilidades involucradas. No es lo mismo; todos estamos en el mismo dominio o en el espacio del problema, pero cada uno tiene habilidades distintas. Creo que es muy importante destacar que esas habilidades están todas relacionadas con la resolución del problema.
Entonces, al pasar del informe, el primer paso que hacemos es tratar de entender el protocolo en su totalidad. Para nosotros, los ingenieros, se trata realmente de construir un prototipo. Creo que la mayoría de los ingenieros estarán de acuerdo conmigo en que, si no está en código, no se entiende. Cuando está en código, puedes empezar a tocarlo y jugar con él. En el caso de “Peras”, por ejemplo, en los primeros días, antes de que el informe estuviera escrito, ya había una especificación semi formal del protocolo. Abordamos eso y comenzamos a escribir código que podría ser representativo, colocar este código que se suponía análogo al protocolo en un entorno simulado, tratando de entender cómo fluía el valor. El ingrediente clave en Peras es la votación, los nodos en el protocolo votarán para decidir y asignar peso a los bloques. Pero ¿cómo se siente, cómo lo hacés en la práctica? Aquí es donde también aplicamos algunos trabajos previos sobre el modelo Delta-Q y sobre Ouroboros en general, para modelar tanto el prototipo como el comportamiento de la red en su conjunto y entender cómo el flujo de datos va a través de la red, cuál sería el impacto sobre Ouroboros .
La versión inicial del protocolo donde básicamente teníamos los certificados que se suponía que debían ser parte de los encabezados de los bloques y difundirse en toda la red. Sin embargo, rápidamente vimos que eso no funcionaría debido a las restricciones en el tiempo de retraso cuando se transfieren bloques. Aquí trabajamos en dos niveles: el prototipo en código, para simular, y el modelo a nivel alto, como primeros pasos, luego hay un paso de refinamiento.
La refinación es muy importante.
¿Qué es este modelo Delta Q? No estoy seguro de entender realmente lo que hace; solo escucho que se menciona todo el tiempo. Sé que está de alguna manera relacionado con la red, así que tenemos un punto de referencia, sí.
Delta Q es un modelo que ha sido desarrollado a lo largo de los años por varias personas del equipo de redes en IOG. Conceptualmente, puedes imaginar Delta Q como una forma de modelar algunos recursos o alguna propiedad de la red, como la que nos interesa en el caso de Cardano. Por ejemplo, una vez que se produce un bloque, ¿cuánto tiempo toma para que ese bloque alcance todos los nodos en la red? Puedes simular eso con código, pero Delta Q es una forma de modelarlo analíticamente, diciendo, por ejemplo, que para que un bloque vaya de un nodo productor de bloques a todos los nodos, debe pasar por varias etapas.
En el caso de los bloques, por ejemplo, se envía un encabezado que se propaga por la red. ¿cómo propagás el encabezado? En la práctica lo que sucede es que los nodos dicen “Tengo un nuevo encabezado” y todos los pares responden “Estoy interesado en ese encabezado nuevo”, lo cual implica una comunicación en ambos sentidos. Obtengo el encabezado Así, modelas el proceso, y el elemento clave es que en cada etapa del proceso adjuntas una probabilidad de distribución para decir, esta es la probabilidad de distribución, en nuestro caso es tiempo, cuál es la probabilidad de distribución del tiempo de transmisión de un nodo a otro y a través de toda la red y lo que obtienes típicamente es una distribución en forma de S que dice: bien, dado mi modelo, puedo evaluar que el 95% de los encabezados de bloque llegarán a los nodos en menos de 3 segundos, que en realidad es nuestra restricción más estricta en la red Cardano. Esto es lo que DeltaQ te permite hacer: modelar la red, pero a un nivel muy abstracto. Creo que, como Neil Davis, quien es uno de los inventores de esta metodología, lo explica, es una forma de reducir el espacio de exploración antes de siquiera construir una simulación o prototipo. Es por eso que es un modelo interesante para explorar, y esta es la razón por la que comenzamos a usarlo. Es decir, se había utilizado antes, pero no formalizado. Y eso es lo interesante también en Peras como buen ejemplo: cómo estamos utilizando esto como un banco de pruebas o una mejora de lo que hicimos antes.
Bueno, creo que básicamente lo que describes también es muy interesante porque no es algo que hayamos inventado en realidad. Esta idea de tomar un resultado de investigación, no necesariamente en un artículo, sino en cualquier informe técnico o idea formalizada lo suficiente como para que podamos trabajar en ella y llevarla a otro nivel hasta alcanzar su implementación en producción, es algo que ya mencionaste: se usa el nivel de preparación del software, siguiendo una escala de evolución de la madurez del software que va desde la idea de investigación hasta la implementación en producción. Pasamos por diferentes fases que básicamente validan las propiedades en un entorno simulado, en un prototipo en un entorno simulado o en un entorno relevante, y luego continuamos adquiriendo conocimiento y certeza sobre lo que estamos construyendo para que podamos avanzar suavemente en la implementación.
Obviamente, la formalización de todo esto también es importante porque hay muchas cosas donde necesitamos simular y en otras áreas necesitamos probar cosas para demostrar que, como dijiste antes, las cosas que hemos verificado manualmente también pueden ser verificadas por la computadora para asegurarnos de que la propiedad se mantendrá siempre en producción. Y en realidad, estoy interesado en tu perspectiva sobre este proceso porque básicamente nos das una idea de investigación y luego hacemos cosas con ella, y tú ves algunos de los resultados. Entonces, ¿cuál es el valor de tu lado del espectro?
Tener estas ideas es muy beneficioso.Quiero decir, este es uno de los beneficios de tener este tipo de trabajo de ingeniería e investigación bajo un mismo techo, ¿verdad? Es porque es mutuamente beneficioso: intentamos resolver algo, tenemos una idea, la escribimos, tal vez en un informe técnico, y luego recibimos la retroalimentación de que, en la práctica, esto no funciona. Funciona en teoría, pero no allá afuera. Y esto es muy provechoso, porque este intercambio es muy importante si al final quieres hacer algo que sea práctico y tenga un impacto. En nuestro caso, impacto significa innovación. Decimos, por ejemplo, que esto es algo que la comunidad de Cardano debería adoptar, entonces estamos seguros de que es factible y es bueno.