🇮🇹 "Convalida delle transazioni senza sorprese su Cardano"

[lordwotton]

Traduzione italiana di “No-surprises transaction validation on Cardano” scritto da Polina Vinogradova nel blog IOG

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

---

Convalida delle transazioni senza sorprese su Cardano

Il modello EUTXO di Cardano permette la natura deterministica dell’esecuzione degli script Plutus

Mentre l’hard fork di Alonzo porta la capacità dei contratti smart Plutus a Cardano, il ledger si evolve per soddisfare il crescente bisogno di implementazione di soluzioni decentralizzate. La progettazione del ledger di Cardano si concentra sull’alta garanzia, la sicurezza e la comprovata verifica formale. In linea con questa strategia, è anche importante garantire che l’elaborazione delle transazioni sia deterministica, il che significa che un utente può prevedere il suo impatto e il risultato prima dell’esecuzione effettiva.

La capacità di garantire il costo dell’esecuzione della transazione, e come la transazione si comporta sul libro mastro prima di essere presentata, diventa ancora più importante con l’introduzione del supporto ai contratti intelligenti. Le blockchain basate sull’Unspent Transaction Output (UTXO), come Cardano, forniscono tali capacità. Le blockchain basate su account, come Ethereum, sono indeterministiche, il che significa che non possono garantire la prevedibilità dell’effetto della transazione sulla catena. Questo presenta rischi di perdita monetaria, commissioni imprevedibilmente alte, e ulteriori opportunità di comportamento avverso.

In questo post sul blog, diamo un’occhiata più da vicino ai vantaggi del design deterministico di Cardano che permette una valutazione sicura delle transazioni e degli script prima dell’esecuzione. Nel seguente post del blog, in arrivo nel corso della settimana, discutiamo le due fasi della convalida delle transazioni su Cardano.

Cos’è il determinismo delle transazioni e perché è importante?

Il determinismo, nel contesto dell’elaborazione delle transazioni e degli script, è un sinonimo di prevedibilità. Questo significa che un utente può prevedere localmente (off-chain) come la sua transazione avrà un impatto sullo stato on-chain del ledger, senza:

• esiti o fallimenti inaspettati della convalida degli script
• commissioni inaspettate
• aggiornamenti inattesi dello stato del libro mastro o degli script.

Una transazione in un sistema deterministico potrebbe ancora essere rifiutata, anche se costruita correttamente. Rifiutata significa che la transazione non può essere applicata al ledger, quindi non ha alcun effetto sul suo stato, quindi non viene pagata alcuna tassa. La ragione per cui questo accadrebbe è dovuta ai cambiamenti nel libro mastro causati da altre transazioni elaborate tra il momento in cui la transazione iniziale viene costruita e il momento in cui viene elaborata. Questo può accadere anche con transazioni semplici. Per esempio, un’altra transazione potrebbe spendere un UTXO che un utente aveva anche intenzione di spendere. Il determinismo assicura che, ogni volta che una transazione viene accettata, avrà solo effetti prevedibili sullo stato del libro mastro.

Affrontare il problema dell’indeterminismo

L’indeterminismo significa che non possiamo prevedere quali effetti avrà una transazione sul ledger prima dell’esecuzione. Quando si progetta il libro mastro, così come un interprete di contratti intelligenti, è importante prevedere le condizioni in cui l’indeterminismo potrebbe verificarsi, e prendere decisioni di progettazione per evitarle. Uno dei principali pericoli in questo caso è l’accesso a dati ledger mutabili, cioè dati che possono essere cambiati o alterati. Quando le modifiche che una transazione o un contratto intelligente fanno al ledger dipendono dal suo stato al momento dell’elaborazione, piuttosto che solo dal contenuto della transazione, l’indeterminismo potrebbe diventare un problema.

