Optimistic Rollup: come funzionano su Ethereum

In questa guida parliamo di Optimistic rollup, una delle soluzioni più promettenti per la scalabilità di Ethereum.

Come sapete la rete Ethereum è in grado di processare poche transazioni al secondo (TPS) anche se fornisce un alto livello attraverso l’esecuzione di transazioni e una validazione che avviene in un ambiente sicuro.

La conseguenza di questa lentezza porta Ethereum a non essere la soluzione ideale per le future applicazioni Web 3, per i pagamenti ed altri settori in forte crescita. Per questo motivo negli ultimi anni sono arrivate le soluzioni di layer 2 per lo scaling di Ethereum, che permetteranno questa blockchain di diventare sempre più efficiente.

I rollup sono una delle soluzioni di Layer 2 in grande crescita su Ethereum e sono destinati probabilmente ad essere la soluzione chiave per la scalabilità di Ethereum 2.0. Ma cos’è un rollup e come funziona questa tecnologia?

In questa guida cercheremo di capire come funzionano i Rollups. Cercheremo inoltre di capire le differenze le due soluzioni tecnologiche principali: Optimistic Rollup e ZK-Rollups e faremo un approfondimento sui rollup di tipo ottimistico.

Perchè Ethereum ha bisogno di soluzioni di scalabilità ?

Come sappiamo, una blockchain moderna, deve essere in grado di assicurare la decentralizzazione e la sicurezza senza scarificare la scalabilità.

Per questo motivo si rende necessario progettare soluzioni di scaling in grado di aumentare l’efficienza di una rete mantenendo comunque un livello di sicurezza accettabile. Oggi ci sono reti molto efficienti che vengono impiegate in vari settori dell’economia come la finanza ed i pagamenti, il gaming e le applicazioni future Web3.

Se pensiamo solo al settore dei pagamenti notiamo come i circuiti tradizionali di pagamento siano in grado di processare migliaia di transazioni per secondo (TPS). In questo caso la sicurezza è garantita da una rete “centralizzata”.

Ma come si risolve il problema in una rete decentralizzata?

Come accennato in precedenza Ethereum può processare in media 15 TPS e ciò costituisce un grosso problema per chi vuole utilizzare la sua blockchain.

Ethereum ha oggi un volume di scambi enorme che porta ad alcuni problemi:

• congestione della rete
• commissioni elevate
• esperienza d’uso negativa da parte degli utenti costretti a pagare costi elevati e ad attese prolungate

In questo contesto si rende necessaria una soluzione per migliorare la scalabiilità e l’efficienza

Generalmente si può scalare una blockchain tramite 2 metodi:

• Soluzioni di scaling layer 1
• Soluzioni di scaling con layer 2

Abbiamo parlato dei layer in un articolo dal titolo “Layer 0,1,2” di come funzionano i livelli e perché sono importanti per una blockchain.

Layer 2 scaling

L’obiettivo principale della scalabilità è quello di incrementare la velocità delle transazioni e il throughput delle transazioni (TPS), senza sacrificare la decentralizzazione o la sicurezza.

Per raggiungere questo obiettivo Ethereum utilizza i layer 2, ovvero protocolli costruiti sulla blockchain esistente (Ethereum layer 1) ad un livello superiore per per migliorare la velocità e dunque raggiungere la scalabilità.

Un layer 2 invece viene costruito sulla blockchain esistente e rappresenta una soluzione di scaling di tipo off-chain, ovvero opera fuori dalla chain principale.

Esso consente di eseguire una serie di operazioni e transazioni indipendentemente dal livello 1. Non è quindi necessario “modificare” la chain principale ma si aggiunge semplicemente uno “strato” aggiuntivo al quale vengono delegate molte operazioni.

Quindi mentre il layer 1 garantisce la sicurezza, il layer 2 di occupa di processare migliaia di transazioni al secondo (TPS) rendendo più utilizzabile la rete per gli utenti.

