ūüá™ūüáł Una completa gu√≠a sobre la seguridad en Marlowe: resultados de auditor√≠a, restricciones funcionales incorporadas y caracter√≠sticas de seguridad del ledger

Información sobre qué caracteriza a Marlowe como plataforma segura de desarrollo de smart contracts

25550635723a49ba122ea8c5b3bab9f32d9c68e7

Descargo de responsabilidad: La informaci√≥n contenida en este art√≠culo de Seguridad sobre Marlowe se ofrece ‚ÄúTAL CUAL‚ÄĚ, sin garant√≠as alguna. El contenido de este documento no pretende ser asesoramiento profesional, incluyendo sin limitaci√≥n, asesoramiento financiero, de inversi√≥n, legal o fiscal. Input Output Global no se hace responsable del uso que usted haga de la informaci√≥n contenida en este documento ni de la confianza que deposite en ella.

Introducción

Un smart contract es, en la mayor√≠a de las blockchain, un programa inform√°tico que se autoejecuta una vez que se cumplen ciertas condiciones predefinidas. Sin embargo, en Cardano es un tanto diferente, ya que la ejecuci√≥n del smart contract se produce en una transacci√≥n enviada externamente al nodo de Cardano. No obstante, independientemente de c√≥mo funcione bajo el cap√≥, los smart contract son √ļtiles para muchas industrias: financiera, inmobiliaria, comercial y muchas otras.

Realizar transacciones mediante smart contracts puede implicar el movimiento y la transferencia de un valor sustancial, que puede ser un objetivo preciado para los malos actores. Igualmente, este valor puede quedar bloqueado, o perderse por completo, debido a fallos o vulnerabilidades en la codificación.

Eludir cualquier resultado indeseado requiere la aplicaci√≥n de un marco de seguridad s√≥lido, lo que supone una combinaci√≥n de principios de dise√Īo, auditor√≠as y buenas pr√°cticas por parte de desarrolladores, Exchange y cualquier otra parte que maneje smart contracts.

A√Īadi√©ndose a una gama cada vez mayor de recursos de toda la comunidad t√©cnica de Cardano, Marlowe es un ecosistema de herramientas y lenguajes creado por Input Output Global (IOG) para permitir el desarrollo de smart contracts financieros y transaccionales en la blockchain de Cardano.

La suite Marlowe ha sido dise√Īada y desarrollada con un enfoque centrado en la seguridad. Sus creadores han incorporado limitaciones funcionales que garantizan, por ejemplo, que los contratos sean finitos y terminen siempre. Adem√°s, Marlowe evita ciertas construcciones de programaci√≥n para prevenir resultados no deseados, por ejemplo, la recursividad y los bucles. Antes del despliegue de Marlowe en mainnet, un organismo intermediario, Tweag, llev√≥ a cabo una auditor√≠a est√°tica y din√°mica. Como resultado de todas estas caracter√≠sticas de seguridad, y de muchas otras, se obtiene una plataforma de creaci√≥n y desarrollo de smart contracts segura y protegida.

El presente artículo profundiza en la seguridad de Marlowe, explicando las conclusiones de la auditoría de seguridad y cómo respondió el equipo a ellas, las limitaciones funcionales incorporadas, las herramientas de análisis de seguridad incluidas en el despliegue y algunas precauciones y consideraciones que deben tenerse en cuenta al utilizar Marlowe.

√ćndice

El presente documento se divide en seis secciones claramente definidas:

  1. Auditoría de contratos inteligentes
  2. Ataques basados en contratos inteligentes
  3. Auditoría de Tweag
  4. Límites funcionales de mejora de la seguridad incorporados en Marlowe
  5. Validación de transacciones
  6. Políticas monetarias

Este documento, de forma general, se propone ofrecer una comprensión exhaustiva de la importancia de la auditoría de smart contracts y de los distintos tipos de ataques basados en smart contracts existentes en la actualidad, antes de profundizar específicamente en cómo el conjunto de herramientas Marlowe utiliza la auditoría y unos sólidos principios de seguridad para mantener un entorno de desarrollo de smart contracts seguro y protegido.

