Espresso Systems sta lavorando alacremente per portare le applicazioni Web3 nella vita quotidiana, affrontando sfide che spaziano dalla privacy alla velocità. Un elemento chiave di questo sforzo è lo sviluppo di Espresso Sequencer, un sistema innovativo che mira a rendere i rollup più decentralizzati senza sacrificare la velocità e la scalabilità che gli utenti si aspettano. In altre parole, l'obiettivo è di fornire prestazioni Web2 con la sicurezza Web3.

Componenti di un Rollup:

I rollup sono composti da diversi componenti:

• Macchina virtuale (VM): Esegue le transazioni e aggiorna lo stato del sistema.

• Sequencer: Ordina le transazioni inviate alla VM.

• Sistema di prova: Genera una prova del cambiamento di stato della VM (solo per le VM zk).

• Contratto Rollup su L1: Registra il cambiamento di stato e verifica la prova.

Sequencer Interno vs. Esterno:

Non è sempre necessario un sequencer esterno. In alternativa, si potrebbe utilizzare il contract stesso per ordinare le transazioni. Questo approccio presenta alcuni vantaggi:

• Maggiore fiducia: Gli utenti devono fidarsi solo di L1 per la continuità del sistema.

• Semplicità: Non è necessario un componente aggiuntivo.

Tuttavia, presenta anche alcuni svantaggi:

• Scalabilità limitata: La velocità del sistema rollup è limitata dalla velocità di sequenziamento dei dati di L1.

• Ritardi di conferma: Gli utenti sperimentano gli stessi ritardi nella conferma delle transazioni come su L1.

L'introduzione di un sequencer esterno promette una maggiore velocità e conferme più rapide delle transazioni. In questo scenario, gli utenti possono scegliere di:

• Fidarsi del sequencer: Ottengono una finalità rapida, ma assumono un rischio di fiducia.

• Attendere la conferma da L1: Ottengono una sicurezza garantita, ma con tempi di attesa più lunghi.

Espresso Sequencer:

Espresso Sequencer è progettato per sfruttare i vantaggi di un sequencer esterno, pur mitigando i rischi di fiducia. Attraverso l'utilizzo di tecnologie avanzate come la crittografia e la decentralizzazione, Espresso Sequencer mira a:

• Migliorare la velocità: Offrire transazioni veloci e a bassa latenza.

• Aumentare la scalabilità: Gestire un elevato volume di transazioni senza sacrificare la sicurezza.

• Ridurre i costi: Offrire transazioni a costi accessibili per tutti gli utenti.

• Migliorare la privacy: Proteggere la privacy degli utenti e la riservatezza dei dati.

La blockchain di Ethereum, un tempo simbolo di innovazione, ha faticato a tenere il passo con il proprio successo. L'aumento vertiginoso dell'attività di rete ha portato le commissioni di transazione a livelli esorbitanti, ostacolando l'esperienza utente e limitando la scalabilità delle applicazioni decentralizzate. I rollup sono emersi come una soluzione potente, scaricando l'esecuzione delle transazioni su livelli secondari pur ereditando la sicurezza dalla rete principale di Ethereum. Tuttavia, l'attuale panorama dei rollup, ciascuno con il proprio sequenziatore indipendente, presenta nuove sfide.

Una delle principali preoccupazioni è il potenziale di centralizzazione. Quando una singola entità controlla l'ordinamento delle transazioni su un rollup, crea l'opportunità sia di prezzi monopolistici che di censura. Gli utenti potrebbero dover affrontare commissioni eccessive o, peggio ancora, essere impediti di effettuare transazioni del tutto. Inoltre, la proliferazione di rollup indipendenti porta a un ecosistema frammentato. La liquidità diventa isolata tra le diverse soluzioni L2, ostacolando l'interoperabilità e riducendo l'efficienza complessiva della rete.

Il sequenziamento condiviso offre una soluzione convincente a queste sfide. Abilitando più rollup a sfruttare un singolo sequenziatore decentralizzato, favorisce un ecosistema L2 più efficiente e componibile. Immaginiamo un futuro in cui i rollup funzionino come città-stato all'interno di una nazione più grande, ciascuna con la propria governance unica e focus economico, ma tutte collegate da un'infrastruttura condivisa che facilita l'interazione sicura e senza interruzioni.

I vantaggi del sequenziamento condiviso sono molteplici. Innanzitutto, elimina il rischio di controllo centralizzato. Con un singolo sequenziatore decentralizzato, nessuna singola entità ha il potere di dettare le commissioni di transazione o impedire agli utenti di partecipare alla rete. Ciò favorisce un ambiente L2 più equo e aperto.

Il sequenziamento condiviso rivoluziona anche il bridging tra rollup, ovvero il processo di trasferimento di asset e dati tra diverse soluzioni rollup. Tradizionalmente, questo è stato un processo complesso e ingombrante, che richiede ai rollup di mantenere light client individuali per ciascuna chain interagente. Il sequenziamento condiviso elimina completamente questa necessità. Utilizzando un singolo sequenziatore, i rollup possono interagire senza problemi, portando a:

• Costi di sviluppo e operativi ridotti: i rollup non devono più investire risorse nella creazione e manutenzione di light client separati.

