Wizja Ethereum na 2030 rok: obliczenia przenoszą się do dowodów kryptograficznych. Kto je zweryfikuje?

Wizja Vitalika Buterina z 27 września opisuje przejście Ethereum od systemu, w którym każdy weryfikator powtarza znaczną część pracy, do systemu, w którym dane mogą być próbkowane, a wykonanie może być sprawdzane za pomocą kompaktowych dowodów. Jedna część, PeerDAS, została już wdrożona. Większa zmiana w zakresie wykonania pozostaje w fazie rozwoju. Dowód może ustalić, że obliczenie przebiegło zgodnie z określonymi regułami, ale użytkownicy nadal potrzebują danych, sposobu na składanie transakcji oraz protokołu, który decyduje, czyj wynik staje się ostateczny.

Główne pytanie ma dwie odpowiedzi. Prover tworzy dowód kryptograficzny; weryfikator, potencjalnie dowolny węzeł walidujący uruchamiający odpowiednie oprogramowanie, sprawdza ten dowód względem reguł i publicznych danych wejściowych. Plan Ethereum dotyczący zkEVM warstwy bazowej mówi, że weryfikacja powinna być znacznie tańsza niż ponowne wykonywanie każdej transakcji. Jednak ustalenie, czy dowód jest poprawny, samo w sobie nie rozstrzyga, czy dane transakcji są dostępne ani czy operator może wstrzymać transakcję użytkownika.

Esej Buterina z 27 września, „The cryptographic world computer”, przedstawia cel jako połączenie blockchaina, kryptograficznej prywatności i weryfikacji oraz zdecentralizowanych komponentów off-chain. Przeciwstawia starszy wzorzec pobierania i ponownego wykonywania modelowi, w którym węzły próbkują dane i weryfikują dowody. Opisuje inne możliwe zmiany w konsensusie i konstrukcji bloków. To osobista wizja techniczna, a nie ostateczna specyfikacja aktualizacji ratyfikowana przez wszystkie zespoły klientów Ethereum.

Rozróżnienie między tym, co istnieje, a tym, co jest wizją, jest ważne. PeerDAS pojawił się wraz z Fusaka w grudniu 2025 r., zgodnie z lutową aktualizacją priorytetów protokołu Ethereum Foundation z 2026 r. Fundacja twierdzi, że walidatory próbkują teraz dane blob zamiast pobierać je w całości. Ogólnosieciowe przejście na weryfikację zwięzłych dowodów wykonania dla bloków warstwy bazowej nie jest opisane jako już wdrożone. Czytelnik, który słyszy, że Ethereum „będzie weryfikować dowody w 2030 r.”, powinien zapytać, który dowód, czyje obliczenia obejmuje i którzy aktorzy mogą niezależnie go przetestować.

PeerDAS sprawdza dostęp do danych, a nie każde obliczenie

Już wdrożonym elementem jest PeerDAS, czyli peer-to-peer data availability sampling. Rollupy umieszczają dane transakcji w przestrzeni blob Ethereum, aby inni uczestnicy mogli odzyskać wystarczającą ilość informacji do odtworzenia stanu i pociągnięcia operatora do odpowiedzialności za przestrzeganie reguł. Stare podejście polegające na zmuszaniu każdego węzła do pobierania każdego bloba czyniłoby większe ilości danych kosztownymi dla zwykłych walidatorów. Próbkowanie prosi węzły o sprawdzanie małych fragmentów względem kryptograficznych zobowiązań, podczas gdy sieć dystrybuuje wystarczającą liczbę zakodowanych fragmentów do rekonstrukcji.

Wyjaśnienie Ethereum mówi, że rozszerzone dane blob są dzielone na 128 kolumn. Zwykły węzeł dołącza do co najmniej 8 losowo wybranych podsieci kolumn. Osiem podzielone przez 128 to jedna szesnasta rozszerzonych danych. Kodowanie dodaje redundancję, więc ta ilość odpowiada około jednej ósmej pierwotnej objętości danych zgodnie z opisem w dokumentacji. Liczby odnoszą się do obciążenia danych domyślnego węzła, a nie do twierdzenia, że jeden węzeł może osobiście przechowywać całą historię każdego rollupa przy jednej ósmej kosztu.