Ethereum è particolarmente suscettibile a questo problema. Per esempio, i prezzi del gas, o un tasso di scambio decentralizzato (DEX) possono fluttuare tra il momento in cui un utente invia una transazione e il momento in cui viene elaborata. Questo si traduce in tariffe inaspettate per il gas, o cambiamenti di prezzo dei beni che vengono acquistati. Oppure uno script potrebbe semplicemente fallire, causando alti costi di esecuzione (centinaia di dollari) e nessun altro effetto. Questo potrebbe accadere, per esempio, se i fondi disponibili per coprire i costi del gas finiscono a metà dell’esecuzione. La progettazione deterministica del libro mastro elimina queste possibilità.

Altre possibili fonti di indeterminismo includono il permettere agli script di vedere:

• dati nel blocco che contiene la transazione, ma non inclusi in nessuna transazione, ad esempio, la casualità del sistema, l’intestazione del blocco, o il numero dello slot corrente
• dati alterati o sostituiti da un avversario, che potrebbero cambiare il risultato della convalida dello script, mentre la transazione stessa rimane processabile.

Nella maggior parte dei sistemi, ci sono modi per mitigare questi problemi con migliori pratiche di scrittura degli script, o soluzioni layer-2. Cardano è progettato per garantire risultati prevedibili per tutti gli script e le transazioni.

Come il modello UTXO di base beneficia in termini di determinismo

Il ledger di Cardano è costruito su un modello contabile UTXO, il che significa che i beni sono memorizzati sul libro mastro in uscite non spese, piuttosto che in conti. Ciascuna di queste uscite specifica le quantità di beni memorizzati in essa, insieme al suo indirizzo. Le uscite non spese sono immutabili, così una transazione può consumare l’intera uscita, ma non può alterarla.

Per trasferire beni, una transazione consuma uno o più output e ne crea di nuovi, che, in totale, contengono le stesse quantità di beni di quelli consumati. Queste quantità - e i loro indirizzi UTXO - sono specificati negli output della transazione. L’unico modo in cui una transazione può influenzare l’effetto di un’altra transazione applicata al libro mastro è spendendo la stessa UTXO che la transazione successiva cerca di spendere, causando così il rifiuto del nodo. Questa è la caratteristica chiave su cui si basa il modello UTXO per mantenere il determinismo.

Un ledger UTXO ha sia vantaggi che svantaggi rispetto al modello basato su account. Quest’ultimo incontrerà meno casi di transazioni che si bloccano a vicenda, per esempio. A differenza delle UTXO, i conti sono dati ledger mutevoli. Così una transazione potrebbe vedere, per esempio, una diversa quantità di beni in un conto, a seconda che sia stata elaborata prima o dopo un’altra transazione che aggiorna lo stesso conto. Questa circostanza potrebbe non causare il rifiuto della transazione, ma potrebbe risultare in diversi - e imprevedibili - cambiamenti nel libro mastro.

Spendere un UTXO è solo un esempio di un’azione che una transazione può compiere. Successivamente, spieghiamo cosa sono le azioni di transazione e come possono essere convalidate. La serie più significativa di cambiamenti introdotti in Alonzo sono i cambiamenti al processo di convalida delle azioni.

Convalidare le azioni con firme e script

Un aspetto importante dell’elaborazione di una transazione è la validazione delle azioni che sta compiendo. Una transazione sta compiendo un’azione quando contiene dati nel campo specifico di quell’azione. Per esempio, una transazione sta spendendo UTXO U quando contiene un riferimento a U nel suo campo di input, e sta coniando un token X quando il suo campo mint contiene X.

Quando il nodo elabora una transazione, verifica se può eseguire l’azione che intende eseguire. Per questo, l’autore della transazione deve fornire dati rilevanti, ad esempio, script, redattori o firme. Un esempio comune di un’azione che richiede una convalida è spendere un UTXO bloccato con una chiave pubblica. La transazione deve fornire una firma dalla chiave privata corrispondente per eseguire questa azione.

Cardano utilizza degli script per convalidare le azioni. Questi script, che sono pezzi di codice, implementano funzioni pure con output True o False. La convalida degli script è il processo di invocare l’interprete dello script per eseguire un dato script su argomenti appropriati.