Le soluzioni di scaling Layer2 per Ethereum sono le seguenti:

• Side chain: un classico esempio è Polygon che sfrutta una chain parallela
• Plasma chain: una soluzione che consente di prevenire gli attacchi di cui soffrono le side chain sfruttando delle sotto catene
• Rollups: con soluzioni come ZK Rollup, Optimistic Rollup, Arbitrum in cui le transazioni del layer 2 sono impacchettate, aggregate ed inviate al layer 1
• State Channels: in cui due parti creano un canale firmando le rispettive transazioni bloccando i fondi (utilizzato nei pagamenti e nel gaming)

Per approfondimenti potete consultare questo video sul nostro canale YouTube che spiega con degli esempi quali sono le soluzioni di scalabilità più adottate per Ethereum.

In questo articolo approfondiamo il funzionamento dei Rollup.

Cos’è un Rollup?

Un rollup è una tecnologia di Layer2 che consente di migliorare la scalabilità della rete Ethereum.

I rollup consentono l’esecuzione delle transazioni al di fuori del layer 1. Col termine Rollup si indica una tecnologia in grado di “impacchettare”(o arrotolare che è ciò che significa rollup) più transazioni in un’unica transazione per essere processate.

A seconda del modo in cui i dati vengono poi ancorati alla blockchain layer 1 di Ethereum possiamo parlare di Optimistic Rollup o ZK-Rollup.

I rollup eseguono l’esecuzione delle transazioni al di fuori del livello 1 e poi i dati vengono inviati al livello 1 dove viene raggiunto il consenso.

Possiamo avere una tecnologia diversa a seconda dei meccanismi utilizzati per inviare i dati alla blockchain di Ethereum. In particolare possiamo dividere i Rollups in:

• Optimistic Rollup: è un modello che presuppone che le transazioni siano valide “a priori”. Se un validatore ritiene che un potenziale blocco sia non valido si torna indietro e si analizza nello specifico fino a trovare l’errore. La sicurezza dunque viene offerta grazie alla possibilità di eseguire prove su potenziali errori nel caso in cui si sospetti una transazione non valida.
• ZK Rollups: questo tipo di rollup detto Zero Knowledge Rollup (a conoscenza zero) pressupone invece che i calcoli vengano eseguiti off chain e successivamente venga inviata una prova di validità alla chain. Cioè utilizza le prove di validità al di fuori della chain principale comprimendo le transazioni prima di inviare la prova definitiva alla blockchain di Ethereum. Da qui il termine a conoscenza zero.

I rollup Zero Knowledge sono più efficienti in quanto hanno bisogno solo della prova di validità invece di tutti i dati delle transazioni come invece richiedono gli Optimistic.

Rollups: riepilogo

👍 Cosa è	Tecnologia di Layer2 che consente di migliorare la scalabilità della rete Ethereum.
✅ Caratteristiche	Layer 2 /
💰Tipi di Rollup	Optimistic Rollup / ZK-Rollup
🥇Migliore piattaforma per fare trading su Ethereum	eToro / Capital.com
🥇Miglior exchange per comprare ETH	Binance

Optimistic Rollup

Un Optimistic Rollup è un protocollo layer 2 (L2) che presuppone che le transazioni siano valide “a priori” e mira ad estendere la velocità della rete Ethereum.

Questo tipo di rollup opera al di fuori della chain principale elaborando le transazioni in un’unico pacchetto per poi pubblicare il risultato di un’unica transazione ancorandola al layer 1 di Ethereum.

In questo modo la rete di Ethereum viene sfruttata solo per la sicurezza e la verifica di eventuali frodi, i dati vengono memorizzati fuori dal layer 1. Un rollup di questo tipo può migliorare anche di 100 volte la scalabilità.

Come funziona un Optimistic Rollup?

