Prelegent: Vitalik Buterin
Opracowane przez: Yuliya, PANews
Witajcie wszyscy! Zapraszam na ETHShanghai 2026. Dziś chcę z wami omówić dość złożony temat techniczny, który jest kluczowy dla przyszłości Ethereum — może on umożliwić Ethereum osiągnięcie niezwykle wysokiej skalowalności, jednocześnie równoważąc prywatność i decentralizację, a wszystkie trzy cele mogą być osiągnięte jednocześnie. Ta propozycja bardzo prawdopodobnie naprawdę zmieni architekturę działania wielu komponentów w blockchainie. Może zmienić wiele rzeczy, ale co zaskakujące, jej faktyczne wdrożenie w istniejącym Ethereum nie jest zbyt trudne. To EIP-8288: Podpis rekurencyjny i agregacja.
Główny problem: Nieprzejednanie bezpieczeństwa, prywatności i skalowalności
Dziś chcę skupić się na kilku głównych kwestiach, które wszystkich bardzo interesują: bezpieczeństwo kwantowe, prywatność i skalowalność. Obecnie dużym problemem jest to, że zarówno bezpieczeństwo kwantowe, jak i prywatność obecnie znacznie kolidują ze skalowalnością:
Normalna transakcja Ethereum zużywa obecnie około 21 000 gas; niezależna weryfikacja podpisu ECDSA (około 65 bajtów) zajmuje około 4000 gas.
Jeśli zastąpimy je podpisami odpornymi na ataki kwantowe (niezależnie od tego, który typ schematu podpisu post-kwantowego), zużycie gas będzie wynosić około 100 000 do 300 000 gas, w zależności od wybranego rozmiaru parametrów (na przykład, czy musi być kompatybilny ze scenariuszami portfeli blockchain). Ale niezależnie od wyboru, koszt będzie kilkakrotnie wyższy niż dzisiejszych transakcji — podpisy odporne na ataki kwantowe są duże i drogie.
Drugi problem: dowody dla protokołów prywatności są również duże i drogie. Jeśli ktoś używał jakiegokolwiek protokołu prywatności opartego na technologii zerowej wiedzy (ZK), będzie wiedział, że w Ethereum takie operacje kosztują co najmniej około 350 000 gas. Ponieważ wiele takich protokołów nie jest zaprojektowanych zbyt wydajnie, czasami rzeczywisty koszt może nawet osiągnąć około 1 miliona gas — to jest bardzo drogie. Dziś normalna transakcja może kosztować tylko kilka centów, podczas gdy takie transakcje mogą kosztować 20 centów, a nawet dwa dolary.
Poważniejszym problemem jest: jeśli chcesz zarówno bezpieczeństwa kwantowego, jak i prywatności, musisz użyć dowodów STARK, aby zastąpić poprzednie schematy. Jednak dowód STARK zużywa około 8 milionów gas, a bardzo prawdopodobnie więcej. To znaczy, jeśli teraz pozwolimy wszystkim zacząć używać transakcji „odpornych na ataki kwantowe + prywatnych”, pierwotna przepustowość Ethereum wynosząca około 25 TPS spadnie do około 0,25 TPS, prawie tracąc użyteczność.
Innym problemem jest: ludzie mogą również chcieć obsługiwać niestandardowe schematy kryptograficzne. Na przykład przejście z dzisiejszych krzywych eliptycznych na przyszłą kryptografię kratową. Problem polega na tym, że za każdym razem, gdy chcesz obsługiwać takie nowe schematy, zwiększa to rozmiar samego protokołu i wymaga więcej plików prekompilacji (duże rozmiary, wysoki koszt). A jeśli nie obsługujesz natywnie tych schematów w EVM lub nie masz odpowiednich plików prekompilacji, wówczas weryfikacja dowolnego takiego podpisu w łańcuchu zużyje bardzo dużą ilość gas.
Innymi słowy, wszystkie nasze cele w zakresie bezpieczeństwa i prywatności faktycznie utrudniają skalowalność, przynajmniej w obecnej architekturze.
Główne rozwiązanie: Przenieść obliczenia agregacji do mempoolu
Jak więc rozwiązać ten problem? To jest główny mechanizm wdrażany przez EIP-8288.
Główna idea jest następująca: zamiast bezpośrednio umieszczać wszystkie te podpisy i wszystkie te dowody STARK (te ogromne, strukturalnie złożone obiekty) w łańcuchu, trzymamy je poza łańcuchem i wykonujemy agregację wewnątrz mempoolu.
Konkretnie: gdy użytkownik wysyła transakcję, w mempoolu istnieje grupa węzłów, a te węzły pracują już przed spakowaniem transakcji do bloku. To, co robią te węzły, nazywa się „agregacją” — zastępują dużą liczbę podpisów i dowodów pojedynczym dowodem, który może zweryfikować, że wszystkie te podpisy i dowody naprawdę istnieją i są ważne.
Zatem z perspektywy użytkownika: użytkownik wysyła transakcję, a wraz z transakcją wysyła również ten ogromny obiekt (podpis/dowód), ale ten ogromny obiekt sam w sobie nigdy tak naprawdę nie trafia do łańcucha. To, co faktycznie trafia do łańcucha, to tylko pojedynczy dowód STARK, używany do weryfikacji, że wszystkie podpisy i wszystkie dowody zawarte we wszystkich transakcjach użytkowników naprawdę istnieją i są ważne.
Mechanizm ten jest zbudowany na szczycie EIP-8141 (natywna abstrakcja konta), który zostanie wprowadzony w następnym hard forku. EIP-8141 kondensuje niemal dekadę badań społeczności Ethereum w dziedzinie abstrakcji konta. Pozwala każdej transakcji bezpośrednio i precyzyjnie jawnie zadeklarować jej komponenty składowe, specyfikacje podpisów i algorytmy weryfikacji, dając transakcjom silniejszą programowalność i typowaną strukturę.
W EIP-8288 dodaliśmy nowy typ ramki, który można rozumieć jako „zależność”. Istnieją łącznie dwa rodzaje zależności: jedna odpowiada podpisom, a jedna odpowiada dowodom (STARK). W przeciwieństwie do obecnego modelu, w którym podpisy są bezpośrednio osadzone w treści transakcji, w nowym mechanizmie sama transakcja zawiera jedynie abstrakcyjną deklarację wskazującą, od jakiego typu podpisu i dowodu transakcja zależy. Gdy transakcja jest rozgłaszana, chociaż pełne dane są wysyłane wraz z nią, to ostatecznie do bloku zapisywana jest jedynie mikro-struktura ramki przenosząca zależności. Dane zajmowane przez każdą zależność to tylko 96 bajtów, a większość jest nawet tak niska jak 65 bajtów. Reszta ogromnych bytów kryptograficznych jest absorbowana i agregowana wewnątrz mempoola, a ostatecznie pojawia się w księdze blockchain jedynie w formie pojedynczego dowodu.
W tej architekturze każdy węzeł w mempoolu stale nasłuchuje nośnika danych zwanego „kopertą”. Pojedyncza koperta może zawierać wiele transakcji i towarzyszących im dowodów.
Węzły używają stałego okresu czasu jako okna, stale zbierają wszystkie obiekty kopert zaobserwowane w tym okresie, wykonują lokalne obliczenia agregacyjne, a następnie rozgłaszają je. Podczas rozgłaszania wszystkie pierwotnie dyskretne niezależne dowody zostały zastąpione jednym globalnym dowodem zagregowanym, który matematycznie rygorystycznie obejmuje poprawność wszystkich podstawowych podpisów w tej partii.
To pokazuje, że zanim węzły pakujące bloki formalnie wykonają aktualizacje stanu, sieć Ethereum zakończyła już zdecydowaną większość obliczeń weryfikacyjnych o wysokiej intensywności na etapie mempoola w warstwie nie-konsensusowej.
Esencja architektoniczna: „Wyspecjalizowany sharding”
Jednym ze sposobów zrozumienia tego mechanizmu jest postrzeganie go jako rodzaju wyspecjalizowanego shardingu. Jego idea jest następująca: możemy wyodrębnić te niezwykle kosztowne części obliczeń obejmujące niezwykle duże ilości danych i pozwolić całej rozproszonej sieci przetwarzać tę część obliczeń równolegle w bardzo luźny, nieustrukturyzowany sposób.
To podejście nie jest kruche; wręcz przeciwnie, jest bardzo solidne — każdy węzeł może podjąć się dowolnej części tej pracy. To, co robimy, zasadniczo polega na podzieleniu każdej transakcji na dwie części:
Jedna część wyjaśnia „co ta transakcja robi, jak wchodzi w interakcję ze stanem i jak wchodzi w interakcję z innymi transakcjami”;
Druga część to ogromna, kosztowna część tej transakcji — to znaczy czysta praca weryfikacyjna.
Poprzez specjalne shardowanie i oddzielenie obciążenia weryfikacyjnego, ładunek danych, który warstwa konsensusu głównego łańcucha ostatecznie wymaga, aby wszystkie węzły weryfikacyjne sieci wspólnie ponosiły, jest ściśle skompresowany do niezwykle małego zakresu 100 do 300 KB na blok. Ten narzut wynosi tylko około dwukrotności obecnej ilości danych bloku Ethereum, a wraz z liniowym rozszerzaniem ogólnej przepustowości sieci, proporcja tego stałego narzutu w całkowitym obciążeniu sieci będzie nadal rozcieńczana.
Zasadniczo to, co robimy, to: przenoszenie pracy z dala od walidatorów, a nawet z dala od węzłów, które pakują bloki, przesuwając tę część pracy do tych węzłów pozałańcuchowych znajdujących się między „użytkownik wysyła transakcję” a „węzeł pakujący blok faktycznie umieszcza transakcję w bloku”.
Co to oznacza dla Ethereum?
Z technicznego punktu widzenia oznacza to, że Ethereum hiper-skaluje określoną klasę obliczeń. Myślę, że to także trend, który będziemy widzieć coraz częściej w miarę dalszego rozwoju Ethereum.
Ethereum, narodzone dziesięć lat temu, skupiało się na w pełni ogólnych obliczeniach, ale jednocześnie całkowicie brakowało mu skalowalności. Więc to, co teraz robimy, to dzielenie obliczeń na różne typy, a następnie specjalne uczynienie tych typów obliczeń, które są „naturalnie bardziej odpowiednie do skalowania”, niezwykle skalowalnymi — budujemy te bardziej wyspecjalizowane „małe narzędzia”, aby to osiągnąć.
Jednocześnie sprawiamy również, że te obliczenia, które muszą być obsługiwane w mniej wydajny sposób, stają się mniejsze i łatwiejsze do obsłużenia. EIP-8288 jest dokładnie hiper-skalowaniem dwóch typów obiektów: „weryfikacji podpisu” i „weryfikacji dowodu wiedzy zerowej”.
Innym interesującym punktem jest to: wiem, że wiele osób od dawna jest ciekawych, kiedy Ethereum przejdzie na RISC-V — ponieważ w porównaniu z obecnym podejściem, RISC-V lub inny bardziej nowoczesny zestaw instrukcji jest znacznie wydajniejszy, a także znacznie prostszy. I EIP-8288 bardzo prawdopodobnie stanie się pierwszym scenariuszem na Ethereum, który naprawdę wprowadzi RISC-V (lub podobny zestaw instrukcji). Powód jest taki, że EIP-8288 pozwala użytkownikom przesyłać dowody, a gdy użytkownicy przesyłają dowody, muszą użyć jakiegoś języka do wyrażenia twierdzeń, które weryfikują — RISC-V jest dokładnie tym językiem.
To znaczy, że logika weryfikacji wyrażona w RISC-V musi być wykonana jedynie jako pojedyncze fizyczne obliczenie lokalnie na kliencie użytkownika: użytkownik generuje odpowiedni dowód (w scenariuszach prywatności jest to ZK-STARK), a następnie natychmiast wypycha go do mempoolu; pierwszy węzeł przekaźnikowy, który to podchwyci, natychmiast rekurencyjnie kompresuje go razem z setkami lub tysiącami podobnych dowodów w całej sieci do pojedynczej encji.
Jest to również równoznaczne z podzieleniem całego obliczenia na dwie główne kategorie:
Jedna kategoria to „zależności” — czyli części, które muszą być zagwarantowane jako poprawne, aby transakcja była ważna;
Druga kategoria to „logika biznesowa” — czyli to, co sama transakcja faktycznie robi.
Logika biznesowa może zatem stać się lżejsza i czystsza, co oznacza również, że część logiki budowania bloków, która zależy od kolejności transakcji, również stanie się prostsza. A część „zależności” może być przetwarzana równolegle na ekstremalnie dużą skalę, praktycznie bez potrzeby jakichkolwiek większych zmian w doświadczeniu deweloperskim deweloperów Ethereum.
Praktyczna wartość dla deweloperów, użytkowników i warstwy 2
Dla każdego, kto buduje aplikacje on-chain, kluczowe znaczenie tego wszystkiego jest takie: najdroższe operacje dzisiaj staną się znacznie tańsze.
Koszt wykonania transakcji odpornych na komputery kwantowe zostanie skompresowany do niemal pomijalnie niskiego poziomu;
Aplikacje chroniące prywatność zbudowane na zk-SNARK/STARK uwolnią się od ograniczeń wysokich opłat za Gas, staną się powszechne przy przystępnym koszcie i będą natywnie odporne na komputery kwantowe.
Poza scenariuszami prywatności, wydajność aplikacji zk-SNARK w skalowaniu (zwłaszcza warstwy 2) doświadczy skoku jakościowego. Obecnie wiele ZK-Rollupów, aby amortyzować wysoki koszt Gas publikowania dowodów stanu do mainnetu, jest często zmuszonych do wydłużania cyklu składania, rozliczając się w partiach z częstotliwością dziesięciu minut, a nawet godziny. Poważnie ogranicza to szybkość ostatecznego potwierdzenia w okresach niskiej aktywności transakcyjnej w sieci.
Obecnie wiele ZK-Rollupów, aby amortyzować wysoki koszt Gas publikowania dowodów stanu do mainnetu, jest często zmuszonych do wydłużania cyklu składania, rozliczając się w partiach z częstotliwością dziesięciu minut, a nawet godziny. Poważnie ogranicza to szybkość ostatecznego potwierdzenia w okresach niskiej aktywności transakcyjnej w sieci.
Ewolucja końcowa: Popychanie obliczeń całkowicie na krawędź
Na koniec, jeśli istnieją inne obliczenia, które chcesz wykonać, ale są zbyt drogie do wykonania wewnątrz EVM, mam nadzieję, że naprawdę zaczniemy zmieniać kierunek — nie polegając już na samym protokole Ethereum, by bezpośrednio ponosił wszystkie obliczenia, które wszyscy chcą wykonywać, ale zamiast tego zachęcając użytkowników do wykonania tej części obliczeń lokalnie na swoich klientach, a następnie opublikowania dowodu, tak aby ten dowód został zweryfikowany na Ethereum.
Zasadniczo jest to skalowanie Ethereum poprzez przenoszenie obliczeń z „centrum” łańcucha i popychanie ich na „krawędź”. Rezultat jest taki: rzeczy, które są dziś najdroższe na Ethereum (różne formy bezpieczeństwa, różne formy prywatności i różne formy kompatybilności z aplikacjami zewnętrznymi) nie są dziś robione przez ludzi, ponieważ są zbyt drogie, a w przyszłości wszystkie staną się znacznie tańsze i naprawdę użyteczne dla wszystkich.
Mam nadzieję, że to dopiero pierwszy krok w przekształcaniu Ethereum z architektury, której używa niemal od momentu powstania, w zupełnie inną i jeszcze potężniejszą nową architekturę — nową architekturę, która naprawdę łączy dwie rzeczy: jedną jest bardzo prosta wczesna idea blockchainu Satoshi Nakamoto; drugą jest niezwykle potężna i niezwykle nowoczesna technologia kryptograficzna, którą nieprzerwanie gromadzimy od tamtego czasu.
Udział w ekosystemie i postęp we wdrażaniu
Obecnie intensywnie prowadzone są wczesne badania i walidacja inżynieryjna wokół tego podejścia, a społeczność techniczna może już uczestniczyć w budowaniu z wielu punktów wejścia:
Modele symulacyjne na poziomie sieci: udostępniono wczesne narzędzia symulacyjne dla topologii mempool i mechanizmów propagacji agregacji;
Działanie testnetu: testnet EIP-8141 obsługujący formę transakcji ramkowych został oddany do testów;
Konkursy optymalizacji algorytmów: prowadzone są specjalne konkursy algorytmiczne dla społeczności deweloperów, skupiające się na wydajnej implementacji bazowego systemu dowodowego;
Implementacja i weryfikacja kodu: bazowa baza kodu prototypowego nabrała kształtu, aby deweloperzy ekosystemu mogli prowadzić niezależne implementacje klientów i formalną weryfikację.
Ogromna liczba bazowych elementów technicznych jest szybko uzupełniana. Zapraszamy deweloperów do głębokiego udziału w tym procesie technicznym i pomocy w tym, aby ta rewolucyjna architektura jak najszybciej stała się rzeczywistym standardem w głównej sieci Ethereum.
