Prelegent: Vitalik Buterin, założyciel Ethereum Opracowano przez: 0xxz, Golden Finance EthCC7 odbyło się niedawno w Brukseli. Organizator zaprosił Vitalika, założyciela Ethereum, do wygłoszenia przemówienia programowego. Warto zauważyć, że w 2024 r. przypada 10. rocznica IC0 Ethereum. Po przemówieniu Vitalika trzej 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, opracowanym przez Golden Finance 0xxz. Wzmocnienie tematu mowy 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 walidator dowodu dla wszystkich warstw 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 zasadniczo skupiono się na dApps, które działają 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 drugą od lewej. 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 mogłaby to być warstwa bazowa, ale także spróbuj dać L2 większą funkcjonalność. Jednym z pomysłów w tym kierunku jest dalsze skrócenie czasu wymiany Ethereum, obecnie 12 sekund, prawdopodobnie do 2-4 sekund. Celem tego jest umożliwienie opartego na zbiorczych zestawieniach wykonalności jako podstawowego sposobu działania L2. Jeśli więc chcesz, aby L2 zapewniał użytkownikom najwyższą jakość, musisz mieć własną walidację wstępną, 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. Zaletą Ethereum jest solidność
Dużą zaletą Ethereum jest to, że ma duży i stosunkowo zdecentralizowany ekosystem stakowania.

Lewa strona powyższego obrazu to wykres szybkości mieszania wszystkich pul wydobywczych Bitcoin, a prawa strona to wykres stawek 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. Niebieskie 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ć.

