El modelo de Marlowe

Marlowe está diseñado para permitir la ejecución de contratos financieros en blockchain, y específicamente para trabajar en Cardano. Los contratos se construyen reuniendo un pequeño número de construcciones que pueden combinarse para describir muchos tipos diferentes de contratos financieros.

Antes de describir estas construcciones, tenemos que ver nuestro enfoque general para modelar los contratos en Marlowe, y el contexto en el que se ejecutan los contratos de Marlowe, la blockchain de Cardano. Al hacerlo, también introducimos parte de la terminología que utilizaremos, indicando las definiciones en cursiva.

Contratos

Los contratos en Marlowe se ejecutan en una blockchain, pero necesitan interactuar con el mundo fuera de la cadena. Las partes del contrato, a las que también llamamos participantes, pueden realizar varias acciones: se les puede pedir que depositen dinero o que elijan entre varias alternativas. La notificación de un valor externo (también llamado valor de oráculo), como el precio actual de una determinada mercancía, es la otra forma posible de entrada. [1]

La ejecución de un contrato también producirá efectos externos, al realizar pagos a las partes del contrato.

Participantes y roles

Debemos separar las nociones de participantes y de roles en un contrato Marlowe. Los roles en un contrato son fijos e inmutables, y podrían denominarse party, counterparty etc. Por otro lado, los participantes vinculados a los roles del contrato pueden cambiar durante la ejecución de la instancia del contrato en particular. Esto permite que los roles en los contratos en ejecución se intercambien entre los participantes, a través de un mecanismo de tokenización. Esto estará disponible en la implementación en cadena de Marlowe, y en la simulación tipo wallet, pero la simulación omnisciente simplemente presenta los roles del contrato.

Cuentas

El modelo Marlowe permite que un contrato almacene activos. Todas las partes que participan en el contrato poseen implícitamente una cuenta con su nombre. Todos los activos almacenados en el contrato deben estar en la cuenta de una de las partes, de esta manera, cuando el contrato se cierra, todos los activos que quedan en el contrato se devuelven a sus respectivos propietarios. Estas cuentas son locales, en el sentido de que sólo existen durante la ejecución del contrato, y durante ese tiempo sólo son accesibles por las partes del contrato.

Pasos y estados

Los contratos Marlowe describen una serie de pasos, normalmente describiendo el primer paso, junto con otro (sub-) contrato que describe lo que hay que hacer a continuación. Por ejemplo, el contrato Pay a p t v cont dice "hacer un pago de valor v de token t a la parte p desde la cuenta a, y luego seguir el contrato cont”. Llamamos a cont la continuación del contrato.

Al ejecutar un contrato tenemos que mantener un seguimiento del contrato actual: después de hacer un paso en el ejemplo anterior, el contrato actual es la continuación, cont. También tenemos que hacer un seguimiento de otra información, como la cantidad que se tiene en cada cuenta: a esta información la llamamos estado: éste también cambia potencialmente en cada paso. En una etapa también puede tener lugar una acción, como el depósito de dinero, o producirse un efecto, por ejemplo, un pago.

Blockchain

Aunque Marlowe está diseñado para trabajar con blockchains en general, [2] algunos detalles de cómo interactúa con la blockchain son relevantes al describir la semántica y la implementación de Marlowe.

Una blockchain basada en UTxO es una cadena de bloques, cada uno de los cuales contiene una colección de transacciones. Cada transacción tiene un conjunto de entradas y salidas, y la blockchain se construye vinculando las salidas de la transacción no utilizadas (unspent transaction outputs) (UTxO) a las entradas de una nueva transacción. Como máximo se puede generar un bloque en cada slot, que tiene una duración de 1 segundo.

Los mecanismos por los que se generan estos bloques, y por quién, no son relevantes aquí, pero los contratos se expresarán en términos de números de slots, contando desde el bloque inicial ("génesis") de la blockchain.

UTxO y wallets

El valor en la blockchain reside en las UTxO, que están protegidas criptográficamente por una clave privada en poder del propietario. Estas claves pueden utilizarse para redimir la salida, y así utilizarlas como entradas para nuevas transacciones, lo que puede verse como un gasto del valor en las entradas. Los usuarios suelen guardar sus claves privadas, y los valores asociados a ellas, en un wallet (billetera) criptográficamente seguro.

Es a través de sus wallets que los usuarios pueden interactuar con los contratos inteligentes -incluyendo los contratos Marlowe- que se ejecutan en la blockchain. Los depósitos se realizan desde los wallets de los usuarios, y los pagos son recibidos por ellos. Sin embargo, hay que tener en cuenta que se trata de acciones fuera de la cadena que deben ser controladas por el código que se ejecuta en el wallet del usuario: no pueden ser realizadas por el propio contrato Marlowe.

Simulación omnisciente y a nivel de wallet

