Lungo articolo di Vitalik: il gioco di uscita degli EVM Validiums e il ritorno di Plasma

Plasma ci permette di aggirare completamente il problema della disponibilità dei dati, riducendo notevolmente le commissioni di transazione.

Autore: Vitalik Buterin

Traduzione: jk, Odaily

 

Plasma è una classe di soluzioni di scalabilità per blockchain che consente di mantenere tutti i dati e i calcoli (eccetto depositi, prelievi e radici Merkle) off-chain. Questo apre la porta a una scalabilità enorme non limitata dalla disponibilità dei dati on-chain. Plasma è stato proposto per la prima volta nel 2017 e ha subito numerose iterazioni nel 2018, in particolare Minimal Viable Plasma, Plasma Cash, Plasma Cashflow e Plasma Prime. Sfortunatamente, a causa di (i) elevati costi di archiviazione dei dati lato client e (ii) limitazioni fondamentali di Plasma che ne rendono difficile l’adozione oltre i pagamenti, Plasma è stato in gran parte sostituito dai rollup.

 

L’emergere delle prove di validità (note anche come ZK-SNARKs) ci dà motivo di riconsiderare questa decisione. La sfida più grande per far funzionare Plasma nei pagamenti, ovvero l’archiviazione dei dati lato client, può essere efficacemente risolta tramite le prove di validità. Inoltre, le prove di validità offrono una serie di strumenti che ci permettono di creare catene simili a Plasma che eseguono l’EVM. Le garanzie di sicurezza di Plasma non coprono tutti gli utenti, poiché il motivo fondamentale per cui il meccanismo di uscita in stile Plasma non si estende a molte applicazioni complesse persiste. Tuttavia, in pratica, è ancora possibile proteggere una percentuale molto ampia di asset.

 

Di seguito, illustrerò in dettaglio come Plasma riesce a ottenere questo risultato.

 

Panoramica: come funziona Plasma

La versione più semplice di Plasma da comprendere è Plasma Cash. Plasma Cash funziona trattando ogni singolo token come un NFT indipendente e tracciando una storia separata per ciascun token. La catena Plasma ha un operatore responsabile della creazione e della pubblicazione periodica dei blocchi. Ogni transazione in un blocco è memorizzata come un albero Merkle sparso: se una transazione trasferisce la proprietà del token k, essa appare nella posizione k dell’albero. Quando l’operatore Plasma crea un nuovo blocco, pubblica la radice dell’albero Merkle on-chain e invia direttamente a ciascun utente il ramo Merkle corrispondente ai token che possiede.

 

 

Supponiamo che questi siano gli ultimi tre alberi delle transazioni nella catena Plasma Cash. Quindi, assumendo che tutti gli alberi precedenti siano validi, sappiamo che attualmente Eve possiede il token 1, David possiede il token 4 e George possiede il token 6.

 

Il rischio principale in qualsiasi sistema Plasma è il comportamento scorretto dell’operatore. Questo può avvenire in due modi:

 

1. Pubblicazione di blocchi non validi (ad esempio, l’operatore include una transazione che trasferisce il token 1 da Fred a Hermione, anche se Fred non possedeva quel token in quel momento);

 

2. Pubblicazione di blocchi non disponibili (ad esempio, l’operatore non invia uno dei suoi rami Merkle a Bob, impedendogli di dimostrare ad altri che il suo token è ancora valido e non speso).

 

Se il comportamento dell’operatore riguarda gli asset di un utente, l’utente è responsabile di uscire immediatamente (specificamente, entro 7 giorni). Quando un utente (“uscente”) esce, fornisce un ramo Merkle che prova l’inclusione della transazione che trasferisce il token dal precedente proprietario a lui. Questo avvia un periodo di contestazione di 7 giorni, durante il quale altri possono contestare l’uscita fornendo una delle seguenti tre prove Merkle:

 

1. Proprietario non aggiornato: una transazione successiva firmata dall’uscente che trasferisce il token a qualcun altro;

 

2. Doppio pagamento: una transazione che trasferisce il token dal precedente proprietario a qualcun altro, inclusa prima della transazione che trasferisce il token all’uscente;

 

