Transcripción al español de “More on Concurrency”
Publicado en el canal de Youtube de Charles Hoskinson el 10 de Septiembre de 2021
Enlace a la versión doblada al español
Hola, este es Charles Hoskinson, transmitiendo en vivo desde la cálida y soleada Colorado, siempre cálida, siempre soleada, a veces Colorado. Hoy es 10 de Septiembre, 2021, día emocionante y divertido, acabamos de publicar algo en el sitio IOHK, en el blog, se llama “Concurrencia y todo eso: contratos inteligentes Cardano y el modelo UTxO extendido”. Han notado que durante los últimos siete días ha habido un goteo de posteos de blog tanto de proyectos de la comunidad, como Minswap, Sundaeswap, Meld, así como también algunos posteos de blog que vienen de nosotros. Incluso comenzamos a actualizar algo de documentación acerca de patrones de diseño específicos para ayudar a los desarrolladores. Así que de todos modos, les mostraré el blog, déjenme compartir mi pantalla, cerramos slack así no nos molestan, bien, uaaaa, literalmente acaba de salir, dice “Concurrencia y todo eso: contratos inteligentes Cardano y el modelo UTxO extendido”, la fecha está mal. Y dice “Cardano es una blockchain basada en UTXO, que utiliza un paradigma de programación para aplicaciones descentralizadas (DApps) diferente de otras blockchains basadas en Account como Ethereum. El sabor específico que utiliza Cardano es el modelo Extendido de Transacción no Gastada introducido por la actualización de Alonzo. eUTXO ofrece una mayor seguridad que permite la predictibilidad de los costes de ejecución de los contratos inteligentes (sin sorpresas desagradables) y, como resultado, ofrece un enfoque diferente de la paralelización.
eUTXO hereda el diseño por ramas del modelo UTXO (Bitcoin)”, este es de hecho el modelo del que Bitcoin fue pionero, “donde una rama es por definición una secuencia de transacciones que requiere una secuencia de validaciones. Para dividir la lógica en diferentes ramas y aplicar más paralelismo, es esencial construir DApps y otras soluciones utilizando múltiples UTXOs”. Este es el primer asunto que hemos visto, que la gente no está haciendo eso. “Esto proporciona beneficios en términos de escalado, al igual que el desarrollo de los servicios de Bitcoin requiere dividir una billetera en sub billeteras.
“Las DApps construidas sobre Cardano no están limitadas a una transacción por bloque”. Como mucha gente ha estado corriendo alrededor reportando, gritando, ladrando. “De hecho, el presupuesto del bloque (es decir, el número máximo de transacciones que puede contener) permite la ejecución de cientos de transacciones simples y de varios scripts complejos. Sin embargo, el modelo eUTXO permite gastar la salida de una transacción sólo una vez. Dado que los usuarios pueden enfrentarse a problemas de contención al intentar acceder al mismo UTXO, es importante utilizar muchos UTXO diferentes”, ese es el componente de diseño de eso. “Tenga en cuenta que esto es importante a menos que un diseño de este tipo se beneficie de un ordenamiento estricto de los clientes. Los conjuntos de UTXOs pueden utilizarse para implementar patrones de diseño que incluyan semáforos. Además, diferentes usuarios pueden interactuar con un contrato inteligente sin ningún fallo de concurrencia. Esto se debe a que un contrato inteligente puede manejar un número de UTXOs diferentes que conforman su estado actual y metadatos off-chain que permiten interpretar esos UTXOs.”
Luego el posteo de blog sigue como discutiendo cómo hacer las cosas en paralelo, cómo entender concurrencia, un poco acerca de cómo desplegar dApps de una manera un poco diferente, y de hecho terminamos con algunos ejemplos, dice “Propusimos una solución en nuestro reciente documento sobre la moneda estable Djed . Para la implementación de Djed en Cardano, se favorece un patrón de modelado de libro de órdenes en el que un creador de órdenes es responsable de enviar cualquier orden de acuñación o quema al contrato inteligente de moneda estable, con una tarifa de incentivo adicional impuesta a cada posible” …bla bla bla. Así que vamos a publicar todo un artículo en este particular patrón de modelo de ordenamiento, y ese artículo incluirá código que escribimos específicamente para Djed. Esto no es “hey, podría ser realizado”, de hecho te vamos a mostrar cómo hacerlo, cómo nosotros lo hicimos. Además de eso escribimos un par de cosas más, por ejemplo, cómo diseñar una aplicación Plutus escalable, continuamos actualizando eso, de hecho escribimos un poco acerca de los patrones del libro de ordenamiento, y esto, estos tres se enlazan aquí dentro del documento. Esto habla acerca de algunos lineamientos en aplicaciones escalables. Este es un documento viviente, con el tiempo, cuando tengamos un poquito más de tiempo, después de la conferencia, vamos a continuar añadiendo a él pero dá un montón de cosas sobre congestión UTxO, guiones de política de acuñado, guías de escalabilidad y dá algunos ejemplos de diferentes cosas. Y luego hablamos del patrón de libro de ordenamiento, que es una cosa muy importante. De alguna manera la gente tiene que hacer esto para sus cosas. Luego agrupamiento concurrente y determinístico en el libro contable UTxO que fue escrito por los muchachos Meld, de hecho es un muy buen artículo, va a través de un montón de cosas que ellos tuvieron que realizar para resolver este asunto de su lado.
De todos modos, resumiendo, este es un ejemplo de un problema que tiene que ser resuelto por cualquiera que esté implementando. El desarrollador tiene que pensar “¿cómo quiero abordar concurrencia?”, podés hacerlo fuera de cadena, podés hacerlo en cadena. Ahora, el UTxO extendido es un nuevo modelo, así que en su mayor parte, desarrolladores viniendo de el espacio Account, Ethereum, tienen que pensar de manera un poco diferente para resolverlo. La analogía que quiero utilizar aquí es cuando fuimos de procesadores de único núcleo a procesadores múlti núcleo, ves el marketing, doble núcleo, cuádruple núcleo, ocho, diez y seis núcleos. Eso significa que el código bajo el capot tiene que ser escrito de manera un poco diferente para sacar ventaja del paralelismo. Y si no lo hiciste, podrías tener 16, 32 núcleos, de hecho sólo uno estaría comprometido, un hilo estaría comprometido en esa aplicación, a menos que la aplicación fuera reescrita para ello. Es un poco deshonesto decir “oh, bueno Intel es una estafa, Arm es una estafa, AMD es una estafa, nos mintieron, dijeron 16 núcleos pero yo sólo utilizo un sólo núcleo”. Bueno esa una cosa contingente de software, esos están ahí, podés acceder a ellos, hay patrones de diseño para hacer eso, hoy se volvieron mucho mejores que cuando salió el mundo de doble núcleo, pero igualmente necesitás introducir paralelismo dentro de tu código para hacer eso. El patrón de paralelismo para el UTxO extendido, la gente recién lo está aprendiendo ahora mismo. Vamos a continuar escribiendo posteos de blog, vamos a continuar haciendo tutoriales, vamos a continuar añadiendo código, nos aseguraremos de incluir estas cosas en la próxima iteración del programa de pioneros Plutus, mostrar cosas que realmente están corriendo, en la red de pruebas y en la red principal, con el tiempo la gente va a aprender mucho más acerca de estas cosas. Lo que es bonito acerca de este modelo es que tenés un alto grado de flexibilidad, la manera en que diseñamos la programabilidad de Cardano, es que entendemos dónde podés utilizar Accounts y dónde tiene sentido el UTxO, en el lado del mundo UTxO obtenés determinismo de recurso, obtenés un montón garantías acerca de ejecución o la falta de ella, y un análisis mucho más fácil del comportamiento de los contratos. Estas son compensaciones fundamentales de diseño que tienen mucho sentido cuando hablás de verificar el comportamiento del flujo de valor en un contrato inteligente. Es donde están la mayoría de los errores, y el porqué tenés errores que vuelven a aparecer y toda clase de cosas que causaron el DAO Hack, errores multi firma, errores de control de acceso donde los hackers pueden entrar y robarse todo tu dinero.
En el lado Account hace otras cosas por vos, creamos algo llamado diseño Chimeric Ledger, está corriendo a full en Catalyst, lo implementamos de esta manera en Jormungandr, tenés una versión de él corriendo para las recompensas de staking en la red principal Cardano. Mientras estos paradigmas de diseño de UTxO extendido se vuelven más maduros, ocurre un bucle de retroalimentación para los desarrolladores, algunos de los trucos que utilizan los desarrolladores para implementar paralelismo eventualmente serán desplegados dentro del lenguaje en sí mismo y dentro del modelo UTxO extendido. Además de eso, estamos trabajando con un socio llamado Mune para hacer una capa contable emulada en vez una completa implementación Chimeric Ledger. Ahora, eso probablemente es suficiente para la mayoría de los desarrolladores dApps, pero podés convertirlo en un completo modelo Account en cadena como lo que tiene que decir Chimeric Ledger al respecto. Y de hecho, construyendo una capa emulada, testearla, pensar al respecto, creo que podemos hacer un siguiente documento que tenga incluso una mejor fusión entre los dos sistemas.
No es un requisito escribir aplicaciones ahora, de hecho muchas personas ni siquiera tienen que pensar al respecto, van a estar felices con esos patrones de diseño, quizás necesiten otro. El punto aquí es la flexibilidad, ser capaces de utilizar distintos modelos computacionales en cadenas laterales y la cadena principal y también la habilidad de tercerizar computación a actores paralelos, así es cómo lográs escalabilidad, cuando tus operadores pueden convertirse en agrupadores, serializadores y procesadores, y ese modelo de confianza está bien para tu aplicación. El desarrollador de aplicación tiene que tomar la decisión de qué modelo abrazar, eso realmente se reduce a tus costos operativos, tu modelo de confianza, también tu latencia y tiempos de establecimiento que querés tolerar. La capa base provee una combinación de compensaciones, y si eso no es lo suficientemente bueno, vas a otro lugar, el punto es que el sistema te permite cablear fácilmente todos esos componentes para una experiencia de usuario unificada. Y el usuario está al tanto, en esa experiencia de usuario unificada, cuál es el modelo de confianza, ese es el punto, es por eso que invertimos tanto tiempo y pensamiento en ello. Con el tiempo, como dije, patrones de diseño, abstracciones, herramientas y otras cosas serán construidas. Y parece estar esta bizarra narrativa que ha estado flotando en el espacio de que si el 12 de septiembre, cuando accionás el interruptor, no se encienden cinco millones de aplicaciones mágicamente y hay dos trillones de actividad en la cadena al día siguiente es una falla, para mí es una locura, es bizarro. Es un sistema completamente nuevo, es un modelo completamente nuevo, la razón por la que estamos encendiendo esa funcionalidad ahora es porque es seguro hacerlo. Entendemos lo que puede hacer y mejorar masivamente la utilidad subyacente del sistema. Pero eso no evita la necesidad que un montón de estas aplicaciones que la comunidad acaba de comenzar a construir, o pensar al respecto, para testearlas en las testnets, y eventualmente desplegarlas en la red principal dónde y cuándo crean que es necesario. Sólo la existencia de estas funciones en la red principal hacen cosas que nosotros estamos haciendo como compañía, para Etiopía y otras cosas, mucho más fáciles para nosotros, lo mismo para la fundación, lo mismo para Emurgo, y muchos otros proyectos. Pero esa funcionalidad de capa base por supuesto va a ser mejorada, aumentada, y muchos nuevos pitos y silbatos vendrán, como la introducción de Hydra por ejemplo. Y ese es un camino que toma meses, así que cada tres meses habrá un evento HFC, probablemente durante el futuro previsible, eso continuará agregando más capacidades y funcionalidad al sistema, obtendrás aplicaciones más y más sofisticadas. Por supuesto, con esa sofisticación, si las herramientas son construidas correctamente, todavía serás capaz de mantener un buen nivel de calidad y certificación, certeza de que tu aplicación está funcionando bien. La otra cosa es que las soluciones de escalado en las que pensamos para Basho, creemos que son mucho más rápidas al mercado, que una cadena completamente fragmentada. Así que Hydra no es un concepto que está muy lejos ahí fuera, que su aplicación sólo ocurrirá en 2025 o algo así, muchos de los componentes de Hydra, para escalar masivamente concurrencia, usabilidad y menor costo, puede ser implementada a través de todo 2022. Mientras este modelo se vuelve más popular, las herramientas se vuelven más populares, los diseños comienzan a solidificarse, será bastante fácil utilizar estos canales de estado isomórficos, agrupación de procesamiento y otras cosas para básicamente acelerar masivamente las aplicaciones. Ese es el punto, ese es el diseño, por eso construimos UTxO extendido de esa manera, ciertamente hay un montón de sintaxis, azúcares y conveniencias que podés poner dentro del sistema, para potencialmente hacer al sistema un poco más fácil para programación de nivel base, pero entonces perdés algo de lo teórico y la certeza aplicada acerca de las capacidades del sistema, la seguridad del sistema. Así que siempre tenés que balancear estas cosas, por supuesto hay compensaciones ahí. Si no te gusta nada de todo eso entonces mantenete con el modelo estilo Account de Ethereum, eso viene pronto para Cardano, tendremos muchos que decir al respecto en la cumbre. Cuando eso esté ahí podrás correr contratos inteligentes Solidity, todo el ecosistema de herramientas de Ethereum, simplemente mejor, más rápido y más barato, en Cardano, esos contratos pueden llamar a contratos inteligentes Plutus en la cadena principal, esa infraestructura también se construirá. Ese es el punto de ser un súper conjunto, maximizando la funcionalidad.
Enlace a Parte 2 de 2