Гілка Bitcoin Core 32.x перейшла до третього реліз-кандидата
Публікація джерела: 2026-10-01 · Редакційний аналіз опубліковано: 2026-10-02
Версію rc3 і оновлену документацію об’єднали 1 жовтня після 29 комітів від rc2. Операторам слід чекати підписаних офіційних бінарників і вважати кандидат тестовим ПЗ.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Гілка 32.x тепер ідентифікується як rc3
Супроводжувачі Bitcoin Core об’єднали запит на отримання 36400 1 жовтня, розширивши гілку 32.x до версії 32.0rc3. Сам запит на отримання містить три коміти: перевірку версії, відновлені сторінки посібника та відновлений приклад bitcoin.conf. Він змінив дев’ять файлів і був об’єднаний як комміт 2633a1de. Це віха підготовки до випуску в системі керування джерелами, а не оголошення про те, що остаточний випуск Bitcoin Core 32.0 доступний.
Реліз-кандидат створено для тестування
У документації життєвого циклу Bitcoin Core пояснюється, що кандидати на випуск використовують такі суфікси rc, як rc1, rc2 і rc3. Вони дають розробникам, операторам вузлів і розробникам пакетів майже остаточну збірку для тестування перед випуском стабільного основного випуску. Вищий номер rc сам по собі не означає схвалення виробництва. Це означає, що інший кандидат був підготовлений після змін або виправлень, і тестування може виявити причини для rc4 або додаткової роботи.
Гілка на 29 комітів випереджає тег rc2
Порівняння GitHub версії 32.0rc2 із гілкою 32.x показало 29 комітів під час перевірки. До них входять код, тести, документація, коригування побудови та коміти створення версії rc3. Підрахунок комітів не є мірою серйозності: невелике операційне виправлення може мати більше значення, ніж кілька оновлень документації. Операторам слід прочитати примітки до остаточного випуску та вивчити конкретні підсистеми, які вони використовують, а не робити висновок про ризик лише за кількістю.
Кандидат виконує кілька операційних налаштувань
Зміни між rc2 і поточною гілкою включають резервні варіанти оцінки комісії, очищення статистики видобутих блоків, коли стан mempool не може бути завантажений, злив зворотних викликів комісії перед збереженням стану вимкнення, формулювання, яке позначає приватну трансляцію як експериментальну, і категорію налагодження майнінгу для періодичного журналу шаблону блоку. Each change has its own scope. Розгалуження не передбачає зміни правила консенсусу, швидшого хешування або зміни в підтвердження роботи.
Зміна журналу майнінгу була перенесена окремо
Один включений комміт переміщує повідомлення ваги CreateNewBlock позаду категорії налагодження видобутку. ASIC.tools охопив цей патч окремо, оскільки часті запити шаблонів блоків можуть генерувати повторювані журнали. У контексті rc3 це просто одна резервна операційна зміна серед багатьох. Адміністраторам пулу, яким потрібен цей рядок, знадобиться відповідний параметр налагодження у випуску, який містить його; вони не повинні вважати, що кожен встановлений вузол уже змінив поведінку.
Офіційні двійкові файли rc3 ще не були в списку під час перевірки
Під час редакційної перевірки 2 жовтня офіційний індекс завантажень Bitcoin Core все ще відкривав підписаний каталог кандидатів 32.0rc2 від 22 вересня, тоді як каталог rc3 ще не був доступний. Підготовка джерела контролю зазвичай передує відтворюваним збіркам, підписам і публікації. Ця різниця в часі запобігає неправильному повідомленню об’єднаної версії як підписаного програмного забезпечення, яке можна завантажити. Доступність може змінитися пізніше, тому оператори повинні перевіряти офіційний індекс і підписи під час завантаження.
Пули повинні тестувати шляхи, які вони фактично використовують
Майнінгові пули, соло-шлюзи та сервери шаблонів повинні налаштовувати кандидатів на getblocktemplate, оцінку комісії, постійність mempool, завершення роботи та перезапуск, автентифікацію RPC, моніторинг і попередження. Тестові вузли не повинні ділитися секретами робочого гаманця. Оператори повинні зберігати порівняльні журнали та показники, перевіряти поведінку кандидатів за реалістичною частотою запитів шаблонів і підтверджувати, що програмне забезпечення Stratum або програмне забезпечення для розподілу завдань обробляє відповіді точно так, як очікувалося.
Підтвердження важливіше, ніж посилання для завантаження
Коли з’являються двійкові файли, оператори повинні використовувати офіційне місце розповсюдження Bitcoin Core, перевірити SHA256SUMS і підписи та порівняти політику підписувачів, яку використовує їхня організація. Реліз-кандидат слід спочатку встановити в ізольованому тестовому середовищі. Створення з джерела GitHub вимагає закріплення точного коміту та дотримання процесу відтворюваного збирання. Посилання, скопійоване з форуму чи дзеркала, не підтверджує, що пакет відповідає розглянутій гілці.
Що підтверджено, а що залишається в очікуванні
Підтвердженими фактами є об’єднана гілка rc3, три коміти підготовки та 29 комітів між тегом rc2 і перевіреною головою 32.x. Офіційний остаточний випуск 32.0 все ще очікував, а підписані двійкові файли rc3 ще не були видимі в перевірений час. Наступним доказом є офіційні артефакти-кандидати, атестації відтворюваної збірки, звіти тестувальників і стабільний тег. Виробничі оновлення мають відповідати цим артефактам, а не лише назві гілки.
Джерело: Bitcoin Core ↗
Калькулятор майнінгу ↗
