Autor: Christine Kim, Galaxy; Kompilator: Wu Baht, Golden Finance
12 września 2024 r. programiści protokołu Ethereum spotkali się wirtualnie za pośrednictwem Zoom w ramach 196. telekonferencji All-Core Developer Execution (ACDE). W tym tygodniu gospodarzem rozmowy był Tim Beiko, szef wsparcia protokołów w Fundacji Ethereum (EF). Połączenie konferencyjne ACDE to dwutygodniowa seria konferencji, podczas których programiści omawiają i koordynują zmiany w warstwie wykonawczej Ethereum (EL).
Na ACDE#196programiści udostępnili najnowsze aktualizacje wersji Pectra Devnet 3 i omówili różne zmiany w kodzie Pectra, które mają zostać zaimplementowane w przyszłej sieci programistycznej. Prowadzą poważne dyskusje na temat podzielenia aktualizacji na dwie części, aby móc udostępnić zmiany w kodzie w Devnet 3 szybciej, prawdopodobnie do lutego przyszłego roku. Deweloperzy zgodzili się podjąć ostateczną decyzję w tej sprawie podczas kolejnego zaproszenia ACD. Na koniec inżynier operacyjny programisty EF, posługujący się pseudonimem „pk910”, udostępnił aktualizację dotyczącą swojej pracy nad uporządkowaniem repozytorium GitHub publicznej sieci testowej Ethereum i zrestrukturyzowaniem go, aby było łatwiejsze w użyciu.
Pectra Devnet 3
Inżynier EF DevOps Parithosh Jayanthi wyjaśnia wydanie Pectra Devnet 3. Sieć deweloperska rusza w środę, 11 września. Zawiera poprawki dotyczące łączenia walidatorów w EIP 7251 i zaktualizowane specyfikacje dla EIP 7702. Na podstawie dotychczasowych testów na Devnet 3 wydaje się, że zarówno EIP 7251, jak i EIP 7702 działają zgodnie z oczekiwaniami. Jayanthi zauważył, że w klientach Nethermind i EthereumJS wykryto pewne problemy i że oba zespoły klienckie ciężko pracują, aby je rozwiązać. Jayanthi dodał, że skoro EIP 7702 został uruchomiony w Devnet 3, dobrym pomysłem byłoby umożliwienie twórcom portfeli przetestowania implementacji i przekazania opinii na temat jego wykorzystania. Wszystkie informacje na temat Pectra Devnet 3, w tym krany umożliwiające żądanie sieci testowej ETH, można znaleźć na tej stronie internetowej.
Aktualizacja specyfikacji Pectry
Deweloper Geth, Felix Lange, zaproponował zmiany w kodowaniu żądań wyzwalacza EL w Pectrze. W tle Pectra umożliwi inteligentne kontrakty na EL inicjowanie wycofywania walidatorów i fuzji na CL. Podczas ostatniej rozmowy ACD Lange podzielił się zaleceniem, aby zmniejszyć ilość pracy wymaganej przez klientów EL przy analizowaniu tych żądań. Od czasu rozmowy telefonicznej z zeszłego tygodnia Lange sformalizował swoje zalecenia i prace, jakie zespół klienta EL musi wykonać, aby zaktualizować kodowanie następujących czterech EIP:
EIP 7685, ogólne żądanie warstwy wykonawczej;
EIP 7002, EL może powodować wypłaty;
EIP 6110, depozyt walidatora dostaw w łańcuchu;
EIP 7251, zwiększ maksymalne efektywne saldo.
Deweloperzy generalnie zgadzają się z propozycją Lange. Jednakże programista Nimbus, podający się za „Dustina”, uważa, że propozycja jest „bezsensownie elastyczna” i niekompatybilna z przyszłymi zmianami w formacie serializacji EL. Podkreślił również, że potrzebne są dodatkowe specyfikacje, aby jasno regulować kolejność żądań klientów EL i zachowanie klientów CL, gdy EL przesyła do CL nieważne wnioski. Lange zgodził się dodać więcej tekstu do API silnika, aby określić kolejność żądań. Zgadza się również z Dustinem, że należy dokładniej rozważyć zachowanie klienta CL, gdy klient CL wykryje nieprawidłowe żądanie od klienta EL.
Badacz Fundacji Ethereum, Peter Miller, zwrócił uwagę, że w oparciu o logiczne zachowanie klientów CL zgodnie z obecną specyfikacją, klienci CL powinni odrzucać bloki z EL, które nie są uporządkowane w prawidłowy sposób. Dodatkowo, jeśli na liście udostępnionej przez EL EL znajdują się nieprawidłowe żądania, CL powinien po prostu przetworzyć wszystkie ważne żądania na liście i zignorować nieprawidłowe żądania. Dustin zgadza się z Millerem i zaleca, aby programiści określili to zachowanie w odpowiedniej dokumentacji. Beiko stwierdziła, że programiści powinni popracować nad rozwiązaniem błędów we wniosku Langego i zakończyć go przed kolejnym zaproszeniem ACD.
Następnie programista Erigon, Andrew Ashikhmin, zaproponował aktualizację EIP 7702, konfigurując kody kont EOA. Zauważył, że kontrole ważności określone w EIP są niezgodne z kontrolami określonymi w starym EIP. Programista Geth, Matt Garnett (znany również jako „Lightclient”), twierdzi, że ma alternatywę, która pozwala rozwiązać problemy ze spójnością i uprościć kontrolę ważności EIP 7702. Deweloperzy w większości opowiadają się za sfinalizowaniem propozycji Lightclient i dodaniem jej do Pectra Devnet 4.
Następna dyskusja związana z Pectrą dotyczy cen prekompilacji BLS w ramach EIP 2537. Deweloper Geth, Jared Wasinger, powiedział, że na podstawie jego analizy porównawczej wstępna kompilacja BLS powinna kosztować dwa razy więcej niż obecnie podaje. Obecnie koszt opiera się na wykonaniu wielowątkowym, co nie jest standardem, według którego wyceniane są inne prekompilowane wykonania. Dlatego też, na podstawie swojej analizy z wykorzystaniem wykonania jednowątkowego, Wasinger zalecił zmiany w tabeli rabatów dla operacji w EIP 2537. Zespół Nethermind informuje, że opracowuje narzędzie, dzięki któremu inne zespoły klientów będą mogły z łatwością przeprowadzić własną analizę porównawczą EIP. Beiko zasugerowała, aby zespół przeprowadził własne testy porównawcze prekompilacji BLS i przedstawił pomysły dotyczące ponownej wyceny tych operacji w ciągu najbliższych dwóch tygodni.
Suplement Pectra EIP
Następnie programiści rozpoczęli dyskusję na temat dodania nowych EIP dla aktualizacji Pectry. Na początku dyskusji Beiko przestrzegła: „W Pectrze mamy już dużą liczbę EIP. To już największy jak dotąd fork pod względem wolumenu EIP”. Zgodnie z poglądami podzielanymi przez deweloperów przed wezwaniem, Beiko powiedział: „Bez wątpienia EIP 7742 (oddzielenie liczby kropelek między EL i CL) jest najmniej kontrowersyjnym z listy EIP wciąż rozważanych pod kątem włączenia do aktualizacji.
Badacz EF, Alex Stokes, po raz kolejny wpadł na pomysł podzielenia Pectry na dwa mniejsze hard forki. „Myślę, że wszyscy zgodzili się, że jest to bardzo duży widelec. Naturalną rzeczą jest więc podzielenie go na dwie części. Ogólnie rzecz biorąc, mniejsze widelce są mniej ryzykowne. W szczególności Pectra ma teraz wiele międzywarstwowych EIP, które naprawdę zwiększa obciążenie związane z testowaniem, bezpieczeństwem i przeglądami” – powiedział Stokes. Jayanthi, który również podniósł ten pomysł podczas poprzedniej rozmowy, powiedział, że nadal go popiera. „Myślę, że głównym powodem jest to, że obecnie mamy wiele EIP i mamy tendencję do dotykania wielu warstw stosu, a im więcej dodajemy, jednej osobie trudno jest uzyskać całościowy obraz wszystkich zmian nawet przy obecnym obciążeniu” – powiedział Jayanthi.
Jeśli chodzi o sposób podziału obecnego Pectra EIP na dwie gałęzie, Stokes zasugerował wykorzystanie wszystkich EIP działających obecnie w sieci rozwojowej do wydania pierwszej części Pectry, a następnie użycie PeerDAS, EOF i kilku innych dodatkowych EIP do wydania drugiej części Pectra. Twórcy są przekonani, że dzięki temu uda im się wypuścić pierwszą część Pectry już w lutym przyszłego roku. „Myślę, że ten fork byłby porażką, gdybyśmy nadal wypuszczali pierwszą połowę tylko w czerwcu” – powiedział badacz EF Ansgar Dietrichs na czacie Zoom.
Beiko opowiada się za pomysłem forka, ale ostrzega przed usuwaniem jakichkolwiek EIPów z sieci deweloperskiej, ponieważ mogłoby to spowodować więcej pracy dla zespołów klientów i wydłużyć, a nie skrócić harmonogram przygotowania zmian w kodzie do aktywacji sieci głównej. Niezależny twórca protokołu Ethereum, Danno Ferrin, zalecił jak najszybsze ukończenie EIP na Devnet 3, aby aktywować sieć główną, a następnie równoległą pracę, zaczynając od Devnet 4 lub 5, w celu przeniesienia PeerDAS i EOF do Pectra EIP. Tak naprawdę, w aktualizacji po Pectrze, Devnet 4 lub 5 stanie się Devnet 0, a programiści nie są pewni, jak to nazwać.
W poprzedniej rozmowie programiści zgodzili się nazwać aktualizację imieniem Pectry Fusaki, ale zgodzili się również zarezerwować aktualizację na czas przejścia na Verkle. W związku z tym Ferrin poradził programistom, aby nie zamawiali aktualizacji w przedsprzedaży, dopóki nie będą pewni, że zmiany w kodzie są gotowe do aktywacji w sieci głównej. Wywołało to gniew programisty Geth, Guillaume’a Balleta, który przewodził pracom nad przejściem na Verkle i upierał się, że przejście na Verkle było gotowe „dawno temu”. Aby złagodzić napięcia, Beiko stwierdziła, że ostatecznym celem podziału Pectry na dwie części była próba udostępnienia zmian w kodzie Pectry w szybszym czasie, co pomogłoby oczyścić drogę do późniejszego przejścia na Verkle.
Istnieje jednak ryzyko, że druga część aktualizacji Pectra może się powiększyć w miarę dodawania większej liczby EIP, w związku z czym jej wydanie zajmie więcej czasu niż jednoczesne opublikowanie aktualnej listy Pectra EIP. Deweloper Nethermind, Ben Adams, zapytał, jak wyglądałby proces testowania Pectry, gdyby aktualizację podzielono na dwie części. Biorąc pod uwagę, że decyzja ta całkowicie zmieni zakres kolejnej natychmiastowej aktualizacji Ethereum, Beiko zaleciła programistom poświęcenie tygodnia na rozważenie tego pomysłu. Poprosił programistów, aby przygotowali się do podjęcia ostatecznej decyzji w tej sprawie podczas rozmowy telefonicznej dotyczącej konsensusu obejmującej wszystkie rdzenie deweloperów, która odbędzie się w przyszły czwartek.
Dopasowanie struktury konfiguracji sieci
Na koniec inżynier EF DevOps „pk910” udostępnił aktualizację dotyczącą swojej pracy nad uporządkowaniem repozytorium GitHub publicznej sieci testowej Ethereum i zrestrukturyzowaniem go w celu ułatwienia użytkowania. Poprosił zespół ds. kont o sprawdzenie konfiguracji węzłów sieci głównej i testowej Ethereum oraz dodanie wszelkich brakujących informacji do odpowiednich repozytoriów.
