Przyszłość aktualizacji Ethereum, po scaleniu [Część 2]

Największa w historii aktualizacja Ethereum — przejście do mechanizmu konsensusu dowodu udziału — jest tuż za rogiem. Ale chociaż scalanie powinno zwiększać bezpieczeństwo i zrównoważony rozwój, nie obejmuje fragmentacji, długo oczekiwanej metody skalowania sieci. 

In Część I W naszej rozmowie z Dannym Ryanem, naukowcem Fundacji Ethereum (EF), który pomagał koordynować proces aktualizacji, omówiliśmy, co ma przynieść połączenie w zakresie bezpieczeństwa i stabilności.

W części II Ryan mówi o ulepszeniach, których użytkownicy mogą spodziewać się w przyszłości, w tym o dankshardingu, bezstanowym Ethereum i aktualizacjach zabezpieczeń, które zmagają się ze wzrostem wartości wydobywanej przez górników (MEV). Wyjaśnia również, w jaki sposób ten wieloletni wysiłek zaowocował nowymi metodami badania i testowania przyszłych ulepszeń.

---

Koordynacja w zdecentralizowanej sieci

PRZYSZŁOŚĆ: Wspomniałeś o możliwości, że górnicy będą się rozwidlać i dalej próbować używać starego łańcucha. Ale w większości ten proces wciągnął wszystkich na pokład. Jaka jest w tym twoja rola jako badacza Fundacji Ethereum? Jak koordynuje się tak ogromny ruch?

Danny Ryan: Zacząłem angażować się w sprawy związane z dowodami stawki około 2017 roku i nawet wtedy wydawało mi się, że przesądziłem. To było pięć lat temu. Społeczność Ethereum była bardzo chętna, aby nie popaść w stagnację i zrobić to dobrze, i skonstruować protokół, który nie tylko działa dzisiaj, ale działa, miejmy nadzieję, przez 100 lat lub dłużej. 

Tak więc na początku jego etosu, kiedy pojawiło się przeczucie, że dowód stawki można wykonać bezpiecznie i lepiej niż dowód pracy, ludzie byli bardzo podekscytowani. A gdy nadejdzie 2016 i 2017 rok, ludzie nie tylko są tym podekscytowani, ale także niespokojny aby tak się stało. Wygląda na to, że jest to bardzo głęboko zakorzenione w etosie społeczności Ethereum, że to się stanie.

Są bardziej delikatne kwestie. Jest mniej przesądzonych wniosków, w których EF, zespół badawczy i klienci spoza EF starają się znaleźć rozwiązania problemów i utrzymać pracę w ruchu. Czasami rozwiązania znajdują się w nieco bardziej szarej strefie — czy to właściwe rozwiązanie? Czy robimy to teraz? Czy zrobimy to później? To kończy się trudne, a EF stara się pomóc koordynować te metody, pomagać w pracach badawczo-rozwojowych, aby wesprzeć rozwiązania, ułatwić rozmowy, aby decydować o terminach, priorytetach i zamówieniach. 

Ale pod koniec dnia, w przypadku większości pozycji, plan EF ma na celu uczynienie protokołu bardziej zrównoważonym, bezpiecznym i skalowalnym, a jednocześnie zdecentralizowanym — a nie dostarczanie określonej funkcji w stosunku do innych. Tak więc wiele z tego, na czym się skupiamy, zarówno w pracy technicznej, jak i koordynacji społecznej, dotyczy ułatwiania dobrych informacji, dobrych badań i dobrego dialogu, aby wielu uczestników zaangażowanych w badania i rozwój, inżynierię i społeczność mogło kontynuować rzeczy poruszają się i podejmują decyzje.

W ciągu ostatnich pięciu lat do społeczności dodano znacznie więcej głosów, a po Merge teoretycznie stanie się ona bardziej zdecentralizowana. Jakie masz przemyślenia na temat przyszłego procesu aktualizacji? Czy to możliwe, że będziemy przyglądać się jakiejś warstwie DAO w celu koordynowania aktualizacji?

Jak rozumiem, społeczność Ethereum nie zajmuje się głosowaniem w sieci – ani jakimkolwiek plutokratycznym głosowaniem i aktualizacjami – i że protokół jest tym, który użytkownicy decydują się uruchomić. Ogólnie istnieje szeroki konsensus. Czasami zdarzają się schizmy — na przykład klasyka Ethereum kontra Ethereum. Ale w ostatecznym rozrachunku to twoje prawo i prawo społeczności oraz prawa użytkowników, aby dowiedzieć się, jakie oprogramowanie chcą uruchomić. Generalnie zgadzamy się, ponieważ ludzie próbują ulepszyć Ethereum i nie ma zbyt wielu konfliktów w niektórych podstawowych rzeczach. 