Gli optimistic rollup eseguono, come abbiamo detto, una serie di transazioni in “batch” al di fuori della catena principale di Ethereum inviando poi il risultato al layer 1.

Grazie a questo meccanismo si riducono le commissioni (gas fee) per l’utente finali in quanto queste vengono spalmante su più transazioni. I dati vengono poi ulteriormente compressi prima di essere inviati ad Ethereum

Un rollup di questo tipo è definito “ottimistico” proprio perché presuppone che le transazioni elaborate off chain siano valide. Per questo motivo non inviano alcuna prova di validità alla chain layer 1, al contrario dei zk-rollup che inviano le prove crittografiche.

Il funzionamento base di un optimistic rollup lo vediamo in questo schema:

In caso di transazione sospetta o fraudolenta entra in gioco un sistema per risolvere la disputa e capire qual è lo stato giusto da ripristinare e quindi quali transazioni non sono calcolate correttamente.

Dopo che un batch di transazioni viene inviato ad Ethereum c’è una finestra temporale (challenge period) in cui qualunque nodo può inviare una fraud proof (cioè la prova che la transazione è fraudolenta) contestando la validità di una transazione.

Il sistema ricercherà nelle transazioni il motivo della controversia e deciderà quindi come risolverla. Questo processo di esecuzione della transazione e ripristino dello stato richiede dei calcoli eseguiti off chain per evitare consumo di gas fees ed è la parte più complessa probabilmente del rollup.

Se la fraud proof ha successo, la transazione viene rieseguita dal procollo di rollup, che si occupa di ripristinare il corretto stato precedente. Una volta dimostrato che una transazione è fraudolenta il nodo responsabile della transazione errata riceve una penalità.

A questo punto se tutto è stato eseguito correttamente e le transazioni sono valide, terminato questo tempo di attesa il blocco è valido e può essere aggiunto sulla chain principale di Ethereum L1.

Architettura degli Optimistic Rollup

Da un punto di vista tecnico gli optimistic rollup vengono gestiti da una archiettura:

• Smart Contract: una serie di contratti intelligenti su Ethereum memorizzano i blocchi del rollup e tengono traccia dello stato
• OVM: una virtual machine si occupa dell’esecuzione dei calcoli e dell’archiviazione dello stato off chain fuori dalla chain principale. Si tratta di un meccanismo che consente di fungere da livello 2 per gli optimistic rollup. Viene chiamata anche Optimistic Virtual machine oltre a Off Chain Virtual Machine, comunque separata dalla EVM di Ethereum Layer 1

Gli optimistic rollup insomma sono perfettamente compatibili col mondo EVM al contrario dei ZK-Rollups che vedremo dopo. Pur eseguendo i calcoli off chain cioè fuori da Ethereum ne sfruttano la sicurezza e perciò possono essere considerati come una soluzione “ibrida”.

In questo senso è fondamentale avere accesso ai dati e agli aggiornamenti di stato su Ethereum. Grazie alla pubblicazione degli aggiornamenti di stato su Ethereum in caso in cui un nodo vada offline, un altro nodo può continuare a produrre blocchi ripristinando lo stato precedentemente memorizzato da un altro nodo.

Gli utenti possono, inoltre utilizzare i dati delle transazioni per dimostrare la proprietà dei fondi e ritirarli dal rollup.

L’esecuzione delle transazioni ed il Merkle Tree

Lo schema di funzionamento è molto semplice. Gli utenti inviano le transazioni ai nodi validatori che si occupano di elaborare ed aggregare i dati in un rollup per poi inviarlo ad Ethereum

Nel caso in cui lo stato finale sia diverso da quello proposto entra in gioco il sistema di disputa di cui abbiamo parlato prima.

In questo viene sintetizzato il funzionamento di un rollup:

Come vediamo nello schema abbiamo uno smart contract sulla chain che mantiene lo stato del rollup in cui sono memorizzati l’indirizzo dello smart contract, i saldi ed altre informazioni.

