Nowy wzorzec architektoniczny opublikowany na EthResearch 28 października 2026 r. proponuje wydzielenie pośredniej roli wykonawczej między L1 Ethereum a trwałymi rollupami, określając ją jako warstwę „L1.5”. Zgodnie z projektem stan użytkownika pozostaje w portfelach, stan współdzielony znajduje się na L1 Ethereum, a obliczenia są delegowane do bezstanowej warstwy efemerycznej, która produkuje dowód ważności, po czym znika, nie pozostawiając sieci żadnych rezydualnych zobowiązań stanowych. Pełna propozycja jest dostępna na EthResearch, publicznym forum, na którym badacze Ethereum publikują i omawiają wczesne koncepcje protokołów, zanim rozpoczną się jakiekolwiek prace wdrożeniowe.

Kluczowe punkty

• Nazwa L1.5 to ramy architektoniczne, a nie nowa kanoniczna warstwa protokołu Ethereum. Opisuje tymczasowe środowisko obliczeniowe, które rozlicza się z powrotem na L1 bez utrzymywania własnego stanu między zadaniami.
• Model jest zaprojektowany dla ograniczonych kontekstów wykonania, takich jak sesje specyficzne dla aplikacji czy intensywne okna zdarzeń, gdzie długotrwały operator rollupu byłby zbędną nadmiarowością.
• Wdrożenie zależy od dwóch propozycji EIP w statusie Draft, EIP-8141 i EIP-8288, co oznacza, że L1.5 to propozycja badawcza uzależniona od przyszłych prac nad protokołem Ethereum, a nie wdrożona funkcja.

Dlaczego efemeryczne rollupy są przedstawiane jako L1.5 Ethereum

Post na EthResearch z 28 października 2026 r. wprowadza L1.5 jako wzorzec projektowy, a nie nowelizację protokołu. Główna teza brzmi, że nie każde obliczenie wymaga długotrwałego środowiska wykonania z sekwencerem, mostem i trwałymi zobowiązaniami stanowymi. Niektóre obciążenia są z definicji ograniczone, a przepuszczanie ich przez trwałe L2 wprowadza zbędną nadmiarowość infrastruktury. Ujęcie to pozycjonuje się w opozycji do roadmapy skoncentrowanej na rollupach, która kierowała strategią skalowania Ethereum od 2020 r. i zgodnie z którą wykonanie zostało w zasadzie zdelegowane do trwałych sieci L2, podczas gdy L1 służy jako warstwa rozliczeniowa i dostępności danych.

Co czyni rollup efemerycznym

Zgodnie z propozycją kwalifikujące się zadanie L1.5 musi spełniać cztery właściwości: musi być bezstanowe między zadaniami, weryfikowane przez L1, opłacane bez wiązania użytkownika z trwałą tożsamością oraz rozliczane bez wymagania długotrwałego operatora. Efemeryczna warstwa obliczeniowa przyjmuje migawkę stanu, wykonuje obliczenia i zwraca nowy stan wraz z dowodem ważności — kryptograficznym zaświadczeniem, które pozwala L1 potwierdzić poprawność wykonania obliczenia bez jego ponownego uruchamiania. Nie zachowuje niczego, czego wymagałoby następne zadanie.

To ostra odmienność od działania trwałych rollupów. Sekwencer Optimism czy Arbitrum utrzymuje ciągłe drzewo stanu, zarządza reorganizacjami i koordynuje się z systemami dowodów oszustw lub dowodów ważności w nieograniczonym horyzoncie czasowym. Model L1.5 świadomie odrzuca tę ciągłość, traktując każde zadanie jako izolowaną jednostkę pracy.

Jak relacjonują się L1, warstwa efemeryczna i użytkownicy

Proponowany model przechowywania stanu precyzyjnie dzieli odpowiedzialności. Portfele przechowują stan należący do użytkowników, podczas gdy L1 Ethereum utrzymuje stan współdzielony, w tym commitmenty i nullifiery, oraz weryfikuje każdą zmianę stanu. Efemeryczna warstwa obliczeniowa znajduje się pomiędzy: przyjmuje dane wejściowe, uruchamia wykonanie i emituje dowód, który L1 może zweryfikować. Po zakończeniu rozliczenia środowisko efemeryczne zostaje wycofane.

