Vitalik Buterin, współzałożyciel Ethereum, w wpisie z 27 września nakreślił wizję Ethereum, w której warstwa bazowa rozlicza końcowe wyniki, podczas gdy kryptograficzne dowody przejmują coraz większą część pracy weryfikacyjnej. Jego wizja na 2030 rok łączy rekurencyjne dowody STARK, próbkowanie dostępności danych, narzędzia prywatności oraz przeprojektowany konsensus. Esej określa wieloletni kierunek techniczny, a nie harmonogram wydawniczy: odpowiedni kod, zakres każdej aktualizacji i daty dostarczenia muszą wciąż przejść przez zwykły proces rozwojowy Ethereum.

Proponowaną zmianę można ująć w jednym zdaniu: łańcuch nadal rozstrzyga końcowe wyniki, a dowody dają uczestnikom bardziej efektywny sposób sprawdzenia pracy, która do tych wyników doprowadziła.

Czym Ethereum musi wciąż zająć się samo

Ethereum potrzebuje wspólnej ewidencji tego, kto co posiada i która transakcja nastąpiła pierwsza. Ta ewidencja zapobiega podwójnemu wydaniu tych samych środków i zapewnia aplikacjom stan końcowy, do którego każdy uczestnik może się odwołać.

Obecnie pełne węzły niezależnie walidują transakcje i zmiany stanu. Sprawdzają, czy nadawca posiada wystarczające środki, czy inteligentny kontrakt przestrzegał swoich reguł oraz czy powstały stan jest zgodny z protokołem. Ta zdwojona praca wzmacnia bezpieczeństwo sieci, ale ogranicza też zyski wydajnościowe, jakie mogłyby wyniknąć z dodania większej liczby komputerów.

Zgod z roadmapą Buterina porządkowanie transakcji i ostateczne rozliczanie pozostają w warstwie bazowej, podczas gdy otaczająca infrastruktura zyskuje przestrzeń do obsługi złożonych obliczeń, zanim dotrą one do bloku końcowego.

Dowody mogą przejąć więcej pracy sprawdzającej

Dowód zerowej wiedzy to zwięzłe matematyczne stwierdzenie, że obliczenie przebiegło zgodnie ze zdefiniowanym zbiorem reguł. STARKi — skrót od Scalable Transparent Argument of Knowledge — to przejrzysta konstrukcja oparta na funkcjach skrótu, niewymagająca zaufanej konfiguracji. Proover wykonuje cięższe obliczenia i dostarcza dowodów, które inni uczestnicy mogą efektywnie zweryfikować. Dowody rekurencyjne rozszerzają ten model, łącząc wiele dowodów w jeden, co pozwala sieci sprawdzić jeden skompresowany wynik obejmujący większy zestaw zależności. Takie podejście mogłoby zmniejszyć ilość powtarzalnych obliczeń docierających do środowiska wykonawczego Ethereum.

Buterin ilustruje tę ideę na przykładzie portfela sprawdzającego skomplikowaną pozycję DeFi obejmującą kilka aktywów zabezpieczających i zautomatyzowane reguły. W opisywanej przez niego architekturze dowód mógłby potwierdzić, że pozycja została poprawnie zaktualizowana, a następnie Ethereum rozliczyłoby powstały stan zgodnie z własnymi regułami.

Niższe koszty i szybsze wykonywanie złożonych operacji pozostają możliwymi rezultatami. Ich skala zależałaby od kosztów generowania dowodów, projektu aplikacji oraz funkcji, które ostatecznie trafią do Mainnetu.

Dostępność danych to odrębne pytanie o bezpieczeństwo

Ważny dowód i dostępne dane służą różnym celom. Dowód dotyczy tego, czy zdefiniowane obliczenie zostało wykonane poprawnie; dostępność danych dotyczy tego, czy informacje wspierające to obliczenie można nadal pobrać i zbadać. To rozróżnienie ma praktyczne znaczenie: bez możliwości odzyskania danych nawet ważny dowód pozostawiłby uczestników bez możliwości niezależnej rekonstrukcji stanu powstałego w wyniku obliczenia.

