Analisi della ricerca originale di Web3.com Ventures

0xFischioso

Introduzione

"zk-Rollups" è stata probabilmente la parola d'ordine Web 3 più in voga dell'anno. Con il lancio della mainnet v2.0 "baby alpha" di zk-Sync negli ultimi giorni, questa eccitazione ha raggiunto il suo apice [1]. Ma dietro tutte queste parole d'ordine, a cosa si riferisce realmente "zk-Rollups"? E dove entra in gioco zk-Sync? In questo articolo, cercherò di approfondire i principi e la pratica di zk-Rollups, spiegare i principali tratti distintivi tecnici di zk-Sync v2.0 come progetto ed esplorare le potenziali implicazioni future per questa tecnologia tanto attesa.

Principi degli zk-Rollup

Perché abbiamo bisogno di zk-Rollup in primo luogo? Certo, Ethereum è fantastico. Ma nel suo stato attuale, la rete è fondamentalmente una diseconomia di scala. Con l'aumento dell'attività di rete, i prezzi del gas diventano proibitivi, in particolare se si verifica un'ondata di attività di rete tutta in una volta. Mentre Ethereum guadagna popolarità in termini di utilizzo e trazione negli ultimi anni, la sua attuale scalabilità limitata è diventata il tallone d'Achille della rete.

Ecco dove entrano in gioco i "rollup": i rollup di Ethereum sono essenzialmente un "plugin" che fornisce a Ethereum una scalabilità extra, correggendo così la sua intrinseca diseconomia di scala. L'intuizione alla base dell'idea è semplice. Immagina di avere 5 oggetti che devi trasportare dal punto A al punto B. Il modo "normale" di farlo sarebbe trasportare l'oggetto 1, trasportare l'oggetto 2, ecc. uno dopo l'altro. Ma questo è ovviamente lento e macchinoso. Un "rollup" è essenzialmente "arrotolare" tutti e 5 gli oggetti in un'unica borsa, consentendoti così di fare un singolo viaggio invece di 5.

Ma ci sono due avvertenze:

  1. Come possiamo essere certi che il rollup possa "contenere" tutto?

  2. Come possiamo essere certi che il rollup non sia falsificato?

