Bitcoin HWI, широко используемый интерфейс для подключения кошельков к аппаратным подписывающим устройствам, готовится к уходу на покой. При этом Rust-проект, который его мейнтейнер назвал многообещающей заменой, пока не продемонстрировал готовности к промышленной эксплуатации.
Мейнтейнер интерфейса аппаратных кошельков (Hardware Wallet Interface, HWI) для Bitcoin Core сообщил 18 августа, что проект фактически находился в режиме поддержки в течение нескольких лет и в основном был сольной работой. HWI больше не будет принимать новые устройства или функции, за исключением работ, необходимых для MuSig2. После завершения этих работ мейнтейнер планирует выпустить релиз, который, вероятно, станет последним, а затем перевести HWI в режим минимальной поддержки, пока не будет готова подходящая замена.
HWI — это мост, который программное обеспечение кошелька может использовать для обнаружения аппаратного устройства, получения открытых ключей, отображения адреса для получения и отправки частично подписанной биткоин-транзакции на такие устройства, как Ledger, Trezor, Coldcard, BitBox или Jade, для утверждения и подписи. Кандидат на замену, упомянутый в уведомлении, BHWI, нацелен на сохранение стиля вывода команд HWI с помощью реализации на Rust.
Ни один из переходов не завершён. HWI не архивирован, дата прекращения поддержки не установлена, и в уведомлении не говорится, что поддерживаемые аппаратные кошельки перестанут работать или что биткоины пользователей находятся под угрозой. Непосредственное давление ложится на команды, которые упаковывают HWI, вызывают его из командной строки или полагаются на него для адаптации к изменениям в устройствах, операционных системах и протоколах вендоров.
Почему важна отдельная граница HWI
HWI — это одновременно библиотека Python и инструмент командной строки. Он предоставляет программному обеспечению единый интерфейс для стандартных операций с аппаратными кошельками вместо необходимости отдельной реализации для каждого вендора.
Его первоначальной целью была поддержка аппаратных кошельков в Bitcoin Core. Интеграция была доведена до пользователей через границу внешнего подписанта, а не путём размещения HWI внутри Bitcoin Core. Документация по внешнему подписанту Bitcoin Core описывает настраиваемую команду и использует HWI в качестве примера, а руководство по Bitcoin Core от HWI показывает, как HWI используется для получения ключей и подписания транзакций вместе с кошельком Core.
Мейнтейнер HWI заявил, что Python препятствует детерминированной сборке — воспроизводимому процессу сборки, который Bitcoin Core использует для бинарных релизов, и поэтому не позволяет поставлять HWI вместе с Bitcoin Core. Это разделение также делает HWI в принципе заменяемым: другая программа может реализовать контракт внешнего подписанта Bitcoin Core. Материал CryptoSlate о Bitcoin Core 22.0 описывал появление поддержки внешнего подписанта в 2021 году.
Однако совместимая поверхность команд — это лишь одна часть миграции. Приложениям всё ещё нужно упаковать замену, протестировать устройства и операции, которые они предоставляют, и решить, кто будет исправлять ошибки при изменении прошивки или поведения операционной системы.
BHWI решает проблему упаковки с помощью ядра на Rust вместо приложения на Python. Его архитектура может упростить воспроизводимое распространение и использование из нескольких сред программирования, но каждый нижестоящий проект всё равно должен проверить, что замена покрывает его собственный набор команд, матрицу устройств и процесс релиза. Bitcoin Core может протестировать другую соответствующую команду за своей границей внешнего подписанта; другое программное обеспечение, использующее командную строку HWI, должно выполнить свою собственную работу по обеспечению совместимости.
Это различие превращает объявление о поддержке в проблему преемственности, а не просто в изменение статуса репозитория. Интерфейс HWI может быть общим, но его потребители не все используют или распространяют его одинаково.
Карта нижестоящих проектов показывает три типа воздействия: прямые зависимости от Python, обёртки вокруг командной строки HWI и проекты, которые уже поддерживают отдельную производную реализацию.
| Проект или путь | Как работает мост к аппаратному кошельку | Нагрузка при переходе |
|---|---|---|
| Внешний подписант Bitcoin Core | HWI — это документированный пример для отдельной команды подписанта | Проверить замену на соответствие командному контракту Core и потокам кошелька |
| Specter Desktop | В его файле зависимостей зафиксирован HWI 3.1.0 | Переупаковать замену и заново протестировать обнаружение, отображение адресов и подписание |
| Wasabi Wallet | В его документации по совместимости поддержка аппаратных кошельков привязана к HWI | Заменить или поддерживать исполняемый файл на всех поддерживаемых платформах |
| BTCPay Server Vault | BTCPayServer.Hwi оборачивает командную строку HWI | Адаптировать обёртку и подтвердить, что локальный мост к устройству сохраняет поведение |
| Sparrow Wallet | В его текущем файле Hwi.java вызывается Lark, а не Python HWI | Продолжить поддержку отдельного стека устройств вместо прямой замены Python-HWI |
Specter Desktop, координатор кошельков Bitcoin Core, является наиболее очевидной прямой зависимостью. В его описании проекта объясняется его фокус на Bitcoin Core и аппаратных кошельках, а в исходном коде зафиксирован конкретный релиз HWI. BTCPay Server Vault выбирает другой путь: его локальный сервис предоставляет доступ к подключённым подписывающим устройствам через обёртку вокруг запросов командной строки HWI. Обоим потребуется интеграционное тестирование, даже если замена будет принимать знакомые команды.
Wasabi, приватный кошелек, демонстрирует пример упаковки. В июльском issue проекта сообщалось, что сборки для Apple Silicon включали исполняемый файл HWI для x86_64, что создавало риск для обнаружения устройств, перечисления, отображения адресов и подписания на базе HWI в затронутых сборках, поскольку полагаться на Rosetta стало менее оправданно. Проблема касалась упакованного исполняемого файла, а не сбоя подписывающих устройств.
Sparrow, десктопный кошелёк, показывает, почему переход может привести к фрагментации вместо конвергенции к единой замене. Lark начинался как Java-порт Python HWI и теперь обеспечивает путь к аппаратному кошельку Sparrow. Таким образом, Sparrow не является прямым случаем миграции с Python HWI, но он остаётся ответственным за отдельную реализацию, происходящую от того же интерфейса.
Новые модели оборудования — это то, где заморозка HWI может стать заметной. Его матрица поддержки охватывает модели Ledger, Trezor, BitBox, KeepKey, Coldcard и Blockstream Jade. Возможности различаются в зависимости от устройства и прошивки, включая типы транзакций, отображение адресов и операции управления устройством. Замена должна соответствовать требуемым парам устройство-операция, а не просто воспроизводить названия команд.
Разрыв между исходным кодом и доступностью у нижестоящих проектов уже проявляется в записях поддержки. HWI выпустил версию 3.2.0 в феврале с поддержкой BitBox02 Nova. В апрельском отчёте пользователя Specter описывалась настройка с использованием HWI 2.4.0, которая не могла обнаружить Nova. В issue Specter не было определено, стала ли причиной сбоя зафиксированная версия, упаковка, прошивка или локальное окружение, но хронология показывает, что поддержка в исходном коде и доступность у нижестоящих проектов могут расходиться.
В рамках новой политики HWI вендор или команда кошелька, столкнувшись со следующей неподдерживаемой моделью, могут поддерживать форк, создать отдельную интеграцию, принять другой интерфейс или оставить эту комбинацию без поддержки. Исчезает обычный путь для внесения изменений в общий вышестоящий проект.
BHWI лидирует в тестировании, но не в промышленной эксплуатации
BHWI решает архитектурное ограничение HWI с помощью ядра на Rust без ввода-вывода, которое оставляет выбор транспорта и среды выполнения вызывающему коду. Его рабочее пространство включает асинхронный, командный и WebAssembly-слои, а его пакет командной строки собирает бинарный файл hwi, предназначенный для сохранения вывода, совместимого с Python HWI. Репозиторий по-прежнему помечает проект как находящийся в разработке.
Текущий срез проекта перечисляет модели BitBox02, Coldcard, Jade и Ledger. Самые веские опубликованные доказательства совместимости уже. Документация по паритету BHWI описывает дифференциальные тесты и финальные шлюзы, которые запускают неизменённый набор устройств HWI 3.2.0 против BHWI для BitBox02, Coldcard, Ledger и Jade.
Эти тесты снижают риск того, что команда замены вернёт другие результаты для охваченных устройств. Однако они не демонстрируют производственное поведение во всей более широкой матрице HWI, на каждой хост-платформе, в каждом формате упаковки или в полных потоках нижестоящих кошельков. README и документ о паритете BHWI также не называют кошелёк, который уже поставляет его в качестве промышленной замены HWI.
Оставшийся разрыв является как организационным, так и техническим. Мейнтейнер HWI сделал архивацию зависимой от подходящей замены, в то время как BHWI определил архитектуру и растущую поверхность тестирования. Командам кошельков всё ещё нужно решить, достаточны ли охваченные пути устройств, как распространять BHWI и кто будет поддерживать интеграцию, которую они поставляют.
Вероятный финальный релиз HWI установит фиксированную вышестоящую границу. Новое устройство, поведение прошивки или хост-платформа могут затем потребовать патча от нижестоящих разработчиков без обычного пути обратно в HWI. Проекты, которые включают Python HWI, нуждаются в планах упаковки и релиза. Потребители командной строки нуждаются в тестах совместимости для своих собственных вызовов. Проекты, такие как Sparrow и Lark, стоят перед отдельным решением о продолжении своего независимого стека.
Репозиторий HWI может оставаться открытым, пока не появится подходящий преемник, но заморозка изменений уже вступила в силу. Риск преемственности начинается тогда, когда приходит следующее изменение совместимости, а общий мост больше его не принимает.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
