L’ecosistema Ethereum L2 si è espanso rapidamente nell’ultimo anno. L'ecosistema rollup ZK-EVM, tradizionalmente composto da StarkNet, Arbitrum, Optimism e Scroll, si sta muovendo rapidamente e sta facendo grandi passi avanti nel migliorare la sicurezza. La pagina L2beat fa un buon lavoro riassumendo lo stato di ciascun progetto; Inoltre, abbiamo visto anche team che costruivano sidechain iniziare a costruire Rollup (Polygon), progetti L1 che cercavano di svilupparsi nella direzione della verifica della validità (Celo) e altri tentativi completamente nuovi (Linea, Zeth...).

Un risultato inevitabile di ciò è che vediamo che i progetti L2 mostrano una tendenza a diventare più eterogenei. Mi aspetto che questa tendenza continui per alcuni motivi:

Alcuni progetti che attualmente sono L1 indipendenti stanno cercando di avvicinarsi all’ecosistema Ethereum e potenzialmente diventare L2. Questi progetti potrebbero richiedere una transizione graduale. Effettuare la transizione tutta in una volta ridurrà l'usabilità perché la tecnologia non è pronta per mettere tutto in un rollup. Se effettui una transizione una tantum in un secondo momento, rischi di sacrificare lo slancio e di far sì che sia troppo tardi per avere un senso.

Alcuni progetti centralizzati vogliono fornire agli utenti maggiori garanzie di sicurezza e stanno esplorando approcci basati sulla blockchain. In molti casi, questi progetti avrebbero esplorato “catene di consorzi autorizzati” nell’era precedente. In effetti, potrebbero richiedere solo un livello di decentralizzazione “semi-centralizzato”. Inoltre, poiché il loro throughput tende ad essere molto elevato, non sono adatti nemmeno allo sviluppo Rollup, almeno nel breve termine.

Le applicazioni non finanziarie come i giochi o i social media vogliono essere decentralizzate, ma richiedono solo un livello di sicurezza “semi-centralizzato”. Quando si tratta di social media, la realtà è che le diverse parti dell'applicazione devono essere trattate in modo diverso: attività rare e di alto valore come la registrazione del nome utente e il recupero dell'account dovrebbero essere eseguite in Rollup, ma attività frequenti e di basso valore come post e post i sondaggi no. Se un errore di collegamento fa scomparire il tuo post, questo è un prezzo accettabile da pagare. Se la catena fallisce e il tuo account viene perso, il problema è molto più grande.

Un tema importante è che mentre le applicazioni e gli utenti attualmente su Ethereum L1 saranno in grado di pagare commissioni di rollup più piccole ma ancora visibili a breve termine, gli utenti del mondo non blockchain non potranno: se in precedenza pagavi $ 1, pagare $ 0,1 è di più ragionevole che pagare $ 0. Ciò vale sia per le attuali applicazioni centralizzate che per le applicazioni L1 più piccole, che in genere costano molto poco ma hanno comunque una piccola base di utenti.

Una domanda che sorge spontanea è: quale di questi complessi compromessi tra rollup, validità e altri sistemi è ragionevole per una determinata applicazione?

Rollup, validium, sistemi disconnessi

La prima dimensione di sicurezza e scala che vogliamo esplorare può essere descritta come segue: se hai un asset emesso su L1, e poi lo depositi su L2, e poi te lo trasferisci, quanta garanzia puoi offrire di poter trasferire? questa risorsa? Riportare L1?

Esiste una domanda parallela: quale scelta tecnologica porta a questo livello di garanzia e quali sono i compromessi di tale scelta tecnologica?

Possiamo usare un diagramma per descriverlo semplicemente:

Vale la pena ricordare che questa è una modalità semplificata con molte opzioni intermedie. Per esempio:

Tra rollup e validium: nel validium, chiunque può effettuare pagamenti on-chain per coprire le commissioni di transazione, a quel punto gli operatori saranno costretti a fornire alcuni dati alla catena o perderanno i loro depositi.