PeerDAS zajmuje się drugim problemem. Pozwala węzłom próbkować dane blob i budować pewność, że szerszy zbiór danych jest dostępny, eliminując konieczność pobierania przez każdy węzeł całego zbioru przed udziałem w sprawdzaniu. PeerDAS pojawił się wraz z aktualizacją Fusaka, stając się żywym elementem architektury skalowania Ethereum. Esej Buterina posuwa tę sam zasadę projektową dalej: mniej powtarzalnej pracy na każdym pojedynczym uczestniku przy zachowaniu ścieżki niezależnej weryfikacji.

Esej sytuuje także wcześniejsze prace nad weryfikacją walidatorów opartą na dowodach, w tym propozycję Lean Ethereum, w szerszym planie obejmującym obliczenia, dane i prywatność w całej sieci.

Prywatność obejmie też ślady pozostawiane przez portfele

Wyzwanie prywatności Ethereum wykracza poza ukrywanie kwot płatności czy adresów odbiorców. Portfele często odpytują zewnętrzne serwery o salda, dane tokenów i historie transakcji, a te zapytania mogą ujawnić, które konta dana osoba obserwuje lub kontroluje.

Buterin opisuje narzędzia kryptograficzne i zdecentralizowaną infrastrukturę, które mogłyby chronić większą część tych metadanych. Deklarowane cele obejmują prywatne płatności, prywatną logikę kont oraz mniejszą liczbę zapytań portfeli wystawianych jednemu dostawcy usług.

Codzienne użytkowanie wymagałoby czegoś więcej niż badań nad protokołem. Oprogramowanie portfeli musi bezpiecznie obsługiwać te narzędzia, a interfejsy muszą wyjaśniać model bezpieczeństwa wystarczająco jasno, aby użytkownicy mogli podejmować świadome decyzje.

Hegotá rozpoczyna dłuższą transformację techniczną

Oficjalna roadmapa Ethereum umieszcza aktualizację Hegotá w 2027 roku. Buterin opisuje ją jako prawdopodobnie ostatnią aktualizację opartą głównie na technologii, która byłaby znajoma programistom z połowy lat 2010. Kolejna faza mogłaby obejmować rekurencyjne STARKi, bardziej zoptymalizowany konsensus, zautomatyzowaną formalną weryfikację oraz kryptografię odporną na zagrożenia kwantowe.

Formalna weryfikacja może sprawdzić, czy kod odpowiada napisanej specyfikacji, ale nie potrafi rozstrzygnąć braków ani błędnych decyzji w samej specyfikacji. Badania nad bezpieczeństwem kwantowym przygotowują Ethereum na przyszły wzrost mocy obliczeniowej; istniejąca kryptografia Ethereum pozostaje dziś w użyciu.

Te idee muszą jeszcze przejść badania, pracę nad specyfikacją, rozwój klientów, przegląd bezpieczeństwa, testy i uzyskać zgodę społeczności. Dla śledzących temat obserwowalnymi kamieniami milowymi są wersje robocze specyfikacji, implementacje klientów i testy w sieciach publicznych — te same etapy, przez które przechodzi każda aktualizacja Ethereum przed dotarciem do Mainnetu. Generowanie dow musi stać się tańsze i bezpieczniejsze w rzeczywistych warunkach obciążenia, a zarządzanie dużymi ilościami współdzielonego stanu aplikacji pozostaje kolejnym poważnym wyzwaniem wskazanym w eseju.

Roadmapa zostanie oceniona przez niezależną weryfikację

Praktyczny standard jest prosty. Użytkownicy, programiści i operatorzy węzłów potrzebują realistycznego sposobu weryfikacji systemu bez polegania na nieprzejrzystym pośredniku. Zwięzłe dowody muszą być wydajne, dane muszą pozostać dostępne, a portfele muszą komunikować założenia stojące za każdą operacją.

Proponowana architektura Ethereum pozostawia łańcuchowi odpowiedzialność za porządkowanie i rozliczanie, podczas gdy systemy dowodowe i zdecentralizowana infrastruktura przejmowałyby większą część pracy prowadzącej do tych końcowych wyników. Wartość roadmapy zależeć będzie od tego, czy taki układ uczyni weryfikację bardziej praktyczną, nie dodając złożoności nie do oceny przez zwykłych użytkowników.

Niniejszy artykuł ma charakter wyłącznie informacyjny i nie stanowi porady finansowej ani inwestycyjnej. Roadmapa Ethereum pozostaje przedmiotem przeglądu technicznego, koordynacji społeczności i zmian.