W ramach przygotowań do aktualizacji Glamsterdam twórcy Ethereum wykryli i usunęli błąd, który w określonych okolicznościach mógł skierować środki przeznaczone na uruchomienie walidatora do operatora działającego jako builder. Poprawkę wprowadzono do specyfikacji sieci, zanim aktualizacja trafiła do głównej sieci. Nie odnotowano strat, a opisany scenariusz nie został potwierdzony jako działający atak.
Skąd wziął się problem?
Glamsterdam ma rozdzielić dwie funkcje, które obecnie są ze sobą ściślej powiązane. Builderzy przygotowują bloki transakcji, natomiast walidatorzy stakują ETH, by uczestniczyć w zabezpieczaniu sieci i potwierdzaniu bloków. Obie role wiążą się z wpłatami, które powinny być rozliczane osobno.
Ryzyko dotyczyło depozytów oczekujących na zaksięgowanie podczas przechodzenia na nową wersję protokołu. Badacz posługujący się pseudonimem avsetsin opisał sytuację, w której operator rejestruje się jako builder, a następnie usługa stakingowa wpłaca ETH na uruchomienie walidatora, używając tego samego klucza publicznego. W pierwotnym projekcie zasad obie wpłaty mogły zostać przypisane builderowi.
W takim przypadku walidator nie zostałby utworzony, a usługa stakingowa mogłaby nie mieć dowodu wymaganego do odzyskania środków. Badacz zaznaczył jednak, że są to ustalenia oparte na określonych warunkach i sposobie obsługi depozytów przez poszczególne protokoły, a nie potwierdzenie działającego exploita. Wskazał też, że istniejące zabezpieczenia mogłyby zablokować część wariantów takiego scenariusza.
Komentarz autora: Sprawa pokazuje, jak ważne jest dokładne określenie zasad przypisywania depozytów. Wykrycie problemu przed wdrożeniem aktualizacji daje czas na poprawki i dodatkowe testy. Na tym etapie nie ma informacji o utracie środków ani o potwierdzonym ataku.
Poprawka po ponownej analizie
Pierwsza propozycja zmiany nie uzyskała wystarczającego poparcia zespołów rozwijających klientów Ethereum i została zamknięta 19 października. Klienty to różne programy, z których korzystają uczestnicy sieci, dlatego wdrożenie zmian wymaga skoordynowania ich pracy.
Więcej o zmianach w ekosystemie Ethereum przeczytasz w artykule: Ethereum wprowadza aktualizację Fusaka, by obniżyć koszty węzłów i przyspieszyć rozliczenia warstwy 2.
Po dalszej analizie propozycję ponownie otwarto, dodano testy, a następnie poprawkę włączono do specyfikacji konsensusu. Nowe reguły przewidują, że oczekujące depozyty będą rozdzielane według danych wypłaty, czyli ustawień określających, dokąd mogą trafić środki. Dzięki temu depozyt walidatora ma pozostać przypisany do walidatora nawet wtedy, gdy builder korzysta z tego samego klucza.
Glamsterdam nadal czeka na testy
Sama aktualizacja musi jeszcze zostać uwzględniona w oprogramowaniu klientów. Glamsterdam przeszła już testy w sieci Sepolia, ale planowane uruchomienie jej na Hoodi, kolejnym środowisku testowym, zostało przesunięte. Zanim będzie można ustalić termin wdrożenia na głównej sieci Ethereum, potrzebna jest nowa data testów na Hoodi.
Dobrze, że wyłapali to przed mainnetem, bo przy takich zmianach najgorsze są edge case’y na styku specyfikacji i clientów. Sam fakt, że depozyt mógł się „przykleić” do buildera przy współdzielonym kluczu, brzmi jak klasyczny problem z założeniami, które ktoś uznał za oczywiste, a potem wychodzi w praniu.
Za każdym razem jak czytam o kolejnej poprawce przed zrobieniem deploya, mam wrażenie że to sieć w permanentnym beta. Niby dobrze, że łatają, ale jak ktoś trzyma tam większy staking i musi ufać takim niuansom z kluczami publicznymi, to ja bym jednak chciał mniej „może”, a więcej twardych gwarancji.
Tu akurat najciekawsze jest to, że problem nie leżał w samym PoS, tylko w rozdzieleniu ról i w tym jak protokoły obsługują oczekujące depozyty. Jeśli spec konsensusu nie wymusza jednoznacznego mapowania po danych wypłaty, to takie pomyłki są tylko kwestią czasu. Dobrze, że dorzucili testy, bo bez nich poprawka byłaby tylko papierowa.
Mam dość mieszane odczucia. Z jednej strony impact ograniczony i nie potwierdzili exploita, z drugiej cały ten opis pokazuje jak łatwo można spalić środki przez detal w logice rejestracji. W stakingu operacyjnym takie rzeczy są gorsze niż jakiś spektakularny hack, bo użytkownik nawet nie wie gdzie dokładnie poszło źle.
Czy dobrze rozumiem, że problem dotyczył tylko sytuacji, gdy staking i builder używały tego samego klucza publicznego? Jeśli ktoś korzysta z usług zewnętrznej platformy stakingowej, to ona powinna już sama ogarniać wypłatę i dowód odzyskania, czy jednak dalej jest ryzyko po stronie użytkownika?
Typowy przykład tego, że „walidator” i „builder” to dla marketingu brzmi jak dwa modne słowa, a w implementacji trzeba jeszcze obsłużyć stan przejściowy, pending deposits i zgodność clientów. Najbardziej mnie bawi, że pierwsza propozycja poleciała przez brak poparcia, a potem wróciła z testami. Czyli jednak test suite ma większą siłę przebicia niż dyskusja na forum devów.
Po tym jak przesunęli Hoodi i cały termin Glamsterdam dalej się rozjeżdża, mam wrażenie że to będzie kolejna aktualizacja z serii „już za chwilę”. Fajnie, że naprawiają błąd przed wdrożeniem, ale dla zwykłego obserwatora wygląda to trochę jak gaszenie pożaru zanim jeszcze ktoś podpalił zapałkę.