🇪🇸 Validación de transacciones en Cardano, sin sorpresas

:cuba: :es: Traducción de No-surprises transaction validation on Cardano publicada en el blog de IOG.

El modelo EUTXO de Cardano permite la naturaleza determinista de la ejecución de los scripts de Plutus

image

A medida que el hard fork de Alonzo aporta la capacidad de los contratos inteligentes de Plutus a Cardano, la blockchain evoluciona para satisfacer la creciente necesidad de despliegue de soluciones descentralizadas. El diseño de la blockchain Cardano se centra en la alta garantía, la seguridad y la verificación formal probada. En consonancia con esta estrategia, también es importante garantizar que el procesamiento de las transacciones sea determinista, es decir, que un usuario pueda predecir su impacto y resultado antes de la ejecución real.

La capacidad de garantizar el coste de la ejecución de la transacción, y cómo se comporta la transacción en la blockchain antes de ser enviada, se vuelve aún más prominente con la introducción del soporte de contratos inteligentes. Las blockchain basadas en transacciones no gastadas (UTXO), como Cardano, proporcionan estas capacidades. Las cadenas de bloques basadas en cuentas, como Ethereum, son indeterministas, lo que significa que no pueden garantizar la previsibilidad del efecto de la transacción on-chain. Esto presenta riesgos de pérdidas monetarias, comisiones impredecibles y oportunidades adicionales de comportamiento adverso.

En esta entrada del blog, damos un vistazo más de cerca a los beneficios del diseño determinista de Cardano que permite una transacción segura y la evaluación del script antes de la ejecución. En la siguiente publicación del blog, que se publicará a finales de esta semana, hablaremos de las dos fases de la validación de transacciones en Cardano.

¿Qué es el determinismo de las transacciones y por qué es importante?

El determinismo, en el contexto del procesamiento de transacciones y scripts, es un sinónimo de previsibilidad. Esto significa que un usuario puede predecir localmente (off-chain) cómo su transacción afectará al estado on-chain de la blockchain, sin:

  • Resultados o fallos inesperados de validación de scripts
  • Comisiones inesperadas
  • Actualizaciones inesperadas del estado de la blockchain o del script.

Una transacción en un sistema determinista podría ser rechazada, incluso si se construye correctamente. Rechazada significa que la transacción no pudo ser aplicada en absoluto a la blockchain, por lo que no tuvo ningún efecto sobre su estado, por lo que no se pagó ninguna comisión. La razón de que esto ocurra es debido a los cambios en la blockchain causados por otras transacciones procesadas entre el momento en que se construye la transacción inicial y el momento en que se procesa. Esto puede ocurrir incluso con transacciones simples. Por ejemplo, otra transacción podría gastar un UTXO que un usuario también tenía previsto gastar. El determinismo garantiza que, siempre que se acepte una transacción, esta sólo tendrá efectos predecibles en el estado de la blockchain.

Resolviendo el problema del indeterminismo

El indeterminismo significa que no podemos predecir qué efectos tendrá una transacción en la blockchain antes de su ejecución. Al diseñar una blockchain, así como un intérprete de contratos inteligentes, es importante prever las condiciones en las que podría producirse el indeterminismo, y tomar decisiones de diseño para evitarlas. Uno de los principales peligros en este caso es el acceso a datos mutables de la blockchain, es decir, datos que pueden ser cambiados o alterados. El indeterminismo podría convertirse en una problema, cuando los cambios realizados por una transacción o un contrato inteligente sobre el estado de la blockchain ocurren en el momento del procesamiento, en vez de ocurrir según el contenido de la transacción.

Ethereum es notablemente susceptible a este problema. Por ejemplo, los precios del gas, o la tasa de un mercado descentralizado (DEX) pueden fluctuar entre el momento en que un usuario envía una transacción y el momento en que se procesa. Esto da lugar a comisiones de gas inesperadas, o a cambios en el precio de los activos que se compran. O bien, un script puede simplemente fallar, dando lugar a altos costes de ejecución (cientos de dólares) y ningún otro efecto. Esto podría ocurrir, por ejemplo, si los fondos disponibles para cubrir los costes de gas se agotan a mitad de la ejecución. El diseño determinista de una blockchain elimina estas posibilidades.