Tra Plasma e validium: il sistema Plasma fornisce garanzie di sicurezza simili a Rollup fornendo al contempo la disponibilità dei dati fuori catena, ma può supportare solo applicazioni limitate. Un sistema può fornire un EVM completo e fornire garanzie a livello di Plasma per gli utenti che non utilizzano queste applicazioni più complesse e garanzie a livello di Validium per gli utenti che lo fanno.

Queste opzioni intermedie possono essere pensate come uno spettro tra rollup e valori validi. Ma cosa motiva un'applicazione a scegliere un punto sullo spettro anziché un punto più a sinistra o a destra? Ci sono due fattori principali:

1. Con l’avanzare della tecnologia, il costo della disponibilità dei dati nativi in ​​Ethereum diminuirà gradualmente. Il prossimo hard fork di Ethereum, Dencun, introduce EIP-4844 (noto anche come “native fork”), che fornisce una disponibilità di dati sulla catena di circa 32 kB al secondo. Nel corso dei prossimi anni, si prevede che questa disponibilità di dati aumenterà gradualmente con l'implementazione del completo "sharding dei dati on-chain", raggiungendo infine una disponibilità di dati di circa 1,3 MB al secondo. Allo stesso tempo, i miglioramenti nella tecnologia di compressione dei dati ci consentiranno di fare di più con la stessa quantità di dati.

2. Le esigenze dell'applicazione stessa: quanto soffriranno gli utenti per le tariffe elevate e quanto costeranno se l'applicazione va storta? Le applicazioni finanziarie soffrono maggiormente di errori applicativi; i giochi e i social media comportano grandi quantità di attività per utente e attività di valore relativamente basso, quindi per loro sono giustificati diversi compromessi in termini di sicurezza.

I compromessi sono più o meno questi:

Un altro tipo di garanzia parziale degna di nota è la preconferma. Una pre-conferma è un messaggio firmato da un gruppo di parti durante un periodo di rollup o di validità, in cui si dice "certificamo che queste transazioni sono incluse in questo ordine e che la radice post-stato è tale". È possibile che le preconferme firmate da questi partecipanti non corrispondano alla realtà successiva, ma in caso contrario la caparra verrà distrutta. Ciò è utile per le applicazioni di basso valore come i pagamenti al consumo, mentre le applicazioni di alto valore come i trasferimenti di fondi multimilionari potrebbero dover attendere conferme "regolari" con il pieno supporto di sicurezza da parte del sistema.

La pre-convalida può essere vista come un altro esempio di sistema ibrido, simile al "sistema ibrido plasma/validium" menzionato sopra, ma questa volta con sicurezza completa ma rollup di latenza più elevato (o validium) con bassi livelli di sicurezza Un ibrido tra sistemi con latenza molto più elevata ma latenza inferiore. Le applicazioni che richiedono una latenza inferiore riceveranno una sicurezza inferiore, ma potranno vivere nello stesso ecosistema di quelle che possono accettare una latenza maggiore in cambio della massima sicurezza.

Leggi Ethereum senza fiducia

Un’altra forma di connettività meno considerata ma comunque molto importante riguarda la capacità del sistema di leggere la blockchain di Ethereum. In particolare, ciò include la possibilità di ripristinare quando Ethereum si riprende. Per comprenderne il valore, consideriamo la seguente situazione:

Supponiamo che la catena di Ethereum si riavvolga come mostrato nella figura. Questo potrebbe essere un intoppo temporaneo in un periodo in cui la catena non è stata finalizzata; potrebbe anche essere un periodo di perdita di inattività in cui troppi validatori sono offline e la catena non è stata finalizzata per molto tempo.

Lo scenario peggiore che potrebbe verificarsi è il seguente:

