Projekt propozycji otwarty przez badaczy Ethereum 21 października ma skrócić oczekiwany czas finalizacji transakcji w sieci z około 16 minut do około czterech, przekształcając dwa procesy głosowania konsensusu w osobne strumienie komunikatów. Projekt Decoupled Consensus pozostaje otwarty i nie został scalony.

Ben Edgington, który opisuje swoją rolę jako koordynowanie prac Ethereum nad szybką finalizacją, otworzył pull request i współtworzył projekt z Francesco D'Amato, Roberto Saltinim, Yannem Vonlanthenem i Mikhaiłem Kalininem. W jego nocie do zgłoszenia napisano, że „wiele aspektów pozostaje TBD”, a bezpośrednim celem jest uzyskanie numeru EIP. Recenzent w repozytorium EIPs zaproponował tego samego dnia numer 8453 i poprosił autorów o otwarcie wątku dyskusyjnego na Ethereum Magicians, forum, na którym omawia się propozycje.

Dlaczego finalizacja nadal zajmuje około 16 minut

Finalizacja oznacza moment, przed którym walidatorzy Ethereum nie odwrócą bloków. Osiągnięcie jej wymaga dwóch rund głosowania — jednej do uzasadnienia checkpointu i drugiej do jego finalizacji — a każda runda trwa epokę obejmującą 32 sloty po 12 sekund. W poście z 11 maja na blogu Ethereum Foundation poświęconym konsensusowi protokołu Edgington określił minimum na 768 sekund, a oczekiwany czas dla transakcji na około 960 sekund; w normalnych warunkach od 63 do 95 najnowszych bloków nie jest sfinalizowanych.

Te najnowsze bloki mogą nadal zostać zreorganizowane: węzły mogą przełączyć się na konkurencyjną sekwencję bloków, a transakcje z odrzuconych bloków wrócą do mempoola, by zostać uwzględnione ponownie. Sfinalizowane bloki są znacznie trudniejsze do zmiany. Ich odwrócenie wymagałoby od atakujących posiadania ponad jednej trzeciej całego stake'u, a kosztowałoby ich co najmniej jedną trzecią wszystkich stakowanych ETH w wyniku slashingu.

Ten sam post opisuje zasadę szybkiego potwierdzenia, zaprojektowaną jako wcześniejszy sygnał. Gdy sieć działa prawidłowo i żaden atakujący nie jest zbyt silny, zasada powinna w ciągu około 13 sekund wskazać, że blok nie zostanie zreorganizowany. Nie wiąże się ona z karą ekonomiczną dla atakujących i nie toleruje opóźnień sieci, dlatego podczas problemów z siecią przechodzi do pełnej finalizacji — dokładnie wtedy, gdy usługi najbardziej potrzebują pewności.

Usługi działające na transakcjach Ethereum wybierają więc, jak dużą część oczekiwania na finalizację są gotowe zaakceptować. W poście wymieniono kilka przykładów, w tym Cross-Chain Transfer Protocol (CCTP) firmy Circle dla USDC. (Źródło: Ben Edgington, blog Ethereum Foundation poświęcony konsensusowi protokołu, maj 2026 r.)

Szybsza finalizacja zmniejszyłaby różnicę między tymi ścieżkami zarówno w przypadku mostów stablecoinów, jak i nowszych produktów tokenizowanych, takich jak depozyty bankowe, które JPMorgan wprowadza do Ethereum. Edgington oczekuje, że najbardziej widoczne korzyści odczuje interoperacyjność między łańcuchami.

Jedna atestacja staje się dwoma komunikatami

Obecny projekt konsensusu Ethereum, Gasper, łączy dwa głosy w każdej atestacji walidatora. Jeden zasila LMD GHOST, regułę wyboru gałęzi, która wskazuje kolejnemu proposerowi, na którym bloku ma budować. Drugi zasila Casper FFG, wolniejszy proces finalizujący checkpointy. Ponieważ oba głosy są przesyłane razem, wybór gałęzi korzysta z atestacji około 30 000 walidatorów na slot, choć badacze stojący za projektem twierdzą, że wystarczyłaby znacznie mniejsza liczba.

Projekt EIP przekształca te głosy w osobne komunikaty, które są przesyłane przez sieć i przetwarzane niezależnie:

• Głosy dotyczące głowy łańcucha. Komitet około 512 walidatorów na slot, wybieranych z prawdopodobieństwem proporcjonalnym do efektywnego salda każdego walidatora — stake'u uznawanego przez protokół — decyduje, który blok jest głową łańcucha i które najnowsze bloki są potwierdzone.
• Atestacje finalności. Cały zestaw walidatorów decyduje, które bloki są uzasadnione i sfinalizowane, w rundach działających według własnego harmonogramu, przy czym każdy krok wymaga co najmniej dwóch trzecich aktywnego stake'u.

