Jak walrus karze leniwe węzły za pomocą wykrywania na łańcuchu

Subtelny tryb awarii dręczy zdecentralizowane przechowywanie: leniwy walidator. Ten węzeł przechowuje dane poprawnie, ale czasami ignoruje żądania pobrania lub odpowiada powoli. To nie jest nieuczciwe—po prostu nie osiąga wyników. Leniwi walidatorzy obniżają niezawodność systemu bez jawnego oszustwa.

Tradycyjne systemy mają trudności z wykrywaniem lenistwa, ponieważ odróżnienie go od warunków sieciowych jest trudne. Czy walidator zignorował żądanie, czy sieć zgubiła pakiet? Bez synchronizacji założeń czasowych nie można tego stwierdzić. Rezultatem jest tolerancja systemu na niedostateczne osiągi—każdy traci na niezawodności.

@Walrus 🦭/acc rozwiązuje to poprzez wykrywanie na łańcuchu. Kiedy walidator zostaje wybrany do obsługi bloba, to zobowiązanie jest rejestrowane na łańcuchu za pomocą Sui. Jeśli walidator nie zrealizuje żądania pobrania w określonym czasie—nie z powodu opóźnienia w sieci, ale z powodu udowodnionej niedostępności—awaria jest wykrywana i udowadniana na łańcuchu. Automatycznie następują kary ekonomiczne.

To tworzy potężne zachęty.

Leniwy walidator staje w obliczu rzeczywistych konsekwencji ekonomicznych. Nie może ukrywać się za warunkami sieciowymi ani twierdzić, że nie da się uniknąć. Zapis na łańcuchu pokazuje, czy wypełnił swoje obowiązki. Uczciwi walidatorzy działający w obniżonych warunkach sieciowych są chronieni—mogą udowodnić, że mieli dane, a opóźnienie w sieci nie jest przeciwko nim.

Różnica ma znaczenie: Walrus nie karze warunków sieciowych, karze odmowę obsługi. Walidatorzy muszą być niezawodnie dostępni, a nie tylko poprawnie przechowywać dane. To podnosi niezawodność systemu z teoretycznej gwarancji do egzekwowanej rzeczywistości operacyjnej.

#Walrus $WAL

WAL
WAL
--
--