Información sobre qué caracteriza a Marlowe como plataforma segura de desarrollo de smart contracts
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:
- Auditoría de contratos inteligentes
- Ataques basados en contratos inteligentes
- Auditoría de Tweag
- Límites funcionales de mejora de la seguridad incorporados en Marlowe
- Validación de transacciones
- 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 --showcontract 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.
u omisión de este, indica que el enlace apunta a un contenido en idioma inglés.
indica que el enlace apunta a un contenido en idioma español.