Napisane przez Christine Kim

Opracowano przez: Luccy, BlockBeats

Nota wydawcy: Konferencja All Core Developers Consensus Call (ACDC) dotycząca Ethereum odbywa się co dwa tygodnie w celu omówienia i koordynowania zmian w warstwie konsensusu Ethereum (CL). To 134. telekonferencja ACDC. Na tej konferencji programiści omówili szczegóły implementacji i wyzwania techniczne wielu kluczowych rozwiązań EIP, w tym EIP 7549, EIP 7251, EIP 6110, EIP 7688 itp.

Ponadto programiści szczegółowo omówili także wdrożenie PeerDAS, technologii próbkowania dostępności danych, która ma znacznie poprawić zdolność sieci Ethereum do obsługi pakietów zbiorczych i wymagań dotyczących dostępności danych. Podczas spotkania zaproponowano podzielenie Pectry na dwa hard forki w celu aktualizacji oraz omówiono kwestie czasu aktywacji i współzależności różnych EIP.

Christine Kim, wiceprezes ds. badań w Galaxy Digital, szczegółowo opisała kluczowe punkty tego spotkania. BlockBeasts skompilowała oryginalny tekst w następujący sposób:

30 maja 2024 r. programiści Ethereum zebrali się w Zoomie na spotkaniu nr 134 w ramach konsensusu All Core Developers Consensus (ACDC). Zaproszenie ACDC to odbywająca się co dwa tygodnie seria spotkań prowadzona przez badacza Fundacji Ethereum, Alexa Stokesa, podczas których programiści omawiają i koordynują zmiany w warstwie Ethereum Consensus Layer (CL, znanej również jako Beacon Chain). W tym tygodniu programiści omawiają doświadczenia i otwarte problemy od czasu uruchomienia Pectra Devnet 0. Dyskutowali także nad wykonalnością rozszerzenia zakresu aktualizacji Pectry o zmiany w kodzie kontenera peerDAS i SSZ.

Recenzja Devneta 0

W świetle uruchomienia Pectry w Devnet 0 zespół klienta zgodził się zachować zachowanie walidacji, na które wpływa EIP 7549, niezmienione podczas aktywacji hard forku. Na poprzednim spotkaniu ACDC programiści rozważali różne opcje, aby zapewnić, że wpływ EIP 7549 nie spowoduje dużej liczby nieprawidłowych weryfikacji podczas forku. Aby uniknąć dalszego komplikowania aktualizacji, zespół klienta zdecydował się aktywować EIP 7549 w tej samej epoce, co inne EIP Pectra, bez zmiany zachowania sprawdzającego przed i po rozwidleniu.

Jeśli chodzi o EIP 7251, programiści nadal nie są pewni, czy należy zezwolić na łączenie postawionych ETH z poziomu warstwy wykonawczej (EL). Byłaby to idealna funkcja dla pul stawek takich jak Lido, dzięki czemu łączenie stawek nie musi polegać na operatorach węzłów, ale może być realizowane za pomocą inteligentnych kontraktów. Stokes zalecił sprawdzenie postępów klientów wdrażających fuzje staków walidacyjnych w ciągu kilku tygodni przed podjęciem decyzji, czy powinny to być operacje EL czy CL.

Następnie programiści omówili kilka pytań bez odpowiedzi dotyczących ostatecznego potwierdzenia depozytów walidatora w ramach EIP 6110. Deweloper Teku, Michaił Kalinin, podsumował wskazówki dotyczące rozwiązania tych problemów w komentarzu na GitHubie przed konferencją. Programista Lighthouse „sean” zadał pytanie dotyczące wersji żądania „GetPayloadBodies” w interfejsie API silnika. Stokes zalecił programistom opublikowanie swoich komentarzy w żądaniu ściągnięcia utworzonym dla problemu w GitHub.

Zmiany w EIP 7549

Deweloper Nimbus, Etan Kissling, zasugerował niewielką zmianę w implementacji EIP 7549. „Chodzi o stabilność uogólnionego indeksu. Gdy dodamy nowe pole w środku kontenera, kolejnym polom zostanie przypisany nowy indeks, co zepsuje dowód oparty na EIP 4788 na poziomie wykonania (EL), i trochę wprowadzające w błąd… Dlatego zalecam przeniesienie nowego pola na koniec, aby uniknąć obu problemów” – wyjaśnił Kissling. Do tej zmiany nie było zastrzeżeń. Stokes zaleca programistom sprawdzenie żądania ściągnięcia Kisslinga w GitHub.

Kolejna zmiana w EIP 7549 zaproponowana na spotkaniu polegałaby na zaprojektowaniu żądań i innych żądań uruchamianych przez EL jako dodatków do bloków EL. Odnosząc się do tej zmiany Kalinin powiedział: „Moim zdaniem jest to bardzo dobre rozwiązanie projektowe, upraszcza EL... i jest w zasadzie alternatywą dla uogólnionych żądań w bloku warstwy wykonawczej. Stokes Zaleca się, aby ten temat był omówione ponownie na następnym spotkaniu CL, aby programiści mieli więcej czasu na zapoznanie się z propozycją w serwisie GitHub.

Dyskusja na temat zakresu Pectry

