Zmiana w specyfikacji zatwierdzona 26 października zamyka lukę w przetwarzaniu depozytów w Ethereum, która mogła pozwolić operatorom węzłów na przekierowanie oczekujących w kolejce depozytów stakerów na salda pod własną kontrolą po aktywacji uaktualnienia sieci o nazwie Glamsterdam. Poprawka trafiła do repozytorium consensus-specs — referencyjnych zasad implementowanych przez zespoły klientów Ethereum — dwa tygodnie po tym, jak luka została zgłoszona na GitHubie. Przekierowane mogły zostać wyłącznie depozyty nadal oczekujące w kolejce w momencie aktywacji fork'a, a ponieważ Glamsterdam nie osiągnął jeszcze mainnetu, żadne środki nie przepadły.

Jak operator mógł przejąć depozyt stakera

Protokoły poolingowego stakingu zazwyczaj dzielą pracę związaną z prowadzeniem walidatora. Protokół wnosi ETH, a zewnętrzny operator węzła przechowuje klucz podpisywania walidatora. Ethereum oddziela podpisywanie od wypłat, dzięki czemu operator może prowadzić walidator, nie mając możliwości wypłaty stawki protokołu.

Glamsterdam łączy zmiany w warstwie wykonawczej z uaktualnieniemstwy konsensusu o nazwie Gloas i dodaje builderów jako nowy typ uczestnika w ramach wbudowanej separacji proponującego i buildera. Builderzy składają część bloku zawierającą transakcje i posiadają własne salda. Przy fork'u Ethereum konwertuje kwalifikujące się depozyty nadal czekające w kolejce na konta builderów.

To właśnie w tej konwersji tkwiła luka. Według starej zasady, gdy oczekujący depozyt zarejestrował buildera dla danego klucza, każdy kolejny depozyt dla tego klucza zasilał buildera — niezależnie od tego, gdzie wskazywały jego poświadczenia wypłat. Operator mógł umieścić w kolejce depozyt buildera dla nowego klucza z adresu, którym się posługiwał. Jeśli protokół stakingowy następnie sfinansowałby depozyt walidatora dla tego samego klucza i oba depozyty byłyby nadal oczekujące w momencie fork'a, ETH protokołu zostałoby zapisane na saldzie buildera operatora, które operator mógłby potem wypłacić. Walidator również nie zostałby utworzony. Niektóre protokoły uwalniają resztę stawki dopiero po udowodnieniu, że nowy walidator posiada ich poświadczenia wypłat — a taki dowód nigdy by nie dotarł.

W komentarzu uzupełniającym autor zgłoszenia wymienił projekty, które luka mogłaby zakłócić: gwarancję przeddepozytową Lido, OETH od Origin oraz Saturn w Rocket Pool, zaznaczając jednocześnie, że lista to szybkie badanie wspomagane AI i może zawierać błędy. W każdym przypadku ekspozycja dotyczyłaby pierwszego depozytu — 1 ETH w przykładach Lido i Rocket Pool — a reszta stawki pozostałaby zablokowana do czasu wykonania kroków odzyskiwania. Autor określił te przypadki jako warunkowe ustalenia w kodzie, a nie aktywne exploity.

Odrzucone 19 października, zatwierdzone tydzień później

Poprawkę zaproponowano 12 października. Po dyskusji na dwóch spotkaniach deweloperów core została zamknięta 19 października z powodu braku wsparcia ze strony klientów, a spotkanie testowe sugerowało prototypowanie jej po uaktualnieniu testnetu Hoodi, aby nie zaburzać harmonogramu.

Trzy dni później Ethereum Foundation odłożyła aktywację Glamsterdam na Hoodi, aby zbadać, jak EIP-8037 współdziała z istniejącymi inteligentnymi kontraktami — problem niezwiązany z depozytami. Dodatkowy czas otworzył na nowo debę. Komentarz z 23 października w agendzie kolejnego spotkania testowego powiązał zmianę dotyczącą depozytów ze zmienionym harmonogramem, tego samego dnia autor dodał testy kolejności depozytów, a zmiana została zatwierdzona 26 października.

Co robi nowa zasada

Po fork'u depozyty builderów i walidatorów podlegają już oddzielnym ścieżkom zgodnie z EIP-8282. Poprawka stosuje tę samą logikę do kolejki w momencie fork'a: o tym, dokąd trafi każdy oczekujący depozyt, decydują poświadczenia wypłat, a nie klucz publiczny.

Ponowne użycie jednego klucza dla walidatora i buildera pozostaje dozwolone; o tym, które konto dany depozyt zasili, decyduje teraz cel zadeklarowany w depozycie.

Co jeszcze musi się wydarzyć przed fork'em

Zatwierdzenie w specyfikacji to dopiero pierwszy krok; zespoły klientów muszą teraz wdrożyć tę samą zasadę. Zmiana w Teku otwarta 27 października była wciąż w trakcie przeglądu, a odpowiednik w Lodestarze pozostawał otwarty.

Późna zmiana musi też trafić identycznie do każdego klienta. Starsze testy referencyjne kodują poprzedni sposób routingu, więc klient stosujący nową zasadę nie zda tych testów. Autor poprawki w Teku informuje o zdaniu testów wygenerowanych ze zaktualizowanej specyfikacji, która nie została jeszcze opublikowana w wydaniu specyfikacji. Gdyby klienci doszli do fork'a stosując różne zasady do tej samej kolejki, obliczyliby różne salda i rozjechaliby się co do stanu łańcucha.

Fundacja nie wyznaczyła nowej daty dla Hoodi ani daty mainnetu dla Glamsterdam. Protokoły stakingowe opierające się na dowodach depozytów mają też własną linię obrony: według autora zgłoszenia kontrole przeddepozytowe odrzucające klucz, który ma już depozyt buildera, mogą zapobiec temu scenariuszowi. Wskaźnikami, na które warto zwracać uwagę, są dwa otwarte pull requesty po stronie klientów, wydanie specyfikacji zawierające zaktualizowane testy oraz nowe daty dla Hoodi i mainnetu.