La convalida degli script può essere eseguita per le seguenti azioni:

• Spendere un UTXO bloccato da un indirizzo di script: lo script che viene eseguito è quello il cui hash forma l’indirizzo.
• Coniatura di un token: lo script che viene eseguito è quello il cui hash forma il policy ID del token che viene coniato.
• Ritiro della ricompensa: lo script che viene eseguito è quello il cui hash forma l’indirizzo di staking.
• Applicazione di un certificato: lo script che viene eseguito è quello il cui hash forma la credenziale dell’autore del certificato.

Oltre a far sapere al nodo quale script eseguire, tutte le azioni di transazione indicano come assemblare gli argomenti passati a quello script.

Il ledger multi-asset di Cardano (Mary) supporta semplici linguaggi di scripting multisig e timelock. Questi permettono agli utenti di specificare le firme necessarie per eseguire un’azione (come spendere un UTXO o coniare un token non fungibile (NFT)), e l’intervallo di tempo in cui può essere eseguita. Uno script timelock non può mai vedere il numero effettivo di slot nella transazione che lo include. Timelock può solo vedere l’intervallo di validità della transazione portante. Permettere ad uno script timelock di vedere il numero di slot corrente (cioè i dati provenienti dal blocco, piuttosto che l’autore) romperebbe il determinismo. Questo è garantito dal fatto che un utente non può conoscere lo slot esatto in cui la transazione viene elaborata, e quindi non può prevedere come si comporterà lo script.

Gli script Mary, a differenza dei contratti Plutus in Alonzo, sono molto limitati in ciò che possono esprimere. L’hard fork di Alonzo inaugura una nuova era di contratti potenti e statici che non compromettono la proprietà deterministica del ledger.

Script Plutus

Alonzo introduce un nuovo approccio alla convalida delle transazioni su Cardano grazie all’implementazione degli script Plutus. Il modello EUTXO (extended unspent transaction output), implementato come parte di Alonzo, fornisce l’infrastruttura ledger per supportare i contratti Plutus. Di seguito, forniamo una panoramica di alto livello dei cambiamenti del ledger e delle transazioni. Per maggiori dettagli su come lavorare con il libro mastro e gli script Plutus, controlla il programma Plutus Pioneer!

Alonzo cambia i dati sul libro mastro come segue:

1. Gli script Plutus possono bloccare gli UTXO.
2. Un nuovo componente, aggiunto al contenuto delle parti in uscita degli UTXO, permette una funzionalità simile a quella degli script. Oltre agli asset e a un indirizzo, un UTXO bloccato dagli script Plutus contiene anche un dato. Un dato è un pezzo di dati che può essere pensato come un’interpretazione dello stato dello script.
3. Ci sono una serie di nuovi parametri di protocollo utilizzati per imporre ulteriori requisiti di convalida sulle transazioni. Questi includono limiti superiori sulle risorse computazionali che gli script possono consumare.

Per supportare gli script Plutus, le transazioni sono state aggiornate come segue:

1. Per ciascuna delle sue azioni, la transazione ora porta un argomento specificato dall’utente, chiamato redeemer. A seconda dello script, un redentore può servire uno scopo diverso. Per esempio, può agire come l’offerta che l’utente fa in un’asta, o l’ipotesi dell’utente in un gioco di indovinelli, tra molte altre funzioni.
2. La transazione specifica i budget di esecuzione computazionale per ogni script.
3. Per garantire che una transazione possa pagare il suo budget di esecuzione, Alonzo introduce ulteriori dati, che discuteremo in un post successivo.
4. Le transazioni contengono un hash di integrità, necessario per garantire che non sia stato compromesso, superato, ecc.

Ci sono anche alcuni cambiamenti nelle specifiche della convalida delle transazioni di Alonzo rispetto a Mary. Per ogni azione, il nodo assembla gli argomenti dello script previsti dall’interprete di Plutus, tra cui:

