Популярні гаманці Bitcoin ризикують втратити підтримку нових апаратних пристроїв, оскільки критичний міст безпеки перестає приймати нові пристрої

Bitcoin HWI, широко використовуваний інтерфейс для підключення програмного забезпечення гаманця до апаратних пристроїв підписання, наближається до завершення, тоді як проект Rust, на який посилався його куратор як на перспективну заміну, ще не продемонстрував передачу в продуктивне середовище.

Куратор інтерфейсу апаратного гаманця Bitcoin Core, або HWI, заявив 18 серпня, що проект фактично перебував у режимі обслуговування протягом багатьох років і в основному був індивідуальною ініціативою. HWI більше не прийматиме нові пристрої або функції, окрім роботи, необхідної для MuSig2. Після завершення цієї роботи куратор очікує випустити версію, яка, ймовірно, стане останньою для проекту, а потім підтримувати HWI в мінімальному режимі обслуговування, поки не буде готова відповідна заміна.

HWI є мостом, який програмне забезпечення гаманця може використовувати для виявлення апаратного пристрою, отримання публічних ключів, відображення адреси отримання та надсилання частково підписаної транзакції Bitcoin на такі пристрої, як Ledger, Trezor, Coldcard, BitBox або Jade для затвердження та підписання. Кандидат на заміну, згаданий у повідомленні, BHWI, має на меті зберегти вихід команд HWI у реалізації Rust.

Жоден з переходів не завершено. HWI не архівується, дата завершення не встановлена, і в повідомленні не сказано, що підтримувані апаратні гаманці перестануть працювати або що біткоїни користувачів під загрозою. Негайний тиск лягає на команди, які пакують HWI, викликають його командний рядок або покладаються на нього для адаптації до змін у пристроях, операційних системах і протоколах постачальників.

Чому окремий кордон HWI має значення

HWI є як бібліотекою Python, так і інструментом командного рядка. Він надає програмному забезпеченню один інтерфейс для загальних операцій з апаратними гаманцями, замість того, щоб вимагати окрему реалізацію для кожного постачальника.

Його початкова мета полягала в тому, щоб забезпечити підтримку апаратних гаманців для Bitcoin Core. Інтеграція досягла користувачів через межу зовнішнього підписувача, а не шляхом розміщення HWI всередині Bitcoin Core. Документація зовнішнього підписувача Bitcoin Core описує налаштовувану команду і використовує HWI як приклад, тоді як посібник HWI для Bitcoin Core показує, як HWI використовується для отримання ключів і підписання транзакцій разом із гаманцем Core.

Куратор HWI заявив, що Python заважає детермінованим збіркам, процесу відтворювальної збірки, який використовує Bitcoin Core для випуску бінарних файлів, і, отже, заважає HWI бути включеним до Bitcoin Core. Це розділення також робить HWI принципово замінним: інша програма може реалізувати контракт зовнішнього підписувача Bitcoin Core. Покриття CryptoSlate версії Bitcoin Core 22.0 описувало появу підтримки зовнішнього підписувача в 2021 році.

Проте сумісна командна поверхня є лише частиною міграції. Додатки все ще повинні упакувати заміну, протестувати пристрої та операції, які вони відкривають, і вирішити, хто відповідає за виправлення, коли змінюється поведінка прошивки або операційної системи.

BHWI вирішує проблему упаковки з ядром Rust, а не з додатком Python. Його дизайн може спростити відтворювальну дистрибуцію та використання з кількох середовищ програмування, але кожен проект, що працює з HWI, все ще повинен перевірити, що заміна охоплює свій власний набір команд, матрицю пристроїв і процес випуску. Bitcoin Core може протестувати іншу відповідну команду за межами свого зовнішнього підписувача; інше програмне забезпечення, яке споживає командний рядок HWI, повинно виконати свою власну роботу з сумісності.

Це розрізнення перетворює оголошення про обслуговування на проблему спадкоємності, а не просту зміну статусу репозиторію. Інтерфейс HWI може бути спільним, але його споживачі не всі використовують або розповсюджують його однаково.

Картографування показує три типи залежностей: прямі залежності Python, обгортки навколо командного рядка HWI та проекти, які вже підтримують окрему реалізацію нащадка.

Specter Desktop, координатор гаманців Bitcoin Core, є найочевиднішою прямою залежністю. Опис проекту пояснює його фокус на Bitcoin Core та апаратних гаманцях, тоді як його джерело фіксує конкретний реліз HWI. BTCPay Server Vault обирає інший шлях: його локальна служба відкриває підключені підписувальні пристрої через обгортку навколо командних запитів HWI. Обидва потребують інтеграційного тестування, навіть якщо заміна приймає знайомі команди.

