MetaMask Reward Diversion Shows Who Controls Ethereum Staking Payouts
Najważniejsze informacje
- •Atakujący zmienił ustawienia odbiorcy opłat dla części walidatorów MetaMask Staking, podczas gdy dane uwierzytelniające wypłat i powierzony kapitał pozostały chronione.
- •MetaMask zakończyła zapobiegawcze wyjścia wszystkich dotkniętych walidatorów, ale część klientów doświadczyła opóźnień w wypłatach i nieokreślonych utraconych nagród.
- •MetaMask nie podała, ilu walidatorów dotknął incydent, jak uzyskano dostęp ani czy klienci otrzymają zwrot środków.
- •Ekspozycja dotyczy szeroko stakingu przez podmioty trzecie, ponieważ operatorzy kontrolują konfigurację odbiorcy opłat, niezależnie od adresów wypłat.
- •Istniejąca polityka Lido kieruje nagrody walidatorów z warstwy wykonawczej do Rewards Vault, natomiast proponowane zmiany ePBS gwarantowałyby kwotę płatności, ale same nie zabezpieczyłyby adresu odbiorcy.

MetaMask potwierdziła, że atakujący przez krótki czas przekierował nagrody z warstwy wykonawczej niektórych walidatorów Ethereum korzystających z jej usługi stakingowej, przekierowując około 0,385 ETH, zanim zmiana została wykryta i cofnięta tego samego dnia. Szczegóły pojawiły się w aktualizacji z 5 listopada, najnowszym wpisie dotyczącym incydentu bezpieczeństwa, który firma po raz pierwszy zidentyfikowała 28 września. Choć przekierowana kwota była niewielka, zdarzenie uwypukla często pomijany aspekt projektu Ethereum: rozróżnienie między tym, dokąd ostatecznie trafia staked ETH walidatora, a tym, dokąd wysyłane są jego bieżące nagrody.
Co dotychczas ujawniła MetaMask
Według aktualizacji atakujący uzyskał nieautoryzowany dostęp do części infrastruktury stojącej za MetaMask Staking, gdzie centralnie przechowywane były adresy zbierające nagrody walidatorów z warstwy wykonawczej. Intruz zmienił te adresy dla części walidatorów. MetaMask poinformowała, że wykryła i naprawiła zmianę tego samego dnia, po przekierowaniu około 0,385 ETH nagród. Firma nie ujawniła, ilu walidatorów dotknął incydent ani jak atakujący uzyskał dostęp.
Strona wypłat pozostała nienaruszona. MetaMask Staking nie przechowuje kluczy do wypłat powierzonego ETH klientów, a firma twierdzi, że nie znalazła dowodów na naruszenie powierzonego kapitału, kluczy do wypłat ani portfeli MetaMask. Zwykli użytkownicy portfela MetaMask nie muszą podejmować żadnych działań.
0,385 ETH nie stanowi pełnego kosztu incydentu. MetaMask zapobiegawczo wycofała wszystkie dotknięte walidatory i wszystkie te wyjścia zostały już zakończone. Część klientów doświadczyła tymczasowych opóźnień w wypłatach, a firma przyznaje, że nagrody mogły zostać utracone, gdy walidatory były wycofywane lub oczekiwały na ponowne postawienie. MetaMask nie określiła tych strat i nie powiedziała, czy przekierowane nagrody zostaną zwrócone, informując jedynie, że pracuje bezpośrednio z dotkniętymi klientami i partnerami.
Samo przekierowanie nagród pojawia się dopiero we wpisie z 5 listopada. Komunikaty MetaMask z 30 września i 1 października opisywały incydent oraz zapobiegawcze wyjścia i stwierdzały, że na tym etapie nie było wskazówek, iż portfele lub środki klientów zostały naruszone. Liczba zaangażowanych walidatorów, punkt wejścia atakującego oraz kwestia zwrotu środków to otwarte kwestie, na które warto zwracać uwagę w kolejnych aktualizacjach MetaMask.
Dlaczego stake pozostał bezpieczny, a nagrody nie
Każdy walidator Ethereum odpowiada przed dwoma adresami, które są ustawiane w różnych miejscach. Wytyczne Ethereum dotyczące wypłat traktują dane uwierzytelniające wypłaty oraz odbiorcę opłat jako odrębne ustawienia, mimo że oba mogą wskazywać ten sam portfel.
Dane uwierzytelniające wypłat są rejestrowane w beacon chain. Gdy wskazują adres w warstwie wykonawczej, ten adres nie może zostać zmieniony i to na niego trafia ETH walidatora przy wyjściu. Żaden serwer operatora nie może tego przekierować.
Odbiorca opłat działa inaczej. To ustawienie programowe dostarczane przez podmiot prowadzący walidator. W usłudze niekustodialnej jest to operator, który przechowuje również klucze, przy użyciu których walidator podpisuje wiadomości. Ustawienie wskazuje sieci, dokąd wysyłać dochody z warstwy wykonawczej przy każdym proposerowanym bloku: priorytetowe opłaty transakcyjne oraz płatności od twórców bloków. Podstawowa opłata (base fee) jest natomiast spalana i nigdy nie trafia do walidatora. Operator może w każdej chwili zmienić odbiorcę opłat bez klucza do wypłat stakera. To właśnie to ustawienie MetaMask przechowywała centralnie — i to je zmienił atakujący.
To samo rozróżnienie wyjaśnia, dlaczego strata pozostała niewielka. Nagrody z warstwy konsensusu pozostają w saldzie walidatora albo są automatycznie przekazywane na adres wypłat, więc zmienione ustawienie ich nie dotknęło. Dochody z warstwy wykonawczej napływają tylko wtedy, gdy walidator proponuje blok, co pojedynczy walidator robi rzadko, a MetaMask naprawiła zmianę w ciągu jednego dnia. Tylko propozycje złożone w tym oknie zapłaciły na niewłaściwy adres.
Ta sama ekspozycja dotyczy pooled stakingu
Ta ekspozycja nie jest unikalna dla MetaMask. Gdziekolwiek walidator prowadzi podmiot trzeci, odbiorca opłat znajduje się w konfiguracji tego podmiotu, co czyni tę ekspozycję cechą strukturalną stakingu przez podmioty trzecie, a nie wadą ograniczoną do jednego dostawcy. Lido, którego walidatorami zarządzają niezależni operatorzy węzłów, reguluje to ryzyko zasadami: istniejąca polityka MEV wymaga, aby każdy walidator Lido wskazywał Execution Layer Rewards Vault protokołu jako odbiorcę opłat, a naruszenia mają już własny proces obsługi.
Vault jest kontraktem. Zgodnie z dokumentacją Lido zbiera on dochody z warstwy wykonawczej, w tym MEV i opłaty priorytetowe, a jedynie główny kontrakt Lido może z niego wypłacać środki, przenosząc ETH do rozliczeń protokołu na rzecz posiadaczy stETH. Płatność wysłana gdziekolwiek indziej nigdy nie trafia do tego rozliczenia.
Posiadacze stETH stoją o krok dalej od tych ustawień niż klienci MetaMask Staking. Posiadają przenoszalny token, a nie dane uwierzytelniające wypłat dla konkretnego walidatora, więc ich ochrona opiera się wyłącznie na kontraktach Lido i zasadach operatorów.
ePBS gwarantowałby płatność, nie adres
4 listopada Lido opublikowało propozycję aktualizacji polityki MEV dla wbudowanego rozdzielenia proposer-builder (ePBS), projektu określonego w EIP-7732. Walidatory, które obecnie zlecają tworzenie bloków na zewnątrz, polegają na relayach — pośrednikach, którym ufamy, że zwycięski builder faktycznie zapłaci. Lido opisuje ePBS jako zmniejszanie potrzeby tego zaufania poprzez gwarancję płatności builderów na poziomie protokołu.
Gwarancja ma ograniczenia. W projekcie opisanym przez Lido pojedyncza oferta może łączyć wartość trustless, należną już w momencie włączenia oferty przez proposer, nawet jeśli builder nigdy nie ujawni swojego bloku, z opcjonalną płatnością trusted rozliczaną poza protokołem, która niesie takie samo ryzyko kontrahenta jak obecny rynek. Lido pozwoliłoby każdemu zarejestrowanemu builderowi wygrywać swoje sloty ofertami w pełni trustless, ale tylko builderowie z zatwierdzonej listy Allowed List mogliby dodawać płatności trusted.
Dla stakerów istotniejsze jest to, że gwarancja dotyczy wysokości płatności, a nie miejsca, do którego trafia. Zgodnie z projektem walidatory rozgłaszają podpisane preferencje wskazujące odbiorcę opłat dla nadchodzących slotów, a wartość trustless trafia do odbiorcy opłat wskazanego w ofercie. Ten adres nadal pochodzi od operatora. Zmieniony odbiorca opłat, opisany przez MetaMask, otrzymywałby gwarantowane płatności z taką samą pewnością jak poprawny.
Projekt Lido zachowuje zasadę odbiorcy opłat jako swój rdzeń. Oba rodzaje płatności muszą trafiać do EL Rewards Vault, a polityka obejmowałaby każdy węzeł zdolny do proponowania bloków dla Lido, w tym maszyny zapasowe i failover. Lido informuje, że propozycja zostanie poddana głosowaniu w listopadzie i wejdzie w życie dopiero po dotarciu aktualizacji Glamsterdam do mainnetu Ethereum. Do tego czasu istniejąca polityka MEV — wraz z zasadą vaulta — pozostaje standardem, do którego przywiązywani są walidatorzy Lido.
Co wykryłby system kontroli Lido
Ponieważ ePBS otwiera dodatkowe ścieżki dostarczania bloków, propozycja rozszerza monitoring Lido. Walidator byłby oznaczany flagą za wskazanie jakiegokolwiek adresu poza vaultem lub za przyjęcie płatności trusted od buildera spoza Allowed List. Flagi obejmowałyby również płatności trusted, które nie dotrą w całości w okresie rozliczenia, oraz bloki budowane lokalnie, zaproponowane gdy dostępne były uprawnione zewnętrzne oferty powyżej minimalnego progu.
Kontrola wartości ofert porównuje każdą wybraną ofertę z najwyższą uprawnioną ofertą zaobserwowaną przez monitoring Lido, oznaczając wszystko poniżej początkowych 90–95% jej wartości. Próg stanowi impuls do zadawania pytań, a nie gwarantowany udział w dochodach. Projekt pozwala operatorom pominąć najwyższą ofertę z uzasadnionych względów operacyjnych i niezawodności, a porównanie obejmuje wyłącznie oferty zaobserwowane przez system Lido.
Flaga nie cofa pieniędzy. Naruszenia dotyczące odbiorcy opłat pozostają w ramach obecnego procesu Lido, natomiast inne flagi podlegałyby ścieżce kontaktu i eskalacji w sekcji E Standard Node Operator Protocol. Lido planuje również zaktualizować publiczny Fees Monitoring Dashboard, aby pokazywać, którą ścieżką przeszła każda propozycja bloku Lido.
Jak sprawdzić własną konfigurację stakingu
Płatności z warstwy wykonawczej są rejestrowane on-chain, dzięki czemu zmienione adresy w MetaMask stały się widoczne. Staker znający indeksy swoich walidatorów może otworzyć każdy zaproponowany przez nie blok w eksploratorze beacon chain i sprawdzić, który adres otrzymał płatność proposera. W przypadku Lido dashboard opłat jest publicznym widokiem monitoringu puli.
Wyjścia zasługują na równą uwagę. Jak zauważa aktualizacja MetaMask, wycofanie walidatora i wypłata jego ETH to odrębne procesy: wycofany walidator nadal musi przejść przez proces obsługi wypłat Ethereum, zanim ETH będzie możliwe do wykorzystania, co opisuje dokumentacja stakingu Ethereum. Od aktualizacji Pectra EIP-7002 pozwala posiadaczowi adresu wypłaty walidatora w warstwie wykonawczej bezpośrednio wywołać jego wyjście, z pominięciem operatora.
Cztery pytania, które warto zadać każdemu dostawcy stakingu, obejmują luki ujawnione przez ten incydent:
Kto może zmienić mojego odbiorcę opłat? Szukaj nazwanych ról, zatwierdzenia przed każdą zmianą oraz dziennika każdej edycji, a nie jednego centralnie przechowywanego ustawienia.
Jak szybko wykrylibyście niewłaściwy adres? Szukaj automatycznych kontroli każdego proponowanego bloku, z alertami zamiast okresowego ręcznego przeglądu.
Które płatności builderów są gwarantowane? Przy ePBS oczekuj zestawienia wartości egzekwowanej przez protokół versus płatności trusted oraz wyjaśnienia, jak dochodzi się należności.
Czy mogę wyjść bez was? Potwierdź, że Twoje dane uwierzytelniające wypłat obsługują samodzielnie wywoływane wyjścia, i zapytaj, kto pokryje nagrody utracone podczas wyjścia zapobiegawczego.