🇪🇸 Serie técnica de Occam.fi: Sobre la concurrencia


Traducción al español de The Occam.fi Technical Series: On Concurrency, escrito por Occam.fi el 1ro de julio de 2021.


La concurrencia se puede visualizar como múltiples actores que acceden a un mismo servicio al unísono.

El presente artículo es el primero de una serie de muchos sobre algunas de las cuestiones y problemas que estamos resolviendo en el ecosistema de Cardano a medida que nos acercamos al lanzamiento del hard fork de Alonzo, cuya llegada está prevista para septiembre de 2021.

Este post dará una visión detallada del problema de la concurrencia - múltiples cálculos que ocurren al mismo tiempo. Lo abordaremos primero desde el punto de vista de Ethereum y luego estudiaremos cómo se traduce a la situación actual del ecosistema de Cardano. Finalmente, exploraremos algunas de las primeras bases de posibles soluciones y hacia dónde podríamos dirigirnos en el futuro. Comenzaremos con una introducción a la concurrencia en el ámbito de la Informática.

¿Qué es la concurrencia?

Iniciemos con una visión general de alto nivel de la concurrencia, que tiene sus raíces en el campo de la ciencia de la computación y puede describirse mejor como: ‘[la] capacidad de que diferentes partes o unidades de un programa, algoritmo o problema se ejecuten fuera de orden o al mismo tiempo en un orden parcial, sin afectar al resultado final’. [1] .

En el mundo de las criptomonedas podemos entender mejor la concurrencia, especialmente cuando se trata de smart contracts (SC), como la capacidad de que varios agentes diferentes interactúen con el mismo smart contract al mismo tiempo.

Figura 1: Perspectiva simplificada de la concurrencia frente al paralelismo

Un ejemplo concreto sería un contrato estándar de intercambio [exchange] descentralizado (DEX) con Bob y Alice intentando intercambiar dos de sus tokens. La concurrencia es que Bob y Alice pueden acceder al mismo contrato al mismo tiempo e intercambiar sus tokens. Como se muestra en la figura 1, podríamos imaginar que Alice y Bob están en colas separadas en la misma máquina expendedora intercambiando sus tokens por otro token al mismo tiempo en el mismo contrato de intercambio. Esto es la concurrencia en su valor nominal, pero en secciones posteriores entraremos en más detalles sobre por qué hay más cosas en realidad.

El modelo de Ethereum

Ethereum fue una de las primeras criptomonedas basadas en cuentas que se crearon dentro del espacio, adoptando un enfoque notablemente diferente al modelo de salida de transacciones no gastadas (UTXO) de Bitcoin. Dentro del modelo de cuenta de Ethereum, el estado global de la blockchain no se almacena en los bloques que se minan. Más bien, se almacena en los nodos localmente, los cuales llegan a un acuerdo comparando el “StateRoot” - o el estado global del sistema [2] .

La máquina virtual de Ethereum (EVM) interpreta las transacciones como eventos y determina el resultado de la transición de estado de estos eventos basándose en el estado anterior. Lo que hace que la abstracción de los desarrolladores sea mucho más fácil y posibilita la construcción de muchas DApps como Uniswap, AAVE, Curve y otras más desde el inicio de Ethereum.

Figura 2: Panorama de la transacción basada en la cuenta

Una forma fácil de imaginar el modelo de Ethereum es entender la cuenta de un agente como un recipiente de $0 a $∞ y al añadir dinero a la cuenta, simplemente se está vertiendo más dinero en el recipiente [llenarlo de líquido], aumentando así su valor. Al realizar la transacción y pagar las tarifas de gas, se vacía la jarra a lo largo del camino tanto por el coste de la transacción como por las tarifas de gas. El valor del fluido en la jarra es líquido - fácilmente adaptable a una transacción y ajustable a nuevos flujos de cuenta.

¿Pueden las transacciones de Ethereum ser concurrentes?

Mencionamos inicialmente que la idea de concurrencia, cuando se trata de los smart contracts, es la capacidad de este para procesar múltiples transacciones de diferentes actores a la vez. Ethereum es capaz de hacer esto, pero tiene una advertencia. Las smart contracts en sí son concurrentes, sí, pero el ordenamiento de las transacciones sigue siendo secuencial y no concurrente.

Esto significa que mientras Alice, Bob y Eve pueden acceder al smart contracts de un DEX para intercambiar pares de tokens, sus transacciones individuales seguirán siendo ordenadas secuencialmente por el minero ya que empaquetan todas estas transacciones en bloques. Los bloques se añaden a la blockchain de Ethereum y posteriormente son reejecutados por los validadores para asegurar que las transacciones son realmente correctas.

