Transcripción al español de un fragmento de “Cardano360 June 2022”
Del minuto 00:26:29 al 00:48:07 del video original
Publicado en el canal de Youtube de IOHK el 30 de Junio de 2022
Enlace a la versión doblada al español
Tim: El Martes anunciamos que íbamos estar bifurcando nuestra red de pruebas Cardano durante el fin de semana. Esta es la cuenta regresiva para liberar la actualización Vasil en la red principal. Ahora se me une Nigel para una actualización. Nigel, ha sido un largo camino hasta aquí.
Nigel: Hola Tim, seguramente lo fue, todo el mundo ha trabajado increíblemente duro para llegar hasta esta etapa, hemos sido muy cuidadosos, nos aseguramos de haber cubierto todos los testeos que queríamos realizar a través de todas las categorías, dApps, integración corriente abajo, productos, lo que pidas. Y como equipo todos hemos decido que tenemos la calidad correcta, y en este punto estamos listos para realizar la bifurcación dura de la red de pruebas. Así que eso va adelante, y la bifurcación dura será el Domingo 3 de Julio. Y en este punto luego estamos mirando un período de cuatro semanas donde le estaremos pidiendo a la comunidad, SPOs, dApps, que realicen su parte del testeo, así como también los exchanges, asegurarse que están listos para nuestra bifurcación dura de red principal.
Tim: Sólo un poquito más para ir, y por supuesto ha habido un montón de gente trabajando muy duro. Estuve con un número de ellos más temprano esta semana para escuchar acerca de qué están haciendo.
A medida que nos acercamos a desplegar la actualización Vasil en red principal, queríamos presentarte algunos del equipo haciéndolo posible. Desde la arquitectura central, difusión de pipelining, trayendo gran rendimiento, a algunos de los desarrolladores muy ocupados comprobando compatibilidad hacia atrás, construyendo, utilizando los nuevos CIPs Plutus, más el proceso de testeo de ingeniería crítica, que asegura que el código es seguro, confiable y que satisface el propósito. Así que conozcamos a algunas de esas personas trabajando detrás de escena, para entregar y cosechar los beneficios de la más compleja actualización Cardano hasta la fecha.
Duncan Coutts es uno de los arquitectos centrales detrás de la difusión de pipelining. Una importante y emocionante parte de la actualización Vasil. Ha vuelto de la paternidad, así que le pedí que explique cómo permitirá mayor velocidad y rendimiento para Cardano.
Duncan: La difusión pipelining nos permite comenzar a incrementar la cantidad de tiempo que empeñamos en procesar bloques, en particular procesando scripts. Así que inicialmente, sin cambiar ninguno de los parámetros, cuando habilitemos la función por primera vez, no va a hacer mucho la diferencia, porque en este momento no estamos empeñando mucho tiempo en cada bloque procesando scripts. La idea clave de difusión pipelining es que estamos solapando el procesamiento de un bloque enviándolo fuera. Eso nos permite incrementar la cantidad de tiempo que empeñamos en procesamiento, y si no estamos empeñando un montón de tiempo procesando inicialmente, no hace mucho la diferencia, la mayoría del tiempo es la propagación. Así que es un habilitador que nos permitirá comenzar a cambiar los parámetros acerca de cuántas ejecuciones de scripts son permitidas por bloque. Y eso nos permitirá comenzar a incrementar el tamaño de bloques, el número de scripts, cuánto tiempo se les permite ejecutar a los scripts, sin explorar nuestro presupuesto de difusión. Esa es la idea clave.
Tim: Duncan, contanos más acerca de ese presupuesto, este es el límite seguro para propagación de bloques, ¿cierto?
Duncan: El presupuesto de difusión Ouroboros es un parámetro clave del sistema, es central para la seguridad de Ouroboros. Ouroboros es un duro sistema en tiempo real, y una de las limitaciones que tenemos es que los bloques deben atravesar la red dentro del llamado parámetro delta que en la práctica son cinco segundos, y ese es un límite duro. No queremos acercarnos a ese límite duro. En este momento estamos teniendo bloques a través de la red en algún lugar entre uno y dos segundos. Así que nuestro presupuesto de difusión está diciendo “¿qué pasa si vamos a 3, 4 segundos?”. Eso significa que podemos estar utilizando bloques más grandes, correr scripts más largos, etc. Así que ese es el presupuesto de difusión, es la cantidad de tiempo que tenemos para gastar en obtener bloques a través de la red, pero manteniéndonos dentro de ese límite duro que requiere Ouroboros.
Tim: Duncan, supongo que veremos un proceso de optimización similar, parecido a lo que estuvimos viendo en la red durante los últimos seis meses, no se introdujo todo de una sola vez.
Duncan: Luego de la actualización Vasil tendremos la oportunidad de modificar los parámetros, y comenzar a utilizar más de nuestro presupuesto de difusión. Como he dicho hace un momento atrás, en este momento sólo estamos utilizando entre uno y dos segundos de nuestro presupuesto de difusión de bloques, y podemos empujar eso hacia arriba. Y en particular, con difusión pipelining, seremos capaces de utilizar ese presupuesto más eficientemente. Así que si, habrá un proceso luego de la bifurcación dura, comenzando a incrementar algunos de los parámetros, poco a poco. Hemos realizado un montón de simulaciones durante el desarrollo, tenemos redes de prueba. Pero no hay nada que sustituya a la cosa real, así que queremos realizarlo con un enfoque muy cuidadoso, poco a poco, para incrementar el presupuesto de difusión que utilizamos.
Tim: Duncan, has estado fuera durante la mayor parte de este año, felicitaciones por cierto. Con difusión pipelining ahora entregada, ¿cuál es tu próximo foco?
Duncan: Una de las cosas realmente interesantes en las que estoy trabajando, que es un proyecto de mirada hacia adelante, es lo que llamamos Ouroboros Leos, Ouroboros con endosantes de entrada. Que es una idea muy emocionante acerca de cómo realizar una versión de muy alto rendimiento, de producción, de Ouroboros. Así que hay un montón de problemas técnicos muy interesantes ahí, en este momento estamos trabajando en algunos prototipos, simulaciones, para ayudar a los investigadores, proporcionar retroalimentación en el diseño, y que nos ayude a lograr un diseño que de hecho tenga el rendimiento que esperamos. Así que son cosas muy interesantes.
Tim: Muchas gracias Duncan. Y por supuesto, si querés aprender más acerca de endosantes de entrada y Ouroboros Leos, asegurate de mirar el reciente video de nuestro jefe científico en IOG, el profesor Aggelos Kiayias, los enlaces están debajo. Tenemos alrededor de 30 desarrolladores trabajando con nosotros a través de la etapa de redes de prueba de desarrolladores Vasil, testeando sus dApps con compatibilidad hacia atrás, así como también probando algunas de las nuevas funciones Plutus. Dquadrant, el equipo detrás Artano, es uno de ellos. Ronald, los equipos IOG y Dquadrant Artano han estado colaborando muy de cerca durante los pasados meses, quizás comenzar con una breve introducción.
Roland: Mí nombre es Roland Span, soy el CEO de Dquadrant, hemos creado la dApp para NFTs, se llama Artano. Básicamente estamos testeando esta dApp en la red de pruebas de desarrolladores. Para asegurarnos que sigue corriendo de la misma manera que lo hizo en la red principal, aplicamos la nueva funcionalidad que trae la bifurcación dura Vasil, reportando los resultados en testeo funcional, en base de testeos de estrés, y este tipo de cosas. Ejecutamos un testeo de máxima velocidad para obtener la confirmación, básicamente, que el código Plutus existente todavía funciona en la nueva versión dos de la red de pruebas de desarrolladores.
Tim: Ahora, esto básicamente es testeo de regresión, ¿cierto?, asegurándose que tú dApp original, construída en la versión uno de Plutus corre exitosamente en la versión dos de Plutus. Pero más allá de ello también has visto una emocionante mejora de rendimiento.
Roland: Yo puedo confirmar que básicamente nuestra dApp, como estaba corriendo en red principal, al moverla a la red de pruebas, encontramos un incremento de rendimiento de diez veces. Digamos que en la red principal previa realizamos pedidos simultáneos en nuestra dApp. Realizamos el mismo pedido simultáneo en la red de pruebas de desarrolladores, y podía cargar diez veces más pedidos, para que el nodo lo sirva. Si hiciéramos ese pedido en la red principal previa, básicamente el nodo lo estaría bloqueando, no estaría procesando esos pedidos. Había, digamos, un cierto límite que podría gestionar, y ahora podemos confirmar que ese límite es mucho más elevado. Esto es específico para nuestra dApp NFT, no sabemos cómo esto estaría rindiendo en otras dApps, pero esperamos que vean el mismo incremento de rendimiento.
Tim: Así que has estado mirando las nuevas mejoras Plutus, esos son datums en línea, entradas de referencia, scripts de referencia. Quizás puedas ayudarnos a entender cómo has rediseñado la arquitectura en tu dApp para sacar ventaja.
Roland: Creo que está relacionado con la salida de transacción y con el contendio del cuerpo. Básicamente testeamos datums en línea, scripts de referencia, y entradas. Y todos funcionaron para nosotros. Los scripts de referencia básicamente nos están dando más flexibilidad porque estás referenciando algo que puede ser almacenado en otro lugar y no tenés que recargar todo el tiempo. Así que si dentro de tu dApp NFT estás construyendo varias transacciones, podés reutilizar esos scripts de referencia sin recargarlos cada vez. Seguido a eso, las variables de referencia, básicamente las entradas, nos dan la posibilidad, digamos por ejemplo, ciertas tarifas que están relacionadas con nuestra dApp NFT de antemano, y podemos distinguir entre varias tarifas. Esto nos da más flexibilidad en la tarifa variable por venta, por ejemplo para una venta directa y para una subasta. Así que esos son parte de los beneficios que obtenemos de estos scripts de referencia que hemos testeado. Obviamente también tuvimos que realizar algunos cambios al código del contrato inteligente y revisar un montón de cambios de API Cardano, esto es algo que todo desarrollador dApp que quiere moverse de esta versión uno a la versión dos de Plutus, por supuesto lo tiene que realizar. Esto está tomando bastante esfuerzo, pero es bastante normal digamos. Con estos cambios siendo aplicados para el beneficio básicamente de rendimiento, tarifas de transacción, etc. Nuestra experiencia básicamente es que nosotros estamos muy felices de trabajar juntos, porque está acelerando el proceso también para nosotros, para avanzar con nuestra dApp. Estamos obteniendo los beneficios en el hecho de que podemos dar ciertas entradas, que básicamente está ayudando a encontrar muy rápidamente algunos asuntos. Estamos intentando mirar dentro de la situación de cómo podría beneficiar a todos, en vez de sólo cómo nos podría beneficiar a nosotros. Así que es importante que entreguemos algo que es bueno para todos. Así que en general estamos muy felices con los resultados y también con la colaboración con IOHK en esta parte.
Tim: Ronald, IOG ha tenido una colaboración cercana con ustedes durante bastante tiempo, y el trabajo que han realizado por supuesto ha sido inmensamente útil para nosotros y también para la más amplia comunidad a través de múltiples áreas, desde código a documentación, así que gracias. Indigo Labs es uno de los proyectos más anticipados a ser lanzados en Cardano y uno de los muchos buscando sacar ventaja de las mejoras Plutus. El equipo ha estado especialmente ocupado en la red de desarrolladores Vasil estas últimas. Así que Eric, quizás darnos una rápida introducción y contarnos qué han estado haciendo.
Eric: Sí, gracias por tenerme hoy, soy Eric Coley, el fundador de Indigo Labs, estamos construyendo el protocolo Indigo, somos un protocolo de activo sintético construyendo en Cardano, dentro del ecosistema DeFi, nuestro equipo ha estado preparando todos nuestros contratos inteligentes para la bifurcación dura Vasil, integrando desde el CIP 31 al 33. La experiencia devnet, para nosotros, ha sido especialmente útil, estamos testeando las nuevas funciones y funcionalidad que se están desbloqueando, con Vasil.
Tim: Eric, ¿cuáles mejoras han identificado hasta ahora, cuál va a ser la más útil?
Eric: Creo que vimos el mayor impacto positivo en nuestros contratos CDP. En particular creo que estamos anticipando que el CIP 31, las entradas de referencia, eso permitirá a nuestros contratos leer datos de precios de oráculos para nuestros activos sin tener que consumir un UTxO. El beneficio ahí es que los contratos encajarán dentro de las limitaciones en cadena, aliviando cualquier asunto de contención en el UTxO de oráculo. También estamos esperando por el CIP 33, scripts de referencia, esto ayuda a reducir las tarifas de transacción para nuestros usuarios, que obviamente es una gran cosa para ahorro. Pero eso significa que en muchos casos los contratos no tendrán que ser colocados en cadena. Así que ahí también hay un gran beneficio. A través del tablero siento que las comunidades dApp y DeFi se darán que el CIP 31 tiene el mayor impacto reduciendo la sobrecarga leyendo datos de los UTxO, para la computación dentro de los contratos inteligentes. Así que es una aplicación específica para nosotros, como he mencionado previamente, los oráculos. Hemos estado colaborando con el equipo Charlie 3, para asegurarnos que el CIP 31 tenga el mayor impacto posible, viendo cómo Indigo será el mayor consumidor de datos de Charlie 3. Y son un gran equipo, así que queremos ser tan colaborativos como sea posible, ayudando a dirigir eso tanto como sea posible. Creo que es importante templar las expectativas respecto con estos CIPs, estas cosas no ocurren de la noche a la mañana, así que todavía hay algo de trabajo por ser realizado por todos los desarrolladores, para asegurarnos que la integración es limpia. Pero en general, estos CIPs van a a ser muy poderosos, ayudando a pavimentar el camino para lo que será un floreciente ecosistema dApp y DeFi, en Cardano.
Tim: Además de ser una avanzada solución de escalabilidad, Hydra de hecho es una dApp. Sebastián ha estado ocupado con algo de testeos, y mucho más además de eso. Así que Sebastián, has estado ocupado detrás de escena mientras hemos estado ocupados preparándonos para la bifurcación dura Vasil. Quizás puedas compartir más acerca de lo que has estado realizando.
Seba: Aquí en el equipo Hydra hemos estado proponiendo un CIP que ha sido incluido en en nuevo conjunto de funciones Vasil, el CIP 42. Que es algo que descubrimos durante las primeras versiones de Hydra, trabajamos alrededor de algunas molestias de la versión uno Plutus, y resolvimos que esto se podría realizar mejor. Así que propusimos, apoyados por puntos de referencia especializados, una manera más eficiente de serializar datos en cadena con los validadores. Esto se convirtió en el CIP 42, esto fue discutido con alternativas y se incluyó en el proceso CIP. Y terminó siendo implementado por el equipo Plutus, de hecho no fue tan difícil, hasta donde se, así que fue un ciclo de vida e iteración bastante rápido, que ahora es parte del enfoque Vasil a ser liberado. Así que en este CIP particular podemos serializar datos de manera más eficiente. Eso para Hydra significa que, por ejemplo, en vez de ser capaz de distribuir alrededor de 60 UTxOs al cerrar la cabeza Hydra en una única transacción ahora podemos realizar alrededor de 300. Así que tiene una mejora sustancial en la eficiencia de Hydra, hace al contrato un poquito más simple, ya que podés confiar en esto que está construido dentro. Fue una gran experiencia proponer algo, que de hecho luego fue adoptado dentro del enfoque. Nos divertimos mucho, así que contribuyendo a la bifurcación dura.
Tim: Pero hay un poco más por hacer.
Seba: Eso es correcto, de hecho todavía hay algo de trabajo. Lo que hemos estado realizando hasta ahora fue evaluar, asegurarnos que las nuevas funciones están funcionando tal como se espera. Así que eso significa que también hemos estado ayudando a verificar el enfoque de Vasil en una red de pruebas privada, ahora también la red de pruebas pública, mientras se bifurca a la nueva era. Así que a lo largo del camino también descubrimos algunos errores, funciones que pueden ser implementadas para realizar cambios corriente arriba, osea en el nodo Cardano. Supongo que ejemplifica un poco la naturaleza de hacer tu parte y contribuir al nodo Cardano como proyecto de código abierto, con tu trabajo, con lo que hacés y con lo que querés ver siendo capaz de realizar. Hay maneras de proponer y participar realmente y contribuir.
Tim: Sebastián, como sabés, la comunidad ha estado siguiendo el desarrollo Hydra con gran interés, pero antes de que te vayas, quizás darnos una actualización en el progreso, ¿qué viene a continuación?.
Seba: Si mirás nuestra hoja de ruta pública, verás que nuestras funciones actuales de hecho están dando un salto, cambiando el conjunto de funciones, que será bifurcado en la red de pruebas y más tarde en la red principal. Así que nos estamos asegurando que el nodo Hydra es compatible con esta nueva era. Recientemente cerramos la mayoría de las funciones principales del protocolo de cabeza Hydra básico. Eso significa que ahora está en una posición donde podemos cerrar algunas brechas en la estrategia de testeo, realizar más testeo, verificación para apoyar un proceso de auditoría, que estamos comenzando en este momento. Así que durante los próximos meses tendremos el protocolo de cabeza Hydra auditado por participantes externos pero también respaldado por los investigadores, con los que hemos estado trabajando, pero igualmente vale la pena atravesar el protocolo y asegurarnos que funciona de manera correcta. Mientras avanza este proceso de maduración, ahora también mayormente estamos añadiendo funciones, que son necesarias para actualizar de manera segura y bonita el nodo Hydra por los desarrolladores. Si sos un desarrollador probalo, como siempre, está disponible, puede correr en la red de pruebas, comprobá nuestro repositorio, asegurate de mirar nuestra demo, quizás incluso intentar lanzar tu protocolo en un nodo Hydra, en una cabeza Hydra, con lo que sea que te encuentres estaremos esperando tu retroalimentación. Realmente depende de lo que necesitemos para realizar una versión uno convincente para ser lanzada en la red principal y eso es en lo que actualmente estamos trabajando.
Tim: Sebastián, muchas gracias, te dejaremos. Ahora ingeniería de testeo es un proceso crítico en desarrollo de software, que está focalizado en evaluar soluciones técnicas, asegurando que son seguras y que operan exactamente como deberían. James Browning es uno de los ingenieros de testeo que ha estado ocupado preparando el código para la actualización Vasil. James, comencemos con una rápida introducción para la comunidad.
James: Soy James, soy un ingeniero de testeo trabajando aquí en IOG, he estado aquí por un año y medio. Así que estuve trabajando en la bifurcación dura Alonzo el año pasado, y en este momento estamos aplicando algunas mejoras a la red, en la bifurcación dura Vasil, realizando testeos una vez más.
Tim: James, quizás puedas compartir un poco más acerca de qué hace un ingeniero en testeo, por qué es importante y cómo funciona el proceso general.
James: El testeo de hecho comienza testeando nueva funcionalidad temprano en la fase de desarrollo. Usualmente comenzando con las especificaciones formales, mirando eso, y todo el camino hasta tener un candidato de nodo completamente integrado liberado. Es importante comenzar temprano porque nos permite y responder a los asuntos más temprano en el ciclo de liberación. La versión dos de Plutus ha sido entregada con el libro contable y el nodo Cardano CLI soporta toda la nueva funcionalidad. Fuimos capaces de progresar con la etapa final de testeo. Que es utilizar una combinación de herramientas automáticas y un enfoque a mano, así que podemos cubrir escenarios de testeos regresivos de manera eficiente, mientras que exploramos el comportamiento de la nueva funcionalidad. Todo el testeo funcional se lleva a cabo en una red de pruebas de desarrollo, donde es más fácil construir escenarios específicos y aplicar arreglos de software. Esto es algo que no siempre nos permite realizar la red principal, así que esto es por qué es crítico que tengamos alta garantía y calidad antes del despliegue en la red principal.
Tim: ¿Y cómo va el proceso?
Seba: Las cosas van muy bien, el equipo de control de calidad de nodo ha sido capaz de ejecutar la mayoría de los testeos de regresión, y cualquier iteración esencial ha sido resuelta por nuestro equipo de desarrollo. Realmente estamos en la etapa de intentar aparecer con la mayor cantidad posible de interesantes combinaciones y casos de borde, que podrían causar que algo se rompa. Aunque la mayoría del tiempo todo funciona bastante bien, sólo está escalando nuestra garantía de calidad, y todo se está comportando como debería. Creo que los desarrolladores van a disfrutar utilizar esta nueva funcionalidad, yo ciertamente lo disfruté. La combinación de entradas de referencia, datums en línea, scripts de referencia siendo integrados dentro de ello no sólo reducirán las tarifas de transacción, pero también permitirán nuevos diseños que incrementan la transparencia, minimizan la contención y en general promoverán la descentralización.
Tim: Así que transparencia, contención mínima, y más descentralización, cómo no querer eso. Gracias James, Duncan, Ronald, Eric y Sebastián por compartir aquí su progreso.
Eso es casi todo por hoy, asegurate de comprobar algo del último contenido publicado en el blog IOG y Essential Cardano, incluyendo artículos de investigación de cimientos detrás de Cardano, y su innovador modelo UTxO, más algo de Lace, redes Dish, y la iniciativa de documentos de la comunidad Plutus. Cardando Consensus en última instancia fue acerca de la comunidad, y Ben O’Hanlon, Matthew Capps han tenido una semana ocupada estando con muchos de los proyectos y contribuidores del ecosistema que estuvieron ahí, incluyendo World Mobile, Clarity Protocol, Buffybot, DeFi Yield, NFT Maker, Rivuto, veritree y más. Así que mantengan la mirada atenta por un video sobre eso pronto. Saldremos con un último video de Consensus, con la comunidad ahí en total fuerza, qué mejor manera de finalizar este show mensual con una conclusión, con algunos destacados del evento de la comunidad Cardano. Antes de irte, asegurate de darle like, suscribirte y darle a esa campana para ser alertado de todos los nuevos videos IOG a medida que salen. Y para sumergirte más profundo acerca de lo que compartimos en Consensus, encontrarás un montón de enlaces debajo. Gracias por unirte, te veremos el próximo mes.