Auditoría de un smart contract

Descripción general

La autonom√≠a inherente de los smart contracts y lo mucho que est√° en juego en determinadas transacciones hacen que garantizar la coherencia y la seguridad sea primordial. Para ello es necesario saber exactamente c√≥mo se comportar√° un smart contract cuando se ejecute, de modo que se pueda detectar y abordar cualquier posible fallo o c√≥digo malicioso intencionado. Auditar los smart contracts desde el punto de vista de la seguridad es la mejor manera de prevenir fallos o da√Īos posteriores. Mediante una auditor√≠a se examina a fondo el c√≥digo y las condiciones del smart contract antes de su despliegue, para garantizar que el contrato se comporta como se espera.

Metodologías de una auditoría

Aunque los métodos de auditoría de contratos inteligentes pueden diferir y variar de un proyecto a otro, los smart contracts pueden analizarse utilizando métodos manuales o automatizados. Habitualmente, la mayoría de los proyectos emplean una combinación de ambos.

Copilación de documentación

Los auditores, antes de comenzar el proceso de auditor√≠a, pueden dedicar alg√ļn tiempo a recopilar toda la documentaci√≥n relacionada con el proyecto. Puede tratarse de documentos t√©cnicos, libros blancos, base de c√≥digo y cualquier otro material que pueda ser relevante y √ļtil en el proceso de auditor√≠a.

Auditoría manual

Esta modalidad de auditor√≠a de smart contract implica que un grupo de personas analice cada l√≠nea de c√≥digo, la l√≥gica del contrato, la arquitectura del contrato y cualquier medida de seguridad incorporada para garantizar un dise√Īo eficiente y correcto. Adem√°s de descubrir errores de codificaci√≥n, una auditor√≠a manual tambi√©n puede descubrir fallos de dise√Īo. La auditor√≠a manual suele considerarse un m√©todo muy exhaustivo y preciso.

Auditoría automatizada

Al contrario que la auditoría manual, la auditoría automatizada adopta normalmente un enfoque de las pruebas centrado en el software. Puede que las herramientas de auditoría de software propietarias o disponibles en el mercado ayuden a detectar fallos, pero puede que ciertas vulnerabilidades no se hagan evidentes.

A causa de la naturaleza complementaria de estos métodos, las mejores prácticas de auditoría implican una combinación de auditoría manual y automatizada para garantizar que se detectan y corrigen todos los fallos, errores y vulnerabilidades potenciales.

Medidas posteriores a la auditoría

Tras finalizar el proceso de auditoría, el auditor o auditores elaborarán un informe en el que se detallarán sus conclusiones. En él se puede incluir una clasificación de los errores por gravedad y una serie de recomendaciones.

Es posible clasificar los errores contractuales como

  • Cr√≠ticos: es probable que este tipo de fallo impida el funcionamiento seguro de un contrato y/o protocolo.
  • Mayor: ciertos errores de codificaci√≥n o de l√≥gica pueden provocar la p√©rdida de fondos o un estado incontrolado del protocolo.
  • Medio: aunque los fondos no corran peligro, este tipo de errores puede afectar al funcionamiento o la fiabilidad del contrato.
  • Menor: esta clasificaci√≥n suele incluir c√≥digo ineficiente con poco o ning√ļn impacto en la seguridad. Informativos: suelen referirse a cuestiones de estilo de codificaci√≥n o mejores pr√°cticas.

Ventajas de la auditoría de smart contracts

Aunque la auditoría es importante para cualquier aplicación, es especialmente crucial para los smart contract y las aplicaciones descentralizadas (DApps) que se ejecutan en blockchain debido a la naturaleza inmutable de estos ledgers descentralizados.

Entre las ventajas de la auditoría de smart contract se incluyen la identificación proactiva de riesgos, la evitación de errores potencialmente costosos, un mejor entorno de desarrollo en general y la obtención de información sobre vulnerabilidades y cómo eliminarlas.

