Bitcoin Core v32.0rc1 змінює протоколи гаманців: можливі збої в застосунках і сервісах

Вихід тестової збірки Bitcoin Core v32.0rc1 фактично відкрив вікно інтенсивної перевірки сумісності для операторів нод, провайдерів гаманців і сервісів, що покладаються на RPC-інтерфейси Bitcoin Core. Кандидат у релізи було позначено 14 вересня з перевіреним підписом. У чинному графіку релізів 10 жовтня вказано як цільову дату фінального тега v32.0 — між цими подіями минає 26 днів. У серпневому прев"ю CryptoSlate фігурувала дата 10 вересня для RC1, тоді як у поточному графіку зазначено 14 вересня. Це створює різницю в чотири дні, але саме по собі не доводить, що було пропущено незмінний дедлайн. Позначка v32.0rc1 означає передрелізне ПЗ, а не фінальне оновлення для продакшену. Також воно не сигналізує активації нових правил консенсусу. Окрема зміна, пов'язана з чернеткою BIP 323, коригує обробку сигнальних бітів і попереджень про невідомі розгортання, але сам документ зберігає статус Draft. Для тестування операторам радять користуватися підходом із найсвіжішого посібника Bitcoin Core щодо перевірки RC: відтворити типові сценарії у тимчасових каталогах даних і порівняти кандидата з попереднім релізом. На офіційній сторінці завантаження поточною базовою версією вказано 31.1. Таке порівняння допоможе зафіксувати відмінності у запуску ноди, поведінці гаманця та відповідях RPC без сприйняття RC як "звичайного" оновлення. Найпомітніша зміна продуктивності у чернетці нотаток до v32 — паралельне попереднє зчитування виходів транзакцій під час під'єднання блоку. Параметр за замовчуванням запускає вісім воркерів, підтримує до 16 і може бути вимкнений. Перевірка в режимі, обмеженому диском, із різними значеннями дозволить зрозуміти, чи прискорення обробки блоків не створює неприйнятного навантаження на CPU, пам'ять або затримки сховища на конкретному обладнанні. Окремий ризик — поломки інтеграцій гаманців і сервісів. Чотири RPC за замовчуванням перейдуть на PSBTv2, інші інтерфейси прибирають застарілі поля або починають відхиляти аргументи, які попередні версії ще приймали. Командам, що створюють, конвертують або виконують fee bump для PSBT, варто прогнати такі транзакції через усі нижчі ланки парсерів і підписувачів. Управління комісіями також потребує перевірки сценаріїв відмов. Типовий шлях estimatesmartfee тепер поєднує оцінювачі blockpolicy та mempool, може повернути нижчу оцінку і здатен завершитися помилкою, якщо будь-який із компонентів дає збій. Операторам слід спостерігати поведінку під час старту та за розрідженого або проблемного mempool, а потім переконатися, що моніторинг і явні запасні механізми через blockpolicy працюють як очікується. Переписаний HTTP-сервер розширює площу тестування за межі самої ноди. Додано ліміт заголовка 8 192 байти, жорсткішу обробку некоректних заголовків, типовий верхній поріг у 16 RPC-з'єднань, нові налаштування кешування REST і негайне від'єднання адрес клієнтів без авторизації. Це може проявитися у зворотних проксі, health check, пулах клієнтів і обробниках помилок. Питання відкату версії варте не меншої уваги. Перебудований індекс транзакцій займає менш ніж половину дискового простору, але старі релізи не читають новий формат, тож даунгрейд може запустити повторну перебудову індексу на години. Операторам, які зосереджені на приватності, варто відтворити й сценарії збоїв приватного розповсюдження навколо виправлення Tor fallback, черги на 10 000 записів, ліміту в 1 000 спроб і поведінки ретрансляції під навантаженням. Оскільки фінальний тег v32.0 залишається цільовою датою, а не гарантією, саме такі крайові кейси і є практичною роботою в межах RC-вікна.