Kodowanie w stylu Reeda-Solomona tworzy nadmiarowe fragmenty danych, a kryptograficzne zobowiązania pomagają węzłowi sprawdzić, że próbkowany fragment należy do tego, co zostało ogłoszone. Próbkowanie zapewnia probabilistyczną gwarancję dostępności wśród uczestniczących węzłów. Nie zastępuje walidacji wykonania. Doskonale dostępna partia transakcji może zawierać nieprawidłowe przejście stanu. Podobnie, ważny dowód dotyczący przejścia stanu nie wystarczy, aby użytkownik mógł odtworzyć stan konta, jeśli dane potrzebne do tego są wstrzymane poza gwarancjami dostępności.

Fundacja Ethereum stwierdziła, że Fusaka umożliwiła ośmiokrotny wzrost teoretycznej przepustowości blobów. Słowo teoretyczna ma znaczenie: rzeczywista, trwała przepustowość zależy od zaplanowanych zwiększeń parametrów, warunków sieciowych i wykorzystania rollupów. Crypto.news wyjaśnił, jak rollupy wykorzystują warstwę danych Ethereum. Nowy esej Buterina traktuje PeerDAS jako pierwszy widoczny krok w kierunku systemu, który weryfikuje więcej i powtarza mniej; nie należy go przekształcać w ostateczną aktualizację dowodu wykonania.

Dowodzący wykonuje ciężką pracę; niezależne węzły to sprawdzają

W modelu wykonania opartym na dowodach ktoś nadal musi wykonać transakcje i skonstruować dowody dotyczące wyniku. Ta strona może używać drogiego, specjalistycznego sprzętu i oprogramowania. Zwięzły dowód pozwala weryfikatorowi sprawdzić, przy znacznie niższym koszcie, że zgłoszona zmiana stanu jest zgodna z programem i danymi wejściowymi zatwierdzonymi zgodnie z regułami protokołu. Sprawdzenie matematyczne nie wymaga, aby weryfikator ufał firmie dowodzącej tylko dlatego, że wygenerowała dowód.

Z tym stwierdzeniem wiążą się warunki. Weryfikator musi uruchomić solidny system dowodowy z właściwym kluczem weryfikacyjnym, publicznymi danymi wejściowymi i uzgodnionymi regułami wykonania. Wadliwy obwód mógłby doskonale udowodnić błędne stwierdzenie. Błąd w implementacji klienta mógłby zaakceptować dowód, który powinien zostać odrzucony. Klucz aktualizacyjny, który może zmienić kod weryfikatora bez solidnych zabezpieczeń, mógłby osłabić gwarancję. W działającym protokole niezależne implementacje i przegląd mają znaczenie obok szybkiego generowania dowodów.

Strona mapy drogowej L1 zkEVM Ethereum opisuje przyszłość, w której węzeł sprawdza dowód wykonania bloku zamiast powtarzać każdą transakcję. Jej deklarowanym celem jest obniżenie kosztu zasobów weryfikacji. Ułatwiłoby to większej liczbie osób sprawdzanie bloków, gdyby weryfikacja dowodów pozostała praktyczna na dostępnym sprzęcie. Nie oznacza to, że każde gospodarstwo domowe może wygenerować dowód bloku, ani że produkcja dowodów będzie równomiernie rozłożona.

Crypto.news doniósł o konkurencji sprzętowej wokół dowodzenia. Użyteczne rozróżnienie dotyczy tego, kto może wygenerować dowód na czas dla łańcucha, a kto może tanio zweryfikować dowód. Generowanie dowodów mogłoby skoncentrować się w firmach posiadających specjalistyczny sprzęt, nie pozwalając tym firmom automatycznie fałszować prawidłowego przejścia stanu. Mogłoby to jednak wprowadzić zależność od żywotności: jeśli zbyt mało stron może wystarczająco szybko produkować dowody, bloki lub finalność mogą zwolnić, nawet gdy system dowodowy pozostaje matematycznie solidny. To inne ryzyko niż akceptacja nieprawidłowego dowodu.