Wasabi, гаманець, орієнтований на конфіденційність, представляє приклад упаковки. У липневій проблемі проекту повідомлялося, що збірки для Apple Silicon включали виконуваний файл HWI x86_64, що підвищує ризик виявлення пристроїв, що підтримуються HWI, перерахування, відображення адреси та підписування в постраждалих збірках, оскільки залежність від Rosetta стала менш надійною. Проблема стосувалася упакованого виконуваного файлу, а не збою підписувальних пристроїв.

Sparrow, настільний гаманець, показує, чому перехід може фрагментуватися, а не зосереджуватися на єдиному наступнику. Lark почався як Java-порт Python HWI і тепер постачає шлях апаратного гаманця Sparrow. Таким чином, Sparrow не є прямим випадком міграції Python-HWI, але залишається відповідальним за окрему реалізацію, що походить з того ж інтерфейсу.

Нові моделі апаратури – це місце, де заморожування HWI може стати видимим. Його матриця підтримки охоплює моделі Ledger, Trezor, BitBox, KeepKey, Coldcard та Blockstream Jade. Можливості відрізняються залежно від пристрою та прошивки, включаючи типи транзакцій, відображення адрес та операції з управління пристроями. Замінник повинен відповідати необхідним парам операцій з пристроями, а не просто відтворювати назви команд.

Розрив між upstream кодом і доступністю на downstream вже з'являється в записах підтримки. HWI випустила версію 3.2.0 у лютому з підтримкою BitBox02 Nova. У квітневому звіті користувача Specter йшлося про налаштування, що використовує HWI 2.4.0, яке не змогло виявити Nova. Проблема Specter не вказала, чи викликала невдачу закріплена версія, пакування, прошивка чи локальне середовище, але хронологія показує, що підтримка на upstream і доступність на downstream можуть розходитися.

Згідно з новою політикою HWI, постачальник або команда гаманців, що стикається з наступною непідтримуваною моделлю, може підтримувати форк, створити окрему інтеграцію, прийняти інший інтерфейс або залишити цю комбінацію непідтримуваною. Що зникає, так це нормальний шлях для внесення змін у спільний проект на upstream.

BHWI має ведучого з тестування, а не передачу в виробництво

BHWI вирішує архітектурні обмеження HWI за допомогою ядра Rust без I/O, яке залишає вибір транспорту та часу виконання для виклику. Його робочий простір включає асинхронні, командні та WebAssembly шари, а його пакет командного рядка створює бінарний файл hwi, призначений для збереження виходу, сумісного з Python-HWI. Репозиторій все ще позначає проект як такий, що знаходиться в процесі розробки.

Поточний знімок проекту перераховує моделі BitBox02, Coldcard, Jade та Ledger. Його найсильніші опубліковані докази сумісності є більш вузькими. Документація з паритету BHWI описує диференційні тести та фінальні ворота, які запускають незмінений набір пристроїв HWI 3.2.0 проти BHWI для BitBox02, Coldcard, Ledger та Jade.

Ці тести зменшують ризик того, що команда заміни повертає різні результати для охоплених пристроїв. Вони не демонструють поведінку у виробництві через ширшу матрицю HWI, кожну платформу хосту, кожен формат пакування або повні потоки гаманців на downstream. README та документ паритету BHWI також не називають гаманець, який вже постачається як виробнича заміна для HWI.

Залишковий розрив є організаційним, а також технічним. Утримувач HWI зробив архівування умовним на наявність відповідної заміни, тоді як BHWI визначив архітектуру та зростаючу поверхню тестування. Команди гаманців все ще повинні вирішити, чи достатньо їхніх охоплених шляхів пристроїв, як їх розподілити і хто буде підтримувати інтеграцію, яку вони постачають.

Ймовірний фінальний реліз HWI встановить фіксовану межу на upstream. Новий пристрій, поведінка прошивки або платформа хосту можуть вимагати патчу на downstream без нормального шляху назад у HWI. Проекти, які об'єднують Python HWI, потребують планів пакування та випуску. Споживачі командного рядка потребують тестів сумісності для своїх власних викликів. Проекти, такі як Sparrow та Lark, стикаються з окремим рішенням щодо продовження своєї незалежної стеку.

Репозиторій HWI може залишатися відкритим, поки не з'явиться відповідник, але його замороження внесків вже діє. Ризик спадкоємності починається, коли з'являється наступна зміна сумісності, і спільний міст більше не приймає її.

Цей контент надано лише для загальних інформаційних цілей і не є фінансовою, інвестиційною, юридичною чи податковою консультацією. Події, нагороди, онлайн-акцій або пов’язану інформацію, згадана тут, не слід розглядати як рекомендацію, прохання чи запрошення до купівлі, продажу, торгівлі чи інших операцій з криптоактивами. Криптоактиви є дуже волатильними та можуть призвести до збитків. Доступність послуг, продуктів WEEX та пов’язаних із ними подій може відрізнятися залежно від регіону. Ви несете відповідальність за забезпечення відповідності вашої участі чинному місцевому законодавству та нормативним актам.