Differenti tipologie di Layer 2, l’ultimo documento di Vitalik Buterin

Il nuovo articolo di Vitalik Buterin

Mentre Ethereum continua a consolidarsi come la principale rete di smart contract blockchain, stanno cominciando ad emergere sempre più soluzioni di scalabilità per rendere questo ecosistema nato su Ethereum più scalabile ed efficiente. Secondo il cofondatore di Ethereum, Vitalik Buterin, il panorama del Layer 2 offrirà sempre più soluzioni eterogenee che offriranno garanzie di sicurezza e scalabilità variabili in base alle richieste della dApp. In un recente post sul blog intitolato “Different Types of Layer 2s” Buterin ha fornito una panoramica dello stato attuale delle soluzioni di Layer 2; vediamo il riassunto del suo testo in questo articolo di approfondimento.

Introduzione

Le soluzioni di scalabilità per Ethereum che utilizzano tecnologia rollup come Optimism, Arbitrum o Scroll sono cresciute enormemente nell’ultimo periodo e hanno fatto passi da gigante in termini di sicurezza ed usabilità. Altre soluzioni di scalabilità stanno nascendo, come, per esempio, quella proposta dalla sidechain di Polygon o progetti del tutto nuovi come Linea. Inoltre, Vitalik, all’interno del panorama delle soluzioni di scalabilità per ETH, traccia l’esistenza anche delle blockchain “quasi-EVM” come Zksync, estensioni come Arbitrum Stylus e l’ecosistema Starknet, Fuel e altri.

Tanti Layer 2 tutti diversi

Come abbiamo appena visto, il panorama dei Layer 2 inizia ad essere complesso e con diversi approcci, le motivazioni per cui questa eterogeneità continuerà sono le seguenti per Vitalik:

• Alcuni progetti che attualmente sono Layer 1 indipendenti stanno cercando di avvicinarsi all’ecosistema Ethereum, diventando magari Layer 2.
• Alcuni progetti centralizzati vogliono dare ai propri utenti maggiori garanzie di sicurezza e stanno esplorando percorsi basati sulla blockchain per farlo.
• Le applicazioni non finanziarie, come i giochi o i social media, vogliono essere decentralizzate ma necessitano solo di un livello di sicurezza a metà strada.
• Un ultimo tema importante è che utenti già nella blockchain accettano di pagare le fees richieste dai rollup, dato che prima pagavano quelle di ETH, ma utenti non blockchain non sono disposti a pagare nulla.

La domanda alla base dell’articolo

Tante soluzioni che offrono caratteristiche di scalabilità e sicurezza diverse fra loro e quindi la domanda sorge spontanea: quale soluzione di scalabilità una determinata DApp dovrebbe scegliere fra tutte quelle presenti? Vitalik risponderà a questa domanda, creando due problemi teorici che analizzano quella che chiama la “connectedness to Ethereum“.

Il primo è “se avete un asset emesso in L1 (Ethereum), poi depositato in L2, quindi trasferito al vostro wallet, quale livello di garanzia avete che sarete in grado di riportare l’asset nel L1?” mentre il secondo è: “Qual’è la capacità di un sistema di leggere la blockchain di Ethereum.” Iniziamo dal primo quesito.

Riportare un asset su Layer 1

Vitalik prende in considerazione tre tipologie di sistemi, ovvero i Layer 2 che utilizzano tecnologia rollup (sia optimistic che Zero Knowledge), le soluzioni di tipologia validium e sistemi disconnessi dalla blockchain principale. Vitalik elenca le caratteristiche di ogni soluzione in questo schema cercando di capire perché una determinata DApp dovrebbe scegliere un punto particolare di questo spettro.

La conclusione è che le DApp che trattano asset finanziari dovrebbero scegliere soluzioni con tecnologia rollup oppure addirittura L1, dato il loro alto grado di sicurezza a costo di una scalabilità relativamente ridotta, mentre soluzioni come giochi e social on-chian dovrebbero scegliere le soluzioni più scalabili come i validium o chain disconnesse, dato la loro quasi infinita scalabilità, al costo di una sicurezza inferiore.

La capacità di leggere Ethereum

La seconda questione messa in campo da Vitalik prende in analisi il caso in cui Ethereum facesse revert, ovvero ci fosse uno split nell’esecuzione dei blocchi a causa di problemi con i validatori e ci fosse la necessità di tornare indietro e annullare gli ultimi blocchi. Dunque viene verificata la capacità di leggere lo stato di Ethereum e di sincronizzare le azioni di revert.

Vitalik dipinge lo scenario peggiore che può verificarsi: Supponiamo che il primo blocco della catena superiore (ovvero il Layer 2) legga alcuni dati di un blocco della catena Ethereum. Ad esempio, qualcuno da Ethereum deposita 100 ETH nella soluzione di scalabilità. A quel punto, Ethereum torna indietro a causa di un problema nella validazione dei blocchi. Tuttavia, il Layer 2 non ritorna. Di conseguenza, i blocchi futuri del layer 2 seguono correttamente i nuovi blocchi della nuova catena Ethereum corretta, ma le conseguenze del vecchio collegamento ormai errato (ossia il deposito di 100 ETH) fanno ancora parte della catena superiore. L’utente che ha fatto il deposito si ritroverebbe dunque con 100 ETH nella soluzione di scalabilità e 100 ETH nella chain principale, che ha fatto revert ed ha annullato l’azione di deposito dell’utente. Questo exploit potrebbe consentire di stampare denaro. Vitalik evidenzia due possibili soluzioni per evitare questo problema:

1. La soluzione di scalabilità potrebbe leggere solo i blocchi finalizzati di Ethereum, quindi non avrebbe mai bisogno di riverificare.
2. La soluzione di scalabilità potrebbe tornare indietro se Ethereum torna indietro.

Entrambe le soluzioni prevengono il problema. La prima è più facile da implementare, ma potrebbe causare una perdita di funzionalità per un periodo prolungato se Ethereum entra in un periodo di inattività. La seconda è più difficile da implementare, ma garantisce la migliore funzionalità possibile in ogni momento.

Conclusione

Le soluzioni di scalabilità devono affrontare due tiopologie di “connessione a Ethereum”:

1. Sicurezza nel prelevare da Ethereum
2. Sicurezza nel leggere Ethereum

Entrambe sono importanti e hanno considerazioni diverse. Esiste uno spettro, secondo Vitalik, per cui per alcune applicazioni è importante un’elevata sicurezza e una stretta connessione con ETH, e dunque dovranno scegliere soluzioni di scalabilità meno efficienti ma più sicure, mentre dApp che gestiscono un basso valore finaziario possono scegliere soluzioni meno sicure ma più scalabili.