Nie oczekuję więc formalnego mechanizmu technicznego. Spodziewam się, że proces będzie nadal rósł, zmieniał się i ewoluował w tego rodzaju luźnym zarządzaniu, gdzie są badacze, są programiści, są członkowie społeczności, są dappy i tym podobne. 

Powiedziałbym, że — i myślę, że do tego nawiązałeś — przy stole jest coraz więcej ludzi i coraz trudniej jest podejmować decyzje i wysyłać rzeczy. Osobiście uważam, że to cecha. Myślę, że zarówno z punktu widzenia niezawodności dla aplikacji i użytkowników, jak i unikania przechwytywania na dłuższą metę, prawdopodobnie ważne jest, aby wiele protokołu Ethereum uległo skostnieniu. Więc chociaż coraz trudniej jest znaleźć się w zamęcie rządów i próbować wysyłać, a czasami wydaje mi się, że próbuję biegać z obciążoną kamizelką i ciężarkami na kostkach, a teraz mam ciężary na nadgarstkach, ja myślę, że mamy kilka kluczowych rzeczy do zrobienia w ciągu najbliższych kilku lat. Ale myślę, że będzie coraz trudniej załatwić sprawy. I myślę, że to dobra rzecz.

Vitalik nazywa to „funkcjonalna prędkość ucieczki”. Przenieśmy Ethereum do miejsca, w którym ma wystarczającą skalę i funkcjonalność, aby można je było rozszerzać i wykorzystywać na nieskończenie wiele sposobów w następnej warstwie stosu. Czy EVM ma minimalną wystarczającą funkcjonalność, czy dostępność danych jest wystarczająca, aby obsłużyć ogromne ilości skali, a następnie aplikacje mogą ją rozszerzyć w inteligentnych kontraktach. Druga warstwa może eksperymentować z nowymi maszynami wirtualnymi w swoich konstrukcjach drugiej warstwy; możesz skalować Ethereum i tak dalej i tak dalej.

Myślę, że będzie coraz trudniej załatwić sprawy. I myślę, że to dobra rzecz.

Widelce do cieni

Jedną z rzeczy, które wyszły z tego specyficznego procesu testowania, były forki cienia, proces kopiowania prawdziwych danych Ethereum do sieci testowej w celu symulacji środowiska testowego sieci głównej. Czy to zawsze było w planie? A jak myślisz, jak to może zmienić proces badawczo-rozwojowy dla przyszłych aktualizacji?

Powinniśmy robić cienie widelca przez ostatnie cztery lata. Oni są wspaniali; Oni są naprawdę fajni. Zasadniczo biorę pewną liczbę węzłów, które kontrolujemy — nazwijmy to 10, 20, 30 — i myślą, że nadchodzi widelec, więc są w sieci głównej lub jednej z tych sieci testowych, a następnie w pewnym stanie rozwidlenia, na przykład na wysokości bloku, wszyscy mówią: „OK, jesteśmy w nowej sieci”. I rozwidlają się, a potem spędzają czas w swojej własnej rzeczywistości, ale mają stan wielkości sieci głównej.

Przez jakiś czas możesz przesyłać transakcje z sieci mainnet do tej rozwidlonej rzeczywistości, aby uzyskać rozsądną ilość tego, co wygląda na organiczną aktywność użytkowników, co jest naprawdę dobre. Pozwala nam to przetestować to, co ostatecznie okazało się wysoce organicznymi procesami, które trudno symulować. I to było świetne. Równy [Jayanthi] i inni, którzy pracują w zespole DevOps w EF, zaaranżowali je i tak wiele się od nich nauczyliśmy. Myślę, że jeśli kogoś zapytasz, odpowie: „Cóż, tak, byłoby wspaniale, gdybyśmy robili to trzy lata temu, cztery lata temu przy każdym uaktualnieniu”.

Ale powiem coś innego. Mówię to [od] rok temu, a teraz jesteśmy w długim ogonie w bezpieczeństwie i testowaniu: to naprawdę uderza w to, upewniając się, że wszystkie skrajne przypadki są poprawne, upewniając się, że kiedy nadejdzie, to się stanie — strzelamy jednym strzałem i działa. Okazuje się, że sposób, w jaki oprogramowanie jest konstruowane z klientami warstwy konsensusu-wykonania, jest po prostu wiele do zbudowania pod względem testowania. Jednym z nich są widelce do cieni. Wykorzystanie innych środowisk symulacyjnych, które mogą testować te dwie rzeczy razem, np. Kurtosis, Antyteza, I inne. 

