Braiins попереджає: нові прошивки Bitmain можуть обмежувати стороннє ПЗ
Публікація джерела: 2026-09-18 · Редакційний аналіз опубліковано: 2026-09-20
Повідомлення від 18 вересня є попередженням постачальника, а не доказом проблеми в кожній моделі чи збірці. Описуємо безпечну процедуру оновлення парку, доки триває перевірка.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Що саме опублікувала Braiins
18 вересня 2026 року Braiins опублікувала коротке операційне попередження із проханням не оновлювати стокову прошивку Bitmain до найновішої версії. Компанія заявила, що окремі нещодавні заводські релізи можуть обмежувати встановлення сторонніх прошивок, і окремо порадила власникам S21, які вже працюють на Braiins OS, не повертатися на найновіший stock-образ. Braiins також повідомила, що продовжує перевірку. Це застереження постачальника альтернативної прошивки, а не бюлетень Bitmain, повний перелік уражених моделей чи доказ для кожного нового файла.
Що поки невідомо
У повідомленні немає назви файла Bitmain, часу збірки, контрольної суми, сімейства control board чи відтворюваного тесту. Не сказано, чи можливе обмеження стосується web-оновлення, SD-відновлення, сервісних інструментів, політики підписаних образів або лише конкретного шляху міграції. Також Braiins не заявляє про несправність майнінгу, пулу чи безпеки стокової прошивки. Доки немає таблиці моделей і збірок, не можна перетворювати вузьке попередження на універсальний висновок. Перед змінами запишіть точну версію та тип плати кожного пристрою: одна комерційна модель може постачатися з різними платами.
Чому незаплановане оновлення ризиковане
Оновлення прошивки ASIC — не косметична зміна. Воно може змінити перевірку завантаження, правила downgrade, зберігання конфігурації, роботу вентиляторів і температурного захисту, API та набір інструментів, які приймає плата. Якщо ферма оновить сотні пристроїв без тесту, заблоковане повернення може означати виїзд техніків, заміну плат або тривалий простій. Водночас повна відмова від усіх stock-оновлень може залишити без виправлень безпеки й стабільності. Потрібен контроль змін: сформулювати причину, очікувану користь, зберегти докази та перевірити оновлення і відновлення на репрезентативному обладнанні.
Безпечна процедура canary
Оберіть один-два некритичні майнери для кожної точної моделі, плати й поточної збірки. Експортуйте налаштування пулу та мережі, сфотографуйте етикетки, зафіксуйте ідентифікатори прошивки й базові accepted hashrate, споживання з розетки, температуру, обороти вентиляторів та rejected shares. Завантажуйте файл лише з потрібного джерела й запишіть його hash. Оновлюйте у зміну з персоналом, після чого перевірте cold boot, резервний пул, DHCP або static IP, моніторинг, тривоги й запланований rollback. Самого входу у web-панель замало. Проведіть canary через нормальний тепловий цикл і встановіть чіткі умови зупинки.
Відновлення треба тестувати окремо
Не припускайте, що файл із назвою recovery працюватиме на кожній ревізії плати. Перевірте фізичний інтерфейс, формат образу, носій, очікувану індикацію LED і чи стирається конфігурація. Зберігайте локально точні дозволені stock та альтернативні образи разом із hash і процедурою, дотримуючись ліцензій та умов виробника. Команда має вміти знайти майнер, адреса якого змінилася після reset. Якщо повернення потребує непідтримуваних обходів, невідомих unlock-утиліт або доступу неперевіреної сторони, зупиніться й ескалюйте проблему. Час відновлення потрібно включати у вікно обслуговування.
Контроль безпеки та походження
Ризик ланцюга постачання існує по обидва боки вибору. Stock-образ може змінити шляхи міграції; сторонній — додати dev fee, віддалені сервіси або непідтримувану поведінку. Використовуйте HTTPS-сторінки виробника чи документовані репозиторії, перевіряйте підписи або checksum і ведіть внутрішній запис погодження. Не приймайте архів, отриманий лише в приватному чаті без незалежно перевіреного hash. Відокремте management network від публічного доступу, змініть облікові дані після recovery та перевірте вихідні з’єднання й адреси пулів. Сумісність не доводить цілісність, а обіцянка продуктивності не замінює security review.
Як ухвалити рішення сьогодні
Якщо новий stock-реліз виправляє критичну проблему саме вашої ферми, отримайте точний changelog і запитайте Bitmain та постачальника альтернативної прошивки про цю модель і плату. Перевіряйте, а не вгадуйте. Якщо термінової причини немає, пауза масового розгортання до результатів Braiins є оборотним рішенням. Не робіть downgrade справного парку лише через допис. Для кожного оновлення потрібні відповідальний, затверджений hash файла, результат canary, доказ rollback і максимально допустима втрата хешрейту. Перегляньте рішення, коли з’являться дані за моделями або документ Bitmain.
Які докази чекати далі
Корисним продовженням буде не ще одне загальне попередження, а відтворювана таблиця: модель, control board, початкова й цільова збірки, спосіб встановлення, помилка та підписаний або захешований тестовий файл. Changelog, відповідь підтримки чи оновлена recovery-інструкція Bitmain дадуть позицію виробника. Braiins може посилити твердження точними версіями й процедурою. До того часу повідомлення має змінити обережність оновлень, але не слугує доказом навмисного lock-in. asic.tools опублікує подальше уточнення окремо й збереже точне формулювання джерела від 18 вересня.
Який запис зберегти для парку
Для кожного тестового пристрою збережіть serial number, control-board ID, прошивку до й після, SHA-256 файла, source URL, оператора, час і виміряні результати. Screenshots використовуйте лише як допоміжний доказ; текст і exported logs корисніші під час інциденту. Прив’яжіть запис до pool configuration та recovery media. Так попередження із соцмережі перетворюється на керовану інженерну реакцію, а подальше уточнення можна порівняти з власними доказами.
Джерело: Braiins ↗
Калькулятор майнінгу ↗