Do zalet Ethereum w zakresie niezawodności zaliczają się również: ● Posiadanie ekosystemu z wieloma klientami: istnieją klienci wykonujący Geth i klienci wykonujący inni niż Geth, a odsetek klientów wykonawczych innych niż Geth przekracza nawet liczbę klientów wykonawczych Geth. Podobna sytuacja ma miejsce również w systemie klienta konsensusowego: ● Społeczność międzynarodowa: ludzie są w wielu różnych krajach, w tym projekty, L2, zespoły itp.; ● Wieloośrodkowy ekosystem wiedzy: Jest Fundacja Ethereum i są zespoły klienckie, nawet zespoły takie jak zespół Reth firmy Paradigm zwiększyły ostatnio swoją pozycję lidera w dziedzinie oprogramowania typu open source; w związku z tym 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? Jak można to ulepszyć?
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 ​​prowadzenie węzła jest zbyt trudne, jest największą przeszkodą i kto uważa, że ​​największą przeszkodą jest brak możliwości zainwestowania swojego ETH w Protokół DeFi w tym samym czasie? 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 dwie największe uzgodnione przeszkody to: 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 32 ETH na depozycie, 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. Gdybyśmy chcieli zejść do 100 000 walidatorów, minimalne wymagania prawdopodobnie wzrosłyby 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ć te dwa aspekty. Jedną z technik jest 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%, pod względem ilości obciętego ETH, wynosi jedną trzecią z 32 milionów ETH, czyli około 11 milionów ETH. Kto wydałby 11 milionów ETH na złamanie blockchainu Ethereum. Nikt, nawet rząd USA, nie chce tego. Te techniki pobierania próbek są podobne do tego, co miałoby miejsce w przypadku domu, w którym drzwi wejściowe były chronione czterema warstwami stali, ale okno było po prostu kawałkiem szkła niskiej jakości, które 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ęść ma ułatwić uruchamianie węzłów. Pierwszym krokiem jest wygaśnięcie historii. Faktycznie, EIP-4444, nastąpił duży postęp w tym zakresie. Drugim krokiem jest klient bezstanowy. Verkle istnieje już od dłuższego czasu, inną możliwą opcją jest utworzenie binarnego drzewa mieszającego, takiego jak Poseidon, funkcji skrótu przyjaznej dla Starka. Kiedy już to zrobisz, aby zweryfikować bloki Ethereum, nie będziesz już potrzebował dysku twardego. Możesz także później dodać ZKVM typu 1, który może Stark weryfikować całe bloki Ethereum, dzięki czemu możesz weryfikować dowolnie duże bloki Ethereum, pobierając dane, a 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ół. zostanie gdzieś Wycięty, a jeśli mamy klienta bezpaństwowego, nie musisz 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 oba problemy, próg 32 ETH i trudność w uruchomieniu węzłów, można rozwiązać technicznie. Myślę, że przyniesie to wiele innych korzyści. Naprawdę poprawi to naszą zdolność do zwiększania indywidualnego stakowania ludzi, zapewni nam lepszy ekosystem indywidualnego stakowania i pozwoli uniknąć ryzyka centralizacji stakowania. Proof of Stake wiąże się z innymi wyzwaniami, takimi jak ryzyko związane z płynnym stakowaniem 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 rzeczywiście napotkamy atak 51%? Ethereum może spotkać się z atakiem 51%, Bitcoin może spotkać się z atakiem 51%, a rząd może również spotkać się z atakiem 51%, na przykład kupując 51% polityków. Jednym z problemów jest to, że nie chcesz polegać wyłącznie na zapobieganiu, 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 swoje bitcoiny, a także zatrzymałem prywatny odrzutowiec i latałem. Bardziej realistyczny atak może obejmować dokonywanie depozytów na giełdach i na przykład naruszanie protokołów DeFi. Ale odwrócenie 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 nie mamy nawet napisanego oprogramowania, aby to sprawdzić, kolejnym wyzwaniem związanym z recenzją jest to, czy ktoś chce na ataki, mogą to zrobić, zaczynają od opóźnienia transakcji i bloków, których nie lubią o 30 sekund, następnie opóźniają je o minutę, a następnie opóźniają je o dwie minuty, a ty nawet nie masz zgody co do tego, kiedy odpowiedzieć . Mówię więc, że cenzura jest w rzeczywistości 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ę 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 przełączy co najmniej większość węzłów w tryb online w oparciu o pewne założenia dotyczące warunków sieciowych. Argument, który próbuję tu przedstawić, 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 nikt, kto był w tym czasie offline, nie byłby 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 17:46, w zasadzie mówiąc: „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 będzie coraz bardziej powszechny i ​​będzie musiał się do tego w dużym stopniu dostosować.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 stanie 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 przechodzących w tryb offline, zatrzymujących się w ostateczności, 21% węzłów przejdzie w tryb offline, zatrzymując się w sposób ostateczny. To jest ryzykowne. 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 zdarzyły się jakieś zdarzenia, w których od 20% do 33% węzłów było 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śli próg Quorum wzrośnie z 67% do 80%, to zakładając, że proporcja, jaką musi osiągnąć klient wzrośnie z 67% do 80%, to 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 list 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. Spośród różnych pomysłów, które omówiłem, około połowa jest prawdopodobnie przeznaczona specjalnie dla rozwiązań L2 dla Ethereum, ale druga połowa ma w zasadzie zastosowanie dla użytkowników Ethereum z L2 jako warstwą podstawową i L1, czyli aplikacjami bezpośrednio do użytkownika. Używaj lekkich klientów w dowolnym miejscu Pod wieloma względami sposób, w jaki współdziałamy z branżą, jest trochę smutny, jesteśmy zdecentralizowani, brak nam zaufania. Kto w tej sali uruchamia na swoim komputerze lekkiego klienta, który potwierdza 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, w rzeczywistości jest to dobre dla Infury, jeśli nie trzeba jej ufać, ponieważ ułatwia jej to budowanie i wdrażanie infrastruktury, ale mamy narzędzia do usunięcia wymogu zaufania. Możemy mieć 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. Dodatkowo potrzebujemy równoważnego schematu 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 gałąź 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 oparty na pakiecie zbiorczym, 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, masz dość prosty łańcuch zaufania, skrót, gałąź Merkle i podpis, które możesz zweryfikować i możesz uzyskać lekką weryfikację klienta. To samo tyczy się każdego L2. Mówiłem o tym ludziom w przeszłości i często odpowiedź brzmiała: „O mój Boże, to interesujące, ale jaki jest tego sens?”.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 znajdują się w pierwszej fazie pakietu zbiorczego, co oznacza, że ​​faktycznie mają działające systemy sprawdzające w łańcuchu oraz 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. , powiedzmy 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ć. Strategia antykwantowa
Czas potrzebny na obliczenia kwantowe skraca się. 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ć podpisu konsensusowego Blake'a, obecnie używamy podpisu zagregowanego BLS, który można zastąpić podpisem zagregowanym Starka. Blob używa KZG, co można udowodnić, używając zakodowanych separacjowo drzew 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ż to zrobisz, użytkownik może skonfigurować własny algorytm podpisu, zasadniczo używając podpisu opartego na haszu. 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, zwłaszcza z procesu 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. Sprawdzanie poprawności skrótów Posejdona w EVM jest obecnie zbyt kosztowne. 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ż weryfikacja dowodów może być tańsza, i lepsze 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 zapłacić 40 dolarów zamiast 80 dolarów? Więcej osób wybierze to pierwsze. Druga grupa użytkowników może dokonywać transakcji w warstwie 2, natomiast w warstwie 1 można znacznie obniżyć koszty. ​