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ąć.
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ść
| Zdarzenie | Przyczyna | Dotkliwość kary |
|---|---|---|
| Pominięta atestacja | Walidator offline lub wolny | Drobny wyciek za nieaktywność, ułamki procenta |
| Podwójne proponowanie | Dwa bloki podpisane dla jednego slotu | Slashing: początkowe spalenie + usunięcie |
| Podwójne atestowanie / głos otaczający | Sprzeczne atestacje, często zduplikowane klucze | Slashing: początkowe spalenie + usunięcie |
| Skorelowany masowy slashing | Wielu walidatorów zeslashowanych razem | Kara korelacyjna skalująca do pełnego salda |
| Przedłużający się brak finalizacji | Łańcuch nie finalizuje, walidator offline | Wyciek 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ż
Proof of Stake kontra Proof of Work — uczciwe porównanie
Oba mechanizmy decydują, kto dodaje kolejny blok, i oba bronią przed atakiem Sybil. Proof of work zużywa prąd; proof of stake blokuje kapitał, który można spalić. Oto uczciwy kompromis i krytyka każdego z nich.
Restaking wyjaśniony: dodatkowy zysk czy ryzyko systemowe
Restaking pozwala już zastakowanemu ETH zabezpieczać dodatkowe usługi w zamian za dodatkowe nagrody. Spopularyzował go EigenLayer. Oto jak działa, ile naprawdę kosztuje ten zysk i dlaczego krytycy nazywają go ryzykiem systemowym.
Liquid Staking: Darmowa Kasa Dopóki Nie Jest
Stakuj ETH i nadal używaj go w DeFi. Co może pójść źle? Właściwie sporo.