• Latenza dei bridge inferiore: le transazioni cross-rollup non devono più affrontare la latenza aggiuntiva associata all'attesa della finalizzazione su sequenziatori separati.

• Sicurezza migliorata: il sequenziamento condiviso mitiga i rischi sistemici associati ai sequenziatori indipendenti. Derivando lo stato di più rollup da un singolo ledger delle transazioni unificato, diventa molto più difficile sfruttare le vulnerabilità nei bridge tra i rollup.

Forse l'aspetto più trasformativo del sequenziamento condiviso risiede nella sua capacità di sbloccare il potenziale per transazioni atomic cross-rollup. Queste transazioni garantiscono che tutte le operazioni all'interno di un bundle abbiano successo o nessuna lo faccia. Immaginiamo un utente che esegue uno swap cross-rollup tra due diverse soluzioni L2. Con il sequenziamento condiviso, può essere sicuro che entrambi gli asset vengano scambiati o nessuno dei due - eliminando il rischio di una transazione parzialmente completata. Il sequenziamento condiviso facilita due tipi principali di bundle atomici:

• Bundle garantiti crittograficamente: questi bundle offrono solide garanzie di sicurezza attraverso prove crittografiche. Sono ideali per casi d'uso semplici come atomic swaps e scambi NFT tra rollup.

• Bundle economicamente assicurati: questi bundle consentono il soddisfacimento di condizioni più complesse prima dell'esecuzione. Ciò apre le porte a casi d'uso innovativi come opportunità di arbitraggio che comportano l'interazione con protocolli esterni su un rollup.

Le implicazioni del sequenziamento condiviso si estendono ben oltre l'efficienza tecnica. Promuovendo l'interoperabilità e la condivisione della liquidità tra i rollup, apre la strada a un ecosistema L2 veramente unificato. I rollup possono specializzarsi in casi d'uso specifici, sfruttando l'infrastruttura condivisa per interagire senza problemi tra loro. Ciò crea un mercato più ampio ed interoperabile.

HotShot è un protocollo di consenso innovativo che privilegia un throughput elevato e una finalizzazione rapida delle transazioni, integrandosi perfettamente con la disponibilità dinamica offerta dal meccanismo di consenso Gasper di Ethereum.

Optimistic Rollup:

Nel contesto dei protocolli di consenso, Optimistic Rollup si riferisce alla capacità di confermare le transazioni non appena le condizioni di rete lo consentono. In circostanze di rete ideali, la conferma può essere quasi istantanea con HotShot. Questo è in netto contrasto con i protocolli in cui i tempi di conferma si basano sugli scenari di rete peggiori, o dove la finalità della transazione è probabilistica.

Disponibilità dinamica e Optimistic Rollup: una sfida

La disponibilità dinamica, una caratteristica chiave del consenso Nakamoto, consente a un protocollo di rimanere operativo anche con una partecipazione sporadica, dove la maggior parte dei nodi potrebbe essere offline in qualsiasi momento. Tuttavia, questa proprietà e l'Optimistic Rollup sono intrinsecamente incompatibili all'interno dei protocolli di consenso. La maggior parte dei protocolli pratici Byzantine Fault Tolerance (BFT), inclusi Tendermint e Casper, non riescono a raggiungere efficacemente nessuna delle due caratteristiche.

HotShot: la soluzione

HotShot si basa sul protocollo HotStuff e lo estende a un setting decentralizzato di Proof-of-Stake con partecipazione dinamica su larga scala, preservando al contempo la responsività ottimistica.

Vantaggi di HotShot:

• Throughput elevato: HotShot è in grado di gestire un elevato volume di transazioni al secondo, rendendolo ideale per applicazioni ad alta scalabilità.

• Finalizzazione rapida: Le transazioni vengono finalizzate rapidamente, offrendo agli utenti un'esperienza fluida e reattiva.

• Disponibilità dinamica: HotShot rimane operativo anche con una partecipazione sporadica dei nodi, garantendo una elevata resilienza.

• Optimistic Rollup: HotShot consente la conferma rapida delle transazioni in condizioni di rete favorevoli.

In sintesi, HotShot rappresenta un passo avanti significativo nella progettazione dei protocolli di consenso, offrendo una combinazione unica di scalabilità, velocità e affidabilità.

La scalabilità nei sistemi di consenso ruota attorno a throughput e latenza. Il throughput è misurato al meglio dalla quantità di dati finalizzati dal sistema per unità di tempo (ad esempio, byte al secondo). Questo approccio è più preciso rispetto alle transazioni al secondo (TPS) in quanto tiene conto delle dimensioni e della complessità variabili delle transazioni. La latenza si riferisce al tempo medio impiegato da una transazione per essere finalizzata dopo l'invio. La sfida principale nella scalabilità dei protocolli di consenso è raggiungere un throughput elevato mantenendo la decentralizzazione e una latenza ragionevolmente bassa.

