Un nuovo pattern architetturale pubblicato su EthResearch il 28 ottobre 2026 propone di ricavare un ruolo di esecuzione intermedio tra l'L1 di Ethereum e i rollup persistenti, definendolo un livello "L1.5". Secondo il progetto, lo stato degli utenti rimane nei wallet, lo stato condiviso risiede sull'L1 di Ethereum, e il calcolo viene delegato a un livello effimero stateless che produce una prova di validità e poi scompare, senza lasciare obblighi di stato residui sulla rete. La proposta completa è disponibile su EthResearch, il forum pubblico dove i ricercatori di Ethereum pubblicano e discutono idee protocolliari in fase preliminare prima che inizi qualsiasi implementazione.

Punti Chiave

• L'etichetta L1.5 è una definizione architetturale, non un nuovo livello protocolliare canonico di Ethereum. Descrive un ambiente di calcolo temporaneo che si regola sull'L1 senza persistere il proprio stato tra un lavoro e l'altro.
• Il modello è pensato per contesti di esecuzione delimitati, come sessioni specifiche di applicazioni o finestre di eventi ad alta intensità, nei quali un operatore di rollup di lunga durata rappresenterebbe un overhead non necessario.
• L'implementazione dipende da due EIP in stato Draft, EIP-8141 ed EIP-8288, il che significa che L1.5 è una proposta di ricerca subordinata a futuri lavori sul protocollo di Ethereum, non una funzionalità già implementata.

Perché gli Ephemeral Rollup Vengono Presentati come L1.5 di Ethereum

Il post su EthResearch del 28 ottobre 2026 introduce L1.5 come pattern di design, non come emendamento al protocollo. L'affermazione centrale è che non ogni calcolo necessita di un ambiente di esecuzione di lunga durata con sequencer, bridge e commitment di stato persistenti. Alcuni carichi di lavoro sono delimitati per definizione, e forzarli attraverso un L2 permanente introduce un overhead infrastrutturale non necessario. Questa impostazione si posiziona in contrapposizione alla roadmap rollup-centric che ha guidato la strategia di scaling di Ethereum dal 2020, nell'ambito della quale l'esecuzione è stata in gran parte delegata alle reti L2 persistenti, mentre l'L1 funge da livello di regolamento e data availability.

Cosa Rende un Rollup Effimero

Secondo la proposta, un lavoro L1.5 idoneo deve soddisfare quattro proprietà: deve essere stateless tra i lavori, verificato dall'L1, pagato senza collegare l'utente a un'identità persistente, e regolato senza richiedere un operatore di lunga durata. Il livello di calcolo effimero riceve uno snapshot di stato, esegue, e restituisce un nuovo stato più una prova di validità—un'attestazione crittografica che consente all'L1 di confermare che un calcolo è stato eseguito correttamente senza doverlo rieseguire. Non conserva nulla di cui il lavoro successivo necessiti.

Questo è una netta rottura rispetto al funzionamento dei rollup persistenti. Un sequencer di Optimism o Arbitrum mantiene un albero di stato continuo, gestisce le reorg e si coordina con sistemi di fraud proof o validity proof su un orizzonte temporale indefinito. Il modello L1.5 scarta deliberatamente quella continuità, trattando ogni lavoro come un'unità di lavoro isolata.

Come si Relazionano L1, il Livello Effimero e gli Utenti

Il modello di custodia dello stato proposto suddivide le responsabilità in modo preciso. I wallet conservano lo stato di proprietà degli utenti, mentre l'L1 di Ethereum detiene lo stato condiviso, inclusi commitment e nullifier, e verifica ogni transizione di stato. Il livello di calcolo effimero si colloca in mezzo: riceve gli input, esegue, ed emette una prova che l'L1 può verificare. Una volta completato il regolamento, l'ambiente effimero viene ritirato.

Questo assetto è distinto sia dalla pura esecuzione su L1, limitata dai gas limit per blocco e dalla throughput di sequenziamento, sia dagli L2 convenzionali, che richiedono un operatore persistente, un bridge attivo e una radice di stato canonica mantenuta attraverso una catena di blocchi indefinita. La definizione di L1.5 descrive un ruolo di calcolo che viene convocato per un lavoro specifico e poi dissolto.

Ethereum viene scambiato a 2.354,52 dollari, in rialzo del 2,04% nelle ultime 24 ore, con una capitalizzazione di mercato di circa 287,7 miliardi di dollari, secondo CoinGecko, e fornisce lo scenario economico rispetto al quale vengono valutate le proposte per migliorare la throughput di esecuzione di Ethereum. Il più ampio indice di sentiment crypto si registra a 51, una lettura Neutra che non riflette né euforia né paura mentre la ricerca entra in fase di revisione pubblica.

Non è emerso alcun commento sociale verificato da esperti sulla proposta dalla pubblicazione, in coerenza con l'assenza di una finestra di reazione pubblica ampia per un post di ricerca pubblicato lo stesso giorno. La base di sentiment Neutro riflette l'ecosistema nel suo complesso piuttosto che una specifica accoglienza di questa proposta architetturale.

I Trade-off Infrastrutturali: Velocità, Composabilità e Regolamento

Possibili Casi d'Uso: Contesti di Esecuzione Delimitati

Il design effimero si adatta naturalmente ai carichi di lavoro ad alta intensità e delimitati nel tempo: una finestra di esecuzione di una votazione di governance, una sessione di regolamento batch per una camera di compensazione di derivati, o un aggiornamento di stato di un gioco specifico di un'applicazione. In questi contesti, avviare un L2 completo con un sequencer e un bridge canonico imporrebbe un costo di coordinamento superiore a quanto l'esecuzione stessa giustifichi.

