Traducción al español de “Concurrency, State, & Cardano”, escrito por
SundaeSwap Labs el 5 de septiembre de 2021.
Tras meses de pruebas con grupos más pequeños, la red de pruebas [testnet] pública de Cardano se actualizó recientemente para incorporar contratos inteligentes. La avalancha de actividad que siguió incluyó muchas pruebas y experimentos de dApps [aplicaciones descentralizadas], con desarrolladores ansiosos por realizar una prueba a gran escala y mostrar su duro trabajo. Este esfuerzo ha creado una feroz discusión en torno a algunas decisiones de diseño de Cardano. Muchos críticos están utilizando esta discusión como una oportunidad para acusar a Cardano, tergiversar el problema y, en última instancia, subestimar el potencial de uno de los gigantes de la industria de las criptomonedas. Ahora están flotando ideas erróneas que sugieren que Cardano solo admite una transacción por bloque, que solo un usuario puede interactuar con un contrato inteligente a la vez y que Cardano está destinado en última instancia a la centralización. Todo esto es inexacto, a continuación presentamos un nuevo panorama y el inicio de algunas soluciones que los creadores de dApps podrían elegir.
Parece ser un buen momento para que el equipo de SundaeSwap opine sobre algunas de las cuestiones más comunes que se están planteando - especialmente las decisiones de diseño y contador que llevaron a Cardano a elegir el modelo eUTXO sobre el enfoque de Ethereum, así como el impacto que esta elección tiene sobre la concurrencia en la blockchain de Cardano.
Aunque vemos mucha intensidad en esta discusión, esperamos explorar imparcialmente algunas ventajas, desventajas, conceptos erróneos y, finalmente, presentar algunas soluciones potenciales. Este artículo es bastante técnico de aquí en adelante, pero cerraremos con un resumen no técnico.
El arte del diseño de sistemas es a menudo el arte de elegir entre distintas opciones. Frecuentemente, se puede seguir el crecimiento de la carrera de un ingeniero de software por lo bien que reconoce y emplea estas alternativas para resolver un problema. Para todos nosotros en la comunidad de Cardano, vale la pena analizar qué soluciones alternativas ha elegido Cardano y un punto de comparación útil es Ethereum.
Mucha gente ha señalado que la elección de Cardano de eUTXO puede crear problemas cuando se portan los protocolos. Esto es ciertamente válido; nosotros hicimos referencia a ello en nuestro whitepaper hace meses. Del mismo modo, Lars Brünjes [@brunjlar], Director de Educación de IOG, ha tuiteado al respecto [ 
español e 
inglés] y muchos otros junto con él.
Para entender bien el impacto de esta decisión, vamos a hablar de algunos antecedentes.
Historia
Bitcoin introdujo al mundo la noción de seguimiento de los fondos de los usuarios a través de una lista de “salidas de transacciones no gastadas” o UTXO [“Unspent Transaction Outputs”] para abreviar. Cada transacción entre usuarios consume algunas entradas y produce algunas salidas; cada salida representa un paquete de valor (algún bitcoin) y una declaración de quién puede gastarlo.
Por tanto, si alguien me enviara 1 bitcoin, se generaría una transacción con un resultado de 1 bitcoin, cuyo propietario sería mi clave pública. Entonces podría enviar ese 1 bitcoin a alguien mediante la creación de una transacción que consuma esa entrada, demostrando que tengo derecho a hacerlo y declarando una nueva salida con un nuevo propietario.
Esto tiene una serie de ventajas:
-
Es increíblemente sencillo y seguro de validar. Resulta muy obvio si se está creando o destruyendo valor: se compara el total de bitcoins de entrada con el total de bitcoins de salida.
-
Es muy fácil validar las transacciones de un bloque en paralelo [en desarrollo de software, se puede hacer que este utilice varios “hilos” de ejecución para realizar varias tareas al mismo tiempo]; basta con comprobar la firma de cada transacción en hilos separados.
-
Es altamente determinista. Cuando un usuario crea y envía la transacción, está declarando explícitamente cómo debe ser su sección del libro mayor [ledger, libro contable] después de que la transacción sea aceptada
No obstante, este énfasis en las cuestiones locales, de una sola transacción, va en detrimento de los sistemas que tienen preocupaciones globales. Bitcoin ha tenido dificultades para introducir contratos inteligentes [smart contracts] porque muchas aplicaciones quieren naturalmente acceder a algún estado global: por ejemplo, una lista de usuarios autorizados, un precio actual o un suministro total [total supply].
Ethereum, en cambio, optó por hacer un seguimiento de un conjunto (global) de saldos de cuentas: el estado del libro mayor es un mapeo de la dirección al saldo y una simple transacción incrementa y disminuye los saldos de las cuentas en pares. Las transacciones más complejas pueden hacer cosas más complejas y tienen acceso a su propio estado global. Un token ERC-20, por ejemplo, no es más que un contrato inteligente que implementa este modelo de contabilidad y proporciona una interfaz para acuñar [minting], quemar y transferir estos tokens.
La diferencia entre estos dos puede ser análoga a la diferencia entre el dinero en efectivo en su bolsillo y el saldo en su cuenta bancaria.
El acceso a la información global, como el precio, es trivial en estos modelos. Sin embargo, esta elección tiene muchos efectos secundarios negativos.
En primer lugar, cada transacción debe ser secuenciada y procesada en algún orden, ya que es difícil, si no imposible, determinar qué transacciones pueden tratar de tocar la misma pieza de estado. Si una transacción actualiza el saldo de su cuenta al mismo tiempo que otra, podría destruir inadvertidamente fichas, gastar dos veces y otros errores desagradables.
En segundo lugar, como consecuencia de lo anterior, el orden de las transacciones importa, lo que fundamentalmente da a la entidad que ordena esas transacciones mucho poder. Esto conduce a fenómenos no deseados, como el Valor Extraíble del Minero (MEV) y el front-running.
En tercer lugar, este modelo requiere fundamentalmente un sacrificio del determinismo y, por tanto, exige una mayor confianza. Dado que el estado de la blockchain puede cambiar entre el momento en que se construye la transacción y el momento en que se envía, es necesario confiar en que el smart contract hará “lo que más le convenga” cuando se ejecute, incluso si no es lo que usted pretendía. Por ejemplo, un DEX necesita saber que, si el precio se ha movido en un determinado alto porcentaje, entonces usted ya no está interesado en la operación. Esto supone un gran esfuerzo de desarrollo, una fuente de errores y una superficie de ataque para hackeos, ya que hay que confiar en que cada contrato inteligente compruebe todas las condiciones “correctas”.
El principal problema es que Ethereum hace esta elección de globalizar el estado para cada dApp, por lo que todas ellas sufren el aumento de los costes de transacción, la vulnerabilidad al front-running y la carga de desarrollo adicional.
Tres palabras que puedes ver entrar mucho en la discusión son “concurrencia”, “paralelismo” y “contención”. Puede ser un concepto sutil y en caso de que solo tenga usted una vaga idea de lo que significan, vale la pena establecer algunas definiciones: La concurrencia es la capacidad de varios actores de progresar en una tarea, sin interferir unos con otros. El paralelismo es la capacidad de varios actores de progresar en una tarea al mismo tiempo, sin interferir unos con otros.
La contención se produce cuando varios actores interfieren entre sí. Para entenderlo mejor, utilicemos una analogía: los chefs en la cocina. Un solo chef experto puede trabajar en la preparación de varios platos a la vez, cambiando entre ellos en el momento justo. Este chef es altamente concurrente. Varios cocineros pueden trabajar en diferentes platos en su propia zona de trabajo. Estos cocineros son altamente paralelos. Sin embargo, una cocina bien gestionada puede tener muchos chefs trabajando en muchos platos a la vez y ser al mismo tiempo concurrentes y paralelos. Si empiezan a chocar entre sí cuando buscan un ingrediente común, de repente están experimentando contención.
En el contexto de esta discusión, Ethereum es decente en la concurrencia, terrible en el paralelismo. El modelo UTXO es fantástico en el paralelismo, pero podría enfrentarse a la contención, haciendo que no sea muy concurrente, para algunos diseños de protocolo.
Cardano y eUTXO
Finalmente, podemos hablar de Cardano. Cardano optó, en cambio, por mejorar el modelo UTXO lo suficiente como para que las propias dApps pudieran hacer estas concesiones entre el funcionamiento independiente y la centralización. El modelo eUTXO sobre el que Cardano lideró la investigación introduce tres nuevas primitivas para los smart contracts: El dato, el canjeador y el validador.
El dato es una pieza arbitraria de datos adjunta a un único UTXO. Representa un trozo de estado interno relevante para ese UTXO. Se puede utilizar, por ejemplo, para rastrear la hora de desbloqueo y la dirección de retorno de un contrato de adquisición de derechos.
El redentor representa la señal de qué hacer, cuando hay múltiples opciones. Por ejemplo, podrías utilizarlo para representar si vas a canjear tus tokens adquiridos, o si vas a ejercer el clawback porque se han roto los términos del vesting.
Por último, el validador representa las condiciones en las que se puede gastar el UTXO, incluyendo la validación de si el nuevo estado es correcto. Tiene acceso a toda la transacción para tomar esa decisión.
El único estado del que puede depender un smart contract son los trozos de estado incluidos como entradas y el único estado que puede producir un smart contract son los declarados como salidas de la transacción.
Las transacciones en Cardano están parcialmente ordenadas por sus dependencias y un operador de stake pool que reordene las cosas no tiene ningún impacto en el resultado, por lo que MEV desaparece.
Del mismo modo, cada transacción de Cardano es determinista: el usuario construye, declara y firma el nuevo estado del mundo. La única manera de cambiar el estado es gastando UTXOs y un UTXO dado solo puede ser gastado una sola vez, por lo que estás protegido contra el cambio de estado.
Para muchos propósitos y protocolos, esto es totalmente suficiente para construir una increíble cantidad de valor. Un contrato de adquisición, por ejemplo, no necesita acceder a ningún estado global. El hecho de que los tokens de Alice estén en un UTXO bloqueado por el contrato de adquisición no tiene ninguna relación con el hecho de que los tokens de Bob estén en otro UTXO bloqueado por el mismo contrato de adquisición.
Algunos protocolos, sin embargo, son mucho más difíciles de separar de su estado global. Un DEX como Uniswap, por ejemplo, se basa fundamentalmente en la puesta en común de la liquidez para la eficiencia del capital y en la creación de una única visión unificada del tipo de cambio entre dos tokens.
Si muchas personas necesitan acceder a este estado global y ese estado se almacena en el dato de un único UTXO, se crea una carrera entre los usuarios para ser los primeros en gastar ese UTXO. Cada vez que alguien gana esa carrera, todos los demás vuelven al punto de partida: tienen que encontrar el nuevo UTXO, construir una nueva transacción y enviarla.
Tanto si las transacciones se limitan a remitirse a los UTXO de bloques anteriores como si pueden encadenarse dentro de un bloque, esta contención fundamental supone un serio reto para la experiencia del usuario y el rendimiento de un protocolo.
Por lo tanto, es necesario realizar una ingeniería inteligente al diseñar el protocolo.
Conceptos erróneos
Antes de hablar de soluciones, vale la pena abordar algunas ideas erróneas sobre el tema:
Falso concepto 1: Cardano es defectuoso porque solo permite 1 transacción por bloque.
De hecho, es todo lo contrario. Cardano permite muchos cientos de transacciones por bloque.
En cambio, es correcto decir que Cardano permite que una salida de transacción dada sea gastada una sola vez, por una sola transacción, por lo que los protocolos que dan acceso a múltiples personas a la misma UTXO podrían enfrentar problemas de contención
Falso concepto 2: Solo un usuario puede interactuar con un smart contract por bloque/transacción.
También es falso; el punto de contención es alrededor del UTXO, pero muchos UTXOs pueden ser gobernados por el mismo smart contract.
Esto se reduce fundamentalmente al cambio de pensamiento de Ethereum, donde se llama a un smart contract para que haga algo y en Cardano, se bloquean las salidas con un contrato, el cual determina cuándo se pueden gastar posteriormente .
Falso concepto 3: La única manera de resolver esto es a través de la centralización.
La centralización es una forma de resolver este problema, pero no es la única. Véase más abajo.
Posibles soluciones
Hoy en día, parece haber dos categorías de soluciones a este problema: o bien diseñar su protocolo para tolerar la segmentación de su estado, o bien agregar las interacciones con ese estado.
Diseñemos algunas DEX hipotéticas para explorar algunas de estas soluciones.
Uno podría diseñar un DEX de tal manera que no requiriera un único fondo de liquidez. En su lugar, la liquidez se fracciona entre varios fondos y cuanto más se fraccione, habrá más puertos para que la gente interactúe y menos contención sobre esos fondos. Sin embargo, cuanto más se fracturen los fondos, menor será la eficiencia del capital y mayor el valor perdido por el arbitraje entre fondos. La parte inteligente, por tanto, consiste en diseñar soluciones a esos problemas: por ejemplo, la liquidez concentrada al estilo de Uniswap v3.
Alternativamente, un modelo de libro de órdenes para un exchange, que en Ethereum es desastrosamente caro de mantener y actualizar, parece más adecuado fundamentalmente para Cardano: cada orden es un UTXO separado. Sin embargo, la parte más complicada es que todavía hay disputa por las órdenes más cercanas al precio actual, donde se juntan los montones de arena. Una solución viable sería que las órdenes de mercado aparecieran en la cadena y que un agregador de terceros las emparejara y ejecutara. La parte inteligente, entonces, está en asegurar que el encargado de emparejar no tenga demasiado poder sobre el mercado.
Por último, se podría crear una exchange híbrido, donde la custodia de los fondos está descentralizada y se almacena en la blockchain, pero la creación de mercado y el emparejamiento se envían a través de un servidor backend central. Esto resuelve el problema de ingeniería, pero probablemente te convierte en un agente de bolsa fuertemente regulado, lo que viene con su propio conjunto de desafíos.
La solución de SundaeSwap
Hemos elegido una solución que difiere de las anteriores; muy pronto estaremos listos para correr la cortina y revelar cómo funciona. Dada la naturaleza del reciente debate, queremos hacerlo con recibos y actualmente estamos preparando las pruebas para demostrar exactamente que nuestra solución de escalado está a la altura. Manténgase atento a más información.
Resumen
En resumen, los rumores de la “decadencia” de Cardano son muy exagerados. Hay soluciones a los problemas que se observan hoy en día, beneficios en las formas en que se ha diseñado Cardano y tanto un futuro brillante, como una intensa fase de descubrimiento de diseños por delante.
Es un aspecto poco saludable de nuestra industria que muchas personas, a menudo con voces prominentes, sean maximalistas en una tecnología. Esto puede estar motivado por un incentivo financiero, esperando que una gane a la otra para obtener beneficios económicos; puede ser un compromiso desbocado con un solo proyecto a expensas de todos los demás, donde se ha vuelto imposible dar marcha atrás y seguir salvando la cara; o puede ser simplemente un mal sabor de boca por las malas interacciones con los miembros de otra comunidad. En cualquier caso, no es muy saludable estar en una posición de argumentar que un proyecto en nuestra comunidad tiene todas las respuestas y es superior en todos los sentidos, sea ese proyecto Bitcoin, Ethereum, Cardano, Solana, Mac, PC, Hammers, Screwdrivers, o cualquier número de otras opciones que tenemos sobre las herramientas a utilizar.
No encontrarás ningún maximalismo de Cardano en nuestro equipo. Creemos que, sí, Cardano tiene soluciones interesantes a problemas difícile, ha hecho concesiones y priorizado cosas de manera diferente que crean nuevas oportunidades en el ecosistema de las criptomonedas. Ciertamente creemos en él lo suficiente como para construir nuestro producto sobre él. A largo plazo, como constructores en el espacio de las criptomonedas, creemos que al usuario final no le importará con qué blockchain está interactuando. El estado final ideal, en nuestra opinión, es que las cadenas de bloques se conviertan en lenguajes de programación, con diferentes proyectos eligiendo diferentes cadenas que se ajusten a los puntos fuertes necesarios para sacar a la luz su protocolo y que los usuarios finales no se enteren.
Así que para la gente que afirma que esto es la muerte de Cardano: es poco probable. Apuntar a un experimento difícil en los primeros días de un ecosistema y sostenerlo como el fatal presagio de la caída de Cardano es, en el mejor de los casos, una ingenuidad prematura y, en el peor, una falta de honestidad intelectual. Hemos esbozado varias soluciones creativas más arriba y estamos seguros de que hay muchas más que se les han ocurrido a quienes construyen sobre Cardano.
Nota del Traductor:
Es esta una traducción hecha con algo de premura en aras de entregar la información en nuestro idioma lo más pronto posible. En unas horas se habrán hecho cualquier corrección requerida.
Articulos relacionados: