Transcripción al español de “Mid Month Technical Development Update - February 2022”
Publicado en el canal de Youtube de IOHK el 11 de Febrero 2022
Enlace a la versión doblada al español
Tim: Hola y bienvenido a tu actualización de mediados de mes donde hacemos una inmersión profunda en el desarrollo y entrega de Cardano. Sin más preámbulos, vayamos con la tripulación. Tenemos a Nigel, a Kevin y a John para que nos cuenten un poco más. Nigel, comencemos con vos, Febrero, un mes ocupado.
Nigel: Como siempre Tim, creo que vale la pena tomarse un momento antes de sumergirnos sólo para reiterar, explicar de nuevo cómo hemos madurado como compañía para realizar lanzamientos principales este año. Este año nos concentraremos en tres meses de liberación principal, tenemos fechas fijas para el fin de Febrero, Junio y Octubre. Esto es realmente importante, creo que esto es un gran paso adelante para nosotros como compañía, porque permite a todos los que están involucrados en nuestro ecosistema, a todas las aplicaciones, productos, dar una indicación acerca de cuándo deberían tener que hacer una actualización a sus piezas particulares de software. También significa que para nosotros, internamente, en nuestra estructura central, tenemos a nuestros ingenieros principales que se están focalizando en estas diferentes fechas, entienden y de hecho pueden desarrollar ideas, testearlas, abordar los desafíos que aparecen y construir hacia estas liberaciones principales que vienen.
Tim: Gracias Nigel, quizás nos podés sumergir y hacernos atravesar ese contenido, esa liberación.
Nigel: Seguro, estamos resaltando algunas de las funciones principales que estamos incluyendo, un montón se está focalizando de nuevo en mejorar el rendimiento de nuestra red, también estamos construyendo más y más en términos de oferta de contratos inteligentes, estamos mejorando nuestro ecosistema de contratos inteligentes, trabajo de infraestructura, herramientas de testeo dApp, también otras piezas que los desarrolladores dApps y la comunidad utilizarán en el futuro, mientras construyen todas sus emocionantes nuevas aplicaciones. Mientras avanzamos para todo lo de Febrero, Kevin y John traerán diferentes detalles técnicos, y luego después de eso les daré un adelanto acerca de lo que estamos planeando realizar en Junio. Así que comencemos, veamos la plataforma central. Comenzamos con una de las primeras cosas que está incluída en la liberación principal de fin de Febrero, la liberación del nodo 1.3.3 incluyó un montón de estas estructuras de datos, mapeo, rediseño, que ha mejorado los tiempos de sincronización para Daedalus y un número de otras aplicaciones que están corriendo en la red. La liberación del nodo 1.3.4 se construye encima de todo el buen trabajo que hemos realizado con 1.3.3, pero para decirles un poquito más está Kevin.
Kevin: Gracias Nigel, una gran felicitación al equipo de nodo que ha estado realizando una enorme cantidad de trabajo aquí para hacer mejor la vida de todos mejorando el rendimiento del nodo, hemos estado viendo grandes pasos hacia adelante. Se han realizado grandes mejoras, en particular a la representación de memoria del nodo que se utiliza, alrededor de 12, todas juntas. Tenemos nuevo formato de datos más compacto, tenemos menores entradas y salidas de transacciones en memoria, las capturas de pantalla están utilizando representaciones más compactas, y se comparten valores durante la serialización. Todo esto significa, no sólo menor utilización de memoria, pero también, muy importante, un nodo más rápido, en este momento todos nos estamos focalizando en eso, mejorando el rendimiento general y experiencia para nuestra base de usuarios. Hay un pliegue con esto, que es que la primera vez que utilizás el nuevo nodo, podrías experimentar un tiempo de sincronización un poco más largo que el usual. Y hay una nueva versión de Daedalus Flight que apunta a hacer eso más obvio para el usuario, así que obtenés mejor información acerca de lo que exactamente está ocurriendo bajo el capot mientras utilizás la nueva versión de Daedalus. Pero quizás debería pasarlo a John para que nos cuente un poco acerca de nuestro nuevo formato CDDL.
John: Cuando tenés datos en la memoria de una computadora, tiende a ser instanciada, cuando se crea, vive como un objeto o estructura. Y hay varios formatos acerca de cómo viven los datos en el RAM de una computadora cuando es utilizada por el programa que lo creó. Resulta que la manera en que las computadoras almacenan datos cuando están ejecutando, no es necesariamente una gran manera de almacenar datos cuando estás tratando de moverlos a través de la red. Así que cuando queremos sacar datos de la memoria de la computadora y pasársela a nuestro vecino, como lo hacemos cuando propagamos bloques en la blockchain, u otros mensajes a través de la red. Es importante que tomemos la representación de la memoria de la computadora, y atraviesa un proceso llamado serialización, para tomar ese objeto de datos y representarlos de una manera que es eficiente para el transporte. El enfoque de serialización que tomamos es conocido como CBOR, que significa representación de objeto binaria concisa. Está vagamente basada en JSON que ustedes muchachos podrían conocer del desarrollo web, esta idea de que tenés pares de valores basados en texto, pero CBOR utiliza un formato binario, así que está representado como puros unos y ceros. Así que el cambio que hemos realizado, en particular, es CDDL, que significa lenguaje de definición de datos conciso. Realmente lo podés pensar como un esquema para CBOR. Hemos tratado de ajustar el esquema para nuestra representación de serialización subyacente, y en última instancia lo que significa todo esto es que cuando estamos enviado datos a través de la red, hacemos eso de manera más eficiente y compacta.
Nigel: Gracias John. Lo siguiente que estaremos mirando es la infraestructura de billetera, sé que hemos realizado un montón de avances y mejoras en ese área. Para comenzar a mejorar la funcionalidad en cualquiera de los productos de entrada tenemos que mirar en mejorar la infraestructura. Estamos introduciendo la capacidad de infraestructura para multi firma para fin de Febrero. Esto incorporará la habilidad para que las partes completen transacciones con múltiples firmas, que podría ser utilizado para validar transacciones, votos, o muchos otros contratos u otras posibilidades. Kevin, ¿podés ayudarnos a entender los otros beneficios que podemos obtener de esto?
Kevin: Múlti firma es una función genial, la tuvimos alrededor desde Shelley, como función independiente, hay nuevas capacidades en Plutus, por supuesto. Básicamente múlti firma es acerca de que dos partes, en una transacción, que ambos estén de acuerdo que la transacción es válida. Esto permite por ejemplo tener dos personas firmando la transacción de un pago, o para que dos partes estén de acuerdo en que un contrato se ha completado, todo este tipo de cosas, una función muy útil desde la perspectiva del mundo real. Y lo que hemos estado haciendo en el nodo es mejorar esa capacidad, así que ha habido trabajo en la mejora en la forma en que se realizan las firmas dentro del nodo, esto hace que sea más fácil que la utilice la capacidad de múlti firma.
Nigel: Además de la mejora que obtuvimos con múlti firma, también introdujimos un beneficio y función de reporte, a través de la agenda de liderazgo, esto nos permite obtener visibilidad acerca de qué SPOs estarán produciendo bloques a continuación, nos ayuda a ser capaces de reportar eso. Lo que es útil si sos un desarrollador dApp, ver qué transacciones están siendo procesadas, si hay una posibilidad de que debas volver a presentar una transacción. Pero no es sólo eso en términos del desarrollo de la plataforma principal, también estamos mirando capacidades de contratos inteligentes, también obtuvimos algunas funciones geniales de ese área.
Kevin: Una de las cosas para resaltar es el monitoreo local de transacciones Nigel. Esto vino de discusiones que ocurrieron en la cumbre Cardano del año pasado, brillante evento por cierto, un montón de compromiso de la comunidad, la gente juntándose, focalizándose en nuevas ideas de desarrollo, ingenieros IO trabajando con la comunidad. Trayendo cosas realmente geniales, algunas personas recibieron premios, gente participando en esto no sólo se sentaron a hacer cosas, hay oportunidades para que hagas diferencias reales para la comunidad. ¿Qué es el monitoreo local de transacciones?, esta es una de las cosas que la gente realmente ha estado esperando, es una idea bastante simple. Esencialmente lo que querés es alguna capacidad para saber si el nodo ha procesado una transacción sin tener esperar que esto emerja en la cadena y saber si tu transacción pasó o no. El monitoreo local de transacciones deja a la gente estudiar el contenido de la mempool, te deja ver qué transacciones están siendo procesadas por los nodos, instantáneamente te dice si han sido procesadas o no en la mempool. Luego podés escribir aplicaciones encima de ello para hacer cosas más sofisticadas. Es una gran capacidad, para ser honesto no es muy complejo, es una pieza relativamente pequeña, incluso pequeñas cosas pueden ser realmente útiles muchachos, esto realmente hace la diferencia. Ahora ha sido incorporado como parte del marco Ogmeos, así que si lo estás utilizando podés seleccionar esta capacidad, podés utilizarla ahí. Por supuesto además de esto Nigel, también deberíamos discutir los auto cálculos para scripts Plutus. ¿Te gustaría darnos una actualización sobre eso?
Nigel: Seguro Kevin, esta es una función que obtuvimos cuando lanzamos Alonzo, y lo hemos hecho es escuchar a la comunidad, fuimos capaces de mejorar ahí, y esa liberación está saliendo también a fin de Febrero. Es sólo un recordatorio, también es una herramienta de auto cálculo para ser capaz de entender el tamaño de transacción para scripts Plutus, que es increíblemente útil si sos un desarrollador dApp, porque entonces podés entender cómo podés tener cosas en la cadena, y de hecho cómo va a rendir tu dApp, cuántas cosas podés meter en un bloque, y todas las otras cosas que necesitás realizar como desarrollador dApp.
Tim: Último pero no menos importante, actualización de parámetros. John, has estado manejando este programa, estas mejoras a la red, firme y seguro, pero quizás puedas darnos una actualización respecto a lo que ocurrirá a continuación.
John: Absolutamente, el 2022 es todo acerca de escalar la capa uno en Cardano, he mencionado eso antes. Dejame recordarte lo que ya hemos realizado, comenzamos con bloques de 64 kilobytes, nos movimos a 72, y más recientemente a 80 kilobytes, así que ya hemos realizado mejoras sustanciales al tamaño del bloque. En término de Plutus, Plutus requiere recursos tanto computacionales, unidades de CPU, y unidades de memoria, para ser capaz de realizar cosas útiles con el script Plutus. Comenzamos con 10 millones de unidades en Plutus, nos movimos a 11.25 millones, a 12.5 millones y más recientemente a 14 millones. Literalmente tuvimos un incremento del 40% en términos de los recursos de memoria disponible para los scripts Plutus. Así que un montón serias mejoras a la capa uno ahí. Hoy vamos a postear otro cambio a los parámetros de red principal. Ahora nos vamos a focalizar en límites de nivel de bloque. Antes he hablado acerca de tamaño de bloque, límites de memoria, esas. Esos límites de memoria eran por transacción, y por supuesto también tenemos límites por bloque tanto en unidades de CPU como de memoria. Vamos a incrementar los límites por bloque, para que la gente no sólo pueda escribir scripts que hagan más, pero ahora podrán poner más scripts dentro de esos bloques más grandes.
Tim: Hablando de parámetros John, otro área de bastante discusión en la comunidad de SPOs ha sido alrededor de los parámetros de descentralización. Entiendo que ahora es algo que estamos mirando muy de cerca.
John: Absolutamente Tim, recientemente tuvimos una llamada con más de 250 SPOs, para mí fue una experiencia de gran aprendizaje, fue la primera vez que me encontré cara a cara con muchos de ellos. En IO estamos escuchando, entendemos que tenemos preocupaciones en la comunidad acerca de ciertos parámetros de descentralización. En las próximas semanas vamos a proveer más retroalimentación y claridad acerca de lo que haremos a continuación con estos parámetros.
Tim: Nigel, en lugar de ir demasiado profundo dentro de lo que está viniendo en Junio, quizás podemos hacer una mirada de mil metros, o yardas, dependiendo desde dónde estés mirando esto, sólo dar un poquito de sabor acerca de a dónde vamos, en más detalle, en futuros shows.
Nigel: Seguro, gracias Tim. Traeré lo que estamos mirando para la bifurcación dura de Junio, la llamamos Vasil, esta es nuestra liberación principal para el fin de Junio. Hay un montón de cosas buenas por esperar en la liberación de Junio. Tenemos mucho trabajo ocurriendo en la optimización de Plutus, que realmente va a ayudar a la comunidad de desarrolladores dApp, también tenemos algunas cosas realmente emocionantes alrededor de la eficiencia de red y la muy esperada función pipelining. En vez de realizar una inmersión profunda ahora, vamos a dejar eso para el 360 de fin de mes.
Tim: Ok, muchas gracias Nigel, como dijo Nigel, tendremos mucha más información acerca de lo que está ocurriendo entre el presente y Junio, la bifurcación dura de Junio, en futuras ediciones del show. Este mes también tuvimos la oportunidad de encontrarnos con el equipo Hydra.
Seba: Hola a todos, soy Sebastián, desarrollador y gerente técnico en Hydra, aquí en IOG.
Mathias: Hola gente, mí nombre es Mathias, también estoy trabajando en el proyecto Hydra, realizando el puenteo entre investigación e ingeniería con Sebastián.
Tim: Mathias, recientemente publicaste un posteo de blog para dar una actualización en el progreso de Hydra, también romper algunos mitos e información errónea, quizás puedas contarnos un poquito más acerca de eso.
Mathias: Sí, queríamos escribir este posteo de blog hace bastante tiempo, para proveer actualización de estado acerca de qué estamos haciendo, dónde estamos, que apuntamos a realizar con este proyecto. Pero también para abordar unas pocas preocupaciones que tenemos al observar a la gente hablar en la comunidad, medios sociales, y ver cosas acerca de Hydra. Vimos este asunto de 1 millón de TPS siendo mencionado por todos lados, ya hemos estado hablando de TPS varias veces, diciendo que realmente no es una buena medida para comparar blockchain. Porque todas las blockchains tienen diferentes maneras de definir una transacción. Una transacción en Cardano no es lo mismo que una transacción en otra plataforma. Incluso las transacciones dentro de Cardano ya son muy diferentes, transacciones de contratos inteligentes versus sólo transacciones de puros pagos, es bastante diferente. Así que no es realmente bueno para mirar las cosas, además, en el caso de Hydra, Hydra es muy similar a tener mini libros contables que están bastante aislados unos de otros. Mirando todos esos libros contables, sumando todos los TPS, de todos esos libros contables independientes juntos, realmente podés alcanzar el número que quieras, un millón, un billón, lo que sea. Así que realmente no nos gusta mirar eso, pensamos que es mucho mejor mirar cosas como el tiempo de establecimiento para una transacción por ejemplo, o la cantidad real de datos que está siendo transferida durante un período de tiempo, este punto de referencia es mucho más útil para nosotros, y también significativo. Segundo, también queremos abordar el hecho que Hydra no es sólo acerca de SPOs, y de hecho los SPOs probablemente sean los candidatos menos probables para estar ejecutando cabezas Hydra en primer lugar. Una cabeza Hydra es algo que cualquiera puede ejecutar, pero será alguien con billetera Daedalus o un proveedor de billetera liviana, incluso proveedores de servicios. Realmente queríamos dejar eso en claro, esto no es sólo una cosa de SPOs, esta es una construcción más amplia, una herramienta, y queremos animar a la gente a construir esta infraestructura de solución de segunda capa encima de Cardano utilizando cabezas Hydra.
Tim: Sebastián, vos también recientemente publicaste la hoja de ruta Hydra, quizás quieras sumergirte en eso, contarnos un poquito acerca del progreso ahí.
Seba: Por supuesto Tim. En términos de la hoja de ruta, también queremos ser transparentes. Es por eso que abrimos lo que planeamos internamente, pasos esenciales a alto nivel, a través de madur lo que tenemos, como vista previa de desarrollador que había en Septiembre, a los primeros prototipos madurando, haciéndolos capaces de correr en la red de pruebas Cardano, eventualmente alcanzando madurez de red principal. La hoja de ruta pública está disponible en GitHub, podés ver en esta dimensión, por ejemplo, como las nuevas liberaciones de hecho están compuestas de múltiples funciones, recientemente realizamos la liberación 1 0 3, quizás quieras comprobar las descripciones acerca de lo que hacemos, qué agregamos, qué cambiamos. Y hubo muchas más liberaciones mientras maduramos la cabeza o nodo Hydra, capaz del protocolo cabeza Hydra, hasta que eventualmente 1.0, por supuesto. Esto es algo que queremos, para ser realmente transparentes acerca de lo que estamos construyendo, en lo que estamos trabajando, e incluso discutir con la comunidad cuán importantes son algunas funciones para los distintos casos de uso. En el comienzo por supuesto la mayoría de las cosas son esenciales, pero mientras avanzamos, muchas de las extensiones, protocolos avanzados que están basados en la cabeza Hydra están en discusión, y estamos felices de realizar eso en plataformas abiertas como GitHub, y también otros canales.
Tim: Y por supuesto las contribuciones de la comunidad al proyecto también serán clave en el futuro, quizás puedas contarnos un poquito más acerca de eso.
Seba: Sí, como se puede demostrar aquí, en la hoja de ruta de GitHub, también tenemos discusiones en GitHub, tenemos un canal discord, que está en nuestro servidor técnico IOG, podés preguntar de Hydra, de cualquier cosa, si querés estar informado a alto nivel podés ir a través de los recursos, quizás la documentación, la gente también se educa a sí misma ahí. Por supuesto también hay un exchange de pila, podés hacer preguntas concretas, incluso probar nuestro código base, los aliento mucho a hacerlo. Realmente queremos llevarte en este viaje, todos juntos construir una solución de escalabilidad para Cardano.
Tim: Así que tendremos mucho más de Mathias, Sebastián durante los próximos meses para mantenerte actualizado acerca de lo que está ocurriendo con Hydra. Si querés leer el posteo de blog, asegurate de comprobar el enlace en la descripción del video. También tendremos una demo para vos, así que mantené un ojo en nuestros canales sociales, compartiré eso tan pronto esté disponible. Caballeros, muchas gracias por unirse, ¿algún pensamiento final antes que los dejemos ir?
Mathias: Quizás sólo queremos recordar a la gente que lo que estamos construyendo y buscando liberar es realmente el primer paso en el viaje Hydra. La cabeza Hydra es uno de los primeros protocolos de toda la familia Hydra. También queremos hacerlo bien, hacerlo tan útil como sea posible para la comunidad. Así que por favor unite a nosotros en Discord, Github, cualquier medio, el más conveniente para vos, porque la retroalimentación es crucial para construirlo correctamente.
Tim: Genial, gracias Mathias, todos los enlaces estarán debajo, muchas gracias caballeros, los veremos de nuevo muy pronto. Eso es todo para otra actualización de mediados de mes, por favor asegurate de agendar el último jueves de este mes para el show completo Cardano 360. Gracias por unirse