Episodio IV: Le Soluzioni di Scalabilità

Come si può rendere più veloce ed economica l’operatività su una rete attualmente costosa e relativamente lenta come Ethereum?

Scalabilità delle blockchain: gli Optimistic Rollups.

Ti sei mai chiesto perchè gli utenti amano utilizzare la DeFi su Arbitrum? Sei curioso di sapere che cosa succede dietro le quinte di Optimism? Vuoi sapere come MetisDAO tiene al sicuro i suoi $ETH?

Buona lettura!

Nel 2008, la finanza moderna (la finanza tradizionale) fallì.

Mentre Satoshi guardava il mondo (finanziario) andare a rotoli, ebbe un’intuizione: @bitcoin.

7 anni dopo, @VitalikButerin ha mantenuto la promessa che Satoshi per primo ci aveva fatto: @ethereum nacque.

Ethereum è un computer globale, caratterizzato da un utilità decentralizzata ed internazionalmente condivisa. Sfortunatamente, questo computer è lento… o perlomeno, era nato lento.
Fortunatamente, abbiamo Soluzioni di Scalabilità!

Il primo gruppo di Soluzioni di Scalabilità è chiamato “state channels”, letteralmente “canali di stato”.
Per aprire un canale, gli utenti depositano i loro fondi in uno smart contract apposito che li custodisce e gestisce a patto che vi sia un deposito in garanzia direttamente on-chain.
I partecipanti possono effettuare off-chain, attraverso questo canale, quante transazioni vogliono. Una volta concluse tutte le operazioni, lo smart contract chiude il canale ed aggiorna i bilanci.

[Per ulteriori approfondimenti sugli state channels, scrivetemi nei commenti!]

Gli state channels sono uno strumento potente, ma soffrono anche di limitazioni rilevanti:

• i partecipanti devono aderire, dunque non si può trasferire valore ad un indirizzo che non è entrato nel canale
• richiedono un grande capitale inziale bloccato, che viene usato come garanzia per “collateralizzare” i vari scambi (il deposito in garanzia di cui abbiamo parlato prima)
• non può rappresentare oggetti senza un esplicito proprietario, per esempio una dApp come Uniswap.

La soluzione successiva è stata creata con l’intento di risolvere alcune di queste debolezze.
Plasma (dette anche plasma blockchain) sono blockchain indipendenti ancorate alla rete principale, Ethereum.

[Per ulteriori approfondimenti riguardo a plasma, scrivetemi nei commenti!]

Proprio come Ethereum, una blockchain plasma gode di un proprio stato della macchina virtuale (stato e bilancio indipendenti di ogni utente, smart contracts propri).

Questo stato può essere espresso con un Merkle Tree.

(Il Merke Tree è una struttura di dati che consente di comprimere una grande quantità di dati in una singola riga, chiamata Merkle Root)

Ad ogni intervallo stabilito, la chain plasma costruirà lo stato della blockchain con il Merkle Tree e lo pubblicherà sulla chain di riferimento (mainnet) sotto forma di Merkle Root. Dunque, su Ethereum troveremo una “registrazione” compressa dell’intero stato della blockchain plasma in quell’istante.
Per prelevare fondi dalla blockchain plasma, l’utente presenta la “Merkle proof” (prova Merkle) di detenzione per quell’asset che vuole prelevare.

Nonostante la soluzione plasma offra sicuramente dei miglioramenti rispetto agli state channels, soffre di una grande debolezza: richiede sempre dell’impegno/coinvolgimento nella proprietà e nella gestione degli asset lato utente.
Se un utente “non si preoccupa”* nella gestione dei propri asset, allora potrebbe venire emesso un risultato “non valido” per quanto riguarda quell’asset.
Di conseguenza, l’implementazione di un DEX o di una qualsiasi dApp diventa molto complessa.

Ma c’è un problema ancora più grande: la (in)disponibilità di dati.

Le chain plasma salvano lo stato del Merkle Root sulla mainnet, ma non le transazioni che hanno portato a quello stato. Di conseguenza, non certificherebbero nemmeno l’esistenza eventuali transazioni maligne.

Quindi?

Quindi i rollups sono la soluzione: viene salvato tutto in mainnet, singole transazioni comprese.

Quando gli utenti interagiscono con un optimistic rollup, depositano i loro fondi in uno smart contract su Ethereum. L’operatore del rollup minta il valore equivalente di asset sulla chain dell’optimistic rollup e lo consegna al’utente che, in questo caso, ha depositato.
Nel frattempo, sulla mainnet gli asset rimangono come depositati in garanzia, “a collaterale”.
Dal momento che i rollups si affidano ad Ethereum per quanto riguarda la decentralizzazione e la struttura, il rollup in sé (col suo operatore) può essere molto più centralizzato.

Lato utente, i tempi ed i costi vengono notevolmente ridotti se comparati con la mainnet di Ethereum.

Dunque. Rollup e Plasma sono fondamentalmente la stessa cosa. In entrambi i casi parliamo di blockchain centralizzate ad alta prestazione, legate ad Ethereum attraverso smart contract che gestiscono i depositi in garanzia e le operazioni effettuate al di fuori della mainnet.

Plasma pubblica il Merkle Root sulla mainnet una volta ad ogni intervallo, documentanto lo stato della rete. E poi si ferma qui.

Ricordiamo che il Merkle Root è una singola riga che può essere utilizzata per provare l’esistenza di una transazione.

Nel caso dei plasma, è però possibile solamente confermare che una transazione sia stata inserita all’interno del Merkle Tree. Non è invece possibile cercare le transazioni in un Merkle Tree partendo dal Merkle Root (dalla Radice).

