Vitalik: Jakie są możliwe ulepszenia Ethereum PoS i jakie są drogi do ich wdrożenia?

Ten artykuł koncentruje się na problemie „Merge” Ethereum: jakie aspekty technicznego projektu proof-of-stake można jeszcze ulepszyć i jakie są możliwe drogi do tych ulepszeń?

Autor:Vitalik Buterin

Tłumaczenie: Deng Tong, Jinse Finance

Szczególne podziękowania dla Justina Drake’a, Hsiao-wei Wang, @antonttc oraz Francesco za uwagi i recenzję.

Początkowo „Merge” odnosił się do najważniejszego wydarzenia w historii protokołu Ethereum od czasu jego uruchomienia: długo oczekiwanej i trudnej do osiągnięcia transformacji z proof-of-work na proof-of-stake. Dziś Ethereum działa już prawie dwa lata jako stabilny system proof-of-stake, który wykazuje się doskonałą stabilnością, wydajnością i odpornością na ryzyko centralizacji. Jednak proof-of-stake nadal posiada kilka istotnych obszarów wymagających ulepszeń.

W mojej mapie drogowej z 2023 roku podzieliłem to na kilka części: ulepszenia techniczne, takie jak stabilność, wydajność i dostępność dla mniejszych walidatorów, oraz zmiany ekonomiczne mające na celu przeciwdziałanie ryzyku centralizacji. Pierwsza część przejęła tytuł „Merge”, a druga stała się częścią „Scourge”.

Ten artykuł koncentruje się na części „Merge”: jakie aspekty technicznego projektu proof-of-stake można jeszcze ulepszyć i jakie są możliwe drogi do tych ulepszeń?

Nie jest to wyczerpująca lista możliwych ulepszeń proof-of-stake; zamiast tego jest to lista pomysłów, które są aktywnie rozważane.

Finalność pojedynczego slotu i demokratyzacja stakingu

Jaki problem rozwiązujemy?

Obecnie potrzeba 2-3 epok (około 15 minut), aby blok został sfinalizowany, a do zostania walidatorem wymagane jest 32 ETH. Początkowo był to kompromis mający na celu zbalansowanie trzech celów:

• Maksymalizacja liczby walidatorów mogących uczestniczyć w stakingu (co bezpośrednio oznacza minimalizację minimalnej ilości ETH wymaganej do stakingu)
• Minimalizacja czasu finalizacji
• Minimalizacja kosztów operacyjnych węzłów

Te trzy cele są ze sobą sprzeczne: aby osiągnąć ekonomiczną finalność (czyli atakujący musi zniszczyć dużą ilość ETH, aby odwrócić sfinalizowany blok), każdy walidator musi podpisać dwie wiadomości przy każdej finalizacji. Jeśli więc mamy wielu walidatorów, albo potrzeba dużo czasu na przetworzenie wszystkich podpisów, albo wymagane są bardzo wydajne węzły, by obsłużyć wszystkie podpisy jednocześnie.

Zauważ, że wszystko to zależy od kluczowego celu Ethereum: zapewnienia, że nawet udany atak będzie bardzo kosztowny dla atakującego. To właśnie oznacza termin „ekonomiczna finalność”. Gdybyśmy nie mieli tego celu, moglibyśmy rozwiązać ten problem poprzez losowy wybór komitetu do finalizacji każdego slotu (tak jak robi to Algorand). Problem z tym podejściem polega na tym, że jeśli atakujący kontroluje 51% walidatorów, może przeprowadzić atak bardzo niskim kosztem (odwracając finalizację bloków, cenzurując lub opóźniając finalizację): tylko część węzłów w komitecie może zostać wykryta jako uczestnicząca w ataku i ukarana, niezależnie czy przez slashing, czy przez soft fork mniejszościowy. Oznacza to, że atakujący może wielokrotnie atakować łańcuch. Jeśli więc chcemy ekonomicznej finalności, proste podejście oparte na komitecie nie działa i na pierwszy rzut oka rzeczywiście potrzebujemy pełnego zestawu walidatorów.

Idealnie chcielibyśmy zachować ekonomiczną finalność, a jednocześnie poprawić obecny stan rzeczy w dwóch aspektach:

