Traduzione italiana di “Time handling on Cardano, part 2: use cases - IOHK Blog”
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
Gestione del tempo su Cardano, parte 2: casi d’uso
Come Plutus, Marlowe e Hydra affrontano la gestione del tempo su Cardano
Questo post è stato scritto da Arnaud Bailly, Michael Peyton Jones, Sebastian Nagel, Polina Vinogradova e Brian Bush.
Nel post precedente abbiamo parlato di come Ouroboros gestisce il tempo su Cardano e abbiamo spiegato l’importanza del determinismo. Qui si parla di casi d’uso specifici per il tempo su Cardano.
Come gestiscono il tempo gli script di Plutus?
Gli script Plutus hanno accesso all’intervallo di validità delle transazioni, definito dal loro creatore. Quando definisce l’intervallo di validità , il creatore può decidere che una transazione sia valida dallo slot X allo slot Y, oppure lasciare uno o entrambi i limiti indefiniti. Questo impone dei vincoli su quale slot una transazione può essere inclusa, il che è molto utile sulla catena per definire vari “contratti”.
Lo script può assumere che il momento effettivo della convalida sia in questo intervallo. In caso contrario, la transazione fallirà nella fase 1 prima dell’esecuzione dello script. Questo assicura il determinismo, poiché lo script vedrà sempre la stessa informazione (l’intervallo di validità ) indipendentemente dal momento in cui lo script viene convalidato, quindi il comportamento sarà lo stesso.
I limiti dell’intervallo di validità sono espressi in tempo reale (POSIXTime), anziché in slot, e la conversione da slot a tempo reale avviene per consenso, come discusso nel post precedente. L’uso del tempo reale anziché degli slot è importante perché la lunghezza degli slot può cambiare durante un hard fork, quindi le ipotesi basate sul conteggio degli slot sono generalmente inaffidabili. Il fatto che gli script vedano l’intervallo di validità permette agli script di fare affermazioni come “l’ora corrente è prima/dopo una certa ora”, ma non permette a uno script di fare qualsiasi altro tipo di asserzione (“il secondo in cui questa transazione è convalidata è pari”, per esempio).
Nel progetto originale di Alonzo, l’intervallo di validità copriva tutti gli usi noti del tempo, adattandosi perfettamente al campo time-to-live (TTL) esistente. In teoria, è possibile applicare gli stessi principi ad altri tipi di asserzioni, ad esempio lasciare che lo script si affidi alle asserzioni verificate nella fase 1. Tuttavia, ciò non sarebbe facile, dato che la fase 1 non è stata verificata. Tuttavia, ciò non sarebbe facile, poiché implica profonde modifiche strutturali a varie parti della rete Cardano. Inoltre, poiché i controlli della fase 1 devono essere validi per ogni nodo della rete, questo preclude qualsiasi tipo di asserzione che dipenda da qualche condizione locale, come l’“ora corrente”.
Casi d’uso del tempo
Il tempo ha diverse applicazioni nell’ecosistema Cardano.
Hydra
Il protocollo Hydra dipende dal tempo per calcolare e applicare la scadenza della contestazione, che è una parte fondamentale del meccanismo di sicurezza del protocollo. La macchina a stati Hydra Head traccia il passaggio del tempo utilizzando UTCTime, ma il tick proviene dalla catena, in base al numero di slot osservato dai blocchi prodotti dalla catena. Il motivo dell’utilizzo di UTCTime è legato alle limitazioni insite nella conversione da slot a tempo imposta dalla finestra di validità . Non è possibile convertire uno slot troppo lontano nel futuro, il che significa che è più semplice utilizzare UTCTime fuori dalla catena ed effettuare le conversioni solo quando si inviano/ricevono transazioni da o verso la catena.
Ciò implica che la granularità del tick è approssimativamente di 20 secondi, poiché questa è la frequenza prevista di produzione dei blocchi. Utilizzando questa misura di tempo, Hydra è in grado di reagire al superamento della scadenza di contestazione rilevante per il protocollo.
L’aspetto importante è che il tempo locale nella testa di Hydra (e nei nodi) è legato al tempo sulla catena gestito da Ouroboros (si veda la parte 1 per maggiori dettagli). Poiché Hydra è un protocollo isomorfo, è auspicabile elaborare le “transazioni a tempo” anche sul livello 2 (si veda il problema #196). Tuttavia, Hydra non produce blocchi, quindi il consenso stesso non ha bisogno di una nozione di tempo (ancora).
Ciò richiede la comprensione della precisione e del processo di discretizzazione del tempo su un ledger di livello 2. Sebbene le complessità della gestione del tempo sulla catena si applichino anche al livello 2, quest’ultimo può fornire soluzioni migliori poiché queste reti sono molto più piccole, hanno una durata di vita più breve e non hanno bisogno di scalare a livello globale.
Se siete interessati a partecipare alle discussioni e a condividere i tipi di applicazioni che avete e i tempi di risoluzione che richiedono, iscrivetevi al canale Discord di Hydra.
Marlowe
Marlowe è un linguaggio specifico per il dominio (DSL) per la scrittura di contratti finanziari e transazionali, quasi tutti basati sul tempo. In Marlowe è stata scritta un’ampia gamma di contratti finanziari standard, tra cui la maggior parte dei contratti standard ACTUS (ad esempio, prestiti, swap, opzioni e derivati). Inoltre, Marlowe supporta una varietà di tipi di contratti non finanziari, come aste, scambi di token e persino giochi. I meccanismi esistenti di Cardano per lavorare con il tempo si integrano perfettamente con la semantica di Marlowe e forniscono alle transazioni di Marlowe la localizzazione e il determinismo ereditati da Plutus.
In Marlowe, il tempo del contratto appare tipicamente nelle scadenze e nei timeout che limitano l’evoluzione dell’esecuzione del contratto, e questo funziona perfettamente con gli intervalli di validità di Cardano. La logica di timeout è necessaria in un contratto di prestito, ad esempio, per gestire la situazione in cui un pagamento del prestito viene mancato: in tal caso è necessario eseguire una logica diversa per imporre una penale, regolare il calendario dei pagamenti futuri, ecc. I contratti possono anche utilizzare direttamente gli estremi temporali dell’intervallo di validità in calcoli numerici, magari per regolare gli importi dei pagamenti futuri in base al momento in cui è stato ricevuto un pagamento anticipato. Il fatto che il tempo appaia come un intervallo ha un impatto pratico minimo su Marlowe, perché l’intervallo può essere breve come il tempo che intercorre tra l’invio di una transazione e la sua comparsa in un blocco sulla rete Cardano - solo pochi minuti.
Soluzioni
Cardano potrebbe potenzialmente fornire dati temporali più accurati durante la convalida delle transazioni, come il timestamp del produttore del blocco in cui il blocco è stato coniato, convertito dal suo slot, o anche il timestamp effettivo in UTC con precisione di millisecondi. Tuttavia, questo romperebbe il determinismo prospettico (si veda la parte 1) come avviene nei protocolli che non includono questa caratteristica: un utente non potrebbe più dire se una transazione può essere applicata al ledger o meno, perché ciò dipenderebbe dal timestamp esatto che il produttore del blocco ha usato quando ha creato il blocco.
Un’altra opzione consiste nell’aggiungere vari tipi di asserzioni ai corpi delle transazioni oltre l’intervallo di validità . Questo è possibile, ma difficile, come già sottolineato in precedenza, quindi è necessario che ci sia un caso d’uso perché questi tipi di asserzioni siano utili.
Infine, le reti di livello 2, come Hydra, possono fornire una maggiore precisione grazie a una “lunghezza dello slot” più breve e a un intervallo di validità più breve, oltre a una minore latenza nella finalizzazione delle transazioni. Si noti che l’attuale implementazione di Hydra Head non fornisce ancora questo livello di flessibilità .
Conclusioni
Il tempo è un argomento complesso, soprattutto in un contesto di blockchain decentralizzata. Questi post dimostrano che esiste una nozione chiara di tempo on-chain su Cardano, con vincoli specifici e opzioni di miglioramento disponibili a lungo termine.
Il tempo on-chain si comporta in modo un po’ diverso dal tempo del software tradizionale. Questa divergenza è definita in modo coerente per affrontare i vincoli del sistema, garantendo al contempo la sicurezza e l’usabilità per gli utenti finali e gli operatori di stake pool. Inoltre, la misura del tempo di Cardano sembra essere abbastanza buona da coprire diversi casi d’uso, anche rispetto agli usi finanziari tradizionali.
Unitevi ai canali della comunità Discord per ulteriori discussioni sulla gestione del tempo in Cardano e sui potenziali casi d’uso non menzionati in questi post.