Vitalik Buterin przyznaje się do swojego największego błędu projektowego od 2017 roku – czy Twoje Ethereum jest zagrożone?

Vitalik Buterin powiedział, że nie zgadza się już ze swoim tweetem z 2017 roku, który bagatelizował potrzebę osobistej weryfikacji Ethereum od końca do końca przez użytkowników.

W tym tygodniu argumentował, że sieć powinna traktować samodzielnie hostowaną weryfikację jako niewymienną opcję awaryjną, w miarę jak jej architektura staje się lżejsza i bardziej modułowa.

Pierwotne stanowisko Buterina wyrosło z debaty projektowej dotyczącej tego, czy blockchain powinien zobowiązywać się do stanu w łańcuchu, czy traktować stan jako „domniemany", możliwy do odtworzenia tylko poprzez powtórne odtwarzanie uporządkowanych transakcji.

Podejście Ethereum, umieszczające korzeń stanu w każdym nagłówku bloku i wspierające dowody w stylu Merkle, pozwala użytkownikowi udowodnić określone saldo, kod kontraktu lub wartość przechowywania bez ponownego wykonywania całej historii, o ile użytkownik akceptuje ważność konsensusu łańcucha przy założeniu uczciwej większości.

W swoim nowym wpisie Buterin przedstawił ten kompromis jako niekompletny w praktyce, ponieważ wciąż może zmusić użytkowników do wyboru między powtórnym odtwarzaniem pełnego łańcucha a zaufaniem pośrednikowi, takiemu jak operator RPC, host danych archiwalnych lub usługa dowodowa.

Zwrot Vitalika w sprawie osobistej weryfikacji historii blockchainu

Zakotwiczył tę zmianę w dwóch przesunięciach: wykonalności i kruchości.

Jeśli chodzi o wykonalność, Buterin napisał, że dowody z wiedzą zerową oferują teraz ścieżkę do sprawdzenia poprawności bez „dosłownego ponownego wykonywania każdej transakcji".

W 2017 roku argumentował, że pchnęłoby to Ethereum w kierunku niższej pojemności, aby utrzymać weryfikację w zasięgu.

Ta zmiana ma znaczenie, ponieważ publiczny plan działania Ethereum coraz częściej traktuje ZK jako prymityw weryfikowalności, a ethereum.org przedstawia dowody z wiedzą zerową jako sposób na zachowanie właściwości bezpieczeństwa przy jednoczesnym zmniejszeniu tego, co weryfikator musi obliczyć.

Prace nad kierunkami „ZK-light-client" również wskazują na model, w którym urządzenie może się synchronizować przy użyciu kompaktowych dowodów, zamiast ufać bramie zawsze online.

Jeśli chodzi o kruchość, Buterin wymienił tryby awarii, które wykraczają poza czyste modele zagrożeń: zdegradowana sieć p2p, zamykanie długotrwałych usług, koncentracja walidatorów, która zmienia praktyczne znaczenie „uczciwej większości", oraz nieformalną presję zarządczą, która zamienia „zadzwoń do deweloperów" w zabezpieczenie.

Przytoczył presję cenzury wokół Tornado Cash jako przykład tego, jak pośrednicy mogą ograniczyć dostęp, argumentując, że ostateczną opcją użytkownika powinno być „bezpośrednie korzystanie z łańcucha".

To ujęcie idzie w parze z szerszą dyskusją na temat utwardzania warstwy bazowej Ethereum i ograniczania zmian, w obliczu dążenia do „osyfikacji" protokołu.

W ujęciu Buterina „górska chata" nie jest domyślnym stylem życia.

Jest wiarygodną alternatywą, która zmienia zachęty, ponieważ świadomość, że użytkownicy mogą wyjść, zmniejsza wpływ każdej pojedynczej warstwy usług.

Ten argument pojawia się, gdy Ethereum zmniejsza to, co zwykłe węzły muszą przechowywać, podczas gdy historia weryfikacji sieci musi nadążać.