Il consenso ha un duplice scopo. Garantisce che i nodi partecipanti concordino su un ordinamento delle transazioni e facilita anche la replicazione dello stato del sistema (o almeno un ledger delle transazioni che può essere riprodotto). Sebbene queste funzionalità possano teoricamente essere separate, con potenzialmente diversi set di nodi coinvolti, entrambe tendono ad essere sostanziali e diversificate in un sistema decentralizzato. Pertanto, un aspetto chiave di qualsiasi blockchain decentralizzata è un meccanismo per la propagazione resiliente delle informazioni tra i nodi partecipanti.

I protocolli di comunicazione resilienti (ad esempio, gossip peer-to-peer) sono una delle ragioni per cui le blockchain decentralizzate ottengono un throughput inferiore rispetto ai tradizionali sistemi transazionali "Web2", specialmente quando c'è una significativa eterogeneità tra i nodi partecipanti. Una tipica architettura "Web2" utilizza una configurazione di rete a stella, in cui tutto il traffico viene instradato attraverso server dedicati ad alta larghezza di banda. Ciò ottimizza la comunicazione (in particolare la velocità di trasmissione) in reti in cui la maggior parte dei nodi ha una larghezza di banda inferiore rispetto a questi server centrali. Tuttavia, questo approccio sacrifica la resilienza ai guasti bizantini.

Un vantaggio chiave dei protocolli di consenso a risposta ottimistica come HotStuff è la loro capacità di funzionare meglio in condizioni di rete favorevoli. Tali protocolli possono persino sfruttare un'architettura "Web2" per ottenere un throughput molto elevato in modo ottimistico, ricorrendo nel peggiore dei casi a un metodo basato sul gossip ad alta resilienza e a throughput inferiore. In questo senso, i protocolli a risposta ottimistica hanno il potenziale di offrire il meglio di entrambi i mondi: prestazioni Web2 con sicurezza Web3.

Sebbene il design interno specifico di un rollup vari in base al suo tipo (ZK-rollup vs. Optimistic Rollup, compatibile con EVM vs. applicazione specifica), tutti i rollup condividono alcuni elementi costitutivi fondamentali. Questo documento si concentra sui componenti principali di un rollup base (illustrato nel diagramma qui sotto).

1. API Rollup: Questa è l'interfaccia utilizzata dai client per interagire con il rollup. Può assumere diverse forme, ma JSON-RPC compatibile con Ethereum è una scelta comune. L'API recupera i dati sullo stato del rollup interrogando un database di stato dedicato. Questo database viene popolato dal componente executor, che elabora ogni blocco fornito dal sequencer. Infine, gli aggiornamenti di stato attivano un prover (che potrebbe essere parte di una rete decentralizzata). Questo prover è responsabile della convalida di questi aggiornamenti. Negli ZK-rollup, il prover genera una prova di validità per ogni aggiornamento di stato del blocco. Per gli optimistic rollup, il prover viene attivato solo quando un altro nodo rileva un aggiornamento non valido, inducendolo a creare una prova di frode.

2. Database di stato: Questo database memorizza lo stato corrente del rollup, che è essenzialmente un'istantanea di tutte le transazioni elaborate finora. L'executor popola questo database con aggiornamenti dopo aver elaborato ogni blocco. L'API rollup recupera informazioni sullo stato del rollup interrogando questo database.

3. Esecutore (Executor): Questo componente funge da motore del rollup, responsabile dell'esecuzione di ogni blocco inviato dal sequencer. Durante l'esecuzione, l'executor aggiorna lo stato del rollup in base alle transazioni all'interno del blocco. Questi aggiornamenti vengono quindi riflessi nel database di stato.

4. Prover: Questo componente gioca un ruolo cruciale nel garantire la validità degli aggiornamenti di stato. Negli ZK-rollup, il prover genera una prova crittografica per ogni blocco, dimostrando la correttezza della transizione di stato causata da quel blocco. Gli optimistic rollup utilizzano il prover in modo diverso. Rimane inattivo a meno che un nodo non rilevi un aggiornamento di stato non valido. In tali casi, il prover genera una prova di frode, dimostrando crittograficamente la natura fraudolenta dell'aggiornamento contestato.

5. Sequencer (Opzionale): Sebbene non essenziale per tutti i design dei rollup, un sequencer è un componente comune che esegue diverse funzioni:

   Riceve transazioni dai client.

   Raggruppa queste transazioni in blocchi.

I client possono inviare transazioni direttamente al sequencer, se disponibile. Tuttavia, questo approccio ha dei limiti:

• L'interfaccia del sequencer potrebbe non essere specifica per un particolare rollup.

• I client devono adattare le loro transazioni a un formato generico prima dell'invio.

• Necessita di interagire con due servizi separati (API rollup per le query e sequencer per gli invii). Per ovviare a queste limitazioni, le API rollup spesso includono un'interfaccia di invio transazioni integrata. Ciò semplifica il processo per i client che già utilizzano l'API. Le implementazioni conformi a JSON-RPC sono tenute a fornire tale interfaccia tramite il metodo eth_sendRawTransaction. Indipendentemente dall'interfaccia specifica, l'implementazione può essere abbastanza semplice, in genere comporta l'inserimento di transazioni di rollup in formati generici e l'inoltro al sequencer.