Detección proactiva de los riesgos

El despliegue de smart contracts no auditados es una apuesta que ning√ļn desarrollador o empresa deber√≠a hacer. Es posible que algunos smart contracts impliquen fondos sustanciales que, si se pierden o se ven comprometidos, pueden dar lugar a responsabilidades a√ļn mayores. Al trabajar de forma proactiva para remediar estos riesgos, la posibilidad de que algo salga mal disminuye considerablemente.

Evitando errores potencialmente costosos.

Que los fondos queden bloqueados para siempre debido a errores de codificaci√≥n/l√≥gica o como resultado de una interferencia maliciosa en un contrato es algo que ning√ļn cliente o desarrollador quiere experimentar jam√°s. Los da√Īos financieros son solo una cara de la moneda. Puede haber tambi√©n serias ramificaciones legales.

Un entorno de desarrollo mejor en general

Realizar auditorías de software no es solo recomendable, es un requisito. Garantizar la seguridad de una aplicación o un conjunto de aplicaciones y seguir las mejores prácticas refuerza la oferta y crea un entorno de desarrollo más saludable.

Descubrir las vulnerabilidades y cómo eliminarlas.

Al desarrollar software, es mejor prevenir que parchear [corregir errores]. Y cuando se trata de smart contracts, no hay posibilidad de parchear debido a la naturaleza inmutable de blockchain. Una exhaustiva auditoría arrojará mucha información sobre el código, la lógica del contrato, la arquitectura y muchos otros parámetros, lo que permitirá a los desarrolladores perfeccionar y producir el mejor contrato posible.

Ataques basados en smart contract

Ataques de reentrada

Estos ataques consisten en que una función de un smart contract cede temporalmente el control de una transacción haciendo una llamada a un segundo contrato, el cual comienza a hacer llamadas recursivas de retirada al primer contrato, drenando sus fondos antes de que el primer contrato actualice su estado. Esta clase de ataques son posibles debido a fallos en la codificación de los smart contract. El evento DAO de 2016 implicó un ataque de reentrada.

El dise√Īo de la blockchain de Cardano hace que los ataques de reentrada sean imposibles. Puesto que Cardano utiliza el modelo EUTXO, los smart contract son at√≥micos y no se hacen llamadas entre s√≠, lo que hace imposible la reentrada.

Invasiones frontales

Los dise√Īos de algunas blockchain permiten que los smart contract y las transacciones sean visibles p√ļblicamente durante un tiempo, antes de ser confirmados en la cadena. Estas transacciones pendientes se comparten a trav√©s de mempools en toda la red, lo que permite a un adversario ver el resultado previsto de un contrato. As√≠, un adversario con visibilidad de las transacciones pendientes puede introducir una nueva operaci√≥n o transacci√≥n con el conocimiento de que al hacerlo obtendr√° un beneficio basado en la operaci√≥n pendiente, a expensas de los beneficios de otros usuarios. B√°sicamente, un adversario manipula el orden de ejecuci√≥n de las transacciones en su propio beneficio.

Aunque este tipo de sucesos es un gran problema en otras blockchains, no hay pruebas de que Cardano (y por extensión, Marlowe) sea vulnerable a las invasiones front-running.

Manipulación de oráculos

A través de los oráculos se conectan las blockchains a sistemas externos, y los smart contract podrían ejecutarse basándose en los datos recibidos de los oráculos. Esta dependiencia de sistemas externos significa que si la entrada recibida por el oráculo ha sido manipulada antes de ser alimentada al oráculo, la seguridad e integridad de la ejecución del smart contract podría verse comprometida.

Entre otras vulnerabilidades de seguridad comunes basadas en los smart contract se incluyen los errores aritméticos, el desbordamiento y subdesbordamiento de enteros, los ajustes de visibilidad de los smart contract y la manipulación de marcas de tiempo.

La auditoría de Tweag