Otras posibles fuentes de indeterminismo son permitir que los scripts vean:

  • Datos en el bloque que contiene la transacción, pero que no están incluidos en ninguna transacción, por ejemplo, la aleatoriedad del sistema, la cabecera del bloque o el número de slot actual

  • Datos alterados o sustituidos por un adversario, que podrían cambiar el resultado de la validación del script, mientras que la transacción en sí sigue siendo procesable.

En la mayoría de los sistemas, hay formas de mitigar estos problemas con prácticas mejoradas de escritura de scripts, o soluciones de capa 2. Cardano está diseñado para garantizar resultados predecibles para todos los scripts y transacciones.

Cómo se beneficia el modelo básico UTXO en términos de determinismo

La blockchain Cardano se basa en un modelo de contabilidad UTXO, lo que significa que los activos se almacenan en la blockchain en salidas no gastadas (UTXO), en lugar de en cuentas. Cada una de estas salidas especifica las cantidades de activos almacenados en ella, junto con su dirección. Las salidas no gastadas son inmutables, por lo que una transacción puede consumir toda la salida, pero no puede alterarla.

Para transferir activos, una transacción consume una o varias salidas y crea otras nuevas que, en total, contienen las mismas cantidades de activos que las consumidas. Estas cantidades -y sus direcciones UTXO- se especifican en las salidas de la transacción. La única forma en que una transacción puede influir en el efecto de otra transacción aplicada a la blockchain es gastando el mismo UTXO que la transacción posterior intenta gastar, haciendo así que el nodo la rechace. Esta es la característica clave en la que se basa el modelo UTXO para mantener el determinismo.

Un libro de contabilidad UTXO tiene tanto ventajas como inconvenientes respecto al modelo basado en cuentas. Por ejemplo, este último encontrará menos casos de transacciones que se bloqueen entre sí. A diferencia de los UTXO, las cuentas son datos mutables del libro mayor. Así, una transacción puede ver, por ejemplo, una cantidad diferente de activos en una cuenta, dependiendo de si se procesó antes o después de otra transacción que actualiza esa misma cuenta. Esta circunstancia podría no provocar el rechazo de la transacción, pero podría dar lugar a cambios diferentes -e imprevisibles- en la blockchain.

Gastar un UTXO es sólo un ejemplo de una acción que puede realizar una transacción. A continuación, explicamos qué son las acciones de transacción y cómo se pueden validar. El conjunto más significativo de cambios introducidos en Alonzo son los cambios en el proceso de validación de acciones.

Validación de acciones con firmas y scripts

Un aspecto importante del procesamiento de una transacción es la validación de las acciones que está realizando. Una transacción está realizando una acción cuando contiene datos en el campo específico de esa acción. Por ejemplo, una transacción está gastando el UTXO U cuando contiene una referencia a U en su campo de entrada, y está acuñando un token X cuando su campo de acuñación contiene X.

Cuando el nodo procesa una transacción, verifica si puede realizar la acción que pretende. Para ello, el autor de la transacción debe proporcionar datos relevantes, por ejemplo, scripts, canjes o firmas. Un ejemplo común de una acción que requiere validación es gastar un UTXO bloqueado con una clave pública. La transacción debe proporcionar una firma de la clave privada correspondiente para realizar esta acción.

Cardano utiliza scripts para validar las acciones. Estos scripts, que son piezas de código, implementan funciones puras con salidas Verdaderas o Falsas. La validación de scripts es el proceso de invocar al intérprete de scripts para ejecutar un determinado script con los argumentos adecuados.