Le transazioni vengono inoltrate tramite l'API del rollup oppure inviate direttamente al sequencer (se disponibile). Il sequencer incorpora queste transazioni in blocchi. Questi blocchi vengono poi elaborati dall'executor e dal prover per gli aggiornamenti di stato e le prove di validità. Infine, il sequencer invia un commitment di blocco e gli elementi di verifica alla chain di livello 1 per la finalizzazione.

Questa suddivisione fornisce una comprensione fondamentale dei componenti principali che costituiscono un sistema di rollup. Comprendendo questi componenti e le loro interazioni, puoi ottenere un apprezzamento più profondo di come funzionano i rollup e di come contribuiscono alla scalabilità della blockchain.

I client possono ottenere rapidamente una forte garanzia di finalità per le loro transazioni. L'inclusione in un blocco sequencer attiva una garanzia di finalità immediata tramite il protocollo di consenso HotShot. Finché nessun attore malintenzionato controlla la maggioranza dello stake di HotShot, la transazione diventa irreversibile. I client con transazioni di valore eccezionalmente elevato possono scegliere di attendere la verifica della catena L1 per una maggiore sicurezza, ma la pre-conferma di HotShot offre una soluzione a bassa latenza e robusta per la maggior parte degli utenti.

A seguito della finalizzazione della transazione, i client potrebbero richiedere l'accesso allo stato aggiornato del rollup per:

• Verificare il risultato dell'esecuzione della loro transazione.

• Preparare transazioni successive.

I client hanno a disposizione diverse opzioni (descritte di seguito) per il recupero dello stato, ciascuna delle quali offre un equilibrio unico tra latenza, presupposti di fiducia e carico di lavoro computazionale.

• Stato pre-confermato da HotShot: I client possono sfruttare la bassa latenza di HotShot per recuperare il blocco pre-confermato ed eseguirlo localmente per calcolare il nuovo stato.

• Affidamento al server rollup: I client possono ottenere un aggiornamento di stato altrettanto rapido fidandosi di un server rollup che ha eseguito la transazione per fornire il nuovo stato, anche prima che venga generata una prova formale di aggiornamento di stato. Questo approccio introduce un presupposto di fiducia aggiuntivo.

• Verifica della prova ZK-rollup: Nel contesto degli ZK-rollup, i client possono attendere che venga generata una prova di aggiornamento di stato e successivamente verificarne la validità. Questo metodo richiede meno calcoli rispetto all'esecuzione locale del blocco e rimane privo di fiducia.

• Stato verificato da L1: I client che preferiscono evitare calcoli complessi o non hanno la capacità di verificare le prove (soprattutto nei rollup ottimistici) possono scegliere di attendere la verifica dello stato dell'aggiornamento sulla chain L1 prima di recuperare lo stato aggiornato. Questo approccio elimina sia la necessità di fiducia in terze parti che il carico di lavoro computazionale per il client.

I blocchi generati dal sequencer possono potenzialmente comprendere transazioni provenienti da più rollup. Per garantirne la corretta esecuzione e verifica, i rollup richiedono meccanismi per dimostrare di aver elaborato tutte le transazioni rilevanti all'interno di un blocco, e solo quelle.

Per facilitare ciò in modo efficiente, ogni transazione inviata dal sequencer è collegata a un identificatore univoco del rollup. I blocchi sequenziati sono strutturati con le transazioni raggruppate in base a questi identificatori. Ciascun blocco possiede anche un impegno (commitment) conciso e univoco che dipende dalle transazioni incluse e da metadati aggiuntivi come l'altezza del blocco e la data/ora. Questo impegno consente la generazione di prove che convincono un verificatore della presenza o dell'assenza di transazioni specifiche all'interno di uno spazio dedicato (rollup) del blocco.

L'immagine mostra la vasta gamma di chain su cui Espresso è interoperabile al momento, la lista è in continua espansione.

Espresso si configura come un progetto ambizioso e in rapida evoluzione, volto a rivoluzionare il modo in cui interagiamo con le blockchain. La sua promessa di interoperabilità abbatte le barriere tra diverse blockchain, permettendo agli utenti di spostare asset e dati in modo fluido e senza soluzione di continuità.

L'impegno di Espresso per la scalabilità, garantita da tecnologie avanzate come Optimistic Rollups, si traduce in un throughput elevato e una bassa latenza, senza sacrificare sicurezza e decentralizzazione. La compatibilità con un'ampia gamma di blockchain, primarie e secondarie, e l'integrazione con diverse soluzioni di scaling, offre agli utenti un accesso a un ecosistema decentralizzato in continua espansione.

Lo sviluppo continuo del progetto, guidato da un team dedicato, testimonia la dedizione alla realizzazione di una visione ambiziosa. Il potenziale di Espresso per rivoluzionare il panorama blockchain è evidente, aprendo nuove possibilità per l'utilizzo di questa tecnologia in una varietà di settori.

Il successo di Espresso dipenderà da diversi fattori, tra cui l'adozione da parte di sviluppatori e utenti, la concorrenza e l'evoluzione del panorama normativo. Tuttavia, le premesse positive e il potenziale dirompente del progetto lo rendono una piattaforma promettente per il futuro interoperabile delle blockchain.