Dzięki własnemu harmonogramowi runda finalizacji może wykorzystywać przepustowość przez cały okres głosowania i zostać później skrócona bez przeprojektowywania działania slotów. Początkowym celem autorów jest co najmniej czterokrotne skrócenie czasu do finalizacji, zależne od parametrów, których jeszcze nie określili. W odniesieniu do dzisiejszego oczekiwania wynoszącego 16 minut czterokrotne skrócenie oznaczałoby około czterech minut, choć sam projekt nie podaje konkretnej wartości.

Jak czterokrotne skrócenie wpisuje się w dłuższy plan

W tym samym majowym poście Edgington przedstawił długoterminową ambicję: skrócenie czasu do finalizacji z około 1 000 sekund do około 10 sekund. Zaznaczył, że jest to jego osobisty pogląd, a nie oficjalna mapa drogowa.

Napisał, że wcześniejsze projekty, takie jak finalizacja w jednym slocie i w trzech slotach, zakończyły się niepowodzeniem, ponieważ wymagały rozwiązania wszystkich problemów jednocześnie. Nowe podejście dzieli prace na etapy. „Decoupled finality is the big unlock” — napisał, oczekując, że sam ten krok przyniesie przyspieszenie o niewielką jednocyfrową wielokrotność, zgodnie z czterokrotnym celem projektu. Kolejne usprawnienia wynikałyby z odrębnych aktualizacji:

• Konsolidacja walidatorów: od aktualizacji Electra duzi operatorzy mogą łączyć do 64 walidatorów w jeden, zmniejszając liczbę głosów finalności. Edgington określił postęp jako powolny.
• Grupowanie głosów u źródła: operatorzy prowadzący wiele walidatorów za jednym węzłem łączyliby swoje głosy przed ich rozgłoszeniem.
• Rotacja zestawu walidatorów: w danym momencie w finalizacji uczestniczyłby tylko podzbiór walidatorów, bez wykluczania kogokolwiek i bez ustalania limitów.
• Szybsza sieć i agregacja: usprawnienia peer-to-peer oraz agregacja oparta na SNARK-ach pozwoliłyby sprawniej przesyłać głosy.
• Finalizacja w jednej rundzie: jedna runda głosowania zamiast dwóch niemal skróciłaby oczekiwanie o połowę, ale obniżyłaby tolerancję błędów z jednej trzeciej stake'u do być może 20% lub 17%.

Sam projekt nie obejmuje żadnego z tych kroków. Według obliczeń Edgingtona cztery usprawnienia, z których każde zapewniłoby trzykrotny wzrost, zbliżyłyby się do ambicji stukrotnego przyspieszenia. Zauważył również, że mapa drogowa Strawmap wymieniała decoupled consensus jako głównego kandydata do aktualizacji wstępnie oznaczonej jako I*, prawdopodobnie w 2027 r., jako cel ambitny.

Dlaczego Ethereum nie zatrzyma się, aby działać szybciej

Klasyczne protokoły bizantyjskiej odporności na błędy, takie jak Tendermint, szybko finalizują bloki, ale przestają je produkować, gdy zbyt wielu walidatorów przechodzi offline. Badacz Luca Zanolini argumentował w marcowym poście na forum Ethereum Research, że zatrzymywanie sieci jest niezgodne z projektem Ethereum. Wskazał na udowodnione ograniczenie znane jako dylemat dostępności i finalności: żaden pojedynczy protokół nie może jednocześnie rozwijać się przy zmiennym uczestnictwie i zachowywać bezpieczeństwa podczas podziału sieci. Odpowiedzią Ethereum jest jedna warstwa, która nadal buduje bloki z udziałem dostępnych walidatorów, oraz druga, która finalizuje bloki za nią.

Zanolini odwołał się do historii sieci. W maju 2023 r. błędy w klientach Prysm i Teku, które łącznie obsługiwały ponad połowę walidatorów, zakłóciły finalizację i uruchomiły pierwszy wyciek nieaktywności w sieci głównej Ethereum. Propozycje bloków nigdy nie spadły poniżej około 90% slotów, a transakcje nadal były przetwarzane. Dla porównania, podczas zatrzymania Solany w lutym 2024 r. przez pięć godzin nie powstał żaden blok, przez co protokoły DeFi w tej sieci nie mogły działać.

Decoupled Consensus zachowuje ten układ. Finalizacja nadal wymaga kworum dwóch trzecich, dlatego wystarczająco duża awaria może ją zatrzymać, podczas gdy pozostali walidatorzy nadal budują bloki. Większość aplikacji może nadal działać, ale wszystko, co wymaga ostatecznego rozliczenia, musi czekać. Jeśli uczestnictwo nie wróci do normy, wyciek nieaktywności będzie stopniowo zmniejszał stake nieaktywnych walidatorów, aż finalizacja będzie mogła zostać wznowiona. Sposób działania wycieku w nowym projekcie nie został jeszcze opracowany.

Powód postkwantowy jest najważniejszy