• Finalizować blok w jednym slocie (najlepiej utrzymując lub nawet skracając obecne 12 sekund), zamiast 15 minut
• Pozwolić walidatorom stakować już od 1 ETH (obniżając próg z 32 ETH do 1 ETH)

Pierwszy cel jest uzasadniony dwoma argumentami, które można postrzegać jako „upodobnienie właściwości Ethereum do (bardziej scentralizowanych) wydajnościowych łańcuchów L1”.

Po pierwsze, zapewnia, że wszyscy użytkownicy Ethereum korzystają z wyższego poziomu bezpieczeństwa zapewnianego przez mechanizm finalizacji. Obecnie większość użytkowników nie korzysta z tej ochrony, bo nie chce czekać 15 minut; dzięki finalności pojedynczego slotu użytkownicy mogą zobaczyć finalizację transakcji niemal natychmiast po jej potwierdzeniu. Po drugie, jeśli użytkownicy i aplikacje nie muszą się martwić o możliwość cofnięcia łańcucha (poza rzadkimi przypadkami nieaktywności), upraszcza to protokół i otaczającą go infrastrukturę.

Drugi cel wynika z chęci wsparcia indywidualnych stakerów. Sondaże wielokrotnie pokazywały, że główną przeszkodą dla większej liczby osób chcących stakować samodzielnie jest minimalny próg 32 ETH. Obniżenie tego progu do 1 ETH rozwiązałoby ten problem, tak że inne kwestie stałyby się główną barierą dla indywidualnego stakingu.

Jest jednak wyzwanie: szybsza finalność i bardziej demokratyczny staking są sprzeczne z celem minimalizacji kosztów. W rzeczywistości to właśnie ten fakt sprawił, że od początku nie przyjęto finalności pojedynczego slotu. Jednak ostatnie badania zaproponowały kilka możliwych rozwiązań tego problemu.

Co to jest i jak działa?

Finalność pojedynczego slotu polega na użyciu algorytmu konsensusu, który finalizuje blok w jednym slocie. Samo w sobie nie jest to trudne do osiągnięcia: wiele algorytmów (np. konsensus Tendermint) już to realizuje z optymalnymi właściwościami. Unikalną cechą Ethereum, której Tendermint nie obsługuje, jest „inactivity leak” – nawet jeśli ponad 1/3 walidatorów jest offline, łańcuch może nadal działać i ostatecznie się zregenerować. Na szczęście to już zostało spełnione: istnieją propozycje modyfikacji konsensusu w stylu Tendermint, by obsługiwał inactivity leak.

Wiodące propozycje finalności pojedynczego slotu

Najtrudniejszą częścią problemu jest ustalenie, jak sprawić, by finalność pojedynczego slotu działała przy bardzo dużej liczbie walidatorów, nie powodując ogromnych kosztów operacyjnych dla operatorów węzłów. W tym celu istnieje kilka wiodących rozwiązań:

Opcja 1: Brute force – praca nad lepszymi protokołami agregacji podpisów, być może z użyciem ZK-SNARKów, co faktycznie pozwala obsłużyć podpisy milionów walidatorów w każdym slocie.

Horn, jeden z projektów zaproponowanych dla lepszych protokołów agregacji.

Opcja 2: Orbit Committee – nowy mechanizm pozwalający losowo wybranemu średniemu komitetowi odpowiadać za finalizację łańcucha, ale w sposób zachowujący pożądane właściwości kosztu ataku.

Jednym ze sposobów myślenia o Orbit SSF jest to, że otwiera on kompromisową przestrzeń od x=0 (komitet w stylu Algorand, bez ekonomicznej finalności) do x=1 (obecny stan Ethereum), wyznaczając punkty pośrednie, gdzie Ethereum nadal ma wystarczającą ekonomiczną finalność dla bardzo wysokiego bezpieczeństwa, a jednocześnie zyskujemy efektywność dzięki udziałowi tylko losowo wybranej próbki walidatorów średniej wielkości w każdym slocie.

