馃嚜馃嚫 Tutoriales de Marlowe: 16. Migraci贸n desde versiones anteriores de Marlowe

Migraci贸n desde versiones anteriores de Marlowe

Este tutorial explica en qu茅 se diferencia la 煤ltima versi贸n de Marlowe de las versiones anteriores del lenguaje.

Eliminar Both

En la 煤ltima versi贸n de Marlowe no incluimos la construcci贸n Both , lo que hace que todos los contratos sean secuenciales.

Dado que en ninguna de las versiones de Marlowe hubo comunicaci贸n entre las ramas de Both, la 煤nica funcionalidad extra que proporcionaba Both en la pr谩ctica era la posibilidad de esperar varios dep贸sitos de dinero al mismo tiempo.

Nos encargamos de esta funcionalidad actualizando la construcci贸n When . En lugar de tener diferentes ramas esperando por diferentes entradas, pasamos a un modelo completamente secuencial y s铆ncrono, donde podemos esperar una de varias entradas posibles al mismo tiempo (como en select).

La raz贸n por la que eliminamos esta construcci贸n es que los programas secuenciales son m谩s f谩ciles de analizar y de razonar, ya que no hay necesidad de sincronizaci贸n y no hay oportunidad de condiciones de carrera.

Incluir las cuentas

En versiones anteriores de Marlowe cada compromiso tiene su propio timeout. Esto significa que el dinero depositado en un contrato no es fungible , porque se puede distinguir por su timeout. Para lograr la fungibilidad hemos eliminado los timeouts de las construcciones individuales, y tenemos un 煤nico timeout para todos los compromisos. Este tiempo de vida del contrato es f谩cil de inferir a partir de los timeouts del contrato.

Sin embargo, incluimos cuentas para organizar el dinero depositado en el contrato. Esto hace m谩s transparente el flujo de dinero dentro del contrato y, en particular, identifica a qui茅n se le devuelve el dinero cuando el contrato termina.

Cada cuenta est谩 identificada por un participante; el participante indica qui茅n recibir谩 el dinero de la cuenta por defecto cuando se llegue al Close .

La raz贸n por la que decidimos incluir las cuentas es que, sin ellas, nos dimos cuenta de que est谩bamos llevando a cabo un seguimiento manual de las cuentas. Adem谩s, en cada hoja del AST, nos encontr谩bamos calculando cu谩nto deb铆amos devolver a cada participante, lo que abarrotaba el 谩rbol con una repetitiva 鈥減alabrer铆a鈥. Por lo tanto, tener el dinero organizado en cuentas puede hacer que los contratos sean m谩s f谩ciles de razonar y menos propensos a errores.

Ten en cuenta que podemos proporcionar una fungibilidad completa utilizando una sola cuenta. S贸lo tenemos que escribir los comandos de Pay apropiados en las hojas del contrato. Si todo el dinero se paga a los participantes, entonces Close no tiene ning煤n efecto. [1]

Discusi贸n: Cuentas impl铆citas frente a cuentas expl铆citas

Muchos de los casos de uso de las cuentas -y todos los que podemos identificar para los contratos ACTUS- tienen una cuenta por participante, y un participante por cuenta (el 鈥渕odelo 1-1鈥). Esto plantea la cuesti贸n de si debemos dar un tratamiento impl铆cito a las cuentas, siendo cada participante propietario de una cuenta.

Por otro lado, hay una variedad de escenarios plausibles para las cuentas que no se ajustan al modelo 1-1.

