Релиз-кандидат Bitcoin Core v32.0rc1 превратил период с 14 сентября по 10 октября в концентрированный тест совместимости для операторов узлов, поставщиков кошельков и сервисов, зависящих от RPC-интерфейсов Bitcoin Core.
Кандидат был помечен проверенной подписью 14 сентября. График выпуска указывает 10 октября как дату финальной метки v32.0, оставляя интервал в 26 дней. Анонс CryptoSlate в августе предполагал целевую дату RC1 10 сентября, тогда как текущий график показывает 14 сентября, что создает расхождение в четыре дня без подтверждения пропущенного срока.
Метка v32.0rc1 идентифицирует предрелизное программное обеспечение, а не финальное обновление для продакшена. Она также не сигнализирует об активации новых правил консенсуса. Одно изменение, связанное с черновиком BIP 323, изменяет обработку бит-сигнализации и предупреждений о неизвестных развертываниях в Bitcoin Core, но само предложение остается в статусе черновика.
Операторы могут начать с общего подхода, описанного в последнем руководстве по тестированию RC Bitcoin Core: регулярно используйте функции в отдельных временных каталогах данных и сравните кандидата с предыдущим релизом. Официальная страница загрузки указывает 31.1 как текущую базовую версию. Такое сравнение может выявить различия в запуске узла, поведении кошелька и ответах RPC, не рассматривая кандидата как обычное обновление для продакшена.
Крупнейшее изменение производительности в черновике заметок к релизу v32 — параллельная предварительная выборка выходных данных транзакций при подключении блока. Настройка по умолчанию использует восемь рабочих процессов, поддерживает до 16 и может быть отключена. Запуск валидации с привязкой к диску при различных настройках может выявить, сопровождается ли ускоренная обработка блоков неприемлемыми затратами на ЦП, память или задержками хранения на оборудовании оператора.
Интеграции кошельков и сервисов сталкиваются с отдельным риском сбоев. Четыре RPC будут по умолчанию использовать PSBTv2, в то время как другие интерфейсы удаляют устаревшие поля или отклоняют аргументы, которые допускались старыми версиями. Поэтому команды, создающие, конвертирующие или корректирующие комиссии в PSBT, должны отслеживать эти транзакции через свои последующие парсеры и подписывающие устройства.
Обработка комиссий также требует покрытия путей отказа. Путь по умолчанию estimatesmartfee объединяет оценщики политики блоков и мемпула, может возвращать более низкую оценку и выдавать ошибку, если один из компонентов выходит из строя. Операторы должны наблюдать за запуском и условиями разреженного или нездорового мемпула, а затем подтверждать, что мониторинг и явные резервные варианты политики блоков работают ожидаемым образом.
Переработка HTTP-сервера расширяет поверхность тестирования за пределы самого узла. Она добавляет ограничение заголовка в 8192 байта, более строгую обработку некорректных заголовков, потолок в 16 RPC-соединений по умолчанию, новые элементы управления кэшем REST и немедленное отключение неавторизованных клиентских адресов. Эти изменения могут проявиться в обратных прокси, проверках работоспособности, пулах клиентов и обработчиках ошибок.
Откат заслуживает равного внимания. Перестроенный индекс транзакций использует менее половины дискового пространства, но старые релизы не могут прочитать новый формат, поэтому откат может вызвать еще одну перестройку, занимающую часы. Операторы, ориентированные на конфиденциальность, также должны воспроизвести пути отказа приватной трансляции вокруг исправления резервного канала Tor, очереди из 10 000 записей, лимита в 1000 попыток и поведения ретрансляции под нагрузкой. Поскольку финальная метка все еще является лишь целью, эти крайние случаи представляют собой практическую работу в рамках окна RC.
Всегда имейте в виду, что редакции могут придерживаться предвзятых взглядов в освещении новостей.
Автор – Liam 'Akiba' Wright
