L'evoluzione "istantanea" di Ethereum: dalla conferma rapida alla compressione del settlement, come Interop elimina i tempi di attesa?

Se spesso ti capita di attraversare le chain tra Base, Arbitrum o Optimism, avrai sicuramente percepito una sottile sensazione di "frammentazione".

Sebbene le transazioni su una singola L2 siano ormai quasi istantanee, quando provi a trasferire asset dalla chain A alla chain B, spesso devi affrontare minuti, se non tempi di attesa ancora più lunghi. Questo non è dovuto alla lentezza delle L2, ma al fatto che, nel processo tradizionale, una transazione che coinvolge più layer e chain deve seguire un percorso lungo e rigoroso:

Ordinamento da parte del sequencer L2 → invio su L1 → consenso e finalizzazione su L1 (Finality), in sintesi, nell’attuale architettura di Ethereum, la finalizzazione su L1 richiede solitamente due Epoch (circa 13 minuti). Questo è senza dubbio necessario per la sicurezza, ma per l’interoperabilità (Interop) risulta troppo lento.

Dopotutto, secondo la grande visione di Ethereum, in futuro esisteranno centinaia o migliaia di L2 che non dovrebbero essere isole isolate, ma lavorare insieme come un unico sistema. La chiave è quindi ridurre il più possibile questo tempo di attesa. 

Proprio in questo contesto, la roadmap Interop di Ethereum, nella fase di Accelerazione, ha identificato tre direzioni di miglioramento altamente coordinate: Fast L1 Confirmation Rule, Shorter L1 Slots, Shorter L2 Settlement.

Si può dire che non si tratta di ottimizzazioni isolate, ma di una vera e propria ricostruzione sistemica attorno a "conferma, ritmo e regolamento".

1. Fast L1 Confirmation Rule: fornire una "risposta affidabile" prima della Finality

Come è noto, nell’attuale architettura di Ethereum, l’intervallo tra i blocchi della mainnet è di circa 12 secondi. I validatori votano sullo stato della chain in ogni slot, mentre la finalizzazione (Finality) avviene dopo diversi slot.

In breve, anche se una transazione è già stata inclusa in un blocco, il sistema deve attendere a lungo prima di essere certo che non verrà riorganizzata o annullata. Attualmente, perché una transazione sia considerata irreversibile, sono necessari circa due Epoch (circa 13 minuti), un tempo troppo lungo per la maggior parte degli scenari finanziari on-chain. 

Possiamo allora fornire un segnale di conferma "abbastanza rapido e affidabile" alle applicazioni e ai sistemi cross-chain prima della Finality? Questo è esattamente ciò che Ethereum ha proposto nella roadmap Interop con il Project #4: Fast L1 Confirmation Rule.

L’obiettivo principale è molto chiaro: consentire ad applicazioni e sistemi cross-chain di ricevere un segnale di conferma L1 "forte e verificabile" entro 15–30 secondi, senza dover attendere i 13 minuti necessari per la Finality completa.

Dal punto di vista del meccanismo, la Fast L1 Confirmation Rule non introduce un nuovo processo di consenso, ma riutilizza i voti degli attester che avvengono in ogni slot nel sistema PoS di Ethereum. Quando un blocco accumula abbastanza voti da validatori sufficientemente distribuiti nei primi slot, può essere considerato "quasi impossibile da annullare sotto un modello di attacco ragionevole", anche se non è ancora stato finalizzato.

In sostanza, questo livello di conferma non sostituisce la Finality, ma fornisce una conferma forte riconosciuta dal protocollo prima della Finality. Questo è particolarmente importante per l’Interop: sistemi cross-chain, Intent Solver e wallet non devono più attendere passivamente la finalizzazione, ma possono procedere in sicurezza al passo successivo entro 15–30 secondi, basandosi su un segnale di conferma a livello di protocollo.

Attualmente, la preconferma (Preconfirmation) promossa dalla narrativa Based Rollup svolge un ruolo di transizione ingegneristica importante in questa direzione. La logica è semplice: immagina che,

quando acquistiamo un biglietto del treno su 12306, una volta selezionato il viaggio e confermato l’ordine (firmando la transazione), il sistema di prenotazione ci fornisce subito una preconferma, informandoci che l’acquisto (cioè ogni transazione) è stato accettato e sta entrando nel processo di conferma. A questo punto possiamo già pianificare il viaggio e preparare i bagagli. Solo quando il biglietto viene definitivamente assegnato (la transazione viene pubblicata su L1), la prenotazione è completata.

In breve, nei Based Rollup, la preconferma è un impegno a includere la transazione in un blocco prima che venga effettivamente inviata su L1, fornendo così all’utente un segnale preliminare che la transazione è stata accettata e sta per essere elaborata.