Supponiamo che il primo blocco della catena superiore legga alcuni dati dal blocco più a sinistra della catena Ethereum. Ad esempio, qualcuno su Ethereum deposita 100 ETH sulla catena principale. Quindi, Ethereum è tornato indietro. Tuttavia, la catena superiore non verrà ripristinata. Pertanto, i futuri blocchi della catena superiore seguiranno correttamente i nuovi blocchi della nuova catena Ethereum corretta, ma le conseguenze del vecchio collegamento sbagliato (ovvero il deposito di 100 ETH) ora fanno ancora parte della catena superiore. Questa vulnerabilità può essere sfruttata per stampare denaro, trasformando l’ETH collegato sulla catena superiore in una riserva parziale.

Esistono due modi per risolvere questo problema:

1. La catena superiore può leggere solo il blocco finale di Ethereum, quindi non ha mai bisogno di essere ripristinata.

2. Se Ethereum viene ripristinato, anche la catena superiore può essere ripristinata. Entrambi i metodi evitano questo problema. Il primo è più semplice da implementare, ma potrebbe comportare una prolungata perdita di funzionalità se Ethereum entrasse in un periodo di perdita inattiva. Quest'ultimo è più difficile da realizzare, ma garantisce sempre una funzionalità ottimale.

Si noti che (1) ha un caso limite. Se un attacco del 51% su Ethereum crea due nuovi blocchi incompatibili ed entrambi i blocchi finiscono contemporaneamente, è probabile che la catena superiore blocchi il blocco sbagliato (ovvero il consenso sociale di Ethereum finisce per non supportare il blocco) e deve essere ripristinata al blocco corretto. Probabilmente, non è necessario scrivere il codice in anticipo per gestire questa situazione, basta effettuare un hard fork della catena superiore.

Ci sono due ragioni per cui una catena può leggere Ethereum in modo trustless:

1. Riduce i problemi di sicurezza coinvolti nel bridging dei token emessi su Ethereum (o altro L2) su quella catena;

2. Consente ai portafogli di astrazione degli account utilizzando un'architettura di archiviazione di chiavi condivise per conservare in modo sicuro le risorse sulla catena.

Il primo punto è importante, anche se la necessità è già ampiamente riconosciuta. Anche il secondo punto è importante perché significa che puoi avere un portafoglio che consente un facile cambio di chiavi e detenere asset su un gran numero di catene diverse.

Possedere un ponte lo rende valido?

Diciamo che la catena principale è iniziata come catena separata e poi qualcuno ha aggiunto un contratto ponte su Ethereum. Un contratto ponte è un contratto semplice che accetta un'intestazione di blocco dalla catena superiore, verifica che qualsiasi intestazione di blocco ad esso inviata porti un certificato valido indicante che è stato accettato dal consenso della catena superiore e aggiunge quell'intestazione di blocco a un elenco mezzo. Su questa base le applicazioni possono implementare funzioni come il deposito e il prelievo di monete. Una volta istituito, tale ponte sarà in grado di fornire la garanzia di sicurezza patrimoniale di cui abbiamo parlato prima?

Finora, non ancora! Ci sono due ragioni:

1. Ciò che verifichiamo è se il blocco è firmato, non se la transizione di stato è corretta. Quindi, se depositi asset emessi su Ethereum nella catena superiore e i validatori sulla catena superiore sono indisciplinati, possono firmare una transizione di stato non valida e quindi rubare tali asset;

2. La catena superiore non riesce ancora a leggere Ethereum. Pertanto, non puoi nemmeno depositare risorse native di Ethereum nella catena principale senza fare affidamento su altri bridge di terze parti (che potrebbero non essere sicuri);

Ora trasformiamo il bridge in un bridge di verifica: non solo controlla il consenso, ma controlla anche gli ZK-SNARK, dimostrando che lo stato di ogni nuovo blocco è stato calcolato correttamente.

Una volta fatto ciò, i validatori sulla catena superiore non potranno più rubare i tuoi fondi. Possono pubblicare un blocco in cui i dati non sono disponibili, impedendo a tutti di ritirarsi, ma non possono rubare (a parte cercare di chiedere un riscatto agli utenti in cambio dei dati che possono ritirare). È uguale alla modalità provvisoria di Validium.