Kwestia weryfikacji ma zatem odpowiedź ludzką, jak i matematyczną. Deweloperzy ustalają obwód, badacze go audytują, zespoły klientów go implementują, operatorzy węzłów uruchamiają weryfikatory, a uczestnicy decydują, czy zaakceptować aktualizacje protokołu. Buterin może zaproponować kierunek. Nie może samodzielnie uczynić przyszłego weryfikatora bezpiecznym ani obowiązkowym dla sieci.

Trzy obietnice są często włączane w słowo dowód

Weźmy użytkownika wysyłającego płatność przez rollup. Transakcja musi zostać uwzględniona w uporządkowanej partii. Dane partii muszą być udostępnione zgodnie z wybranym modelem rollupu. Wreszcie, wynikowa zmiana stanu musi być zgodna z jego regułami. Kolejność, dostępność i poprawność to oddzielne obietnice. Dowód poprawności dotyczy ostatniej z nich dla określonego obliczenia. PeerDAS dotyczy dostępności danych blobów Ethereum. Mechanizm sekwencera lub budowania bloków wpływa na to, które transakcje są uwzględniane i w jakiej kolejności.

Crypto.news przeanalizował sekwencer jako odrębny punkt kontroli. Doskonale ważny dowód może poświadczyć, że partia została przetworzona zgodnie z regułami, nawet jeśli jej operator wykluczył transakcję konkretnego klienta. Użytkownik może mieć ścieżkę ucieczki lub wymuszonego włączenia w zależności od projektu tego rollupa, ale sam dowód nie wymusza sprawiedliwego dostępu. Sekwencer może również zmieniać kolejność transakcji, wciąż produkując ważne przejście stanu. Twierdzenia, które jest dowodzone, nie należy mylić z każdą właściwością, jakiej użytkownicy oczekują od rynku.

Strona danych jest równie łatwa do rozmycia. Ethereum dokumentacja validium opisuje systemy, które używają dowodów ważności, ale nie publikują danych transakcji do głównej sieci Ethereum. Ich wykonanie może być poprawne według weryfikatora, jednak awaria dostępności danych może uniemożliwić użytkownikom odtworzenie stanu lub wycofanie środków zgodnie z oczekiwaniami. Rollup Ethereum publikujący wystarczające dane w Ethereum ma inny model dostępności. Nazywanie obu po prostu „ZK” ukrywa krytyczną różnicę w zdolności użytkownika do odzyskania stanu konta bez operatora.

Najprostszym testem jest trójkolumnowa lista kontrolna. Zapytaj, kto wprowadza transakcję do partii. Zapytaj, skąd można pobrać dane potrzebne do odtworzenia sald. Zapytaj, który kontrakt lub węzeł weryfikuje dowód poprawności stanu. Jeśli projekt odpowiada tylko na trzecie pytanie, nie odpowiedział na dwa pierwsze. Dlatego esej Buterina mówi o konstrukcji bloków i dystrybucji danych sieciowych obok kryptografii, zamiast zastępować cały system jednym magicznym dowodem.

Warstwa bazowa nie może pożyczyć każdej właściwości od istniejących rollupów

Rollupy ZK już przesyłają dowody ważności do Ethereum na podstawie własnych kontraktów i reguł. Dokumentacja Ethereum dotycząca rollupów ZK opisuje operatora tworzącego dowód dla partii i kontrakt weryfikujący akceptujący nowy korzeń stanu dopiero po weryfikacji. To użyteczny precedens dla dowodzenia obliczeń. Nie oznacza to, że warstwa bazowa Ethereum już przeniosła całą walidację wykonania na takie dowody.

Zakres się różni. Rollup dowodzi własnego przejścia stanu w ramach własnej maszyny wirtualnej i kontraktu, podczas gdy weryfikator warstwy bazowej Ethereum musiałby sprawdzić wykonanie bloku protokołu w sposób akceptowany przez zespoły klientów. Niezgodność między niestandardową logiką rollupa a regułami wykonania głównej sieci Ethereum nie jest szczegółem, który szybszy dowodzący może odczarować. Systemy dowodowe muszą również pozostać solidne poprzez aktualizacje protokołu, nowe typy transakcji i wrogie dane wejściowe.