Espresso Systems sta lavorando alacremente per portare le applicazioni Web3 nella vita quotidiana, affrontando sfide che spaziano dalla privacy alla velocità. Un elemento chiave di questo sforzo è lo sviluppo di Espresso Sequencer, un sistema innovativo che mira a rendere i rollup più decentralizzati senza sacrificare la velocità e la scalabilità che gli utenti si aspettano. In altre parole, l'obiettivo è di fornire prestazioni Web2 con la sicurezza Web3.

Componenti di un Rollup:

I rollup sono composti da diversi componenti:

• Macchina virtuale (VM): Esegue le transazioni e aggiorna lo stato del sistema.

• Sequencer: Ordina le transazioni inviate alla VM.

• Sistema di prova: Genera una prova del cambiamento di stato della VM (solo per le VM zk).

• Contratto Rollup su L1: Registra il cambiamento di stato e verifica la prova.

Sequencer Interno vs. Esterno:

Non è sempre necessario un sequencer esterno. In alternativa, si potrebbe utilizzare il contract stesso per ordinare le transazioni. Questo approccio presenta alcuni vantaggi:

• Maggiore fiducia: Gli utenti devono fidarsi solo di L1 per la continuità del sistema.

• Semplicità: Non è necessario un componente aggiuntivo.

Tuttavia, presenta anche alcuni svantaggi:

• Scalabilità limitata: La velocità del sistema rollup è limitata dalla velocità di sequenziamento dei dati di L1.

• Ritardi di conferma: Gli utenti sperimentano gli stessi ritardi nella conferma delle transazioni come su L1.

L'introduzione di un sequencer esterno promette una maggiore velocità e conferme più rapide delle transazioni. In questo scenario, gli utenti possono scegliere di:

• Fidarsi del sequencer: Ottengono una finalità rapida, ma assumono un rischio di fiducia.

• Attendere la conferma da L1: Ottengono una sicurezza garantita, ma con tempi di attesa più lunghi.

Espresso Sequencer:

Espresso Sequencer è progettato per sfruttare i vantaggi di un sequencer esterno, pur mitigando i rischi di fiducia. Attraverso l'utilizzo di tecnologie avanzate come la crittografia e la decentralizzazione, Espresso Sequencer mira a:

• Migliorare la velocità: Offrire transazioni veloci e a bassa latenza.

• Aumentare la scalabilità: Gestire un elevato volume di transazioni senza sacrificare la sicurezza.

• Ridurre i costi: Offrire transazioni a costi accessibili per tutti gli utenti.

• Migliorare la privacy: Proteggere la privacy degli utenti e la riservatezza dei dati.

La blockchain di Ethereum, un tempo simbolo di innovazione, ha faticato a tenere il passo con il proprio successo. L'aumento vertiginoso dell'attività di rete ha portato le commissioni di transazione a livelli esorbitanti, ostacolando l'esperienza utente e limitando la scalabilità delle applicazioni decentralizzate. I rollup sono emersi come una soluzione potente, scaricando l'esecuzione delle transazioni su livelli secondari pur ereditando la sicurezza dalla rete principale di Ethereum. Tuttavia, l'attuale panorama dei rollup, ciascuno con il proprio sequenziatore indipendente, presenta nuove sfide.

Una delle principali preoccupazioni è il potenziale di centralizzazione. Quando una singola entità controlla l'ordinamento delle transazioni su un rollup, crea l'opportunità sia di prezzi monopolistici che di censura. Gli utenti potrebbero dover affrontare commissioni eccessive o, peggio ancora, essere impediti di effettuare transazioni del tutto. Inoltre, la proliferazione di rollup indipendenti porta a un ecosistema frammentato. La liquidità diventa isolata tra le diverse soluzioni L2, ostacolando l'interoperabilità e riducendo l'efficienza complessiva della rete.

Il sequenziamento condiviso offre una soluzione convincente a queste sfide. Abilitando più rollup a sfruttare un singolo sequenziatore decentralizzato, favorisce un ecosistema L2 più efficiente e componibile. Immaginiamo un futuro in cui i rollup funzionino come città-stato all'interno di una nazione più grande, ciascuna con la propria governance unica e focus economico, ma tutte collegate da un'infrastruttura condivisa che facilita l'interazione sicura e senza interruzioni.

I vantaggi del sequenziamento condiviso sono molteplici. Innanzitutto, elimina il rischio di controllo centralizzato. Con un singolo sequenziatore decentralizzato, nessuna singola entità ha il potere di dettare le commissioni di transazione o impedire agli utenti di partecipare alla rete. Ciò favorisce un ambiente L2 più equo e aperto.

Il sequenziamento condiviso rivoluziona anche il bridging tra rollup, ovvero il processo di trasferimento di asset e dati tra diverse soluzioni rollup. Tradizionalmente, questo è stato un processo complesso e ingombrante, che richiede ai rollup di mantenere light client individuali per ciascuna chain interagente. Il sequenziamento condiviso elimina completamente questa necessità. Utilizzando un singolo sequenziatore, i rollup possono interagire senza problemi, portando a:

• Costi di sviluppo e operativi ridotti: i rollup non devono più investire risorse nella creazione e manutenzione di light client separati.