Tuttavia non abbiamo ancora risolto il secondo problema: la top chain non riesce a leggere Ethereum.

Per fare ciò dobbiamo fare una delle due cose:

1. Posiziona un contratto bridge nella catena superiore per verificare il blocco Ethereum finalizzato;

2. Lascia che ogni blocco nella catena superiore contenga un hash del blocco Ethereum più recente e sviluppa una regola di scelta del fork che imponga il concatenamento dell'hash. Cioè, un blocco della catena superiore collegato a un blocco Ethereum che non è nella catena canonica è esso stesso non canonico. Se un blocco della catena superiore è collegato a un blocco Ethereum originariamente canonico ma in seguito diventato non canonico, il blocco catena superiore Anche i blocchi devono diventare non canonici.

Il collegamento viola può essere un collegamento hash o un contratto ponte che verifica il consenso di Ethereum.

È abbastanza? A quanto pare, non è ancora sufficiente perché ci sono alcuni casi limite:

1. Cosa accadrebbe se Ethereum venisse attaccato del 51%?

2. Come gestire l’aggiornamento dell’hard fork di Ethereum?

3. Come gestire gli aggiornamenti dell'hard fork della catena?

Le conseguenze di un attacco del 51% su Ethereum sono simili alle conseguenze di un attacco del 51% sulla catena superiore, ma la situazione è opposta. Un hard fork di Ethereum ha il potenziale per rendere non più valido il bridge Ethereum all’interno della top chain. Il modo più semplice per risolvere questo problema è assumere un impegno sociale per ripristinare un blocco finale se Ethereum lo ripristina; assumere un impegno sociale per l’hard fork se Ethereum effettua un hard fork; Potrebbe non essere mai necessario che tale promessa venga effettivamente applicata: potresti far sì che il gadget di governance sulla catena superiore entri in azione quando vede la prova di un possibile attacco o hard fork, e solo hard fork della catena superiore se il gadget di governance fallisce.

Sfortunatamente, l’unica risposta fattibile al punto (3) è quella di impostare una qualche forma di gadget di governance su Ethereum che renda il contratto bridge su Ethereum consapevole degli aggiornamenti dell’hard fork della catena superiore.

Riepilogo: il bridging di verifica bidirezionale è quasi sufficiente per creare un validium blockchain. Il principale fattore rimanente è l’impegno sociale secondo cui se succede qualcosa di speciale a Ethereum che fa sì che il ponte non funzioni più, l’altra catena si biforcherà in risposta.

Insomma

Ci sono due dimensioni chiave per “connettersi a Ethereum”:

1. La sicurezza del prelievo di fondi su Ethereum;

2. Leggi la sicurezza di Ethereum.

Questi sono tutti importanti e hanno considerazioni diverse. In entrambi i casi esiste uno spettro continuo:

Si noti che queste due dimensioni sono misurate ciascuna in due modi diversi (ci sono quindi davvero quattro dimensioni?): La sicurezza di un prelievo può essere misurata da (i) il livello di sicurezza e (ii) beneficiando del livello di sicurezza più elevato Misurato come una percentuale di utenti o casi d'uso; la sicurezza di lettura può essere misurata in base a (i) la velocità con cui la catena legge i blocchi Ethereum, in particolare il blocco finale rispetto a qualsiasi blocco, e (ii) la catena gestisce il 51% di attacchi e punteggi difficili Cross e altro casi limite per misurare la forza dell’impegno sociale.

Il valore del progetto esiste in molte aree di questo spazio di progettazione. Per alcune applicazioni, un'elevata sicurezza e una stretta connettività sono molto importanti. Per altre applicazioni, è accettabile essere più flessibili per ottenere una maggiore scalabilità. In molti casi, iniziare oggi con un accoppiamento più flessibile e passare a un accoppiamento più stretto nel prossimo decennio, man mano che la tecnologia avanza, potrebbe essere l’opzione migliore.