"Ti do prima una promessa verbale forte, la conferma definitiva arriverà dopo": attraverso questa logica di conferma a livelli, la roadmap Interop di Ethereum suddivide in modo preciso diversi livelli di fiducia tra "sicurezza" e "velocità", costruendo un’esperienza di interoperabilità il più fluida possibile. 

2. Shorter L1 Slot: accelerare il "battito cardiaco" di Ethereum

Insieme alla Fast L1 Confirmation Rule, che rappresenta una "ricostruzione logica a livello di consenso", c’è una modifica ancora più profonda e fisica: ridurre la durata degli slot.

Se la Fast Confirmation è come "emettere una cambiale" prima della finalizzazione, ridurre la durata degli slot L1 significa accorciare direttamente il "ciclo di regolamento" del libro mastro. Nella roadmap Interop, l’obiettivo del Project #5 è chiaro: ridurre la durata degli slot della mainnet Ethereum dagli attuali 12 secondi a 6 secondi.

Questa apparente "dimezzamento" comporta in realtà una reazione a catena su tutta la chain. È facile da capire: slot più brevi significano che le transazioni vengono incluse nei blocchi, distribuite ai validatori e confermate più rapidamente, riducendo la latenza a livello di protocollo.

L’impatto sull’esperienza utente è diretto: le interazioni su L1 (come i trasferimenti ETH) vengono confermate più rapidamente, la frequenza di invio degli stati L2 su L1 aumenta e, combinando slot più brevi con la Fast Confirmation Rule, si ottiene un "feedback quasi in tempo reale on-chain", consentendo a DApp, wallet e protocolli cross-chain di offrire un’esperienza di conferma in pochi secondi.

Per i protocolli di interoperabilità cross-chain, la riduzione dei tempi significa anche un enorme salto nell’efficienza del capitale. Attualmente, i bridge o i market maker devono sostenere il rischio di "capitale in transito" per diversi minuti o più durante la gestione degli asset tra chain diverse. Per coprire il rischio di volatilità in questo periodo, sono costretti a richiedere commissioni più elevate.

Quando il ciclo di regolamento L1 si accorcia e la velocità di rotazione del capitale raddoppia, l’occupazione di capitale in transito diminuisce notevolmente. Il risultato è evidente: costi di frizione più bassi, commissioni utente più basse e tempi di accredito più rapidi. Questo incentiverà fortemente sviluppatori e utenti a tornare al sicuro livello di regolamento L1, invece di affidarsi a relay di terze parti fragili.

Naturalmente, raddoppiare la "frequenza del battito cardiaco" non è facile. Diversi gruppi di lavoro della Ethereum Foundation stanno portando avanti questo complesso progetto:

• Analisi di rete: i team di ricerca (inclusa Maria Silva e altri ricercatori) stanno conducendo analisi dati rigorose per garantire che slot più brevi non aumentino il rischio di riorganizzazione (Reorg) a causa della latenza di rete o creino pressioni di centralizzazione sui nodi domestici con banda limitata;
• Implementazione client: si tratta di una ricostruzione profonda che coinvolge sia il livello di consenso che quello di esecuzione. È importante notare che questo lavoro è indipendente da EIP-7732 (Native Staker - Builder Separation ePBS), il che significa che il piano di accelerazione del battito cardiaco può procedere indipendentemente dall’avanzamento di ePBS;

In generale, quando gli slot da 6 secondi si combinano con la Fast Confirmation Rule, Ethereum potrà davvero offrire un "feedback quasi in tempo reale on-chain", permettendo a dApp e wallet di costruire un’esperienza di conferma in pochi secondi senza precedenti.

3. Shorter L2 Settlement: asset "pronti all’uso"

Nella roadmap Interop, il Project #6: Shorter L2 Settlement è l’aspetto più controverso, ma anche quello con il maggiore potenziale.

Nell’architettura attuale, gli Optimistic Rollup si basano solitamente su un periodo di challenge di 7 giorni, mentre anche gli ZK Rollup sono limitati dai tempi di generazione e verifica delle prove. In termini di sicurezza, questa progettazione è impeccabile, ma a livello di interoperabilità crea un problema concreto:

Gli asset e gli stati vengono "bloccati nel tempo" tra le chain. Questo non solo aumenta i costi cross-chain, ma incrementa notevolmente il carico di ribilanciamento per i Solver, riflettendosi infine in costi più elevati per l’utente. Per questo motivo, la riduzione del ciclo di regolamento è considerata una delle leve chiave per la scalabilità di Interop. Le principali direzioni ingegneristiche attuali includono (per approfondire: ZK Dawn: la roadmap finale di Ethereum sta accelerando?):