En esta secci√≥n nos ocuparemos de los resultados de la auditor√≠a de seguridad de Tweag, la respuesta del equipo de Marlowe y los principios de seguridad incorporados en el dise√Īo de Marlowe.

Los principales resultados de la auditoría de seguridad de Tweag y las respuestas internas

Tweag llevó a cabo una auditoría manual y otra automatizada del lenguaje Marlowe, que revelaron varios problemas.

Las conclusiones de mayor gravedad inclu√≠an la gesti√≥n de dep√≥sitos negativos, la prevenci√≥n de ‚Äėdoble satisfacci√≥n‚Äô, la aplicaci√≥n de invariantes de estado, una diferencia de implementaci√≥n entre la especificaci√≥n formal frente a la implementaci√≥n de Plutus, y la prueba del teorema de conservaci√≥n del dinero.

Tratamiento de los depósitos negativos

Para calcular los ingresos por depósitos se suman los ingresos por depósitos, independientemente de que sean negativos, mientras que la semántica los considera como depósitos cero. En combinación con la ausencia de una comprobación de saldo en el estado final de Marlowe, esto permite que el saldo final difiera del valor pagado al validador de Marlowe. Ello puede ser explotado por un contrato Marlowe que permita depósitos negativos.

Solución interna

Se ha resuelto este problema a√Īadiendo una guardia contra dep√≥sitos negativos en el validador sem√°ntico de Marlowe. Esa protecci√≥n garantiza que la sem√°ntica del validador para los dep√≥sitos negativos coincide con la sem√°ntica Isabelle de Marlowe. Concretamente, un dep√≥sito de una cantidad negativa se trata como un dep√≥sito de cero. Por lo tanto, un dep√≥sito negativo no disminuir√° ninguno de los saldos de la cuenta en el dato Plutus, y el total de los saldos internos coincidir√° con el valor mantenido en el UTXO a la direcci√≥n de las secuencias de comandos de la sem√°ntica de Marlowe.

Prevención de la doble satisfacción

Si bien el validador de Marlowe impedía la doble satisfacción entre varias copias de la secuencia de comandos del validador de Marlowe que se ejecutaban en la misma transacción, no la impedía en los casos en los que el validador de Marlowe se ejecutaba junto con otro validador de Plutus en la misma transacción.

Respuesta interna

Ahora es evitada la doble satisfacci√≥n obligando a que el validador Marlowe sea la √ļnica secuencia de comandos Plutus que se ejecute durante las transacciones que realizan pagos a las partes. De esta forma, los contratos de Marlowe pueden coordinarse con otras secuencias de comandos de Plutus, pero solo en condiciones en las que la doble satisfacci√≥n sea imposible. Para comprobar la correcci√≥n de esta mitigaci√≥n se han a√Īadido algunas pruebas basadas en propiedades.

Aplicación de invariantes de estado

Originalmente, el validador de Marlowe había hecho suposiciones optimistas sobre su propio funcionamiento correcto y no comprobaba ciertas invariantes con el fin de reducir los costes de ejecución de Plutus.

Respuesta interna

Ahora el validador semántico de Marlowe aplica rigurosamente los invariantes para los estados inicial y final, garantizando que los tres invariantes de estado de cuentas positivas, no duplicación de entradas de estado (cuentas, elecciones y valores vinculados) y un valor interno total coinciden con el valor de UTXO de las secuencias de comandos.

Diferencia de implementación entre la especificación formal y la implementación de Plutus

La auditoría reveló algunas diferencias entre la especificación formal y la implementación real de Plutus. Específicamente, diferencias de lenguaje y consideraciones de eficiencia con respecto a Isabelle, Haskell, y Plutus Tx.

La especificación formal está escrita en Isabelle, un lenguaje para métodos formales, mientras que la implementación real de Marlowe está escrita en Haskell y Plutus Tx. El equipo de Marlowe trabajó para seguir la especificación Isabelle lo más fielmente posible, pero algunas desviaciones fueron inevitables debido a los diferentes lenguajes. Por ejemplo, algunos aspectos de la implementación de Marlowe serían ineficientes en Isabelle, por lo que fue necesario realizar cambios para conseguir una implementación de Haskell más eficiente.

