🇪🇸 Actualización de desarrollo y avance del HF Vasil de Junio | Cardano 360 | IOG 31 Mar 2022

:es: Transcripción al español de un fragmento de “Cardano360 March 2022

Del minuto 00:27:47 al 00:42:11 del video original

Publicado en el canal de Youtube de IOHK el 31 de Marzo 2022

Enlace a la versión doblada al español


Tim: Mientras tanto, el equipo de desarrollo central, detrás de escena, continúa construyendo Cardano en sí mismo. Aquí está John, Kevin y Nigel para actualizarnos, incluyendo lo que se espera de la bifurcación dura Vasil de Junio.

John, Kevin, Nigel, bienvenidos nuevamente. Hoy vamos a hablar de la bifurcación dura Vasil, pero antes de hacerlo, Nigel, ¿podés darnos un resumen de la agenda de liberación principal, lo que hay detrás de ello?

Nigel: Seguro Tim, como podrías recordar, optamos por concentrar esfuerzos alrededor de tres liberaciones significativas por año, eso es en Febrero, Junio y Octubre. Esto permite a nuestros equipos de producto focalizarse en mejoras principales, mientras damos a la comunidad un montón de márgen de tiempo necesario para prepararse para cualquier cambio significativo bajo una bifurcación dura. Mientras crece la comunidad, esto se vuelve más y más importante, hay compañías dApps ahí fuera que quieren sacar ventajas de las mejoras que estamos construyendo, y necesitarán márgen de tiempo para ser capaz de integrar eso dentro de sus ciclos de desarrollo. Mientras continuamos liberando más mejoras durante el año, los desarrolladores deberían mirar estos tres hitos, mientras los puntos de referencia que hemos resaltado, en nuestra manera de escalar Cardano este año. En Febrero no necesitamos una bifurcación dura, eso normalmente es necesario cuando tenemos cambios de libro contable. Sin embargo estas actualizaciones nos llevaron camino a la bifurcación dura Vasil, viniendo en Junio. Y sólo para recapitular, esto es lo que hicimos en Febrero, entregamos transacciones compatibles CDDL directamente del CLI, realizamos los cambios de infraetructura necesarios para multi firma incremental, pusimos una agenda de liderazgo, un monitoreo de transacciones en la mempool y también una estimación de costo de script. Pero hoy vamos a hablar de los componentes principales Vasil, y eso es nuestra versión dos de Plutus, nuestro manejo colateral de script, y mejoras a nuestros primitivos cripto.

Tim: Gracias Nigel, y de hecho vayamos directamente a Plutus, y Kevin. Kevin, Plutus por supuesto es un lenguaje de contratos inteligentes en maduración, todavía un montón de mejoras para agregar. Junio por supuesto traerá algunas significativas.

Kevin: Sí, absolutamente Tim. Esta es sólo la primera de muchas mejoras que estaremos desplegando para Plutus. En Vasil de Junio habrá cuatro áreas principales en las que nos estaremos focalizando. La primera será scripts de referencia, estos son scripts, pre grabados si querés, en cadena, a los que luego nos podemos referir desde otras transacciones. Eso significa que seremos capaces de reducir el tamaño de las transacciones que utilizan scripts, y como he dicho, también seremos capaces de reutilizar código existente, así gran mejora para los desarrolladores dApp.

La segunda cosa para desplegar son entradas de referencia, con entradas de referencia lo que podés hacer es podés hacer referencia a una entrada dentro de un script, sin consumirlo, lo que eso hace es permitir que muchos scripts se refieran a la misma entrada al mismo tiempo, eso mejora nuestra concurrencia, podés hacer muchas cosas simultáneamente utilizando la misma entrada, así que gran mejora al rendimiento.

La tercera cosa son datos en línea, lo que hacen es volver más fácil para que los desarrolladores se refieran a una simple entrada, así que no tenemos que utilizar entradas para hashes por ejemplo, podemos referirnos a ellas directamente, vuelve más fácil para usuarios y desarrolladores ver entradas, tres grandes mejoras. Estas están cubiertas por varios CIPs que hemos empujado a la comunidad, ha sido comentado por varios expertos. CIP 33, scripts de referencia, CIP 31, entradas de referencia, CIP 32 datos en línea.

La cosa final que estaremos desplegando son redentores, en información de transacción. Lo que esto hace es dejar operar a los scripts utilizando un redentor compartido, cuatro grandes mejoras ahí.

Tim: John, primitivos cripto, no estamos hablando de gente que vemos en twitter todos los días, asumo eso.

