Traducción al español de “Plutus: what you need to know”, escrito por Lars Brünjes, Director de Educación de IOG [IOHK], el 12 de abril de 2021.
Los desarrolladores se están preparando para la llegada de los contratos inteligentes [smart contracts] de Cardano, estos estarán habilitados por Plutus y la actualización del protocolo Alonzo
Durante nuestra anterior publicación en el blog, hablamos de Alonzo, el nombre que le hemos dado a la actualización del protocolo que introducirá el soporte de contratos inteligentes en Cardano. Alonzo sentará la infraestructura y añadirá herramientas para el desarrollo funcional de contratos inteligentes utilizando Plutus.
La plataforma Plutus aporta un lenguaje de contrato inteligente nativo para la blockchain de Cardano. Su comprensión y dominio requiere entender estos tres conceptos:
-
El modelo *UTxO Extendido (EUTxO)
-
Plutus Core: es la parte “dentro de la cadena” [on-chain] de Plutus
-
Marco de desarrollo de aplicaciones Plutus (PAF según sus siglas en inglés): es la parte “fuera de la cadena” [off-chain] de Plutus que permite la interacción con los contratos inteligentes.
Los contratos de Plutus constan de partes que se ejecutan en la blockchain (código on-chain) y partes que se ejecutan en la máquina del usuario (código off-chain o cliente). Tanto el uno como el otro están escritos en Haskell, y los contratos inteligentes de Plutus son en realidad programas Haskell. Se puede escribir el código fuera de la cadena utilizando PAF, este es compilado por el GHC (Compilador General Haskell), en tanto que el código dentro de la cadena (escrito utilizando el núcleo de Plutus) es compilado por el compilador de esta plataforma.
Es fundamental entender la relación entre estos conceptos de Plutus y la funcionalidad de los tokens nativos para ver cómo su interacción convierte a estos últimos en una característica más eficaz y potente.
El modelo UTxO extendido
Cardano (al igual que Bitcoin) emplea el modelo contable de Transacción (Tx) de Salida (O) no Gastada (U). En el modelo UTxO una transacción tiene entradas y salidas, donde las entradas son salidas no gastadas de transacciones anteriores. En cuanto una salida es utilizada como entrada en una transacción, se gasta y nunca puede ser utilizada de nuevo. La salida se especifica mediante una dirección (una clave pública o un hash de clave pública) y un valor (que consiste en una cantidad de ada y cantidades adicionales de token nativo). La dirección de una salida determina qué transacciones pueden “desbloquear” la salida y utilizarla como entrada. Una transacción se debe firmar por el propietario de la clave privada correspondiente a la dirección. Imagine una dirección como una “cerradura” que sólo puede ser “desbloqueada” con la “llave” adecuada, es decir, con la firma correcta.
El modelo EUTxO extiende este modelo en dos direcciones:
-
Generaliza el concepto de “dirección” utilizando la analogía del candado y la llave. En vez de limitar los bloqueos a las claves públicas y las claves a las firmas, las direcciones en el modelo EUTxO pueden incluir una lógica arbitraria en forma scripts ¹. A modo de ejemplo, cuando un nodo valida una transacción, el nodo determina si la transacción puede o no utilizar una determinada salida como entrada. La transacción buscará el script proporcionado por la dirección de la salida y ejecutará el script si la transacción puede utilizar la salida como entrada.
-
Como segunda diferencia entre UTxO y EUTxO, las salidas pueden contener datos (casi) arbitrarios además de una dirección y un valor. De este modo, los scripts [secuencias de comandos] son mucho más potentes, ya que pueden contener estados.
Cuando se valide una dirección, el script accederá a los datos transportados por la salida, a la transacción que se está validando y a algunos datos adicionales, llamados redentores, que la transacción provee para cada entrada. Al consultar todos estos datos, el script tiene suficiente contexto para responder con un “sí” o un “no” a lo que pueden ser situaciones y casos de uso muy complejos.
Resumiendo, EUTXO extiende el modelo UTXO permitiendo que las direcciones de salida incluyan una lógica compleja a la hora de decidir qué transacciones pueden desbloquearlas y añadiendo datos personalizados a todas las salidas.
Las ventajas del modelo EUTXO son únicas con respecto a otros modelos de contabilidad. El éxito o el fracaso de la validación de la transacción sólo depende de la propia transacción y de sus entradas, y no de nada más en la blockchain. Por consiguiente, la validez de una transacción puede comprobarse fuera de la cadena, antes de que la transacción se envíe a la blockchain. Una transacción puede fallar si alguna otra consume simultáneamente una entrada que está esperando, pero si todas las entradas siguen estando presentes, la transacción está garantizada para tener éxito.
A diferencia de un modelo basado en cuentas (como el utilizado por Ethereum), en el que una transacción puede fallar en mitad de la ejecución del script. Esto nunca puede ocurrir en EUTXO. Por otra parte, los costes de ejecución de las transacciones pueden establecerse fuera de la cadena antes de la transmisión, lo cual es otra característica imposible en Ethereum.
Por último, dado el carácter “local” de la validación de transacciones, se puede alcanzar un alto grado de simultaneidad: un nodo podría, en principio, validar transacciones en paralelo, si estas no intentan consumir la misma entrada. Es estupendo en cuanto a la eficiencia y al razonamiento, pues simplifica el análisis de los posibles resultados y demuestra que no puede ocurrir “nada malo”. Puede adentrarse en el modelo EUTXO en la anterior entrada del blog.
Plutus Core
Para poner en práctica el modelo EUTXO, se necesita definir claramente los términos “script” y “datos”. Los scripts requieren un lenguaje de scripting definido, bien especificado; es también importante definir el tipo de datos que se añaden a las salidas y se utilizan como redentores.
En este punto es donde entra en juego Plutus Core, el lenguaje de scripting utilizado por Cardano. Es un simple lenguaje funcional similar a Haskell; y un gran subconjunto de Haskell que puede ser utilizado para escribir scripts Plutus Core. El autor del contrato no escribe nada en Plutus Core pues el código es generado por un plugin del compilador de Haskell.
Los scripts serán ejecutados por los nodos durante la validación de las transacciones “en vivo” en la cadena. Bloquearán UTXOs en forma de scripts validadores o como políticas de acuñación, que controlan la acuñación y quema de tokens nativos (véase más abajo).
Los datos redentores son un tipo de datos simple (algebraico) que puede ser definido con facilidad en Haskell, lo que constituye otra razón por la que Haskell es una buena opción para escribir scripts de Plutus Core. En la práctica, un desarrollador de contratos inteligentes escribirá scripts validadores en Haskell, los cuales serán compilados automáticamente en Plutus Core.
Las librerías Haskell adecuadas facilitan la escritura de dicha lógica de validación, proporcionando tipos de datos básicos para la inspección de las transacciones durante la validación y ofreciendo muchas funciones de ayuda y abstracciones de alto nivel, lo que permite a los autores de los contratos concentrarse en la lógica del negocio y no tener que hacer frente a demasiados detalles de bajo nivel.
El Entorno de desarrollo de Aplicaciones Plutus (PAF, según sus siglas en inglés)
El estado en la cadena de los scripts validadores solo puede modificarse mediante transacciones que gastan y producen la salida del script. A la hora de escribir una aplicación Plutus, tenemos que tener en cuenta no solo la parte on-chain de la aplicación (los scripts de Plutus Core), también la parte off-chain que construye y envía las transacciones.
El código fuera de la cadena se escribe en Haskell, del mismo modo que el código dentro de la cadena. Por tanto, solo tenemos que escribir la lógica de negocio una vez. Entonces podremos usarlo en el script validador y en el código que construye las transacciones que ejecutan el script validador.
Numerosas aplicaciones requieren vigilar el conjunto UTXO en busca de cambios en determinadas direcciones, así que, si escribimos nuestro contrato como una máquina de estado, debemos rastrear la salida no gastada que representa el estado actual de la máquina y actualizar nuestro estado local cuando el de la cadena cambia. Asimismo, muchas aplicaciones necesitan comunicarse con el backend [código de fondo] de la wallet para acceder a la criptomoneda que están utilizando para las transacciones.
El PAF ofrece un fácil acceso a los servicios comúnmente utilizados por las aplicaciones de Plutus. Las aplicaciones desplegadas utilizando las bibliotecas del entorno de desarrollo [framework] pueden ejecutarse en el backend de la aplicación Plutus, que proporciona soporte en tiempo de ejecución para el acceso a la blockchain y otras preocupaciones como la persistencia, el registro y la supervisión. Las aplicaciones escritas sobre el PAF proporcionan automáticamente una interfaz HTTP y WebSocket que puede ser utilizada para interactuar con la aplicación desde el navegador web.
Tokens nativos
Los tokens nativos están disponibles en Cardano desde el hard fork de febrero. Todos los usuarios pueden crear sus propios tokens, y estos pueden enviarse y recibirse a voluntad, al igual que ada. Cada token nativo tiene su propia política de acuñación, la que determina las condiciones bajo las cuales los tokens pueden ser acuñados y quemados.
Actualmente, estas políticas de acuñación consisten en combinaciones de reglas simples que especifican las firmas y tiempos de bloqueos. Por ejemplo, una política puede determinar que sólo se permite acuñar o quemar tokens en las transacciones con dos de las cinco firmas posibles. Otra política puede permitir la acuñación sólo antes o después de un slot [5 días] determinado.
A pesar de lo poderosos que son estos bloques básicos de construcción, no abarcan todos los usos concebibles. Por ejemplo, es posible, aunque complicado, modelar tokens no fungibles (NFT) utilizando estas políticas simples. Esto podría hacerse empleando un bloqueo de tiempo para acuñar un NFT, limitando la operación de acuñación a un punto de tiempo específico. En caso de que sólo se acuñe un token antes de que se alcance ese punto de tiempo, el token es técnicamente no fungible (ya que sólo existe uno). Sin embargo, para verificar esto, no basta con comprobar la política de acuñación. Tendríamos que mirar el historial de acuñación del token para asegurarnos de que, efectivamente, sólo se ha acuñado una vez.
A partir del despliegue de Plutus, sus usuarios serán capaces de escribir políticas de acuñación utilizando Plutus core. Durante la acuñación o la quema, el script de política de Plutus Core será ejecutado en el contexto de la transacción de ambos procesos, y el script tendrá que aprobar o prohibir la acción. Ello acelerará aún más el crecimiento de las NFTs en Cardano al permitir la creación de políticas de acuñación mucho más complejas y permitir la creación de NFTs de forma tal que la confianza no sea un requisito [o sea, trustless].
Alonzo se está desplegando de forma gradual en la red principal a través de varias redes de prueba, de modo que nuestros socios y pioneros de Plutus podrán probar Plutus Core escribiendo aplicaciones en Cardano a lo largo de mayo y junio antes de la congelación del código ². También será el periodo de garantía de calidad y de pruebas de aceptación de los usuarios por parte de los intercambios para garantizar que la plataforma esté totalmente lista en el momento de la actualización de la mainnet de Alonzo. Si es usted un desarrollador y desea saber más sobre Plutus, plantéese unirse a una futura cohorte de pioneros. Como alternativa, consulte los repositorios GitHub de Plutus y entable debates sobre el tema en el Foro de Cardano.
Agradezco a Jann Müller su aportación y contribución a este artículo del blog.
Notas del traductor
¹ script se trata de un código de programación, usualmente sencillo, que contiene comandos u ordenes que se van ejecutando de manera secuencial y comúnmente se utilizan para controlar el comportamiento de un programa en especifico o para interactuar con el sistema operativo
² congelación del código [freeze en inglés]: En la ingeniería de software , una congelación es un momento en el proceso de desarrollo después del cual las reglas para realizar cambios en el código fuente o los recursos relacionados se vuelven más estrictas, o el período durante el cual se aplican esas reglas. Una congelación ayuda a que el proyecto avance hacia un lanzamiento o el final de una iteración al reducir la escala o la frecuencia de los cambios, y puede usarse para ayudar a cumplir con una hoja de ruta.
Enlaces de interés:
Contratos inteligentes: allá vamos
Todo lo que necesitas saber sobre nuestro nuevo “Programa para Pioneros de Plutus”