Ostatnia runda rozwoju sieci testowej Ethereum Shapella ujawnia kilka błędów

Testy w sieci testowej Ethereum Zhejiang przed aktualizacją Shanghai-Capella ujawniły pewne błędy, ale nic, co wpłynęłoby na harmonogram wprowadzenia stakingu do sieci. 

Deweloper Marius VanDerWijden udokumentowane błąd synchronizacji napotkany przez innych klientów, co do którego programiści są przekonani, że można go załatać, zgodnie z wątkiem Tima Beiko z Fundacji Ethereum. Zauważył, że błąd nie wpłynie na żadne ustalone harmonogramy proponowanego zestawu aktualizacji dla sieci testowej Sepolia zaplanowanej na 28 lutego.

Najnowsza aktualizacja devnet do wypłat zawierała szczegółowy test warunków skrajnych składający się z 600,000 360,000 walidatorów, z których XNUMX XNUMX przeprowadziło aktualizacje danych uwierzytelniających wypłaty w momencie rozwidlenia. Wystąpiły skoki w pamięci RAM i procesorze klientów, a programiści będą mierzyć liczbę utraconych i zarejestrowanych komunikatów aktualizacji poświadczeń w nadchodzących dniach, powiedział Beiko.

Test warunków skrajnych ujawnił również błąd między klientem Proof of Stake, Prysm, a klientem Besu, który jest przeznaczony do dozwolonych przypadków użycia. W celu prawidłowej synchronizacji klient Prysm oczekuje określonej liczby odpowiedzi; jednak Besu nakłada ograniczenia odpowiedzi, które schodzą poniżej niezbędnego progu synchronizacji, powiedziała Beiko. Zespół Besu bada sprawę.

Blobless zakaz

Po dyskusji na temat tego, jak najlepiej zoptymalizować początkową orientację na klienta, programiści ostatecznie postanowiła całkowicie zakazać transakcji Blobless 4844, co zmieniłoby założenia klientów dotyczące transakcji i mogłoby skomplikować konfigurację.

Deweloperzy dyskutowali również o tym, jak posunąć się naprzód z wycofywaniem słowa kluczowego SELFDESTRUCT, które kończy umowę, usuwa kod bajtowy umowy z łańcucha bloków i przekierowuje środki w kontakcie na określony adres.

Chociaż ścieżka naprzód pozostaje niejasna, obecnie dyskutowane są trzy propozycje na ten temat, ponieważ programiści starają się znaleźć „opcje dezaktywacji, które nie psują rzeczy”, powiedziała Beiko.

„Wyzwanie polega na tym, że otwiera paskudny wektor ataku: zastosuj kontrakt, zapełnij pamięć masową w określony sposób, a kiedy ponownie wdrożysz umowę, stara pamięć nadal tam będzie i można uzyskać do niej dostęp w złośliwy sposób” – powiedziała Beiko.