John: ha, ha, no esta vez Tim, no esta vez. Utilizamos un montón de cripto genial en Cardano, de hecho de vanguardia, quizás en otro momento podría hablar de la curva elíptica de primitivo que utilizamos, utilizamos una llamada ED 255 19, es de vanguardia en términos de firmas digitales, súper genial. Hoy quiero focalizarme en un cambio que realizamos alrededor del VRF, VRF es otro primitivo criptográfico y cuando digo primitivo son como pequeños bloques lego, pequeños bloques de construcción, desde los cuales construimos sistemas más complicados. VRF significa función aleatoria verificable. Normalmente, cuando estás firmando algo, pasás el mensaje, la clave secreta, atravesás un algoritmo, obtenés una firma, esa firma puede ser verificada por la gente, eso creo que se puede entender bastante bien por la mayoría de la gente. VRF es un poco diferente, ponés una clave secreta, seguís necesitando una clave privada, pero también ponés una especie de semilla aleatoria, una pieza de datos aleatoria. Durante el algoritmo, en vez de obtener una firma, obtenés lo que llamamos una prueba y otra salida aleatoria. Y esta salida aleatoria es indistinguible de ruido completamente aleatorio. Pensé en dar un poco de conocimiento acerca de cómo funciona el VRF, básicamente es algo que toma la semilla, el secreto, y produce una prueba y salida. Pero utilizamos esto para nuestra agenda de liderazgo determinístico, es un aspecto muy importante de cómo decidimos quién forjará un bloque a continuación. De todos modos, es costoso, con todos estos primitivos criptográficos, la matemática tiende a ser bastante pesada, es costoso para que las computadoras lo calculen. Así que estuvimos utilizando esto dos veces, y ahora hemos reducido eso, fuimos capaces, durante el proceso de propagación de bloque, en vez de tener dos VRF corriendo, dos cálculos, ahora sólo tenemos uno. Así que haciendo esto estamos moviendo redundancia, donde, de nuevo, hacemos menos trabajo durante nuestra validación y propagación de bloque, estas son todas buenas noticias. La cosa es que cuando sea que eliminás algo como eso, tan técnico, tenés que ser muy cuidadoso acerca de cómo lo rebanás quirúrgicamente, asegurarnos que verdaderamente no lo necesitamos, pero lo hacemos de una manera donde somos más rápidos, mejores, pero al mismo tan seguro, determinístico como eramos antes.

Tim: Gracias John, ajuste de script colateral es la próxima cosa que vamos a cubrir, Kevin, quizá podés tomar esa.

Kevin: Cuando estamos ejecutando un contrato inteligente Plutus, lo que hacemos es tener un proceso de validación de dos etapas. En la primera etapa un script es ejecutado fuera de línea, comprobamos que va a ser exitoso, y sólo si atraviesa la primera etapa de validación, luego de hecho lo ponemos para ejecución en la cadena, así que esa es la segunda etapa de validación.

Lo que no queremos es tener scripts ejecutándose en cadena que no han sido pagados. Así requerimos que los usuarios coloquen un colateral para cubrir el costo de ejecutar un script. Si la segunda etapa falla, entonces el colateral se pierde. Esto significa que si deliberadamente presentás una transacción en la cadena que sabés que va a fallar, siempre tenés la oportunidad de comprobar eso a través de la primera etapa. Luego vas a pagar el costo colateral por ejecutar el script, de esa manera no podés atacar la cadena presentando un enorme número de scripts que fallan, no teniendo que pagar por ellos.

Con el mecanismo colateral actual lo que ocurre es que ponés una entrada en Ada, si la transacción falla en ser ejecutada entonces se pierde todo el colateral, hay un valor mínimo asociado con eso, que es más grande que el costo de ejecutar el script. Así que realmente no hay incentivo para intentar atacar la red de esta manera. Lo que hemos hecho es realizar unas pocas mejoras que ayudarán al usuario dApp, mientras que este proceso es bastante efectivo, quizás es un poquito draconiano, no satisface todas las necesidades de los usuarios que estamos viendo de desarrolladores dApps. Así que lo que vamos a hacer es primero ajustar el colateral al monto exacto requerido para que el usuario final nunca arriesgue más de lo necesario. Así que podés un millón de Adas, sé que sos una ballena Tim, ponés un millón de Adas, en el viejo sistema si deliberadamente presentás una transacción que falla perdiste tu millón de Adas, eso es un poco duro. Si lo hacés ahora estarás perdiendo mucho menos, será algún porcentaje del costo de la ejecución del script, así que unos pocos Adas. Eso te hará mucho más feliz, no estarás arriesgando tu parte como colateral todo el tiempo. El resto va a una nueva dirección de cambio, así que podés especificar a dónde va el cambio Tim.

Tim: Por supuesto Kevin esa no es la única mejora, ¿no es así?

Kevin: No, absolutamente no. Varias mejoras viniendo del mismo borrador CIP. La primera es que ya no vas a estar restringido a sólo tokens Ada, te permitirá utilizar tokens no Ada, donde un montón de desarrolladores dApp manienten Ada y no Ada en los mismos UTxOs, esto lo hará mucho más fácil, más simple para que los desarrolladores dApps utilicen este mecanismo.

La segunda mejora es que este proceso funcionará mucho mejor con billeteras de hardware, las billeteras de hardware sabrán que la transacción tendrá éxito, habrá maneras de comprobar eso, eso dará a los usuarios mucha más confianza y certeza en la utilización de scripts Plutus con colateral.

Tim: Gracias Kevin, y por supuesto si querés comprobar el proceso CIP, los que están en camino en este momento, pondremos un enlace en las notas debajo. John, además de estas mejoras Plutus, obviamente habrá trabajo en la red, quizás quieras contarnos más al respecto.