Orbit wykorzystuje istniejącą heterogeniczność wielkości depozytów walidatorów, by uzyskać jak najwięcej ekonomicznej finalności, a jednocześnie daje małym walidatorom odpowiednią rolę. Ponadto Orbit stosuje powolną rotację komitetów, by zapewnić duże nakładanie się kolejnych kworum, co gwarantuje, że ekonomiczna finalność nadal obowiązuje na granicach rotacji komitetów.

Opcja 3: Dwupoziomowy staking – mechanizm, w którym stakerzy są podzieleni na dwie kategorie: jedna z wyższym wymaganiem depozytu, druga z niższym. Tylko poziom z wyższym depozytem bierze bezpośredni udział w zapewnianiu ekonomicznej finalności. Istnieją różne propozycje dotyczące praw i obowiązków poziomu z niższym depozytem (np. zobacz post o Rainbow Staking). Typowe pomysły obejmują:

• Prawo delegowania stake’u do wyższego poziomu
• Losowo wybierani stakerzy niższego poziomu muszą potwierdzać każdy blok
• Prawo do generowania listy włączeń

Jakie są powiązania z istniejącymi badaniami?

• Drogi do osiągnięcia finalności pojedynczego slotu (2022):
• Konkretne propozycje protokołu finalności pojedynczego slotu dla Ethereum (2023):
• Orbit SSF:
• Dalsza analiza mechanizmów w stylu Orbit:
• Horn, protokół agregacji podpisów (2022):
• Agregacja podpisów dla konsensusu na dużą skalę (2023):
• Protokół agregacji podpisów autorstwa Khovratovicha i in.:
• Agregacja podpisów oparta na STARK (2022):
• Rainbow Staking:

Co jeszcze pozostało do zrobienia? Jakie są kompromisy?

Są cztery główne możliwe ścieżki (możemy też zastosować podejście hybrydowe):

• Utrzymanie status quo
• Orbit SSF
• Brute force SSF
• SSF z dwupoziomowym stakingiem

(1) oznacza brak zmian, pozostawienie stakingu bez zmian, ale to sprawia, że bezpieczeństwo Ethereum i właściwości decentralizacji stakingu są gorsze niż mogłyby być.

(2) Unika „high-tech”, rozwiązując problem przez sprytne przemyślenie założeń protokołu: rozluźniamy wymaganie „ekonomicznej finalności”, tak by koszt ataku był wysoki, ale akceptujemy, że może być 10 razy niższy niż obecnie (np. koszt ataku 2.5 miliarda dolarów zamiast 25 miliardów dolarów). Powszechnie uważa się, że dzisiejsza ekonomiczna finalność Ethereum jest znacznie wyższa niż potrzeba, a główne ryzyka bezpieczeństwa leżą gdzie indziej, więc można uznać to za akceptowalny kompromis.

Główna praca polega na weryfikacji, czy mechanizm Orbit jest bezpieczny i posiada pożądane właściwości, a następnie pełnej formalizacji i wdrożeniu. Ponadto EIP-7251 (zwiększenie maksymalnego efektywnego salda) pozwala na dobrowolne łączenie sald walidatorów, co natychmiast zmniejsza koszty weryfikacji łańcucha i może być skutecznym etapem początkowym wdrożenia Orbit.

(3) Unika sprytnego przemyślenia i zamiast tego rozwiązuje problem siłą technologii. Wymaga to zebrania ogromnej liczby podpisów (ponad milion) w bardzo krótkim czasie (5-10 sekund).

(4) Unika sprytnego przemyślenia i high-tech, ale tworzy system stakingu dwupoziomowego, który nadal niesie ryzyko centralizacji. Ryzyko zależy w dużej mierze od konkretnych praw przyznanych niższemu poziomowi stakingu. Na przykład:

• Jeśli stakerzy niższego poziomu muszą delegować prawo do potwierdzania wyższemu poziomowi, delegacja może się scentralizować i skończymy z dwoma wysoko scentralizowanymi poziomami stakingu.
• Jeśli wymagana jest losowa próbka niższego poziomu do zatwierdzania każdego bloku, atakujący może za bardzo małą ilość ETH zablokować finalność.
• Jeśli stakerzy niższego poziomu mogą tylko tworzyć listy włączeń, warstwa potwierdzająca może pozostać scentralizowana, a atak 51% na warstwę potwierdzającą może cenzurować same listy włączeń.