Jest kilka innych rzeczy, które musimy zrobić, na przykład ponowne okablowanie Ul, która jest naszą integracyjną platformą testów kompilacji, która umożliwia obsługę obu tych typów klientów i umożliwia pisanie testów, w których po obu stronach korytarza mają miejsce różne złożoności. Wszystko to musiało się wydarzyć. Po pierwsze, frameworki musiały zostać opracowane lub zmodyfikowane. Potem trzeba było napisać wiele testów. Tak więc fajną rzeczą w Merge jest to, że naprawdę ulepszyliśmy narzędzia w naszym pasku narzędzi, aby móc testować aktualizacje w taki sposób, że następne uaktualnienie będzie znacznie bardziej polegało na pisaniu testów niż na myśleniu o tym, jak je przetestować i pisanie frameworków do testowania. 

Co jest po dowodzie stawki?

Ponieważ trwało to od dłuższego czasu, początkowo sharding miał być na pierwszym miejscu. Ale rozwój ekosystemu oznaczał, że możesz najpierw przejść do dowodu stawki. Czy w trakcie tego procesu pojawiły się inne zmiany w ekosystemie, które mogą zmienić twoje podejście do przyszłych aktualizacji?

Po pierwsze, prawdopodobnie istnieje wiele powodów, dla których zmiana dowodu stawki była traktowana priorytetowo. Jednym z nich było zaprzestanie przepłacania za bezpieczeństwo dowodem pracy. Po drugie, skala zaczynała przenikać przez te konstrukcje warstwy drugiej. Więc może, jeśli masz z tego skalę 10-100x, możesz skupić się na tej innej rzeczy i dokończyć pracę i zunifikować te dwa różne systemy: łańcuch beaconów i obecną sieć główną. 

Jest kilka innych rzeczy, które wpłynęły na to, jak myślimy o terminach i priorytetach. Wspomniałem wcześniej, że cały świat MEV rzucił klucz w niektóre rzeczy. Kiedy zaczynasz myśleć o tym, dokąd może pójść MEV, pojawiają się problemy związane z centralizacją i innymi kwestiami bezpieczeństwa. W ciągu ostatnich 12 miesięcy przeprowadzono wiele badań nad tym, jak złagodzić niektóre z tych problemów za pomocą modyfikacji warstwy pierwszej. W zależności od analizy zagrożeń pochodzących ze świata MEV, może to nadać priorytet niektórym funkcjom bezpieczeństwa i dodatkom bezpieczeństwa do L1 przed czymś innym, co może być priorytetem. 

Myślę, że coś, co jest interesujące, to mapa drogowa shardingu i obecna oczekiwana konstrukcja, która nazywa się danksharding, nazwana tak Dankrad [Feist], nasz badacz z EF. Cała konstrukcja jest w rzeczywistości uproszczona, jeśli założysz, że istnieją ci wysoce zmotywowani aktorzy MEV. Niektórzy z tych zewnętrznych aktorów nie tylko zmienili sposób myślenia o bezpieczeństwie, ale także zmienili sposób myślenia o konstrukcji tych protokołów. Jeśli założysz, że MEV istnieje, jeśli założysz, że ci wysoce zmotywowani aktorzy są gotowi zrobić pewne rzeczy z powodu MEV, to nagle masz tego zewnętrznego uczestnika w konsensusie, że być może możesz odciążyć rzeczy, które na wiele sposobów może być uproszczenie. Tak więc pojawiają się nie tylko złe rzeczy, ale także nowe rodzaje projektów, które się otwierają.

Naprawdę ulepszyliśmy narzędzia w naszym pasku narzędzi, aby móc testować aktualizacje w taki sposób, że następne uaktualnienie będzie znacznie bardziej polegało na pisaniu testów, a nie zastanawianiu się, jak je przetestować.

Czy bezstanowe Ethereum jest nadal aktywnie dyskutowane i badane? 

TAk. Stan — wszystkie konta, kontrakty, salda i takie tam — to stan Ethereum. Biorąc pod uwagę, gdzie jesteś w łańcuchu bloków, istnieje stan rzeczywistości. Ta rzecz rośnie z czasem, rośnie liniowo. A jeśli zwiększysz limit gazu, rośnie jeszcze szybciej. Więc to jest problem. Jeśli rośnie szybciej niż pamięć i miejsce na dysku twardym komputerów konsumenckich, masz problemy z faktycznym uruchamianiem węzłów na komputerach domowych i sprzęcie konsumenckim, co ma problemy z bezpieczeństwem i centralizacją. Ponadto, jeśli porozmawiasz z niektórymi POBIERZ [klient] członkowie zespołu, fakt, że państwo wciąż się rozwija, oznacza, że ​​muszą ciągle optymalizować rzeczy. Więc to jest trudne.