3. Storia non valida: una transazione che trasferisce il token negli ultimi 7 giorni senza la corrispondente spesa. L’uscente può rispondere fornendo la spesa corrispondente; se non lo fa, l’uscita fallisce.

 

 

Secondo queste regole, chiunque possieda il token k deve vedere tutti i rami Merkle nella posizione k di tutti gli alberi storici dell’ultima settimana, per assicurarsi di possedere effettivamente il token k e poterlo ritirare. Deve memorizzare tutti i rami che includono i trasferimenti di asset, così da poter rispondere alle contestazioni ed uscire in sicurezza con i propri token.

 

Estensione ai token fungibili

Il design sopra descritto si applica ai token non fungibili (NFT). Tuttavia, i token fungibili come ETH e USDC sono più comuni degli NFT. Un modo per applicare Plasma Cash ai token fungibili è trattare ogni piccolo taglio di token (ad esempio 0,01 ETH) come un NFT separato. Sfortunatamente, se facciamo così, il costo del gas per l’uscita sarebbe troppo alto.

 

Una soluzione è ottimizzare il sistema trattando molteplici token adiacenti come un’unità, che può essere trasferita o ritirata in una sola volta. Ci sono due modi per farlo:

 

1. Utilizzare Plasma Cash quasi invariato, ma con algoritmi complessi per calcolare molto rapidamente l’albero Merkle di molti oggetti, se molti oggetti adiacenti sono uguali. Sorprendentemente, non è difficile da realizzare; qui puoi vedere un’implementazione in Python.

 

2. Utilizzare Plasma Cashflow, che rappresenta semplicemente molti token adiacenti come un singolo oggetto.

 

Tuttavia, entrambi i metodi incontrano il problema della frammentazione: se ricevi 0,001 ETH da centinaia di persone che comprano il caffè, avrai 0,001 ETH in molte posizioni dell’albero, quindi per ritirare effettivamente questi ETH dovrai comunque presentare molte uscite separate, rendendo il costo del gas troppo elevato. Sono stati sviluppati protocolli di deframmentazione, ma sono piuttosto complessi da implementare.

 

Un altro approccio è ridisegnare il sistema considerando un modello più tradizionale di “output di transazione non speso” (UTXO). Quando esci con un token, devi fornire la storia di quel token dell’ultima settimana, e chiunque può contestare la tua uscita dimostrando che uno di quei token storici è già stato ritirato.

 

 

Il prelievo dell’UTXO da 0,2 ETH in basso a destra può essere annullato mostrando il prelievo di uno qualsiasi degli UTXO nella sua storia, come indicato in verde. Si noti in particolare che gli UTXO in basso a sinistra e al centro sinistra sono antenati, ma quello in alto a sinistra non lo è. Questo metodo è simile al concetto di colorazione basata su sequenza nei protocolli di colored coin intorno al 2013.

 

Ci sono diverse tecniche per realizzare questo obiettivo. In tutti i casi, l’obiettivo è tracciare una sorta di concetto di “stesso token” in diversi punti della storia, per impedire che “lo stesso token” venga ritirato due volte.

 

Le sfide dell’estensione all’EVM

Sfortunatamente, estendere questo modello all’EVM oltre i pagamenti è molto più difficile. Una sfida chiave è che molti oggetti di stato nell’EVM non hanno un “proprietario” chiaro. La sicurezza di Plasma dipende dal fatto che ogni oggetto abbia un proprietario, responsabile di monitorare e garantire la disponibilità dei dati on-chain e di uscire dall’oggetto in caso di problemi. Tuttavia, molte applicazioni Ethereum non funzionano così. Ad esempio, le pool di liquidità di Uniswap non hanno un singolo proprietario.

 

