Popularne portfele Bitcoin ryzykują utratę wsparcia dla nowych urządzeń sprzętowych, gdy krytyczny most bezpieczeństwa przestaje akceptować nowe urządzenia

Bitcoin HWI, powszechnie używany interfejs do łączenia oprogramowania portfela z urządzeniami do podpisywania sprzętowego, zmierza ku zakończeniu działalności, podczas gdy projekt Rust, który jego opiekun wskazał jako obiecującego następcę, jeszcze nie wykazał się gotowością do produkcji.

Opiekun interfejsu sprzętowego portfela Bitcoin Core, znanego jako HWI, powiedział 18 sierpnia, że projekt był w trybie konserwacji przez lata i w dużej mierze był indywidualnym wysiłkiem. HWI nie będzie już akceptować nowych urządzeń ani funkcji poza pracami potrzebnymi do MuSig2. Po zakończeniu tych prac, opiekun spodziewa się wydania, które prawdopodobnie będzie ostatnie dla projektu, a następnie utrzymania HWI w minimalnej konserwacji, aż do momentu, gdy odpowiedni zamiennik będzie gotowy.

HWI jest mostem, który oprogramowanie portfela może wykorzystać do odkrywania urządzenia sprzętowego, pobierania kluczy publicznych, wyświetlania adresu do odbioru i wysyłania częściowo podpisanej transakcji Bitcoin do urządzeń takich jak Ledger, Trezor, Coldcard, BitBox czy Jade w celu zatwierdzenia i podpisania. Kandydat na następcę wymieniony w ogłoszeniu, BHWI, ma na celu zachowanie stylu wyjścia poleceń HWI z implementacją w Rust.

Żaden z procesów przejścia nie jest zakończony. HWI nie jest archiwizowane, nie ustalono daty zakończenia działalności, a ogłoszenie nie mówi, że wspierane portfele sprzętowe przestaną działać lub że bitcoin użytkowników jest zagrożony. Bezpośrednia presja spoczywa na zespołach, które pakują HWI, wywołują jego linię poleceń lub polegają na nim, aby wchłonąć zmiany w urządzeniach, systemach operacyjnych i protokołach dostawców.

Dlaczego oddzielna granica HWI ma znaczenie

HWI jest zarówno biblioteką Pythona, jak i narzędziem wiersza poleceń. Daje oprogramowaniu jeden interfejs do wspólnych operacji portfela sprzętowego, zamiast wymagać osobnej implementacji dla każdego dostawcy.

Jego pierwotnym celem było wprowadzenie wsparcia dla portfeli sprzętowych do Bitcoin Core. Integracja dotarła do użytkowników poprzez granicę zewnętrznego podpisującego, a nie poprzez umieszczenie HWI wewnątrz Bitcoin Core. Dokumentacja zewnętrznego podpisującego Bitcoin Core opisuje konfigurowalne polecenie i używa HWI jako przykładu, podczas gdy przewodnik HWI dla Bitcoin Core pokazuje, jak HWI jest używane do pobierania kluczy i podpisywania transakcji obok portfela Core.

Opiekun HWI powiedział, że Python uniemożliwia deterministyczne budowy, proces budowy reprodukowalnej, który Bitcoin Core wykorzystuje do wydania binariów, a zatem uniemożliwia dołączenie HWI do Bitcoin Core. Ta separacja sprawia również, że HWI jest zasadniczo wymienne: inny program może zaimplementować kontrakt zewnętrznego podpisującego Bitcoin Core. Relacja CryptoSlate dotycząca Bitcoin Core 22.0 opisała przybycie wsparcia zewnętrznego podpisującego w 2021 roku.

Jednak kompatybilna powierzchnia poleceń to tylko jedna część migracji. Aplikacje nadal muszą pakować zamiennik, testować urządzenia i operacje, które udostępniają, oraz zdecydować, kto odpowiada za poprawki, gdy zmienia się zachowanie oprogramowania układowego lub systemu operacyjnego.