• Latenza dei bridge inferiore: le transazioni cross-rollup non devono più affrontare la latenza aggiuntiva associata all'attesa della finalizzazione su sequenziatori separati.

• Sicurezza migliorata: il sequenziamento condiviso mitiga i rischi sistemici associati ai sequenziatori indipendenti. Derivando lo stato di più rollup da un singolo ledger delle transazioni unificato, diventa molto più difficile sfruttare le vulnerabilità nei bridge tra i rollup.

Forse l'aspetto più trasformativo del sequenziamento condiviso risiede nella sua capacità di sbloccare il potenziale per transazioni atomic cross-rollup. Queste transazioni garantiscono che tutte le operazioni all'interno di un bundle abbiano successo o nessuna lo faccia. Immaginiamo un utente che esegue uno swap cross-rollup tra due diverse soluzioni L2. Con il sequenziamento condiviso, può essere sicuro che entrambi gli asset vengano scambiati o nessuno dei due - eliminando il rischio di una transazione parzialmente completata. Il sequenziamento condiviso facilita due tipi principali di bundle atomici:

• Bundle garantiti crittograficamente: questi bundle offrono solide garanzie di sicurezza attraverso prove crittografiche. Sono ideali per casi d'uso semplici come atomic swaps e scambi NFT tra rollup.

• Bundle economicamente assicurati: questi bundle consentono il soddisfacimento di condizioni più complesse prima dell'esecuzione. Ciò apre le porte a casi d'uso innovativi come opportunità di arbitraggio che comportano l'interazione con protocolli esterni su un rollup.

Le implicazioni del sequenziamento condiviso si estendono ben oltre l'efficienza tecnica. Promuovendo l'interoperabilità e la condivisione della liquidità tra i rollup, apre la strada a un ecosistema L2 veramente unificato. I rollup possono specializzarsi in casi d'uso specifici, sfruttando l'infrastruttura condivisa per interagire senza problemi tra loro. Ciò crea un mercato più ampio ed interoperabile.

HotShot è un protocollo di consenso innovativo che privilegia un throughput elevato e una finalizzazione rapida delle transazioni, integrandosi perfettamente con la disponibilità dinamica offerta dal meccanismo di consenso Gasper di Ethereum.

Optimistic Rollup:

Nel contesto dei protocolli di consenso, Optimistic Rollup si riferisce alla capacità di confermare le transazioni non appena le condizioni di rete lo consentono. In circostanze di rete ideali, la conferma può essere quasi istantanea con HotShot. Questo è in netto contrasto con i protocolli in cui i tempi di conferma si basano sugli scenari di rete peggiori, o dove la finalità della transazione è probabilistica.

Disponibilità dinamica e Optimistic Rollup: una sfida

La disponibilità dinamica, una caratteristica chiave del consenso Nakamoto, consente a un protocollo di rimanere operativo anche con una partecipazione sporadica, dove la maggior parte dei nodi potrebbe essere offline in qualsiasi momento. Tuttavia, questa proprietà e l'Optimistic Rollup sono intrinsecamente incompatibili all'interno dei protocolli di consenso. La maggior parte dei protocolli pratici Byzantine Fault Tolerance (BFT), inclusi Tendermint e Casper, non riescono a raggiungere efficacemente nessuna delle due caratteristiche.

HotShot: la soluzione

HotShot si basa sul protocollo HotStuff e lo estende a un setting decentralizzato di Proof-of-Stake con partecipazione dinamica su larga scala, preservando al contempo la responsività ottimistica.

Vantaggi di HotShot:

• Throughput elevato: HotShot è in grado di gestire un elevato volume di transazioni al secondo, rendendolo ideale per applicazioni ad alta scalabilità.

• Finalizzazione rapida: Le transazioni vengono finalizzate rapidamente, offrendo agli utenti un'esperienza fluida e reattiva.

• Disponibilità dinamica: HotShot rimane operativo anche con una partecipazione sporadica dei nodi, garantendo una elevata resilienza.

• Optimistic Rollup: HotShot consente la conferma rapida delle transazioni in condizioni di rete favorevoli.

In sintesi, HotShot rappresenta un passo avanti significativo nella progettazione dei protocolli di consenso, offrendo una combinazione unica di scalabilità, velocità e affidabilità.

La scalabilità nei sistemi di consenso ruota attorno a throughput e latenza. Il throughput è misurato al meglio dalla quantità di dati finalizzati dal sistema per unità di tempo (ad esempio, byte al secondo). Questo approccio è più preciso rispetto alle transazioni al secondo (TPS) in quanto tiene conto delle dimensioni e della complessità variabili delle transazioni. La latenza si riferisce al tempo medio impiegato da una transazione per essere finalizzata dopo l'invio. La sfida principale nella scalabilità dei protocolli di consenso è raggiungere un throughput elevato mantenendo la decentralizzazione e una latenza ragionevolmente bassa.

