Bitcoin Core 32.0 увійшов у фінальний цикл тестування кандидатів на випуск після того, як розробники позначили v32.0rc1 14 вересня, наблизивши оцінку комісій, продуктивність перевірки блоків та виправлення безпеки до запланованого випуску 10 жовтня.
Підсумок
- Bitcoin Core 32.0 увійшов у тестування кандидатів на випуск 14 вересня, з фінальним тегуванням, запланованим на 10 жовтня.
- Новий оцінювач комісій поєднує історію блоків з поточними умовами mempool і може рекомендувати нижчі комісії.
- Перевірка блоків тепер попередньо вибирає попередні виходи через вісім робочих потоків за замовчуванням, зменшуючи затримки диска.
- Помилка сповіщень гаманця могла дозволити автентифікованим користувачам виконувати команди в уражених системах вузлів, крім 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 до того, як технічні деталі стали публічними.
Новий оцінювач комісій поєднує mempool та історію блоків
Одна з більш помітних змін для користувачів у Bitcoin Core 32 впливає на estimatesmartfee, RPC, який використовується гаманцями та додатками для розрахунку комісій за транзакції.
До цього часу основний оцінювач Bitcoin Core покладався на спостережувану поведінку підтвердження транзакцій, включених у минулі блоки. Версія 32 додає окремий оцінювач на основі транзакцій, які наразі очікують у mempool вузла.
Новий оцінювач mempool створює як економні, так і консервативні оцінки на основі поточних умов очікуваних транзакцій. Bitcoin Core перевіряє нещодавню активність блоків перед його використанням і може відхилити оцінку, коли mempool виглядає занадто розрідженим або нездоровим.
Коли обидві системи видають дійсні результати, estimatesmartfee повертає нижчу оцінку комісії. Таким чином, новий метод не може підвищити існуючу рекомендацію block-policy через комбінований режим за замовчуванням; його роль полягає в зниженні рекомендації, коли поточні умови mempool це підтримують.
Такий дизайн може реагувати швидше після закінчення періоду дорогого блокового простору. Оцінювач на основі історії блоків може продовжувати враховувати нещодавно підтверджені транзакції з високими комісіями, тоді як mempool може вже показувати менше транзакцій, що конкурують за підтвердження.
Програмне забезпечення зберігає можливість для застосунків використовувати попередній метод. Додана опція fee_rate_estimator дозволяє користувачам запитувати block_policy, mempool_policy або комбіновану поведінку за замовчуванням. Bitcoin Core зберігає статистику нового оцінювача mempool в окремому файлі даних, щоб їх можна було перезавантажити після перезапуску.
Розрахунки комісій гаманця використовуватимуть комбінований оцінювач за замовчуванням. Відповідь може вказати, який оцінювач створив вибрану комісію, тоді як вищі рівні деталізації розкривають статистику здоров’я mempool для застосунків, яким потрібно більше деталей.
Валідація блоків отримує паралельне попереднє завантаження з диска
Bitcoin Core 32 змінює спосіб отримання даних транзакцій вузлами під час з’єднання блоків, особливо коли потрібну інформацію необхідно зчитати зі сховища.
Програмне забезпечення тепер може попередньо завантажувати попередні виходи транзакцій, відомі як prevouts, з бази даних chainstate за допомогою кількох робочих потоків, поки валідація блоків продовжується. За замовчуванням використовується вісім потоків попереднього завантаження, причому оператори можуть збільшити налаштування до 16 або вимкнути паралельне завантаження, встановивши його на нуль.
Prevouts ідентифікують монети, які витрачаються входами транзакцій. Вузлам потрібна ця інформація, щоб перевірити, чи існують входи, чи не були вони вже витрачені та чи відповідають застосовним правилам валідації.
Покращення призначене для скорочення часу очікування на читання з диска, коли вузол обробляє блоки, що містять входи, які ще не доступні в швидших кешах пам’яті. Ефект залежатиме від апаратного забезпечення сховища, поведінки кешу та конфігурації вузла.
Bitcoin Core 32 надає доступ до налаштування через -prevoutfetchthreads=<n>, даючи операторам контроль над кількістю задіяних потоків. У чернеткових примітках цю функцію описано саме як покращення продуктивності валідації блоків.
Окремі зміни RPC надають операторам більше інформації під час фонової валідації AssumeUTXO. Після того як вузол на основі знімка досягає вершини ланцюга, getblockchaininfo тепер може повідомляти про прогрес історичної валідації ланцюга, яка все ще виконується позаду активного стану вузла.
Виправлення безпеки закривають недоліки пам’яті гаманця та HTTP
Bitcoin Core 32 виправляє недолік сповіщень гаманця, що впливає на не-Windows системи за вузького набору умов.
У чернеткових примітках зазначено, що автентифікований користувач RPC з дозволом на створення гаманців міг створити назву гаманця, яка містить спеціальні символи заміни, коли вузол було налаштовано з -walletnotify. За таких умов назва могла спричинити виконання довільних команд з привілеями процесу Bitcoin Core.
Версія 32 змінює заміну заповнювачів сповіщень гаманця, щоб назви гаманців оброблялися як буквальний текст. Випуск також посилює іменування гаманців, відхиляючи певні назви з відносними шляхами, що містять елементи шляху . або ..
Друга проблема виникла під час перегляду переписаного HTTP-сервера Bitcoin Core, який замінює libevent у версії 32.
Розробник Метью Зіпкін подав 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 буде трансльована. Перехід типового формату на версію 2 може вимагати тестування з боку програмного забезпечення, яке припускає, що вивід RPC Core використовуватиме старіший формат.
Оновлення не скасовує можливості запросити попередню версію. Застосунки, побудовані навколо відповідних команд RPC, можуть явно встановлювати формат, поки тестують сумісність із версією 2.
Інструменти для гаманців отримують інші зміни в тому самому випуску. Нова RPC exportwatchonlywallet створює файл дескрипторного гаманця, що містить публічні дескриптори, історію транзакцій і дані адресної книги без приватних ключів. Посібник Bitcoin Core з офлайн-підписування тепер використовує цю команду для створення онлайн-гаманця лише для спостереження.
Ще одна нова команда, derivehdkey, дозволяє гаманцю вивести розширений публічний або приватний ключ через шлях, що містить принаймні один укріплений крок, тоді як addhdkey дозволяє додати розширений ключ BIP32, не використовуючи його одразу для генерації вихідних скриптів.
PrivateBroadcast також продовжує отримувати підтримку. Crypto.news повідомляло в червні, що Bitcoin Core 31.1rc1 виправив мережеву умову, яка могла розкрити початкову IP-адресу під час використання PrivateBroadcast. Версія 32 містить подальші зміни RPC PrivateBroadcast і трансляції транзакцій, задокументовані в чернетці приміток до випуску.
Поточний графік Bitcoin Core усе ще вказує 10 жовтня як цільову дату для позначення v32.0. Гілка зворотного зв'язку щодо тестування RC, відкрита 15 вересня, залишається активною, і розробники скеровують тестувальників, які виявляють справжні дефекти Bitcoin Core, подавати окремі звіти до фінального випуску.