Un’altra sfida è che l’EVM non cerca di limitare le dipendenze. Nel blocco N, l’ETH detenuto nell’account A può provenire da qualsiasi punto del blocco N-1. Per uscire da uno stato coerente, una catena Plasma EVM dovrebbe avere un meccanismo di uscita in cui, nel caso estremo, chi vuole uscire con le informazioni del blocco N potrebbe dover pagare il costo di pubblicare l’intero stato del blocco N on-chain: costi che possono arrivare a milioni di dollari. Gli schemi Plasma basati su UTXO non hanno questo problema: ogni utente può uscire con i propri asset dall’ultimo blocco di cui possiede i dati.

 

La terza sfida è che le dipendenze illimitate nell’EVM rendono difficile avere incentivi coerenti per la prova di validità. La validità di qualsiasi stato dipende da tutto il resto, quindi per provare qualsiasi cosa bisogna provare tutto. In questo caso, a causa dei problemi di disponibilità dei dati, spesso non è possibile rendere la risoluzione dei fallimenti compatibile con gli incentivi. Un problema particolarmente fastidioso è che perdiamo la garanzia presente nei sistemi basati su UTXO, secondo cui lo stato di un oggetto non può essere modificato senza il consenso del proprietario. Questa garanzia è molto utile perché significa che il proprietario conosce sempre lo stato più recente e dimostrabile dei propri asset e semplifica il meccanismo di uscita. Senza di essa, creare un meccanismo di uscita diventa molto più difficile.

 

Come le prove di validità alleviano questi problemi

La funzione più basilare delle prove di validità è dimostrare on-chain la validità di ogni blocco Plasma. Questo semplifica notevolmente lo spazio di progettazione: significa che dobbiamo preoccuparci solo degli attacchi di blocchi non disponibili da parte dell’operatore, non di blocchi non validi. Ad esempio, in Plasma Cash, elimina la preoccupazione per le contestazioni storiche. Questo riduce la quantità di stato che gli utenti devono scaricare, da un ramo per ogni blocco dell’ultima settimana a un ramo per ogni asset.

 

Inoltre, l’estrazione dallo stato più recente (nel caso comune in cui l’operatore sia onesto, tutte le estrazioni avverranno dallo stato più recente) non è soggetta a contestazioni da parte di proprietari non aggiornati, quindi in una catena Plasma con prove di validità, tali estrazioni non saranno soggette ad alcuna contestazione. Questo significa che, in condizioni normali, i prelievi possono avvenire immediatamente.

 

Estensione all’EVM: grafico UTXO parallelo

Nel caso dell’EVM, le prove di validità ci permettono anche di fare cose intelligenti: possono essere usate per implementare un grafico UTXO parallelo per ETH e token ERC 20, e usare SNARK per dimostrare l’equivalenza tra il grafico UTXO e lo stato EVM. Una volta ottenuto questo, puoi implementare un sistema Plasma “regolare” sul grafico UTXO.

 

 

Questo ci permette di aggirare molte delle complessità dell’EVM. Ad esempio, in un sistema basato su account, qualcuno può modificare il tuo account senza il tuo consenso (inviandoti token e aumentando il saldo), ma questo non è importante perché Plasma non si basa sullo stato EVM stesso, ma su uno stato UTXO parallelo all’EVM, dove qualsiasi token ricevuto sarà un oggetto indipendente.

 

Estensione all’EVM: uscita dallo stato completo

Esistono già soluzioni più semplici proposte per creare una “Plasma EVM”, come Plasma Free, e prima ancora questo articolo del 2019. In questi schemi, chiunque può inviare un messaggio su L1, costringendo l’operatore a includere una transazione o a rendere disponibile un ramo di stato specifico. Se l’operatore non lo fa, la catena inizia a fare rollback dei blocchi. Una volta che qualcuno pubblica una copia completa dello stato, o almeno tutti i dati che gli utenti hanno segnalato come potenzialmente mancanti, la catena smette di fare rollback. Per effettuare prelievi potrebbe essere necessario pubblicare una ricompensa, che pagherà la quota di gas dell’utente a chi pubblica una così grande quantità di dati.

 

Schemi come questi hanno una debolezza: non consentono prelievi istantanei in condizioni normali, perché c’è sempre la possibilità di dover fare rollback allo stato più recente.

 

Limitazioni degli schemi Plasma EVM

