Bitcoin Core додав bestblockhash у getmininginfo проти гонок шаблонів
Публікація джерела: 2026-09-14 · Редакційний аналіз опубліковано: 2026-09-19
Злитий патч дає майнінговому ПЗ хеш вершини й дані наступної цілі в одному узгодженому RPC-знімку.
Аналіз і практичні висновки
У цьому розділі — наш аналіз та умовні розрахунки, окремо від повідомлення джерела.
Що саме злили
Pull request Bitcoin Core #36081 злили в master 14 вересня 2026 року. Він додає поле bestblockhash до відповіді RPC getmininginfo. Майнінгове ПЗ уже могло читати наступну висоту, nBits і target з об’єкта next; тепер воно також знатиме точну вершину ланцюга, з якої ці значення отримані. Це злитий код розробки, а не доказ, що поле вже є на кожному розгорнутому вузлі.
两次 RPC 的竞态
Раніше ПЗ, якому потрібні і хеш вершини, і ціль наступного блока, часто викликало getmininginfo, а потім getbestblockhash чи getblockchaininfo. Між запитами вершина могла змінитися, тож пара поєднувала хеш одного tip із target іншого. Автор особливо вказав на реорганізації однакової висоти біля межі retarget, де конкурентні вершини можуть означати різний next nBits. Рідкісний сценарій не є нешкідливим, якщо значення входить у шаблон блока.
Чому один знімок безпечніший
Повернення пов’язаних полів під одним внутрішнім блокуванням стану ланцюга дає узгоджений знімок. Хеш стає маркером версії: ПЗ може пов’язати next-target із конкретною вершиною та виявити застарівання після появи нової. Це не скасовує реорганізації й не замінює getblocktemplate. Патч прибирає одну уникненну неузгодженість на межі RPC і спрощує перевірку стану пулом.
部署不会立即生效
Злиття в master потрапляє до лінії розробки. Оператори мають перевірити, у який реліз увійде commit і чи зробив дистрибутив backport. Клієнтам варто визначати наявність bestblockhash, а не припускати її, особливо в змішаному парку вузлів. Безпечний rollout зберігає старий fallback із двох викликів та перевіркою узгодженості, тестує parser на записаних відповідях і оновлює моніторинг до використання поля у production.
矿池开发者的测试
Протестуйте звичайну зміну tip, реорганізацію тієї самої висоти, межу retarget і перезапуск вузла. Кешовані шаблони мають скидатися при зміні bestblockhash, навіть якщо висота не змінилася. Відсутній чи неправильний хеш слід обробити без падіння, записуючи версію вузла і доступність поля. Якщо пул має кілька вузлів, failover не повинен змішувати їхні знімки. Метрики мають рахувати stale responses і fallback до того, як зросте rejected work.
实际意义
Патч малий, але дотримується важливого правила: дані, які тлумачаться разом, мають повертатися зі спільним контекстом версії. Пул не отримає додаткового хешрейту, однак зменшить вузький клас гонок стану шаблону й покращить діагностику. Слідкуйте за майбутнім релізом, поетапно додавайте підтримку клієнта і не прибирайте наявні перевірки. GitHub pull request є авторитетним записом статусу, review та історії commit.
Джерело: Bitcoin Core ↗
Калькулятор майнінгу ↗