Bezstanowe Ethereum i rzeczy w tym kierunku badawczym są potencjalną ścieżką rozwiązania tego problemu, gdzie do wykonania bloku tak naprawdę nie potrzebuję całego stanu; jest coś w rodzaju tego ukrytego wejścia przy wykonywaniu funkcji bloku. Potrzebuję stanu wstępnego, potrzebuję blokady, a następnie otrzymuję stan końcowy, aby wiedzieć, czy blok jest ważny. Podczas gdy w przypadku bezstanowego Ethereum wymagania stanu — konta i inne rzeczy potrzebne do wykonania tego konkretnego bloku — są osadzone w bloku i są dowodami, że są to prawidłowe stany. Teraz wykonanie bloku i sprawdzenie poprawności Ethereum staje się po prostu koniecznością posiadania bloku, co jest naprawdę dobre. Teraz możemy mieć pełne węzły, które niekoniecznie mają pełny stan. Otwiera całe spektrum sposobów konstruowania węzłów. Więc mogę mieć węzeł, który w pełni waliduje i nie ma stanu, mogę mieć węzeł, który po prostu utrzymuje stan istotny dla mnie, lub mogę mieć bardzo pełne węzły, które mają cały stan i tego typu rzeczy.

Aktywnie nad tym pracujemy. Uważam, że obecnie istnieje sieć testowa ze wszystkimi innymi zabawnymi rzeczami, które muszą się wydarzyć, aby tak się stało. Moja obecna ocena jest taka, że ​​zapotrzebowanie na sharding i skalę L1 jest wyższe niż nieuchronne zagrożenie wzrostem państwa. Jest więc bardzo prawdopodobne, że jeden z nich będzie traktowany priorytetowo nad drugim, że skala będzie traktowana priorytetowo. 

To powiedziawszy, trudno powiedzieć. Jest "proto-dankharding”, co jest swego rodzaju stopniowym sposobem na uzyskanie nieco większej skali. Może tak się stanie, a potem stanie się bezpaństwowiec, a potem nastąpi pełne sharding, w zależności od potrzeb i oceny tego, co się dzieje i związanych z tym zagrożeń. Myślę, że ogólna myśl o rozwoju państwa jest taka, że ​​musimy mieć ścieżkę i musimy ją naprawić, ale nieuchronne pożary zostały ugaszone i nie jest to rzecz, która sparaliżuje Ethereum przez następne kilka lat. Ale to rzecz, którą trzeba naprawić.

Przeprowadź mnie przez ulepszenia, które do wiedzieć po scaleniu. Czy będzie aktualizacja czyszczenia? Czy to jest odrębne od ulepszeń w Szanghaju? A kiedy wprowadza się sharding?

Szanghaj prawdopodobnie będzie nazwą tego, czym jest rozwidlenie po scaleniu. Aby faktycznie wypłacić swoje fundusze, które obstawiałeś już od prawie dwóch lat — [to] nie zostanie włączone podczas łączenia. Początkowo oczekiwano, że zostaną wykonane, ale biorąc pod uwagę złożoność łączenia, z czasem zdecydowano się go naprawdę rozebrać i po prostu wykonać scalanie, bez dodawania dodatkowej funkcjonalności wypłat. Bardzo, bardzo, bardzo bym się spodziewał, że wypłaty zostaną włączone w Szanghaju — a więc pierwsza aktualizacja po Merge. Zostało to obiecane wielu, wielu ludziom, którzy mają duży kapitał na linii i nie spodziewam się z tym żadnego problemu. Są one ogólnie określone, są napisane testy i tego typu rzeczy. 

Istnieje wiele innych ulepszeń EVM [Ethereum Virtual Machine], które moim zdaniem mogłyby znaleźć się w tym systemie — różne operacje matematyczne, różne rzeczy rozszerzalności, nieco lepsze wersjonowanie w EVM i inne funkcje. To trochę zawór zwalniający ciśnienie w ulepszeniach EVM, które od wielu lat odkładano na bok, aby przeprowadzić scalanie i inne ulepszenia. A ludzie naprawdę chcą zobaczyć tutaj jakąś drobną aktualizację skalowalności. Może to więc być proto-danksharding, który kładzie fundament pod pełne sharding i zyskuje nieco większą skalę, lub potencjalnie obniżki cen gazu calldata, które są bardzo łatwe, ale nie są tak naprawdę trwałym rozwiązaniem. Miejmy nadzieję, że tego właśnie oczekujemy w Szanghaju: wycofań i odrobiny skali.

Wtedy pytanie brzmi: co dalej? A to trudno powiedzieć. Jeśli dostaniemy tam trochę skali i naprawdę dobrze uzupełnia L2 i rzeczy są całkiem dobre, to może w tym momencie pojawi się zapotrzebowanie na bezstanowe. Lub jeśli L2 mają nienasyconą potrzebę większej skali, to może to przygotowuje scenę do pełnego dankshardingu.

Ten wywiad został zredagowany i skondensowany. 

Opublikowano 27 lipca 2022