Traduzione italiana di EUTxO Model Offers Determinism to Users
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
Il modello EUTxO offre determinismo agli utenti
Dal punto di vista degli sviluppatori di applicazioni, il modello UTxO è fondamentalmente diverso dal modello basato sugli account. Il modello basato sugli account è semplice e offre agli sviluppatori un’elevata flessibilità, soprattutto se è necessario definire una logica di esecuzione complessa. Tuttavia, l’eccessiva flessibilità va a scapito delle garanzie di esecuzione, con conseguenti vulnerabilità del sistema e attacchi. Lavorare con il modello UTxO è più complicato, ma offre agli sviluppatori (e quindi agli utenti) diversi vantaggi, in particolare il determinismo.
Spieghiamolo in dettaglio.
Il modello UTxO dal punto di vista delle transazioni
Nel caso del modello UTxO, una transazione può essere percepita come una funzione che consuma uno o più UTxO in ingresso e produce uno o più UTxO in uscita.
Gli UTxO che entrano nella transazione sono immutabili e, come mostreremo in seguito, dal punto di vista dell’utente dell’applicazione è possibile garantire un accesso esclusivo. Durante la convalida della transazione, si garantisce che il valore degli UTxO in ingresso sia uguale al valore di tutti gli UTxO in uscita. A livello di convalida di tutte le transazioni nel blocco, è possibile garantire la protezione contro un attacco double-spend, poiché ogni UTxO in ingresso può essere consumato solo una volta e completamente. Ogni nuovo blocco aggiunto al libro mastro definisce una transizione di stato per quanto riguarda la proprietà degli UTxO.
Le transazioni sono intrinsecamente stateless. La convalida della transazione dipende essenzialmente solo dagli UTxO in ingresso. È possibile verificare localmente che gli UTxO in ingresso possano essere spesi da una transazione (cioè utilizzati). La transizione di stato è verificabile localmente senza dipendere da nessun altro stato globale della catena.
È possibile prevedere localmente come una transazione influenzerà lo stato on-chain. In altre parole, la logica fuori dalla catena (utente o applicazione) può assicurarsi che la transazione non fallisca se viene inviata alla rete.
Una transazione non fallirà quasi mai se l’utente (o l’agente) ha il diritto esclusivo di spendere l’UTxO in ingresso. Questo è il caso in cui Alice invia monete o gettoni a Bob dal proprio portafoglio. L’UTxO in ingresso non può essere speso da nessun altro.
Esaminiamo l’unica possibilità in cui una transazione può fallire. Questo è fondamentalmente limitato al caso in cui più agenti possono spendere lo stesso UTxO. Come mostreremo più avanti, questo può essere il caso delle pool di liquidità.
Nell’immagine si può vedere come due agenti stiano cercando di costruire una transazione. Entrambi gli agenti hanno l’ultimo stato corretto del libro mastro. Per coincidenza, hanno scelto lo stesso input UTxO. La convalida locale fuori dalla catena avrà successo. Entrambi gli agenti inviano quindi la transazione alla rete e presumono che anche la convalida on-chain della transazione avrà successo.
Tuttavia, ogni UTxO può essere speso solo una volta. Pertanto, solo una transazione avrà successo e l’altra fallirà.
Nell’immagine sottostante, si può notare che nel blocco seguente solo la transazione 1 è arrivata al libro mastro. La transazione 2 è fallita.
Come abbiamo già spiegato, questo stato può verificarsi solo se gli utenti utilizzano un’applicazione in cui gli UTxO sono condivisi.
Immaginiamo ora un normale exchange decentralizzato (DEX) che utilizza diversi pool di liquidità. Ogni pool di liquidità può essere visto come un insieme contenente diversi UTxO con valori diversi. Gli utenti che inviano transazioni per effettuare swap vogliono essenzialmente ottenere una parte della liquidità (token) che si trova nel pool di liquidità. In pratica, vogliono ottenere uno o più UTxO dal pool di liquidità. In altre parole, gli utenti possono presentare transazioni di swap (quasi) in parallelo e competere per la liquidità.
Il punto chiave è la selezione degli UTxO in ingresso per le transazioni. Gli agenti devono sincronizzarsi tra loro per evitare che le transazioni falliscano.
Cardano permette teoricamente di costruire un’applicazione che garantisca che le transazioni degli utenti non falliscano mai. La logica applicativa fuori dalla catena (agenti) deve sincronizzarsi tra loro. Grazie a ciò, è possibile prenotare uno specifico UTxO dal pool di liquidità condiviso prima di inviare la transazione. In altre parole, la convalida locale off-chain può garantire che una transazione quasi certamente non fallirà.
Nell’immagine sottostante, si può notare che esiste una sincronizzazione reciproca fuori catena tra gli agenti prima della convalida locale delle transazioni. Ogni agente riserva un UTxO diverso, quindi è molto probabile che entrambe le transazioni inviate superino la convalida sulla catena.
Naturalmente, funzionerà solo se è possibile prenotare UTxO. Può anche accadere che non sia disponibile alcun UTxO adatto quando l’utente tenta di inviare una transazione. In questo caso, è possibile aspettare (e non inviare la transazione), oppure correre il rischio e aspettare che non appaia un UTxO adatto in seguito. I dettagli dipendono dalla specifica implementazione di DEX e dall’interfaccia utente.
Il modello EUTxO contribuisce alla sicurezza e alla natura deterministica di Cardano. In questo modello, le transazioni non dipendono dai conti o dai saldi degli utenti come nel caso di un modello basato sui conti, ma piuttosto solo dagli UTxO coinvolti nella transazione. Ciò significa che per una determinata transazione sono importanti solo gli UTxO coinvolti e non gli account utente, che hanno una natura globale.
Nel modello UTxO, il saldo di un conto specifico è fondamentalmente solo un elenco di UTxO agli indirizzi appartenenti a un proprietario.
Perché il modello basato sugli account è indeterministico
Le blockchain basate sugli account sono indeterministiche poiché l’effetto di una transazione sul libro mastro è imprevedibile. Il motivo è che gli account utente sono intrinsecamente mutevoli.
Nella blockchain basata sui conti, una transazione può essere vista come una funzione che modifica i saldi dei conti. Ogni transazione comporta il trasferimento di monete o token da un conto a un altro, modificando i saldi di tali conti.
La convalida delle transazioni dipende dai conti e dai loro saldi. Questo può portare a un comportamento non deterministico, poiché l’esito di una transazione dipende dallo stato della blockchain nel momento esatto in cui viene inclusa in un blocco.
I conti possono essere visti come una risorsa condivisa nel sistema. Questo perché tutte le transazioni vengono elaborate dall’intera rete e ogni transazione può potenzialmente influenzare lo stato di qualsiasi conto del sistema. Questa natura condivisa dei conti è uno dei motivi per cui Ethereum e altre blockchain simili sono considerate blockchain statiche.
Le transazioni in Ethereum possono essere considerate stateful. Lo stato completo di Ethereum descrive lo stato attuale di tutti i conti e i saldi, nonché le memorie collettive di tutti gli smart contract distribuiti e in esecuzione nell’EVM. Lo stato attuale può essere modificato con le transazioni.
Torniamo al nostro esempio in cui due utenti (agenti) stanno cercando di inviare una transazione di swap per ottenere parte della liquidità (token) dal pool di liquidità.
Non è possibile riservare una parte di un saldo specifico per una transazione nello stesso modo in cui si può riservare un UTxO in Cardano. Se la transazione fosse in grado di riservare una parte del saldo dal pool di liquidità e successivamente non fosse inclusa nella blockchain per un lungo periodo (magari a causa di una commissione bassa), bloccherebbe l’esecuzione di ulteriori swap.
In un certo senso, anche le singole applicazioni dipendono l’una dall’altra, poiché l’attività nella rete influisce sul costo del GAS. Il costo del GAS influenza la selezione delle transazioni e il loro ordine nel blocco. Questo porta a un comportamento non deterministico.
Nel modello AMM, i pool di liquidità sono essenzialmente riserve di due o più token bloccati in uno smart contract. Gli utenti commerciano con questi smart contract piuttosto che tra di loro e i tassi sono basati su formule matematiche.
Nell’ecosistema Ethereum, gli utenti competono essenzialmente per l’equilibrio o la liquidità di un determinato pool di liquidità. Quando gli utenti inviano transazioni in parallelo, la rete Ethereum dà priorità alle transazioni in base alle tariffe GAS. Più alta è la tariffa GAS che un utente è disposto a pagare, maggiore è la priorità della sua transazione. Ciò significa che le transazioni con tariffe più elevate saranno elaborate per prime e avranno la prima possibilità di consumare liquidità.
Questa competizione per la liquidità può portare alla cosiddetta GAS WARS, in cui gli utenti superano continuamente le tariffe GAS degli altri nel tentativo di far elaborare le loro transazioni il più rapidamente possibile. Questo è uno dei motivi per cui le commissioni di transazione su Ethereum possono essere talvolta elevate.
Nell’immagine, si può notare che due agenti vogliono consumare lo stesso saldo. Entrambi gli agenti vedono che il saldo è sufficiente per la loro transazione e quindi inviano la transazione all’incirca nello stesso momento. Il primo agente stabilisce una commissione più alta del secondo.
Non è garantito che le transazioni inviate vadano a buon fine, ma gli utenti devono assumersi il rischio e provare a inviarle se vogliono effettuare uno scambio. Una transazione con una tariffa bassa può essere ritardata e altre transazioni con una tariffa più alta possono avere la priorità. Le transazioni con tariffe basse possono successivamente fallire. La commissione verrà addebitata indipendentemente dallo stato finale. L’utente paga quindi per il tentativo di scambio senza avere la garanzia che lo scambio abbia luogo.
Nell’immagine si può notare che solo la transazione 1 è riuscita perché l’agente ha impostato una tariffa più alta. L’operazione 1 ha drenato una tale quantità di liquidità dal pool che l’operazione 2 non ha potuto essere eseguita. Il secondo agente ha dovuto pagare la commissione anche se l’operazione 2 è fallita.
Come già descritto, gli agenti non possono sincronizzarsi tra loro e riservare parte del saldo del pool di liquidità. Gli agenti rispondono solo allo stato valido nel momento in cui cercano di inviare una transazione.
Il non-determinismo è svantaggioso anche dal punto di vista dell’equità, perché offre agli agenti avversari la possibilità di abusare delle vulnerabilità della rete. Sono noti gli attacchi di front-running, in cui i bot scansionano le transazioni nella mem-pool e cercano opportunità adeguate da cui trarre profitto. Se trovano tali transazioni, devono solo inviare una transazione simile con una tariffa più alta.
Nel nostro caso, ciò significherebbe che le transazioni di entrambi gli agenti fallirebbero, poiché l’attaccante prosciugherebbe l’intera liquidità dal pool solo per sé.
Nel caso di Cardano, un attacco simile fallirebbe se esistesse un sistema di prenotazione off-chain in cui gli agenti sarebbero in grado di riservare uno specifico UTxO per se stessi.
Conclusione
Agli sviluppatori piace il modello basato sugli account perché è semplice e facile da usare. Le applicazioni lavorano fondamentalmente solo con i saldi. Tuttavia, l’aspetto negativo è che le transazioni non si comportano in modo deterministico e possono fallire. Ciò è dovuto al fatto che tra il momento in cui l’utente invia la transazione e quello in cui viene eseguita, lo stato globale del sistema, cioè il saldo dei conti, può cambiare.
Il modello UTxO è più complesso da capire e la selezione degli UTxO in ingresso può sembrare un po’ macchinosa. È più facile detrarre un importo da un conto e accreditarlo a un altro conto piuttosto che dover selezionare più UTxO e creare nuovi UTxO di uscita da questi (compresi gli UTxO che restituiscono parte del valore all’indirizzo originale). Gli sviluppatori sono costretti a pensare alle applicazioni tenendo conto della parallelizzazione. Devono occuparsi della sincronizzazione tra gli agenti in modo da evitare problemi di contesa. Dal punto di vista dell’utente, tuttavia, è possibile creare applicazioni che si comportino in modo deterministico. Se la validazione locale off-chain passa, passerà anche la validazione on-chain.