Aplikacja może zlecić swoje obliczenia arytmetyczne koprocesorowi i dostarczyć wynik z dowodem, ale łańcuch bazowy nadal decyduje, czy zaakceptować publiczne dane wejściowe, przechować zobowiązania i rozstrzygnąć wynikowy stan. Aplikacja może być w stanie wybrać własny projekt dowodzącego; reguła warstwy bazowej wymaga szerokiej koordynacji między klientami i walidatorami. Sformułowanie Buterina „kryptograficzny komputer świata” jest użyteczne jako kierunek architektoniczny, a nie obietnica, że pojedyncza usługa dowodowa będzie obsługiwać całe Ethereum.

Istnieje pozorna sprzeczność, którą warto rozwiązać. Jeśli węzły przestaną ponownie wykonywać, jak ktokolwiek znajdzie błąd w dowodzonym obliczeniu? Jedną odpowiedzią jest to, że programiści mogą uruchomić niezależne pełne wykonanie i porównać je z wynikami dowodu podczas tworzenia i po wdrożeniu. Inną jest wiele implementacji dowodów i formalne sprawdzenia obwodów. Dokładny projekt Ethereum nie został sfinalizowany. Protokół, który redukuje wymagane ponowne wykonanie, nie zabrania ludziom przeprowadzania dodatkowych sprawdzeń; zmienia to, co każdy zwykły węzeł walidujący musi robić dla konsensusu.

Fundacja aktualizacja priorytetów protokołu z września traktuje zkEVM warstwy L1 i formalną weryfikację jako główne strumienie pracy. To dowód aktywnej inżynierii, a nie ustalona data uruchomienia. Standard bezpieczeństwa jest wysoki, ponieważ błąd w systemie dowodowym warstwy bazowej wpłynąłby na fundament, od którego zależą inne aplikacje.

Dowody mogą poprawić weryfikację, podczas gdy problem stanu rośnie

Buterin wymienia dostęp do bardzo dużego współdzielonego stanu jako szczególnie trudny, nierozwiązany problem. Crypto.news przeanalizował jego odrębną propozycję skalowania mempoolu opartego na dowodach, która celuje w inne wąskie gardło niż końcowe wykonanie stanu. Dowód może poświadczyć obliczenie, ale dowodzący musi uzyskać informacje, od których to obliczenie zależy: salda, przechowywanie kontraktów i inny stan konta. Jeśli wiele transakcji dotyka tego samego stanu jednocześnie, podział obliczeń między maszyny staje się trudniejszy. Płatność z jednego konta i swap dotykający puli płynności nie mogą zostać oba sfinalizowane na podstawie niespójnych migawek.

Esej sugeruje, że aplikacje mogą umieszczać porządkowanie i nieprzemienne zmiany stanu w łańcuchu, jednocześnie agregując inne obliczenia przed włączeniem. Jest to zachęta architektoniczna, a nie wiążąca zasada dla dzisiejszych deweloperów. „Nieprzemienny” oznacza, że zmiana kolejności zmienia wynik. Dwie osoby kupujące z tej samej cienkiej puli mogą otrzymać różne ceny w zależności od tego, które zlecenie zostanie przetworzone pierwsze. Żaden dowód nie czyni tych dwóch zleceń ekonomicznie równoważnymi.

Jest to użyteczna przeciwwaga dla uproszczonej obietnicy darmowej skalowalności. Praca równoległa jest łatwiejsza, gdy zadania można bezpiecznie rozdzielić. Współdzielony stan tworzy zależności. Prover może wykonywać wiele niezależnych obliczeń szybko i wciąż czekać na dostęp do spornego stanu lub wybór kolejności przez budowniczego bloków. Poprawa samej szybkości dowodu nie rozwiązuje kontencji bazy danych, cenzury ani kosztu udostępnienia wystarczającej ilości informacji innym uczestnikom.

