AktualnościKryptoMantle cofna poprawkę state root z Reth w op-reth v1.6.3 po błędzie z 5 listopada – aktywa bezpieczne

Mantle cofna poprawkę state root z Reth w op-reth v1.6.3 po błędzie z 5 listopada – aktywa bezpieczne

Autor: Tron Weekly·

Najważniejsze informacje

  • •Mantle wydało op-reth mantle-v1.6.3, wydanie z własnej produkcyjnej linii wersji, które przenosi poprawkę z Reth z wersji upstream zamiast przechodzić na najnowszą wersję upstream.
  • •Firma bezpieczeństwa Blockaid ujawniła 5 listopada, że niezałatane węzły mogły generować nieprawidłowe state rooty i zwracać błędne dowody stanu poprzez eth_getProof — metodę RPC, której aplikacje i mosty używają do weryfikacji stanu on-chain.
  • •Poprawka w wersji upstream trafiła do Reth 3 listopada, dwa dni przed publicznym ujawnieniem, w wydaniach załatanych obejmujących Reth v2.10.0 i op-reth v2.8.1.
  • •Blockaid zaklasyfikował problem jako błąd poprawności, a nie exploit, i nie stwierdzono utraty środków, a Mantle potwierdziło, że aktywa są bezpieczne, nie jest wymagana akcja użytkownika ani migracja bazy danych.
  • •Ponieważ większość sieci OP Stack współdzieli klienta op-reth, błąd stworzył skorelowane ryzyko dla niezależnych od siebie sieci, wywołując reakcje takie jak wydanie node-reth v1.5.3 przez Base i scalenie backportu przez Celo.
Mantle cofna poprawkę state root z Reth w op-reth v1.6.3 po błędzie z 5 listopada – aktywa bezpieczne

Sieć Mantle pozostała online przez cały czas trwania błędu state root obecnego w Reth, klienckim execution cliecie upstream stojącym za jej stackiem op-reth, który szerzej wpływał na sieci zgodne z Ethereum. Zespół wydał op-reth mantle-v1.6.3, wydanie z własnej produkcyjnej linii wersji Mantle, które przenosi poprawkę błędu z wersji upstream zamiast przeskakiwać na najnowszą wersję upstream. W ogłoszeniu na X Mantle poinformowało, że aktywa są bezpieczne, nie jest wymagana żadna akcja użytkownika ani migracja bazy danych, prosząc jednocześnie operatorów węzłów o aktualizację (post).

Krótkie zdarzenie o wysokiej stawce

Zdarzenie było krótkie i niewidoczne dla użytkowników końcowych, co mogłoby sugerować, że nie ma znaczenia. Ma jednak znaczenie: state rooty to zobowiązania kryptograficzne używane do udowodnienia poprawności sald kont i pamięci kontraktów, a ich błędne obliczenie może powodować zatrzymanie węzłów, zwracanie nieprawidłowych dowodów lub rozbieżność z łańcuchem kanonicznym. „Aby warstwa druga (Layer 2) rozliczała się do Ethereum, poprawność na tym poziomie jest fundamentalna” — podkreśliło ogłoszenie Mantle.

Co się stało i kto był dotknięty

Wada znajdowała się w Reth, implementacji klienta wykonawczego Ethereum w języku Rust, oraz w op-reth, jego wariancie OP Stack wdrażanym przez kilka sieci warstwy drugiej. 5 listopada firma bezpieczeństwa Blockaid ujawniła, że niezałatane węzły mogły generować nieprawidłowe state rooty i zwracać błędne dowody stanu poprzez eth_getProof — metodę RPC, z której aplikacje i mosty korzystają, aby weryfikować stan on-chain. Blockaid zaklasyfikował problem jako błąd poprawności, a nie exploit, i nie stwierdzono utraty środków. Poprawka w wersji upstream trafiła do Reth 3 listopada — dwa dni przed publicznym ujawnieniem przez Blockaid — w załatanych wydaniach obejmujących Reth v2.10.0 oraz op-reth v2.8.1.

Reakcja rozprzestrzeniła się na cały ekosystem. Base wydał node-reth v1.5.3 i poinformował, że ponownie zweryfikował poprawność swojego węzła, a Celo scalił backport. Mantle wybrało inną drogę — załataniło bezpośrednio swoją linię produkcyjną zamiast przechodzić na najnowsze wydanie, czyli podejście backportu, które dostarcza ukierunkowaną poprawkę do istniejącej linii wydań bez wprowadzania niepowiązanych zmian z nowszych wersji upstream.

Dlaczego to ma znaczenie dla szerszego ekosystemu kryptowalut

Klienty wykonawcze to jedne z najmniej widocznych, a zarazem najbardziej znaczących komponentów infrastruktury blockchain. Deweloperzy rozszerzają API i uruchamiają na nich indeksery. Instytucje polegają na depozytariuszach, giełdach i dostawcach danych. Każda z tych warstw zależy od konsensusu węzłów co do stanu. Błędny state root niekoniecznie oznacza kradzież środków — może oznaczać niedokładne dowody, zatrzymaną synchronizację lub otrzymywanie przez aplikacje niespójnych danych.

Gdy mosty i usługi komunikacji międzyłańcuchowej polegają na dowodowalnym stanie, nawet krótka niespójność może wywołać ostrożnościowe zatrzymania. Te zatrzymania były reakcją defensywną, a nie skutkiem eksploatacji, ale pokazują, jak szybko pojedynczy błąd klienta może wywołać zakłócenia w całym ekosystemie.

Zdarzenie uwypukla też znaczenie różnorodności klientów — oraz jej granice. Warstwa wykonawcza Ethereum korzysta z wielu klientów, co ogranicza ryzyko systemowe w razie awarii jednego z nich. Większość sieci OP Stack współdzieli jednak op-reth. Błąd w tym wspólnym komponencie tworzy więc skorelowane ryzyko dla sieci niezależnych od siebie.

Co dalej dla Mantle i sieci OP Stack

Bezpośrednim krokiem jest wdrożenie przez operatorów. Poprawka zmniejsza ryzyko dopiero wtedy, gdy operatorzy węzłów, dostawcy RPC, walidatorzy i zespoły infrastruktury ją wdrożą, a od operatorów oczekuje się planowania aktualizacji i testowania węzłów. Blockaid zalecił protokołom i mostom zweryfikowanie, że ich dostawcy załatali swoje systemy.

W dłuższej perspektywie zdarzenie podkreśla trzy wzorce: szybsze ujawnianie i backportowanie poprawek dla linii produkcyjnych, które nie mogą aktualizować się od razu; więcej procedur awaryjnych na wypadek błędów klientów, w tym weryfikację dowodów dla komunikatów międzyłańcuchowych, gdy dowodów nie można ufać; oraz dalszą analizę współdzielonych zależności między sieciami OP Stack.

Dla Mantle testem będzie ciągłość działania. Jego fundament opiera się na skalowalności, niskich opłatach i godnym zaufania rozliczaniu dla zdecentralizowanych finansów, gier i aplikacji konsumenckich. Pozostanie online podczas błędu upstream wspiera tę propozycję, ale sieć wciąż musi wykazać, że jej linia produkcyjna pozostaje w zgodzie z poprawkami bezpieczeństwa z wersji upstream. Bezpieczeństwo blockchain to ostatecznie także oprogramowanie obliczające stan — i szybkość, z jaką jest łatane.