Wszystkie artykuły
ZaawansowanyStaking

Slashing walidatorów: jak stakerzy tracą pieniądze

Slashing to kara niszcząca część stake'u walidatora za dowodliwie szkodliwe zachowanie — głównie podwójne podpisywanie i głosy otaczające. Oto co go wyzwala, co nie, i jak go uniknąć.

31 lipca 2026
6 min czytania

Pogłęb temat z AI

Kliknij → prompt skopiowany → wklej w czacie AI

Slashing to kara niszcząca część zestakowanych środków walidatora za dowodliwie szkodliwe zachowanie — głównie podwójne podpisywanie (equivocation) lub głosy otaczające (surround votes). Istnieje po to, by atak na łańcuch był kosztowny. Zwykłe niedostępności to nie slashing; przejście w offline powoduje jedynie niewielkie kary za nieaktywność.

To jest krótka odpowiedź. Reszta tej strony oddziela dwa zupełnie różne sposoby, w jakie staker traci pieniądze, i pokazuje, gdzie leży prawdziwe ryzyko.


Slashing kontra niedostępność: dwie różne kary

Łańcuchy proof-of-stake karzą walidatorów w dwóch kategoriach, a ich mylenie to najczęstsze nieporozumienie.

Slashing jest zarezerwowany dla przewinień, które protokół potrafi kryptograficznie udowodnić jako atak na konsensus. Zeslashowany walidator ma spalone środki, jest przymusowo usuwany z aktywnego zestawu i nie może wrócić. Na Ethereum przewinieniami podlegającymi slashingowi są:

  • Podwójne proponowanie (double-proposing) — podpisanie dwóch różnych bloków dla tego samego slotu.
  • Podwójne atestowanie (equivocation) — podpisanie dwóch sprzecznych atestacji dla tego samego celu.
  • Głosy otaczające (surround votes) — oddanie atestacji, której zakres głosu otacza lub jest otoczony przez wcześniejszy głos, czyli wzorzec generowany tylko przez nieuczciwego lub źle skonfigurowanego walidatora.

Wszystkie trzy sprowadzają się do tego, że walidator mówi jednocześnie dwie sprzeczne rzeczy o historii łańcucha. Dokładnie tak zachowałby się atakujący próbujący rozwidlić lub odwrócić łańcuch, więc protokół traktuje to jako wrogie niezależnie od intencji.

Niedostępność (downtime) to nie slashing. Jeśli twój walidator jest offline i pomija atestacje, ponosisz niewielki wyciek za nieaktywność (inactivity leak) — nie zarabiasz nagród i tracisz drobną kwotę mniej więcej równą temu, co byś zyskał. W normalnych warunkach to ułamki procenta dziennie. Przeradza się w poważne straty tylko podczas zdarzenia inactivity leak, gdy łańcuch przez długi czas nie finalizuje i walidatory offline są drenowane, by przywrócić superwiększość. To rzadka, ogólnołańcuchowa sytuacja awaryjna, nie rutynowa kara.


Kara korelacyjna

Slashing nie jest stałą grzywną. Kwota skaluje się z tym, ilu walidatorów zostaje zeslashowanych mniej więcej w tym samym czasie, poprzez karę korelacyjną (na Ethereum: proporcjonalny slashing).

Logika: pojedynczy walidator dopuszczający się equivocation to prawdopodobnie pomyłka lub samotny złośliwy aktor i wyrządza niewielką szkodę. Tysiące robiące to razem wygląda jak skoordynowany atak. Im więcej stake'u zostaje zeslashowanego w tym samym oknie, tym większą karę płaci każdy sprawca — potencjalnie całe saldo, jeśli udział skorelowany jest wystarczająco wysoki.

Ten mechanizm wprost zniechęca do koncentracji. Uruchamianie wielu walidatorów na identycznej infrastrukturze oznacza, że jeden błąd może zeslashować je wszystkie jednocześnie, wyzwalając mnożnik korelacyjny. To celowa zachęta do rozproszenia stake'u na niezależne klienty, maszyny i operatorów.


Zdarzenia, przyczyny i dotkliwość

ZdarzeniePrzyczynaDotkliwość kary
Pominięta atestacjaWalidator offline lub wolnyDrobny wyciek za nieaktywność, ułamki procenta
Podwójne proponowanieDwa bloki podpisane dla jednego slotuSlashing: początkowe spalenie + usunięcie
Podwójne atestowanie / głos otaczającySprzeczne atestacje, często zduplikowane kluczeSlashing: początkowe spalenie + usunięcie
Skorelowany masowy slashingWielu walidatorów zeslashowanych razemKara korelacyjna skalująca do pełnego salda
Przedłużający się brak finalizacjiŁańcuch nie finalizuje, walidator offlineWyciek za nieaktywność drenujący stake offline w czasie

Różnica między pierwszym wierszem a resztą to sedno sprawy: niedostępność kosztuje cię nagrody, slashing kosztuje kapitał.