Durante operazioni ed operatività normali, ciò non rappresenta un problema. Ogni qualvolta che l’operatore Plasma pubblica un nuovo Merkle Root, si inviano anche i rami del Merkle necessari al proprietario degli asset.
Gli utenti devono affidarsi all’operatore se hanno bisogno di fornire informazioni per dimostrare ad esempio delle truffe.

Ma cosa succederebbe se un giorno l’operatore semplicemente si fermasse?
Oppure, sappiamo ad esempio che un operatore malevolo potrebbe con facilità creare una transazione fittizia e nascondere le informazioni necessarie per provare la frode.

Ciò non sarebbe possibile se all’operatore fosse richiesto di riportare tutte le transazioni consultabili in modo trasaparente direttamente sulla mainnet.
Per questo, i rollups sono la soluzione al problema della mancanza di dati delle chain plasma.

Pubblicando tutte le informazioni on-chain è possibile verificare le operazioni avvenute all’interno dei rollup. Diventa anche possibile rilevare incongruenze ed operare in trasparenza sulla completezza dei dati.
Gli operatori pubblicano un batch (gruppo) di transazioni nel contratto, inclusi Merkle Root precedente e successivo.
Il contratto verifica che il Merkle Root precedente inserito sia corretto. Se coincide, sostituisce il Merkle Root con il successivo.

In altre parole, aggiorna lo stato, che viene rappresentato dal Merkle Root (come nel modello plasma). Ma in più vengono pubblicate anche le transazioni

Ma perchè? Cosa si risolve così?

Capiamolo assieme.

In questo modo, tutti hanno la possibilità di verificare l’integrità e la correttezza di ciò che viene pubblicato. Ecco perchè:

1. Il Merkle Root precedente che coincide conferma che lo stato di partenza della rete a cui sono state effettuate le modifiche è lo stato corretto.

2. Tutte le operazioni avvenute nell’intervallo fra un Merkle Root ed il successivo sono pubbliche, salvate in mainnet e dunque verificabili.
Volendo, si può quindi anche verificare che dal Merkle Root di partenza + le transazioni avvenute “risulti” il Merkle Root finale.

3. Il Merkle Root alla fine delle operazioni serve per permettere all’operatore, nel prossimo intervallo, di confermare lo stato della rete da cui a sua volta è “partito a modificare”, e così di “ricominciare il ciclo”.

I rollups scalano Ethereum in due modi:

- in primo luogo, spostando parte della computazione su una chain più efficiente in termini di prestazioni e costi.

- inoltre, pubblicano le transazioni sempre in mainnet ma in forma molto compressa, ottimizzando le gas fee.

Ma rimane una questione da risolvere: come fa lo smart contract a sapere che i Merkle Root inseriti dall’operatore sono corretti?

Un OPTIMISTIC rollup parte dal presupposto che le transazioni siano corrette, ma lascia aperto un “challenge period”.

Il “challenge period” è una finestra di tempo in cui chiunque riscontri delle frodi da parte dell’operatore può “confutare l’asserzione” (informazioni date dall’operatore) e provare il comportamento malevolo. In questo modo, le transazioni dovrebbero essere rifiutate.
Pertanto, il rollup presuppone un comportamento onestamente collaborativo da parte degli operatori ma si basa comunque su incentivi per gli attori corretti del network al fine di mantenere l’integrità della rete.

Per prelevare i propri fondi, un utente invia allo smart contract un messaggio per inizializzare il processo di prelievo. Questa operazione modifica lo stato del rollup e questo nuovo stato viene rappresentato con il Merkle Tree e pubblicato on chain.
Una volta trascorso il “challenge period”, durante il quale la correttezza delle transazioni può essere messa in discussione, la transazione viene finalizzata ed il prelievo portato a termine.

Rollups e Plasma sono sviluppati sullo stesso concetto di base: alleggerire la chain principale eseguendo operazioni off chain, mentre si tiene costantemente aggiornato lo stato del newtork salvandolo su Ethereum.

Ma i rollups fanno un gran passo oltre, risolvendo il problema dell’indisponibilità dei dati di cui soffrono le chain plasma.

Il risultato più importante che raggiungono è il fatto che gli asset non richiedono più di essere posseduti da un proprietario.

I rollup possono dunque eseguire un EVM.

Un rollup EVM-compatibile o una soluzione equivalente rappresenta Il Sogno: tutte le caratteristiche di Ethereum ma più economiche e più veloci.

Ma possiamo ancora fare di meglio!

E se invece che essere ottimisti (“optimistic” rollups perchè presuppongono la correttezza delle informazioni fornite) volessimo avere un riscontro immediato delle nostre transazioni, senza “challenge period”?

Alla prossima puntata (lol)!

ZK è un indizio.

Se vi è piaciuto questo contenuto, potete retweettare il primo Tweet di questo Thread o anche solo mettere qualche applauso a questo articolo. Mi aiuta ad arrivare a più persone ed a voi costa poco o niente.

This article was inspired by @SalomonCrypto. It is a re-adaptation and @SalomonCrypto is not responsible for what I wrote. I thank @SalomonCrypto for the excellent idea and the very clear and understandable content.

Link to his Thread below:
https://twitter.com/SalomonCrypto/status/1569023606029697024?s=20&t=s0dSvgkBPr-dcj8HS6PYuQ

Per oggi è tutto. Spero abbiate trovato interessante questa panoramica relativa alla potenziale integrazione della blockchain in un sistema economico tradizionale. Se è stato così, non dimenticate di commentare qui sotto, seguirmi su tutti i miei social che vi lascio qui sotto e di non perdervi i prossimi approfondimenti!

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