Срез рынка · ↗Курс Bitcoin$77,735Хешрейт сети936 EH/sСложность127.45 T

Прошивки и оптимизация

Core Lightning 26.06.9 устраняет уязвимости платежных узлов и задержки трафика

Публикация источника: 2026-10-07 · Редакционный анализ опубликован: 2026-10-09

В выпуске от 7 октября исправлена регрессия слухов 26.06.8, усилена защита каналов и API, а также добавлены подписанные сборки ARM. Сопровождающие рекомендуют выполнить обновление как можно скорее.

Серверное оборудование, архивная иллюстрация, не конкретный узел Core Lightning
Иллюстративное архивное фото, а не конкретное устройство или объект из новости. Преобразовано в WebP; при необходимости уменьшен размер. Dmitry Nosachev · CC BY-SA 4.0

Анализ и практические выводы

В этом разделе — наш анализ и условные расчёты, отдельно от сообщения источника.

Выпущенное обновление для уровня оплаты

Core Lightning опубликовала версию 26.06.9 на GitHub 7 октября 2026 года. Журнал изменений с пометкой датирован 6 октября. Специалисты по сопровождению рекомендуют как можно скорее установить этот точечный выпуск; он включает исправления безопасности и устраняет регрессию обработки сообщений, появившуюся в версии 26.06.8. Это программное обеспечение платежного узла, а не прошивка ASIC или изменение консенсуса Биткойн. Это различие имеет значение для майнингового бизнеса, который использует сервис Lightning наряду с его хэш-мощностью: обновление платежного сервера не меняет хешрейт майнера, настройки мощности или вознаграждение за блок.

ASIC.tools напрямую проверил версию и журнал изменений. Практический анализ, приведенный ниже, касается эксплуатации узла и окружающих его сервисов, а не обещаний увеличения доходов от майнинга. Ферма, которая получает только обычные внутрисетевые выплаты, может не иметь развертывания Core Lightning для обновления. Компания, принимающая платежи Lightning за хостинг, тепло или услуги, должна сначала определить фактическую реализацию и версию, поскольку одноименные продукты Bitcoin имеют отдельные графики выпуска и процедуры миграции.

Кабели сети Ethernet, архивная иллюстрация
Иллюстративное архивное фото, а не конкретное устройство или объект из новости. Преобразовано в WebP; при необходимости уменьшен размер. Dezlynjf · CC BY-SA 4.0

Почему занятые узлы могут задерживать сообщения

В релизе исправлен учет ресурса CPU для gossip-запросов: обычные gossip-сообщения, ping и onion-сообщения больше не расходуют предназначенный для запросов лимит. В 26.06.8 нагруженный узел мог ограничивать обработку сообщений других узлов и задерживать трафик каналов. Это конкретная регрессия обработки нагрузки, а не свидетельство остановки всех платежей Lightning или поступления блоков Bitcoin. Исправление сохраняет лимит для запросов, которые он должен контролировать.

Для операторов полезно различать тайм-аут приложения и неудачный платеж. Если касса ждет дольше, чем ожидалось, повторная попытка вслепую может создать запутанную последовательность счетов, невыполненных попыток и бухгалтерских записей. Усовершенствованная операционная проверка связывает идентификатор платежа, состояние счета и окончательный расчет, прежде чем рассматривать тайм-аут как новую продажу. После обновления сравните ту же рабочую нагрузку и интервал наблюдения: отдельные быстрые реакции сами по себе не доказывают, что самые загруженные периоды теперь обрабатываются правильно.

Закрытие канала и сроки оплаты

Журнал изменений исправляет обработку предложенного HTLC, достигшего предельного срока во время закрытия канала: узел теперь принудительно закрывает канал, защищая транзитные средства от позднего исполнения. HTLC — условный платежный контракт, а не шара ASIC, отправленная майнинговому пулу. Исправление касается взаимодействия работы канала вне блокчейна с исполнением в блокчейне. Оно не гарантирует возврата уже потерянных средств и не означает, что каждый закрытый канал был уязвим.