Ten układ różni się zarówno od czystego wykonania na L1, które jest ograniczone limitami gazu bloku i przepustowością sekwencjonowania, jak i od konwencjonalnych L2, które wymagają trwałego operatora, działającego mostu i kanonicznego korzenia stanu utrzymywanego w nieograniczonym łańcuchu bloków. Ujęcie L1.5 opisuje rolę obliczeniową, która jest przywoływana dla konkretnego zadania, po czym ulega rozwiązaniu.

Ethereum notowane jest na poziomie 2 354,52 USD, w górę o 2,04% w ciągu ostatnich 24 godzin, przy kapitalizacji rynkowej wynoszącej około 287,7 mld USD, według CoinGecko, co stanowi tło ekonomiczne, na którym oceniane są propozycje poprawy przepustowości wykonania Ethereum. Szerszy indeks nastrojów kryptowalutowych wynosi 51 — odczyt Neutralny, który nie odzwierciedla ani euforii, ani strachu, gdy badania wchodzą w fazę publicznej oceny.

Od momentu publikacji nie pojawiły się żadne zweryfikowane komentarze ekspertów w mediach społecznościowych dotyczące propozycji, co jest zgodne z brakiem szerokiego okna reakcji publicznej dla posta badawczego opublikowanego tego samego dnia. Neutralny poziom nastrojów odzwierciedla ekosystem jako całość, a nie konkretne przyjęcie tej propozycji architektonicznej.

Kompromisy infrastrukturalne: szybkość, kompozycyjność i rozliczanie

Potencjalne przypadki użycia: ograniczone konteksty wykonania

Projekt efemeryczny naturalnie pasuje do intensywnych, ograniczonych czasowo obciążeń: okna wykonania głosowania governance, sesji rozliczeń batchowych dla izby rozliczeniowej instrumentów pochodnych czy aktualizacji stanu gry specyficznej dla aplikacji. W tych kontekstach uruchomienie pełnego L2 z sekwencerem i mostem kanonicznym generowałoby większy koszt koordynacji, niż na to zasługuje samo wykonanie.

Protokoły, które już radzą sobie z impulsowym popytem on-chain, takie jak rynki pieniężne obsługujące kaskady likwidacji czy aktualizacje parametrów ryzyka sterowane governance w Aave, reprezentują klasę obciążeń, dla których izolowane wykonanie o wysokiej przepustowości, zakończone czystym rozliczeniem, zmniejszyłoby obciążenie L1 bez konieczności trwałego wdrożenia L2. Kluczową właściwością jest to, że aplikacja nie potrzebuje, aby jej stan utrzymywał się w nieograniczonym czasie; potrzebuje poprawnego, weryfikowalnego wykonania w ramach określonego zakresu zadania.

Opóźnienia, sekwencjonowanie, synchronizacja stanu i finalność

Praktyczne pytania dla każdego dewelopera oceniającego ten wzorzec koncentrują się na tym, jak stan jest przekazywany do efemerycznego środowiska i z niego z niego wyprowadzany. Podział stanu w propozycji przypisuje współdzielone commitmenty i nullifiery do L1, ale opóźnienie mostu między stanem trzymanym w portfelu użytkownika a kontekstem wykonania warstwy efemerycznej to problem sekwencjonowania, który poszczególne implementacje będą musiały rozwiązać. Istotny jest też czas generowania dowodu: jeśli warstwa efemeryczna musi wytworzyć dowód ważności, zanim L1 zfinalizuje wynik, opóźnienie end-to-end jest ograniczone od dołu przez szybkość konstrukcji dowodu.

Tu zależność od projektów EIP w statusie Draft staje się kluczowa. EIP-8141, propozycja standardowa Draft Core utworzona 29 stycznia 2026 r., wprowadza transakcje ramkowe z abstrakcyjną logiką walidacji i płatności gazu, obejmującą tryby ramek VERIFY i SENDER. Bez niej właściwość płatności bez trwałej tożsamości, której wymaga model L1.5, nie ma natywnego haka na L1, do którego można się podpiąć.

