Sieć testowa połączenia Ethereum Kintsugi podzielona przez błąd, oto dlaczego

Wydarzeniem fuzji w sieci Ethereum jest przejście na model konsensusu Proof-of-Stake z aktualnie stosowanego modelu Proof-of-Work. Fuzja ta oznacza, że ​​obecny system sieci głównej Ethereum i nowy łańcuch Beacon, często określany jako Ethereum 2.0, zostaną połączone w jeden blockchain.

Aby przetestować połączenie, w grudniu wdrożono sieć testową Kintsugi. Celem sieci testowej jest uruchamianie różnych przypadków brzegowych i obserwowanie zachowania systemu. Jednym z programistów zaangażowanych w przeprowadzanie testów na Kintsugi jest Mariusa van der Wijdena, główny programista Ethereum współpracujący z zespołem klienta Geth (Go-Ethereum).

„Sieć testowa działała bezbłędnie przez kilka tygodni. W zeszłym tygodniu stworzyłem fuzzera, który wysyłał nieprawidłowe bloki. Blok zawiera wiele informacji, takich jak transakcje, hash poprzedniego bloku, limit gazu itp. – mówi Marius van der Wijden.

Niektóre implementacje nie wykonały i nie zweryfikowały bloku

Fuzzer jest powszechnym rodzajem narzędzia testowego używanego przez programistów do generowania losowych danych wejściowych do funkcji lub innych fragmentów kodu i próbowania ich zepsucia w taki czy inny sposób. Chodzi o generowanie zniekształconych i nieoczekiwanych danych wejściowych oraz obserwowanie, co dzieje się z systemem.

Fuzzer stworzony przez van der Wijden tworzy prawidłowy blok i zmienia jeden z jego elementów, aby uczynić go nieważnym. Jedną z technik, których używa, jest zmiana elementu na inny. W tym przypadku fuzzer zmienił hash blokowy na hash nadrzędny.

„Węzły powinny odrzucić tak zmieniony blok. Jednak ponieważ skrót nadrzędny wskazywał na prawidłowy blok, niektóre implementacje faktycznie nie wykonywały i nie weryfikowały bloku, ale zamiast tego szukały go w pamięci podręcznej. Ponieważ poprzedni blok był poprawny i znajdował się w pamięci podręcznej, założyli, że nowy blok jest również prawidłowy” – wyjaśnia van der Wijden.

Sieć podzielona dwukrotnie

W rezultacie połowa sieci, klienci Geth, odrzucili blokadę, podczas gdy druga połowa, klienci Nethermind i Besu, zaakceptowała go, powodując podział łańcucha, ponieważ mieliśmy teraz dwa różne widoki prawidłowego stanu. Co gorsza, była jeszcze jedna kwestia.

Według van der Wijdena, z kolei węzły łańcucha Geth, które składają się z Lighthouse-Geth, Prysm-Geth, Lodestar-Geth, Nimbus-Geth i Teku-Geth, również są rozdzielone między nimi.

„Ten podział jest nadal badany, ale wygląda na to, że Teku może również mieć jakiś mechanizm buforowania, który zawiódł”, mówi van der Wijden.

Ponieważ w chwili pisania tego tekstu istnieje kilka różnych rozwidleń sieci testowej Kintsugi i każdy węzeł myśli, że znajduje się na właściwym rozwidleniu, sieć nie jest już finalizowana.

„Wymyślimy coś, co pozwoli ponownie połączyć sieć. Zaktualizowaliśmy już klienta Nethermind i te węzły znajdują się teraz we właściwym łańcuchu. Nadal potrzebujemy poprawki do Teku, ponieważ ponad 33 procent węzłów to Teku, w przeciwnym razie łańcuch nie zostanie sfinalizowany”, mówi van der Wijden.

Incydent przynosi trochę dobrego

Według van der Wijden incydent ten nie zabrania ani nie opóźnia dalszych testów połączenia Ethereum, ani nie opóźnia samego połączenia. Van der Wijden twierdzi, że incydent faktycznie pomaga w testowaniu przypadków brzegowych, które byłyby trudne do przetestowania, gdyby sieć działała prawidłowo.

„Długie okresy braku finalizacji są wyzwaniem dla węzłów i bardzo ważne jest, abyśmy zobaczyli, jak zachowują się teraz. Uważamy, że sieć testowa w końcu znów się połączy, ale nie sądzę, abyśmy próbowali to naprawić ręcznie, ponieważ daje nam to możliwość przetestowania interesujących przypadków brzegowych”.

„Nie sądzę, żeby to opóźniło fuzję, ponieważ fuzja nie jest jeszcze zaplanowana. Ale pokazuje, jak ważne jest testowanie. Myślę, że połączenie przebiega bardzo dobrze. Potrzebujemy jeszcze kilku tygodni, aby uzyskać oprogramowanie w akceptowalnym stanie, a następnie potrzebujemy kilku miesięcy na jego przetestowanie”, mówi van der Wijden.

Co się stanie, jeśli zdarzy się to w sieci głównej?

Ciekawym pytaniem jest to, co by się stało, gdyby taki błąd wystąpił w łańcuchu głównym.

„Zaczęliśmy testować dość wcześnie, więc spodziewaliśmy się kilku takich błędów. Taki błąd w sieci mainnet byłby jednak dość nieprzyjemny, ponieważ musielibyśmy znaleźć i naprawić błąd, w czym jesteśmy całkiem dobrzy, opublikować kod, a następnie poinformować wszystkich graczy, że powinni zaktualizować swoje węzły. Ostatnia część jest moim zdaniem trudna, ponieważ niektórzy użytkownicy nie śledzą zbyt uważnie rozwoju” – mówi van der Wijden.

Po więcej szczegółów zachęcamy zainteresowanych czytelników do lektury Mariusa van der Wijdena tweety na incydencie.