I protocolli che già gestiscono una domanda on-chain a intermittenza, come i money market che attraversano cascate di liquidazioni o gli aggiornamenti dei parametri di rischio guidati dalla governance di Aave, rappresentano la classe di carichi di lavoro per i quali un'esecuzione isolata e ad alta throughput seguita da un regolamento pulito ridurrebbe la congestione dell'L1 senza richiedere un deployment L2 permanente. La proprietà chiave è che l'applicazione non necessita che il proprio stato persista per un tempo illimitato; necessita di un'esecuzione corretta e verificabile per un ambito di lavoro definito.

Latenza, Sequenziamento, Sincronizzazione dello Stato e Finalità

Le domande pratiche per chiunque valuti questo pattern riguardano il modo in cui lo stato viene trasferito dentro e fuori dall'ambiente effimero. La suddivisione dello stato proposta assegna commitment e nullifier condivisi all'L1, ma la latenza del bridge tra lo stato detenuto nel wallet dell'utente e il contesto di esecuzione del livello effimero è un problema di sequenziamento che le singole implementazioni dovranno risolvere. Anche il tempo di generazione delle prove è rilevante: se il livello effimero deve produrre una prova di validità prima che l'L1 finalizza il risultato, la latenza end-to-end ha come limite inferiore la velocità di costruzione della prova.

È qui che la dipendenza dagli EIP in bozza diventa determinante. EIP-8141, una proposta Draft Core nel percorso di standardizzazione creata il 29 gennaio 2026, introduce le frame transaction con logica astratta di validazione e pagamento del gas, che copre le modalità di frame VERIFY e SENDER. Senza di essa, la proprietà di pagamento senza identità persistente richiesta dal modello L1.5 non ha alcun hook nativo sull'L1 a cui agganciarsi.

EIP-8288, creata il 3 giugno 2026 e anch'essa Draft Core, estende l'EIP-8141 con un'aggregazione ricorsiva basata su STARK per firme e prove STARK, e rende uno STARK ricorsivo un requisito per la validità dei blocchi. Gli STARK—scalable transparent arguments of knowledge—sono una classe di prove di validità che possono essere verificate a un costo molto inferiore rispetto a quello di rieseguire il calcolo che attestano. Questo è il livello di aggregazione delle prove che consentirebbe all'output dell'ephemeral rollup di essere verificato in modo efficiente sull'L1 senza consumare gas sproporzionato per ogni lavoro. Entrambi gli EIP sono in stato Draft, il che significa che nessuno dei due è programmato per un hard fork specifico; secondo il processo di miglioramento di Ethereum, le proposte avanzano attraverso le fasi Draft, Review, Last Call e Final, e uno standard entra in vigore solo quando viene incluso in un upgrade di rete.

Rischio di Composabilità e Frammentazione della Liquidità

L'esecuzione delimitata comporta un costo di composabilità che anche gli L2 persistenti sostengono, ma con un profilo diverso. Un L2 di lunga durata accumula TVL e liquidità nel tempo, costruendo profondità di composabilità all'interno del proprio ambiente. Un ephemeral rollup, per design, non detiene liquidità persistente: ogni lavoro parte da uno snapshot di stato fresco e si regola sull'L1. Per i protocolli in cui la composabilità tra più contratti in una singola transazione è un'aspettativa centrale degli utenti, come il routing DEX multi-hop o le liquidazioni supportate da flash loan, il vincolo stateless-between-jobs del modello effimero limita il tipo di interazioni eseguibili all'interno del perimetro di un singolo lavoro.

La proposta non presenta questo come un difetto ma come un confine di design. Il pattern L1.5 non è inteso a sostituire gli ambienti di esecuzione L2 di uso generale. È rivolto alla classe di carichi di lavoro che possono essere interamente specificati in anticipo, eseguiti atomicamente e regolati in modo pulito. Si tratta di uno spazio problematico più ristretto di quello affrontato da Optimism o Arbitrum, ma anche di uno in cui l'infrastruttura attuale è discutibilmente sovradimensionata.

Il grado in cui questa impostazione avrà successo nella pratica sarà determinato dal fatto che EIP-8141 ed EIP-8288 avanzino nel processo di miglioramento di Ethereum, e dal fatto che gli sviluppatori di applicazioni trovino il vincolo stateless-between-jobs accettabile per i loro specifici pattern di carico di lavoro. I builder che operano su infrastrutture L2 emergenti, come quelli che attualmente migrano contratti di staking tra Arbitrum e Avalanche, illustrano la complessità operativa che deriva dalla gestione dello stato attraverso ambienti di rollup persistenti. Il modello L1.5 offre un'inquadratura alternativa per i lavori in cui quella gestione continua dello stato è il problema da evitare, non una funzionalità da sfruttare.

Prospettive

Il post di ricerca presenta L1.5 come un contributo al lessico architetturale piuttosto che come un annuncio di deployment. La sua validità come pattern pratico dipende dalla finalizzazione di due EIP in stato Draft, dal fatto che la latenza di generazione delle prove corrisponda ai requisiti di throughput dei casi d'uso target, e dall'accettazione da parte degli sviluppatori di applicazioni dei trade-off di composabilità imposti dall'esecuzione stateless. Lo stato di entrambe le proposte è tracciato pubblicamente sul sito degli EIP di Ethereum, quindi la loro progressione nella standardizzazione è direttamente osservabile man mano che il processo di miglioramento avanza. Finché EIP-8141 ed EIP-8288 non usciranno dallo stato Draft, il design L1.5 rimarrà una proposta su ciò che lo stack di esecuzione di Ethereum potrebbe supportare, non una descrizione di ciò che fa attualmente.