La validación de scripts puede realizarse para las siguientes acciones:

  • Gastar un UTXO bloqueado por una dirección de script: el script que se ejecuta es aquel cuyo hash forma la dirección.

  • Acuñar un token: el script que se ejecuta es aquel cuyo hash forma el ID de la política del token que se está acuñando.

  • Retirada de recompensas: el script que se ejecuta es aquel cuyo hash forma la dirección de stake.

  • Aplicación de un certificado: el script que se ejecuta es aquel cuyo hash forma la credencial del autor del certificado.

Además de permitir que el nodo sepa qué script debe ejecutar, todas las acciones de transacción indican cómo ensamblar los argumentos pasados a ese script.

La blockchain multiactivo Cardano (Mary) admite lenguajes sencillos de scripting multifirma y timelock. Estos permiten a los usuarios especificar las firmas necesarias para realizar una acción (como gastar un UTXO o acuñar un token no fungible (NFT)), y el intervalo de tiempo en el que se puede realizar. Un script de Timelock nunca puede ver el número de slot real de la transacción que lo incluye. Timelock sólo puede ver el intervalo de validez de la transacción que lo incluye. Permitir que un script de timelock vea el número de slot actual (es decir, los datos procedentes del bloque, en lugar del autor) rompería el determinismo. Esto está garantizado por el hecho de que un usuario no puede conocer el slot exacto en el que se procesa la transacción, y por lo tanto no puede predecir cómo se comportará el script.

Los scripts de Mary, a diferencia de los contratos de Plutus en Alonzo, están muy limitados en lo que pueden expresar. El hard fork de Alonzo da paso a una nueva era más potente y con contratos de estado que no comprometen la propiedad determinista de la blockchain.

Scripts de Plutus

Alonzo introduce un nuevo enfoque para la validación de transacciones en Cardano debido a la implementación de scripts Plutus. El modelo extendido de salida de transacciones no utilizadas (EUTXO), desplegado como parte de Alonzo, proporciona la infraestructura de la blockchain para soportar los contratos de Plutus. A continuación, proporcionamos una visión general de alto nivel de los cambios en la blockchain y las transacciones. Para obtener más detalles sobre el trabajo con la blockchain y los scripts de Plutus, consulte el programa Plutus Pioneer.

Alonzo cambia los datos en la blockchain de la siguiente manera:

  1. Los scripts de Plutus pueden bloquear los UTXOs.

  2. Un nuevo componente, añadido al contenido de las partes de salida de los UTXOs, permite una funcionalidad similar a la de los scripts. Además de los activos y una dirección, un UTXO bloqueado por los scripts de Plutus también contiene un datum. Un datum es una pieza de datos que puede considerarse como una interpretación del estado del script.

  3. Hay una serie de nuevos parámetros de protocolo que se utilizan para imponer requisitos de validación adicionales a las transacciones. Entre ellos se encuentran los límites máximos de recursos computacionales que pueden consumir los scripts.

Para dar soporte a los scripts de Plutus, las transacciones se han actualizado de la siguiente manera:

  1. Para cada una de sus acciones, la transacción lleva ahora un argumento especificado por el usuario, llamado canjeador. Dependiendo del script, un canjeador puede servir para un propósito diferente. Por ejemplo, puede actuar como la oferta que el usuario hace en una subasta, o como la respuesta del usuario en un juego de adivinanzas, entre otras muchas funciones.

  2. La transacción especifica los presupuestos de ejecución computacional para cada script.

  3. Para garantizar que una transacción pueda pagar su presupuesto de ejecución, Alonzo introduce datos adicionales, de los que hablaremos en una próxima entrada del blog.

  4. Las transacciones contienen un hash de integridad, necesario para asegurar que no ha sido comprometido, obsoleto, etc.

También hay algunos cambios en los aspectos específicos de la validación de transacciones de Alonzo en comparación con Mary. Para cada acción, el nodo ensambla los argumentos de script esperados por el intérprete de Plutus, incluyendo

  • El datum
  • El canjeador
  • El presupuesto de ejecución
  • Un resumen de la transacción.