Ejemplos en los que varios participantes utilizan una cuenta.

  • Alice es propietaria de una cuenta en la que compromete dinero para que Bob lo gaste (piensa que Alice es la empleadora de Bob). Bob puede gastar hasta el l铆mite de la cuenta, pero despu茅s de que el compromiso se agote, Alice recupera todo lo que queda.
  • Alice es propietaria de una cuenta en la que compromete dinero para que Bob y Carol lo gasten (piensa que Alice es la empleadora de Bob y Carol). Pueden gastar (conjuntamente) hasta el l铆mite de la cuenta, pero despu茅s de que el compromiso se agote, Alice recupera todo lo que queda.
  • Por otro lado, se les podr铆a dar a cada uno una cuenta separada desde la que gastar: eso har铆a cumplir los l铆mites individuales as铆 como un l铆mite agregado.
  • Si Bob [y Carol] quieren gastar dinero tambi茅n pueden a帽adir dinero a la cuenta, pero deben saber que todo lo que no se utilice se devolver谩 a Alice.

Ejemplos de cuentas m煤ltiples para una persona:

  • Los ejemplos de aseguramiento encajar铆an aqu铆. Una persona asegura el riesgo de primer nivel y el de segundo nivel utilizando cuentas diferentes. S贸lo cuando se haya gastado la garant铆a de primer nivel de todos los participantes se producir谩 el gasto de segundo nivel.

Close reemplaza a Null / Pay

Como todos los contratos son ahora secuenciales, podemos decir f谩cilmente cuando un contrato llega a su fin, es decir, cuando s贸lo queda Null. Aprovechamos esta oportunidad para cerrar el contrato y devolver el dinero que queda en las cuentas; por eso hemos cambiado el nombre de Null por el de Close (para facilitar la comprensi贸n).

Como se ha se帽alado anteriormente, ya no hay ning煤n timeout expl铆cito en las cuentas, ya que todos los contratos acabar谩n reduci茅ndose a Close. De hecho, podemos calcular de forma est谩tica y eficiente un l铆mite superior para cuando esto ocurra, haciendo que este aspecto de Marlowe sea analizable.

Pay

Pay es ahora inmediato, y tiene una 煤nica continuaci贸n, y menos par谩metros. [2] Permite los pagos de una cuenta a un participante o a otra cuenta. Descartamos PayAll, ya que se puede emular como una serie finita de Pay. De hecho, podemos definir payAll como una funci贸n Haskell (v茅ase el ejemplo de zeroCouponBond ).

Una consecuencia de la eliminaci贸n de la construcci贸n Both es que ahora es inequ铆voco cu谩l es el primer Pay : todos son secuenciales, lo que facilita el an谩lisis. Con la construcci贸n Both , podr铆amos tener Pays en cualquier orden (ya que ambos lados de Both se supone que se ejecutan simult谩neamente).

Multi-cl谩usula When

Hemos modificado When para incluir un conjunto de posibles acciones que se pueden introducir mientras When espera. Llamamos a este enfoque 鈥淯no de muchos鈥, porque acepta una acci贸n de las potencialmente muchas permitidas. When queda as铆:

MT-16-1

donde When esperar谩 al Timeout y continuar谩 como Contract, o continuar谩 como se especifica en uno de los Cases, lo que ocurra primero. Case se define como:

MT-16-2

y Action como:

MT-16-3

Una cl谩usula de Case se activar谩 s贸lo si se produce la Action correspondiente, y continuar谩 como Contract. En caso de coincidencia de dos Actions , se ejecutar谩 la primera de la lista.

Se admiten tres tipos de acciones:

  • Deposit representa un dep贸sito de dinero en una cuenta; originalmente se llamaba Commit.
  • Choice representa una elecci贸n realizada por un participante dentro de un conjunto de valores Integer (especificados por la lista de Bounds).
  • Notify esperar谩 a que se emita una acci贸n Notify cuando la Observation sea verdadera. Lo llamamos Notify para dejar claro que no podemos esperar simplemente a las Observations, sino que alguien debe activar el contrato en un momento en el que una Observation sea verdadera.

Hemos descartado a帽adir observaciones a Deposit y Choice ya que no ser铆a obvio si la Observation ser铆a evaluada antes o despu茅s de aplicar la acci贸n.

Adem谩s de los casos expl铆citos en When, debemos recordar que la rama timeout tambi茅n es un caso, y tambi茅n necesita ser activada (de forma similar a Notify). [3] [4]

