Traduzione italiana di “No-surprises transaction validation: part 2” 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: parte 2
La convalida delle transazioni di Alonzo viene eseguita in due fasi per garantire un equo compenso per il lavoro di convalida
Nel nostro precedente post sul blog, abbiamo discusso la natura deterministica della convalida delle transazioni e degli script sul ledger Alonzo, che fornisce la garanzia che il risultato dell’applicazione delle transazioni on-chain e della convalida degli script può essere accuratamente previsto localmente, prima che la transazione sia mai inviata.
Basandosi sulle garanzie fornite dal design deterministico del ledger Alonzo, abbiamo implementato uno specifico schema di convalida a due fasi. È progettato per ridurre al minimo le risorse che i nodi utilizzano per convalidare le transazioni in rete, eliminando al contempo i costi imprevisti per l’utente. In questo post del blog, ci immergiamo più a fondo in come funziona la convalida a due fasi.
Nelle epoche Shelley, Allegra e Mary, la convalida delle transazioni era un processo a una fase. L’effetto di una transazione valida sul libro mastro era completamente prevedibile prima che fosse applicata. Se una transazione era valida, veniva inclusa in un blocco e aggiunta al libro mastro. In caso contrario, un nodo la rifiutava dopo un tentativo di convalida fallito e la transazione non veniva inclusa in un blocco. Tuttavia, i nodi che convalidavano le transazioni in entrata usavano tempo e risorse, indipendentemente dal fatto che la transazione finisse o meno in un blocco.
Alonzo introduce gli script di Plutus, che potrebbero richiedere molte più risorse per validarli rispetto ai semplici script delle epoche precedenti. Per affrontare il problema dei nodi che spendono risorse per validare gli script delle transazioni che vengono rifiutati, Alonzo introduce un approccio di validazione a due fasi. Questa strategia mantiene un risultato prevedibile dell’applicazione delle transazioni al libro mastro, e assicura anche un equo compenso ai nodi per il loro lavoro e l’uso delle risorse.
Convalida delle transazioni in due fasi
La convalida delle transazioni su Cardano è divisa in due fasi. La ragione principale per l’introduzione della convalida in due fasi è quella di limitare la quantità di lavoro di convalida non compensato dai nodi. Ogni fase ha uno scopo nel raggiungimento di questo obiettivo. Approssimativamente, la prima fase controlla se la transazione è costruita correttamente e può pagare la sua tassa di elaborazione. La seconda fase esegue gli script inclusi nella transazione. Se la transazione è valida nella fase-1, vengono eseguiti gli script della fase-2. Se la fase-1 fallisce, non viene eseguito alcuno script e la transazione viene immediatamente scartata.
Quindi, ci si aspetta che i nodi aggiungano transazioni processabili ad un blocco anche se le transazioni non sono valide in fase-2. Questo significa che
- una piccola quantità di lavoro non compensato viene fatto da un nodo per scoprire che una transazione non è processabile, ma non viene fatta una costosa validazione di fase 2, oppure
- la transazione è processabile. Il nodo può quindi eseguire la validazione di fase-2 degli script, etichettare la transazione di conseguenza come fase-2 valida o fase-2 non valida, e aggiungerla ad un blocco. In entrambi i casi, il nodo sarà successivamente compensato per entrambe le fasi di convalida attraverso la tassa o la garanzia raccolta da questa transazione.
L’aspettativa è che il fallimento della fase-2 dovrebbe essere raro, perché un utente che presenta una transazione con script falliti perderà ada mentre non ottiene nulla. Questo è localmente prevedibile, e quindi un evento prevenibile. La fase è una salvaguardia necessaria per garantire la compensazione per il calcolo potenzialmente dispendioso di risorse degli script.
Diamo un’occhiata più da vicino alle specifiche di ogni fase.
Fase 1
La prima fase di convalida deve essere semplice. Se questa fase fallisce, un nodo non viene compensato per il lavoro che ha fatto, poiché non può accettare commissioni di elaborazione da transazioni non elaborabili.
La convalida della fase 1 verifica due cose: che una transazione sia costruita correttamente e che sia possibile aggiungerla al libro mastro. Questa convalida include i seguenti controlli e alcuni aggiuntivi:
- paga la corretta quantità di commissioni e fornisce la corretta quantità di garanzia (cioè l’ada raccolta in caso di fallimento dello script, spiegato di seguito)
- include tutti i dati richiesti per l’esecuzione degli script Plutus
- non supera alcun limite fissato nei parametri del protocollo (sulle dimensioni dell’output, ecc.)
- i suoi input si riferiscono a UTXO esistenti sul libro mastro
- il budget computazionale dichiarato per la transazione non supera il limite massimo di risorse per transazione
- i controlli di integrità dell’hash, ecc.
Prima di aggiungere una transazione in entrata al mempool (ed eventualmente ad un blocco), un nodo deve eseguire tutti i controlli di convalida della fase 1. Se uno di questi controlli fallisce, la transazione viene rifiutata senza essere inclusa in un blocco, e non vengono addebitate commissioni. Nelle epoche precedenti, questa era l’unica fase di convalida, e Cardano gestiva tutti i fallimenti di convalida in questo modo.
Non ci si aspetta che i nodi onesti e non compromessi producano intenzionalmente transazioni non elaborabili. I nodi possono anche interrompere le connessioni eseguendo la diffusione avversaria delle transazioni non valide della fase 1.
Fase 2
La seconda fase della convalida esegue gli script di Plutus, che possono essere più costosi dal punto di vista computazionale. Pertanto, le tariffe sono addebitate a seguito di un successo o di un fallimento nella seconda fase. L’ada raccolto va nel piatto delle tariffe, e quindi compensa i nodi per le risorse utilizzate nel processo di convalida.
Il successo della convalida della fase-1 non garantisce che tutte le azioni della transazione siano processabili, ma solo che la raccolta della garanzia sia possibile. La fase-2 esegue la convalida dello script Plutus, e la decisione se eseguire l’elaborazione completa o solo raccogliere le garanzie viene presa in base al risultato della convalida:
- applicare completamente la transazione (l’unica possibilità prima di Alonzo) - se gli script Plutus convalidano tutte le azioni della transazione, oppure
- raccogliere la garanzia ada e ignorare il resto della transazione - se uno degli script Plutus fallisce.
Ricordiamo che la convalida degli script ha un risultato localmente prevedibile ed è garantita per terminare. Gli utenti possono controllare localmente i risultati della validazione degli script, e non ci sarà disaccordo tra i nodi onesti su come elaborare una data transazione e gli script in essa contenuti.
Collaterale
Se gli script non convalidano, abbiamo ancora bisogno di compensare i nodi per il loro lavoro. Ma non possiamo semplicemente prendere i soldi dagli input della transazione, perché quelli potrebbero essere stati bloccati con gli script - quelli che hanno fallito! Così, invece, Alonzo introduce una disposizione speciale per questo. La garanzia di una transazione è l’ammontare di ada che sarà raccolto come tassa in caso di fallimento della validazione di uno script di fase 2. In una transazione processabile, questo importo deve essere almeno una certa percentuale della tassa di transazione, specificata in un parametro di protocollo.
Questo importo è specificato al momento della costruzione della transazione. Non direttamente, ma aggiungendo input collaterali alla transazione. Il saldo totale nelle UTXO corrispondenti a questi input appositamente contrassegnati è l’importo collaterale della transazione. Queste UTXO devono avere indirizzi a chiave pubblica (piuttosto che script) e non contenere altri token oltre ad ada.
Gli input collaterali vengono rimossi dal ledger UTXO solo se uno script fallisce la validazione della fase 2. Se tutti gli script passano, l’importo della tassa di transazione specificato viene raccolto, come nelle ere precedenti. In particolare, l’importo proviene dagli input regolari, non collaterali, e gli input collaterali vengono semplicemente ignorati. E, buone notizie! È permesso usare gli stessi input sia come collaterale che regolare, dato che solo uno dei due set viene rimosso dall’UTXO.
Le firme richieste per convalidare la spesa degli input collaterali giocano anche un ruolo importante nel mantenere l’integrità di una transazione. Lo fanno impedendo agli avversari di alterarne il contenuto in modo che continui ad essere processabile, ma non superi la convalida della fase 2. Un esempio di questo potrebbe essere un avversario che sostituisce un redentore. Le firme dei detentori delle chiavi collaterali sono necessarie per effettuare un tale cambiamento. I detentori di chiavi collaterali sono anche gli unici utenti che rischiano di perdere qualsiasi ada se la validazione dello script fallisce.
Poiché la valutazione dello script è deterministica, i detentori delle chiavi collaterali sono in grado di controllare localmente se la transazione passerà la convalida della fase 2 sulla catena prima di firmarla. Se lo fa, allora possono essere sicuri che lo farà anche sulla catena, e sicuramente non perderanno la loro garanzia. Un utente che agisce in buona fede non dovrebbe mai perdere il suo collaterale. Significa anche che possono riutilizzare gli stessi input di collaterale per transazioni multiple, ed essere sicuri che il collaterale non venga ritirato.
Ora che abbiamo lanciato il testnet pubblico di Alonzo, invitiamo tutti gli utenti e gli sviluppatori a valutarlo costruendo ed eseguendo gli script di Plutus. Puoi trovare maggiori informazioni nel repository dedicato di Alonzo testnet, o discutere gli argomenti di Plutus e Alonzo con la nostra diversa comunità.