Najnowsze badania Vitalika: Jak protokoły LSDFi i płynność muszą się zmienić, aby zwiększyć decentralizację i zmniejszyć przeciążenie konsensusu?

Niniejszy artykuł koncentruje się głównie na obecnych problemach związanych z ryzykiem centralizacji operatorów węzłów oraz niepotrzebnym obciążeniem konsensusu w protokołach LSDFi i pulach płynności.

Autor:Vitalik Buterin

Tłumaczenie: bayemon.eth, ChainCatcher

Obecny stan rozwoju Ethereum obejmuje w dużej mierze podwójne stakowanie (two-tiered staking), gdzie przez podwójne stakowanie rozumie się model, w którym uczestniczą dwie kategorie uczestników.

• Operator węzła (Node Operator): prowadzi węzeł i zabezpiecza go własną reputacją oraz określoną ilością własnego kapitału jako zabezpieczenie
• Delegat (Delegator): delegaci stakują określoną ilość Ethereum, nie ma minimalnego progu, a poza zabezpieczeniem nie ma dodatkowych ograniczeń co do innych form uczestnictwa

Ten nowy model podwójnego stakowania powstał dzięki licznym pulom stakingowym oferującym płynne tokeny stakingowe (LST). (Rocket Pool i Lido działają w tym modelu).

Jednak obecny model podwójnego stakowania ma dwie wady:

• Ryzyko centralizacji operatorów węzłów: obecne mechanizmy wyboru operatorów węzłów w pulach stakingowych są nadal zbyt scentralizowane
• Niepotrzebne obciążenie konsensusu: Ethereum L1 musi weryfikować około 800 000 podpisów na każdy Epoch, co stanowi ogromne obciążenie dla pojedynczego slotu. Ponadto, ponieważ pule płynnego stakingu wymagają dużych środków, a sieć nie czerpie z tego wystarczających korzyści, jeśli sieć Ethereum mogłaby osiągnąć odpowiedni poziom decentralizacji i bezpieczeństwa bez konieczności podpisywania przez każdego stakującego w każdym slocie, społeczność mogłaby przyjąć takie rozwiązania, skutecznie redukując liczbę podpisów na slot.

W tym artykule opisano rozwiązania powyższych dwóch problemów, zakładając najpierw, że większość kapitału znajduje się w rękach tych, którzy nie chcą samodzielnie zarządzać węzłami stakingowymi w obecnej formie, podpisywać informacji w każdym slocie, blokować depozyty i redystrybuować środki w przypadku slashingów. W takim przypadku, jaką rolę mogą odegrać ci ludzie, aby nadal wnieść znaczący wkład w decentralizację i bezpieczeństwo sieci?

Jak działa obecne podwójne stakowanie?

Obecnie najpopularniejsze dwie pule stakingowe to Lido i RocketPool. W przypadku Lido uczestniczą dwie strony:

• Operator węzła: wybierany przez głosowanie Lido DAO, co oznacza, że w praktyce wybierają go posiadacze LDO. Gdy ktoś wpłaca ETH do systemu smart kontraktów Lido, tworzony jest stETH, który operator może wprowadzić do puli stakingowej (ale ponieważ poświadczenie wypłaty jest powiązane z adresem smart kontraktu, operator nie może swobodnie wypłacać środków)
• Delegat: gdy ktoś wpłaca ETH do systemu smart kontraktów Lido, powstaje stETH, który operator węzła może wykorzystać do stakingu (ale ponieważ poświadczenie wypłaty jest powiązane z adresem smart kontraktu, operator nie może swobodnie wypłacać środków)

W przypadku Rocket Pool wygląda to następująco:

• Operator węzła: każdy może zostać operatorem węzła, wystarczy wpłacić 8 ETH i określoną ilość tokenów RPL.
• Delegat: gdy ktoś wpłaca ETH do systemu smart kontraktów Rocket Pool, powstaje rETH, który operator węzła może wykorzystać do stakingu (również tutaj poświadczenie wypłaty jest powiązane z adresem smart kontraktu, operator nie może swobodnie wypłacać środków).

Rola delegata

W tych systemach (lub w nowych systemach, które mogą powstać w wyniku przyszłych zmian protokołu) kluczowe pytanie brzmi: jaki jest sens ustanawiania delegatów z perspektywy protokołu?