Observations y Values

Hemos descartado Observations y Values que pueden ser expresados combinando otros: como el general AvailableMoney (para todo el contrato), o como DepositedMoneyBy, que recuerda la cantidad de dinero depositada por un participante, ya que el contrato puede ser reestructurado para observar eso, y apoyarlo requerir铆a informaci贸n adicional en el estado (simplicidad).

Hemos mantenido la observaci贸n ChoseSomething a pesar de que, en la sem谩ntica propuesta, cada ocurrencia de ChoseSomething puede ser evaluada est谩tica y eficientemente examinando su contexto.

Por ejemplo, en el siguiente contrato podemos ver que la primera ocurrencia de ChoseSomething se evaluar谩 como True, y la segunda como False:

MT-16-4

Sin embargo, hemos optado por mantener la construcci贸n por dos razones:

  • Permite la reutilizaci贸n del c贸digo (comodidad). Por ejemplo, en el contrato anterior, podr铆amos definir chosen1:

MT-16-5

Pero esto no ser铆a posible si no tuvi茅ramos la construcci贸n ChoseSomething, ya que el valor al que se reduce depende del contexto.

  • Puede que ya no sea posible evaluar est谩ticamente las ocurrencias de la construcci贸n si ampliamos la construcci贸n When para que admita entradas 鈥渕uchas de muchas鈥.

Inclusi贸n de SlotIntervals

La especificaci贸n EUTxO proporciona scripts de validaci贸n con intervalos de slots en lugar de con n煤meros de slots. Esto es para promover el determinismo en los scripts de validaci贸n. Sin embargo, hemos mantenido el timeout de When (el 煤nico timeout) como un n煤mero de slot. La forma en que tratamos los intervalos de slot es requiriendo que el intervalo de una transacci贸n no incluya ning煤n timeout sobre el que la sem谩ntica tenga que hacer una elecci贸n. Por ejemplo: si el timeout es 10, una transacci贸n con el intervalo 5-15 fallar谩 con AmbiguousSlotInterval. Los participantes tendr铆an que emitir una transacci贸n con el intervalo 5-9 o 10-15 (o ambos).

Sin embargo, para los Values, proporcionamos las dos construcciones SlotIntervalStart y SlotIntervalEnd. Una alternativa a considerar ser铆a modificar la sem谩ntica para que los Valores sean no deterministas, de esta manera podr铆amos incluir una construcci贸n CurrentSlot y s贸lo invalidar las transacciones que sean ambiguas, pero esto complicar铆a la sem谩ntica y la har铆a menos predecible.

[1]

Potencialmente podemos proporcionar una forma de analizar est谩ticamente el contrato para comprobar si es posible que quede dinero en alguna cuenta cuando se alcance el Close .

[2]

Esto significa que los pagos ahora obedecen a un modelo 鈥減ush鈥 en lugar de un modelo 鈥減ull鈥.

[3]

No obstante, la activaci贸n del contrato para el tratamiento de los timeouts no es urgente como en el caso de Notify, ya que mientras que las Observations pueden alternar entre True y False, los timeouts s贸lo pueden ocurrir una vez e, independientemente de que hayan sido observados por el contrato o no, no pueden ser revertidos.

[4]

De hecho, ya no se puede emitir un Case expl铆cito despu茅s del timeout, incluso si el timeout no ha sido observado por el contrato, ya que el timeout se comprueba antes que los Inputs. Sin embargo, un participante puede querer desencadenar un timeout en casos en los que no se necesitan otros Inputs , para desencadenar uno o m谩s pagos, por ejemplo. En la implementaci贸n actual de la sem谩ntica eso se har铆a emitiendo una transacci贸n con una lista vac铆a de Inputs.

漏 Copyright 2020, IOHK Revision 74cb849b.

Encuentra una copia oficial de este documento aqu铆:

https://alpha.marlowe.iohkdev.io/doc/marlowe/tutorials/migrating.html

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

M谩s traducciones de Cardano en: Cardano For The World