Учет оператора должен отражать оба уровня. Ликвидность канала не идентична подтвержденному расходуемому балансу в цепочке, и закрытие транзакции может включать комиссию за транзакцию и периоды ожидания. Для услуги майнинг-хостинга это различие влияет на рабочий баланс, доступный для оплаты электроэнергии и возмещения клиентам. Разумным оперативным ответом является сверка записей о состоянии канала и расчетах с бухгалтерской книгой приложения, а не делать вывод о платежеспособности на основе одного номера информационной панели или успешного тестового платежа.

Разрешения API заслуживают отдельного рассмотрения.

В этом выпуске ужесточается авторизация API на основе рун и маскируются некоторые конфиденциальные значения конфигурации. Журнал изменений также закрывает путь внедрения постоянной конфигурации и проверяет псевдонимы методов на соответствие соответствующим ограничениям. Это изменения в администрировании сервера; руна в этом контексте — это учетные данные авторизации, а не токен криптовалюты. Операторам следует сопоставить изменения указанных методов с учетом своих собственных интеграций, особенно если служба мониторинга или выставления счетов использует намеренно ограниченные учетные данные.

Независимо от этого конкретного патча, службе выставления счетов обычно не требуются те же привилегии, что и администратору-человеку. Отделение мониторинга только для чтения от выполнения платежей и изменений конфигурации упрощает аудит интеграции. Обновление дает возможность проверить, какой процесс хранит каждые учетные данные, где они хранятся и как они отозваны. Работоспособный экран мониторинга должен демонстрировать, что требуемые вызовы по-прежнему работают с заданными ограничениями; это не должно зависеть от незаметной замены ограниченных полномочий неограниченным доступом.

Подписанные двоичные файлы доступны для большего количества архитектур

В выпуске наряду с amd64 добавлены воспроизводимые двоичные файлы Arm64 и Armv7 для Ubuntu 22.04, 24.04 и 26.04. Каждая архитектура имеет свой собственный подписанный манифест контрольной суммы. Опубликованная процедура проверки проверяет подпись манифеста, а затем контрольные суммы файлов. Файлы, зависящие от архитектуры, важны: устройство ARM и сервер x86 не могут просто обмениваться двоичными файлами, поскольку оба работают под управлением Linux. Операторам также нужен пакет, соответствующий их методу дистрибутива и развертывания, а не выбирать только самую новую загрузку.

Контрольная сумма отвечает на вопрос, соответствуют ли загруженные байты манифесту; проверенная подпись связывает этот манифест с ключом подписи, которому вы доверяете. Обе проверки имеют цель. Сохранение точного имени артефакта, версии и результата проверки делает последующее устранение неполадок более точным, чем написание «обновлено до последней версии». Это особенно полезно, когда несколько компьютеров были установлены в разное время или когда образ контейнера и хост-пакет имеют отдельные механизмы обновления и могут фактически содержать разные версии.

Совместимость базы данных ограничивает откат

Специалисты по обслуживанию предупреждают, что узлы, на которых запущены сборки ветки разработки master, не могут перейти на версию 26.06.x из-за более новой схемы базы данных. Они также сохраняют осторожность в отношении экспериментального двойного финансирования и каналов с нулевым подтверждением от недоверенных узлов. Это не означает, что сам общедоступный выпуск является снимком разработки. Это означает, что путь обновления зависит от истории узла, поэтому работающий двоичный файл сам по себе не может определить, совместимо ли открытие существующего каталога данных.

В качестве принципа работы перед сменой программного обеспечения запишите начальную версию, источник пакета, включенные плагины и структуру хранилища. Резервные копии должны соответствовать собственным рекомендациям приложения по согласованности и восстановлению; копирование произвольных файлов активной базы данных автоматически не является действительным планом восстановления. Аналогично, восстановление старого состояния канала не эквивалентно восстановлению статического веб-сайта. Рассматривайте возможность отката операционной системы отдельно от возможности отката состояния оплаты и тестируйте процедуры обслуживания на подходящей непроизводственной установке.