John: Vamos a estar realizando grandes cambios este verano cuando despleguemos pipelining. Sé que hay un blog que salió de uno de nuestros distinguidos investigadores Mathias Fitzy. Quiero dar a la gente un poco de información, porque creo que ese blog era bastante técnico, cuando la gente lo lee quizás no está claro lo que exactamente estamos entregando, quiero tratar de aclarar errores de concepto alrededor de esto. Cuando sea que estamos desplegando cosas como esta, la semilla comienza con investigación, pasan todo el día pensando acerca de esta clase de cosas, aparecen con diferentes modelos, todo es muy académico en ese punto, no hay código, es más pensamiento y proceso. Luego, a medida que estas cosas toman forma, estas mejoras, ya sea pipelining u otra cosa, se vuelve más concreto, más real, más tangible, decimos “sí, esto es algo con que podemos hacer un cambio y tener impacto real en el sistema”. Ese proceso luego va a gente como yo, en la sección de arquitectura, tomaré la entrada de investigación, es mí trabajo tomar eso y convertirlo en una especificación más tangible, lo llamamos especificación de ingeniería o de arquitectura. Luego de hecho va a la gente que hace el trabajo real, los ingenieros, ellos toman mí trabajo y escriben el código, así es cómo lo hacemos. Creo que la gente que leyó el blog de Mathías, el está hablando desde un punto de vista muy académico. Cuando en el show decimos pipelining, realmente es acerca de hacer que los bloques se transmitan más rápido a tu vecino, he discutido eso antes, porque cuanto más rápido podés transmitir, más espacio tenemos para incrementar los parámetros de la red, hacer las cosas más rápidas, grandes y mejores. Cuando Mathias está pensando, no está pensando acerca del impacto corriente abajo, él está muy focalizado en todas las diferentes variantes que podés tener de pipelining. Podrías haber escuchado palabras como pipelining, difusión de pipelining, validación asincrónica, validación demorada. Son todos distintos sabores de la misma idea, que es juntar el proceso de validar un bloque, mientras que también estás comunicando y transmitiendo los datos lo más rápido posible.

Cuando estamos seleccionado alguna de las brillantes ideas con las que aparecieron los genios investigadores, tenemos que hacer eso con un sombrero pragmático colocado, porque tenemos que decirnos a nosotros mismos “bueno, está versión de validación asincrónica quizás es un poquito más rápida pero es más peligrosa y necesita más tiempo”. Así que hemos escogido lo que se llama difusión de pipelining, es por eso que se llama pipelining en el show. Sentimos que es un punto dulce, que entregará un montón de espacio para asombrosos cambios durante el resto del año. Podríamos volver atrás y mirar otras cosas como validación asincrónica, y otras cosas que nos conducen a rendimiento aún mayor. Pero tenés que recordar, ya estamos adelantados en términos de nuestra hoja de ruta de rendimiento, dónde queríamos estar, nuestra utilización de bloque todavía no está al 100%, tenemos grandes cambios viniendo en Junio que realmente nos permitirán aumentar los parámetros de red, incrementar el tamaño de bloques y la velocidad. Encima de eso, componiendo todo esto, podríamos nunca terminar de realizar variantes de pipelining, creo que lo que vamos a traer en Junio será el punto dulce y será suficiente. Luego nos estaremos moviendo a endosantes de entrada, que es una manera radicalmente diferente de realizar consenso, propagación de bloque, podemos hablar de eso en detalle en otro momento, ranqueando bloques, bloques de entrada, es todo bastante sofisticado. Pero creo que pipelining, de la manera en que lo estamos trayendo en Junio, nos dará espacio hasta que vengan los endosantes de entrada, que efectivamente es una solución de fin de juego, que nos verá escalar por los próximos cinco años.

Tim: Gracias John por ese resumen. Nigel, el trabajo continua para prepararse para la bifurcación dura Vasil de Junio. Por supuesto vienen Octubre, llegará más pronto de lo que creemos, eso se llamará la bifurcación dura Chang, se trabajó en algunas piezas, ¿cuál es la actualización ahí?

Nigel: Por supuesto Tim, nuestro equipo comenzó a planear para la bifurcación dura Chang de Octubre, mientras el enfoque total todavía está en desarrollo, que cambiará durante las próximas semanas y meses, definitivamente sabemos que ciertas cosas estarán en la tubería para Octubre. Nuestra comunidad puede esperar ver más acerca de esto en el futuro. Tenemos cambios en el área de gobernanza, tenemos más evolución de contratos inteligentes, tenemos más cambios y mejoras al rendimiento, y por supuesto eso es sólo el desarrollo central. Como hemos compartido anteriormente, también tenemos un montón de cosas emocionantes viniendo en la tubería para billeteras livianas, cadenas laterales.

Tim: Gracias Nigel, como podés ver, una gran cantidad de trabajo para Junio, y también ya estamos pensando anticipadamente para Octubre. Caballeros, muchas gracias por unirse, los veremos de nuevo pronto.