Bitcoin Core 32.0 wchodzi w końcową fazę przed planowanym wydaniem 10 października

Bitcoin Core 32.0 zbliża się do końca cyklu rozwoju, w którym najbardziej widoczne zmiany niekoniecznie są najciekawsze. Wersja kandydująca jest już dostępna, a deweloperzy planują wydanie ostatecznej wersji na 10 października. W programie: lepsza organizacja walidacji, przegląd serwera HTTP oraz kilka poprawek bezpieczeństwa. Audyt wspomagany przez AI uruchomił również dość pouczającą sekwencję testów: pierwsza diagnoza nie opowiedziała jeszcze całej historii.

W skrócie

• Bitcoin Core 32.0 zbliża się do wydania po kilku miesiącach rozwoju, z wersją kandydującą, która została już poddana ostatnim testom przez współpracowników.
• Walidacja bloków rozwija się pod maską dzięki równoległemu ładowaniu niektórych danych, co jest szczególnie przydatne dla operatorów uruchamiających własne węzły.
• Kimi K3 pomógł zidentyfikować słabość serwera HTTP, zanim deweloper odkrył, że scenariusz mógł dotknąć większej liczby połączeń.
• Poprawka wymagała kilku dostosowań, ponieważ jej pierwsza wersja chroniła pamięć, wprowadzając jednocześnie uciążliwą latencję w niektórych trwałych połączeniach.
• Dla zwykłego użytkownika zmiana pozostanie w dużej mierze niewidoczna, podczas gdy deweloperzy i operatorzy skorzystają głównie z lepiej chronionej i bardziej efektywnie zorganizowanej infrastruktury.

Bitcoin Core 32.0 przyspiesza przede wszystkim pracę pod maską

Bitcoin Core umożliwia komputerowi samodzielne weryfikowanie transakcji i bloków sieci, bez konieczności delegowania tego zadania na zewnętrzną usługę. Wersja 32.0 dotyczy więc głównie operatorów węzłów, deweloperów oraz usług zbudowanych wokół tej infrastruktury.

Najbardziej zauważalna zmiana wydajności dotyczy walidacji bloków. Aby zweryfikować transakcję, oprogramowanie musi przede wszystkim odnaleźć wcześniejsze wydania, które ona wydaje, znane jako prevouts. Gdy znajdują się one na dysku, ich odczyt może spowolnić pracę. Nowa wersja umożliwia równoległe wstępne ładowanie tych danych z bazy chainstate.

Domyślnie pracują osiem wątków, z maksymalnym limitem ustawionym na szesnaście. Skromniejsza maszyna może obniżyć tę liczbę do zera i dezaktywować mechanizm.

Zysk nie sprawi, że blockchain będzie szybszy i nie zmniejszy interwału między dwoma blokami. Dotyczy to pracy wykonywanej lokalnie przez węzeł. To techniczna niuans, wprawdzie dyskretna na ekranie, ale dość konkretna dla tych, którzy codziennie utrzymują infrastrukturę.

Kimi K3 identyfikuje lukę, deweloperzy drążą dalej

Historia zaczyna się od Matthew Zipkina, współpracownika znanego pod pseudonimem pinheadmz. Podczas audytu nowego serwera HTTP z Kimi K3, modelem sztucznej inteligencji również używanym przez Bitcoin Red Team, natrafił na scenariusz wyczerpania pamięci.

Serwer mógł nadal odczytywać dane wysyłane przez klienta, podczas gdy już przetwarzał żądanie. Złośliwy klient miał więc możliwość utrzymywania tego żądania zajętym, a następnie wysyłania coraz większej ilości danych. Te gromadziły się w pamięci.

Zipkin początkowo sądził, że atak wymagał autoryzacji. Jednak przegląd kodu zmienił sytuację. Deweloper jeanpablojp testuje interfejs REST i stwierdza, że 16 połączeń bez identyfikatorów może zwiększyć zużycie węzła z około 46 MB do prawie 3 GB w ciągu minuty.

AI rzeczywiście zidentyfikowała problem. Nie zakończyła jednak dochodzenia. Człowiek posunął test dalej i odkrył szerszy wektor. To znacznie ciekawsza współpraca człowiek-maszyna niż prosta rywalizacja mająca na celu ustalenie, który z nich znajdzie więcej błędów.

Pierwsza poprawka zbyt mocno spowalniała serwer