• il dato
• il redentore
• il budget di esecuzione
• un riassunto della transazione.

Il nodo esegue nuovi controlli specifici per Alonzo che assicurano che la transazione sia costruita correttamente. Per esempio, non deve superare il budget massimo di risorse di esecuzione. Invoca anche l’interprete di script Plutus per eseguire gli script.

Oggetti dati vs stato script

Come i conti mutabili, lo stato degli script mutabili rientra perfettamente nella categoria dei “dati del libro mastro mutabili” delle fonti di indeterminismo. Abbiamo già visto che il modello UTXO evita il problema dell’indeterminismo dei conti mutabili. Può anche aiutarci a reimmaginare il concetto di script state in un modo che mantiene il determinismo. Se una UTXO è bloccata da uno script Plutus, il codice dello script di quella UTXO è associato al suo indirizzo. Lo stato-analogo di questo script è il dato memorizzato in quella UTXO. Quando una transazione spende quell’UTXO, viene cancellata dal libro mastro, incluso il dato. Tuttavia, il contenuto dello script Plutus potrebbe imporre che la transazione che lo trasporta debba anche creare una UTXO contenente un dato specifico che può essere visto come lo stato aggiornato dello script.

Bilancio dell’esecuzione dello script

Il modello di gas non-deterministico può far pagare agli utenti tariffe imprevedibilmente grandi. Negli script di Cardano, questa fonte di indeterminismo è affrontata richiedendo che il budget delle risorse stesse, così come la tassa richiesta per coprire questo budget, siano inclusi nella transazione. In Alonzo, un utente può prevedere entrambi localmente quando costruisce la transazione. L’esecuzione di uno script restituisce necessariamente o True o False, e non si ripeterà all’infinito. La ragione di questo è che ogni operazione che uno script esegue richiede una quantità non nulla di risorse, che sono tracciate dall’interprete. Se il budget specificato dalla transazione viene superato, l’esecuzione dello script termina e restituisce False.

Convalida delle transazioni in Alonzo

Affrontando le possibili fonti di indeterminismo, i seguenti punti chiave rendono prevedibili i risultati della convalida di script e transazioni:

• l’interprete dello script terminerà sempre e restituirà lo stesso risultato di validazione quando applicato agli stessi argomenti
• una transazione fissa necessariamente tutti gli argomenti che saranno passati all’interprete dello script durante la validazione
• una transazione specifica tutte le azioni che sta compiendo e che richiedono la validazione dello script
• le firme obbligatorie su una transazione assicurano che non possa essere alterata da un avversario in modo da far fallire gli script
• l’applicazione di una transazione nel modello ledger EUTXO è deterministica.

L’ultimo punto è in gran parte ereditato dal modello UTXO, poiché gli aggiornamenti del protocollo ledger Alonzo rimangono, per la maggior parte, coerenti con gli aggiornamenti delle ere precedenti (compreso lo schema di delega, ecc.). Dopo l’aggiornamento di Alonzo, il fallimento o il successo della convalida dello script influenza il modo in cui una transazione viene elaborata (di più su questo nella parte 2!). Tuttavia, l’esito Vero o Falso, così come i cambiamenti del libro mastro associati ad entrambi gli esiti, sono prevedibili per una data transazione.

Il comportamento deterministico dello script di Cardano e la convalida delle transazioni non è un risultato naturale dell’utilizzo del modello EUTXO. Per garantire questa proprietà, il team IOG ha dovuto tracciare attentamente la fonte di ogni pezzo di dati che uno script è autorizzato a vedere.

La proprietà di valutazione deterministica è specificata formalmente nella specifica Alonzo, e il team IOG ha anche abbozzato la prova che l’interprete riceve solo quegli argomenti che non rompono la proprietà.

Nel nostro secondo post sul blog, daremo uno sguardo più da vicino al processo di convalida in 2 fasi delle transazioni Cardano. Quindi, tenete d’occhio questa settimana per la seconda parte.