Deweloperzy Ethereum scalili poprawkę dotyczącą luki w obsłudze depozytów w nadchodzącej aktualizacji Glamsterdam, która mogła pozwolić budowniczemu bloków na otrzymanie ETH przeznaczonego dla nowego walidatora, po początkowej decyzji o odrzuceniu proponowanej zmiany.
Podsumowanie
- Ethereum scalilo poprawkę obsługi depozytów Glamsterdam 26 października.
- Luka mogła przypisać depozyty stakingowe budowniczym dzielącym ten sam klucz publiczny.
- Deweloperzy początkowo odrzucili korektę przed zatwierdzeniem dodatkowych testów.
- Osobne dochodzenie w sprawie zgodności kontraktów opóźniło aktywację Glamsterdam na Hoodi.
Zgodnie ze specyfikacjami konsensusu Ethereum, opiekun Justin Traglia scalił korektę 26 października po tym, jak deweloper avsetsin zidentyfikował problem ze sposobem przetwarzania oczekujących depozytów podczas forka Gloas. Zmiana oddziela depozyty budowniczych od depozytów walidatorów na podstawie ich poświadczeń wypłaty, zapobiegając przedostaniu się środków na niewłaściwe konto, gdy oba używają tego samego klucza publicznego.
Podatność dotyczyła opracowywanych zasad, a nie potwierdzonej kradzieży z głównej sieci Ethereum. Deweloperzy włączyli korektę do specyfikacji, choć poszczególne klienty konsensusu wciąż muszą wdrożyć i przetestować zmienione zachowanie.
Luka w Ethereum Glamsterdam ujawniła ryzyko depozytów walidatorów
Problem wynikał ze zmian planowanych w ramach zapisanego w Glamsterdam rozdzielenia proposera i budowniczego, które przypisuje budowę bloków i proponowanie bloków różnym rolom. Budowniczowie składają ładunki transakcji, podczas gdy walidatorzy uczestniczą w proponowaniu i potwierdzaniu bloków poprzez system proof-of-stake Ethereum.
Badacz avsetsin opisał lukę 12 października, identyfikując problem w zasadach używanych do przetwarzania depozytów oczekujących podczas aktualizacji sieci. Jeśli budowniczy zarejestrował się przy użyciu klucza publicznego, zanim dotarł depozyt walidatora pod tym samym kluczem, proponowana logika mogła przypisać oba depozyty budowniczemu.
Badacz przedstawił scenariusz, w którym operator stakingu otrzymuje środki z protokołu płynnego stakingu w celu utworzenia nowego walidatora. Rejestrując się najpierw jako budowniczy, operator mógł spowodować, że depozyt walidatora protokołu trafił do salda budowniczego, gdzie adres wypłaty mógł znajdować się pod kontrolą operatora.
„Operator może wypłacić środki protokołu” – ostrzegł avsetsin w raporcie na GitHubie.
Ponieważ oczekiwany walidator nie zostałby utworzony, usługa stakingowa mogłaby mieć trudności z uzyskaniem dowodu potrzebnego do zakończenia normalnych procedur depozytu i odzyskiwania.
Badacz zbadał potencjalne narażenie dotyczące Lido, Origin i Rocket Pool poprzez wstępne badania kodu. Te ustalenia były warunkowe i zależały od sposobu, w jaki poszczególne protokoły obsługiwały depozyty, a raport nie ustalił, że projekty padły ofiarą wykorzystania luki.
Deweloperzy odwracają decyzję po dalszym przeglądzie
Proponowana korekta początkowo napotkała opór ze strony deweloperów klientów Ethereum, mimo opisu ryzyka routingu depozytów przez badacza. 19 października Traglia zamknął pull request po dyskusjach wśród głównych deweloperów.
„W tym momencie nie było wystarczającego wsparcia ze strony klientów, aby wprowadzić tę zmianę” – napisał Traglia.
Decyzja nie pozostała w mocy, a deweloperzy ponownie otworzyli propozycję 23 października po dalszym zbadaniu.
Następnie recenzent potuz zatwierdził podejście, ale zażądał więcej testów dla określonych kombinacji depozytów. Avsetsin dodał te testy 23 października, obejmując przypadki, w których depozyty budowniczego i walidatora dzielą klucz publiczny, ale wymagają oddzielnej obsługi.
Ostateczna zmiana została scalona ze specyfikacjami konsensusu Ethereum 26 października po dalszym przeglądzie przez klientów. Kieruje ona prawidłowe depozyty walidatorów do kolejki walidatorów, jednocześnie pozwalając legalnym depozytom budowniczych na rejestrację lub dodanie środków do istniejącego budowniczego.
Nowe zasady rozróżniają depozyty poprzez poświadczenia wypłaty, które określają dozwolone ustalenia dotyczące wypłat. Zachowują oddzielne rekordy budowniczego i walidatora, nawet gdy ten sam klucz publiczny pojawia się w obu rolach.
Opóźnienie Hoodi daje deweloperom więcej czasu na zbadanie problemu
Aktualizacja specyfikacji pojawiła się, gdy deweloperzy Ethereum analizowali osobny problem wpływający na zaplanowaną aktywację Glamsterdam w sieci testowej Hoodi. Fundacja Ethereum przełożyła aktualizację z 26 października po tym, jak badacze zidentyfikowali ryzyko związane z kompatybilnością dotyczące EIP-8037.
Jak crypto.news wcześniej informował o przełożeniu, decyzja usunęła zarówno zmiany w wykonaniu Amsterdam, jak i zmiany w konsensusie Gloas z planowanej aktywacji w Hoodi. Proponowane zwiększenie limitu gazu do 200 milionów zostało przełożone wraz z nimi.
Badacz Ethereum Toni Wahrstätter wyjaśnił, że EIP-8037 może zakłócać działanie inteligentnych kontraktów opierających się na założeniach dotyczących pozostałego gazu podczas wykonania. Zidentyfikował przypadki, w których rozliczanie gazu mogło spowodować nieoczekiwane wycofanie transakcji lub umożliwić ścieżkę wykonania, którą deweloperzy uważali za nieosiągalną.
Problem kompatybilności kontraktów różni się od wady depozytu budowniczego omówionej w poprawce na GitHubie. Oba dotyczą Glamsterdam, ale przełożenie z 22 października przez Fundację konkretnie wskazywało na dalsze badanie interakcji EIP-8037 z istniejącymi kontraktami.
Klienci Ethereum muszą wdrożyć zmienione zasady
Glamsterdam został już aktywowany w sieci testowej Sepolia 6 października, gdzie deweloperzy zbadali zmiany w konstrukcji bloków i wyższą przepustowość przetwarzania transakcji. Kolejna próba w Hoodi pozostaje niezaplanowana, bez potwierdzonej daty aktywacji w głównej sieci Ethereum.
Scalona poprawka depozytu zawiera testy regresji obejmujące sposób klasyfikacji depozytów podczas przejścia Gloas. Zespoły klientów muszą włączyć zmianę specyfikacji do swojego oprogramowania i przeprowadzić dalsze testy, zanim zaktualizowane zasady będą mogły działać podczas przyszłej aktualizacji sieci.
