Transcripción al español de “Babel fees via limited liabilities”
Publicado en el canal de Youtube de IOHK el 22 de Julio 2022
Enlace a la versión doblada al español
En este vídeo, Polina Vinogradova, ingeniera de investigación de IOG, nos guía a través de las tasas de Babel, un novedoso mecanismo que permite el pago de tasas de transacción en tokens definidos por el usuario en Cardano.
Hola a todos, mí nombre es Polina Vinogradova, hoy les voy a estar hablando acerca de tarifas de Babel a través de las responsabilidades limitadas. Que es un documento del que fui co autora con Manuel Chakravarty, Nicolás Tallar, Nicolás Kiaias y Michael Peyton Jones. Para espoilear un poquito la sorpresa, las tarifas de Babel son un mecanismo que hemos diseñado para permitir a los usuarios pagar tarifas en tokens que no son Ada. En este momento se requiere pagar las tarifas en Ada, el algoritmo de consenso de prueba de participación depende de esto. Algunos posibles usuarios no quieren utilizar su propio Ada, por lo tanto no pueden construir transacciones válidas, porque las transacciones requieren que se paguen tarifas. Así que estos podrían ser usuarios que quieren realizar transacciones en tokens de juegos, en un mercado del juego por ejemplo. Diferentes usuarios podrían valorar de manera diferente tokens no primarios. Por ejemplo la cantidad de tokens no primarios que el usuario quiere es limitada y luego de ello ya no quieren más un token dado. El precio de mercado del token también puede afectar la cantidad de tokens que no son Ada, que son tokens no primarios, que un usuario podría querer. No queremos dar un mandato a ningún usuario a aceptar recompensas en un token no primario, su ratio de intercambio, digamos, por otro usuario del sistema, o fluctuaciones de mercado impredecibles. Queremos que todos los usuarios acepten un ratio de intercambio con el que están cómodos. El resumen de la solución que nosotros proponemos para esto es que proponemos el mecanismo de tarifas de Babel que deja a los usuarios presentar transacciones, que funciona como ofertas de exchange. Así que por ejemplo yo ofrezco una cantidad “x” del token “y” a cualquiera que quiera proporcionar el Ada requerido para cubrir la tarifa para esta transacción. Así que cualquiera interesado en la oferta podría presentar una transacción que lo acepta. Así que estas dos transacciones junta forman un lote válido, y pueden ser agregadas al libro contable en el lote. Sin embargo tampoco puede ser agregado por sí mismo. El resultado de este mecanismo efectivamente es que el usuario está pagando tarifas en el token “y” en vez de Ada. Un poquito de antecedentes barra revisión acerca de cómo se ve el mecanismo de tarifas Cardano, para ver por qué es difícil directamente pagar tarifas en tokens no Ada. Así que los usuarios presentan transacciones, en este caso ves tres usuarios presentando tres transacciones, cada una con una tarifa. Un productor de bloques ve esas transacciones, el productor de bloques uno en este caso. Así que la tarifa de transacción es calculada basada en tamaño, tiempo de ejecución de contrato inteligente, y otros parámetros. Y todas las tarifas van hacia las recompensas de productores de bloques. Así que las transacciones que recibe un productor de bloques primero va a la mempool del productor de bloque, luego, más tarde, a un bloque. Y el productor de bloque elije qué transacciones poner en un bloque. Así que los bloques tienen una capacidad limitada, por ejemplo, tienen un tamaño máximo de memoria que la transacción puede ocupar, así como también otras limitaciones. La producción de bloques consume recursos, tale como memoria, CPU, costos de equipamiento. Los productores quieren ser recompensados utilizando esos recursos, y obtener ganancias por producir bloques. Así que pueden escoger qué transacciones incluir para maximizar las recompensas para la producción de bloques. En particular este productor de bloque escogió incluir sólo las primera dos transacciones, presumiblemente debido a que la tercer transacción no encajaba en el bloque. Luego, el productor de bloque realiza el bloque, lo envía, lo disemina a través de la red, para que todos los nodos lo procesen y agreguen a su libro contable local. Un libro contable contiene un montón de datos, incluyendo el conjunto UTxO, por ejemplo el conjunto UTxO contiene algunas salidas de la transacción dos y la transacción uno, así como también un bote de tarifas. Así que ahí es a donde van todas las tarifas, es lo que nos importa en esta presentación. El bote de tarifas es sólo el número de tokens Ada que han sido colectados como tarifas en el curso de una época, y en el curso de la época se agregan más bloques, se colectan más tarifas, y todas van al mismo bote de tarifas. En este caso tenemos tenemos algo de valor en el bote de tarifas luego de todo ello. Una vez que se alcanza el límite de bloques se distribuyen las recompensas. Así que todo el dinero en el bote de tarifas se comparte entre todos los productores de bloques y titulares que han producido bloques o poseen participación durante esta época. Así que cada productor de bloque en cada época obtiene una parte del bote de tarifas conteniendo tarifas de cada bloque producido en esa época. Todo se divide de acuerdo a algunas reglas. Dividiendo recompensas tarifas no Ada requeriría un muy complicado cambio de libro contable para calcular qué parte de algún token no Ada un productor de bloque, o titular de Ada obtendrá como recompensas es muy complicado. Esta es la razón por la que es difícil tener un mecanismo para pagar tarifas directamente en tokens no Ada. Las tarifas de Babel realizan las cosas un poquito diferente, y voy a explicar cómo en segundo.
Un poco de trabajo relacionado. El primer pedazo de trabajo relacionado es por supuesto Hitchhiker Guide to the Galaxy de Douglas Adams, que es el inventor de Babel Fish. El mecanismo de tarifas de Babel nos deja traducir de una moneda a otra, al igual que el Babel Fish nos ayuda a traducir de un idioma a otro. Ahora, para un poco de trabajo relacionado real. Hay soluciones existentes para blockchains abordando este problema. Por ejemplo, la solución de Ethereum es utilizar la red Gas Station. Que es como una estructura complicada que está construida encima de Ethereum. Y requiere infraestructura adicional, requiere cambios a los contratos existentes desplegados. Stellar tiene un enfoque diferente para esto. Stellar es otra blockchain multi activo que soporta un dex implementado en el libro contable, que es un exchange distribuido. Los exchanges distribuidos son complicados y susceptibles a ciertos ataques. También hay otra solución ahí fuera, de Algorand, que utiliza meta transacciones, o transacciones incompletas. Este enfoque como que requiere comunicación hacia adelante y atrás, así que dos usuarios se tienen que comunicar fuera de cadena juntos para construir esta meta transacción. Nuestro mecanismo de tarifas de Babel, de nuevo, es diferente que cualquiera de ellos.
Un poco de publicidad para el mecanismo de tarifas de Babel, ¿por qué este es un buen enfoque? Primero que todo, mínima complejidad de cambios a la plataforma. Mínimos cambios a la construcción de transacciones y procesamiento. Mínimos cambios a la validez o efectos a transacciones existentes. No es un Dex implementado en el libro contable. La simplicidad de los cambios que proponemos permiten mantener las garantías seguridad del libro contable existente. Segundo, mínima sobrecarga para los usuarios. No hay un costoso diseño, implementación, mejora, o ejecución de contratos inteligentes existentes, debido a que es un cambio al libro contable que opera a nivel de libro contable, no a nivel de contratos inteligentes. También tenemos una construcción de transacción sin pasos de intermediarios o meta transacciones. Y no se requiere coordinación fuera de cadena para que las construcción de transacciones. También la oferta es especificada y aceptada en el mismo bloque, así que no tenés que presentar una oferta, esperar que el bloque sea procesado, y luego presentar una manera de aceptar una oferta, no es así. No hay costos adicionales asociados con realizar o aceptar ofertas comparado con transacciones de tarifas principales. Así que cuando alguien realiza una oferta es cuánta tarifa es cubierta por esa cantidad específica de tokens, y no hay tarifa adicional que tengan que pagar encima de ello para ser capaces de presentar esa oferta. Y finalmente el mecanismo que proponemos es bastante versátil. Los exchanges no son forzados a un algoritmo fijo, dando a los usuarios el poder para configurar su proceso de selección en cualquier momento y decidir qué tipos de tokens quieren. También es de bastante bajo compromiso. Los usuarios no son forzados a comprometerse o pre pagar para aceptar cualquier oferta futura hasta que presentan la transacción de aceptación. Podrían decir que están dispuestos a cubrir cierto tipo de ofertas pero pueden decidir en el acto, cuando ven una transacción realizando una oferta de intercambio de cierto token, acerca de si la quieren aceptar o no. Finalmente, el mecanismo que proponemos es versátil porque puede ser utilizado para cubrir tarifas de contratos inteligentes e intercambios puntuales, así como también transacciones ajustadamente agrupadas, donde más tarde también iré en más detalles.
Un poco de recordatorio de cómo se ven los multi activos en la blockchain Cardano. Todos los activos en cadena son almacenados utilizando algo llamado paquetes de tokens, que son colecciones heterogéneas de activos tokens primarios y definidos por el usuario. En este caso vemos un ejemplo de un Sword, 20 Game Coin y cuatro Adas negativos en el mismo paquete de tokens. Así que estos cuatro Ada negativos es una responsabilidad, porque es negativo lo llamamos responsabilidad. En este momento, este tipo de valor no puede aparecer en salidas de transacciones. Sin embargo, uno de los principales cambios que proponemos para el mecanismo de libro contable es que la responsabilidad ahora es permitida temporalmente en el libro contable. Como que ya lo dije, pero para la gran revelación, el título del documento es “Responsabilidades Limitadas”, limitada en este caso significa no persistente, y responsabilidades se refieren a deuda, la deuda viene en forma de valor negativo, y no persistente porque no permitimos que persistan valores negativos en el libro contable, tienen que ser resueltos dentro de un paquete. Así que dos de nuestras contribuciones principales al mecanismo de libro contable es que la deuda ahora está permitida en el libro contable. La segunda es una estrategia para resolver esta deuda dentro de un paquete. Agrupar es una manera de asegurar que todas las responsabilidades son resueltas en un libro contable válido. La deuda en el libro contable debe ser resuelta dentro de un paquete. Forzado por un cambio en las reglas de validación de bloques, que ahora validan transacciones en paquetes en vez de atómicamente. Antes, cuando procesabas un bloque, validabas una transacción, determinabas si era válida o no. Sin embargo, con este cambio, cada transacción en el paquete sólo puede ser determinada a ser válida condicionalmente, así que válida pero podría contener responsabilidades. Toda salidas de responsabilidad creadas dentro de un paquete deben ser consumidas dentro del mismo paquete. Así que ahí es donde entra la parte no persistente de la deuda. Dentro de un paquete todas las responsabilidades tienen que ser consumidas, antes que ese paquete sea completamente válido y pueda ser agregado al libro contable. Así que una estrategia de agrupación natural es, por supuesto, que cada bloque forme un paquete. Así que sólo necesitamos comprobar que al final del bloque no haya responsabilidades pendientes.
Daré un pequeño ejemplo para ilustrar qué es lo que estamos realizando con el mecanismo de tarifas de Babel. Aquí ves que Alice tiene una salida con 5 Swords, y Bob tiene una salida con 30 Game Coins. Ambos están jugando a un juego juntos, y sólo están interesados en intercambiar Game coins en el mercado del juego, y ninguno tiene Ada o quiere Ada. Sin embargo quieren construir una transacción realizando un intercambio donde Bob compra cuatro de los Swords de Alice por cinco Game coins por Sword. Alice ha notado que un ratio intercambio de uno a uno de Game Coin por Ada está siendo publicitado por un productor de bloques, y ella quiere sacar ventaja de ello. Así que continúan construyendo esta transacción, las tarifas transacción serán 5 Adas, y la salida de la transacción demostrará que Bob ahora tiene 4 Swords, que cuánto estaba intentando construir, y tiene 10 Game Coins remanentes. Alice todavía tiene 1 Sword, sin embargo, tendrá 20 Game Coins, si no hubiera tarifa de transacción, pero la tarifa tiene que ser pagada. Así que para pagar la tarifa está esta salida adicional de responsabilidad que es creada, que es parte de la transacción, donde un valor negativo de cinco Adas está incluida en ella, así como también un valor positivo de cinco Game Coins. Efectivamente esa es una oferta de intercambio de cinco Game Coins para cualquiera que esté dispuesto a pagar cinco Adas. Así que la diferencia entre las salidas que tienen los pequeños candados con los nombres junto a ellos, Alice y Bob, esto se refiere al hecho de que Alice o Bob tienen que firmar para gastar eso. Sin embargo, el candado con responsabilidad junto a él, cualquiera puede gastarlo, no hay restricciones, así que la transacción gastando es capaz de cubrir la deuda en la responsabilidad. En este caso Alice y Bob, ambos firmaron la transacción porque eso es requerido por los candados. Y la tarifa de cinco Adas es incluida en la transacción, a través de poner eso en la responsabilidad de cinco negativo que ves ahí. Esta transacción en sí misma no es válida para ser colocada en el libro contable porque tiene una responsabilidad no resuelta. Lo que ocurre a continuación, con suerte, Calvin, que ha realizado la oferta de intercambio de uno a uno de Ada a Game Coin, ve que su transacción ha sido diseminada por la red, y decide completar el paquete. Así que agrega su propia entrada a una nueva transacción, la transacción dos, y esta entrada es de 15 Adas, así que ahora gasta la responsabilidad, y la entrada de 15 Ada. También necesita pagar la tarifa de cinco Adas, con lo que termina, en total, es con cinco Adas remanentes y cinco Game Coins que vienen de esa salida de responsabilidad, que fue capaz de resolver. Estas dos transacciones juntas ahora forman un paquete completo, porque ambas son condicionalmente válidas, y la responsabilidad en ellas es resuelta. Después que este paquete sea aplicado al libro contable, esta responsabilidad de hecho no aparece en el libro contable, en el conjunto UTxO, y es por eso que llamamos a esto deuda no persistente, porque el conjunto UTxO de un libro contable válido no contiene esta salida de responsabilidad. Sin embargo realiza un cálculo intermedio de aplicar un bloque.
Para facilitar que paquetes de transacciones sean agregados al libro contable, necesitamos una manera de permitir a la gente poder encontrar qué tipo de ofertas serán aceptadas, y ser capaces de completar paquetes. Este es el mecanismo de descubrimiento de precios, todas las tarifas de intercambio de todos los vendedores son publicadas en una lista fuera de cadena, En este caso ves dos diferentes ratios para Swords, y un ratio de intercambio de una Game Coin por un Ada. Los usuarios pueden ver esta lista y decidir realizar ofertas basados en lo que ven ahí. Así que los vendedores producen ofertas de Babel, que son transacciones de responsabilidad, y lo publican en la red, y como he dicho, deciden cuáles realizar, basados en que ven en la lista fuera de cadena. Y quieren que sus ofertas estén en vivo, así que si una oferta de Babel atrae al menos una parte honesta, la oferta aceptada eventualmente será publicada en la blockchain, es la condición de vivacidad. Y por supuesto, querés realizar una oferta que esté en vivo. Así que en este caso vemos la oferta de cinco Adas por cinco Game Coins, y es enviada, y el productor de bloques uno ve que es una buena oferta. Esta oferta va a la mempool del productor de bloques uno. Así que el productor de bloques construyen un montón de transacciones escogiendo de un conjunto de transacciones disponibles, llamada mempool. Así que los productores de bloques ven todas ofertas diseminadas a través de la red, y son capaces de decidir cuáles de estas ofertas que han ido dentro de su mempool, quieren resolver las responsabilidades ellos mismos, y cuáles paquetes resueltos existentes quieren incluir en sus bloques. Así que un productor de bloques racional trata de maximizar la cantidad de ganancia de moneda primaria por los bloques que están produciendo. Y en el documento de responsabilidades limitadas damos una variación de la solución de programación dinámica al problema knapsack 0/1 para solucionar este problema en tiempo exponencial, así como también damos una aproximación de tiempo polinómica para permitir al productor de bloque maximizar sus ganancias realizadas por transacciones de responsabilidades.
Así que en la imagen vemos que el productor de bloque obtiene su transacción con la responsabilidad, la coloca en la mempool, quizás completan el paquete ellos mismos y produzcan un bloque con el paquete completo, y el productor de bloque uno, como resultado, obtiene cinco Game Coins. Como he dicho, este mecanismo de tarifas de Babel es bastante versátil, en particular hay unas pocas otras maneras de utilizar este mecanismo. Por ejemplo, un atomic swaps. Atomic Swaps amplia la idea de ofertas de tarifas de Babel, para cualquier clase de intercambios, no sólo tarifas. Así que no hay restricciones acerca de qué tipo de tokens pueden ser negativos en salidas de responsabilidad. Así que eso significa que podés realizar responsabilidades no sólo con Ada negativo sino con negativo de cualquier otro token, y realizar atomic swaps de esa manera. Las responsabilidades nos permiten dividir el proceso cooperativo de construir una transacción atomic swap monolítica, en un proceso no interactivo de dos etapas. Así que el primer usuario envía su transacción y no tiene que hacer nada después de eso, y otro usuario en el que necesariamente no necesitan confiar puede ver esta transacción, completar el paquete, y ahora tenés un paquete completamente válido, en un proceso de dos etapas.
Y la segunda manera en que el mecanismo de tarifas de Babel puede ser utilizado es para paquetes indivisibles. Así que las ofertas de tarifas de Babel pueden ser, en este momento, o como he dicho antes, agrupadas a cualquier transacción aceptando esta oferta. Al cambiar el script o bloqueo de firma, la salida de responsabilidad es posible controlar qué tipo de transacciones soy capaz de consumir en esa responsabilidad. Así que previamente en cualquier transacción, si cambiás el bloqueo en el UTxO permite a los usuarios formar paquetes donde las transacciones no pueden ser reemplazadas con otra transacción. Así que por ejemplo, esto es muy útil en el caso de que tengas scripts que necesiten varias transacciones para ejecutar el paso de un programa y que sea completado. Un único paso del script tiene que ser separado en varias transacciones. Esto puede formarse en paquetes utilizando el mecanismo de responsabilidad. Hay algunas otras cosas que tienen que ser elaboradas para que este mecanismo sea viable. Por ejemplo, en este momento el proceso de validación de transacciones en la mempool, en el sistema existente, lleva un libro contable válido a otro libro contable válido aplicando una transacción. Una mempool tiene una transacción y el productor de bloques testea si la transacción es válida aplicando el libro contable válido actual y viendo si el próximo libro contable también es válido. Sin embargo, con el mecanismo de tarifas de Babel, aplicarás una transacción a un libro contable válido, y el libro contable que podrías obtener potencialmente podría potencialmente ser sólo condicionalmente válido, lo que significa que contendrá responsabilidades. No hay manera de decidir si una responsabilidad dada alguna vez será parte de un paquete válido, osea si alguna vez será resuelto. Responsabilidades no resueltas no pueden aparecer en un libro contable válido, así que las mempools podrían estar atascadas colectando estas transacciones condicionalmente válidas, y llenarse de responsabilidades no resueltas, y no son capaces de producir bloques. Esto por supuesto es malo y tenemos que hacer algo acerca de este problema. Hemos estado pensando acerca de algunas soluciones, por ejemplo, sólo transacciones publicadas en paquetes completos en lugar de individualmente. Lo que requeriría un método alternativo de publicación para transacciones individuales con responsabilidades, probablemente fuera de cadena. Otra idea acerca de la cuál estamos pensando es instruir a los nodos relay sólo postear transacciones a esos nodos que han optado aceptar transacciones con ciertas responsabilidades. Esto requiere un mecanismo para mantener listas de ofertas de tokens para saber cuáles responsabilidades tienen probabilidades de ser completadas. Este tipo de mecanismo sería complejo de ajustar para paquetes individuales. Así que después de haber establecido cómo resolver eso, seguiremos el proceso usual, así que realizaríamos un CIP, formalizaríamos este mecanismo, lo implementaríamos en el libro contable, en la billetera, dbSync, etc. Luego, ualá, pago de tarifas en monedas no primarias. Muchas gracias por escuchar, con suerte hayan disfrutado la presentación.