Respuesta interna

Este problema se mitigó mediante análisis de código y pruebas basadas en propiedades

Prueba del teorema de conservación del dinero

El teorema de conservación del dinero solo tenía en cuenta la cantidad de bienes, pero no su tipo. Significando que la prueba no consideraría un caso en el que un contrato pudiera, por ejemplo, recibir 20 ada y 15 Djed y devolver 20 Djed y 15 ada.

Respuesta interna

Mediante una revisión del código Isabelle se puso remedio a este problema. En concreto, la adición de un nuevo tipo MultiAssets y la refactorización del código Isabelle (sin modificar el intérprete) para demostrar que los activos se conservan.

Limitaciones funcionales incorporadas en Marlowe para mejorar la seguridad

Marlowe incorpora varias limitaciones para garantizar que no puedan producirse ciertos riesgos de seguridad.

  • Los contratos son finitos
  • Los contratos terminar√°n
  • Los contratos tienen una duraci√≥n definida
  • No se conservan activos cuando finaliza el contrato
  • El valor se conserva

Además de estas limitaciones, algunas construcciones del lenguaje de programación están ausentes de Marlowe para garantizar la seguridad:

  • No se permite la recursi√≥n
  • No se admiten bucles
  • No se pueden definir funciones o macros
  • Los tiempos de espera deben ser constantes num√©ricas
  • Solo se pueden merkleizar las continuaciones Case. El lenguaje de programaci√≥n Faustus relaja algunas de las limitaciones anteriores, no obstante compila para asegurar Marlowe.

Herramientas de an√°lisis de seguridad

La herramienta de an√°lisis marlowe-cli run analyze dise√Īada por el equipo de Marlowe comprueba la compatibilidad de un contrato Marlowe con las reglas del ledger [libro contable] Cardano.

El ledger Cardano tiene restricciones incorporadas que podr√≠an impedir que un contrato Marlowe se ejecutara en la cadena, incluso si el propio contrato fuera v√°lido con respecto al lenguaje Marlowe. As√≠, por ejemplo, el ledger impone restricciones a la longitud de los nombres de roles y tokens, y tambi√©n limita los costes de ejecuci√≥n de Plutus. Todo contrato que infrinja alguna de estas normas no se ejecutar√≠a en la cadena, aunque el contrato pudiera estar correctamente construido. Igualmente, aunque los contratos puedan ejecutarse en el Playground, no se ejecutar√≠an en la cadena si el contrato viola las restricciones del ledger. M√°s informaci√≥n sobre restricciones de dise√Īo del ledger incorporado.

Lo más importante: mientras que el Playground trata sobre el lenguaje, el Runtime trata sobre la implementación del contrato Marlowe en la blockchain de Cardano específicamente. Si alguien implementa Marlowe en otra blockchain, podrá seguir utilizando el Playground, pero no podrá utilizar Runtime en otra blockchain.

Nota: se puede bloquear un contrato si el dato no encaja en la cadena, pero el conjunto Marlowe incluye herramientas para evaluar este riesgo. Estas herramientas deben utilizarse antes de desplegar un contrato.

Validación de transacciones

En la validación del gasto UTXO intervienen dos tipos de secuencias de comandos del validador Plutus:

  • Validador de sem√°ntica
  • Validador de pago

Las pr√°cticas de seguridad dictan que las transacciones no deben firmarse a menos que el contenido y las implicaciones de la transacci√≥n hayan sido revisados y se comprendan bien. En el entorno Marlowe, esto significa verificar el contrato Marlowe, su entrada y su estado. Tambi√©n significa asegurarse de que la pol√≠tica de acu√Īaci√≥n de roles (si existe) y el validador de Marlowe utilizados son los correctos.

Las consideraciones de seguridad que se exponen a continuación se aplican a ambos tipos de secuencias de comandos del validador.

