Plutus: Acerca del modelo de Libro Mayor (Ledger)
Cardano, como cualquier otra blockchain, es un libro de contabilidad distribuido o una base de datos que registra todas las transacciones y bloques creados en la cadena. Esta base de datos comparte registros entre todos los participantes y se sincroniza continuamente con las actividades de la blockchain para proporcionar información transparente y actualizada a la que cualquiera puede acceder.
Cardano DB Sync recupera estos registros del blockchain y permite a los usuarios consultar los detalles de las transacciones y los bloques mediante comandos CLI . Para una exploración de datos más cómoda y fácil de usar, puedes utilizar el Cardano Explorer – una interfaz gráfica de usuario que presenta los detalles de forma sencilla.
Un productor de bloques valida cada transacción antes de enviarla a un bloque. El remitente debe tener fondos suficientes, para que no haya un doble gasto, y todos los nodos del libro mayor deben llegar a un consenso.
Veamos con más detalle cómo funcionaba esto dentro del libro mayor de Shelley y cómo los scripts de Plutus cambian este proceso para soportar transacciones de múltiples activos y contratos inteligentes.
Validación de transacciones mediante scripts nativos de Shelley
Cardano opera basándose en el modelo contable de salidas de transacciones no gastadas (UTXO). Este proceso significa que utiliza las entradas y salidas de las transacciones como registros para seguir las transferencias de fondos, la propiedad y los saldos. Los fondos de los usuarios se almacenan como salidas de transacciones no gastadas, cada una de las cuales tiene una cantidad que puede ser gastada. Las entradas son salidas no gastadas de transacciones anteriores. En el momento en que una salida se utiliza como entrada en una transacción, se gasta y no puede volver a utilizarse. La salida se especifica mediante:
- una dirección: que contiene una credencial de pago y una credencial de participación opcional, ya sea un hash de clave pública/de verificación o un hash de script. Técnicamente, la credencial de participación también puede ser un puntero al certificado de registro.
- un valor: refleja el importe real de ada que puede gastarse.
Una transacción debe ser firmada por el propietario de la clave privada (también denominada clave de firma), que corresponde a la credencial de pago incluida en la dirección.
Cardano Shelley soportaba exclusivamente transacciones ada. Sin embargo, la especificación formal de Shelley introdujo el concepto de multi-signature (multisig) scripts, que, siendo nativos por su naturaleza, son capturados en su totalidad por las reglas del libro mayor. Este esquema multisig permitía utilizar la salida de una transacción no utilizada como entrada de una nueva transacción si se proporcionaba una combinación predefinida de firmas. Por ejemplo, si dos personas tienen que firmar la transacción simultáneamente, hay que proporcionar dos de las tres claves, etc.
Multisig es un lenguaje muy sencillo, y permite trabajar con cuatro constructores como RequireSignature, RequireAllOf, RequireAnyOf y RequireMOf. Sin embargo, a medida que se añadan más funcionalidades al libro mayor, los scripts deberían ampliarse para soportar términos adicionales para expresar una serie de otras condiciones.
Actualización de multisig a Plutus Core
Con la introducción del soporte de multi-activos y contratos inteligentes en Cardano, es esencial ampliar el lenguaje de scripting básico de multisig con opciones más avanzadas. Una vez integradas las reglas de Alonzo en el libro mayor (lo que significa la adición de capacidades de contratos inteligentes a Cardano), hemos añadido las herramientas y la infraestructura necesarias, así como el soporte para un nuevo lenguaje de scripting - Plutus Core.
Para actualizar multisig a Plutus Core, el libro mayor Alonzo implementa el modelo de contabilidad de salida de transacciones no gastadas (EUTXO), utilizando Plutus Core para proporcionar potentes capacidades de scripting.
EUTXO amplía el modelo UTXO al permitir que las direcciones de salida contengan una lógica compleja para decidir qué transacciones pueden utilizarse para desbloquearlas y al añadir datos personalizados a todas las salidas. Para lograr esto, los scripts requieren un lenguaje de scripting definido y bien especificado, y deben adjuntarse datos a las salidas, que se pasarán al script durante la ejecución. Plutus Core permite la ejecución de este tipo de scripts complejos por parte de los nodos durante la validación de las transacciones mientras están “en vivo” en la cadena. Se 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. Los datos del redimidor se especifican entonces como un tipo de datos simple (algebraico) que puede definirse fácilmente en Haskell. En la práctica, un desarrollador de contratos inteligentes escribirá scripts validadores en Haskell, que luego serán compilados automáticamente en Plutus Core.
Las bibliotecas Haskell apropiadas simplifican la escritura de dicha lógica de validación al proporcionar tipos de datos básicos para la inspección de las transacciones durante la validación. También ofrecen muchas funciones de ayuda y abstracciones de alto nivel, lo que permite a los autores de contratos concentrarse en la lógica del negocio sin preocuparse por demasiados detalles de bajo nivel.
Encuentra una copia oficial de este documento aquí:
https://docs.cardano.org/plutus/ledger-model
Más traducciones de Cardano en: Home