Aby zrozumieć głębię tego pytania, najpierw rozważmy, że w przypadku zmian protokołu wspomnianych w poście, czyli ograniczenia kary slashingowej do 2 ETH, Rocket Pool również obniżyłby wymagany depozyt operatora do 2 ETH, a udział rynkowy Rocket Pool wzrósłby do 100% (dla stakujących i posiadaczy ETH, gdy rETH stanie się pozbawione ryzyka, prawie wszyscy posiadacze ETH staną się posiadaczami rETH lub operatorami węzłów).

Załóżmy, że stopa zwrotu dla posiadaczy rETH wynosi 3% (w tym nagrody protokołu oraz opłaty za pierwszeństwo + MEV), a stopa zwrotu dla operatorów węzłów wynosi 4%. Przyjmujemy również, że całkowita podaż ETH wynosi 100 milionów.

Obliczenia są następujące. Aby uniknąć obliczeń składanych, liczymy zyski dzienne:

Teraz załóżmy, że Rocket Pool nie istnieje, minimalny depozyt dla każdego stakującego spada do 2 ETH, całkowity limit płynności wynosi 6,25 miliona ETH, a stopa zwrotu operatora węzła spada do 1%. Przeliczmy ponownie:

Rozważając koszt ataku w obu przypadkach: w pierwszym przypadku atakujący nie zarejestruje się jako delegat, ponieważ delegat nie ma faktycznie żadnych praw do wypłaty, więc nie ma to sensu. Zatem całość ETH wykorzysta do stakingu jako operator węzła. Aby osiągnąć 1/3 całkowitej ilości stakingu, musi włożyć 2,08 miliona ETH (co i tak jest dużą liczbą). W drugim przypadku atakujący musi tylko zainwestować środki, aby osiągnąć 1/3 całkowitej ilości stakingu, również musi włożyć 2,08 miliona ETH.

Z punktu widzenia ekonomii stakingu i kosztu ataku, końcowy rezultat w obu przypadkach jest identyczny. Udział ETH w rękach operatorów węzłów rośnie codziennie o 0,00256%, a udział ETH w rękach nie-operatorów węzłów maleje codziennie o 0,00017%. Koszt ataku to 2,08 miliona ETH. W tym modelu delegat wydaje się być bezużyteczną maszyną Rube Goldberga i racjonalna społeczność mogłaby preferować usunięcie pośrednika, znaczne zmniejszenie nagród za staking i ograniczenie całkowitej ilości stakowanego ETH do 6,25 miliona.

Oczywiście, ten artykuł nie sugeruje czterokrotnego obniżenia nagród za staking i sztywnego ograniczenia całkowitej ilości stakingu do 6,25 miliona. Przeciwnie, główną tezą jest to, że dobrze działający system stakingowy powinien mieć kluczową cechę: delegaci powinni odgrywać ważną rolę w całym systemie. Co więcej, jeśli delegaci są w dużej mierze motywowani presją społeczności i altruizmem do podejmowania właściwych działań, to też jest w porządku; w końcu to właśnie te siły napędzają dziś wdrażanie zdecentralizowanych i bezpiecznych rozwiązań stakingowych.

Obowiązki delegata

Jeśli delegaci mogą odegrać znaczącą rolę w systemie stakingowym, to jaka może być ta rola?

Uważam, że są dwie odpowiedzi:

• Wybór delegata: delegaci mogą wybrać, którym operatorom węzłów powierzyć swoje interesy. Waga operatora węzła w mechanizmie konsensusu jest proporcjonalna do całkowitej ilości stakingu delegowanej do niego. Obecnie mechanizm wyboru delegata jest ograniczony, tj. posiadacze rETH lub stETH mogą wycofać swoje ETH i przejść do innej puli, ale rzeczywista dostępność wyboru delegata może być znacznie zwiększona.
• Udział w mechanizmie konsensusu: delegaci mogą wybrać, by odegrać pewną rolę w mechanizmie konsensusu, z mniejszą odpowiedzialnością niż pełne prowadzenie węzła, bez długiego okresu wyjścia i ryzyka slashingów, ale nadal mogą równoważyć operatorów węzłów.

Wzmocnienie praw wyboru delegata

Są trzy sposoby na wzmocnienie uprawnień wyborczych delegata:

• Ulepszenie narzędzi do głosowania w pulach
• Zwiększenie konkurencji między pulami
• Utrwalenie praw delegata

Obecnie głosowanie w pulach jest w praktyce nieefektywne: w Rocket Pool każdy może zostać operatorem węzła, w Lido głosowanie odbywa się przez posiadaczy LDO, a nie ETH. Lido zaproponowało podwójny system zarządzania LDO + stETH, w którym można aktywować mechanizm ochronny, blokujący nowe głosowania, a tym samym uniemożliwiający dodawanie lub usuwanie operatorów węzłów, co w pewnym stopniu daje posiadaczom stETH głos. Niemniej jednak, ta władza jest ograniczona i mogłaby być silniejsza.

