Opracowano przez: 0xxz, Golden Finance
EthCC7 odbyło się niedawno w Brukseli, a organizatorzy zaprosili Vitalika, założyciela Ethereum, aby wygłosił przemówienie programowe.
Warto zauważyć, że w 2024 r. przypada 10. rocznica Ethereum ICO Po przemówieniu Vitalika trzej byli główni założyciele Ethereum, Vitalik Buterin, Joseph Lubin i Gavin Wood, ponownie zrobili wspólne zdjęcie, aby upamiętnić tę okazję.
Ten artykuł jest przemówieniem programowym wygłoszonym niedawno przez Vitalika, założyciela Ethereum, na EthCC7.
temat przemówienia
Wzmocnienie L1: Optymalizacja Ethereum, aby stać się wysoce niezawodną, godną zaufania i niewymagającą zezwoleń warstwą bazową warstwy 2
Spektrum wizji Ethereum
Myślę, że istnieje spektrum możliwych różnych podziałów pracy w odniesieniu do roli, jaką warstwa podstawowa Ethereum może odegrać w ekosystemie w ciągu najbliższych pięciu do dziesięciu lat. Można o tym myśleć jak o widmie od lewej do prawej.
Po lewej stronie spektrum zasadniczo stara się być bardzo minimalistyczną warstwą bazową, która po prostu działa jako weryfikator dowodu dla wszystkich L2. Być może zapewni także możliwość przesyłania ETH pomiędzy różnymi L2. Ale poza tym, to w zasadzie wszystko.
Po prawej stronie spektrum ponownie skupiono się na dApps działających głównie na L1, przy czym L2 jest używany tylko do niektórych bardzo specyficznych i wydajnych transakcji.
W środku spektrum znajduje się kilka interesujących opcji. Umieściłem Ethereum jako warstwę bazową L2 po drugiej lewej stronie. Skrajną wersję umieściłem po lewej stronie. Skrajna wersja polega na tym, że całkowicie porzucamy część kliencką Ethereum, zachowując tylko część konsensusową i dodając kilka walidatorów z wiedzą zerową, w zasadzie zamieniając całą warstwę wykonawczą w pakiet zbiorczy.
Mam na myśli bardzo ekstremalne opcje po lewej stronie, a po prawej może to być warstwa podstawowa, ale także próba zapewnienia L2 większej funkcjonalności. Jednym z pomysłów w tym kierunku jest dalsze skrócenie czasu wymiany Ethereum, który obecnie wynosi 12 sekund, prawdopodobnie do 2-4 sekund. Celem tego jest sprawienie, aby podstawowe podsumowania stały się wykonalne jako podstawowy sposób działania L2. Zatem teraz, jeśli chcesz, aby L2 zapewniał użytkownikom najwyższą jakość, musisz mieć własne wstępne potwierdzenie, co oznacza albo scentralizowany sorter, albo własny zdecentralizowany sorter. Jeśli ich konsensus przyspieszy, L2 nie będzie już musiał tego robić. Jeśli naprawdę chcesz zwiększyć skalowalność L1, wówczas zapotrzebowanie na L2 również zostanie zmniejszone.
Jest to więc widmo. W tej chwili skupiam się głównie na wersji drugiej od lewej, ale to, co tutaj sugeruję, odnosi się także do innych wizji, a zawarte tu rady w niczym nie przeszkadzają innym wizjom. To jest coś, co moim zdaniem jest bardzo ważne.
Zaleta wytrzymałości Ethereum
Dużą zaletą Ethereum jest to, że ma duży i stosunkowo zdecentralizowany ekosystem stakowania.
Lewa strona powyższego zdjęcia to wykres mocy obliczeniowej wszystkich pul wydobywczych Bitcoin, a prawa strona to wykres Stakerów Ethereum.
Rozkład mocy obliczeniowej Bitcoina nie jest obecnie zbyt dobry. Dwie pule wydobywcze stanowią ponad 50% mocy obliczeniowej, a cztery pule wydobywcze stanowią ponad 75%.
A sytuacja Ethereum jest faktycznie lepsza niż pokazuje wykres, bo druga duża część szarej części jest właściwie niezidentyfikowana, co oznacza, że może to być kombinacja wielu osób, a nawet może być w niej wielu niezależnych udziałowców. Niebieska część, Lido, jest w rzeczywistości dziwną, luźno skoordynowaną strukturą złożoną z 37 różnych walidatorów. Zatem Ethereum ma stosunkowo zdecentralizowany ekosystem stakowania, który działa całkiem nieźle.
Możemy dokonać wielu ulepszeń w tym obszarze, ale myślę, że nadal warto to dostrzec. To jedna z wyjątkowych zalet, na której naprawdę możemy bazować.
Zalety solidności Ethereum obejmują również:
Ma ekosystem obejmujący wielu klientów: istnieją klienci wykonujący Geth i klienci wykonujący inni niż Geth. Odsetek klientów wykonawczych innych niż Geth przekracza nawet liczbę klientów wykonawczych Geth. Podobna sytuacja ma miejsce w systemach klientów konsensusowych;
Społeczność międzynarodowa: ludzie w wielu różnych krajach, w tym projekty, L2, zespoły itp.;
Wieloośrodkowy ekosystem wiedzy: jest Fundacja Ethereum, jest zespół klienta, a nawet zespół Reth firmy Paradigm zwiększa ostatnio swoją pozycję lidera w obszarze open source;
Kultury, które cenią te atrybuty
Zatem ekosystem Ethereum jako warstwa podstawowa ma już te bardzo potężne zalety. Myślę, że to coś bardzo cennego i nie należy tak łatwo rezygnować. Posunąłbym się nawet do stwierdzenia, że istnieją wyraźne kroki, które można podjąć, aby zwiększyć wykorzystanie tych mocnych stron, a nawet wyeliminować nasze słabości.
Gdzie Ethereum L1 nie spełnia wysokich standardów i jak można to poprawić?
Oto ankieta, którą przeprowadziłem na Farcaster około pół roku temu: Jeśli nie grasz solo, co cię powstrzymuje przed obstawianiem solo?
Mogę powtórzyć pytanie w tym miejscu: kto zajmuje się stakowaniem solo? Kto z Was bez stakowania Solo uważa, że próg 32 ETH jest największą przeszkodą, kto uważa, że uruchomienie węzła jest zbyt trudne, jest największą przeszkodą, a kto uważa, że największą przeszkodą jest to, że nie można zainwestować swojego ETH w DeFi protokół jednocześnie? Kto uważa, że największą przeszkodą jest strach przed koniecznością umieszczania kluczy prywatnych w działającym węźle, gdzie można je łatwiej ukraść?
Można zauważyć, że dwiema głównymi przeszkodami, co do których panuje jednomyślność, są: minimalny wymóg 32 ETH oraz trudność obsługi węzła. Zawsze ważne jest, aby zdać sobie z tego sprawę.
Wiele razy, gdy zaczynamy zastanawiać się, jak zmaksymalizować zdolność ludzi do podwójnego wykorzystania swoich zabezpieczeń w protokołach DeFi, okazuje się, że duża liczba osób w ogóle nie korzysta z protokołów DeFi. Skupmy się więc na głównych problemach i tym, co możemy zrobić, aby je rozwiązać.
Zacznij od uruchomienia węzła walidatora, czyli innymi słowy od progu 32 ETH. W rzeczywistości te dwa pytania są ze sobą powiązane, ponieważ oba są funkcjami liczby walidatorów w Proof of Stake Ethereum.
Dziś mamy około 1 miliona podmiotów walidatorów, każdy z depozytem w wysokości 32 ETH, więc gdyby minimalne wymagania zostały zmienione na 4 ETH, mielibyśmy 8 milionów, a może ponad 8 milionów, może 9 milionów lub 10 milionów walidatorów. Jeśli chcemy zredukować tę liczbę do 100 000 walidatorów, wówczas minimalne wymagania mogą wzrosnąć do około 300 ETH.
Jest to więc kompromis. Ethereum historycznie próbowało znaleźć się w środku kompromisu. Jeśli jednak uda nam się znaleźć sposób na ulepszenie tego, będziemy mieli dodatkowe punkty statystyk, które będziemy mogli opcjonalnie wykorzystać do zmniejszenia minimalnych wymagań lub ułatwienia obsługi węzła.
Tak naprawdę teraz myślę, że agregowanie podpisów nie jest nawet główną trudnością w prowadzeniu węzła. Na początku możemy bardziej skupić się na zmniejszeniu wymagań minimalnych, ale ostatecznie będzie to obejmować jedno i drugie.
Istnieją więc dwie techniki, które mogą poprawić oba te aspekty.
Jedną z technik byłoby umożliwienie stakowania lub zezwolenie na ostateczność bez wymagania podpisu od każdego walidatora. Zasadniczo potrzebny jest rodzaj losowego próbkowania wystarczającej liczby węzłów, aby osiągnąć znaczne bezpieczeństwo ekonomiczne.
Myślę, że obecnie mamy więcej niż wystarczające bezpieczeństwo gospodarcze. Koszt przeprowadzenia ataku 51%, obliczony na podstawie ilości obciętego ETH, wynosi jedną trzecią z 32 milionów ETH, co stanowi około 11 milionów ETH. Kto wydałby 11 milionów ETH na zniszczenie blockchainu Ethereum. Nikt, nawet rząd USA, nie chce tego.
Te techniki pobierania próbek są podobne do sytuacji, gdy masz dom, a drzwi wejściowe były chronione czterema warstwami stali, ale okno to tylko kawałek szkła niskiej jakości, który ktoś mógłby łatwo rozbić kijem baseballowym. Myślę, że w pewnym stopniu Ethereum tak właśnie wygląda, jeśli chcesz wykonać atak 51%, musisz stracić 11 milionów ETH. Jednak w rzeczywistości istnieje wiele innych sposobów ataku na protokół i naprawdę powinniśmy bardziej wzmacniać te mechanizmy obronne. Zamiast tego, jeśli masz podzbiór walidatorów wykonujących ostateczność, protokół jest nadal wystarczająco bezpieczny i naprawdę możesz zwiększyć poziom decentralizacji.
Drugą techniką jest lepsza agregacja podpisów. Mógłbyś zrobić coś zaawansowanego jak Starks i zamiast obsługiwać 30 000 podpisów na slot, być może w końcu będziemy mogli obsługiwać więcej podpisów. To jest pierwsza część.
Druga część ułatwia uruchamianie węzłów.
Pierwszym krokiem jest wygaśnięcie historii. Faktycznie, EIP-4444, nastąpił duży postęp w tej dziedzinie.
Drugim krokiem jest klient bezstanowy. Verkle istnieje już od dłuższego czasu, inną możliwą opcją jest utworzenie binarnego drzewa skrótów podobnego do Posejdona, funkcji skrótu przyjaznej dla Starka. Kiedy już to zrobisz, aby zweryfikować bloki Ethereum, nie będziesz już potrzebował dysku twardego. Następnie możesz dodać ZKVM typu 1, który może Stark zweryfikować cały blok Ethereum, dzięki czemu możesz zweryfikować dowolnie duże bloki Ethereum, pobierając dane lub nawet dane próbkujące dostępność danych, a wtedy wystarczy zweryfikować tylko jeden dowód.
Jeśli to zrobisz, uruchomienie węzła stanie się łatwiejsze. Jedną z bardzo irytujących rzeczy obecnie związanych z klientami bezpaństwowymi jest to, że jeśli chcesz zmienić ustawienia sprzętu lub oprogramowania, zazwyczaj musisz albo zacząć od zera i stracić dzień, albo musisz zrobić coś bardzo niebezpiecznego i umieścić klucze na pół. byłoby slah, jeśli mamy klientów bezpaństwowców, nie trzeba już tego robić.
Możesz po prostu uruchomić nowego, samodzielnego klienta, zamknąć starego, przenieść klucze i uruchomić nowy. Tracisz tylko jedną epokę.
Kiedy już masz ZKVM, wymagania sprzętowe w zasadzie spadają prawie do zera.
Dlatego zarówno próg 32 ETH, jak i trudność działania węzła można rozwiązać technicznie. Myślę, że przyniesie to wiele innych korzyści. Naprawdę poprawi to naszą zdolność do zwiększania indywidualnych stawek, zapewni nam lepszy ekosystem indywidualnych staków i pozwoli uniknąć ryzyka centralizacji stakowania.
Proof of Stake wiąże się z innymi wyzwaniami, takimi jak ryzyko związane ze stakowaniem płynności i ryzyko związane z MEV. To także ważne pytania, nad którymi warto się zastanowić. Nasi badacze zastanawiają się nad tym.
Odzyskaj siły po 51% ataku
Naprawdę zacząłem myśleć poważnie i rygorystycznie. Zaskakujące jest, jak wiele osób w ogóle nie myśli o tym temacie i traktuje go jak czarną skrzynkę.
Co się stanie, jeśli naprawdę napotkamy atak 51%?
Ethereum może ucierpieć z powodu ataku 51%, Bitcoin może zostać dotknięty atakiem 51%, a rząd może również doświadczyć ataku 51%, na przykład kupując 51% polityków.
Jednym z problemów jest to, że nie chcesz polegać wyłącznie na profilaktyce, chcesz także mieć plan powrotu do zdrowia.
Powszechnym błędnym przekonaniem jest to, że ludzie myślą, że 51% ataków ma na celu odwrócenie ostateczności. Ludzie zwracają na to uwagę, bo właśnie to podkreślił w białej księdze Satoshi Nakamoto. Możesz wydać podwójnie, po tym jak kupiłem prywatny odrzutowiec, przeprowadziłem atak 51%, odzyskałem bitcoiny i mogłem zatrzymać prywatny odrzutowiec i latać.
Bardziej realistyczny atak może obejmować dokonywanie depozytów na giełdach i na przykład naruszanie protokołów DeFi.
Ale odwrócenie sytuacji nie jest w rzeczywistości najgorszą rzeczą. Największym ryzykiem, którym powinniśmy się martwić, jest cenzura. 51% węzłów przestało akceptować bloki od pozostałych 49% węzłów lub dowolnego węzła próbującego zawierać jakiś rodzaj transakcji.
Dlaczego jest to największe ryzyko? Ponieważ odwrócenie ostateczności ma Slash, istnieje natychmiastowy, możliwy do sprawdzenia dowód w łańcuchu, że co najmniej jedna trzecia węzłów zrobiła coś bardzo, bardzo złego i została ukarana.
A ataku cenzury nie można przypisać proceduralnie, nie ma bezpośrednich dowodów proceduralnych, które pozwalałyby stwierdzić, kto zrobił coś złego. Teraz, jeśli jesteś węzłem internetowym i chcesz sprawdzić, czy dana transakcja nie została uwzględniona w 100 blokach, ale nawet nie napisaliśmy oprogramowania, aby to sprawdzić,
Kolejnym wyzwaniem związanym z cenzurą jest to, że jeśli ktoś chce zaatakować, może to zrobić, opóźniając transakcje i bloki, których nie lubi, o 30 sekund, następnie opóźniając je o minutę, a następnie opóźniając je o dwie minuty, a ty nawet tego nie robisz osiągnijcie konsensus co do tego, kiedy odpowiedzieć.
Mówię więc, że cenzura jest większym ryzykiem.
W kulturze blockchain istnieje argument, że jeśli nastąpi atak, społeczność zjednoczy się i oczywiście wykona kilka miękkich forków i odetnie atakujących.
Może to być prawdą dzisiaj, ale opiera się to na wielu założeniach dotyczących koordynacji, ideologii i wszelkiego rodzaju innych rzeczy i nie jest jasne, jak prawdziwe będzie coś takiego za 10 lat. Mówią więc, że wiele innych społeczności blockchain zaczyna robić takie rzeczy, jak cenzura, mamy błędy, których natury nie można przypisać. Dlatego musimy polegać na konsensusie społecznym. Opierajmy się zatem wyłącznie na konsensusie społecznym i z dumą przyznajmy, że wykorzystamy go do rozwiązania naszych problemów.
W rzeczywistości zalecam pójście w odwrotnym kierunku. Wiemy, że pełna koordynacja automatycznych odpowiedzi i automatyczne forkowanie większości sprawdzanych atakujących jest matematycznie niemożliwe. Ale możemy być tak blisko tego, jak to tylko możliwe.
Można utworzyć rozwidlenie, które faktycznie połączy co najmniej większość węzłów online w oparciu o pewne założenia dotyczące warunków sieciowych. Argument, który próbuję tutaj przekazać, jest taki, że tak naprawdę chcemy, aby reakcja na atak 51% była jak najbardziej zautomatyzowana.
Jeśli jesteś walidatorem, na twoim węźle powinno działać oprogramowanie, które jeśli wykryje cenzurę transakcji lub cenzurę niektórych walidatorów, automatycznie zdecenzuruje większość łańcucha, a wszystkie uczciwe węzły automatycznie to zrobią ze względu na ich. Działający kod jest koordynowany na tych samych kilku miękkich widelców.
Oczywiście, znowu mamy do czynienia z matematycznie niemożliwym wynikiem, przynajmniej osoba, która w tym czasie była offline, nie byłaby w stanie stwierdzić, kto miał rację, a kto nie.
Istnieje wiele ograniczeń, ale im bliżej tego celu, tym mniej pracy wymaga konsensus społeczny.
Jeśli wyobrazisz sobie, co faktycznie dzieje się z atakiem 51%. To nie będzie tak, jak poniżej, że nagle w pewnym momencie Lido, Coinbase i Kraken opublikują post na blogu o 5:46, mówiąc w zasadzie: „Hej, chłopaki, teraz robimy recenzję”.
W rzeczywistości może się zdarzyć, że w tym samym czasie będziesz świadkiem wojny w mediach społecznościowych i wszelkiego rodzaju innych ataków. Nawiasem mówiąc, jeśli faktycznie dojdzie do ataku 51%, nie powinniśmy zakładać, że Lido, Coinbase i Kraken będą u władzy za 10 lat. Ekosystem Ethereum stanie się coraz bardziej powszechny i będzie musiał być do tego w dużym stopniu przystosowany. Chcemy, aby obciążenie warstwy społecznej było jak najmniejsze, co oznacza, że warstwa techniczna musi przynajmniej wyłonić wyraźnego zwycięskiego kandydata, a jeśli chce ona opuścić łańcuch będący przedmiotem przeglądu, powinna się zjednoczyć wokół kilku miękkich widelców Superior.
Zalecam przeprowadzenie dalszych badań i przedstawienie bardzo konkretnych zaleceń.
Propozycja: Podnieść próg kworum do 75% lub 80%
Myślę, że próg kworum (uwaga: mechanizm kworum to algorytm głosowania powszechnie stosowany w systemach rozproszonych w celu zapewnienia redundancji danych i ostatecznej spójności) można podnieść z dwóch trzecich obecnie do około 75–80%.
Podstawowym argumentem jest to, że w przypadku ataku złośliwego łańcucha, takiego jak łańcuch cenzury, odzyskanie staje się bardzo, bardzo trudne. Jednakże z drugiej strony, jeśli zwiększysz odsetek kworum, jakie będzie ryzyko? Jeśli kworum wynosi 80%, zamiast 34% węzłów przechodzi w tryb offline, zatrzymując się w sposób ostateczny, 21% węzłów przechodzi w tryb offline, zatrzymując się w sposób ostateczny.
Istnieje ryzyko. Zobaczmy jak to wygląda w praktyce? Z tego, co rozumiem, myślę, że tylko raz ostateczność została wstrzymana na około godzinę, ponieważ ponad jedna trzecia węzłów była w trybie offline. Czy zdarzają się przypadki, w których od 20% do 33% węzłów jest w trybie offline? Myślę, że co najwyżej raz i co najmniej zero razy. Ponieważ w praktyce bardzo niewielu walidatorów przechodzi w tryb offline, myślę, że ryzyko takiego działania jest dość niskie. Korzyści są zasadniczo takie, że znacznie zwiększa się poprzeczka, do której musi dotrzeć atakujący, oraz znacznie zwiększa się zakres scenariuszy, w których łańcuch przechodzi w tryb awaryjny w przypadku luki po stronie klienta, dzięki czemu ludzie mogą faktycznie współpracować, aby dowiedzieć się, co poszło źle.
Jeżeli próg Kworum wzrośnie z 67% do 80%, to przy założeniu, że proporcja, jaką musi osiągnąć klient wzrośnie z 67% do 80%, wówczas wartość małej liczby klientów lub wartość, jaką mała liczba klientów klienci mogą zapewnić, naprawdę zaczyna rosnąć.
Inne obawy związane z cenzurą
Inne obawy związane z cenzurą dotyczą list włączenia lub jakiejś alternatywy dla list włączenia. Zatem cała sprawa z wieloma równoległymi proponującymi, jeśli zadziała, może nawet zastąpić listy włączające. Potrzebujesz albo abstrakcji konta, albo abstrakcji konta w ramach jakiegoś protokołu.
Potrzebujesz tego, ponieważ obecnie inteligentne portfele kontraktowe tak naprawdę nie korzystają z listy uwzględnienia. Inteligentne portfele kontraktowe tak naprawdę nie korzystają z żadnej gwarancji odporności na cenzurę w warstwie protokołu.
Odnieśliby korzyść, gdyby w protokole istniała abstrakcja konta. Jest więc wiele rzeczy, właściwie wiele z nich jest cennych w wizji centrum L2 i wizji centrum L1.
Myślę, że z różnych pomysłów, o których mówiłem, prawdopodobnie około połowa była przeznaczona specjalnie dla Ethereum skupiona na L2, ale druga połowa była w zasadzie przeznaczona dla L2 jako warstwy bazowej dla użytkowników Ethereum i L1 lub, podobnie jak, bezpośrednio dla aplikacji użytkownika, jak użytkownik.
Używaj lekkich klientów wszędzie
Pod wieloma względami to trochę smutne, jak wchodzimy w interakcję z przestrzenią, jesteśmy zdecentralizowani, brak nam zaufania. Kto w tym pokoju uruchamia na swoim komputerze lekkiego klienta, który sprawdza konsensus? rzadki. Kto korzysta z Ethereum, ufając portfelowi przeglądarki Infura? Chciałbym, żeby za pięć lat liczba podniesionych rąk uległa odwróceniu. Chciałbym zobaczyć portfele, które za nic nie ufają Infurze. Musimy zintegrować lekkich klientów.
Infura może w dalszym ciągu dostarczać dane. To znaczy, jeśli nie musisz ufać firmie Infura, jest to właściwie dobre dla firmy Infura, ponieważ ułatwia jej budowanie i wdrażanie infrastruktury, ale mamy narzędzia umożliwiające zniesienie wymogu zaufania.
Jedyne, co możemy zrobić, to stworzyć system, w którym użytkownik końcowy uruchamia coś w rodzaju lekkiego klienta Helios. Powinien faktycznie działać bezpośrednio w przeglądarce, bezpośrednio potwierdzając konsensus Ethereum. Jeśli chce zweryfikować coś na łańcuchu, na przykład wejść w interakcję z łańcuchem, po prostu zweryfikuj bezpośrednio dowód Merkle.
Jeśli to zrobisz, faktycznie zyskasz pewien stopień braku zaufania w swoich interakcjach z Ethereum. To jest dla L1. Ponadto potrzebujemy również równoważnego rozwiązania dla L2.
W łańcuchu L1 znajdują się nagłówki bloków, stany, komitety synchronizacyjne i konsensus. Jeśli zweryfikujesz konsensus, jeśli wiesz, jaki jest nagłówek bloku, możesz przejść przez oddział Merkle i zobaczyć, jaki jest stan. Jak więc zapewnić lekkie gwarancje bezpieczeństwa klienta dla L2. Znajduje się tam katalog główny stanu L2. Jeśli jest to podstawowy pakiet zbiorczy, istnieje inteligentny kontrakt, a ten inteligentny kontrakt przechowuje nagłówek bloku L2. Lub, jeśli masz wstępne potwierdzenie, masz inteligentną umowę, która przechowuje, kto jest wstępnym potwierdzeniem, więc ustalasz, kto jest wstępnym potwierdzeniem, a następnie słuchasz podzbioru dwóch trzecich ich podpisów.
Tak więc, gdy już masz nagłówek bloku Ethereum, istnieje dość prosty łańcuch zaufania, skrót, gałąź Merkle i podpis, który możesz zweryfikować, a także możesz uzyskać lekką weryfikację klienta. To samo tyczy się każdego L2.
Mówiłem o tym ludziom w przeszłości i wiele razy odpowiedź brzmiała: O mój Boże, to interesujące, ale po co? Wiele L2 ma wiele podpisów. Dlaczego nie ufamy wielokrotnym podpisom w celu weryfikacji wielokrotnych podpisów?
Na szczęście od zeszłego roku nie jest to już prawdą. Optimism i Arbitrum są na pierwszym etapie pakietu zbiorczego, co oznacza, że faktycznie mają działające systemy sprawdzające w łańcuchu i komitet ds. bezpieczeństwa, który może je zabezpieczyć w przypadku luki w zabezpieczeniach, ale komitet ds. bezpieczeństwa musi przekroczyć bardzo wysoki próg głosowania. , np. 75% z 8 osób, wielkość Arbitrum wzrośnie do 15 osób. Tak więc w przypadku Optimism i Arbitrum nie są to tylko multisigy, mają one rzeczywiste systemy dowodowe, a te systemy dowodowe faktycznie odgrywają rolę, przynajmniej jeśli chodzi o posiadanie większości władzy w decydowaniu, który łańcuch jest poprawny, a który zły .
EVM idzie jeszcze dalej. Uważam, że nie ma nawet komisji ds. bezpieczeństwa, więc jest całkowicie pozbawiona zaufania. Naprawdę zaczynamy posuwać się do przodu w tej kwestii i wiem, że wiele innych L2 również postępuje naprzód. Zatem L2 to coś więcej niż tylko multisig, więc koncepcja lekkich klientów dla L2 faktycznie zaczyna mieć sens.
Dziś możemy już zweryfikować oddział Merkle, wystarczy wpisać kod. Jutro możemy również zweryfikować ZKVM, dzięki czemu będziesz mógł w pełni zweryfikować Ethereum i L2 w swoim portfelu przeglądarki.
Kto chce być niezaufanym użytkownikiem Ethereum w portfelu przeglądarki? cudowny. Kto wolałby być pozbawionym zaufania użytkownikiem Ethereum na swoim telefonie komórkowym? A co z Raspberry Pi? A co powiesz na inteligentny zegarek? Ze stacji kosmicznej? To też naprawimy. Zatem potrzebujemy odpowiednika konfiguracji RPC, który zawiera nie tylko informacje o serwerach, z którymi się rozmawiasz, ale także instrukcje uwierzytelniania klienta lekkiego. To jest coś, nad czym możemy popracować.
Strategie odporne na kwanty
Czas obliczeń kwantowych się kurczy. Metaculous uważa, że komputery kwantowe pojawią się na początku lat trzydziestych XXI wieku, a niektórzy uważają, że wcześniej.
Dlatego potrzebujemy strategii odpornej na działanie kwantowe. Mamy strategię opartą na kwantach. Istnieją cztery części Ethereum, które są podatne na obliczenia kwantowe i każda z nich ma naturalne alternatywy.
Odporną kwantowo alternatywą dla Verkle Tree jest Starked Poseidon Hash lub jeśli chcemy być bardziej konserwatywni, możemy użyć podpisów konsensusowych Blake'a, obecnie używamy podpisów zagregowanych BLS, które można zastąpić zagregowanymi podpisami Starka. Blob używa KZG i można to udowodnić przy użyciu osobnego kodowania drzewa Merkle Stark. Konta użytkowników korzystają obecnie z ECDSA SECP256K1, który można zastąpić podpisami opartymi na skrótach oraz abstrakcją i agregacją kont, inteligentnymi portfelami kontraktowymi ERC 4337 itp.
Gdy już je masz, użytkownik może skonfigurować własny algorytm podpisu, zasadniczo używając podpisu opartego na skrótach. Myślę, że naprawdę musimy zacząć myśleć o budowaniu podpisów opartych na skrótach, aby portfele użytkowników mogły łatwo przejść na podpisy oparte na skrótach.
Uproszczenie protokołu
Jeśli chcesz solidnej warstwy bazowej, protokół musi być prosty. Nie powinien mieć 73 losowych zaczepów i pewnej kompatybilności wstecznej, która istnieje z powodu przypadkowego głupiego pomysłu, na który wpadł jakiś przypadkowy facet o imieniu Vitalik w 2014 roku.
Dlatego warto spróbować naprawdę uprościć i zacząć naprawdę eliminować dług techniczny. Dzienniki są obecnie oparte na filtrach Bloom, które nie działają dobrze i nie są wystarczająco szybkie, dlatego potrzebne są ulepszenia dzienników, aby dodać silniejszą niezmienność, co już robimy po stronie bezstanowej, zasadniczo ograniczając stan każdego widoku bloku.
Ethereum jest obecnie niesamowitą kolekcją, jest RLP, jest SSZ, jest API i w idealnym przypadku powinniśmy po prostu używać SSZ, ale przynajmniej pozbyć się RLP, stanu i binarnego drzewa Merkle, kiedy już będziemy mieć binarne drzewo Merkle, to wtedy całe Ethereum znajduje się na binarnym drzewie Merkle.
Fast Finality, Single Slot Finality (SSF), czyści nieużywane prekompilatory, takie jak prekompilator ModX, który często powoduje błędy konsensusu. Byłoby miło, gdybyśmy mogli go usunąć i zastąpić wydajnym kodem solidności.
Podsumować
Jako solidna warstwa bazowa, Ethereum ma bardzo unikalne zalety, w tym takie, których nie ma Bitcoin, takie jak decentralizacja konsensusu i znaczące badania dotyczące odzyskiwania 51% ataków.
Uważam, że należy naprawdę wzmocnić te mocne strony. Należy także rozpoznać i skorygować nasze niedociągnięcia, aby mieć pewność, że spełniamy bardzo wysokie standardy. Pomysły te są w pełni zgodne z agresywnym planem działania L1.
Jedną z rzeczy, z których jestem najbardziej zadowolony w Ethereum, a w szczególności w procesie rozwoju rdzenia, jest to, że nasza zdolność do równoległej pracy znacznie się poprawiła. To mocny punkt, właściwie możemy pracować nad wieloma rzeczami równolegle. Zatem zajmowanie się tymi tematami w rzeczywistości nie wpływa na możliwość ulepszenia ekosystemu L1 i L2. Na przykład ulepszenie EVM L1, aby ułatwić wykonywanie kryptografii. Obecnie weryfikacja skrótów Posejdona w EVM jest zbyt kosztowna. Kryptografia 384-bitowa jest również zbyt droga.
Jest więc kilka pomysłów oprócz EOF, takich jak kody operacji SIMD, EVM max itp. Istnieje możliwość podłączenia tego wysokowydajnego koprocesora do EVM. Jest to lepsze dla warstwy 2, ponieważ można taniej weryfikować dowody, i lepiej dla aplikacji warstwy 1, ponieważ protokoły prywatności, takie jak zk SNARK, są tańsze.
Kto skorzystał z umowy o ochronie prywatności? Kto chce płacić 40 opłat zamiast 80 w przypadku umowy o ochronie prywatności? więcej ludzi. Druga grupa może być używana w warstwie 2, a warstwa 1 może osiągnąć znaczne oszczędności.
„Wielka Trójka” Ethereum ponownie się łączy
W 2024 r. przypada 10. rocznica Ethereum IC0. EthCC 2024 zaprosiło wszystkich trzech byłych głównych założycieli Ethereum, Vitalika Buterina, Josepha Lubina i Gavina Wooda, do wzięcia udziału w spotkaniu.
Po przemówieniu Vitalika zostali zaproszeni do wspólnego zdjęcia grupowego:
Wielka Trójka ponownie podaje sobie ręce