Szybsza finalizacja przyciąga uwagę, ale zajmuje trzecie miejsce na liście autorów. Pull request jako pierwszy wymienia fundament pod późniejsze przejście postkwantowe, a jako drugi — bezpieczeństwo wyboru gałęzi; uzasadnienie projektu zachowuje tę samą kolejność.

Związek wynika z agregacji podpisów. Walidatorzy podpisują za pomocą BLS, schematu pozwalającego połączyć wiele podpisów w jeden kompaktowy podpis. Zanolini napisał, że żaden schemat postkwantowy nie oferuje porównywalnej agregacji przy praktycznych rozmiarach. Komitet głosów dotyczących głowy łańcucha, liczący kilkuset walidatorów, omija ten problem, ponieważ jego podpisy mogą być wysyłane obok siebie. Argumentował, że może to umożliwić postkwantową wersję warstwy produkującej bloki, zanim uda się rozwiązać agregację głosów finalności pochodzących od pełnego zestawu walidatorów. Projekt przygotowuje tę ścieżkę, ale nie wybiera konkretnego schematu podpisu postkwantowego.

Nowe zabezpieczenia wiążą się z mniejszym celem

Obecny wybór gałęzi przechowuje najnowszy głos każdego walidatora bez ograniczenia wieku. Według projektu pozwala to atakującym wstrzymywać głosy i ujawniać je w strategicznych momentach, aby skierować węzły ku wybranej gałęzi. Zgodnie z propozycją wybór gałęzi uwzględniałby wyłącznie głosy z niedawnego slotu, z określonymi terminami ich nadejścia.

Blokady chronią bloki potwierdzone przez łańcuch. Blok zostaje szybko zablokowany, gdy co najmniej połowa komitetu danego slotu prześle na czas głosy dotyczące głowy łańcucha, a żaden walidator nie zagłosuje w obie strony. Blokady wygasają, a najnowsze głosy za konkurencyjnym blokiem mogą przesunąć blokadę z powrotem na wcześniejszy blok, pozwalając łańcuchowi odzyskać stabilność wraz ze zmianą warunków. Proposerzy przenosiliby również najnowsze głosy w swoich blokach, aby ujednolicić widoki walidatorów. Technika ta, nazywana view-merge, zastępuje proposer boost — dodatkową wagę wyboru gałęzi przyznawaną obecnie blokowi dostarczonemu na czas — i ma przeciwdziałać atakom równoważącym oraz reorganizacjom.

Mniejszy komitet jest jednak kompromisem. Mniejsza liczba głosujących oznacza mniej pracy związanej z podpisami w każdym slocie, ale zwiększa prawdopodobieństwo, że losowanie przydzieli atakującemu nieproporcjonalnie dużą część komitetu, a także daje atakującym mniejszą grupę do wyłączenia za pomocą ataków typu denial-of-service. Jedną z analizowanych opcji jest prywatny wybór komitetów za pomocą weryfikowalnej funkcji losowej. Rozmiar komitetu również nie został ustalony: wcześniejsze posty badawcze sugerowały około 256 walidatorów, a projekt pozostawia otwarte zarówno 512 walidatorów, jak i metodę wyboru.

Co musi się wydarzyć przed jakąkolwiek aktualizacją

Aktywacja Decoupled Consensus wymagałaby hard forka warstwy konsensusu, w ramach którego klienci konsensusu i walidatorów obsługiwaliby nowe obowiązki głosowania, formaty bloków i stanu oraz reguły wyboru gałęzi. Nagrody i kary, warunki slashingu, parametry czasu i blokad, reguły przejścia forka, wykonywalne przypadki testowe oraz pełna analiza bezpieczeństwa i żywotności wciąż muszą zostać opracowane. Specyfikacja będąca w toku znajduje się w gałęzi funkcjonalnej specyfikacji konsensusu Ethereum. Projekt utrzymuje łączny budżet nagród walidatorów bez zmian, choć płatności mogą zostać przesunięte między obowiązki związane z głosowaniem na głowę łańcucha i finalizacją.

Większy kompromis wykracza poza ten projekt. Edgington napisał, że chce wystarczająco szybkiej finalizacji bez wykluczania stakerów domowych, stakerów solo ani osób działających z odległych lokalizacji, a społeczność może w pewnym momencie być zmuszona rozważyć jeszcze szybszą finalizację kosztem różnorodności stakingu.

Na co zwrócić uwagę w następnej kolejności

• Status EIP: czy pull request zostanie scalony jako Draft pod numerem 8453 i czy na Ethereum Magicians powstanie wątek dyskusyjny.
• Prace nad specyfikacją: postępy w sekcjach dotyczących nagród, slashingu i wycieku nieaktywności, które nadal są oznaczone jako TBD.
• Zakres aktualizacji: czy główni deweloperzy wybiorą decoupled consensus jako główny element I*. Pominięcie tej listy przesunęłoby ambitny cel na 2027 r.