Kto jest zagrożony i jak tego uniknąć

Zdecydowana większość rzeczywistych slashingów ma jedną główną przyczynę: te same klucze walidatora działające na dwóch maszynach naraz. Ktoś stawia węzeł zapasowy lub failover z tymi samymi kluczami, oba wchodzą online, a dwie instancje podpisują sprzeczne komunikaty — natychmiastowy slashing za equivocation. Nie ma tu ataku, jedynie błąd konfiguracji, którego protokół nie odróżnia od ataku.

Jeśli sam prowadzisz walidatory, praktyczne zabezpieczenia to:

  • Nigdy nie uruchamiaj identycznych kluczy na dwóch węzłach jednocześnie. Nie buduj "gorącej rezerwy" współdzielącej klucze. Przy migracji na nowy sprzęt całkowicie wyłącz i potwierdź, że stara instancja jest martwa, zanim uruchomisz nową.
  • Używaj bazy ochrony przed slashingiem (slashing-protection database). Klienty prowadzą lokalny rejestr każdego podpisanego komunikatu i odmawiają podpisania czegokolwiek, co byłoby slashowalne. Zawsze importuj i przenoś tę bazę przy zmianie konfiguracji; nigdy nie startuj od zera z istniejącymi kluczami.
  • Dywersyfikuj klienty i infrastrukturę, by pojedynczy błąd klienta nie zeslashował całej twojej floty i nie wyzwolił kary korelacyjnej.
  • Zrozum kompromis delegowania. Przy puli stakingowej lub dostawcy liquid staking to operator prowadzi walidatory. Ryzyko slashingu leży po jego stronie, nie bezpośrednio po twojej — ale dziedziczysz jego kompetencje i jego koncentrację.

Uczciwe ograniczenia

Nie istnieje wersja stakingu bez ryzyka; jest tylko wybór, które ryzyko posiadasz.

Solo staking daje pełne nagrody i pełną kontrolę oraz pełną odpowiedzialność. Zdarzenie niedostępności kosztuje cię nagrody; błąd z kluczami na dwóch maszynach kosztuje kapitał poprzez slashing. Tryby awarii są operacyjne i w dużej mierze w twoich rękach.

Delegowany lub liquid staking przenosi ten ciężar operacyjny na dostawcę. To już nie ty możesz podwójnie podpisać. Zamiast tego bierzesz na siebie ryzyko dostawcy i kontrahenta: operator wciąż może zostać zeslashowany (i przekazać ci straty), platforma może upaść, ustalenia dotyczące custody mogą się załamać, a token liquid staking może odczepić się (depeg) od bazowego stake'u. Zamieniłeś ryzyko, które kontrolujesz, na takie, którego nie kontrolujesz.

Żadne nie jest jednoznacznie bezpieczniejsze. Slashing to małe, możliwe do uniknięcia ryzyko ogonowe dla ostrożnego operatora solo i delegowane ryzyko, któremu osobiście nie zapobiegniesz, korzystając z puli.


FAQ

Za co walidator zostaje zeslashowany? Za dowodliwe naruszenia konsensusu: proponowanie dwóch bloków dla tego samego slotu lub sprzeczne atestacje (podwójne głosy i głosy otaczające). W praktyce niemal zawsze wynikają one z uruchomienia zduplikowanych kluczy na dwóch maszynach, a nie z celowych ataków.

Czy zostanę zeslashowany za przejście w offline? Nie. Niedostępność nie jest przewinieniem podlegającym slashingowi. Tracisz nagrody i płacisz niewielki wyciek za nieaktywność mniej więcej równy temu, co byś zarobił. Straty stają się poważne tylko podczas przedłużającego się braku finalizacji, co jest rzadkie.

Ile może kosztować slashing? Zaczyna się od początkowego spalenia i przymusowego usunięcia, a następnie dodaje karę korelacyjną zależną od tego, ile stake'u zeslashowano razem z twoim. W izolacji strata jest umiarkowana; w skorelowanym masowym slashingu może skalować się do całego zestakowanego salda.

Czy staking przez pulę chroni mnie przed slashingiem? Przenosi ryzyko operacyjne na operatora, a nie je eliminuje. Osobiście nie podwójnie podpiszesz, ale operator wciąż może zostać zeslashowany i przekazać ci stratę, a w zamian bierzesz na siebie ryzyko dostawcy i kontrahenta.


Zanim w ogóle zaczniesz stakować, upewnij się, że rozumiesz mechanizm, który zabezpieczasz — przeczytaj czym jest staking i jak proof-of-stake wypada wobec proof-of-work. Jeśli wolisz nie prowadzić walidatora, rozważ kompromisy w liquid staking.

Przeczytaj też

Podobał Ci się artykuł? Obserwuj mnie!

@t0tty3
#slashing#validators#staking#ethereum#proof-of-stake

Pogłęb temat z AI

Kliknij → prompt skopiowany → wklej w czacie AI