Episodio IV.1: Plasma, il trampolino di lancio per le attuali soluzioni di scalabilità

Nel precedente episodio IV abbiamo approfondito le soluzioni di Scalabilità. Oggi facciamo un salto ed esploriamo meglio una di loro: le chain Plasma.

Plasma: una delle soluzioni per scalare una blockchain. Anzi, la soluzione che, evolvendo gli state channels, ha lanciato una nuova concezione di scalabilità.

Plasma schematicamente

Ricordiamo che gli state channels sono dei canali in cui un gruppo di utenti può scambiarsi valore con fee molto ridotte, perchè ciò che succede all’interno, succede off-chain. On-chain, viene salvata solo la situazione economica iniziale e finale del canale e degli utenti.

Ma torniamo alle Plasma, che dunque evolvono il concetto di state channels in qualcosa di più accessibile, affidabile e sicuro.
Le Plasma sono state le prime soluzioni di scalabilità “persistenti” sviluppate ed ancorate ad Ethereum: sono il precursore delle attuali soluzioni di scalabilità.

Come funziona(va) quindi il (giovane) antenato degli attuali rollups e famiglia, cioè la chain Plasma? 🥖

Partiamo dal capire perchè è nato: il presupposto del loro sviluppo rimane sempre la dolorosa lentezza di Ethereum a pochi anni dalla sua nascita. Nascono dunque per primi gli state channels, come abbiamo detto. Che però soffrono di alcuni problemi:

• tutti i partecipanti devono aderire, non si possono inviare fondi a qualcuno che non “faccia parte” del canale;
• i canali non possono rappresentare oggetti senza un esplicito proprietario (ed esempio Uniswap);
• richiedono un grande capitale per collateralizzare gli scambi.

Così, subentra Plasma, che viene sviluppata proprio per risolvere questi problemi.

Una chain Plasma è una blockchain indipentente e seperata, ancorata ad Ethereum, ma che esegue le transazioni off-chain, secondo un proprio algoritmo di consenso.
Gli utenti operano su una chain Plasma depositando i loro asset direttamente in uno smart contract sulla mainnet Ethereum. A questo punto l’operatore Plasma minta la stessa quantità di asset sulla chain Plasma e la consegna a chi ha depositato.
Sulla mainnet di Ethereum rimane l’asset depositato dall’utente, che funge da collaterale, da deposito in garanzia per ciò che è stato mintato e consegnato sulla Plasma.

Dal momento che la chain Plasma si affida ad Ethereum per quanto riguarda la distribuzione della fiducia, l’operatore Plasma in sé (colui che effettua le operazioni) può essere piuttosto centralizzato (a volte persino una singola entità), ottenendo una performance veloce ed economica.

La chain Plasma è caratterizzata da una propria infrastruttura blockchain, con la propria macchina virtuale ed il proprio stato.
Lo stato della macchina virtuale descrive tutto ciò che si trova all’interno della macchina virtuale stessa: ogni account, smart contract, ogni saldo.

Le chain Plasma (come in realtà anche tutti i “blockchain computer”, quindi Ethereum incluso), conservano il loro stato in un Merkle Tree modificato. A sua volta, un Merkle Tree può essere ridotto ad un singolo hash.

Il Merkle Tree consente una verifica efficiente dell’esistenza di un dato senza aver bisogno di trasferire l’intero insieme di dati. Ad ogni intervallo, l’operatore Plasma raggruppa (batcha) tutte le transazioni avvenute e genera un Merkle Tree che rappresenta lo stato.

In seguito, prima di tutto, l’operatore pubblica sulla mainnet il Merkle Root (il singolo hash in grado di rappresentare lo stato dell’intera chain Plasma).
Dopodichè, l’operatore invia il ramo Merkle ai proprietari dei vari asset, per consentirgli anche la verifica della correttezza.

Quel ramo Merkle servirà all’utente per prelevare gli asset ed “uscire” dalla chain Plasma. Al momento del prelievo, l’utente fornirà il ramo Merkle allo smart contract come prova di essere effettivamente il proprietario dei suoi asset.

Qui ha inizio il periodo di prelievo.

Durante il periodo di prelievo, ognuno può invalidare l’operazione, a patto che fornisca la prova che chi sta cercando di prelevare non è il vero proprietario di quegli asset che sta richiedendo.

Come?

Fornendo un ramo Merkle che provi che chi ha inizializzato quel prelievo non detiene gli asset. In altre parole, un ramo Merkle che dimostri la non veridicità del ramo Merkle fornito per inizializzare il prelievo.

Se il periodo di prelievo si conclude senza che nessuno certifichi la scorrettezza della richiesta di prelievo, l’utente potrà prelevare i fondi.

La più grande differenza fra state channels e Plasma è che le Plasma supportano uno “stato persistente” della chain, ovvero è possibile avere una “fotografia” dello stato della chain mano a meno che viene modificata, indipendentemente da eventuali ingressi ed uscite degli utenti.

Un nuovo canale rappresenta un nuovo stato: una volta chiuso il canale, quello stato viene distrutto.
Lo stato delle Plasma invece esiste all’interno del proprio contesto (la blockchain stessa), anche nel caso in cui gli utenti entrino ed escano. Gli utenti influenzano ma non rappresentano lo stato.

Le chain Plasma forniscono una sicurezza molto più forte degli state channels: una registrazione delle varie operazioni viene salvata sulla mainnet mentre le operazioni stesse sono ancora in corso.

Ciò permette anche di inviare fondi a chi non è ancora entrato a far parte del sistema, a differenza degli state channels che, come sappiamo, richiedono l’adesione di tutti i partecipanti per essere coinvolti anche semplicemente nella ricezione di fondi.

Tuttavia, anche le Plasma scendono ad alcuni compromessi:

• richiedono una manutenzione regolare (e costosa) sulla mainnet
• non supportano prelievi istantanei (bisogna aspettare che l’operatore lo pubblichi in mainnet e che venga concluso l’intero processo)

Le Plasma condividono inoltre la loro più grande debolezza con gli state channels: si affidano entrambe ad una proprietà esplicita e coinvolta nel sistema. Ad esempio, il ramo Merkle deve essere consegnato all’utente dalla Plasma. Ogni asset deve avere un proprietario logico, e se il proprietario non presta abbastanza attenzione ai propri asset, allora i suoi asset diventano vulnerabili.

Questo può essere un compromesso ragionevole per alcune dApp, ma fondamentalmente non può supportare diverse dApp native EVM che non hanno un proprietario esplicito. Le Plasma hanno quindi difficoltà con le dApp che modificano i saldi senza un consenso esplicito (es. pagando interessi).

Questi sono i fattori principali per cui è un impossibile costruire un ecosistema EVM completo in un ambiente Plasma.

Di conseguenza, la community di Ethereum ha approfondito le chain Plasma, arrivando a creare qualcosa di ancora migliore e più evoluto…

i ROLLUPS!

Anche questo articolo è arrivato alla conclusione, grazie a tutti per aver letto! Cosa vorreste che io approfondissi prossimamente? Scrivetemelo qui sotto oppure nei commenti di Twitter.

Se vi è piaciuto, lasciate un like al primo Tweet del mio Thread su Twitter, è gratis per voi ma un grande supporto per me!

Telegram (per Annunci delle pubblicazioni)
Spotify (Podcast) SOON
Twitter
YouTube
LinkedIn