W opinii Buterina silniejsza zdecentralizowana warstwa pośrednia mogłaby przetwarzać pracę równolegle, a w niektórych przypadkach chronić metadane o tym, skąd pochodzą żądania. Taka infrastruktura mogłaby poprawić wydajność lub prywatność, ale musiałaby określić, jak dystrybuowane są dane, kto może dołączyć i które awarie mają ścieżkę ucieczki. Prywatność płatności użytkownika nie jest automatyczną konsekwencją użycia dowodu ważności. Publiczne dane wejściowe, aktywność portfela i metadane sieciowe mogą nadal ujawniać informacje, chyba że system chroni również te części.

Niezależność można zmierzyć przed ostatecznym forkiem

„Każdy może zweryfikować” ma praktyczne warunki. Zwykły węzeł potrzebuje kodu weryfikatora, odpowiednich publicznych danych wejściowych, połączenia z zaakceptowanym stanem łańcucha i wystarczającej mocy obliczeniowej, aby ukończyć sprawdzenie w ramach limitów czasowych protokołu. Jeśli sprawdzenie dowodu zajmuje sekundy na skromnej maszynie, ale godziny na jego wytworzenie na drogim sprzęcie, system może osiągnąć szeroką weryfikację przy wąskiej produkcji. Może to być akceptowalny kompromis inżynieryjny dla poprawności, pod warunkiem że awaria producenta nie stanie się trwałą blokadą rozliczenia.

Eksperyment jest prosty w zarysie. Uruchom oprogramowanie weryfikatora z więcej niż jednego zespołu klienta przeciwko temu samemu ważnemu dowodowi bloku i potwierdź, że go akceptują. Dostarcz zmienione publiczne dane wejściowe i potwierdź odrzucenie. Zapytaj, czy oddzielne zespoły dowodzące mogą wytworzyć akceptowane dowody dla tych samych reguł, jak szybko mogą to zrobić i jaki sprzęt każdy z nich wymaga. Powtórzenie tego w publicznej sieci testowej pod dużym obciążeniem powiedziałoby więcej o gotowości niż laboratoryjna demonstracja jednego szybkiego dowodu. Dokładne kryteria akceptacji Ethereum pozostają przedmiotem prac protokołu; są to obserwowalne pytania, a nie oficjalne progi zaliczenia.

Generowanie dowodów ma inny tryb awarii, którego samo sprawdzenie ważności nie może wychwycić. Prover może odmówić wytworzenia dowodu dla proponowanego bloku. Weryfikator nie może zaakceptować dowodu, który nie dotarł. Projekt może to rozwiązać, pozwalając na wielu niezależnych proverów, awaryjną ścieżkę wykonania, dostosowane czasy lub inne mechanizmy. Wybór wpłynie na złożoność, koszt i czas do finalności. Obecnych zasad warstwy bazowej Ethereum nie należy opisywać jako wybranych jednego z tych przyszłych rozwiązań tylko dlatego, że roadmapa mówi, iż weryfikacja dowodów jest celem.

Niezależność oznacza również, że użytkownik może uzyskać informacje potrzebne do zweryfikowania własnego roszczenia do aktywów. Dowód, że korzeń stanu jest zgodny z kodem, jest potężny, ale użytkownik, który nie może zrekonstruować ścieżki od danych swojego konta do tego korzenia, nadal polega na pośredniku w praktycznym sprawdzeniu salda. PeerDAS zmniejsza wymagania dotyczące dostępności danych blob dla każdego węzła, opierając się na dystrybucji i próbkowaniu w całej sieci. Dane aplikacji przechowywane gdzie indziej potrzebują własnych gwarancji dostępności. Weryfikator dowodów łańcucha nie może zmusić zewnętrznego operatora do publikowania wstrzymanych rekordów.

