Tytuł oryginalny: „Ethereum All Core Developers Consensus Call#139Writeup”
Autorka oryginalna: Christine Kim
Oryginalna kompilacja: Ladyfinger, BlockBeats
Notatka redaktora:
All Core Ethereum Developers Consensus Call (ACDC) to dwutygodniowa seria spotkań skupiająca się na omawianiu i koordynowaniu zmian w warstwie Ethereum Consensus Layer (CL), znanej również jako Beacon Chain. 139. rozmowa ACDC, prowadzona przez badacza Fundacji Ethereum (EF), Alexa Stokesa, dotyczyła poprawek Pectra Devnet 2, przygotowań do Devnet 3, postępu we wdrażaniu PeerDAS i nowych danych na temat dystrybucji węzłów Ethereum.
Podczas spotkania programiści dokonali przeglądu stabilności i istniejących problemów Pectra Devnet 2, omówili przygotowania do nadchodzącego Devnet 3 oraz odbyli szczegółową dyskusję na temat postępów we wdrażaniu PeerDAS. Ponadto propozycja EIP 7688, której celem jest wprowadzenie kompatybilnej w przód struktury danych w celu wsparcia potencjalnych zmian w metodzie serializacji danych Ethereum, również wywołała szeroką dyskusję wśród uczestników. Christine Kim, wiceprezes ds. badań w Galaxy Digital, szczegółowo nagrała to spotkanie, a BlockBeats skompilował oryginalny tekst w następujący sposób:
8 sierpnia 2024 r. programiści Ethereum zorganizowali 139. konferencję Core Developers Consensus Conference Call (ACDC) za pośrednictwem Zoom. Telekonferencja ACDC to odbywająca się co dwa tygodnie seria spotkań, podczas których programiści omawiają i koordynują zmiany w warstwie Ethereum Consensus Layer (CL), znanej również jako Beacon Chain. Gospodarzem tego tygodnia jest badacz Fundacji Ethereum (EF), Alex Stokes. Programiści omawiają poprawki Pectra Devnet 2, przygotowania do Devnet 3, postęp wdrożenia PeerDAS i nowe dane na temat dystrybucji węzłów Ethereum.
Aktualizacja Pectry
Stokes ogłosił, że badacz EF, Hsiao Wei Wang, wkrótce wypuści oficjalną, zaktualizowaną wersję alfa.4 specyfikacji warstwy konsensusu Pectra (CL). Ta wersja zawiera wiele ulepszeń w stosunku do poprzedniej wersji, a jej wydanie jest planowane w najbliższej przyszłości.
W temacie Pectra Devnet 2, inżynier operacyjny EF Developer Barnabas Busa powiedział, że sieć jest stabilna i osiągnęła 85% udziału w sieci. Nadal istnieje kilka drobnych problemów, które należy rozwiązać w klientach warstwy wykonawczej (EL), głównie EthereumJS i Erigon. Większość klientów CL działa stabilnie na Devnet 2. Jednakże Busa wspomniał o drobnych problemach z klientem Prysm, które wymagają dalszego zbadania. Inżynier EF DevOps Parithosh Jayanthi dodał, że zespoły klientów są również wymagane do zbadania problemów między węzłami Lighthouse, Teku i Besu.
Następnie programiści dyskutowali, jak ulepszyć proces komunikacji podczas uruchamiania devnetu. Programistka Prysm, Kasey Kirkham, podczas czatu Zoom zwróciła uwagę na jej brak wiedzy na temat czasu uruchamiania Devnet 2. Aby mieć pewność, że informacje o uruchomieniu Devnet 3 zostaną dokładnie przekazane wszystkim zespołom klienckim, programiści postanowili zorganizować regularne cotygodniowe spotkania w celu aktualizacji postępów testów Pectry. Chociaż dokładna godzina nie została jeszcze ustalona, oczekuje się, że spotkania te będą odbywać się w każdy poniedziałek, podobnie jak rozmowy telefoniczne Dencun dotyczące testów przed aktualizacją. Jayanthi zaproponował, aby spotkania te były krótkie i skuteczne, trwały od 15 do 30 minut i skupiały się na omówieniu aktualizacji testów devnet związanych z firmą Pectra, obejmujących takie tematy, jak PeerDAS i EOF devnets.
Omawiając Pectra Devnet 3, programiści powtórzyli, że będzie on nadal korzystał z tej samej konfiguracji EIP, co Devnet 2. Ponadto Devnet 3 po raz pierwszy zintegruje nowo zaprojektowany EIP 7702, który zespół przeprowadzi skrupulatne testy, aby zapewnić kompatybilność z rdzeniami EIP firmy Pectra. Gajinder Singh z zespołu Lodestar wspomniał, że EIP 7251, problem występujący w propozycji MaxEB, został wykryty w Devnet 2. Chociaż został on debugowany, nadal potrzebne są bardziej szczegółowe testy w następnej sieci deweloperskiej Pectra, aby zweryfikować rozwiązanie.
Jak omówiono w ACDE nr 193, istnieje nowa specyfikacja API silnika, która umożliwia klientom CL uzyskiwanie obiektów BLOB z puli pamięci transakcyjnej obiektów blob EL. Ta metoda nazywa się „getBlobsV1”. Aby uniknąć nadużyć, twórca Teku, Enrico del Fante, zaproponował pewne wyjaśnienia do specyfikacji CL. Stokes zalecił programistom przejrzenie tych wyjaśnień i zaplanowanie przetestowania zastosowania tego podejścia w Pectra Devnet 3.
Twórcy omówili wycofanie złożonego protokołu. Mplex był protokołem używanym przez klientów CL do transmisji wielostrumieniowej w jednym łączu komunikacyjnym, ale jego twórcy uznali go za przestarzały. Zespół klienta planuje przejść na nowe technologie ponownego wykorzystania strumieni, takie jak Yamux. Phil Ngo z Lodestar ogłosił, że zakończył integrację i testowanie Yamux i woli bezpośrednio przejść na nowy protokół, niż utrzymywać dwa protokoły w dłuższej perspektywie, ponieważ zwiększy to koszty operacyjne klienta. Etan Kissling z Nimbus ujawnił również, że jego zespół testuje yamux. Twórcy zgodzili się, że będą w dalszym ciągu monitorować postępy innych zespołów klienckich CL w zakresie przejścia protokołu i planują ponowną ocenę strategii migracji z multipleksera na nowy multiplekser w nadchodzących miesiącach.
Etan Kissling przedstawił w wątku Pectra dyskusję na temat EIP 7688, propozycji wprowadzenia struktury danych kompatybilnej z forward, aby umożliwić twórcom inteligentnych kontraktów przejście z RLP w metodzie serializacji danych Ethereum Execution Layer (EL). Kontynuuj używanie, kiedy dojazd do SSZ. Chociaż sama aktualizacja Pectry nie w pełni zaimplementuje SSZ, zaproponowano EIP 7688, aby zapewnić kompatybilność w przyszłości Pectra EIP w odniesieniu do zmian danych.
Alex Stokes ostrożnie podchodzi do włączania EIP 7688 do aktualizacji Pectry, twierdząc, że aktualizacja jest już dość duża. Parithosh Jayanthi wspomniał podczas konferencji, że EIP 7688 może zostać przetestowany w Devnet 5 tak szybko, jak to możliwe. Przedstawiciele zespołów, w tym Lodestar, Prysm, Teku i Lighthouse, wyrazili poparcie dla tej propozycji. Stokes i Beiko zalecają, aby unikać dodawania nowych EIP do Pectry, dopóki wszystkie istniejące EIP Pectra nie osiągną stanu ustalonego. Kissling przyjął tę sugestię i zapytał, kiedy najlepiej będzie powrócić do tej kwestii. Chociaż nie otrzymano żadnej konkretnej odpowiedzi, zespół ogólnie zgodził się, że przed uruchomieniem Pectra Devnet 5 należy ponownie ocenić EIP 7688.
Aktualizacje PeerDAS
Przedstawiciele zespołu klienta Prysm przedstawili na spotkaniu swoje najnowsze postępy we wdrażaniu PeerDAS, wywołując dyskusję na temat potrzeby wysyłania żądań API silnika „blobsidecar”. Alex Stokes zasugerował, że następne spotkanie grupy PeerDAS wymaga szczegółowej dyskusji na temat zmian, jakie PeerDAS musi wprowadzić w API silnika. Zauważył również, że badacz EF sporządził formalną specyfikację, w której proponuje usunięcie mechanizmu próbkowania z PeerDAS w celu zmniejszenia złożoności procesu aktualizacji. Jednak na niedawnym spotkaniu grupy PeerDAS uczestnicy wyrazili obawę, że posunięcie to może utrudnić w przyszłości ponowne wprowadzenie próbkowania za pomocą hard forku. Dodatkowo niejasny jest wpływ usunięcia mechanizmu pobierania próbek na bezpieczne zwiększenie limitów gazów typu blob w Pectrze. Podczas telekonferencji, która odbyła się w tym tygodniu, ponownie poruszono propozycję oddzielenia limitów gazów blob w warstwie wykonawczej (EL) i warstwie konsensusowej (CL), EIP 7742. Stokes powiedział, że zaktualizuje EIP i planuje omówić jego ewentualne włączenie podczas następnego zaproszenia do składania wniosków w ramach CL, a także tematy związane z korektami limitów gazów typu blob w Pectra.
Aktualizacja badań
Podczas telekonferencji, która odbyła się w tym tygodniu, programiści skupili się na trzech tematach badawczych. Po pierwsze, badają przypadki skrajne, które weryfikatorzy mogą napotkać podczas łączenia postawionych sald ETH w ramach EIP 7251. Etan Kissling zasugerował, że salda walidatorów mogą nie być aktualizowane przez długi czas podczas fuzji, co może spowodować, że protokół nieprawidłowo przydzieli obowiązki komitetu synchronizacyjnego. W odpowiedzi Alex Stokes odpowiedział, że ten problem jest podobny do obsługi wyjścia walidatora przez protokół i zasugerował udokumentowanie tego przypadku brzegowego w specyfikacji warstwy konsensusu (CL) bez zmiany istniejącego projektu scalania.
Następnie programiści omówili zmiany w warstwie sieci Ethereum, w szczególności wprowadzenie „szybkiego wpisu ENR”. Quic oznacza szybkie połączenie internetowe UDP, które pomaga węzłom wysyłać i odbierać dane. Stokes zasugerował utworzenie żądania ściągnięcia (PR) w serwisie GitHub w celu uszczegółowienia konkretnych zmian w szybkim wpisie ENR.
Na koniec ProbeLab podzielił się swoją bieżącą analizą działania węzłów w sieci Ethereum. Z raportów wynika, że w sieci Ethereum działa obecnie 8335 węzłów, z czego 42% korzysta z klienta Lighthouse. Węzły działające w Stanach Zjednoczonych stanowią 36% całości, a około połowa węzłów jest wdrożona w centrach danych. Deweloper firmy Prysm „Potuz” wyraził ciekawość faktem, że liczba węzłów Lighthouse hostowanych w centrum danych przekracza liczbę węzłów hostowanych samodzielnie. Stokes spekuluje, że może to wynikać z faktu, że główna baza użytkowników klienta Lighthouse obejmuje instytucje i profesjonalnych operatorów węzłów.
Pod koniec spotkania Potuz nalegał, aby zespół przejrzał przesłany przez siebie PR dotyczący ulepszenia struktury ładunku wykonawczego. Propozycję tę po raz pierwszy poruszono podczas ostatniego zaproszenia ACDC. Potuz podkreślił znaczenie szybkiego podejmowania decyzji, zauważając, że chociaż zmiany te są koncepcyjnie proste i łatwe do zrozumienia, zintegrowanie ich ze specyfikacją Consensus Layer (CL) może stanowić wyzwanie. Radzi programistom, aby jak najszybciej rozpoczęli prace nad tym.
„Oryginalne łącze”