Sem√°ntica del validador

Los siguientes conceptos deben entenderse bien antes de firmar una transacción Marlowe:

  • ¬ŅOpera la transacci√≥n un contrato Marlowe?
  • ¬ŅCu√°l es su pol√≠tica de acu√Īaci√≥n de roles (si existe)?
  • ¬ŅC√≥mo se han distribuido los tokens de rol (si los hay)?
  • ¬ŅCu√°l es el contrato actual y su estado?
  • ¬ŅQu√© entrada se est√° aplicando al contrato?
  • ¬ŅQu√© m√°s est√° ocurriendo en la transacci√≥n?

¬ŅManeja un contrato Marlowe la transacci√≥n?

Las secuencias de comandos [scripts] del validador Plutus son intérpretes universales para todos los contratos Marlowe de una versión especificada, lo que significa que el UTXO de un contrato Marlowe reside en un hash de secuencia de comandos. Al comprobar que una transacción se gasta desde una dirección que tiene el hash de las secuencias de comandos Marlowe como parte de pago, se confirma que el validador Marlowe verdadero se ejecutará para validar el gasto de ese UTXO específico. Se puede calcular el hash de script del validador Marlowe desde los primeros principios compilando el validador y calculando su hash, suponiendo que se puede confiar en el código fuente de las secuencias de comandos Marlowe de este repositorio.

¬ŅCu√°l es su pol√≠tica de acu√Īaci√≥n de funciones (si la hay)?

La pol√≠tica de acu√Īaci√≥n es el conjunto de reglas para la creaci√≥n de tokens de un tipo de token determinado, que se identifica por el hash de su pol√≠tica de acu√Īaci√≥n. Esto se conoce como ID de la pol√≠tica de acu√Īaci√≥n. Una pol√≠tica de acu√Īaci√≥n determina si se pueden crear nuevos tokens, o si los tokens que se han creado son todo lo que habr√°.

Por ejemplo, las partes de un contrato Marlowe, como prestamista y prestatario, pueden representarse de dos maneras:

  • Mediante una direcci√≥n: cada parte del tipo direcci√≥n corresponde a una instancia de un par de una clave p√ļblica y una privada que presumiblemente est√° en posesi√≥n de una Las wallets de una de las partes. Utilizar direcciones para representar a las partes es m√°s sencillo y barato que utilizar roles. Para autenticarse, las partes representadas por una direcci√≥n s√≥lo tienen que firmar las transacciones que requieren su autenticaci√≥n (es decir, las que ejecutan dep√≥sitos o elecciones para la parte).
  • Mediante un token de rol: cada parte del tipo rol corresponde a un token almacenado en la cadena. Para que un contrato utilice tokens de rol como autenticaci√≥n, el contrato necesita declarar que su ID de pol√≠tica de acu√Īaci√≥n de tokens de rol es el ID de pol√≠tica de acu√Īaci√≥n del token que quiere utilizar como token de rol. En este caso, cada uno de los nombres de activos del token identificado por el ID de pol√≠tica de acu√Īaci√≥n representa a una parte diferente. Para autenticar una transacci√≥n, el propietario de un token de funci√≥n s√≥lo tiene que incluirlo como parte de la transacci√≥n que requiere la autenticaci√≥n del propietario del token de funci√≥n. Potencialmente puede haber m√°s de un token con el mismo nombre de activo, por lo que t√©cnicamente no se es propietario de una parte de rol a menos que se posean todas las instancias del token de rol que tiene el nombre de activo de la parte.

¬ŅC√≥mo se han distribuido los tokens de rol?

Si el contrato solo utiliza direcciones para representar a las partes, las pol√≠ticas de acu√Īaci√≥n de fichas de rol no son una preocupaci√≥n. La desventaja de las direcciones es que no pueden transferirse de forma demostrable, por lo que una vez que se conoce la clave privada de una direcci√≥n, no se puede demostrar que se ha olvidado y borrado. Desde la perspectiva del destinatario de una direcci√≥n, √©sta siempre es insegura. La √ļnica manera de tener una direcci√≥n segura es generarla usted mismo.

