Polygon załatał dwie podatności w BlockSTM V2, systemie równoległego wykonania w kliencie Bor zasilającym blockchain Polygon PoS, które mogły pozwolić ważnym transakcjom na spowalnianie węzłów sieci. Według opublikowanego przez Polygon przeglądu technicznego błędy nie zmieniały wyników transakcji ani nie zagrażały konsensusowi. Ich ryzykiem była dostępność: węzeł mógł obliczyć poprawny wynik dla bloku, ale spędzać na jego przetwarzaniu tak dużo czasu, że pozostawał w tyle za resztą sieci. Firma ujawniła wyniki równolegle z publicznym wydaniem Bor v2.10.3, wersji klienta zawierającej poprawki.

Polygon deklaruje, że nie ma wiedzy o wykorzystaniu podatności na mainnecie ani teściecie Amoy.

Dlaczego zakończenie wykonania szeregowego jako pierwszego nie kończyło opóźnienia

Bor przetwarza nadchodzące bloki zarówno poprzez wykonanie szeregowe, jak i równoległe, przyjmując tę trasę, która zakończy się pierwsza. Wykonanie szeregowe podąża za kolejnością transakcji, podczas gdy wykonanie równoległe próbuje przetwarzać transakcje jednocześnie, a następnie weryfikuje, czy przyjęte założenia dotyczące zależności były poprawne. Takie podejście może przyspieszyć zwykłe obciążenia, gdy transakcje nie zależą od siebie nawzajem, ale tworzy też pracę spekulacyjną, która musi zostać niezwłocznie zatrzymana, gdy przestaje być użyteczna.

Ten projekt umieszcza Bor w rodzinie systemów optymistycznego wykonania równoległego: klient zakłada, że większość transakcji jest niezależna, uruchamia je obok siebie i ponosi koszt weryfikacji, gdy założenie okaże się błędne. Błędy wydajności w takich systemach zwykle objawiają się jako zmarnowana praca, a nie błędne wyniki, co odpowiada opisowi przedstawionemu przez Polygon.

Polygonu z powtarzalnym hashowaniem kodu ujawnił lukę. Wykonanie szeregowe zakończyło transakcję w dziesiątkach milisekund, lecz trasa równoległa pracowała jeszcze przez około 11 sekund. Wówczas anulowanie było sprawdzane tylko między transakcjami, co oznacza, że kosztowna transakcja już uruchomiona równolegle musiała się zakończyć, nawet po tym, jak wykonanie szeregowe wygenerowało wynik.

Właśnie dlatego ten test miał znaczenie: transakcja była ważna, a Bor mógł szybko ustalić jej stan końcowy, ale węzeł nadal musiał czekać na zakończenie zbędnego przetwarzania.

Dwa błędy tworzyły pracę, którą gaz nie w pełni wyceniał

Dwie podatności wynikały z różnych źródeł nadmiarowej pracy. Jedna pozwalała wykonaniu spekulacyjnemu na zachowanie zbyt dużej ilości obliczonych danych. Druga wielokrotnie ponownie obliczała hash kodu kontraktu, mimo że mogła wykorzystać wcześniejszy wynik.

Limity gazu obciążają użytkowników za określone operacje transakcyjne, ale nie zawsze obejmują każdy koszt wynikający z implementacji klienta. W tych przypadkach rozrost pamięci podręcznej i redundantne hashowanie mogły generować pracę po stronie węzła nieproporcjonalną do pozornego kosztu transakcji.

Polygon sklasyfikował oba błędy jako o średniej wadze i stwierdził, że żaden nie wpływał na konsensus. Ocena ta jest spójna z charakterem ustaleń: ryzykiem były wolniejsze węzły i marnowanie zasobów, a nie zmienione wyniki transakcji ani uszkodzony konsensus.

Co zmienia poprawka Bor v2.10.3

Poprawki w v2.10.3 ograniczają ten narzut bez zmiany wyników wykonania. Aktualizacja limituje współdzieloną pamięć podręczną używaną podczas wykonania spekulacyjnego i umożliwia Bor ponowne wykorzystanie wyniku hasha kodu zamiast jego ponownego obliczania przy powtarzających się odczytach. Celem jest zapobieżenie temu, aby ważne, lecz nietypowe obciążenie zużywało nadmierne zasoby lub niepotrzebnie wydłużało czas przetwarzania bloków.

Według notatek do wydania Bor v2.10.3 publiczne wydanie nie wymaga twardego forka, migracji bazy danych ani resynchronizacji węzłów. Operatorzy mogą aktualizować swoje węzły indywidualnie.

Prywatne łatanie poprzedziło publiczne ujawnienie

Polygon poinformował, że 5 października rozesłał prywatny build dla testnetu Amoy, a 8 października prywatny build dla mainnetu. Ujawnienie techniczne opublikował na forum zarządzania Polygon 15 października, po tym jak aktualizacje objęły większość sieci. Osobne ogłoszenie wydania opisuje wdrożenie na mainnecie i teściecie.

Z notatek do wydania wynika, że większość walidatorów i główni dostawcy RPC uruchamiali już prywatną wersję. Nie oznacza to, że każdy podłączony węzeł został zaktualizowany — dlatego ogłoszenie dla operatorów wzywa użytkowników Bor v2.10.2 lub starszych do szybkiej aktualizacji. Operatorzy korzystający z prywatnych buildów mogą przejść na wydanie publiczne podczas najbliższego okna serwisowego.

Pozostającym problemem jest pokrycie poprawkami

W przypadku portfeli, aplikacji i innych usług węzły, które pozostają w tyle, mogą zwracać opóźnione informacje o łańcuchu lub dłużej przetwarzać przesyłanie transakcji. Ujawnienie Polygonu nie potwierdza, by użytkownicy doświadczyli takich zakłóceń, a firma deklaruje, że nie zna przypadków wykorzystania podatności na mainnecie ani Amoy.

Ponieważ v2.10.3 nie zawiera twardego forka, nie ma terminu na poziomie protokołu zmuszającego maruderów do aktualizacji; wdrożenie postępuje według harmonogramu każdego operatora. Dlatego pokrycie poprawkami jest obserwowalnym sygnałem do śledzenia: jak szybko operatorzy Bor na wersji v2.10.2 lub starszej przejdą na poprawione wydanie.

Szersze prace Polygonu nad szybszym przetwarzaniem i infrastrukturą płatniczą czynią niezawodność operacyjną istotną. Poprawka eliminuje dwa zidentyfikowane źródła nadmiarowej pracy; praktycznym kolejnym krokiem jest jej wdrożenie przez pozostałych operatorów Bor.

Ten artykuł ma wyłącznie charakter informacyjny. Opisy podatności i oceny możliwości ich wykorzystania odzwierciedlają opublikowane ujawnienie Polygonu.

Źródło: Coindoo