Użycie i historia klientów Ethereum

Klienci wykonawczy zbliżają się do częściowego wygasania historii, a Fundacja Ethereum powiedziała, że użytkownicy mogą zmniejszyć użycie dysku o około 300–500 GB, usuwając dane bloków sprzed Merge, umieszczając węzeł w zasięgu na dysku 2 TB.

Jednocześnie lekkie klienty już odzwierciedlają sformalizowany model zaufania zoptymalizowany dla urządzeń o niskich zasobach, opierający się na komitecie synchronizacji składającym się z 512 walidatorów wybieranych co około 1,1 dnia.

Te parametry sprawiają, że weryfikacja lekkiego klienta jest możliwa na dużą skalę.

Jednak koncentrują one również doświadczenie użytkownika wokół dostępności prawidłowych danych i dobrze działających przekaźników, gdy warunki się pogarszają.

Długoterminowa praca Ethereum nad „bezstanowością" ma na celu zmniejszenie potrzeby przechowywania dużego stanu przez węzły przy zachowaniu nienaruszalnej walidacji bloków.

Ethereum.org ostrzega, że „bezstanowość" jest błędną nazwą, rozróżniając słabsze formy od silniejszych projektów, które pozostają badaniami, w tym wygasanie stanu.

Drzewa Verkle mieszczą się w tym planie, ponieważ zmniejszają rozmiary dowodów i są pozycjonowane jako kluczowy krok umożliwiający walidację bez przechowywania dużego stanu lokalnie.

W miarę jak coraz większe obciążenie przechowywania przesuwa się na zewnątrz, albo do wyspecjalizowanych hostów historii, albo innych sieci danych, historia bezpieczeństwa staje się mniej związana z tym, kto może wszystko przechowywać, a bardziej z tym, kto może niezależnie sprawdzić poprawność i pobrać to, czego potrzebuje, gdy domyślna ścieżka zawiedzie.

Co to oznacza w przyszłości

W ciągu najbliższych 12–36 miesięcy praktycznym pytaniem jest, czy weryfikacja rozprzestrzeni się na zewnątrz, gdy Ethereum eksternalizuje więcej obciążeń związanych z przechowywaniem, czy też zaufanie skupi się wokół nowych wąskich gardeł usług.

Jedna ścieżka polega na tym, że portfele i infrastruktura przechodzą z „zaufaj RPC" na „zweryfikuj dowód", podczas gdy produkcja dowodów konsoliduje się w niewielki zestaw zoptymalizowanych stosów, które są trudne do replikacji, przenosząc zależność z jednej klasy dostawcy na inną.

Inna ścieżka polega na tym, że weryfikacja oparta na dowodach staje się zwykła, z nadmiarowymi implementacjami dowodzenia i narzędziami, które pozwalają użytkownikom przełączać dostawców lub weryfikować lokalnie, gdy punkt końcowy cenzuruje, degraduje lub znika, co jest zgodne z wysiłkami mającymi na celu lekkie przepływy weryfikacji.

Trzecia ścieżka polega na tym, że przycinanie i modułowość postępują szybciej niż UX weryfikacji, pozostawiając użytkownikom mniej wykonalnych opcji podczas awarii lub wydarzeń cenzury.

To sprawiłoby, że „górska chata" byłaby operacyjnie realna tylko dla wąskiego wycinka sieci.

Buterin przedstawił chatę jako BATNA Ethereum, rzadko używaną, ale zawsze dostępną, ponieważ istnienie opcji samodzielnej ogranicza warunki narzucane przez pośredników.

Zakończył, argumentując, że utrzymanie tej alternatywy jest częścią utrzymania samego Ethereum.

Post Vitalik Buterin przyznaje się do swojego największego błędu projektowego od 2017 roku – czy Twoje Ethereum jest zagrożone? pojawił się najpierw na CryptoSlate.