Lo stato degli optimistic rollup viene organizzato a livello logico come un albero (Merkle tree) che è chiamato albero degli stati. Alla radice dell’albero (root) abbiamo un hash che fa riferimento all’ultimo stato del rollup. Ogni transizione di stato produce un calcolo e dunque un nuovo stato del rollup su cui verrà calcolata una nuova root.

Per chi non lo sapesse il Merkle Tree, rappresenta una struttura dati usata in varie applicazioni in informatica (ed anche da Bitcoin) utilizzata per verificare l’integrità dei dati in un insieme. Viene usata ad esempio quando facciamo download di un file nei network peer to peer. Queste informazioni non vengono memorizzate sulla chain principale ma possono essere ricalcolate dai dati off chain.

Nel contesto di una blockchain i merkle tree vengono usati nelle intestazioni di blocco per la verifica degli hash e per altre funzioni. Se non sapete cos’è un hash crittografico vi invito a consultare il nostro articolo sulla Blockchain.

Come vedete nello schema qui sotto:

le transazioni vengono compresse e impacchettate in un insieme di transazioni insieme allo stato attuale (codificato tramite funzioni hash dopo l’elaborazione delle transazioni) e allo stato precedente (merkle tree precedente).

Lo smart contract a questo punto controlla che lo stato precedente del batch corrisponda alla radice del merkle tree attuale. Se la verifica è positiva passa al nuovo stato e così via.

Questo è tenuto a tenere traccia del vecchio stato e del nuovo nel momento in cui invia gli L1 batch ad Ethereum. Se la vecchia root del merkle tree corrisponde alla root dello stato attuale, questa viene sostituita con la nuova radice con lo stato aggiornato.

Questa operazione si chiama state commitment e si rende necessaria in quanto qualunque nodo può includere una transazione nel batch di transazioni su layer 1 presentando una Merkle Proof. Uno state commitment di fatto consente di dimostrare che i cambiamenti di stato nel rollup sono corretti.

Lo smart contract di rollup accetta le nuove radici di stato subito dopo che sono state pubblicate ma può cancellarle ritornando indietro se non sono valide per riportare il rollup allo stato corretto.

Ovviamente se un operatore potesse inviare un batch di transazioni con qualsiasi stato successivo senza controlli, potrebbe di fatto trasferire tutti i fondi all’interno del rollup a sé stesso. Per evitare questo ci sono le soluzioni di verifica dei rollup.

Gli optimistic rollup utilizzano la fraud proof, vediamo come funziona.

Fraud Proof

Negli optimistic rollup si utilizza un meccanismo chiamato Fraud Proof. Questo perché chiunque può pubblicare blocchi senza fornire prove di validità, appunto in modo ottimistico.

Quindi chiunque può inviare transazioni fraudolente e rimanere impunito? No perché chiunque vuole produrre un blocco deve fornire un bond cioè degli ETH da vincolare prima, un sistema simile ad una Proof of Stake se vogliamo. Dunque può essere punito con lo slashing se si comporta male. Analogamente anche chi fornisce una fraud proof che non è vera può subire lo slashing in quanto deve impegnare dei fondi con un bond (una sorta di cauzione).

In questo modo gli optimistic rollup garantiscono che i nodi validatori si comportino in maniera trasparente ed onesta.

Lo smart contract di rollup è in grado di memorizzare l’intera storia delle radici di stato e il codice hash di ogni batch.

In questo modo se qualche nodo ritiene che un batch abbia uno stato errato, può pubblicare una fraud proof per dimostrare che il batch è stato calcolato il modo errato. Questo può avvenire in un tempo (challenge) specifico.