Konkurencja między pulami już istnieje, ale jest stosunkowo słaba. Głównym wyzwaniem jest to, że tokeny stakingowe mniejszych pul mają niższą płynność, trudniej zdobyć zaufanie i są rzadziej wspierane przez aplikacje.

Możemy poprawić dwa pierwsze problemy, ograniczając wysokość kary do niewielkiej kwoty, np. 2 lub 4 ETH. Pozostałe ETH można bezpiecznie zdeponować i natychmiast wypłacić, dzięki czemu dwukierunkowa wymiana pozostaje możliwa nawet dla mniejszych pul stakingowych. Możemy poprawić trzeci problem, tworząc kontrakt emisji ogólnej do zarządzania LST (podobnie jak ERC-4337 i ERC-6900 dla portfeli), aby zagwarantować, że każdy token stakingowy wydany przez ten kontrakt jest bezpieczny.

Obecnie w protokole nie istnieje jeszcze utrwalona władza delegata, ale taki scenariusz wydaje się możliwy w przyszłości. Obejmowałoby to logikę podobną do powyższych pomysłów, ale wdrożoną na poziomie protokołu. Więcej o zaletach i wadach utrwalania rzeczy można znaleźć w tym artykule.

Te pomysły są ulepszeniem obecnego stanu, ale ich zalety są ograniczone. Zarządzanie przez głosowanie tokenami ma swoje problemy, a każda forma nieincentywowanego wyboru delegata jest w istocie formą głosowania tokenami; to zawsze było moją główną krytyką wobec delegated proof of stake. Dlatego warto rozważyć silniejsze formy udziału w konsensusie.

Udział w konsensusie

Nawet bez obecnych problemów płynnego stakingu, obecne metody indywidualnego stakingu mają swoje ograniczenia. Załóżmy, że używamy single-slot finality, w idealnym przypadku każdy slot może obsłużyć około 100 000 do 1 000 000 podpisów BLS. Nawet jeśli użyjemy rekurencyjnych SNARK-ów do agregacji podpisów, dla śledzenia podpisów trzeba przypisać każdemu podpisowi pole bitowe uczestnika. Jeśli Ethereum stanie się siecią o globalnej skali, nawet całkowicie zdecentralizowane przechowywanie pól bitowych nie wystarczy: 16 MB na slot obsłuży tylko około 64 milionów stakujących.

Z tej perspektywy warto podzielić staking na warstwę o wyższej złożoności i warstwę o niższej złożoności: warstwa o wyższej złożoności działa w każdym slocie, ale może mieć tylko 10 000 uczestników, podczas gdy warstwa o niższej złożoności jest wywoływana tylko okazjonalnie. Warstwa o niższej złożoności może być całkowicie wolna od slashingów lub losowo przyznawać uczestnikom możliwość zdeponowania środków i zostania podmiotem slashingów przez kilka slotów.

W praktyce można to osiągnąć, podnosząc limit salda walidatora, a następnie zwiększając próg salda (np. 2048 ETH), aby określić, którzy obecni walidatorzy trafiają do warstwy o wyższej lub niższej złożoności.

Poniżej kilka sugestii, jak mogą działać te role małych stakujących:

• W każdym slocie losowo wybieranych jest 10 000 małych stakujących, którzy mogą podpisać to, co uważają za reprezentatywne dla danego slotu. Używając tych małych stakujących jako wejścia, uruchamia się regułę wyboru forka LMD GHOST. Jeśli wybór forka przez małych stakujących i operatorów węzłów różni się, klient użytkownika nie akceptuje żadnego bloku jako ostatecznego i wyświetla błąd. To zmusza społeczność do interwencji i rozwiązania sytuacji.
• Delegaci mogą wysłać transakcję, ogłaszając sieci, że są online i gotowi pełnić rolę małego stakującego przez następną godzinę. Wiadomości wysyłane przez węzły (bloki lub dowody) wymagają podpisu zarówno operatora węzła, jak i losowo wybranego delegata, aby potwierdzić wiadomość.
• Delegaci mogą wysłać transakcję, ogłaszając sieci, że są online i gotowi pełnić rolę małego stakującego przez następną godzinę. W każdej epoce wybieranych jest 10 losowych delegatów jako dostawców listy włączeń (inclusion list provider) oraz 10 000 kolejnych jako wyborców. Są oni wybierani przed slotem k i mają okno k slotów na opublikowanie na łańcuchu potwierdzenia, że są online. Każdy potwierdzony dostawca listy włączeń może opublikować listę włączeń; dla każdej listy, jeśli nie zostanie uwzględniona w bloku lub nie będzie wystarczającej liczby głosów wyborców wskazujących, że lista jest niedostępna, blok zostanie uznany za nieważny.