• ZK proof in tempo reale: con l’accelerazione hardware e la maturità delle prove ricorsive, i tempi di generazione delle prove stanno passando da minuti a secondi;
• Meccanismi di regolamento più rapidi: ad esempio, l’introduzione di modelli di regolamento sicuri 2-out-of-3;
• Layer di regolamento condiviso: consentire a più L2 di completare le modifiche di stato sotto una semantica di regolamento unificata, invece di "prelievo-attesa-deposito";

Naturalmente, nella discussione su Interop, una domanda centrale è inevitabile: se per ottenere conferme cross-chain più rapide si riduce il periodo di challenge da 7 giorni a 1 ora, si lascia spazio agli attaccanti?

In teoria, questa preoccupazione non è infondata. Diversamente dalla "censura forte" (collusione dei validatori), nella realtà è più insidiosa la censura soft guidata dai block builder: l’attaccante non deve controllare il consenso, basta che continui a superare l’offerta del difensore per impedire che le transazioni chiave vengano incluse on-chain. 

Curiosamente, l’unica analisi economica sistematica di tali scenari proviene dal paper di Offchain Labs pubblicato a febbraio 2025, "Economic Censorship Games in Fraud Proofs". Il paper costruisce tre modelli, dal più pessimista al più ottimista, ipotizzando: 

• Modello G¹: il contenuto del blocco è deciso interamente da chi offre di più;
• Modello G¹ₖ: alcuni validatori costruiscono sempre blocchi localmente;
• Modello Gᵐ: più validatori decidono insieme il contenuto del blocco; basta che uno scelga la transazione del difensore;

Nella pratica, poiché i validatori possono saltare slot (miss slots), alcuni design possono degenerare nello scenario più pessimista G¹, quindi il paper parte dall’analisi del caso peggiore. 

Sulla base di questo, i ricercatori propongono una strategia difensiva molto pragmatica: un meccanismo di difesa ritardata "piccolo contro grande", in cui il difensore ha il diritto di "attivare il ritardo" con un solo click, senza dover completare tutte le verifiche complesse in poco tempo, ma solo inviare una transazione chiave.

Questa transazione chiave ha uno scopo molto chiaro: una volta inclusa on-chain, estende automaticamente il periodo di challenge da 1 ora ai tradizionali 7 giorni. Ad esempio, se il difensore rileva uno stato anomalo su L2, non deve completare tutte le verifiche in 1 ora, ma solo inviare una transazione speciale su L1, che funge da allarme e prolunga immediatamente il periodo di challenge a 7 giorni.

Questo costringe l’attaccante a una guerra di logoramento asimmetrica: per impedire che la transazione venga inclusa on-chain, l’attaccante deve continuare a pagare una priorità superiore a quella del difensore in ogni blocco, mantenendo questa pressione per tutto il periodo di challenge.

I risultati quantitativi del paper sono molto chiari: se un attaccante con grandi risorse è disposto a spendere 10 billions di dollari per una censura continua, allora:

• Nel periodo di 1 ora, il difensore ha bisogno solo di un budget gas di 33 millions di dollari per contrattaccare;
• Se riesce ad attivare il meccanismo di ritardo e prolungare il periodo di challenge a 7 giorni, il costo di difesa scende addirittura a circa 200 mila dollari;

In altre parole, questo è un vantaggio strutturale cruciale: il costo per l’attaccante cresce linearmente, mentre il difensore deve solo riuscire una volta a includere la transazione on-chain.

È proprio questo rapporto tra costo di attacco e costo di difesa (Cost to Attack vs. Cost to Defend) che garantisce che, anche comprimendo drasticamente il ciclo di regolamento, Ethereum mantenga una forte robustezza in termini di sicurezza economica. 

Per Interop, questo è fondamentale: conferma rapida e cicli di regolamento più brevi non devono necessariamente compromettere la sicurezza, e con un design istituzionale ragionevole, conferme cross-chain in pochi secondi e sicurezza economica possono coesistere, fornendo almeno la base più solida per realizzare Interop con conferme cross-chain in pochi secondi.

Considerazioni finali

Qualcuno potrebbe chiedersi: perché impegnarsi tanto per ottimizzare quei pochi secondi o minuti di latenza?

Nell’era geek del Web3, eravamo abituati ad aspettare, persino a considerare "l’attesa" come un prezzo da pagare per la decentralizzazione. Ma nel percorso di Web3 verso il grande pubblico, gli utenti non dovrebbero, né devono preoccuparsi su quale chain stanno operando, né calcolare la logica di finalità di L1.

Conferma rapida, battito cardiaco da 6 secondi e meccanismi di difesa asimmetrici stanno facendo una cosa: eliminare la "variabile tempo" dalla percezione dell’utente.

Come ripeto spesso: la migliore forma della tecnologia è quella in cui la complessità scompare completamente in una conferma ultra-rapida.