Slashing
Mechanizm kary w sieciach proof of stake, który konfiskuje część zastakowanego kapitału walidatora za wyraźnie nieuczciwe lub rażąco niedbałe działanie. W Ethereum walidator może stracić od ok. 1 ETH po niemal całe 32 ETH zależnie od skali naruszenia.
Trzy warunki slashingu w Ethereum
- Podwójna propozycja (ang. double proposal): walidator podpisuje dwa różne bloki dla tego samego slotu. To najoczywistszy sposób na próbę stworzenia forka.
- Podwójne głosowanie (ang. double voting / attestation equivocation): walidator składa dwie różne attestacje dla tego samego celu w tej samej epoce.
- Głosowanie otaczające (ang. surround votes): walidator składa attestację, której zakres (source/target) otacza zakres innej swojej attestacji. Pozwoliłoby to popierać sprzeczne sfinalizowane łańcuchy.
Jak działa kara korelacyjna
Gdy walidator popełni slashowalny błąd, natychmiast traci co najmniej 1/32 swojego efektywnego salda (ok. 1 ETH przy pełnych 32 ETH) i jest kolejkowany do przymusowego wyjścia. Następnie czeka 36 dni (8192 epoki) przed możliwością wypłaty środków. W tym czasie stosowana jest kara korelacyjna – i tu kryje się najistotniejszy mechanizm.
Kara korelacyjna skaluje się z tym, ilu walidatorów zostało slashowanych mniej więcej w tym samym oknie czasowym. Jeśli tylko jeden walidator popełni błąd (np. solo staker z duplikatem kluczy przez chwilę), dodatkowa kara jest bliska zeru. Jeśli slashowany jest duży dostawca usług stakingowych, który jednocześnie uruchamia setki duplikatów kluczy, każdy ze slashowanych walidatorów traci wielokrotnie więcej – nawet całe 32 ETH.
Ten mechanizm jest celowy: minimalne straty za izolowane błędy operacyjne, katastrofalne straty za koordynowany atak lub rażące zaniedbania dużego operatora. To sprawia, że przejęcie kontroli nad 33%+ stake'u i próba zaatakowania finalności sieci jest ekonomicznie samobójcza.
Inactivity leak – co kiedy sieć nie finalizuje
Slashing dotyczy aktywnie nieuczciwych działań. Odrębnym mechanizmem jest inactivity leak (wyciek nieaktywności) – odpowiedź sieci na masowe przejście walidatorów offline bez slashingu. Jeśli sieć nie może osiągnąć finalności przez ponad 4 epoki (~25 min), offline walidatorzy zaczynają tracić ETH w przyspieszającym tempie.
Cel jest prosty: jeśli wystarczająca liczba walidatorów wróci online lub saldo offline walidatorów spadnie wystarczająco, by pozostałe aktywne stanowiły wymagane dwie trzecie, sieć odzyskuje zdolność do finalizacji i leak się zatrzymuje. To odporność projektowa – Ethereum może odzyskać konsensus nawet po permanentnej utracie dużej części walidatorów.
Najczęstsze błędy
- Problem: Uruchamianie duplikatów kluczy walidatora jako 'zabezpieczenie redundantności'. Właśnie tak dochodzi do podwójnej propozycji lub podwójnego głosowania. Jeden walidator = jedno aktywne miejsce podpisywania.
- Problem: Zakładanie, że 'wypadek się nie wydarzy'. Większość przypadków slashingu wynika z błędów migracji, konfiguracji failover i nieprzemyślanych aktualizacji – nie z celowego działania.
- Problem: Ignorowanie różnicy między slashingiem a karą za nieaktywność. Offline walidator traci nagrody i ponosi małe kary – nie jest slashowany, o ile nie łamie zasad protokołu.
- Problem: Delegowanie do walidatora bez sprawdzenia historii slashingowej. Każda poważna usługa stakingowa powinna mieć publicznie dostępne logi incydentów.
Redundancja może zwiększyć ryzyko slashingu
Źródła i dalsza lektura
Najczęstsze pytania
- Ostatnia aktualizacja