Mientras que los smart contracts de Ethereum pueden ser concurrentes, los procesos de ordenación y aprobación de las transacciones no lo son ya que eso introduciría toda una serie de problemas de estado provocados por las transacciones. Digamos que un minero recibe un conjunto de transacciones y comienza a procesarlas todas al mismo tiempo. Inmediatamente se encontraría con un error si una de las transacciones se basara en fondos que se hubieran enviado o recibido a través de otra transacción anterior. Se han realizado pruebas para intentar que el procesamiento de las transacciones sea concurrente y se ha comprobado que aumentan la velocidad de procesamiento en general, pero, no obstante, siguen encontrando transacciones “conflictivas”, deben reordenarlas y volver a procesarlas [3] .

El modelo de Cardano

El modelo de Cardano vuelve a los orígenes de la industria con su creación del modelo UTXO extendido (eUTXO). Bitcoin también se basa en el modelo UTXO y la mejor manera de entenderlo es pensar en las transacciones con Bitcoin como si se tratara de dinero en efectivo. Con el dinero en efectivo, digamos que usted tiene un billete de 10 dólares y quiere comprar una barra de chocolate por 2 dólares. Usted tiene su UTXO original de $10.00 y lo envía al cajero pagando los $2.00, el cajero recibe dos UTXOs de $1.00 y usted recibe, como cambio, un UTXO de $5.00 y tres de $1.00. En conjunto, el cajero tiene 2 dólares y usted tiene 8 dólares, pero individualmente tiene varios UTXOs diferentes que, cuando se suman, forman su “saldo de cuenta”. Tu billete original de 10 dólares se ha “consumido” y en su lugar usted tiene ahora una colección de billetes de 1, de 5 y un chocolate; por su parte el cajero una colección de billetes de 1 y un chocolate menos.

Esta es la mejor manera de pensar en el modelo UTXO realizado por Bitcoin y ahora con Cardano tenemos el eUTXO que es esencialmente un UTXO pero con dos características añadidas - la capacidad de mantener el estado del contrato y la capacidad de hacer cumplir que el mismo código de contrato se utilize a lo largo de toda la secuencia de transacciones. El eUTXO añade datos y valores personalizados a las transacciones, lo que permite una lógica arbitraria para interactuar con estas transacciones y abre la puerta a los smart contract [4] .

Contratos inteligentes de Plutus

Con nuestra nueva comprensión de la concurrencia, el modelo de Ethereum y la concurrencia en términos de sus contratos inteligentes y el modelo eUTXO de Cardano, podemos finalmente comenzar a explorar nuestro tema principal - los contratos inteligentes de Cardano. Estos, en Cardano se almacenan en forma de UTXOs, donde los agentes deben interactuar con el UTXO, que contiene el script lógico del contrato inteligente para realizar cualquier acción que el actor pretenda realizar.

Con el lanzamiento de Plutus, el lenguaje de codificación de Cardano para competir con Solidity de Ethereum en la escritura de SC, Cardano es finalmente capaz de entrar en el espacio de contrato inteligente y comenzar a construir muchas de las DApps que existen en otras blockchains; mientras que permite a los desarrolladores mejorar y reiterar en ellos.

¿Pueden las transacciones de Cardano ser concurrentes?

Esto nos lleva ahora a la cuestión actual de la causa de preocupación entre muchos desarrolladores de Plutus, la cuestión de ‘Contrato-Concurrencia’. Esta concurrencia es diferente de la de Ethereum ya que actualmente con Plutus no hay un estado global o ‘Máquina Virtual Cardano’ a la que todos los contratos inteligentes de Plutus podrían estar conectados. Con Ethereum, como hemos mencionado, muchos actores diferentes son capaces de acceder a un contrato inteligente basado en Ethereum debido al estado global compartido, pero con el modelo UTXO de Cardano ese no es el caso. Con Cardano, los contratos en sí mismos son componentes del UTXO y esencialmente actúan como condiciones que gobiernan cómo se utilizará el UTXO. Una vez que se cumpen los criterios de la secuencia de comandos del contrato, el UTXO se cumple y se “consume” [5] .