Można łączyć różne strategie, np.:

• (1 + 2): Dodanie Orbit bez wdrażania finalności pojedynczego slotu.
• (1 + 3): Użycie brute force do zmniejszenia minimalnego depozytu bez wdrażania finalności pojedynczego slotu. Wymagana agregacja jest 64 razy mniejsza niż w przypadku czystego (3), więc problem jest łatwiejszy.
• (2 + 3): Wdrożenie Orbit SSF z konserwatywnymi parametrami (np. komitet 128k walidatorów zamiast 8k lub 32k) i użycie brute force do zwiększenia wydajności.
• (1 + 4): Dodanie Rainbow Staking bez wdrażania finalności pojedynczego slotu.

Jak to współdziała z innymi częściami mapy drogowej?

Oprócz innych korzyści, finalność pojedynczego slotu zmniejsza ryzyko niektórych typów ataków MEV na wiele bloków. Ponadto w świecie finalności pojedynczego slotu projekt rozdziału validator-proposer i inne pipeline’y produkcji bloków w protokole muszą być zaprojektowane inaczej.

Słabością strategii brute force jest to, że utrudniają one skracanie czasu slotu.

Wybór pojedynczego tajnego lidera

Jaki problem rozwiązujemy?

Obecnie wiadomo z wyprzedzeniem, który walidator zaproponuje następny blok. Powoduje to lukę bezpieczeństwa: atakujący może monitorować sieć, zidentyfikować, który walidator odpowiada któremu adresowi IP i przeprowadzić atak DoS na walidatora tuż przed jego propozycją bloku.

Co to jest? Jak to działa?

Najlepszym sposobem rozwiązania problemu DoS jest ukrycie informacji o tym, który walidator wygeneruje następny blok, przynajmniej do momentu jego wygenerowania. Zauważ, że jeśli usuniemy wymóg „pojedynczości”, jest to łatwe: jedno rozwiązanie to pozwolić każdemu na stworzenie następnego bloku, ale wymagać, by randao ujawniło wartość mniejszą niż 2256 / N. Średnio tylko jeden walidator spełni ten warunek – ale czasami będzie ich dwóch lub więcej, czasami zero. Połączenie wymogu „tajności” z „pojedynczością” od dawna stanowi wyzwanie.

Protokół wyboru pojedynczego tajnego lidera (SSLE) rozwiązuje ten problem, używając kryptografii do utworzenia „ślepego” identyfikatora walidatora dla każdego walidatora, a następnie pozwalając wielu propozytorom na przetasowanie i ponowne „zaślepienie” puli tych identyfikatorów (podobnie jak działają sieci mieszające). W każdym slocie wybierany jest losowo jeden ślepy identyfikator. Tylko właściciel tego identyfikatora może wygenerować ważny dowód do propozycji bloku, ale nikt nie wie, który walidator się za nim kryje.

Protokół Whisk SSLE

Jakie są powiązania z istniejącymi badaniami?

• Artykuł Dana Boneha (2020):
• Whisk (konkretna propozycja dla Ethereum, 2022):
• Tag wyboru pojedynczego tajnego lidera na ethresear.ch:
• Uproszczony SSLE z użyciem podpisów pierścieniowych:

Co jeszcze pozostało do zrobienia? Jakie są kompromisy?

W praktyce pozostaje znaleźć i wdrożyć wystarczająco prosty protokół, by można go było łatwo zaimplementować na mainnecie. Bardzo cenimy sobie prostotę protokołu Ethereum i nie chcemy dalszego zwiększania złożoności. Widzieliśmy, że implementacje SSLE zwiększają specyfikację o setki linii kodu i wprowadzają nowe założenia kryptograficzne. Opracowanie wystarczająco efektywnej implementacji SSLE odpornej na komputery kwantowe to nadal otwarty problem.

Ostatecznie może się okazać, że tylko wtedy, gdy z innych powodów (np. drzewo stanów, ZK-EVM) wprowadzimy ogólny mechanizm dowodów zero-knowledge na L1 protokołu Ethereum, „marginalna dodatkowa złożoność” SSLE spadnie do akceptowalnego poziomu.