Gli zk-Rollup sono uno dei principali tipi di tecnologie di rollup (l'altro è Optimistic Rollup) che sfrutta le "zero-knowledge proof" per risolvere questi due problemi. Per risolvere questi problemi, uno zk-Rollup raggrupperà un certo numero di transazioni insieme, eseguirà il calcolo su L2 e invierà sia le modifiche di stato sia una "validity proof" a un verificatore su L1 che mostra che i calcoli sono stati eseguiti con integrità. Questa "validity proof" avviene sotto forma di una "Zero-Knowledge Proof", un modo matematico di dire a qualcuno che sai qualcosa senza dirgli cosa sai.

Un semplice esempio di Zero-Knowledge Proof è un autograder di codice (per i compiti di informatica). L'autograder è un "verificatore" che ti fornisce un mucchio di casi di test generati casualmente e tu sei un "dimostratore" che deve essere in grado di superare tutti i casi di test per dimostrare di avere il codice corretto. Per tutto il tempo, non condividi il tuo codice direttamente con l'autograder. Ed ecco, hai appena condotto una "Zero-Knowledge Proof", dimostrando che sai qualcosa senza dire cosa sai. [2]

Il code autograder di cui sopra usa una "Zero-Knowledge-Proof interattiva", dove il code-provider e il code-provider "interagiscono" direttamente tra loro. Al contrario, la maggior parte degli zk-Rollup usa una dimostrazione non interattiva matematicamente più complicata (come uno zk-SNARK, o Zero Knowledge Succinct Noninteractive ARgument of Knowledge), che fa risparmiare tempo e spazio rispetto a una dimostrazione interattiva. Mentre i dettagli tecnici degli zk-SNARK vanno oltre lo scopo di questo articolo, il principio di base del superamento del caso di prova è lo stesso.

Il Santo Graal degli zk-Rollup è una Zero-Knowledge Ethereum Virtual Machine (zk-EVM) che consente agli sviluppatori di trasferire qualsiasi smart contract Ethereum senza modifiche su una catena zk-Rollup. Ma è difficile. Poiché ogni "problema" richiede diversi set di "casi di test", sviluppare un "algoritmo di prova" in grado di risolvere ogni caso di test immaginabile è un collo di bottiglia tecnico delle Zero-Knowledge Proof e degli zk-Rollup.

Come afferma lo stesso Vitalik Buterin:

In generale, la mia opinione è che nel breve termine, i rollup ottimistici probabilmente prevarranno per il calcolo EVM di uso generale e i rollup ZK probabilmente prevarranno per pagamenti semplici, scambi e altri casi d'uso specifici dell'applicazione, ma nel medio e lungo termine i rollup ZK prevarranno in tutti i casi d'uso man mano che la tecnologia ZK-SNARK migliora. [3]

Pertanto, storicamente gli zk-Rollup sono stati solo tecnologie consolidate per casi d’uso specifici dell’applicazione, in cui i “casi di test” sono ben definiti e limitati nella portata. Tuttavia, diversi progetti stanno rapidamente avanzando verso il “castello sulla collina” – un algoritmo zk-Rollup generico compatibile con EVM. [4]

Sincronizzazione zk v2.0

zk-Sync v2.0 è solo uno dei tanti progetti attualmente in gioco nello sviluppo di uno zk-EVM (altri includono StarkNet, Polygon Hermez e Scroll). A differenza di zk-Sync v1.0, che richiedeva agli utenti di ricostruire ampie sezioni delle loro basi di codice per il porting dall'EVM a zk-Sync, in zk-Sync v2.0 i programmatori possono distribuire le loro applicazioni con poche o nessuna modifica, o come zk-Sync potrebbe voler affermare.

In pratica, non tutti gli zk-EVM sono creati uguali. Esiste un netto compromesso tra componibilità (quanto è vicino ai contratti EVM originali) e prestazioni (quanto velocemente verranno eseguiti gli zk-Rollup) [6]. All'interno di questo compromesso, zk-Sync ha scelto di ottimizzare completamente le prestazioni, sacrificando così la componibilità.

Nella prospettiva di Vitalik Buterin, ci sono quattro tipi distinti di zk-EVM, riassunti nel seguente grafico:

Come afferma Vitalik, nel suo stato attuale zk-Sync v2.0 è uno zk-EVM di tipo 4, in grado di compilare contratti scritti in Solidity e linguaggi di alto livello utilizzando il proprio compilatore, che è distinto dall'EVM. Poiché zk-Sync ha il pieno controllo sulla progettazione del suo compilatore, è in grado di ottimizzare in modo aggressivo velocità e produttività. Il costo di ciò è che alcune DApp e toolchain di debug EVM potrebbero essere incompatibili con zk-Sync v2.0. In sostanza, zk-Sync è la stessa shell di Ethereum ma con un motore sostituito [5].

In effetti, nella sua documentazione per sviluppatori, Matter Labs afferma che mentre le operazioni di "lettura" degli smart contract possono essere integrate senza alcuna modifica al codice, le operazioni di "scrittura" degli smart contract necessitano di "codice aggiuntivo" a causa di "differenze fondamentali tra L1 e L2" [6]. In realtà, questo è leggermente fuorviante. Non è tanto dovuto a una "differenza fondamentale" tra L1 e L2, ma piuttosto al tipo di zk-Rollup che Matter Labs ha deciso di perseguire: il rollup di tipo 4. Poiché zk-Sync è fondamentalmente un rollup di tipo 4 che utilizza un compilatore e un bytecode diversi, ciò significa che gli smart contract hanno indirizzi diversi e l'infrastruttura del debugger che si basa sull'analisi del bytecode potrebbe non essere in grado di funzionare su zk-Sync v2.0 [7].

In futuro, zk-Sync potrebbe aggiungere più supporto nativo per il byte-code EVM, consentendo al sistema di passare lentamente a un rollup di tipo 3 che supporta una gamma più ampia di questi "casi limite". Ma affinché lo zk-Rollup di tipo 4 o di tipo 3 di zk-Sync abbia successo rispetto al rollup di tipo 2 di Polygon Hermez e Scroll Labs, che sostanzialmente scambia la velocità per una compatibilità più ampia, devono esserci due importanti prerequisiti. In primo luogo, c'è solo una piccola frazione di progetti non importanti che sono incompatibili con il compilatore personalizzato di zk-Sync. In secondo luogo, c'è una differenza qualitativa nella velocità di esecuzione di zk-Sync rispetto a uno zk-EVM di tipo 2.

Sfortunatamente, personalmente credo che sia improbabile che ciò accada. Qualsiasi ecosistema di sviluppo avanzato si basa su un'infrastruttura di "impalcatura" matura, che include strumenti di debug e test convenienti e modulari. Se, come postula Vitalik, una larga parte degli strumenti di debug nativi di EVM non sarà in grado di essere trasferita su zk-Sync a causa di differenze nel bytecode, allora zk-Sync dovrà sviluppare la propria suite di strumenti di test e debug. Questo è un sovraccarico aggiuntivo che potrebbe in ultima analisi ostacolare la velocità di adozione di zk-Sync come soluzione L2, rispetto ai suoi concorrenti zk-EVM di tipo 2 più componibili come Polygon Hermez e Scroll.

Il futuro degli zk-Rollup

Con molti attori competitivi nella battaglia per gli zk-EVM, si può sostenere che sia solo questione di tempo prima di vedere uno zk-EVM completamente funzionante. Ma cosa succederà? Una strada è utile solo finché ci sono edifici sulla strada; la forza a lungo termine di uno zk-Rollup deriva dai progetti che utilizzano quella soluzione.

Al momento, DeFi, GameFi e applicazioni mobili sono i principali beneficiari dell'infrastruttura zk-Rollup. Sia DeFi che GameFi sono fondamentalmente economie di scala, poiché prosperano in un ambiente in cui ci sono molte persone che le utilizzano. Le applicazioni mobili come i portafogli mobili aprono anche le porte al consumatore di massa che è troppo pigro (o non può permettersi) un PC desktop. Utilizzare zk-Rollup per queste situazioni ha quindi molto senso.

Ma questo non è affatto il limite dell'utilità di zk-Rollups. Se non altro, questo è solo l'inizio. zk-Rollups sono per Ethereum ciò che il 5G è per Internet. Proprio come il 5G può abilitare un nuovo mondo di applicazioni e sistemi IoT, zk-Rollups può anche aprire le porte a una "Blockchain of Things", consentendo agli elettrodomestici digitali del nostro mondo fisico (frigoriferi, orologi, semafori e tutto il resto) di essere integrati con contratti intelligenti garantiti su Ethereum.

Uno degli argomenti più forti contro l'IoT è che consentirà a Big Tech di invadere la nostra vita quotidiana. Ma con una "Blockchain of Things", possiamo godere delle comodità dell'IoT senza preoccuparci che i nostri elettrodomestici intelligenti vengano compromessi su un database centralizzato. Invece di comodità O privacy, possiamo avere comodità E privacy. Questo è il mondo che zk-Rollups può prometterci.

🐦 @0xfishylosopher

📅 31 ottobre 2022

Queste informazioni sono puramente didattiche e non devono essere considerate come consigli finanziari. Tutte le opinioni espresse sono quelle dell'autore e non sono necessariamente approvate da Web3.com Ventures.

Riferimenti

[1] https://blog.matter-labs.io/baby-alpha-has-arrived-5b10798bc623

[2] Adattato da https://pages.cs.wisc.edu/~mkowalcz/628.pdf

[3] https://vitalik.ca/general/2021/01/05/rollup.html

[4] https://www.coindesk.com/tech/2022/07/20/the-sudden-rise-of-evm-friendly-zk-rollups/

[5] https://cryptobriefing.com/the-race-scale-ethereum-zkevm-rollups/

[6] https://docs.zksync.io/dev/contracts/#porting-smart-contracts

[7] https://vitalik.ca/general/2022/08/04/zkevm.html