Istnieją pewne EIP skupione na warstwie konsensusu (CL), które nie zostały oficjalnie uwzględnione lub wyłączone z aktualizacji Pectry. Na spotkaniu w tym tygodniu programiści dyskutowali, czy dodać EIP 7688 i PeerDAS do Pectry. EIP 7688 przyjmuje część struktury danych SSZ „StableContainer”, aby zapewnić zgodność w przód zmian atestów EIP 7549. Jako wprowadzenie w tle, SSZ jest strukturą danych używaną w CL i programiści chcą jej używać również w warstwie wykonawczej (EL). Więcej informacji na temat przejścia SSZ można znaleźć w protokołach z poprzednich posiedzeń. PeerDAS to implementacja próbkowania dostępności danych w Ethereum, która ma znacznie zwiększyć zdolność sieci do obsługi pakietów zbiorczych i wymagań dotyczących dostępności danych. W praktyce oczekuje się, że PeerDAS zwiększy liczbę transakcji typu blob, które walidatorzy mogą dołączyć do bloku, z 3 do 64 lub więcej na blok.

Barnabas Busa, inżynier operacyjny programistów w Fundacji Ethereum, powiedział, że programiści uruchomili wczesną wersję PeerDAS w sieci programistycznej. „Myślę, że wielu klientów odkryło wiele problemów, a kiedy poczynimy znaczne postępy, zawsze będziemy mogli ponownie uruchomić nową sieć programistyczną” – powiedział Busa. Stokes zapytał programistów, czy byliby skłonni dodać PeerDAS do Pectry bez powodowania opóźnień w aktualizacji.

Programista o pseudonimie „Nishant” ponowił sugestię, aby oddzielić aktywację PeerDAS od aktywacji innych EIP w Pectra. Chociaż jest to wykonalne, inny programista o pseudonimie „atd” podkreślił, że jeśli programiści planują aktywować te aktualizacje jedna po drugiej w krótkim czasie, użytkownicy nadal muszą aktualizować swoje oprogramowanie w tym samym czasie. atd powiedział: „Myślę, że to trochę szaleństwo robić fork dwa miesiące po kolejnej aktualizacji. Jeśli mamy koordynować wszystkich przy aktualizacji klienta, nie chcemy, aby wszyscy aktualizowali klienta dwa miesiące później. To by oznaczało nawet jeden cykl wydawniczy nie wystarczy.”

atd dodał, że jego zdaniem PeerDAS jest najciekawszą zmianą kodu w EIP uwzględnioną i omówioną w Pectrze. Stokes powiedział, że ma nadzieję włączyć PeerDAS do Pectry, nawet jeśli spowoduje to opóźnienia w aktualizacji. Deweloper klienta Grandine, Saulius Grigaitis, zaproponował usunięcie EIP 7549 i EIP 7688 z Pectry na rzecz PeerDAS. To skłoniło do dyskusji na temat szczegółów implementacji EIP 7688. Twórcy nie byli w stanie dojść do porozumienia w sprawie zmian w kodzie i propozycja zostanie ponownie rozpatrzona na następnym spotkaniu ACDC.

W temacie PeerDAS programiści nadal rozważają pomysł podzielenia Pectry na dwa hard forki. Inżynier ds. opcji programistycznych Fundacji Ethereum, Parithosh Jayanthi, ostrzegł, że jeśli programiści podzielą Pectrę na dwie aktualizacje, muszą uważać, aby nie dodać więcej EIP w przyszłej części 2 Pectry. Jayanthi powiedział: „Jedną rzecz, o której chcę wspomnieć, to to, że jeśli rozważamy podział na dwa widełki, musimy bardzo uważać, aby nie dodać więcej nowych EIP w następnym widelcu. Nie wiem, czy będziemy w stanie to zrobić Do tego momentu, jeśli uda nam się zaangażować w coś rok lub półtora roku temu, ponieważ zawsze mamy nowe pomysły, zmieniają się priorytety i tak dalej.

Kontynuując dyskusję na temat dwóch pomysłów na ulepszenia, programista Lighthouse „sean” powiedział, że nie przewiduje wielu współzależności pomiędzy PeerDAS a obecną listą Pectra EIP. Dlatego można je wykonać osobno, a później łatwo połączyć, gdy programista nabierze większej pewności w ich implementacji. Atd zgodził się, argumentując, że połączenie Pectra EIP, PeerDAS i EIP 7688 po ich odrębnym opracowaniu i przetestowaniu nie wiązałoby się z dużym ryzykiem.

Busa zaleca dalsze testowanie Pectra EIP i PeerDAS, ale zaprojektowanie zmian w kodzie tak, aby PeerDAS aktywował się o jedną epokę później niż Pectra EIP w sieciach deweloperskich i testowych. Zauważył, że tak już wygląda testowanie Pectra EIP i PeerDAS na Devnecie 0. „Naprawdę nie trzeba nic zmieniać” – stwierdził Busa, dodając, że jeśli PeerDAS nie jest gotowy, gdy inne rozwiązania EIP firmy Pectra są gotowe, programiści mogą usunąć tę zmianę w kodzie z aktualizacji. Rodzi to kilka pytań o to, jak różne epoki aktywacji PeerDAS wpływają na pracę zespołów klienckich. Ostatecznie twórcy zgodzili się na dalszy rozwój PeerDAS i Pectra EIP, ale założenie było takie, że PeerDAS będzie aktywowany w różnych epokach w sieci rozwojowej i sieci testowej.

Jak wspomnieliśmy wcześniej, twórcy zgodzili się pozostawić dyskusję na temat tego, czy EIP 7688 zostanie uwzględniony w Pectrze, do następnego zaproszenia ACDC.