W czwartek późnym wieczorem blockchain Ethereum napotkał problem, który tymczasowo uniemożliwił poprawną walidację bloków. Chociaż od tego czasu wszystko wróciło do normy, oto co wiemy o tym epizodzie na chwilę obecną.
Bloki tymczasowo przestały być finalizowane na Ethereum
W chwili pisania tego tekstu dokładna przyczyna nie została jeszcze podana, ale przez około trzydzieści minut blockchain Ethereum (ETH) napotkał problem uniemożliwiający finalizację bloków.
Łańcuch beaconów przestał być finalizowany około trzydzieści minut temu. Nie wiem jeszcze dlaczego, ale ogólnie łańcuch został zaprojektowany tak, aby był odporny na to, transakcje będą kontynuowane jak zwykle, a finalizacja rozpocznie się, gdy problem zostanie rozwiązany. pic.twitter.com/utAS0uAWpG
– superphiz.eth ️ (@superphiz) May 11, 2023
Ważne jest, aby podkreślić, że blockchain nie zatrzymał się. Jednak w ciągu 3 epok w warstwie konsensusu wystąpił błąd podobny do tak zwanego „wycieku nieaktywności”.
Mówiąc prościej, blockchain zachowywał się tak, jakby wiele walidatorów było offline.
Tak się nie stało, ale faktem jest, że w tym okresie walidatory wydały ograniczoną liczbę certyfikatów:
Figure 1 – Epochs that encountered a consensus bug on Ethereum
Problem z używanym oprogramowaniem
Aby funkcjonować, blockchain Ethereum jest podzielony na 2 filary: warstwę wykonawczą, która umożliwia przeprowadzanie transakcji, oraz warstwę konsensusu, która zapewnia spójność bloków. W przypadku tych dwóch filarów walidatorzy mogą korzystać z różnego oprogramowania zwanego klientami.
Fundacja Ethereum zachęca walidatorów do dywersyfikacji klientów, z których korzystają, aby w przypadku wystąpienia błędu blockchain nadal działał normalnie.
Na poniższej ilustracji widzimy, że oprogramowanie używane w warstwie konsensusu jest prawidłowo zdywersyfikowane, podczas gdy w warstwie wykonawczej klient Geth jest zdecydowanie zbyt reprezentowany:
Figure 2 – Diversity of clients used by validators on Ethereum
Ponieważ żaden klient warstwy konsensusu nie jest używany przez więcej niż 50% walidatorów, wczorajszy błąd nie mógł spowodować zamknięcia lub rozwidlenia łańcucha bloków. Zakładając, że problem rzeczywiście miał swoje źródło w jednym z wykorzystywanych pakietów oprogramowania.
W takim przypadku deweloper Superphiz wskazuje, że problemu wycieku nieaktywności można by nawet uniknąć, gdyby żadne oprogramowanie nie reprezentowało więcej niż 33% walidatorów:
Jeśli klient warstwy konsensusu spowodował utratę ostateczności:
* Uniknęliśmy rozwidlenia, nie mając klienta supermajority.
* Mogliśmy całkowicie uniknąć utraty ostateczności, gdyby żaden klient nie miał więcej niż 33%.
Jestem dumny z naszej pracy nad różnorodnością, ale to jeszcze nie koniec. https://t.co/TUtXnQu5hD
– superphiz.eth ️ (@superphiz) 11 maja 2023
Ze swojej strony Terence Tsao wskazał, że zidentyfikowano problem z klientem Prysm, chociaż w tej chwili nie możemy powiedzieć, czy jest to źródło zatrzymania walidacji bloków :
Update from Prysm. Zidentyfikowaliśmy obszary, w których można poprawić buforowanie stanu. Dzięki ulepszonej pamięci podręcznej węzeł powinien działać lepiej w czasie awarii, tak jak wcześniej.
Biorąc pod uwagę, że łańcuch się ustabilizował, jako staker / operator węzła nie jest wymagane żadne działanie
– terence.eth (@terencechain) May 11, 2023
Najważniejsze w tym momencie jest to, że wszystko szybko wróciło do normy i żadne walidatory nie zostały przecięte podczas tego odcinka. W rzeczywistości slashing jest używany do wysysania części ETH przechowywanego, gdy walidatory nie wykonują prawidłowo swojej pracy.
Szczegółowy raport na temat tego, co się stało, powinien zostać wkrótce dostarczony przez zespół programistów, a my będziemy mogli powrócić do tych informacji w tym czasie.
