Traduzione italiana di “A comprehensive guide to Marlowe security”
Traduzione italiana a cura di Lordwotton di RIOT Stake Pools. Se apprezzi queste traduzioni, per favore valuta di supportare il mio lavoro delegando i tuoi ada a RIOT 
entra nel nostro gruppo Telegram
Una guida completa alla sicurezza di Marlowe: risultati dell’audit, restrizioni funzionali incorporate e caratteristiche di sicurezza del ledger
Scoprite cosa rende Marlowe una piattaforma sicura per lo sviluppo di contratti intelligenti.
Disclaimer: Il contenuto di questo articolo di Marlowe Security è fornito “COSÌ COM’È” senza garanzie di alcun tipo. Nulla di quanto contenuto nel presente documento è da intendersi come consulenza professionale, inclusi, senza limitazioni, consigli finanziari, di investimento, legali o fiscali. Input Output Global non è responsabile per l’uso o l’affidamento dell’utente sulle informazioni contenute in questo documento.
Introduzione
Nella maggior parte delle blockchain, uno smart contract è un programma informatico che si auto-esegue una volta soddisfatte determinate condizioni predefinite. In Cardano è un po’ diverso, poiché l’esecuzione del contratto smart avviene in una transazione presentata esternamente al nodo Cardano. Ma a prescindere dal suo funzionamento, i contratti intelligenti sono utili per molti settori: finanziario, immobiliare, commerciale e molti altri.
Le transazioni che utilizzano i contratti intelligenti possono comportare il movimento e il trasferimento di un valore sostanziale, che può essere un obiettivo privilegiato per i malintenzionati. Allo stesso modo, questo valore può essere bloccato o perso del tutto a causa di difetti o vulnerabilità nella codifica.
Per evitare qualsiasi esito indesiderato è necessario implementare un solido quadro di sicurezza, che prevede una combinazione di principi di progettazione, verifiche e best practice da parte di sviluppatori, exchange e qualsiasi altra parte che gestisce gli smart contract.
Aggiungendosi a una gamma sempre crescente di risorse provenienti dalla comunità tecnica di Cardano, Marlowe è un ecosistema di strumenti e linguaggi creato da Input Output Global (IOG) per consentire lo sviluppo di smart contract finanziari e transazionali sulla blockchain di Cardano.
La suite Marlowe è stata progettata e sviluppata con un’attenzione particolare alla sicurezza. I creatori di Marlowe hanno inserito limitazioni funzionali che garantiscono, ad esempio, che i contratti siano finiti e terminino sempre. Marlowe evita anche alcuni costrutti di programmazione per prevenire risultati indesiderati, come la ricorsione e il looping. Una terza parte, Tweag, ha condotto un audit statico e dinamico prima della distribuzione di Marlowe sulla mainnet. Il risultato di tutte queste caratteristiche di sicurezza, e di molte altre, è una piattaforma di creazione e sviluppo di contratti smart sicura e protetta.
Questo articolo approfondisce la sicurezza di Marlowe, spiegando i risultati dell’audit di sicurezza e come il team ha risposto ad essi, le limitazioni funzionali integrate, gli strumenti di analisi della sicurezza inclusi nella distribuzione e alcune precauzioni e considerazioni da prendere quando si utilizza Marlowe.
Struttura del documento
Questo documento è suddiviso in sei sezioni chiaramente definite:
- Audit dei contratti intelligenti
- Attacchi basati su contratti smart
- Audit di Tweag
- Limitazioni funzionali di sicurezza incorporate in Marlowe
- Convalida delle transazioni
- Politiche monetarie
Nel complesso, questo documento intende fornire una comprensione completa dell’importanza dell’auditing degli smart contract e dei diversi tipi di attacchi basati sugli smart contract che esistono oggi, prima di approfondire nello specifico il modo in cui la suite di strumenti Marlowe utilizza l’auditing e i forti principi di sicurezza per mantenere un ambiente di sviluppo degli smart contract sicuro e protetto.
Audit dei contratti smart
Panoramica
L’autonomia intrinseca dei contratti intelligenti e la posta in gioco relativamente alta di alcune transazioni fanno sì che garantire coerenza e sicurezza sia fondamentale. A tal fine è necessario sapere esattamente come si comporterà uno smart contract durante la sua esecuzione, in modo da poter individuare e risolvere qualsiasi potenziale difetto o codice dannoso intenzionale. L’audit dei contratti smart dal punto di vista della sicurezza è il modo migliore per prevenire eventuali guasti o danni. Un audit esamina a fondo il codice e le condizioni del contratto smart prima della distribuzione, per garantire che il contratto si comporti come previsto.
Metodi di audit
Sebbene gli approcci all’audit degli smart contract possano essere diversi e variare da progetto a progetto, gli smart contract possono essere analizzati con metodi manuali o automatizzati. Di solito, la maggior parte dei progetti utilizza una combinazione di entrambi.
Raccolta della documentazione
Prima di iniziare il processo di audit, gli auditor possono dedicare un po’ di tempo alla raccolta di tutta la documentazione relativa al progetto. Questa può includere documenti tecnici, whitepaper, codebase e qualsiasi altro materiale che possa essere rilevante e utile per il processo di audit.
Audit manuale
Questa forma di audit degli smart contract prevede che un gruppo di persone analizzi ogni riga di codice, la logica del contratto, l’architettura del contratto e tutte le misure di sicurezza integrate per garantire una progettazione efficiente e la correttezza. Oltre a rivelare errori di codifica, un audit manuale può anche scoprire difetti di progettazione. L’audit manuale tende a essere considerato un metodo molto approfondito e accurato.
Audit automatizzato
A differenza dell’auditing manuale, l’auditing automatizzato adotta normalmente un approccio al test incentrato sul software. Gli strumenti di audit del software, proprietari o disponibili sul mercato, possono aiutare a rilevare i bug, ma alcune vulnerabilità potrebbero non risultare evidenti.
Data la natura complementare di questi metodi, le migliori pratiche di auditing prevedono una combinazione di auditing manuale e automatizzato per garantire che tutti i potenziali difetti, bug e vulnerabilità vengano individuati e corretti.
Azioni successive all’audit
Una volta completato il processo di auditing, il/i revisore/i produrrà un rapporto che illustra in dettaglio le sue scoperte. Questi possono includere una classificazione degli errori per gravità e una serie di raccomandazioni.
Gli errori contrattuali possono essere classificati come:
- Critici: questo tipo di errore probabilmente impedirà il funzionamento sicuro di un contratto e/o di un protocollo.
- Maggiore: alcuni errori di codifica o di logica possono portare alla perdita di fondi o a uno stato incontrollato del protocollo.
- Medio: anche se i fondi non sono a rischio, questo tipo di errori può influire sulle prestazioni o sull’affidabilità del contratto.
- Minore: questa classificazione include solitamente codice inefficiente con un impatto minimo o nullo sulla sicurezza. Informativo: di solito si riferisce a problemi di stile di codifica o di best practice.
Vantaggi dell’auditing degli smart contract
Sebbene l’auditing sia importante per qualsiasi applicazione, è particolarmente cruciale per gli smart contract e le applicazioni decentralizzate (DApp) che girano su blockchain, a causa della natura immutabile di questi ledger decentralizzati.
I vantaggi dell’auditing degli smart contract includono l’identificazione proattiva dei rischi, l’evitamento di errori potenzialmente costosi, un ambiente di sviluppo complessivamente migliore e l’ottenimento di informazioni sulle vulnerabilità e su come eliminarle.
Identificazione proattiva dei rischi
L’implementazione di smart contract non verificati è una scommessa che nessuno sviluppatore o azienda dovrebbe mai fare. Alcuni contratti intelligenti possono comportare fondi consistenti che, se persi o compromessi, possono portare a responsabilità ancora maggiori. Lavorando proattivamente per rimediare a questi rischi, si riduce notevolmente la possibilità che qualcosa vada storto.
Evitare errori potenzialmente costosi
I fondi bloccati per sempre a causa di errori di codifica/logica o come risultato di un’interferenza dolosa in un contratto sono qualcosa che nessun cliente o sviluppatore vorrebbe mai sperimentare. La perdita finanziaria è solo un aspetto della questione. Ci possono essere anche serie ramificazioni legali.
Un ambiente di sviluppo migliore in generale
La verifica del software non è solo raccomandata, è un requisito. Garantire la sicurezza di un’applicazione o di una suite di applicazioni e seguire le best practice rafforza l’offerta e crea un ambiente di sviluppo più sano.
Ottenere informazioni sulle vulnerabilità e su come eliminarle
Nello sviluppo del software, prevenire è meglio che correggere. E quando si tratta di contratti intelligenti, non c’è possibilità di patch a causa della natura immutabile della blockchain. Una verifica approfondita fornirà molte informazioni sul codice, sulla logica del contratto, sull’architettura e su molti altri parametri, consentendo agli sviluppatori di perfezionare e produrre il miglior contratto possibile.
Attacchi basati su contratti intelligenti
Attacchi di tipo “re-entrancy”
In questo attacco, una funzione di smart contract cede temporaneamente il controllo di una transazione effettuando una chiamata a un secondo contratto, che inizia a effettuare chiamate ricorsive di prelievo al primo contratto, prosciugandone i fondi prima che il primo contratto aggiorni il suo stato. Questi tipi di attacchi sono possibili a causa di bug nella codifica degli smart contract. L’evento DAO del 2016 ha coinvolto un attacco di re-entrancy.
Il design della blockchain di Cardano rende impossibili gli attacchi di re-entrancy. Poiché Cardano utilizza il modello EUTXO, gli smart contract sono atomici e non si chiamano a vicenda, il che rende impossibile il rientro.
Attacchi front-running
Alcuni progetti di blockchain consentono che gli smart contract e le transazioni siano visibili pubblicamente per un certo periodo di tempo, prima di essere confermati sulla catena. Queste transazioni in sospeso sono condivise nei mempool della rete, il che consente a un avversario di vedere l’esito previsto di un contratto. Un avversario che ha visibilità delle transazioni in sospeso può introdurre una nuova transazione o un nuovo scambio sapendo che così facendo otterrà un profitto basato sulla transazione in sospeso, a scapito dei profitti degli altri utenti. In sostanza, un avversario manipola l’ordine di esecuzione delle transazioni a proprio vantaggio.
Mentre questo tipo di evento è un grosso problema su altre blockchain, non ci sono prove che Cardano (e, per estensione, Marlowe) sia vulnerabile alle invasioni front-running.
Manipolazione degli oracoli
Gli oracoli collegano le blockchain a sistemi esterni e gli smart contract possono essere eseguiti sulla base dei dati ricevuti dagli oracoli. Questa dipendenza da sistemi esterni significa che se l’input ricevuto dall’oracolo è stato manipolato prima di essere alimentato dall’oracolo, la sicurezza e l’integrità dell’esecuzione dello smart contract potrebbero essere compromesse.
Altre comuni vulnerabilità di sicurezza basate su smart contract includono errori aritmetici, integer overflow e underflow, impostazioni di visibilità dello smart contract e manipolazione del timestamp.
L’audit di Tweag
Questa sezione si concentra sui risultati dell’audit di sicurezza di Tweag, sulla risposta del team di Marlowe e sui principi di sicurezza incorporati nel progetto di Marlowe.
Risultati principali dell’audit di sicurezza di Tweag e risposte interne
Tweag ha eseguito un audit manuale e automatico del linguaggio Marlowe, che ha rivelato diversi problemi.
I risultati ad alta gravità hanno riguardato la gestione dei depositi negativi, la prevenzione della “doppia soddisfazione”, l’applicazione degli invarianti di stato, una differenza di implementazione tra la specifica formale e l’implementazione di Plutus e la prova del teorema di conservazione del denaro.
Gestione dei depositi negativi
Il reddito da depositi viene calcolato sommando gli input dei depositi, indipendentemente dal fatto che siano negativi, mentre la semantica li considera come depositi nulli. In combinazione con l’assenza di un controllo del saldo sullo stato finale di Marlowe, questo permette al saldo finale di differire dal valore pagato al validatore di Marlowe. Questo potrebbe essere sfruttato da un contratto Marlowe che consente depositi negativi.
Risposta interna
Il problema è stato risolto aggiungendo una protezione contro i depositi negativi nel validatore della semantica di Marlowe. Questa protezione assicura che la semantica del validatore per i depositi negativi corrisponda alla semantica Isabelle di Marlowe. In particolare, un deposito di una quantità negativa viene trattato come un deposito di zero. Pertanto, un deposito negativo non decrementerà nessuno dei saldi dei conti nel dato Plutus e il totale dei saldi interni corrisponderà al valore detenuto nell’UTXO all’indirizzo dello script della semantica di Marlowe.
Prevenzione della doppia soddisfazione
Sebbene il validatore Marlowe impedisca la doppia soddisfazione tra più copie dello script del validatore Marlowe in esecuzione nella stessa transazione, non lo impedisce nei casi in cui il validatore Marlowe viene eseguito insieme a un altro validatore Plutus nella stessa transazione.
Risposta interna
La doppia soddisfazione viene ora impedita imponendo che il validatore Marlowe sia l’unico script Plutus in esecuzione durante le transazioni che effettuano pagamenti alle parti. Questo permette ai contratti Marlowe di coordinarsi con altri script Plutus, ma solo in condizioni in cui la doppia soddisfazione è impossibile. Sono stati aggiunti alcuni test basati sulle proprietà per verificare la correttezza di questa mitigazione.
Applicazione degli invarianti di stato
In origine, il validatore Marlowe aveva fatto ipotesi ottimistiche sul proprio corretto funzionamento e non aveva controllato alcuni invarianti per ridurre i costi di esecuzione di Plutus.
Risposta interna
Il validatore della semantica di Marlowe ora applica rigorosamente gli invarianti per gli stati iniziali e finali, assicurando che i tre invarianti di stato di conti positivi, non duplicazione delle voci di stato (conti, scelte e valori vincolati) e un valore interno totale corrispondano al valore dello script UTXO.
Differenze di implementazione tra la specifica formale e l’implementazione di Plutus
La verifica ha rivelato alcune differenze tra le specifiche formali e l’effettiva implementazione di Plutus. In particolare, differenze linguistiche e considerazioni sull’efficienza rispetto a Isabelle, Haskell e Plutus Tx.
La specifica formale è scritta in Isabelle, un linguaggio per metodi formali, mentre l’implementazione effettiva di Marlowe è scritta in Haskell e Plutus Tx. Il team di Marlowe ha lavorato per seguire il più possibile le specifiche di Isabelle, ma alcune deviazioni erano inevitabili a causa dei diversi linguaggi. Ad esempio, alcuni aspetti dell’implementazione di Marlowe sarebbero stati inefficienti in Isabelle, quindi sono state necessarie delle modifiche per ottenere un’implementazione Haskell più efficiente.
Risposta interna
Questo problema è stato mitigato attraverso l’analisi del codice e i test basati sulle proprietà.
Prova del teorema della conservazione del denaro
Il teorema della conservazione del denaro aveva preso in considerazione solo la quantità di beni, ma non il loro tipo. Ciò significava che la prova non considerava il caso in cui un contratto potesse, ad esempio, ricevere 20 ada e 15 Djed e restituire 20 Djed e 15 ada.
Risposta interna
Una revisione del codice di Isabelle ha posto rimedio a questo problema. In particolare, l’aggiunta di un nuovo tipo MultiAssets e la rifattorizzazione del codice Isabelle (senza modificare l’interprete) per dimostrare che gli asset sono preservati.
Limitazioni funzionali di sicurezza incorporate in Marlowe
Marlowe presenta diverse limitazioni per garantire che non si verifichino determinati rischi per la sicurezza.
- I contratti sono finiti
- I contratti terminano
- I contratti hanno una durata definita
- Non vengono conservate attività quando il contratto si chiude
- Il valore è conservato
Oltre a queste limitazioni, alcuni costrutti del linguaggio di programmazione sono assenti da Marlowe per garantire la sicurezza:
- La ricorsione non è consentita
- Il looping non è supportato
- Non si possono definire funzioni o macro
- I timeout devono essere costanti numeriche
- Solo le continuazioni di caso possono essere merkelizzate. Il linguaggio di programmazione Faustus allenta alcune delle limitazioni di cui sopra, ma compila in modo sicuro Marlowe.
Strumenti di analisi della sicurezza
Lo strumento di analisi marlowe-cli run analyze, progettato dal team Marlowe, verifica la compatibilità di un contratto Marlowe con le regole del ledger Cardano.
Il libro mastro Cardano ha restrizioni incorporate che potrebbero impedire a un contratto Marlowe di funzionare sulla catena, anche se il contratto stesso fosse valido rispetto al linguaggio Marlowe. Ad esempio, il ledger impone restrizioni sulla lunghezza dei nomi dei ruoli e dei token e limita anche i costi di esecuzione di Plutus. Qualsiasi contratto che violi una di queste regole non verrebbe eseguito sulla catena, anche se il contratto potrebbe essere costruito correttamente. Allo stesso modo, anche se i contratti possono essere eseguiti sul Playground, non possono essere eseguiti sulla catena se il contratto viola le restrizioni del ledger. Per saperne di più sulle restrizioni di progettazione del ledger.
Aspetto fondamentale: mentre il Playground riguarda il linguaggio, Runtime riguarda l’implementazione del contratto Marlowe sulla blockchain Cardano. Se qualcuno implementa Marlowe su un’altra blockchain, si può ancora usare il Playground, ma non si può usare Runtime su un’altra blockchain.
Nota: un contratto può essere bloccato se il dato non si adatta alla catena, ma la suite Marlowe include strumenti per valutare questo rischio. Questi strumenti dovrebbero essere utilizzati prima di distribuire un contratto.
Convalida delle transazioni
Per la convalida della spesa UTXO sono coinvolti due tipi di script del validatore Plutus:
- Validatore semantico
- Validatore di pagamento
Le pratiche di sicurezza impongono di non firmare le transazioni se non si sono esaminati e compresi bene i contenuti e le implicazioni della transazione. Nell’ambiente Marlowe, ciò significa verificare il contratto Marlowe, i suoi input e il suo stato. Significa anche assicurarsi che la politica di conio dei ruoli (se presente) e il validatore Marlowe utilizzato siano quelli giusti.
Le considerazioni sulla sicurezza riportate di seguito si applicano a entrambi i tipi di script del validatore.
Validatore semantico
I seguenti concetti devono essere ben compresi prima di firmare una transazione Marlowe:
- La transazione opera un contratto Marlowe?
- Qual è la sua politica di conio dei ruoli (se esiste)?
- Come sono stati distribuiti i token di ruolo (se esistono)?
- Qual è il contratto corrente e il suo stato?
- Quali input vengono applicati al contratto?
- Cos’altro sta accadendo nella transazione?
La transazione gestisce un contratto Marlowe?
Gli script del validatore Plutus sono interpreti universali per tutti i contratti Marlowe di una versione specifica, il che significa che l’UTXO per un contratto Marlowe risiede in un hash dello script. La verifica che una transazione spenda da un indirizzo che ha l’hash dello script Marlowe come parte di pagamento conferma che il vero validatore Marlowe verrà eseguito per convalidare la spesa di quello specifico UTXO. È possibile calcolare l’hash dello script del validatore di Marlowe dai primi principi compilando il validatore e calcolando il suo hash, assumendo che il codice sorgente dello script di Marlowe in questo repository possa essere attendibile.
Qual è la politica di conio del suo ruolo (se esiste)?
Una politica di conio è l’insieme delle regole per la creazione di token di un determinato tipo di token, che è identificato dall’hash della sua politica di conio. Questo è noto come ID della politica di conio. Una politica di conio determina se possono essere creati nuovi gettoni o se i gettoni che sono stati creati sono tutti quelli che ci saranno.
Ad esempio, le parti di un contratto Marlowe, come mutuante e mutuatario, possono essere rappresentate in due modi:
- Con un indirizzo: ogni parte di tipo indirizzo corrisponde a un’istanza di una coppia di chiavi pubbliche e private, presumibilmente in possesso di un portafoglio di una delle parti. L’uso degli indirizzi per rappresentare le parti è più semplice ed economico rispetto all’uso dei ruoli. Per autenticarsi, le parti rappresentate da un indirizzo devono semplicemente firmare le transazioni che richiedono la loro autenticazione (cioè quelle che eseguono depositi o scelte per la parte).
- Tramite un token di ruolo: ogni parte di tipo ruolo corrisponde a un token memorizzato sulla catena. Affinché un contratto utilizzi i token di ruolo come autenticazione, deve dichiarare che il suo ID di politica di conio del token di ruolo è l’ID di politica di conio del token che vuole utilizzare come token di ruolo. In questo caso, ogni nome di risorsa del token identificato dall’ID della politica di conio rappresenta una parte diversa. Per autenticare una transazione, il proprietario di un token di ruolo deve semplicemente includerlo come parte della transazione che richiede l’autenticazione del proprietario del token di ruolo. Potenzialmente può esistere più di un token con lo stesso nome di risorsa, quindi tecnicamente non si possiede una parte di ruolo se non si possiedono tutte le istanze del token di ruolo che ha il nome di risorsa della parte.
Come sono stati distribuiti i token di ruolo?
Se un contratto utilizza solo gli indirizzi per rappresentare le parti, le politiche di conio per i ruoli non sono un problema. Lo svantaggio degli indirizzi è che non possono essere trasferiti in modo dimostrabile, quindi una volta che la chiave privata di un indirizzo è nota, non si può dimostrare di averla dimenticata e cancellata. Dal punto di vista del destinatario di un indirizzo, l’indirizzo è sempre insicuro. L’unico modo per avere un indirizzo sicuro è generarlo da soli.
Il vantaggio o i ruoli è che, poiché i token sono trattati come beni nativi della catena, possono essere trasferiti proprio come gli ada o qualsiasi altro bene. Ma chiunque possieda un token con il giusto ID di politica di conio e il nome dell’asset può agire come la parte che rappresenta, quindi dovete assicurarvi di essere gli unici a possedere un token di questo tipo, altrimenti non avrete il controllo della parte.
È possibile assicurarsi di essere l’unico proprietario del token coniando personalmente i token di ruolo (Marlowe Runtime lo fa in modo sicuro come parte del processo di creazione del contratto). Se qualcun altro ha coniato i token di ruolo o creato il contratto, è necessario assicurarsi che:
- si disponga di tutti i token esistenti che controllano il partito
- Non è possibile creare altri token di questo tipo (perché la politica di conio non lo consente).
Se la politica di conio è abbastanza semplice, il modo più facile per verificarlo è utilizzare uno scanner Marlowe per scoprire l’ID della politica di conio del ruolo del contratto. Quindi, utilizzare Cardano explorer per verificare quale sia la politica di conio (per garantire che non possano essere prodotti altri ruoli) e per controllare l’attuale distribuzione dei ruoli esistenti già coniati (chi ha quali token, in altre parole).
Qual è il contratto attuale e il suo stato?
Lo stato del contratto prima della transazione è definito nel dato Plutus associato all’UTXO speso dall’indirizzo dello script Marlowe. Questo dato deve essere fornito nella transazione e deve contenere quanto segue:
- i saldi dei conti interni al contratto
- lo storico delle scelte effettuate fino a questo momento dell’esecuzione del contratto
- i valori attuali delle variabili vincolate del contratto
- la parte del contratto che rimane da eseguire.
Il dato può essere estratto dal corpo della transazione non firmata e deserializzato in Language.Marlowe.Core.V1.Semantics.MarloweData utilizzando la funzione Plutus.V2.Ledger.Api.fromData.
In alternativa:
- lo strumento a riga di comando marlowe log --show contract visualizza la storia del contratto sulla catena.
- Questo strumento online consente anche di visualizzare i contratti e lo stato sulla catena.
- Un’API REST fornisce le stesse informazioni ottenute tramite marlowe log --show
Quale input viene applicato al contratto?
Il redentore Plutus associato alla spesa dell’UTXO dall’indirizzo dello script Marlowe definisce l’input che viene applicato al contratto, insieme all’intervallo di validità dello slot per la transazione specificato nel corpo della transazione. L’input è una sequenza di zero o più depositi, scelte e notifiche. Utilizzando strumenti come Marlowe Playground o marlowe-cli run prepare, è possibile analizzare le conseguenze dell’applicazione di questo input al contratto.
Il riscatto può essere estratto dal corpo della transazione non firmata e deserializzato in Language.Marlowe.Scripts.MarloweInput utilizzando la funzione Plutus.V2.Ledger.Api.fromData. Lo strumento a riga di comando marlowe-cli util slotting calcolerà la relazione tra gli slot menzionati nell’intervallo di validità e i tempi POSIX del contratto.
Cos’altro sta accadendo nella transazione?
La transazione non firmata può contenere altre spese e pagamenti oltre a quelli specificati per il contratto Marlowe. Questo può essere esaminato con lo strumento cardano-cli transaction view.
Politiche monetarie
In genere, si dovrebbero utilizzare politiche monetarie (come quelle supportate da Marlowe Runtime) che impongono un singolo evento di conio e singoli token per ogni ruolo. Queste politiche assicurano che i token di ruolo siano veri token non fungibili (NFT), in modo che i titolari dei token di ruolo siano verificabilmente gli unici a poter agire come parti del contratto.
Le politiche monetarie che coniano più copie di un particolare token di ruolo, o le politiche con una politica di conio aperta, supportano casi d’uso non standard. Ad esempio, il conio di due copie di ciascun token di ruolo e la loro distribuzione allo stesso soggetto consente a quest’ultimo di mettere un token in un deposito freddo come backup se il portafoglio contenente il token di ruolo “caldo” diventa inaccessibile. Alcuni contratti di crowdsourcing innovativi potrebbero prevedere l’assegnazione del ruolo (tramite token di ruolo identici che possono essere coniati anche dopo l’inizio del contratto) a molti partecipanti. Infine, la politica di coniazione dei gettoni di ruolo di un contratto Plutus può coordinarsi con il funzionamento di uno o più contratti Marlowe.
Gettoni di ruolo
I gettoni di ruolo possono autorizzare depositi e scelte nelle transazioni Marlowe. Autorizzare l’uso di un token di ruolo è più flessibile che autorizzare con una chiave pubblica, perché un token di ruolo (e quindi la partecipazione a un contratto Marlowe) può essere trasferito tra portafogli o a qualcun altro.
Gli script del validatore Marlowe non applicano alcuna politica monetaria particolare per i token di ruolo, per consentire nuovi casi d’uso. Tuttavia, la sicurezza delle autorizzazioni in un contratto Marlowe basato sui ruoli dipende in modo critico dalla politica monetaria dei token di ruolo. Ciò significa che sia la politica monetaria che l’erogazione dei token sulla catena devono essere attentamente esaminate prima di partecipare a un contratto Marlowe. La verifica della politica monetaria di un semplice script comporta il recupero dello script dalla blockchain e il suo studio. La verifica della politica monetaria di uno script Plutus comporta l’ottenimento e lo studio del codice sorgente Plutus dello script e l’hashing del codice sorgente per verificare l’ID della politica monetaria.
Ringraziamenti: Joseph Fajen, Brian Bush e Omer Husain hanno dato un contributo prezioso a questo articolo.