Su ventaja o su papel es que, dado que los tokens se tratan como activos nativos en la cadena, pueden transferirse igual que los ada o cualquier otro activo. Pero cualquiera que posea un token con el ID de pol√≠tica de acu√Īaci√≥n y el nombre de activo adecuados puede actuar como la parte a la que representa, por lo que debe asegurarse de que usted es el √ļnico que posee un token de este tipo, o de lo contrario no tendr√° realmente el control de la parte.

Evidentemente, puede asegurarse de que es el √ļnico propietario de ese token acu√Īando usted mismo los tokens de rol (Marlowe Runtime lo hace de forma segura como parte del proceso de creaci√≥n del contrato). Si otra persona acu√Ī√≥ los tokens de rol o cre√≥ el contrato, deber√° asegurarse de que

  • Usted tiene todos los tokens existentes que controlan el partido.
  • No se pueden crear m√°s tokens de este tipo (porque la pol√≠tica de acu√Īaci√≥n no lo permite)

Si la pol√≠tica de acu√Īaci√≥n es lo suficientemente sencilla, la forma m√°s f√°cil de comprobarlo es utilizar un explorador Marlowe para averiguar el ID de la pol√≠tica de acu√Īaci√≥n del papel del contrato. A continuaci√≥n, utilice un explorador de Cardano para comprobar cu√°l es la pol√≠tica que hay detr√°s de la pol√≠tica de acu√Īaci√≥n (para garantizar que no se pueden producir m√°s roles) y para comprobar la distribuci√≥n actual de los roles existentes ya acu√Īados (qui√©n tiene qu√© tokens, en otras palabras).

¬ŅCu√°l es el contrato actual y su estado?

El estado previo a la transacción del contrato se define en el dato Plutus asociado al UTXO que se está gastando desde la dirección de las secuencias de Marlowe. Dicho datum debe ofrecerse en la transacción y debe contener lo siguiente:

  • los saldos de las cuentas internas del contrato
  • el historial de las elecciones realizadas hasta ese momento en la ejecuci√≥n del contrato
  • los valores actuales de las variables vinculadas del contrato
  • la parte del contrato que queda por ejecutar

El dato puede extraerse del cuerpo de la transacción sin firmar y deserializarse a Language.Marlowe.Core.V1.Semantics.MarloweData utilizando la función Plutus.V2.Ledger.Api.fromData.

Alternativamente:

  • la herramienta de l√≠nea de comandos marlowe log --show contract mostrar√° el historial en cadena del contrato.
  • Esta herramienta en l√≠nea tambi√©n permite ver los contratos y el estado en la cadena.
  • Una API REST ofrece la misma informaci√≥n obtenida mediante marlowe log --show.

¬ŅQu√© entrada se est√° aplicando al contrato?

La entidad de canje de Plutus asociada al gasto del UTXO desde la dirección de las secuencias de comandos de Marlowe define la entrada que se está aplicando al contrato, junto con el intervalo de validez de la ranura para la transacción especificado en el cuerpo de la transacción. La entrada es una secuencia de cero o más depósitos, elecciones y notificaciones. Utilizando herramientas como Marlowe Playground o marlowe-cli run prepare, es posible analizar las consecuencias de aplicar esta entrada al contrato.

El canjeador puede extraerse del cuerpo de la transacción sin firmar y deserializarse a Language.Marlowe.Scripts.MarloweInput utilizando la función Plutus.V2.Ledger.Api.fromData. La herramienta de línea de comandos marlowe-cli util slotting calculará la relación entre las franjas horarias mencionadas en el intervalo de validez con los tiempos POSIX del contrato.

¬ŅQu√© m√°s ocurre en la transacci√≥n?

La transacción sin firmar puede contener otros gastos y pagos además de los especificados para el contrato Marlowe. Esto puede examinarse con la herramienta cardano-cli transaction view.

Políticas monetarias