Wreszcie, weryfikowany program musi być programem, za który uważają go użytkownicy. Publiczny hash kodu weryfikatora, udokumentowany proces aktualizacji i niezależne testy zachowania obwodu pozwalają osobom z zewnątrz porównać reklamowaną regułę z tym, co faktycznie egzekwują węzły. Weryfikacja formalna może zmniejszyć szansę na błąd logiczny, ale ona również zaczyna się od specyfikacji napisanej przez ludzi. Sprawdzalny wynik to nie „kryptografia rozwiązała zaufanie”. To, że określone roszczenie może zostać niezależnie odrzucone, gdy jego dowody są nieprawidłowe, bez ponoszenia przez każdy węzeł pełnego kosztu jego wytworzenia.

Hegota to znacznik, a nie gwarancja wydania w 2030 roku

Buterin odnosi się do Hegoty, forka planowanego na 2027 rok, jako prawdopodobnie ostatniej aktualizacji, której komponenty byłyby znajome dla obserwatora Ethereum z 2015 roku. Późniejsze prace w jego opisie obejmowałyby rekurencyjne STARKi, weryfikację formalną, zoptymalizowany konsensus i bezpieczeństwo kwantowe. Crypto.news informowało o odrębnym celu kwantowym na 2029 rok jako celu planistycznym. Ani esej, ani data docelowa nie dowodzą, że każdy proponowany komponent będzie gotowy i przyjęty zgodnie z harmonogramem.

Aktualizacje Ethereum wymagają specyfikacji, implementacji klientów, sieci testowych, przeglądów bezpieczeństwa i koordynacji między uczestnikami. Mapa orientacyjna to mapa badań i potencjalnych kamieni milowych, a nie wprowadzenie na łańcuchu. Można zweryfikować, że PeerDAS jest wdrożony, patrząc na wydanie Fusaka i aktualne zasady węzłów. Nie można zweryfikować przyszłego ogólnego bazowego zkEVM, patrząc na niebieską kolumnę 2030 w eseju. Dowody pojawią się najpierw w publicznych specyfikacjach i testach, a następnie w konkretnym planie forka i aktywacji produkcyjnej.

Argument za podejściem Buterina jest mocny. Jeśli weryfikacja stanie się tania, a dane będzie można bezpiecznie próbkować, więcej użytkowników będzie mogło niezależnie sprawdzić większy system bez kupowania maszyn proporcjonalnych do całej jego mocy obliczeniowej i danych. Wyzwanie jest równie realne: stos dowodowy musi być bezpieczny, konkurencyjnie wytwarzany i wystarczająco szybki, aby utrzymać system w działaniu, a dane i porządkowanie muszą pozostać dostępne. Sieć z tanią weryfikacją, ale pojedynczym niezbędnym proverem lub sequencerem, może nadal być krucha.

Esej nie rozstrzyga, kto zbuduje każdy dowód ani który system dowodowy zwycięży. Wskazuje jednak test, który ma znaczenie dla użytkowników: czy zwykły niezależny uczestnik może odrzucić błędny wynik, odzyskać dane potrzebne do poznania własnego stanu i przesłać transakcję mimo dowolnego pojedynczego operatora? Każda odpowiedź wymaga odrębnego mechanizmu. Sprawdzenie kryptograficzne jest potężne właśnie dlatego, że mogą je powtórzyć osoby, które nie wykonały ciężkiej pracy.

Na co uważać

• Specyfikacje L1 zkEVM. Szukaj konkretnego weryfikatora, publicznego formatu danych wejściowych i reguł wykonania akceptowanych przez różnych klientów.
• Różnorodność proverów. Wiele niezależnych implementacji i zmierzone wymagania sprzętowe sprawdzą, czy produkcja dowodów ma pojedynczy punkt krytyczny.
• Pomiary PeerDAS. Sprawdź przepustowość blobów i przepustowość sieci węzłów, gdy wzrost parametrów nastąpi po uruchomieniu w grudniu 2025 r.
• Decyzje dotyczące Hegota. Ostateczny zakres forka ma większe znaczenie niż cechy kandydujące w projekcie roadmapy.
• Zabezpieczenia danych i kolejności. Sprawdź, czy rollupy i przyszłe projekty warstwy bazowej zachowują niezależną rekonstrukcję i włączenie transakcji.

FAQ