Tytuł oryginalny: „Ethereum Core Developer Meeting Update 014”
Oryginalne źródło: Aktualizacja AllCoreDevs
Autor oryginalny: Tim Beiko
Oryginalna kompilacja: Ethereum.cn
Witamy w nowej edycji aktualizacji AllCoreDevs (Ethereum Core Developer Conference) – ostatniej w 2022 roku.
Przegląd
Treść aktualizacji Shanghai/Capella została sfinalizowana: wypłaty, EOF i kilka drobnych modyfikacji... pod warunkiem, że nie opóźnią wypłat.
Nadchodzi przestrzeń Blob: EIP-4844 będzie w centrum kolejnej aktualizacji Ethereum, a ceremonia jego przywołania wkrótce się rozpocznie.
Od strony technicznej trwają wysiłki mające na celu koordynację procesów aktualizacji warstwy wykonawczej i warstwy konsensusu. Jesteśmy także świadkami aktywnych dyskusji na temat lepszego włączania wkładu społeczności w ten proces.
Gildia Protokołu opublikowała średnioterminowy raport pilotażowy i przybliżony plan zwiększenia liczebności opiekunów pierwszego poziomu i lepszego ich wspierania w 2023 roku.
Aktualizacja w Szanghaju/Capelli
Podczas niedawnej konferencji AllCoreDevs zespół klienta osiągnął konsensus w sprawie ostatecznego zakresu aktualizacji w Szanghaju/Capella. Choć nazwa ulepszenia może być przedmiotem dyskusji, zespół jasno określa jego zakres. Główną cechą aktualizacji jest wprowadzenie wypłat Beacon Chain dla stakerów. Zespół klienta nie chce pójść na kompromis, jeśli chodzi o możliwie najszybsze wdrożenie tej funkcji, dlatego inne funkcje w ramach aktualizacji muszą być gotowe w tym samym czasie, w przeciwnym razie istnieje ryzyko, że zostaną porzucone.
Specyfikacja warstwy wykonawczej w Szanghaju zawiera listę wszystkich zawartych EIP:
EIP-3540: Format obiektowy EVM (EOF) v1
EIP-3651: Zmniejsz koszty paliwa za dostęp do adresów COINBASE
EIP-3670: EOF – weryfikacja kodu
EIP-3855: Dodano kod operacji PUSH 0
EIP-3860: Ogranicz rozmiar kodu initcode i wprowadź pomiar gazu
EIP-4200: EOF - statyczny skok względny
EIP-4750: EOF - Funkcje importowania
EIP-4895: Wycofanie sygnału poprzez łańcuch sygnalizatorów jako operacja systemowa
EIP-5450: EOF – weryfikacja stosu
Chociaż lista jest długa, można ją podzielić na trzy różne części: drobne ulepszenia, formaty obiektów EVM i wypłaty. Następnie przedstawimy je jeden po drugim:
Niewielkie zmiany
EIP-3651: Ciepła COINBASE (obniż koszty paliwa związane z dostępem do adresów COINBASE)
Ten EIP naprawia niedopatrzenie w EIP-2929, w którym koszt paliwa za dostęp do niektórych pól danych był modyfikowany w zależności od tego, czy dane znajdowały się już w pamięci klienta (WARM), czy też wymagały odzyskania z dysku (COLD).
EIP-2929 ustawia dwie części danych w pamięci klienta na WARM na początku każdej transakcji: adres wysyłający i adres odbierający. EIP-3651 dodaje do tej listy trzeci adres, adres COINBASE (czyli odbiorcy opłaty), ponieważ jest to również adres, który klient ma w pamięci podczas przetwarzania transakcji blokowych.
EIP-3855: Instrukcja PUSH 0 (nowy kod operacji `PUSH 0)
Jak sama nazwa wskazuje, EIP-3855 wprowadza kod operacji, który umieszcza na stosie wartość 0. Wciskanie zer jest często używane do wypełniania wartości w EVM, ten kod operacji zapewni bardziej wydajny i tańszy sposób na zrobienie tego.
EIP-3860: Limit i kod init licznika (ogranicz rozmiar kodu initcode i wprowadź pomiar gazu)
To EIP dodaje ograniczenie rozmiaru kodu initcode i wprowadza pomiar gazu na podstawie jego długości. Jego górny limit rozmiaru dodaje niezmiennik do EVM, ułatwiając zrozumienie i proponowanie modyfikacji.
Wprowadza narzut wynoszący 2 gazy na 32 bajty dla kodu initcode, który jest używany do płacenia za najszybszą analizę, którą klient musi wykonać przed wykonaniem, a która nie jest wymieniona w liczniku gazu.
formacie obiektowym
Większość elementów EIP objętych aktualizacją w Szanghaju jest w rzeczywistości częścią jednej funkcji: formatu obiektowego EVM (EOF). Prace podzielono na 5 różnych EIP, aby pomóc programistom klienta zrozumieć każdą indywidualną modyfikację, ale aby zapewnić przegląd na wyższym poziomie, programiści opublikowali ujednoliconą specyfikację. EIP tych pięciu EOF to:
EIP-3540: Format obiektu EVM w wersji 1
EIP-3670: EOF – weryfikacja kodu
EIP-4200: EOF - statyczny skok względny
EIP-4750: EOF - Funkcje importowania
EIP-5450: EOF – weryfikacja stosu
Warto zaznaczyć, że pierwszym krokiem EOF była londyńska aktualizacja EIP-3541, która zarezerwowała prefiks 0xEF 00 dla kontraktu EOF. W ciągu ostatnich kilku miesięcy zmienił się także zakres EOF modernizacji w Szanghaju.
W lutym zespół klienta zgodził się rozważyć modernizację w Szanghaju w celu uwzględnienia dwóch najmniejszych EIP EOF: EIP 3540 i 3670. Wszystkie będą służyć jako elementy składowe, ale nie zapewnią pełnej funkcjonalności bez wprowadzenia EIP 4200, 4750 i 5450. Chociaż możliwe jest rozszerzenie EOF, niezgodność wsteczna może wymagać nowej wersji. Ponieważ kontrakty poprzedzające EOF lub EOF z określoną wersją muszą zawsze być wykonywalne, każda nowa wersja EOF oznacza, że programiści-klienci muszą utrzymywać nowy zestaw reguł wykonywania EVM równolegle ze starymi regułami.
Przed EOF klienci obsługiwali tylko jeden zestaw reguł EVM na raz. Baza kodu obsługuje również poprzednie reguły EVM, które są modyfikowane przy każdej aktualizacji sieci, ale gdy dotrą do głowy łańcucha bloków, należy zastosować tylko najnowsze reguły. Po wdrożeniu EOF klient będzie utrzymywał dwa równoległe zestawy reguł EVM, dzięki czemu będzie mógł wykonywać kod w kontraktach EOF i innych niż EOF. Innymi słowy, zwiększanie liczby wersji EOF zwiększa liczbę równoległych, a nie kolejnych zestawów reguł EVM, które należy zachować.
W tym celu w ciągu ostatnich kilku miesięcy zespoły klientów zaczęły faworyzować podejście „dużego EOF”. W ten sposób, mimo że muszą wdrożyć większe zestawy modyfikacji, wersja EOF wytrzyma dłużej i zmniejszy liczbę „równoległych EVM”, które należy konserwować. Dlatego programiści rozważyli „duży EOF” i ostatecznie uwzględnili go w aktualizacji w Szanghaju.
To powiedziawszy, większe funkcje są oczywiście trudniejsze do wdrożenia i przetestowania, a zespół nie chce, aby EOF poważnie opóźniał wycofywanie łańcuchów sygnałów nawigacyjnych. Dlatego też, jeśli wdrożenie EOF nie zostanie zakończone do stycznia i nie będą mogły szybko ze sobą współpracować, zespół klienta wyraża zgodę na przeniesienie EOF z Szanghaju w celu modernizacji.
Mając na uwadze te konteksty, przedstawmy teraz pokrótce każde EIP EOF:
EIP-3540: Format obiektowy EVM (EOF) v1 (format obiektowy EVM wersja 1)
To EIP wprowadza „kontener” do umowy EOF. Dodaje znaczniki umożliwiające rozróżnienie części kodu i danych kontraktu oraz zapobiega wdrażaniu kontraktów EOF, które nie są zgodne z formatem. Gwarantuje to, że każda umowa EOF w łańcuchu będzie miała prawidłowy format, co upraszcza interakcję z tymi umowami, a także ich analizę statyczną.
EIP-3670: EOF – weryfikacja kodu (EOF – weryfikacja kodu)
Opierając się na kontenerze wprowadzonym przez 3540, EIP-3670 zapewnia ważność kodu w umowie EOF lub uniemożliwia jego wdrożenie.
Oznacza to, że w kontraktach EOF nie można wdrażać niezdefiniowanych opkodów, co ma dodatkową zaletę polegającą na zmniejszeniu liczby wersji EOF, które należy dodać. Jeśli zostanie dodany nowy kod operacji, można po prostu zmienić zasady sprawdzania poprawności, aby go włączyć i upewnić się, że żaden wdrożony kontrakt EOF nie odwołuje się do niego w swojej sekcji kodu.
EIP-4200: EOF – Statyczne skoki względne (EOF – Statyczne skoki względne)
EIP-4200 wprowadza pierwsze kody operacji specyficzne dla EOF: RJUMP, RJUMPI i RJUMPV, które kodują miejsca docelowe jako wartości bezpośrednie ze znakiem. Kompilatory mogą używać tych nowych rozkazów JUMP do optymalizacji narzutu gazu, ponieważ eliminują potrzebę analizy skoków w czasie wykonywania, która jest wymagana przez istniejące rozkazy JUMP i JUMPI.
EIP-4750: EOF — Funkcje (funkcje wprowadzone przez EOF)
EIP-4750 idzie o krok dalej niż 4200: uniemożliwia użycie kodów operacji JUMP i JUMPI i dodaje alternatywy dla funkcji, których nie można skopiować. Jest to realizowane poprzez wprowadzenie określonych sekcji funkcji w kodzie bajtowym EOF. Funkcje te mogą skakać odpowiednio z nowych kodów operacji JUMPF, CALLF i RETF i używać ich do wywoływania i zwracania.
EIP-5450: EOF — weryfikacja stosu (weryfikacja stosu EOF)
Wreszcie, EIP-5450 dodaje kolejną kontrolę walidacji dla kontraktów EOF, tym razem wokół stosu. To EIP uniemożliwia kontraktom EOF wdrażanie kodu, który może powodować niedopełnienie, a w niektórych przypadkach przepełnienie stosu. Dzięki temu EIP klienci mogą zmniejszyć liczbę kontroli walidacyjnych podczas wykonywania kontraktów EOF, ponieważ mają lepsze gwarancje dotyczące wyjątków związanych ze stosem.
Jako ekspert spoza EVM, który bardzo skupia się na samym EIP, niewiele mogę na ten temat powiedzieć! Jeśli czytelnicy chcą dowiedzieć się więcej o EOF, polecam odpowiednie tweety zamieszczone przez klientów light z zespołu Geth i Leo z zespołu Solidity.
Wycofanie łańcucha sygnalizacyjnego
Wreszcie, główną częścią „Shapelli” (przypis tłumacza: zbiorowa nazwa Szanghaju/Capelli) jest wycofanie łańcucha latarni. Ta część zmiany jest opisana w specyfikacji warstwy konsensusu i EIP-4895. Istnieje obecnie nieco przestarzała meta-specyfikacja łącząca te zmiany.
Na wysokim poziomie mechanika wypłat wygląda następująco:
Proponując blok, walidator liniowo skanuje indeks walidatora, aby znaleźć pierwszych 16 walidatorów z referencjami 0x01, które muszą spełniać jeden z następujących warunków:
Posiadaj saldo powyżej 32 ETH (tj. zgromadziłeś nagrody walidatora)
Można je wypłacić (tj. całkowicie opuszczono zestaw walidatorów)
Saldo jest większe niż 32 ETH (oznacza to, że nagroda walidatora została uzyskana)
Jest wyjmowany (wypłacalny, to znaczy całkowicie opuścił zestaw walidatora)
Na ich podstawie weryfikator utworzy listę wypłat, które zostaną uwzględnione w ich ExecutionPayload. Każda pozycja na tej liście zawiera następujące elementy:
Walidator utworzy listę wypłat z tych walidatorów i spakuje ją do swojego ExecutionPayload. Każdy element na liście zawiera następujące elementy:
WithdrawalIndex: Indeks wszystkich dokonanych transakcji wypłat - pomaga to rozróżnić wypłaty tej samej kwoty z tego samego adresu, tego samego walidatora
ValidatorIndex: indeks walidatora, w przypadku którego saldo zostało podniesione
ExecutionAddress: Adres ETH warstwy wykonawczej, na który mają być wysyłane wypłaty
Kwota: Kwota wysłana na adres wykonania, kwota ta jest mierzona w gwei (nie wei)
Klienci warstwy wykonawczej będą dokonywać tych wypłat po wykonaniu transakcji podczas budowania lub przetwarzania bloków. Innymi słowy, wypłaty są przetwarzane w podobny sposób, jak rejestrowanie nagród typu dowód pracy i nie konkurują z transakcjami użytkownika o miejsce w bloku.
Warto zwrócić uwagę na jeszcze kilka szczegółów:
Podczas przetwarzania wypłat nie ma różnicy w priorytecie/kolejności pomiędzy „pełnymi środkami” i „częściowymi środkami”. Wycofanie pełne następuje w momencie opuszczenia zespołu wyjściowego przez walidatora, natomiast wycofanie częściowe następuje okresowo, czyli gdy następuje liniowe skanowanie zbioru walidatorów i przeskanowanie numeru indeksowego danego walidatora.
Aby wypłaty mogły zostać przetworzone, walidatory muszą użyć danych uwierzytelniających 0x01, które są reprezentowane przez adresy ETH. Gdy łańcuch nawigacyjny przechodzi w tryb online, dozwolone są tylko poświadczenia pary kluczy BLS 0x00. Aby zainicjować wypłatę, walidator z danymi uwierzytelniającymi 0x00 będzie musiał podpisać wiadomość BLSToExecutionChange. Zostaną one aktywowane podczas aktualizacji Capelli. Do podpisania tej wiadomości zostanie wykorzystanych wiele narzędzi, a walidatorzy mogą spodziewać się wsparcia i samouczków dotyczących tych narzędzi.
Skanowanie walidatorów odbywa się na blok. Jeśli po przeskanowaniu podzbioru zestawu walidatorów nie ma 16 wypłat do przetworzenia, walidator zatrzyma skanowanie, a następny walidator rozpocznie pracę od ostatnio zeskanowanego indeksu walidatora.
Jak zwykle, będzie kilka sieci testowych dla programistów i sieci testowych (może nawet kilka nowych sieci testowych!), w których walidatorzy będą mogli przeprowadzić cały proces i wyeliminować wszelkie problemy, zanim sieć główna zostanie uruchomiona.
Szanghaj/Capella to nie jedyne ulepszenie, które robi postępy! Zespół programistów wciąż nie może się doczekać kolejnej aktualizacji.
Aktualizacja w Cancun
Ponieważ zawartość aktualizacji w Szanghaju jest już pełna, wiele EIP (CFI), które uwzględniono w modernizacji, nie mogło zostać objętych modernizacją w Szanghaju. Zespół klienta rozpoczyna dyskusję, które EIP należy wziąć pod uwagę przy następnej modernizacji: aktualizacji w Cancun (nazwa warstwy do ustalenia)
Jeśli chodzi o warstwę konsensusu, EIP-4844 stał się pierwszym EIP zapisanym w specyfikacji po aktualizacji Capelli. Nie ma (jeszcze) specyfikacji warstwy wykonawczej, która mogłaby zaimplementować ten układ, ale zespół warstwy wykonawczej zgodził się podążać podobną ścieżką i wyśrodkować EIP-4844 przy następnej aktualizacji.
Zgodnie z konwencją uaktualnień wykorzystującą nazwy miast, w których odbywał się Devcon, utworzono plik cancun.md, w którym oficjalnie uwzględniono EIP-4844.
Decyzja ta zapadła w ostatniej chwili ostatniego spotkania AllCoreDevs w 2022 roku, więc nie było czasu na pracę nad innymi propozycjami. EIP, które weszły do aktualizacji CFI w Szanghaju, ale nie zostały ostatecznie uwzględnione, zostały przeniesione na listę CFI w celu aktualizacji w Cancun. Otworzono również post na forum Ethereum Magicians w celu omówienia kandydatów EIP w Cancun. Dyskusje na temat zakresu modernizacji w Cancun powinny rozpocząć się na dobre na początku przyszłego roku.
Ceremonia KZG
Kolejną rzeczą, na którą warto czekać w związku z aktualizacją w Cancun, jest ceremonia KZG, która jest wymaganiem EIP-4844.
Ten rytuał wygeneruje losowość potrzebną do sprawdzenia ważności danych obiektu BLOB. Aby można było uznać to za bezpieczne, wystarczy, że tylko jeden uczestnik będzie uczciwy. Innymi słowy, jeśli wszyscy uczestnicy oprócz jednego uczestniczą w zmowie, cały proces jest kryptograficznie bezpieczny.
Ceremonia rozpoczyna się w styczniu i przez kilka miesięcy będzie otwarta dla wszystkich. Planuje się, że będzie to największa jak dotąd ceremonia tego typu, w której weźmie udział 10 000 uczestników! Jeśli chcesz mieć pewność, że nic Cię nie ominie, śledź Trenta Van Eppsa na Twitterze!
Proces aktualizacji po fuzji
Jak wspomniano w poprzedniej aktualizacji, po fuzji ważnym zadaniem jest koordynacja procesu aktualizacji Ethereum na poziomie wykonawczym i konsensusowym. Z perspektywy wysokiego poziomu warstwa wykonawcza wykorzystuje Yellow Paper i EIP do opisywania modyfikacji, podczas gdy warstwa konsensusu wykorzystuje wykonywalne specyfikacje Pythona.
Zaletą procesu na szczeblu wykonawczym jest to, że EIP jest dobrze znane społeczności i jest sformatowane w sposób wyraźnie przedstawiający uzasadnienie wniosku. Żółte księgi zawierające dużo treści matematycznych w połączeniu z EIP i koniecznością ponownego umieszczenia specyfikacji w kontekście każdego EIP sprawiają, że specyfikacje warstwy wykonawczej są trudne do zrozumienia i rozszerzenia.
Problem z warstwą konsensusu jest odwrotny: ma ona jasną i zrozumiałą specyfikację w jednym repozytorium, ale zmiany nie są namacalne, a propozycje są chowane w innych publicznych PR w repozytorium.
Mamy nadzieję, że wraz z wprowadzeniem specyfikacji warstwy wykonawczej Ethereum zmniejszymy tę lukę od strony warstwy wykonawczej. A przy pewnych konfliktach procesowych być może uda nam się wprowadzić EIP do procesu warstwy konsensusu!
To powiedziawszy, gdy omówiono i sfinalizowano zakres modernizacji w Szanghaju, stało się jasne, że może brakować innej części procesu: umożliwienia społeczności wyrażenia swoich względnych preferencji co do zmian i zaangażowania się w dyskusje na temat całego zakresu aktualizacji (zamiast poszczególne EIP) Przedyskutuj to na miejscu i uwzględnij to w decyzjach na spotkaniach AllCoreDevs i warstwy konsensusu.
Nie jest jeszcze jasne, jak to będzie wyglądać – chętnie przyjmę sugestie! — jednak w miarę jak rosła liczba zainteresowanych stron aktywnie zaangażowanych w zmiany protokołu, podobnie jak liczba obszarów dotkniętych zmianami w warstwie 1, stało się jasne, że czegoś potrzebujemy.
Na szczęście nie musimy zaczynać od zera. Ethereum Magicians istnieje już od lat, a jego spotkania offline, dedykowane spotkania grupowe lub spotkania społeczności mogą być dobrym punktem wyjścia do ekspansji.
Większych postępów w tym zakresie można spodziewać się na początku 2023 r.!
Aktualizacja Gildii Porozumienia
Ponieważ pilotażowy projekt Protocol Guild (PG) jest już w połowie, opublikowano raport, w którym można przyjrzeć się rozwojowi sytuacji i zastanowić się, jakie są kolejne kroki w ramach projektu.
Przypominamy, że PG to niewymagający pozwolenia mechanizm finansowania dla programistów klientów Ethereum Layer 1, badaczy protokołów i współpracowników wspierających (takich jak Ty).
Mechanizm ten koncentruje się na jednostce, a nie na organizacji. Krótko mówiąc, każdy członek jest uprawniony do części tokenów gildii, ważonej w zależności od tego, jak długo przyczynił się do Ethereum. Dodawanie i usuwanie członków odbywa się w sposób prawdziwie Ethereum – w oparciu o zestaw standardów i ogólny konsensus w ramach PG. Lista ta zostanie następnie umieszczona w łańcuchu przy użyciu umowy podziału 0xSplit. Darczyńca może następnie wysłać środki bezpośrednio na adres odbiorcy lub w ramach umowy o nabyciu uprawnień, która zwalnia środki na adres odbiorcy.
Podsumowanie pilotażowego raportu okresowego znajduje się w tym tweecie. Oto kilka najważniejszych wydarzeń
W ramach pilotażu zebrano 9,7 miliona dolarów od organizacji takich jak Lido, Uniswap, ENS, NounsDAO i MolochDAO, a także od stałych darczyńców od osób prywatnych (dzięki Tetranode!) – dziękujemy wszystkim, dzięki którym było to możliwe!
Na początku PG liczyło 90 członków, a obecnie ma 128, a między nimi rozdzielono 5 milionów dolarów
Każdy członek otrzymywał średnio 39 000 dolarów, najniższa kwota wyniosła 13 000 dolarów, a najwyższa 79 000 dolarów
Architektura PG zmienia się i będzie obsługiwać L2 i wyeliminuje potrzebę stosowania wielu podpisów w celu aktualizacji wag
Te wczesne wyniki pokazują, że PG działa zgodnie z planem: mechanizm dystrybucji koszyka tokenów wśród samoinkubującej się, rosnącej grupy autorów protokołów. Projekt ten nie byłby tym, czym jest dzisiaj, gdyby nie hojne wsparcie darczyńców pilotażowych.
Patrząc w przyszłość, nadszedł czas, aby rozszerzyć zasięg PG i wykorzystać jego pełny potencjał: zapewnić opiekunom Ethereum konkurencyjne wynagrodzenie dostosowane do ryzyka. Najłatwiej jest w tym przypadku przekazać darowiznę w ramach projektu na rzecz PG od samego początku, jak powiedział Danny Ryan w tweecie uruchamiającym PG.
Większość darowizn w ramach pilotażu pochodziła z dużych projektów, na które przyznano duże kwoty środków. Jeśli Gildia Protokołu zdoła przekonać te projekty do przekazania darowizn na rzecz PG od pierwszego dnia, kiedy ich tokeny są nadal naprawdę „bezwartościowe”, wówczas opiekunowie Ethereum będą mogli skorzystać z całej trajektorii wzrostowej tych udanych projektów.
Jeśli zaangażowanych jest wystarczająca liczba projektów, zachęty mogą zatrzymać najlepsze talenty w ramach umów serwisowych, zamiast ich odciągać.
Aby wesprzeć ten i wiele innych rodzajów darowizn, PG będzie wymagać modernizacji technologicznej. Następna wersja będzie obsługiwać warstwy L1 i L2 i jeszcze bardziej ograniczy wpływ zarządzania na łańcuch.
Jeśli jesteś projektem, który chciałby przekazać datki na rzecz Gildii Protokołu, skontaktuj się ze mną – moje wiadomości prywatne są otwarte!
Podejmować właściwe kroki
Na tym kończy się rok 2022... Cóż za niezwykły rok! Trzy miesiące temu nawet nie byliśmy połączeni! Teraz, gdy Ethereum ma dowód, że stawka działa cicho w tle, uwaga przesunęła się na przyszłe transakcje.
Ponieważ wszyscy powrócą w styczniu, możesz spodziewać się:
Shanghai/Capella zaktualizowała sieć testową dla programistów i fork cienia
Ceremonia KZG przechodzi do Internetu
Dyskusje na temat Cancun i tego, jak powinien ewoluować proces modernizacji sieci, aby lepiej uwzględnić preferencje społeczności
Pilotażowy protokół gildii dobiegnie końca i ogłosimy strukturę popilotażową.