BHWI rozwiązuje problem pakowania z rdzeniem Rust zamiast aplikacji Python. Jego projekt może ułatwić reprodukowalną dystrybucję i użycie z wielu środowisk programistycznych, ale każdy projekt downstream nadal musi zweryfikować, że zamiennik obejmuje własny zestaw poleceń, matrycę urządzeń i proces wydania. Bitcoin Core może przetestować inne zgodne polecenie za swoją granicą zewnętrznego podpisującego; inne oprogramowanie, które korzysta z linii poleceń HWI, musi wykonać własną pracę nad kompatybilnością.

Ta różnica przekształca ogłoszenie o konserwacji w problem sukcesji, a nie prostą zmianę statusu repozytorium. Interfejs HWI może być współdzielony, ale jego konsumenci nie korzystają z niego ani nie dystrybuują go w ten sam sposób.

Mapa zależności pokazuje trzy rodzaje ekspozycji: bezpośrednie zależności Pythona, opakowania wokół wiersza poleceń HWI oraz projekty, które już utrzymują oddzielną implementację potomną.

Specter Desktop, koordynator portfeli Bitcoin Core, jest najjaśniejszą bezpośrednią zależnością. Opis projektu wyjaśnia jego skupienie na Bitcoin Core i portfelach sprzętowych, podczas gdy jego źródło przypisuje konkretną wersję HWI. BTCPay Server Vault podąża inną drogą: jego lokalna usługa eksponuje podłączone urządzenia podpisujące poprzez opakowanie wokół poleceń wiersza poleceń HWI. Oba wymagałyby testów integracyjnych, nawet jeśli zamiennik akceptowałby znane polecenia.

Wasabi, portfel skoncentrowany na prywatności, przedstawia przykład pakowania. W lipcu zgłoszono problem projektu, że kompilacje dla Apple Silicon zawierały wykonywalny plik HWI x86_64, co zwiększało ryzyko wykrywania urządzeń wspieranych przez HWI, enumeracji, wyświetlania adresów i podpisywania w dotkniętych kompilacjach, ponieważ poleganie na Rosetta stało się mniej wykonalne. Problem dotyczył pakowanego wykonywalnego, a nie awarii urządzeń podpisujących.

Sparrow, portfel desktopowy, pokazuje, dlaczego przejście może się fragmentować zamiast konwergować na jednym następcy. Lark rozpoczął jako port Java Pythona HWI i teraz dostarcza ścieżkę portfela sprzętowego Sparrow. Sparrow nie jest więc bezpośrednim przypadkiem migracji Pythona-HWI, ale pozostaje odpowiedzialny za oddzielną implementację pochodzącą z tego samego interfejsu.

Nowe modele sprzętowe to miejsce, w którym zamrożenie HWI może stać się widoczne. Jego macierz wsparcia obejmuje modele Ledger, Trezor, BitBox, KeepKey, Coldcard i Blockstream Jade. Możliwości różnią się w zależności od urządzenia i oprogramowania układowego, w tym typów transakcji, wyświetlania adresów i operacji zarządzania urządzeniami. Zamiennik musi odpowiadać wymaganym parom operacji urządzeń, a nie tylko reprodukować nazwy poleceń.

Luka między kodem upstream a dostępnością downstream już pojawia się w zapisach wsparcia. HWI wydało wersję 3.2.0 w lutym z obsługą BitBox02 Nova. Raport użytkownika Specter z kwietnia dotyczył konfiguracji używającej HWI 2.4.0, która nie mogła wykryć Novy. Problem Specter nie określił, czy przyczyną awarii była przypięta wersja, pakowanie, oprogramowanie układowe czy lokalne środowisko, ale chronologia pokazuje, że wsparcie upstream i dostępność downstream mogą się różnić.

