Bitcoin Core 32.0 вступил в финальный цикл тестирования кандидата на выпуск после того, как разработчики пометили тегом v32.0rc1 14 сентября, приблизив оценку комиссий, производительность проверки блоков и исправления безопасности к запланированному выпуску 10 октября.
Краткое содержание
- Bitcoin Core 32.0 вступил в тестирование кандидата на выпуск 14 сентября, финальное тегирование запланировано на 10 октября.
- Новый оценщик комиссий объединяет историю блоков с текущими условиями мемпула и может рекомендовать более низкие комиссии.
- Проверка блоков теперь по умолчанию предварительно загружает предыдущие выходы через восемь рабочих потоков, сокращая ожидание диска.
- Ошибка уведомлений кошелька могла позволить аутентифицированным пользователям выполнять команды в затронутых не-Windows системах узлов.
- Тестирование показало, что шестнадцать неаутентифицированных REST-соединений могли быстро довести использование памяти примерно до трёх гигабайт.
Официальный выпуск на GitHub проекта Bitcoin Core показывает v32.0rc1 на коммите d0231bb, подписанном проверенной подписью сопровождающего 14 сентября в 12:58 UTC. График выпуска проекта по-прежнему нацелен на 10 октября для финального тега v32.0, хотя дата остаётся предметом тестирования и дальнейших исправлений.
Версия 32 сосредоточена на поведении программного обеспечения узла, интерфейсах кошелька, расчёте комиссий, сетевом взаимодействии и производительности. Черновик примечаний к выпуску не содержит изменения правил консенсуса Bitcoin, что означает, что обновление не переопределяет, какие транзакции или блоки сеть считает действительными.
Bitcoin Core 32 нацелен на 10 октября после тега RC1
Разработчики вступили в фазу заморозки функций 20 августа, ограничив работу исправлениями, необходимыми перед выпуском. 14 сентября они отделили ветку 32.x от основной ветки разработки и начали цикл кандидата на выпуск, в то время как работа над версией 33 возобновилась отдельно.
Первый кандидат предназначен для операторов узлов, разработчиков кошельков и других пользователей для тестирования, прежде чем разработчики решат, готов ли код к стабильному выпуску. Bitcoin Core открыл специальный выпуск для обратной связи по тестированию кандидата на выпуск 32.0 15 сентября, через день после того, как RC1 был помечен тегом.
Проект просит тестировщиков использовать руководство по тестированию для проверок, специфичных для RC, и сообщать о проблемах с программным обеспечением через отдельные выпуски на GitHub. По состоянию на 16 сентября финальный бинарный файл v32.0 не выпущен.
Bitcoin Core не обновляется автоматически. Операторы выбирают, когда устанавливать новые версии, что означает, что старые выпуски могут оставаться активными после появления более нового программного обеспечения.
Эта модель ручного обновления имела значение в предыдущих раскрытиях безопасности. Как ранее сообщал crypto.news, Bitcoin Core раскрыл CVE-2024-52911 в мае после того, как уязвимая ветка 28.x достигла конца жизненного цикла. Ошибка уже была исправлена в Bitcoin Core 29.0 до того, как технические детали стали публичными.
Новый оценщик комиссий сочетает мемпул и историю блоков
Одно из более заметных изменений Bitcoin Core 32, ориентированных на пользователя, затрагивает estimatesmartfee — RPC, используемый кошельками и приложениями для расчёта комиссий за транзакции.
До сих пор основной оценщик Bitcoin Core полагался на наблюдаемое поведение подтверждения транзакций, включённых в прошлые блоки. Версия 32 добавляет отдельный оценщик, основанный на транзакциях, в настоящее время ожидающих в мемпуле узла.
Новый оценщик мемпула выдаёт как экономичные, так и консервативные оценки исходя из текущих условий ожидающих транзакций. Bitcoin Core проверяет недавнюю активность блоков перед его использованием и может отклонить оценку, когда мемпул выглядит слишком разреженным или нездоровым.
Когда обе системы выдают допустимые результаты, estimatesmartfee возвращает более низкую оценку комиссии. Таким образом, новый метод не может повысить существующую рекомендацию block-policy через комбинированный режим по умолчанию; его роль — понижать рекомендацию, когда текущие условия мемпула это поддерживают.
Такая конструкция позволяет быстрее реагировать после окончания периода дорогого блочного пространства. Оценщик на основе истории блоков может продолжать учитывать недавно подтверждённые транзакции с высокими комиссиями, в то время как мемпул уже может показывать меньше транзакций, конкурирующих за подтверждение.
Программное обеспечение сохраняет возможность для приложений использовать предыдущий метод. Добавленная опция fee_rate_estimator позволяет пользователям запрашивать block_policy, mempool_policy или комбинированное поведение по умолчанию. Bitcoin Core хранит статистику нового оценщика мемпула в отдельном файле данных, чтобы их можно было перезагрузить после перезапуска.
Расчёты комиссий в кошельке будут использовать комбинированный оценщик по умолчанию. Ответ может указать, какой оценщик выдал выбранную комиссию, а более высокие уровни детализации раскрывают статистику здоровья мемпула для приложений, которым нужны более подробные сведения.
Валидация блоков получает параллельную предвыборку с диска
Bitcoin Core 32 меняет способ извлечения данных транзакций узлами при подключении блоков, особенно когда необходимую информацию приходится читать из хранилища.
Теперь программное обеспечение может предварительно выбирать предыдущие выходы транзакций, известные как prevouts, из базы данных chainstate с помощью нескольких рабочих потоков, пока валидация блоков продолжается. По умолчанию используется восемь потоков предвыборки, при этом операторы могут увеличить настройку до 16 или отключить параллельную выборку, установив её в ноль.
Prevouts идентифицируют монеты, которые тратятся входами транзакций. Узлам нужна эта информация, чтобы проверить, существуют ли входы, не были ли они уже потрачены и удовлетворяют ли они применимым правилам валидации.
Улучшение предназначено для сокращения времени ожидания чтения с диска, когда узел обрабатывает блоки, содержащие входы, которых ещё нет в более быстрых кэшах памяти. Эффект будет зависеть от аппаратного обеспечения хранилища, поведения кэша и конфигурации узла.
Bitcoin Core 32 предоставляет настройку через -prevoutfetchthreads=<n>, давая операторам контроль над тем, сколько потоков участвует. В черновиках примечаний эта функция описывается specifically как улучшение производительности валидации блоков.
Отдельные изменения RPC дают операторам больше информации во время фоновой валидации AssumeUTXO. После того как узел на основе снимка достигает верхушки цепи, getblockchaininfo теперь может сообщать о прогрессе исторической валидации цепи, всё ещё выполняющейся за активным состоянием узла.
Исправления безопасности закрывают уязвимости памяти кошелька и HTTP
Bitcoin Core 32 исправляет ошибку уведомлений кошелька, затрагивающую не-Windows системы в узком наборе условий.
В черновиках примечаний указано, что аутентифицированный пользователь RPC с разрешением на создание кошельков мог создать имя кошелька, содержащее специальные символы замены, когда узел был настроен с -walletnotify. В этих условиях имя могло вызвать выполнение произвольных команд с привилегиями процесса Bitcoin Core.
Версия 32 изменяет замену заполнителей уведомлений кошелька так, чтобы имена кошельков рассматривались как буквальный текст. Выпуск также ужесточает именование кошельков, отклоняя определённые имена с относительными путями, содержащие элементы пути . или ..
Вторая проблема возникла во время проверки переписанного HTTP-сервера Bitcoin Core, который заменяет libevent в версии 32.
Разработчик Matthew Zipkin отправил pull request #36123 после того, как аудит с использованием модели Kimi K3 от Moonshot AI выявил путь исчерпания памяти. Пока сервер обрабатывал один запрос, он мог продолжать читать и ставить в очередь данные, отправленные тем же соединением, без эффективного ограничения размера.
Первый анализ предположил, что условие в основном требует аутентифицированного клиента, способного держать запрос занятым. Дальнейшее тестирование показало, что трафик REST создавал аналогичную проблему без аутентификации.
Рецензент сообщил, что 16 неаутентифицированных соединений REST подняли память одного тестового процесса с 46 МБ примерно до 3 ГБ примерно за одну минуту. После пересмотренного исправления тот же тест увеличил использование памяти примерно на 3 МБ за 90 секунд по сравнению с 3,2 ГБ до патча.
Патч был объединён 5 сентября, до того как был помечен v32.0rc1. Поскольку переписанный HTTP-сервер является новым для версии 32, конкретная уязвимость была обнаружена до того, как сервер появился в стабильном выпуске Bitcoin Core.
Использование Kimi K3 соответствует недавней тенденции применения ИИ для проверки безопасности в программном обеспечении Bitcoin. Как сообщал crypto.news в августе, Bitcoin Red Team зафиксировала 7 958 потенциальных находок после сканирования сотен открытых проектов, связанных с Bitcoin, хотя многие из них требовали проверки человеком, прежде чем их можно было считать подтверждёнными уязвимостями.
Проблемы исчерпания ресурсов появлялись в другом программном обеспечении Bitcoin в этом году. В связанном материале crypto.news сообщал, что Core Lightning подтвердил уязвимости безопасности после проверки отчётов, сгенерированных ИИ, и предупредил операторов о необходимости обновления или временного использования офлайн-режима.
PSBT версии 2 становится форматом по умолчанию для четырёх RPC
Bitcoin Core 32 меняет формат по умолчанию, создаваемый четырьмя командами, используемыми с частично подписанными транзакциями Bitcoin.
createpsbt, walletcreatepsbt, converttopsbt и psbtbumpfee будут по умолчанию создавать PSBT версии 2. Разработчики добавили необязательный аргумент psbt_version, чтобы приложения могли явно запросить другую поддерживаемую версию при необходимости.
PSBT позволяют нескольким кошелькам, приложениям или аппаратным устройствам подписи обмениваться информацией о транзакции до того, как завершённая транзакция Bitcoin будет broadcast. Переход формата по умолчанию на версию 2 может потребовать тестирования со стороны программного обеспечения, которое предполагает, что вывод RPC Core будет использовать старый формат.
Обновление не удаляет возможность запросить предыдущую версию. Приложения, построенные вокруг затронутых RPC-команд, могут явно задать формат, пока они тестируют совместимость с версией 2.
Инструменты для кошельков получают другие изменения в том же релизе. Новая RPC exportwatchonlywallet создаёт файл descriptor-кошелька, содержащий публичные дескрипторы, историю транзакций и данные адресной книги без приватных ключей. Руководство Bitcoin Core по офлайн-подписи теперь использует эту команду для создания онлайн watch-only кошелька.
Другая новая команда, derivehdkey, позволяет кошельку вывести расширенный публичный или приватный ключ по пути, содержащему как минимум один hardened шаг, а addhdkey позволяет добавить расширенный ключ BIP32 без немедленного использования его для генерации output scripts.
PrivateBroadcast также продолжает поддерживаться. Crypto.news сообщал в июне, что Bitcoin Core 31.1rc1 исправил сетевое условие, которое могло раскрыть исходный IP-адрес при использовании PrivateBroadcast. Версия 32 содержит дальнейшие изменения RPC PrivateBroadcast и relay транзакций, задокументированные в черновике примечаний к релизу.
Текущий график Bitcoin Core по-прежнему указывает 10 октября как целевую дату для присвоения тега v32.0. Поток отзывов о тестировании RC, открытый 15 сентября, остаётся активным, и разработчики направляют тестировщиков, обнаруживших реальные дефекты Bitcoin Core, создавать отдельные issues до финального релиза.