Wspólną cechą tych małych węzłów stakingowych jest to, że nie muszą aktywnie uczestniczyć w każdym slocie, a nawet mogą wykonywać całą pracę jako light node. W związku z tym wdrożenie węzła wymaga jedynie weryfikacji warstwy konsensusu, a operatorzy mogą korzystać z aplikacji lub wtyczek do przeglądarki, które są w większości pasywne, mają niskie wymagania obliczeniowe, sprzętowe i techniczne, a nawet nie wymagają zaawansowanych technologii jak ZK-EVM.

Wszystkie te "małe role" mają wspólny cel: zapobieganie cenzurze transakcji przez 51% większość operatorów węzłów. Pierwszy i drugi sposób mogą również zapobiegać cofnięciu finalności przez większość. Trzeci sposób koncentruje się bardziej bezpośrednio na cenzurze, ale jest bardziej podatny na wybory większości operatorów węzłów.

Te pomysły zostały napisane z perspektywy wdrażania podwójnego stakingu na poziomie protokołu, ale można je również wdrożyć jako funkcje puli stakingowych. Oto kilka konkretnych pomysłów na implementację:

1. Z perspektywy protokołu każdy walidator może ustawić dwa klucze stakingowe: jeden klucz stakingowy P oraz powiązany adres Ethereum, który może wywołać i wyprowadzić szybki klucz stakingowy Q. Podpisy dotyczące wyboru forka są śledzone przez P, a podpisy Q, jeśli wyniki przechowywania PQ są niespójne, żaden blok nie jest akceptowany jako ostateczny, a pula płynności losowo wybiera przedstawiciela.
2. Protokół zasadniczo pozostaje niezmieniony, ale publiczny klucz walidatora w danym okresie jest ustawiony jako P+Q. Należy zauważyć, że dla slashingów dwa komunikaty mogą mieć różne klucze Q, ale ten sam klucz P; projekt slashingów musi to uwzględnić.
3. Klucz Q może być używany w protokole wyłącznie do podpisywania i weryfikacji listy włączeń w bloku. W tym przypadku Q może być smart kontraktem, a nie pojedynczym kluczem, dzięki czemu pula stakingowa może wdrożyć bardziej złożoną logikę głosowania, akceptując listy włączeń od losowo wybranych dostawców lub wystarczającą liczbę głosów wskazujących, że lista jest niedostępna.

Wnioski

Jeśli zostaną prawidłowo wdrożone, drobne korekty w projektowaniu proof-of-stake mogą jednocześnie rozwiązać dwa problemy:

• Zapewnić tym, którzy dziś nie mają zasobów lub możliwości prowadzenia niezależnego proof-of-stake, możliwość uczestnictwa w stakingu, zachowując większą władzę w ich rękach: obejmuje to (i) możliwość wyboru, które węzły wspierać, oraz (ii) aktywne uczestnictwo w konsensusie w sposób lżejszy, ale nadal znaczący, niż pełne prowadzenie węzła stakingowego. Nie wszyscy uczestnicy wybiorą jedną lub obie opcje, ale każdy, kto wybierze jedną lub obie, uzyska znaczną poprawę w stosunku do obecnego stanu.
• Zmniejszyć liczbę podpisów, które warstwa konsensusu Ethereum musi obsłużyć w każdym slocie, nawet w systemie single-slot finality, redukując ją do około 10 000 lub podobnej liczby. To również pomoże w decentralizacji, ułatwiając każdemu uruchomienie węzła walidatora.

Dla tych rozwiązań można znaleźć odpowiedzi na różnych poziomach abstrakcji: uprawnienia przyznane użytkownikom w ramach protokołu proof-of-stake, wybór użytkownika między protokołami proof-of-stake oraz ustanowienie w protokole. Wybór ten należy rozważyć ostrożnie i zazwyczaj najlepiej wybrać minimalną możliwą implementację, aby maksymalnie ograniczyć złożoność protokołu i zmiany w ekonomii protokołu, jednocześnie osiągając zamierzone cele.

Szczególne podziękowania dla Mike'a Neudera, Justina Drake'a i innych za opinie i recenzje. Zobacz także: artykuły Mike'a Neudera, Dankrada Feista i arixon.eth na podobny temat.