Bitcoin Core додав категорію mining для журналу шаблонів блоків
Публікація джерела: 2026-09-29 · Редакційний аналіз опубліковано: 2026-10-01
Зміна переносить повторюваний рядок CreateNewBlock про вагу блоку під параметр -debug=mining. Код уже в master і гілці 32.x, але ще не у фінальному релізі.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Часто повторюваний рядок журналу більше не є безумовним
Супроводжувачі Bitcoin Core об’єднали запит на отримання 36336 29 вересня 2026 року. Він переміщує повідомлення ваги блоку CreateNewBlock у нову категорію налагодження майнінгу. Раніше цей рядок записувався безумовно щоразу, коли вузол створював шаблон блоку, і міг заповнювати debug.log у системах, які часто запитують шаблони. Після зміни оператори, які бажають це повідомлення, увімкнуть його за допомогою -debug=mining, тоді як установки, яким не потрібні деталі, можуть уникнути повторного входу.
Оператори пулів і шаблонів повинні переглянути параметри журналювання
У примітці до випуску спеціально рекомендовано, щоб користувачі getblocktemplate і користувачі Mining IPC увімкнули категорію майнінгу, якщо вони покладаються на ці повідомлення. Пули, шлюзи для соло-майнінгу та системи тестування часто створюють шаблони блоків набагато частіше, ніж звичайний вузол гаманця. Конфігурація, яка раніше збирала рядок автоматично, може втратити його після оновлення до версії, що містить виправлення. Перед розгортанням оператори повинні перевіряти сповіщення на основі журналу, аналізатори та процедури усунення несправностей.
У повідомленні повідомляється вага шаблону блоку
CreateNewBlock створює блоки-кандидати з поточної підказки ланцюга та mempool відповідно до політики та обмежень консенсусу. Уражене повідомлення повідомляє про вагу блоку-кандидата. Це може допомогти розробникам перевірити поведінку шаблону, але це не є доказом того, що блок було видобуто, подано чи прийнято мережею. Переміщення лінії в категорію змінює лише видимість; це не змінює вибір транзакцій, підтвердження роботи, дійсність блоку чи винагороди за майнінг.
Нова категорія відповідає елементам керування налагодженням Bitcoin Core
Bitcoin Core підтримує реєстрацію налагодження для певної категорії, щоб оператори могли вибирати підсистеми, необхідні для діагностики. За допомогою цього патча -debug=mining вмикає повідомлення шаблону блоку, тоді як звичайна конфігурація може залишатися тихішою. Точний синтаксис командного рядка або bitcoin.conf слід протестувати під час постановки, особливо там, де менеджери служб або образи контейнерів автоматично генерують аргументи. Увімкнення більшої кількості журналів також потребує відповідних обмежень на ротацію та збереження диска в довгостроковій інфраструктурі пулу.
Патч об’єднано, але не новий остаточний випуск
Зміну було об’єднано в основну гілку після перегляду та 27 автоматизованих перевірок. Менеджер також повідомив, що 30 вересня функціональну зміну було перенесено до гілки 32.x. Об’єднаний або зворотно перенесений патч — це не те саме, що остаточний пакет випуску Bitcoin Core. Операторам слід дочекатися офіційного релізу з тегами, якщо вони вже не мають контрольованого процесу створення та перевірки гілок розробки.
Існуючі аналізатори можуть потребувати явного тестування
У коментарі до огляду зазначено, що під час пошуку синтаксичних аналізаторів точної вагової лінії CreateNewBlock не знайдено жодних вартих уваги зовнішніх проектів, але відсутність загальнодоступного пошуку не стосується інструментів приватного пулу. Перед оновленням команди повинні шукати цю фразу у своїх власних правилах моніторингу, журналах відправників і на інформаційних панелях. Безпечний тест генерує повторні запити getblocktemplate з і без -debug=mining, підтверджує очікувану поведінку повідомлення та перевіряє, чи не пов’язані журнали помилок залишаються видимими.
Більш тихі журнали зменшують шум зберігання та сигналу
Для служби шаблонів із високою частотою безумовний рядок може створити непотрібні записи на диск і ускладнити пошук важливих попереджень. Стробування за категоріями дозволяє оператору вибирати між детальною діагностикою майнінгу та меншим загальним журналом. Перевага є операційною, а не хешрейтом або підвищенням ефективності: це не робить ASIC швидшим і не зменшує його електричне навантаження. Однак це може покращити збереження журналів і спростити перегляд інцидентів на вузлах, що підтримують пул майнінгу.
Не відключайте діагностичні дані без заміни
Якщо пул використовує тренди ваги шаблону для виявлення незвичайних умов mempool або регресії блок-асамблеї, він повинен зберегти категорію видобутку або збирати еквівалентні показники з перевіреного інтерфейсу. Журнали також слід ротувати, позначати часом і відправляти в сховище розміром для очікуваної кількості запитів. Правильне налаштування залежить від мети системи: легкий вузол може надавати перевагу мінімальному виводу, тоді як виробничий пул може цінувати повну діагностику шаблону під час оновлення.
Наступна контрольна точка – офіційний випуск
Перевірені факти вузькі: запит на отримання було об’єднано, повідомлення переміщено за категорію майнінгу, примітка до випуску попереджає користувачів getblocktemplate та Майнінг IPC, а код було перенесено до 32.x. Остаточний номер версії та дата випуску не встановлюються цим запитом на отримання. Операторам слід прочитати офіційні примітки до випуску та підписані двійкові файли, коли з’явиться наступний випуск, а потім перевірити свою точну конфігурацію журналювання перед розгортанням виробництва.
Джерело: Bitcoin Core ↗
Калькулятор майнінгу ↗