EIP-8288, utworzony 3 czerwca 2026 r., również w statusie Draft Core, rozszerza EIP-8141 o rekurencyjną agregację podpisów i dowodów STARK opartą na STARK-ach oraz czyni rekurencyjny STARK wymogiem ważności bloku. STARK-i — skalowalne przejrzyste argumenty wiedzy — to klasa dowodów ważności, których weryfikacja jest znacznie tańsza niż ponowne uruchomienie obliczeń, których dotyczą. To warstwa agregacji dowodów, która pozwoliłaby efektywnie weryfikować wynik efemerycznego rollupu na L1 bez zużywania nieproporcjonalnego gazu na zadanie. Oba EIP-y mają status Draft, co oznacza, że żaden nie jest zaplanowany na konkretny hard fork; zgodnie z procesem ulepszania Ethereum propozycje przechodzą przez etapy Draft, Review, Last Call i Final, a standard wchodzi w życie dopiero po włączeniu go do aktualizacji sieci.

Ryzyko kompozycyjności i fragmentacja płynności

Ograniczone wykonanie wiąże się z kosztem kompozycyjności, który niesieją też trwałe L2, ale w innym profilu. Długotrwałe L2 akumuluje w czasie TVL i płynność, budując głębię kompozycyjności we własnym środowisku. Efemeryczny rollup z założenia nie utrzymuje trwałej płynności: każde zadanie zaczyna od świeżej migawki stanu i rozlicza się z powrotem na L1. W przypadku protokołów, w których kompozycyjność między wieloma kontraktami w ramach jednej transakcji jest podstawowym oczekiwaniem użytkowników, takich jak routing DEX wieloskokowy czy likwidacje zabezpieczone flash loanami, ograniczenie bezstanowości między zadaniami w modelu efemerycznym ogranicza typ interakcji, które można wykonać w ramach pojedynczego zakresu zadania.

Propozycja nie przedstawia tego jako wady, lecz jako granicę projektu. Wzorzec L1.5 nie ma zastępować ogólnego przeznaczenia środowisk wykonania L2. Jest przeznaczony dla klasy obciążeń, które można w pełni zdefiniować z góry, wykonać atomowo i czysto rozliczyć. To węższa przestrzeń problemowa niż ta, którą zajmują się Optimism czy Arbitrum, ale jest to również obszar, w którym obecna infrastruktura jest — można argumentować — przeprojektowana.

Stopień, w jakim to ujęcie sprawdzi się w praktyce, zależy od tego, czy EIP-8141 i EIP-8288 przejdą przez proces ulepszania Ethereum, oraz od tego, czy deweloperzy aplikacji uznają ograniczenie bezstanowości między zadaniami za akceptowalne dla swoich wzorców obciążeń. Deweloperzy wdrażający na nowej infrastrukturze L2, tacy jak ci, którzy obecnie migrują kontrakty stakingowe między Arbitrum i Avalanche, ilustrują złożoność operacyjną związaną z zarządzaniem stanem w środowiskach trwałych rollupów. Model L1.5 oferuje alternatywne ujęcie dla zadań, w których ciągłe zarządzanie stanem jest problemem, którego się pozbywamy, a nie funkcją, którą się wykorzystuje.

Perspektywy

Post badawczy przedstawia L1.5 jako wkład do słownictwa architektonicznego, a nie zapowiedź wdrożenia. Jego zasadność jako praktycznego wzorca zależy od finalizacji dwóch EIP w statusie Draft, od dopasowania opóźnień generowania dowodów do wymagań przepustowościowych docelowych zastosowań oraz od akceptacji przez deweloperów aplikacji kompromisów kompozycyjności, które narzuca wykonanie bezstanowe. Status obu propozycji jest publicznie śledzony na stronie EIP Ethereum, więc ich postępy w standaryzacji są bezpośrednio obserwowalne w miarę postępu procesu ulepszania. Dopóki EIP-8141 i EIP-8288 nie opuszczą statusu Draft, projekt L1.5 pozostaje propozycją tego, co stack wykonania Ethereum mógłby obsługiwać, a nie opisem tego, co obecnie robi.