Il consenso ha un duplice scopo. Garantisce che i nodi partecipanti concordino su un ordinamento delle transazioni e facilita anche la replicazione dello stato del sistema (o almeno un ledger delle transazioni che può essere riprodotto). Sebbene queste funzionalità possano teoricamente essere separate, con potenzialmente diversi set di nodi coinvolti, entrambe tendono ad essere sostanziali e diversificate in un sistema decentralizzato. Pertanto, un aspetto chiave di qualsiasi blockchain decentralizzata è un meccanismo per la propagazione resiliente delle informazioni tra i nodi partecipanti.

I protocolli di comunicazione resilienti (ad esempio, gossip peer-to-peer) sono una delle ragioni per cui le blockchain decentralizzate ottengono un throughput inferiore rispetto ai tradizionali sistemi transazionali "Web2", specialmente quando c'è una significativa eterogeneità tra i nodi partecipanti. Una tipica architettura "Web2" utilizza una configurazione di rete a stella, in cui tutto il traffico viene instradato attraverso server dedicati ad alta larghezza di banda. Ciò ottimizza la comunicazione (in particolare la velocità di trasmissione) in reti in cui la maggior parte dei nodi ha una larghezza di banda inferiore rispetto a questi server centrali. Tuttavia, questo approccio sacrifica la resilienza ai guasti bizantini.

Un vantaggio chiave dei protocolli di consenso a risposta ottimistica come HotStuff è la loro capacità di funzionare meglio in condizioni di rete favorevoli. Tali protocolli possono persino sfruttare un'architettura "Web2" per ottenere un throughput molto elevato in modo ottimistico, ricorrendo nel peggiore dei casi a un metodo basato sul gossip ad alta resilienza e a throughput inferiore. In questo senso, i protocolli a risposta ottimistica hanno il potenziale di offrire il meglio di entrambi i mondi: prestazioni Web2 con sicurezza Web3.

Sebbene il design interno specifico di un rollup vari in base al suo tipo (ZK-rollup vs. Optimistic Rollup, compatibile con EVM vs. applicazione specifica), tutti i rollup condividono alcuni elementi costitutivi fondamentali. Questo documento si concentra sui componenti principali di un rollup base (illustrato nel diagramma qui sotto).

1. API Rollup: Questa è l'interfaccia utilizzata dai client per interagire con il rollup. Può assumere diverse forme, ma JSON-RPC compatibile con Ethereum è una scelta comune. L'API recupera i dati sullo stato del rollup interrogando un database di stato dedicato. Questo database viene popolato dal componente executor, che elabora ogni blocco fornito dal sequencer. Infine, gli aggiornamenti di stato attivano un prover (che potrebbe essere parte di una rete decentralizzata). Questo prover è responsabile della convalida di questi aggiornamenti. Negli ZK-rollup, il prover genera una prova di validità per ogni aggiornamento di stato del blocco. Per gli optimistic rollup, il prover viene attivato solo quando un altro nodo rileva un aggiornamento non valido, inducendolo a creare una prova di frode.

2. Database di stato: Questo database memorizza lo stato corrente del rollup, che è essenzialmente un'istantanea di tutte le transazioni elaborate finora. L'executor popola questo database con aggiornamenti dopo aver elaborato ogni blocco. L'API rollup recupera informazioni sullo stato del rollup interrogando questo database.

3. Esecutore (Executor): Questo componente funge da motore del rollup, responsabile dell'esecuzione di ogni blocco inviato dal sequencer. Durante l'esecuzione, l'executor aggiorna lo stato del rollup in base alle transazioni all'interno del blocco. Questi aggiornamenti vengono quindi riflessi nel database di stato.

4. Prover: Questo componente gioca un ruolo cruciale nel garantire la validità degli aggiornamenti di stato. Negli ZK-rollup, il prover genera una prova crittografica per ogni blocco, dimostrando la correttezza della transizione di stato causata da quel blocco. Gli optimistic rollup utilizzano il prover in modo diverso. Rimane inattivo a meno che un nodo non rilevi un aggiornamento di stato non valido. In tali casi, il prover genera una prova di frode, dimostrando crittograficamente la natura fraudolenta dell'aggiornamento contestato.

5. Sequencer (Opzionale): Sebbene non essenziale per tutti i design dei rollup, un sequencer è un componente comune che esegue diverse funzioni:

   Riceve transazioni dai client.

   Raggruppa queste transazioni in blocchi.

I client possono inviare transazioni direttamente al sequencer, se disponibile. Tuttavia, questo approccio ha dei limiti:

• L'interfaccia del sequencer potrebbe non essere specifica per un particolare rollup.

• I client devono adattare le loro transazioni a un formato generico prima dell'invio.

• Necessita di interagire con due servizi separati (API rollup per le query e sequencer per gli invii). Per ovviare a queste limitazioni, le API rollup spesso includono un'interfaccia di invio transazioni integrata. Ciò semplifica il processo per i client che già utilizzano l'API. Le implementazioni conformi a JSON-RPC sono tenute a fornire tale interfaccia tramite il metodo eth_sendRawTransaction. Indipendentemente dall'interfaccia specifica, l'implementazione può essere abbastanza semplice, in genere comporta l'inserimento di transazioni di rollup in formati generici e l'inoltro al sequencer.