A questo punto lo smart contract di rollup verifica che sia vero e annulla il batch e tutti quelli successivi ripristinando lo stato corretto. Per farlo il protocollo di rollup si occupa di rieseguire la transazione contestata sul layer 1 (L1) di Ethereum determinando tramite la root di stato calcolata chi ha ragione. Il nodo che perde la disputa viene penalizzato con uno slashing dei suoi bond impegnati.

Ipoteticamente basta 1 solo nodo per fare funzionare il rollup in quanto entrando in disputa con nodi fraudolenti risulterebbe sempre vincente e la validità della catena sarebbe garantita.

Questo meccanismo di riesecuzione delle transazioni sul layer 1 è inefficiente e richiede dei costi in gas fees. Inoltre si basa sul concetto che se qualcuno pubblica un batch non corretto ci sono altri nodi che seguono la catena di rollup e rilevano la frode dimostrando che il batch deve essere annullato.

Grazie alla struttura dati Merkle Tree utilizzata è possibile calcolare lo stato e la radice. Questo assicura che se un batch viene calcolato in modo errato è possibile sempre dimostrarlo con una fraud proof. Viceversa se un elenco di transazioni è corretto non c’è modo di creare una prova che invece dimostri che non sia valido.

Si parla in questi casi di un sistema di validatori permissionless che può contribuire alla validazione dei blocchi in modo autonomo.

Alcuni optimistic rollup invece utilizzano un “sequencer” ovvero un sistema che elabora le transazioni in sequenza e produce una catena di rollup da inviare poi allo smart contract on chain. In questo caso le transazioni vengono accodate finché il sequencer non lo introduce in un nuovo batch.

La comunicazione tra Optimistic Rollup ed Ethereum

Riepilogando possiamo vedere l’esecuzione di transazioni in un Optimistic Rollup come scandita da più fasi:

• Invio delle transazioni
• Impacchettamento delle transazioni in un batch da inviare al layer 1 (L1) Ethereum
• Invio di eventuali fraud proof da parte dei nodi in una finestra temporale di contestazione
• Riesecuzione dei batch su L1 per risolvere la disputa
• Penalità per i nodi che perdono la disputa

La compressione dei dati

Una transazione su Ethereum richiede circa 110 byte come spazio occupato per il trasferimento. Trasferire invece 1 ETH su un rollup come può essere una soluzione di Optimistic Rollup richiede circa 12 byte quindi quasi un decimo dello spazio.

Gli Optimistic Rollup utilizzano soluzioni per comprimere i batch delle transazioni. Una compressione molto netta si ha sulla firma (signature) che fa risparmiare molto spazio attraverso l’aggregazione di più firme in un’unica.

La compressione dei dati è fondamentale per rendere scalabile i rollup. Senza questi probabilmente si avrebbe un miglioramento ma non così netto come quello assicurato dal fatto di comprimere i transaction data.

Optimistic Rollup: vantaggi e svantaggi

Cerchiamo allora, dopo questa panoramica sulle caratteristiche, di riepilogare quali sono i vantaggi di utilizzare un optimistic rollup per scalare su Ethereum.

Tra i vantaggi ricordiamo:

• Miglioramento delle prestazioni senza sacrificare la sicurezza
• Disponibilità dei dati sul layer 1 per migliorare la trasparenza
• Il meccanismo di disputa e fraud proof assicura la continuità della chain grazie ai nodi onesti
• Compressione dei dati
• Compatibilità EVM con gli smart contract scritti in Solidity che possono essere eseguiti anche sul rollup

Tra gli svantaggi possiamo segnalare:

• Ritardi nella finalizzazione delle transazioni e nei prelievi a causa dei potenziali casi di frode
• L’utilizzo dei sequencer può influenzare l’ordine delle transazioni
• Se tutti i nodi sono disonesti, pubblicando degli state commitment fraudolenti si possono rubare potenzialmente fondi
• I fondi di Ethereum possono essere prelevati dopo 1 settimana dalla fine di una disputa
• I dati dei rollup vengono pubblicati on chain e questo può influire sui costi
• L’esecuzione dei batch sul layer 1 richiede molte risorse e causa inefficienze.

