R3E Network wydała neox-rs v2.7.0, nową wersję klienta pełnowęzłowego Neo X napisanego w Ruście, która scala 185 commitów z upstreamowego Reth 2.7.0, usuwa dziewięć luk wykrytych przez cargo audit oraz utwardza cykl życia walidatora generowania kluczy rozproszonych (DKG).

Jimmy Liao, główny deweloper Neo i założyciel R3E Network, ogłosił wydanie 20 października.

Od debiutu w lipcu klient przeszedł przez trzy wcześniejsze wydania: wstępną wersję przedpremierową, pierwszą stabilną wersję z poprawkami konsensusu oraz wydanie usuwające ustalenia audytu, które zamknęło 11 ustaleń. Numer wersji przeszedł z v2.5.2 od razu na v2.7.0, aby pozostać zgodnym z numeracją upstreamową Reth — konwencja ta pozwala operatorom węzłów prześledzić każdą kompilację neox-rs do dokładnego upstreamowego punktu odniesienia.

Scalanie z upstreamem Reth 2.7

Aktualizacja przenosi neox-rs na bazę kodową Reth 2.7.0, włączając 185 commitów z poprzedniego punktu odniesienia, zachowując jednocześnie warstwy protokołu specyficzne dla Neo X, w tym konsensus dBFT, szyrowanie progowe DKG, przetwarzanie kopert Anti-MEV oraz niestandardowe punkty końcowe RPC. Reth to klient wykonawczy dla Ethereum napisany w Ruście, rozwijany przez Paradigm, a regularne scalania upstreamowe tego typu pozwalają klientowi pochodnemu przejmować poprawki i ulepszenia ze swojej bazy wraz z rozwojem upstreamowej bazy kodu, zamiast od niej odbiegać.

Równolegle ze scalaniem oracle Neo X Geth został zsynchronizowany z najnowszym punktem odniesienia. Pliki genesis zarówno MainNet, jak i TestNet zostały zweryfikowane pod kątem zgodności z kanonicznymi bajtami, co zachowało hashe bloków genesis. Wydanie zawiera binaria dla Linuksa i Windows x86_64, każde opublikowane z sumami kontrolnymi SHA-256; artefakty aarch64 nie zostały zbudowane dla tego wydania.

Usuwanie luk bezpieczeństwa

Dziewięć luk wykrytych przez cargo audit zostało usuniętych poprzez aktualizacje zależności do quinn-proto 0.11.18 i rustls 0.23.46, a projekt nie raportuje obecnie żadnych znanych luk w cargo audit. Cargo audit sprawdza drzewo zależności projektu Rust względem bazy danych opublikowanych alertów, więc raport bez ustaleń oznacza, że w bieżącym zestawie zależności nie pozostały żadne znane flagi luk.

Przegląd bezpieczeństwa został przeprowadzony w ramach procesu autoryzowanego przez agenta, a nie przez niezależny audyt strony trzeciej — rozróżnienie to zostało odnotowane w wydaniu jako zarejestrowane zaakceptowanie ryzyka.

Utwardzenie cyklu życia DKG

Cztery zmiany celują w niezawodność cyklu życia walidatora DKG, adresując tryby awarii zaobserwowane podczas przedłużonych przebiegów walidacyjnych:

• Przygotowania DKG przetrwają teraz przesunięcia kanonicznej głowicy, co zapobiega wcześniej występującym stanom osieroconym.
• Odrzucone operacje Submit przywracają walidator do stanu Ready zamiast pozostawiać przygotowane zadanie osierocone.
• Dopasowywanie udziałów wykorzystuje teraz jednocześnie rundę i zagregowany klucz globalny, eliminując fałszywe błędy niezgodności epok podczas normalnego postępu bloków.
• Udziały podpisujących nie są już ponownie instalowane przy każdym bloku; system haszuje rozliczone dane wejściowe kanoniczne zamiastonicznej głowicy.

DKG to procedura kryptografii progowej, w której zestaw walidatorów wspólnie generuje materiał kluczowy tak, aby żaden pojedynczy uczestnik nie posiadał pełnego klucza — jedna z warstw specyficznych dla Neo X, którą scalanie upstreamowe musiało zachować. Te poprawki dotyczą przypadków brzegowych, w których stan DKG mógł stać się niespójny między granicami bloków — scenariuszy ujawniających się podczas długotrwałej walidacji wielorundowej.

Walidacja i testy

Kandydat do wydania został zwalidowany za pomocą bramki G8 obejmującej 1402 bloki, w zakresie wysokości od 2404 do 3805. Bramka potwierdziła postęp rund DKG z rundy pierwszej do drugiej, utrzymała identyczne 128-bajtowe zagregowane zobowiązanie przez cały czas trwania i zarejestrowała zero reorganizacji oraz zero przejściowych błędów RPC.

Odszyfrowanie kopert zostało zweryfikowane w scenariuszach zarówno w bieżącej epoce, jak i między epokami, przy czym zapisana koperta z rundy pierwszej została pomyślnie odszyfrowana i wydobyta po przejściu łańcucha do rundy drugiej. Testy odporności na błędy obejmowały 60-sekundowe opóźnienia provera, wymuszone restarty procesów oraz wymianę udziałów z brakującymi paragonami.

Wszystkie 427 testów Neo X przechodzi pomyślnie, podobnie jak czyste sprawdzenia clippy i formatowania. Potwierdzono również kompatybilność katalogu danych: katalog danych v2.7.0 i keystore DKG otworzyły się pomyślnie pod v2.5.2, a binarka wydania wczytała istniejący archiwalny katalog danych MainNet — kontrole istotne dla operatorów, ponieważ pokazują, że istniejące dane łańcucha i keystory DKG pozostają użyteczne przez granice wersji.

Perspektywy

Pełna czysta synchronizacja MainNet od genesis pozostaje w toku po wydaniu, chociaż połączenia z peer i potok nagłówków zostały zweryfikowane. Ta synchronizacja jest pozostałym kamieniem milowym do obserwowania, przy czym jej dwa warunki wstępne — łączność z peerami i pobieranie nagłówków — zostały już potwierdzone jako działające.

neox-rs nadal służy jako niezależna implementacja protokołu Neo X w Ruście, zapewniając różnorodność klientów obok klienta Neo X Geth napisanego w Go, utrzymywanego przez Bane Labs. Różnorodność klientów — uruchamianie niezależnych implementacji tego samego protokołu — to długo praktykowana zasaba odporności w sieciach blockchain, ponieważ wada ograniczona do jednej bazy kodu nie wpływa automatycznie na drugą.

Strona wydania jest dostępna pod adresem: https://github.com/R3E-Network/neox-rs/releases/tag/neox-v2.7.0