Полезная приемочная проверка после технического обслуживания

Предлагаемая нами приемочная проверка фокусируется на услуге, которую фактически предоставляет узел. Убедитесь, что он достигает своего бэкэнда Биткойн, повторно подключается к ожидаемым узлам и предоставляет только намеченные интерфейсы управления. Затем проверьте контролируемый счет и его окончательное состояние с помощью того же приложения, которое используют клиенты. Просматривайте журналы ошибок, незавершенные платежи и результаты сверки в течение репрезентативного периода занятости. Это практические проверки вашего развертывания, а не показатели производительности, измеренные Core Lightning, или обещание совместимости каждого стороннего плагина.

Для фермы сохраняйте доступность платежей и доступность майнинга как разные индикаторы. Задержанный счет клиента может потребовать внимания, пока парк ASIC продолжает нормально хешировать; и наоборот, успешные платежи ничего не говорят вам о неисправности охлаждающего насоса или отклоненных шарах. Сообщение об этих двух случаях по отдельности помогает персоналу диагностировать правильную систему и позволяет избежать обвинения версии прошивки ASIC в проблеме платежного узла. Это также дает клиентам более четкое объяснение, когда период технического обслуживания влияет на платежную услугу, но оставляет размещенное оборудование для майнинга в рабочем состоянии.

Что содержит и чего не устанавливает объявление

Обновление доступно, но разработчики временно не публикуют тесты исправлений безопасности, чтобы дать операторам время установить исправления. Такой выбор публикации не является свидетельством неопубликованного будущего релиза или поводом ждать демонстрации эксплойтов. Следуйте официальным примечаниям к выпуску для принятия решений по установке и совместимости. Описательное название релиза само по себе не является доказательством того, что майнинг биткойнов или каждая транзакция Lightning получили новую гарантию квантовой безопасности; техническое поведение должно быть установлено на основе реализации и документации.

В этой статье использованы отдельные лицензированные архивные фотографии компьютерного и сетевого оборудования. Они иллюстрируют операционную среду и не показывают команду разработчиков или скомпрометированную установку. ASIC.tools будет рассматривать последующие выпуски как отдельные события после подтверждения их журналов изменений и дат публикации. Для этого выпуска немедленное решение является конкретным: определите, использует ли ваш сервис Core Lightning, просмотрите документированные изменения и выберите совместимый путь обслуживания с проверенными артефактами установки.

Источник: Core Lightning ↗ · Versioned 26.06.9 changelog ↗

Калькулятор майнинга ↗

Ещё в этой рубрике

Bitcoin Core исправляет ошибку bitcoin-cli с неограниченным таймаутом на macOS

Bitcoin Core исправляет ошибку bitcoin-cli с неограниченным таймаутом на macOS

PR №36340 принят 7 октября. Он ограничивает ожидание сокета для -rpcclienttimeout=0; наличие исправления в готовом релизе или стабильной ветке нужно проверять отдельно.

HashSmash запускает конкурс AI-криптоанализа SHA-256 и других хеш-функций

HashSmash запускает конкурс AI-криптоанализа SHA-256 и других хеш-функций

5 октября Eigen Labs и Shielded Labs запустили открытый конкурс на Yukon. Он исследует SHA-256, SHA-3, BLAKE3 и Poseidon; начало конкурса не свидетельствует о взломе хеширования Bitcoin.

Ранний доступ Braiins Price Adapt заканчивается 30 сентября: что на самом деле меняет автоматическое таргетирование мощности

Ранний доступ Braiins Price Adapt заканчивается 30 сентября: что на самом деле меняет автоматическое таргетирование мощности

Брэйнс говорит, что Price Adapt может настроить каждый поддерживаемый майнер на целевую прибыльную мощность или сократить ее, когда ожидаемый доход больше не покрывает электроэнергию. Бесплатный ранний доступ продлится до 30 сентября, а опубликованные результаты представляют собой смоделированные результаты, которые операторы должны сверить с данными своих собственных тарифов, парка и пула.