Inną opcją jest całkowite zignorowanie SSLE i rozwiązanie problemu DoS za pomocą środków poza protokołem (np. na warstwie p2p).

Jak to współdziała z innymi częściami mapy drogowej?

Jeśli dodamy mechanizm rozdziału validator-proposer (APS), np. execution tickets, to bloki wykonawcze (czyli zawierające transakcje Ethereum) nie będą wymagały SSLE, bo możemy polegać na wyspecjalizowanych budowniczych bloków. Jednak dla bloków konsensusu (czyli zawierających wiadomości protokołu, np. dowody, części list włączeń itd.) nadal skorzystamy z SSLE.

Szybsze potwierdzanie transakcji

Jaki problem rozwiązujemy?

Dalsze skrócenie czasu potwierdzania transakcji w Ethereum – z 12 do 4 sekund – jest wartościowe. Poprawi to znacząco doświadczenie użytkownika na L1 i dla rozwiązań opartych na rollupach, a także zwiększy efektywność protokołów DeFi. Ułatwi to również decentralizację L2, bo pozwoli wielu aplikacjom L2 działać na rollupach, zmniejszając potrzebę budowania własnych zdecentralizowanych mechanizmów kolejkowania na L2.

Co to jest? Jak to działa?

Istnieją tu zasadniczo dwie techniki:

• Skrócenie czasu slotu, np. do 8 lub 4 sekund. Nie musi to oznaczać 4-sekundowej finalności: finalność wymaga zasadniczo trzech rund komunikacji, więc każdą rundę można uczynić osobnym blokiem, a po 4 sekundach uzyskać wstępne potwierdzenie.
• Pozwolenie propozytorowi na publikowanie pre-potwierdzeń w trakcie slotu. W skrajnym przypadku propozytor może na bieżąco włączać transakcje do swojego bloku i natychmiast publikować pre-potwierdzenie dla każdej z nich („moja pierwsza transakcja to 0×1234...”, „moja druga to 0×5678...”). Konfliktujące potwierdzenia można rozwiązać na dwa sposoby: (i) przez slashing propozytora lub (ii) przez głosowanie walidatorów, która była wcześniejsza.

Jakie są powiązania z istniejącymi badaniami?

• Oparte na pre-potwierdzeniach:
• PEPC (Protocol-Enforced Proposer Commitments):
• Przeplatane cykle na równoległych łańcuchach (pomysł na niskie opóźnienia z 2018):

Co jeszcze pozostało do zrobienia? Jakie są kompromisy?

Nie jest jeszcze jasne, na ile praktyczne jest skrócenie czasu slotu. Nawet dziś wielu walidatorów na świecie ma trudności z uzyskaniem dowodu wystarczająco szybko. Próba 4-sekundowego slotu grozi centralizacją zestawu walidatorów i sprawia, że poza nielicznymi uprzywilejowanymi regionami bycie walidatorem jest niepraktyczne z powodu opóźnień.

Słabością metody pre-potwierdzeń propozytora jest to, że znacznie poprawia średni czas włączenia, ale nie poprawia najgorszego przypadku: jeśli obecny propozytor działa dobrze, twoja transakcja zostanie pre-potwierdzona w 0,5 sekundy zamiast (średnio) 6 sekund, ale jeśli propozytor jest offline lub działa źle, nadal musisz czekać pełne 12 sekund na rozpoczęcie kolejnego slotu i nowego propozytora.

Ponadto pozostaje otwarta kwestia, jak motywować pre-potwierdzenia. Propozytor ma motywację, by maksymalnie długo utrzymywać opcjonalność. Jeśli walidatorzy podpisują terminowość pre-potwierdzeń, nadawca transakcji może przekazać część opłaty w zamian za natychmiastowe pre-potwierdzenie, ale to nakłada dodatkowe obciążenie na walidatorów i może utrudnić im pozostanie neutralnymi „niemymi rurami”.

Z drugiej strony, jeśli tego nie zrobimy i utrzymamy czas finalizacji na poziomie 12 sekund (lub dłużej), ekosystem będzie bardziej polegał na mechanizmach pre-potwierdzeń budowanych na L2, a interakcje między L2 będą trwały dłużej.

