Bitcoin Core v32.0rc1 меняет протоколы кошелька и RPC: возможны сбои в приложениях

Релиз-кандидат Bitcoin Core v32.0rc1 фактически превращает период с 14 сентября по 10 октября в сжатое окно проверки совместимости для операторов нод, провайдеров кошельков и сервисов, завязанных на RPC-интерфейсы Bitcoin Core. Тег кандидата был опубликован 14 сентября с проверенной подписью. В актуальном графике релизов финальная метка v32.0 запланирована на 10 октября, то есть интервал составляет 26 дней. В августовском превью CryptoSlate фигурировала цель по RC1 на 10 сентября, а в текущем расписании указано 14 сентября — расхождение на четыре дня, без явного подтверждения, что дедлайн "пропустили". Метка v32.0rc1 означает предрелизное ПО, а не готовое к продакшену обновление. Она также не указывает на активацию новых консенсусных правил. В рамках изменений, связанных с черновиком BIP 323, корректируется то, как Bitcoin Core трактует сигнальные биты и предупреждения о неизвестных развертываниях, при этом сам документ по-прежнему имеет статус Draft. Тестирование рекомендуется начинать по схеме из свежего руководства по RC-проверкам: прогонять часто используемые функции в отдельных временных каталогах данных и сравнивать поведение кандидата с предыдущим релизом. На официальной странице загрузок базовой версией обозначена 31.1. Такое сравнение помогает выявить различия при запуске ноды, работе кошелька и ответах RPC, не воспринимая RC как обычный продакшен-апдейт. Самое заметное изменение производительности, указанное в черновых заметках к v32, — параллельная предвыборка выходов транзакций при подключении блока. По умолчанию используется восемь воркеров, максимум — 16, функцию можно отключить. Для сценариев, где валидация упирается в диск, стоит прогнать несколько конфигураций и оценить, не оборачивается ли ускорение обработки блоков неприемлемыми затратами по CPU, памяти или задержкам хранилища на конкретном железе. Для кошельков и интеграций сервисов ключевой риск — поломка совместимости. Четыре RPC по умолчанию перейдут на PSBTv2; другие интерфейсы убирают устаревшие поля или начинают отклонять аргументы, которые старые версии ранее принимали. Командам, которые создают, конвертируют или делают feebump для PSBT, важно провести такие транзакции через все downstream-парсеры и подписанты. Отдельного внимания требует обработка комиссий и сценарии отказа. Дефолтный путь estimatesmartfee объединяет оценщики blockpolicy и mempool, может вернуть более низкую оценку и способен завершиться ошибкой при сбое любого из компонентов. Операторам стоит понаблюдать за поведением при старте и при разреженном или "нездоровом" mempool, затем проверить, что мониторинг и явные fallback-механизмы на blockpolicy работают ожидаемо. Переписывание HTTP-сервера расширяет зону тестирования за пределы самой ноды. Появляется лимит заголовков 8 192 байта, более строгая обработка некорректных заголовков, потолок по умолчанию в 16 RPC-подключений, новые настройки кэширования REST и немедленное отключение неавторизованных адресов клиентов. Эти изменения могут проявиться в обратных прокси, health-check, пулах клиентов и обработчиках ошибок. Не меньшее значение имеет и сценарий отката. Пересобранный индекс транзакций занимает менее половины прежнего места на диске, но старые релизы не умеют читать новый формат. Откат версии может запустить повторную пересборку, которая занимает часы. Операторам, ориентированным на приватность, также рекомендуется воспроизвести отказные сценарии для privatebroadcast на фоне исправления Tor fallback, очереди на 10 000 записей, лимита в 1 000 попыток и поведения ретрансляции под нагрузкой. Поскольку финальная метка пока обозначена как цель, именно такие пограничные случаи и составляют практическую работу на протяжении окна RC.