Pierwsza odpowiedź Zipkina była dość prosta: gdy żądanie jest już przetwarzane, nie ma sensu kontynuować pobierania kolejnych danych do pamięci aplikacji. Mogą one poczekać po stronie systemu, aż ciśnienie TCP naturalnie spowolni nadawcę.

Rozwiązanie tej poprawki polega na tym, aby nawet nie czytać gniazda, gdy jesteśmy zajęci przetwarzaniem żądania.

Matthew Zipkin, GitHub PR #36123

Jednak pierwsza poprawka miała wadę. Na połączeniu persistentnym, jeanpablojp mierzy medianę opóźnienia przechodzącą z około 0,14 ms do 53 ms. Poprawka chroniła pamięć, ale niepotrzebnie opóźniała niektóre żądania.

Nowa kopia, nowe testy. Po przeglądzie, 16 nieautoryzowanych połączeń REST dodaje już tylko około 3 MB w 90 sekund, w porównaniu do 3,2 GB wcześniej. Kara wynosząca około 50 ms również znika.
Twoje pierwsze kryptowaluty z Binance Ten link wykorzystuje program partnerski

Nie wszystko jest jednak za darmo. Na nieaktywnym węźle poddanym ciągłemu pipeliningowi, recenzent mierzy przepustowość przechodzącą z 383 do 18,9 żądań na sekundę. Bardzo specyficzny przypadek, którego nie znajduje u żadnego rzeczywistego klienta. Bezpieczeństwo zyskuje więc zdecydowanie, z kompromisem mierzonym, a nie ukrytym.

W październiku operatorzy znajdą przede wszystkim przydatne porządki

Wersja 32.0 nie ogranicza się tylko do tej historii pamięci. Kilka mniej spektakularnych zmian pojawi się z nią, jeśli harmonogram się utrzyma. Cztery polecenia związane z częściowo podpisanymi transakcjami będą domyślnie korzystać z PSBT v2. Aplikacje, które tego potrzebują, będą mogły nadal żądać starszej wersji.

Serwer HTTP został przepisany, aby zastąpić libevent. Stosuje surowsze zasady i domyślnie ogranicza liczbę jednocześnie podłączonych klientów HTTP do szesnastu. Inną docenianą oszczędnością jest to, że po rekonstrukcji indeks transakcji txindex zajmie mniej niż połowę swojej poprzedniej przestrzeni dyskowej.

Po stronie portfela, exportwatchonlywallet umożliwi eksportowanie informacji potrzebnych do portfela obserwacyjnego bez zabierania kluczy prywatnych.

Poprawka zamyka również lukę walletnotify. Na systemach innych niż Windows, użytkownik RPC z odpowiednimi uprawnieniami mógł tworzyć niektóre nazwy portfeli, aby wywołać wykonanie poleceń. Te nazwy są teraz traktowane dosłownie.

Dla użytkownika lekkiej aplikacji nic z tego nie zmienia dnia. Dla tych, którzy uruchamiają węzły blockchain, szczegóły mają większe znaczenie.

Do zapamiętania przed 10 października

• Wydanie Bitcoin Core 32.0 planowane jest na 10 października 2026 roku, termin ten może się zmienić w trakcie ostatnich testów wersji kandydującej.
• Walidacja będzie mogła wstępnie załadować niektóre dane z ośmioma wątkami domyślnie i maksymalnie szesnastoma, bez zmiany tempa produkcji bloków.
• Po poprawce, 16 nieautoryzowanych połączeń REST dodawało około 3 MB pamięci w 90 sekund, w porównaniu do 3,2 GB przed przeglądem.
• Cztery polecenia portfela przyjmą PSBT v2 domyślnie, podczas gdy aplikacje zachowają możliwość żądania poprzedniej wersji.
• Całkowicie odbudowany txindex zajmie mniej niż połowę przestrzeni dyskowej, podczas gdy nowy serwer HTTP otrzymuje dodatkowe zabezpieczenia.

Harmonogram oferuje zresztą ładne skrzyżowanie. Podczas gdy Bitcoin Core celuje w październik, Ethereum przygotowuje Glamsterdam, następny duży rozwój swojej blockchain. Sepolia ma przyjąć test 6 października, jeśli błędy wciąż obecne na devnets zostaną naprawione. Mainnet wciąż oczekiwany w czwartym kwartale, z grudniem wciąż możliwym. Dwa różne projekty, ta sama metoda: testować, czasami łamać, dużo poprawiać, a następnie dopiero dostarczać.