Bitcoin Core 32.0 wszedł w końcowy cykl testów kandydata do wydania po tym, jak programiści oznaczyli v32.0rc1 14 września, przybliżając szacowanie opłat, wydajność walidacji bloków i poprawki bezpieczeństwa do planowanego wydania 10 października.
Podsumowanie
- Bitcoin Core 32.0 wszedł w testy kandydata do wydania 14 września, a ostateczne oznaczenie ma nastąpić 10 października.
- Nowe szacowanie opłat łączy historię bloków z bieżącymi warunkami mempoola i może zalecać niższe opłaty.
- Walidacja bloków domyślnie pobiera teraz wstępnie poprzednie wyjścia w ośmiu wątkach roboczych, skracając oczekiwanie na dysk.
- Wada powiadomień portfela może pozwolić uwierzytelnionym użytkownikom na wykonywanie poleceń w podatnych systemach węzłów innych niż Windows.
- Testy wykazały, że szesnaście nieuwierzytelnionych połączeń REST może szybko doprowadzić do zużycia pamięci wynoszącego około trzech gigabajtów.
Oficjalne wydanie na GitHubie projektu Bitcoin Core pokazuje v32.0rc1 w commicie d0231bb, podpisane zweryfikowanym podpisem opiekuna 14 września o 12:58 UTC. Harmonogram wydań projektu nadal zakłada 10 października jako datę ostatecznego tagu v32.0, choć data ta pozostaje uzależniona od testów i dalszych poprawek.
Wersja 32 koncentruje się na zachowaniu oprogramowania węzła, interfejsach portfela, obliczaniu opłat, sieci i wydajności. Wstępne informacje o wydaniu nie wymieniają zmiany zasad konsensusu Bitcoina, co oznacza, że aktualizacja nie przedefiniowuje, które transakcje lub bloki sieć uznaje za ważne.
Bitcoin Core 32 celuje w 10 października po tagu RC1
Programiści weszli w fazę zamrożenia funkcji 20 sierpnia, ograniczając prace do poprawek potrzebnych przed wydaniem. 14 września oddzielili gałąź 32.x od głównej gałęzi rozwojowej i rozpoczęli cykl kandydatów do wydania, podczas gdy prace rozwojowe nad wersją 33 wznowiono osobno.
Pierwszy kandydat jest przeznaczony dla operatorów węzłów, deweloperów portfeli i innych użytkowników do testowania, zanim programiści zdecydują, czy kod jest gotowy na stabilne wydanie. Bitcoin Core otworzył dedykowane zgłoszenie opinii na temat testów kandydata do wydania 32.0 15 września, dzień po oznaczeniu RC1.
Projekt prosi testerów o korzystanie z przewodnika testowego do sprawdzeń specyficznych dla RC i zgłaszanie problemów z oprogramowaniem przez osobne zgłoszenia na GitHubie. Do 16 września nie wydano żadnego ostatecznego pliku binarnego v32.0.
Bitcoin Core nie aktualizuje się automatycznie. Operatorzy sami decydują, kiedy zainstalować nowe wersje, co oznacza, że starsze wydania mogą pozostać aktywne po udostępnieniu nowszego oprogramowania.
Ten model ręcznej aktualizacji miał znaczenie w poprzednich ujawnieniach dotyczących bezpieczeństwa. Jak wcześniej informował crypto.news, Bitcoin Core ujawnił CVE-2024-52911 w maju, po tym jak podatna gałąź 28.x osiągnęła koniec życia. Błąd został już naprawiony w Bitcoin Core 29.0, zanim szczegóły techniczne stały się publiczne.
Nowy estymator opłat łączy mempool i historię bloków
Jedna z bardziej widocznych zmian w Bitcoin Core 32 wpływających na użytkownika dotyczy estimatesmartfee, RPC używanego przez portfele i aplikacje do obliczania opłat transakcyjnych.
Do tej pory główny estymator Bitcoin Core opierał się na zaobserwowanym zachowaniu potwierdzeń transakcji zawartych w przeszłych blokach. Wersja 32 dodaje osobny estymator oparty na transakcjach aktualnie oczekujących w mempoolu węzła.
Nowy estymator mempoola tworzy zarówno ekonomiczne, jak i konserwatywne szacunki na podstawie bieżących warunków oczekujących transakcji. Bitcoin Core sprawdza ostatnią aktywność bloków przed jego użyciem i może odrzucić szacunek, gdy mempool wydaje się zbyt rzadki lub niezdrowy.
Gdy oba systemy dają prawidłowe wyniki, estimatesmartfee zwraca niższy szacunek opłaty. Nowa metoda nie może zatem podnieść istniejącej rekomendacji polityki blokowej poprzez połączony tryb domyślny; jej rolą jest obniżenie rekomendacji, gdy bieżące warunki mempoola na to pozwalają.
Taka konstrukcja może reagować szybciej po zakończeniu okresu drogiej przestrzeni blokowej. Estymator historii bloków może nadal uwzględniać niedawno potwierdzone transakcje o wysokich opłatach, podczas gdy mempool może już pokazywać mniej transakcji konkurujących o potwierdzenie.
Oprogramowanie zachowuje możliwość korzystania przez aplikacje z poprzedniej metody. Dodana opcja fee_rate_estimator pozwala użytkownikom wybrać block_policy, mempool_policy lub połączone zachowanie domyślne. Bitcoin Core przechowuje statystyki nowego estymatora mempoola w osobnym pliku danych, aby można je było ponownie załadować po restarcie.
Obliczenia opłat w portfelu będą korzystać z połączonego estymatora domyślnego. Odpowiedź może wskazać, który estymator wygenerował wybraną opłatę, a wyższe poziomy szczegółowości ujawniają statystyki zdrowia mempoola dla aplikacji, które potrzebują więcej szczegółów.
Walidacja bloków zyskuje równoległe wstępne pobieranie z dysku
Bitcoin Core 32 zmienia sposób, w jaki węzły pobierają dane transakcji podczas łączenia bloków, szczególnie gdy potrzebne informacje muszą być odczytane z pamięci masowej.
Oprogramowanie może teraz wstępnie pobierać poprzednie wyjścia transakcji, znane jako prevouts, z bazy danych stanu łańcucha za pomocą kilku wątków roboczych, podczas gdy walidacja bloku jest kontynuowana. Domyślnie jest osiem wątków wstępnego pobierania, a operatorzy mogą zwiększyć to ustawienie do 16 lub wyłączyć równoległe pobieranie, ustawiając je na zero.
Prevouts identyfikują monety wydawane przez wejścia transakcji. Węzły potrzebują tych informacji, aby sprawdzić, czy wejścia istnieją, nie zostały już wydane i spełniają obowiązujące reguły walidacji.
Ulepszenie ma na celu skrócenie czasu oczekiwania na odczyt z dysku, gdy węzeł przetwarza bloki zawierające wejścia, które nie są jeszcze dostępne w szybszych pamięciach podręcznych. Efekt będzie się różnić w zależności od sprzętu pamięci masowej, zachowania pamięci podręcznej i konfiguracji węzła.
Bitcoin Core 32 udostępnia to ustawienie poprzez -prevoutfetchthreads=<n>, dając operatorom kontrolę nad liczbą uczestniczących wątków. W notatkach roboczych funkcję opisano konkretnie jako ulepszenie wydajności walidacji bloków.
Oddzielne zmiany RPC dają operatorom więcej informacji podczas walidacji w tle AssumeUTXO. Gdy węzeł oparty na migawce osiągnie końcówkę łańcucha, getblockchaininfo może teraz raportować postęp walidacji historycznego łańcucha wciąż działającej za aktywnym stanem węzła.
Poprawki bezpieczeństwa zamykają luki pamięciowe w portfelu i HTTP
Bitcoin Core 32 naprawia wadę powiadomień portfela wpływającą na systemy inne niż Windows w wąskim zestawie warunków.
W notatkach roboczych stwierdzono, że uwierzytelniony użytkownik RPC z uprawnieniem do tworzenia portfeli mógł stworzyć nazwę portfela zawierającą specjalne znaki zastępcze, gdy węzeł był skonfigurowany z -walletnotify. W tych warunkach nazwa mogła spowodować wykonanie dowolnych poleceń z uprawnieniami procesu Bitcoin Core.
Wersja 32 zmienia zastępowanie symboli zastępczych w powiadomieniach portfela, tak aby nazwy portfeli były traktowane jako dosłowny tekst. Wydanie zaostrza również nazewnictwo portfeli, odrzucając pewne nazwy ścieżek względnych zawierające elementy ścieżki . lub ..
Drugi problem pojawił się podczas przeglądu przepisanego serwera HTTP Bitcoin Core, który zastępuje libevent w wersji 32.
Deweloper Matthew Zipkin przesłał pull request #36123 po tym, jak audyt z użyciem modelu Kimi K3 od Moonshot AI zidentyfikował ścieżkę wyczerpania pamięci. Gdy serwer obsługiwał jedno żądanie, mógł kontynuować odczytywanie i kolejkowanie danych wysyłanych przez to samo połączenie bez skutecznego limitu rozmiaru.
Pierwsza analiza sugerowała, że warunek wymagał głównie uwierzytelnionego klienta zdolnego do utrzymania żądania w stanie zajętości. Dalsze testy wykazały, że ruch REST tworzył podobny problem bez uwierzytelniania.
Recenzent zgłosił, że 16 nieuwierzytelnionych połączeń REST zwiększyło pamięć jednego procesu testowego z 46 MB do około 3 GB w ciągu około jednej minuty. Po poprawionej naprawie ten sam test zwiększył użycie pamięci o około 3 MB w ciągu 90 sekund, w porównaniu z 3,2 GB przed poprawką.
Poprawka została scalona 5 września, przed oznaczeniem v32.0rc1. Ponieważ przepisany serwer HTTP jest nowy w wersji 32, konkretna wada została wykryta, zanim serwer pojawił się w stabilnym wydaniu Bitcoin Core.
Użycie Kimi K3 wpisuje się w niedawny wzorzec przeglądu bezpieczeństwa wspomaganego przez AI w oprogramowaniu Bitcoin. Jak informował crypto.news w sierpniu, Bitcoin Red Team odnotował 7 958 potencjalnych ustaleń po przeskanowaniu setek projektów open source związanych z Bitcoinem, choć wiele z nich wymagało weryfikacji przez człowieka, zanim można było uznać je za potwierdzone luki w zabezpieczeniach.
Problemy z wyczerpywaniem zasobów pojawiły się w tym roku w innym oprogramowaniu Bitcoin. W powiązanej relacji crypto.news informował, że Core Lightning potwierdził luki w zabezpieczeniach po przejrzeniu raportów wygenerowanych przez AI i ostrzegł operatorów, aby zaktualizowali oprogramowanie lub tymczasowo korzystali z trybu offline.
PSBT w wersji 2 staje się domyślny dla czterech RPC
Bitcoin Core 32 zmienia domyślny format tworzony przez cztery polecenia używane z Częściowo Podpisanymi Transakcjami Bitcoin.
createpsbt, walletcreatepsbt, converttopsbt i psbtbumpfee będą domyślnie generować PSBT w wersji 2. Deweloperzy dodali opcjonalny argument psbt_version, aby aplikacje mogły w razie potrzeby jawnie zażądać innej obsługiwanej wersji.
PSBT pozwalają kilku portfelom, aplikacjom lub urządzeniom do podpisywania sprzętowego wymieniać informacje o transakcjach, zanim ukończona transakcja Bitcoin zostanie rozgłoszona. Przeniesienie domyślnego ustawienia na wersję 2 może wymagać testów przez oprogramowanie, które zakłada, że dane wyjściowe RPC Core będą używać starszego formatu.
Aktualizacja nie usuwa możliwości zażądania poprzedniej wersji. Aplikacje zbudowane wokół objętych zmianą poleceń RPC mogą jawnie ustawić format, podczas gdy testują zgodność z wersją 2.
Narzędzia portfela otrzymują inne zmiany w tym samym wydaniu. Nowe RPC exportwatchonlywallet tworzy plik portfela deskryptorowego zawierający publiczne deskryptory, historię transakcji i dane książki adresowej bez kluczy prywatnych. Samouczek Bitcoin Core dotyczący podpisywania offline używa teraz tego polecenia do tworzenia online portfela tylko do obserwacji.
Kolejne nowe polecenie, derivehdkey, pozwala portfelowi wyprowadzić rozszerzony klucz publiczny lub prywatny poprzez ścieżkę zawierającą co najmniej jeden krok wzmocniony, podczas gdy addhdkey pozwala dodać rozszerzony klucz BIP32 bez natychmiastowego używania go do generowania skryptów wyjściowych.
PrivateBroadcast również otrzymuje ciągłe utrzymanie. Crypto.news informował w czerwcu, że Bitcoin Core 31.1rc1 naprawił warunek sieciowy, który mógł ujawnić źródłowy adres IP, gdy używano PrivateBroadcast. Wersja 32 zawiera dalsze zmiany RPC PrivateBroadcast i przekazywania transakcji udokumentowane w jej wstępnych informacjach o wydaniu.
Obecny harmonogram Bitcoin Core nadal podaje 10 października jako cel oznaczenia v32.0. Wątek opinii z testów RC otwarty 15 września pozostaje aktywny, a deweloperzy kierują testerów, którzy znajdą rzeczywiste defekty Bitcoin Core, do zgłaszania osobnych problemów przed ostatecznym wydaniem.