Zgodnie z nową polityką HWI, dostawca lub zespół portfela, który napotyka następny nieobsługiwany model, może utrzymać fork, zbudować osobną integrację, przyjąć inny interfejs lub pozostawić tę kombinację nieobsługiwaną. To, co znika, to normalna ścieżka wprowadzenia zmiany w wspólnym projekcie upstream.

BHWI ma lidera testów, a nie przekazanie produkcji

BHWI radzi sobie z ograniczeniem architektonicznym HWI za pomocą rdzenia Rust, bez I/O, który pozostawia wybór transportu i czasu wykonania wywołującemu. Jego przestrzeń robocza obejmuje warstwy asynchroniczne, wiersza poleceń i WebAssembly, a jego pakiet wiersza poleceń buduje binarny plik hwi, który ma na celu zachowanie zgodności z wyjściem Python-HWI. Repozytorium nadal oznacza projekt jako w trakcie realizacji.

Aktualny zrzut projektu wymienia modele BitBox02, Coldcard, Jade i Ledger. Jego najsilniejsze opublikowane dowody na zgodność są węższe. Dokumentacja parytetowa BHWI opisuje testy różnicowe i końcowe bramy, które uruchamiają niezmodyfikowany zestaw urządzeń HWI 3.2.0 przeciwko BHWI dla BitBox02, Coldcard, Ledger i Jade.

Te testy zmniejszają ryzyko, że polecenie zastępcze zwróci różne wyniki dla objętych urządzeń. Nie demonstrują one jednak zachowania produkcyjnego w szerszej macierzy HWI, na każdej platformie hosta, w każdym formacie pakowania ani w pełnych przepływach portfela downstream. README BHWI i dokument parytetowy nie wymieniają również portfela, który już go wysyła jako produkcyjne zastępstwo dla HWI.

Pozostała luka jest organizacyjna, jak i techniczna. Utrzymujący HWI uzależnił archiwizację od odpowiedniego zastępstwa, podczas gdy BHWI zdefiniowało architekturę i rosnącą powierzchnię testową. Zespoły portfela muszą nadal zdecydować, czy jego objęte ścieżki urządzeń są wystarczające, jak je dystrybuować i kto będzie utrzymywał integrację, którą wysyłają.

Prawdopodobne ostateczne wydanie HWI ustanowiłoby stałą granicę upstream. Nowe urządzenie, zachowanie oprogramowania układowego lub platforma hosta mogłyby następnie wymagać łatki downstream bez normalnej ścieżki powrotnej do HWI. Projekty, które łączą Python HWI, potrzebują planów pakowania i wydania. Użytkownicy wiersza poleceń potrzebują testów zgodności dla swoich własnych wywołań. Projekty takie jak Sparrow i Lark stoją przed osobną decyzją o kontynuowaniu swojej niezależnej stosu.

Repozytorium HWI może pozostać otwarte, dopóki następca nie będzie odpowiedni, ale jego zamrożenie wkładów już obowiązuje. Ryzyko sukcesji zaczyna się, gdy nadchodzi następna zmiana zgodności, a wspólny most już jej nie akceptuje.

Niniejsza treść ma charakter wyłącznie informacyjny i nie stanowi porady finansowej, inwestycyjnej, prawnej ani podatkowej. Wszelkie wydarzenia, nagrody, promocje online lub powiązane informacje, o których tu mowa, nie powinny być traktowane jako rekomendacja, zachęta ani zaproszenie do kupna, sprzedaży, wymiany lub innego rodzaju obrotu aktywami kryptograficznymi. Aktywa kryptograficzne charakteryzują się dużą zmiennością i mogą prowadzić do strat. Dostępność usług, produktów i powiązanych wydarzeń WEEX może się różnić w zależności od regionu. Użytkownik jest odpowiedzialny za upewnienie się, że jego udział jest zgodny z obowiązującymi lokalnymi przepisami i regulacjami.