Jak to współdziała z innymi częściami mapy drogowej?

Pre-potwierdzenia oparte na propozytorze w praktyce wymagają mechanizmu rozdziału validator-proposer (APS), np. execution tickets. W przeciwnym razie presja na zapewnienie pre-potwierdzeń w czasie rzeczywistym może nadmiernie obciążyć zwykłych walidatorów.

Inne obszary badań

Odzyskiwanie po ataku 51%

Powszechnie uważa się, że jeśli dojdzie do ataku 51% (w tym ataku, którego nie da się udowodnić kryptograficznie, np. cenzury), społeczność zjednoczy się, by wdrożyć soft fork mniejszościowy, zapewniając zwycięstwo „dobrym”, a „źli” zostaną ukarani za nieaktywność lub przez slashing. Jednak tak duże poleganie na warstwie społecznej można uznać za niezdrowe. Możemy spróbować ograniczyć zależność od warstwy społecznej i uczynić proces odzyskiwania możliwie najbardziej zautomatyzowanym.

Pełna automatyzacja jest niemożliwa, bo wtedy mielibyśmy algorytm konsensusu tolerujący >50% błędów, a matematyczne ograniczenia takich algorytmów są dobrze znane i bardzo rygorystyczne. Możemy jednak osiągnąć częściową automatyzację: np. jeśli klient wykryje cenzurę transakcji przez wystarczająco długi czas, może automatycznie odmówić uznania danego łańcucha za sfinalizowany, a nawet za główną gałąź wyboru forka. Kluczowym celem jest zapewnienie, że „źli” nie mogą szybko wygrać ataku.

Zwiększenie progu kworum

Obecnie blok jest finalizowany, jeśli popiera go 67% stakerów. Niektórzy uważają, że to zbyt agresywne. W całej historii Ethereum tylko raz (i to bardzo krótko) doszło do braku finalności. Jeśli ten procent zwiększymy do 80%, liczba okresów bez finalności wzrośnie relatywnie niewiele, ale Ethereum zyska na bezpieczeństwie: zwłaszcza wiele bardziej kontrowersyjnych sytuacji spowoduje tymczasowe zatrzymanie finalności. To wydaje się zdrowsze niż natychmiastowe zwycięstwo „złej strony”, niezależnie czy są to atakujący, czy klient z błędem.

To także odpowiada na pytanie „po co indywidualny staking”. Dziś większość stakerów korzysta z pul, a osiągnięcie przez indywidualnych stakerów 51% stake’u ETH wydaje się mało prawdopodobne. Jednak jeśli się postaramy, osiągnięcie przez indywidualnych stakerów progu blokującego większość (zwłaszcza przy większości 80%, więc próg blokujący to tylko 21%) wydaje się możliwe. Dopóki indywidualni stakerzy nie uczestniczą w ataku 51% (czy to cofanie finalności, czy cenzura), taki atak nie odniesie „czystego zwycięstwa”, a indywidualni stakerzy aktywnie pomogą zorganizować soft fork mniejszościowy.

Odporność na komputery kwantowe

Metaculus obecnie uważa, że – choć z dużym marginesem błędu – komputery kwantowe prawdopodobnie zaczną łamać kryptografię w latach 30. XXI wieku:

Eksperci od komputerów kwantowych, tacy jak Scott Aaronson, ostatnio również zaczęli poważniej rozważać możliwość praktycznego działania komputerów kwantowych w średnim terminie. Ma to wpływ na całą mapę drogową Ethereum: oznacza to, że każda część protokołu Ethereum obecnie polegająca na krzywych eliptycznych będzie potrzebować alternatywy opartej na hashach lub innych mechanizmach odpornych na komputery kwantowe. W szczególności nie możemy zakładać, że zawsze będziemy mogli polegać na doskonałych właściwościach agregacji BLS do obsługi podpisów z dużych zestawów walidatorów. To uzasadnia ostrożność w założeniach dotyczących wydajności projektów proof-of-stake oraz potrzebę aktywnego rozwoju alternatyw odpornych na komputery kwantowe.