Donde los desarrolladores se encuentran actualmente con un problema es en el hecho de que solo un agente puede consumir el UTXO y, por tanto, el contrato inteligente a la vez, creando el llamado problema de “Concurrencia”. Si ponemos esto en el contexto de un DEX; Alice, Bob, Eve, Steve y Joe están tratando de cambiar su ADA por otro token y todos ellos envían su transacción dentro de un bloque determinado, solo el primer agente tendrá su transacción aprobada porque en este momento el UTXO puede ser consumido solo una vez por bloque. En ese momento se convierte en un juego de adivinación para el agente ya que nunca sabrá si su transacción ha sido aprobada o no, hasta después de que el bloque haya sido procesado.

Esto difiere radicalmente del modelo de Ethereum, en el que uno simplemente interactúa con la lógica del contrato inteligente y puede simplemente transferir la acción de cambio de estado a los mineros para su validación. El enfoque de Cardano en la “carrera armamentística de los smart contracts” aporta muchas ventajas para “blindar el futuro” de la red, pero esta cuestión del consumo del contrato es el problema inmediato al que se enfrentan muchos desarrolladores en estos momentos. ¿Cómo se supone que los desarrolladores de proyectos como DEXs, préstamos y protocolos de liquidez van a crear proyectos cuando los contratos que van a alimentar todo su sistema no pueden manejar transacciones concurrentes y no son capaces de soportar múltiples decenas, si no miles, de actores [usuarios] tratando de interactuar con el sistema en un momento dado?

Por último, todo el concepto de provisión de liquidez se pone en tela de juicio porque en el sistema de Ethereum delegar tus tokens LP es bastante sencillo porque todo el sistema es bastante fluido. Cuando intentamos migrar esa idea a Cardano y al modelo eUTXO debemos encontrar una forma de trasladar algo así como un fondo de liquidez al ámbito de los resultados de las transacciones no gastadas.

Mirando hacia el futuro

El problema ha sido abordado por el propio Lars Brunjes @brunjlar en un hilo de Twitter [ [ :es:español e :uk:inglés]] que se muestra a continuación, muchas otras personas dentro del ecosistema de Cardano han reconocido el problema y actualmente están corriendo hacia una solución respecto a la concurrencia.

También tenemos a Sundaeswap.finance, cuyo equipo también ha abordado exactamente el mismo problema en [un artículo y en] su whitepaper. El equipo escribió: “Debido a que cualquier eUTXO solo puede ser gastado una vez, como parte de una transacción, parece que solo puede ocurrir un intercambio por bloque. En la blockchain de Cardano, hay aproximadamente un bloque cada 20 segundos. Esto sería un rendimiento abismal para un intercambio descentralizado”. [6] .

Figura 3: Cardano y la concurrencia

Lars ha afirmado que los ingenieros de IOHK ya están pensando en “máquinas de estado concurrentes” para Plutus y en cómo incorporarlas al código; también ha planteado la idea de la paralelización, como se muestra en la imagen anterior.

Nosotros, en Occam.fi, al igual que en muchos otros proyectos de Cardano, estamos trabajando para encontrar una solución a este problema y probando diferentes teorías y soluciones. Estamos comprometidos a ayudar a resolverlo y a demostrar un producto que funcione con la solución. Con el mes de junio llegando a su fin y la bifurcación dura de Alonzo programada para septiembre, los desarrolladores solo tienen algunos días para solucionar lo de la concurrencia del consumo de SC, pero el equipo que sea capaz de resolver esto ciertamente tendrá una ventaja para los meses venideros.

Fuentes

  1. https://en.wikipedia.org/wiki/Concurrency_(computer_science)
  2. https://medium.com/nervosnetwork/my-comparison-between-the-utxo-and-account-model-821eb46691b2
  3. https://www.cs.stevens.edu/~ejk/papers/podc17a.pdf
  4. https://iohk.io/en/blog/posts/2021/03/12/cardanos-extended-utxo-accounting-model-part-2/
  5. https://ipfs.blockfrost.dev/ipfs/QmRkw1hRfdqPdZMpShDY9oEQQLeAywiY4ZaV9DC7qdDpdh
  6. https://www.sundaeswap.finance/papers/SundaeSwap-2021-06-01-Fundamentals.pdf

Artículos relacionados:

:es: Concurrencia, Estado y Cardano

Traducción del tweet de Lars Brünjes:

El modelo (E)UTxO permite que se consuman muchos UTxO por bloque. Incluso, en teoría, dependientes, donde una transacción crea un UTxO que luego es consumido por otra. En la práctica, este último caso es el que resulta problemático. Al menos si las dos transacciones provienen de wallets diferentes.

https://twitter.com/LarsBrunjes/status/1403761666383306757?s=20