Le transazioni vengono inoltrate tramite l'API del rollup oppure inviate direttamente al sequencer (se disponibile). Il sequencer incorpora queste transazioni in blocchi. Questi blocchi vengono poi elaborati dall'executor e dal prover per gli aggiornamenti di stato e le prove di validità. Infine, il sequencer invia un commitment di blocco e gli elementi di verifica alla chain di livello 1 per la finalizzazione.

Questa suddivisione fornisce una comprensione fondamentale dei componenti principali che costituiscono un sistema di rollup. Comprendendo questi componenti e le loro interazioni, puoi ottenere un apprezzamento più profondo di come funzionano i rollup e di come contribuiscono alla scalabilità della blockchain.

I client possono ottenere rapidamente una forte garanzia di finalità per le loro transazioni. L'inclusione in un blocco sequencer attiva una garanzia di finalità immediata tramite il protocollo di consenso HotShot. Finché nessun attore malintenzionato controlla la maggioranza dello stake di HotShot, la transazione diventa irreversibile. I client con transazioni di valore eccezionalmente elevato possono scegliere di attendere la verifica della catena L1 per una maggiore sicurezza, ma la pre-conferma di HotShot offre una soluzione a bassa latenza e robusta per la maggior parte degli utenti.

A seguito della finalizzazione della transazione, i client potrebbero richiedere l'accesso allo stato aggiornato del rollup per:

• Verificare il risultato dell'esecuzione della loro transazione.

• Preparare transazioni successive.

I client hanno a disposizione diverse opzioni (descritte di seguito) per il recupero dello stato, ciascuna delle quali offre un equilibrio unico tra latenza, presupposti di fiducia e carico di lavoro computazionale.

• Stato pre-confermato da HotShot: I client possono sfruttare la bassa latenza di HotShot per recuperare il blocco pre-confermato ed eseguirlo localmente per calcolare il nuovo stato.

• Affidamento al server rollup: I client possono ottenere un aggiornamento di stato altrettanto rapido fidandosi di un server rollup che ha eseguito la transazione per fornire il nuovo stato, anche prima che venga generata una prova formale di aggiornamento di stato. Questo approccio introduce un presupposto di fiducia aggiuntivo.

• Verifica della prova ZK-rollup: Nel contesto degli ZK-rollup, i client possono attendere che venga generata una prova di aggiornamento di stato e successivamente verificarne la validità. Questo metodo richiede meno calcoli rispetto all'esecuzione locale del blocco e rimane privo di fiducia.

• Stato verificato da L1: I client che preferiscono evitare calcoli complessi o non hanno la capacità di verificare le prove (soprattutto nei rollup ottimistici) possono scegliere di attendere la verifica dello stato dell'aggiornamento sulla chain L1 prima di recuperare lo stato aggiornato. Questo approccio elimina sia la necessità di fiducia in terze parti che il carico di lavoro computazionale per il client.

I blocchi generati dal sequencer possono potenzialmente comprendere transazioni provenienti da più rollup. Per garantirne la corretta esecuzione e verifica, i rollup richiedono meccanismi per dimostrare di aver elaborato tutte le transazioni rilevanti all'interno di un blocco, e solo quelle.

Per facilitare ciò in modo efficiente, ogni transazione inviata dal sequencer è collegata a un identificatore univoco del rollup. I blocchi sequenziati sono strutturati con le transazioni raggruppate in base a questi identificatori. Ciascun blocco possiede anche un impegno (commitment) conciso e univoco che dipende dalle transazioni incluse e da metadati aggiuntivi come l'altezza del blocco e la data/ora. Questo impegno consente la generazione di prove che convincono un verificatore della presenza o dell'assenza di transazioni specifiche all'interno di uno spazio dedicato (rollup) del blocco.

L'immagine mostra la vasta gamma di chain su cui Espresso è interoperabile al momento, la lista è in continua espansione.

Espresso si configura come un progetto ambizioso e in rapida evoluzione, volto a rivoluzionare il modo in cui interagiamo con le blockchain. La sua promessa di interoperabilità abbatte le barriere tra diverse blockchain, permettendo agli utenti di spostare asset e dati in modo fluido e senza soluzione di continuità.

L'impegno di Espresso per la scalabilità, garantita da tecnologie avanzate come Optimistic Rollups, si traduce in un throughput elevato e una bassa latenza, senza sacrificare sicurezza e decentralizzazione. La compatibilità con un'ampia gamma di blockchain, primarie e secondarie, e l'integrazione con diverse soluzioni di scaling, offre agli utenti un accesso a un ecosistema decentralizzato in continua espansione.

Lo sviluppo continuo del progetto, guidato da un team dedicato, testimonia la dedizione alla realizzazione di una visione ambiziosa. Il potenziale di Espresso per rivoluzionare il panorama blockchain è evidente, aprendo nuove possibilità per l'utilizzo di questa tecnologia in una varietà di settori.

Il successo di Espresso dipenderà da diversi fattori, tra cui l'adozione da parte di sviluppatori e utenti, la concorrenza e l'evoluzione del panorama normativo. Tuttavia, le premesse positive e il potenziale dirompente del progetto lo rendono una piattaforma promettente per il futuro interoperabile delle blockchain.