Schemi di questo tipo sono potenti, ma non possono offrire garanzie di sicurezza complete a tutti gli utenti. Il caso di fallimento più evidente è quando oggetti di stato specifici non hanno un “proprietario” economico chiaro.

 

Consideriamo il caso di un CDP (Collateralized Debt Position), uno smart contract in cui gli utenti bloccano token che possono essere rilasciati solo dopo aver rimborsato il debito. Supponiamo che un utente abbia bloccato 1 ETH in un CDP (circa 2000 dollari al momento della scrittura) e abbia un debito di 1000 DAI. Ora, la catena Plasma smette di pubblicare blocchi e l’utente si rifiuta di uscire. L’utente può semplicemente non uscire mai. Ora, l’utente ha un’opzione gratuita: se il prezzo di ETH scende sotto i 1000 dollari, abbandona il CDP; se il prezzo di ETH rimane sopra i 1000 dollari, alla fine lo reclama. In media, un utente malintenzionato guadagnerà da questa situazione.

 

Un altro esempio sono i sistemi di privacy, come Tornado Cash o Privacy Pools. Consideriamo un sistema di privacy con cinque depositanti:

 

 

Gli ZK-SNARKs nei sistemi di privacy mantengono nascosto il collegamento tra il proprietario dei token in entrata e il proprietario dei token in uscita dal sistema.

 

Supponiamo che solo l’arancione abbia già prelevato, e a questo punto l’operatore della catena Plasma smette di pubblicare dati. Supponiamo che usiamo un metodo di grafico UTXO con regola FIFO, quindi ogni token è abbinato al token sottostante. In tal caso, l’arancione può prelevare sia il token pre-mix che quello post-mix, e il sistema li considererà come due token indipendenti. Se il blu tenta di prelevare il proprio token pre-mix, lo stato aggiornato dell’arancione lo sostituirà; allo stesso tempo, il blu non avrà informazioni per prelevare il proprio token post-mix.

 

Se permetti agli altri quattro depositanti di prelevare direttamente dal contratto di privacy (che sostituirà i depositi) e poi ritirare i token su L1, il problema può essere risolto. Tuttavia, implementare effettivamente un tale meccanismo richiede uno sforzo aggiuntivo da parte degli sviluppatori del sistema di privacy.

 

Esistono altri metodi per risolvere i problemi di privacy, come il metodo Intmax, che prevede di mettere alcuni byte on-chain in stile rollup e un operatore simile a Plasma che trasmette le informazioni tra gli utenti.

 

Le posizioni LP di Uniswap presentano problemi simili: se hai scambiato ETH con USDC in una posizione Uniswap, puoi tentare di prelevare sia gli USDC prima dello scambio che gli ETH dopo lo scambio. Se colludi con l’operatore della catena Plasma, i fornitori di liquidità e altri utenti non potranno accedere allo stato post-scambio, quindi non potranno prelevare i loro USDC dopo lo scambio. È necessaria una logica speciale per prevenire questa situazione.

 

Conclusione

Anche nel 2023, Plasma rimane un design sottovalutato. I rollup sono ancora lo standard d’oro e hanno proprietà di sicurezza impareggiabili. Questo è particolarmente vero dal punto di vista dell’esperienza degli sviluppatori: nulla è paragonabile alla semplicità per cui gli sviluppatori di applicazioni non devono nemmeno considerare la struttura della proprietà e il flusso degli incentivi nelle loro applicazioni.

 

Tuttavia, Plasma ci permette di aggirare completamente il problema della disponibilità dei dati, riducendo notevolmente le commissioni di transazione. Per quelle catene che sarebbero validium, Plasma può rappresentare un importante miglioramento della sicurezza. ZK-EVMs sono finalmente diventati realtà quest’anno, offrendo un’opportunità eccezionale per riesplorare questo spazio di progettazione e proporre modalità di costruzione più efficienti, semplificando l’esperienza degli sviluppatori e proteggendo i fondi degli utenti.

Un ringraziamento speciale a Karl Floersch, Georgios Konstantopoulos e Martin Koppelmann per i loro contributi in termini di feedback, revisione e discussione.