Normalmente, deben utilizarse pol√≠ticas monetarias (como las soportadas en Marlowe Runtime) que impongan un √ļnico evento de acu√Īaci√≥n y tokens √ļnicos para cada rol. Estas pol√≠ticas garantizan que los tokens de rol son verdaderos tokens no fungibles (NFT), por lo que los poseedores de tokens de rol son verificablemente los √ļnicos que pueden actuar como partes en el contrato.

Las pol√≠ticas monetarias que acu√Īan m√ļltiples copias de un token de rol concreto, o las pol√≠ticas con una pol√≠tica de acu√Īaci√≥n abierta, admiten casos de uso no est√°ndar. Por ejemplo, acu√Īar dos copias de cada token de funci√≥n y distribuirlas a la misma parte permite a esa parte colocar un token en almacenamiento en fr√≠o como copia de seguridad si el wallets que contiene el token de funci√≥n ‚Äúcaliente‚ÄĚ se vuelve inaccesible. Algunos contratos de crowdsourcing novedosos podr√≠an implicar la asignaci√≥n del rol (a trav√©s de tokens de rol id√©nticos que pueden acu√Īarse incluso despu√©s de que comience el contrato) a muchos participantes. Por √ļltimo, la pol√≠tica de acu√Īaci√≥n de tokens de rol de un contrato Plutus puede coordinarse con el funcionamiento de uno o varios contratos Marlowe.

Tokens de rol

Los tokens de rol pueden autorizar dep√≥sitos y elecciones en transacciones Marlowe. Autorizar el uso de un token de rol es m√°s flexible que autorizar con una clave p√ļblica, porque un token de rol (y por tanto la participaci√≥n en un contrato Marlowe) puede transferirse entre wallets o a otra persona.

Las secuencias de comandos del validador de Marlowe no imponen ninguna política monetaria particular para los tokens de función, para permitir casos de uso novedosos. No obstante, la seguridad de las autorizaciones en un contrato Marlowe basado en roles sí depende críticamente de la política monetaria de los tokens de rol. Esto significa que tanto la política monetaria como el desembolso en cadena de los tokens deben examinarse cuidadosamente antes de participar en un contrato Marlowe. Verificar la política monetaria de una simple secuencia de comandos implica recuperar la secuencia de comandos de la blockchain y estudiarla. Verificar la política monetaria de una secuencia de comandos de Plutus implica obtener y estudiar el código fuente de Plutus de la secuencia de comandos y realizar un hash del código fuente para comprobar el ID de la política monetaria.

Un reconocimiento: Joseph Fajen, Brian Bush y Omer Husain han realizado contribuciones inestimables a este artículo.

Traducci√≥n al espa√Īol de ‚ÄúA comprehensive guide to Marlowe‚Äôs security: audit outcomes, built-in functional restrictions, and ledger security features‚ÄĚ, escrito por Fernando Sanchez, Escritor T√©cnico Principal en IOG, el 26 de junio de 2023.


Notas del traductor

  • Corchetes del traductor.
  • :uk: u omisi√≥n de este, indica que el enlace apunta a un contenido en idioma ingl√©s.
  • :es: indica que el enlace apunta a un contenido en idioma espa√Īol.

Considere suscribirse a las siguientes fuentes de informaci√≥n en espa√Īol de Cardano seg√ļn su inter√©s.

  • [Twitter] :es:Cardanians Hispanos
    Seguimiento y traducci√≥n al espa√Īol de los tweets oficiales de la Fundaci√≥n Cardano, EMURGO, IOG, Yoroi y Comunidad Cardano y m√°s.

  • [Telegram] :es:Anuncios de Cardano en Espa√Īol
    Anuncios oficiales traducidos al espa√Īol, de Cardano, EMURGO y Yoroi.

  • [YouTube] :es:Cardano en Castellano
    Videos oficiales de Cardano doblados al espa√Īol.

  • [Medium] :es:El Blog de LiberLion
    Art√≠culos de Cardano en ingl√©s y espa√Īol.