El nodo realiza nuevas comprobaciones, específicas de Alonzo, que aseguran que la transacción se construye correctamente. Por ejemplo, no debe superar el presupuesto máximo de recursos de ejecución. También invoca el intérprete de scripts Plutus para ejecutar los scripts.

Objetos datum vs estado del script

Al igual que las cuentas mutables, el estado de scripts mutables entra de lleno en la categoría de fuentes de indeterminismo de los “datos mutables de la blockchain”. Ya hemos visto que el modelo UTXO evita el problema del indeterminismo de las cuentas mutables. También puede ayudarnos a reimaginar el concepto de estado del script de forma que se mantenga el determinismo. Si un UTXO está bloqueado por un script de Plutus, el código de script de ese UTXO está asociado a su dirección. El estado-análogo de este script es el datum almacenado en ese UTXO. Cuando una transacción gasta ese UTXO, se borra de la blockchain, incluyendo el datum. Sin embargo, el contenido del script Plutus podría obligar a que la transacción que lo lleva también cree un UTXO que contenga un datum específico que pueda ser visto como el estado actualizado del script.

Presupuesto de ejecución de scripts

El modelo de gas no determinista puede cobrar a los usuarios comisiones imprevisiblemente grandes. En los scripts de Cardano, esta fuente de indeterminismo se aborda requiriendo que el presupuesto de recursos en sí mismo, así como la comisión requerida para cubrir este presupuesto, se incluyan en la transacción. En Alonzo, un usuario puede predecir ambos localmente al construir la transacción. La ejecución de los scripts devuelve necesariamente tanto Verdadero como Falso, y no hará un bucle indefinido. La razón de esto es que cada operación que realiza un script toma una cantidad no nula de recursos, que son rastreados por el intérprete. Si se supera el presupuesto especificado por la transacción, la ejecución del script termina y devuelve Falso.

Validación de transacciones en Alonzo

Abordando las posibles fuentes de indeterminismo, los siguientes puntos claves hacen que los resultados de la validación de scripts y transacciones sean predecibles:

  • El intérprete de scripts siempre terminará y devolverá el mismo resultado de validación cuando se aplique a los mismos argumentos

  • Una transacción fija necesariamente todos los argumentos que se pasarán al intérprete de scripts durante la validación

  • Una transacción especifica todas las acciones que realiza y que requieren la validación del script

  • Las firmas obligatorias en una transacción garantizan que no pueda ser alterada por un adversario de manera que haga fallar los scripts

  • La aplicación de una transacción en el modelo de blockchain EUTXO es determinista.

Este último punto se hereda en gran medida del modelo UTXO, ya que las actualizaciones del protocolo de la blockchain Alonzo siguen siendo, en su mayor parte, coherentes con las actualizaciones de eras anteriores (incluido el esquema de delegación, etc.). Después de la actualización de Alonzo, el fracaso o el éxito de la validación de la secuencia de comandos afecta a cómo se procesa una transacción (¡más sobre esto en la parte 2!). Sin embargo, el resultado Verdadero o Falso, así como los cambios en la blockchain asociados a cualquiera de los dos resultados, son predecibles para una transacción determinada.

El comportamiento determinista de la validación de scripts y transacciones de Cardano no es un resultado natural del uso del modelo EUTXO. Para asegurar esta propiedad, el equipo del IOG tuvo que rastrear cuidadosamente la fuente de cada pieza de datos que un script tiene permitido ver.

La propiedad de evaluación determinista se especifica formalmente en la especificación de Alonzo, y el equipo del IOG también ha esbozado la prueba de que el intérprete obtiene sólo aquellos argumentos que no romperían la propiedad.

*En nuestra segunda entrada del blog, echaremos un vistazo más de cerca al proceso de validación en dos fases de las transacciones de Cardano. Así que, mantente atento a finales de esta semana para la segunda parte.*emphasised text

2 Likes