Esempio 1: Arbitrum

Un esempio di layer 2 di tipo optimistic rollup per Ethereum è Arbitrum.

Arbitrum dunque è un soluzione di scaling che memorizza un riepilogo delle transazioni L2 su Ethereum. E’ basato sulla cosiddetta “fraud proof” ovvero un nodo può avanzare il sospetto che una transazione sia non valida o fraudolenta.

In Arbitrum la fase di esecuzione è gestita in modo separato dalla fase di convalida. L’esecuzione viene eseguita in ambiente locale per velocizzare il processo. La fase di convalida invece con la verifica sarà richiesta meno spesso ma deve essere efficiente per essere eseguita anche su Ethereum.

In caso di errore o transazione sospetta, la fase di convalida avviene al di fuori della catena con Arbitrum che ricercherà nelle transazioni il motivo della controversia e deciderà quindi come risolverla. Questo processo di “arbitraggio” richiede dei calcoli eseguiti off chain per evitare consumo di gas fees. La risoluzione del problema sulla transazione non valida viene invece poi risolta sulla chain.

Per mettere in comunicazione Ethereum con Arbitrum si utilizza poi un bridge e la validazione avviene sul layer 1.

Se tutti i nodi validatori sono d’accordo si prosegue, altrimenti si procede a scomporre il blocco alla ricerca dell’errore come visto in precenza.

Lo svantaggio di Arbitrum è che le gas fees sono ridotte ma comunque sono ancora presenti.

Esempio 2: Optimism

Optimism è un altro esempio di optimistic rollup e quindi di soluzione di scaling per Ethereum.

Rispetto ad Arbitrum qui abbiamo la fase di esecuzione che avviene in contemporanea a quella di convalida.

Anche in questo caso le transazioni vengono impacchettate ed inviate in blocco al layer 1.

Optimism è in grado di processare insieme le transazioni, fornire la prova della validità ed inviarle in blocco ad Ethereum.

Durante una transazione Optimism continua a comunicare con Ethereum sfruttandone la sicurezza e la decentralizzazione mentre il layer 2 di occupa della scalabilità.

Questo porta ad alcuni vantaggi:

• Scalabilità: si ottiene un miglioramento della velocità fino a 100 volte
• Costi ridotti: Optimism costa molto meno in quanto i rollup, impacchettando più transazioni in un’unica, consentono di ridurre il costo per singola transazione
• Sicurezza: il layer 2 sfrutta comunque la sicurezza del layer 1
• Esperienza d’uso: gli utenti possono sfruttare Optimism pagando meno commissioni e sfruttando le transazioni più velocità

Come vedete in questa immagine sull’architettura di Optimism

le transazioni vengono processate da un “Sequencer” che si occupa di alleggerire le operazioni su Ethereum.

Optimistic Rollup: video tutorial

Per concludere abbiamo preparato un video sul nostro canale YouTube con un approfondimento sui Rollup, in particolare sugli Optimistic Rollup:

Optimistic Rollup: le domande frequenti

Conclusioni

I rollup costituiscono una delle soluzioni di scaling più efficaci per Ethereum. Gli stessi sviluppatori di Ethereum parlano di questa chain come rollup-centric a dimostrare l’importanza di queste tecnologie.

Abbiamo visto cos’è un rollup e fatto un approfondimento sugli Optimistic Rollup, una soluzione layer 2 impiegata da protocolli come Arbitrum e Optimism.

Gli optimistic rollup presentano dei vantaggi ma anche degli svantaggi rispetto agli zk-rollups che sembrano essere più promettenti.

E’ bene conoscerli e comprenderli per capire anche quale sarà l’evoluzione di Ethereum 2.0 nel futuro.

Per acquistare ETH potete utilizzare uno dei broker proposti sul nostro sito o un exhange.