Marlowe Playground dispone de dos tipos de simulación: la simulación estándar omnisciente y una prueba de concepto a nivel de wallet.

En una simulación omnisciente, el usuario puede realizar cualquier acción para cualquier rol, y por tanto puede observar la ejecución desde la perspectiva de todos los usuarios. La simulación tipo " wallet " modela explícitamente diferentes wallets (es decir, diferentes participantes) y su participación en múltiples roles en múltiples contratos. Este modelo presenta, por tanto, una perspectiva más fiel de la ejecución del contrato para un participante concreto en el mismo.

Valor

En los ejemplos anteriores, siempre que se ha necesitado un Value , hemos utilizado exclusivamente Ada. Esto tiene mucho sentido, ya que Ada es la moneda fundamental de Cardano.

Sin embargo, Marlowe ofrece un concepto más general de valor, admitiendo tokens personalizados fungibles, no fungibles y mixtos. [3] ¿Qué es un Value en Marlowe?

Los tipos CurrencySymbol y TokenName son dos simples envoltorios alrededor de ByteString.

Esta noción de valor abarca Ada, tokens fungibles (piensa en monedas), tokens no fungibles (un token personalizado que no es intercambiable con otros tokens) y casos mixtos más exóticos:

Ada tiene el bytestring vacío como CurrencySymbol y TokenName.
Un token fungible está representado por un CurrencySymbol para el que hay exactamente un TokenName que puede tener una cantidad entera no negativa arbitraria (de la que Ada es un caso especial).
Una clase de tokens no fungibles es un CurrencySymbol con varios TokenNames, cada uno de los cuales tiene una cantidad de uno. Cada uno de estos nombres corresponde a un único token no fungible.
Los tokens mixtos son los que tienen varios TokenNames y cantidades mayores que uno.

Cardano proporciona una forma sencilla de introducir una nueva moneda forjándola mediante scripts de política monetaria. Esto incorpora efectivamente los estándares ERC-20/ERC-721 de Ethereum como valores primitivos en Cardano. Utilizamos tokens personalizados para representar a los participantes en los contratos Marlowe que se ejecutan en la cadena.

Ejecución de un contrato Marlowe

Ejecutar un contrato Marlowe en la blockchain de Cardano significa restringir las transacciones generadas por el usuario de acuerdo con la lógica del contrato. Si un contrato espera un depósito de 100 Ada por parte de Alice, sólo esa transacción tendrá éxito, cualquier otra será rechazada.

Una transacción contiene una lista ordenada de entradas o acciones. El intérprete de Marlowe se ejecuta durante la validación de la transacción. En primer lugar, evalúa el contrato paso a paso hasta que no pueda modificarse más sin procesar ninguna entrada, condición que llamamos estar quiescente. En esta etapa se avanza a través de When con los timeouts pasados, If, Let, Pay, y Close construcciones sin consumir ninguna entrada.

A continuación, se procesa la primera entrada, y luego el contrato se vuelve a procesar de paso a paso hasta la quiescencia, y este proceso se repite hasta que se procesan todas las entradas. En cada paso, el contacto actual y el estado cambiarán, algunas entradas pueden ser procesadas, y pagos realizados.

Una transacción de este tipo, como se muestra en el siguiente diagrama, se añade a la blockchain. Lo que hacemos a continuación es describir en detalle cómo son los contratos Marlowe y cómo se evalúan paso a paso.

Hemos mostrado, [4] que el comportamiento de Marlowe es independiente de cómo se reúnen las entradas en las transacciones, por lo que cuando simulamos la acción de un contrato no necesitamos agrupar las entradas en transacciones explícitamente. Para concretar, podemos pensar que cada transacción tiene como máximo una entrada. Aunque la semántica de un contrato es independiente de cómo se agrupen las entradas en transacciones, los costos de ejecución pueden ser menores si se pueden agrupar varias entradas en una sola transacción.

En la simulación omnisciente disponible en el Marlowe playground nos abstraemos de la agrupación de transacciones, mientras que en la simulación de " wallet" basada en roles las transacciones son explícitas.

Construcción de una transacción

transaction

[1]

Podemos pensar en los oráculos como otro tipo de parte en el contrato; bajo este punto de vista, las notificaciones se convierten en las elecciones hechas por esa parte.

[2]

De hecho, Marlowe podría modificarse para funcionar fuera de blockchain, o para trabajar también en una blockchain permisionada.

[3]

Esto refleja el modelo de valor de Plutus.

[4]

En nuestro estudio Marlowe: implementing and analysing financial contracts on blockchain

Encuentra una copia oficial de este documento aquí:

https://alpha.marlowe.iohkdev.io/doc/marlowe/tutorials/marlowe-model.html

https://docs.cardano.org/projects/plutus/en/latest/marlowe/tutorials/marlowe-model.html

Más traducciones de Cardano en: http://CardanoForTheWorld.com