TON Core v2026.05-rc: что нового в релизе сети

25 мая 2026 команда TON выпустила релиз-кандидат TON Core v2026.05 — крупный плановый апдейт основной ноды сети. В сборке 33 merged pull request’а, и среди них есть как минимум одно изменение, которое касается всех разработчиков смарт-контрактов (TVM v14), и несколько серьёзных правок инфраструктуры, важных валидаторам.

Разберём, что внутри, и кому стоит обновляться сейчас, а кому ждать stable.

TVM v14: новая версия виртуальной машины

Главное изменение для разработчиков смарт-контрактов — апгрейд TVM (TON Virtual Machine) до версии 14. Каждый смарт-контракт на TON исполняется внутри TVM, и любое изменение её opcode-набора потенциально:

• меняет gas-расход у уже задеплоенных контрактов (обычно в меньшую сторону, но возможны нюансы);
• добавляет новые инструкции, которые компилятор может сгенерировать в новых версиях контрактов;
• закрывает старые edge-кейсы.

Конкретный список новых инструкций и изменений gas-моделей будет ясен из финального stable-тега и сопутствующей документации. До stable рекомендуется не менять gas-чувствительный код в продакшене, но прочитать changelog заранее имеет смысл — особенно если ваши контракты дорогие в исполнении.

Параллельно с Core команда выпустила Tolk 1.4.1 — минорный апдейт языка смарт-контрактов, идущего на смену FunC. Tolk и TVM эволюционируют в связке: новые TVM-инструкции часто становятся первыми точками оптимизации для Tolk-компилятора.

Чистка консенсуса: catchain больше нет

Несколько лет назад TON использовал catchain — собственный механизм консенсуса валидаторов, основанный на BFT-протоколе. С релиза Simplex он стал legacy, и в v2026.05-rc команда полностью выпиливает catchain из репозитория.

Что это значит:

• Для пользователей сети — ничего видимого. Финализация транзакций, скорость блоков, поведение валидаторов остаются прежними, потому что Simplex активен уже давно.
• Для операторов валидаторов — меньше кода в ноде, меньше путей сбоев, проще диагностика. Конфиги, связанные с catchain (если такие ещё лежат в отдельных оверрайдах), можно удалить.
• Для разработчиков ядра — окончательное закрытие большой ветки legacy-кода, на которую раньше уходили часы поддержки.

Параллельно команда улучшила обработку Simplex-слотов: “Do not treat Simplex slots unaccepted by manager as normal” — фикс граничного случая, когда менеджер отвергает слот, а нода продолжала считать его нормальным.

Сетевой стек: новые оверлеи и удаление adnl-proxy

В v2026.05-rc команда модернизировала несколько уровней сетевого стека:

Block-sync overlay. Кандидаты блоков (block candidates) теперь отправляются через выделенный block-sync оверлей, а не общий канал. Это разводит трафик: критичные для скорости финализации сообщения идут отдельно от служебных, что снижает вероятность задержек на пиках нагрузки.

Disable legacy RLDP for full-node shard inbound. RLDP — это надстройка над ADNL для надёжной доставки. Старая версия RLDP больше не используется для входящих сообщений на full-node, обрабатывающие шарды. Это движение в сторону RLDP2, которое и стало основным транспортом.

Удаление adnl-proxy. Целый компонент, позволявший проксировать ADNL-трафик через выделенные узлы, убран из репозитория. С новой сетевой архитектурой потребности в нём не осталось — пользователи получают свежие данные через стандартные ADNL-каналы.

Для обычных нод (например, лайт-серверов, обслуживающих кошельки) эти изменения — внутренние оптимизации. Для операторов нод-кластеров — повод проверить конфиги: если в них прописан adnl-proxy как часть пути, после обновления он не подхватится.

Валидаторы: cap веса сета и явный сигнал готовности

Два изменения для валидаторов:

Cap validator set total weight. Суммарный вес валидаторского сета теперь имеет верхний потолок. Раньше при определённой комбинации стейков и параметров эпохи теоретически можно было получить чрезмерную концентрацию голосования у крупного валидатора. Теперь это ограничивается на уровне протокола.

Explicit startup-readiness signaling в validator-engine. Валидатор-движок теперь явно сигнализирует о своей готовности к работе после старта. Это критично для оркестрации валидаторских кластеров (Kubernetes, systemd с зависимостями, custom-инструментов) — раньше приходилось гадать по логам, готова ли нода принимать смены валидатора.

Liteserver: get shard client state. Лайт-сервер получил новый метод для отдачи состояния шард-клиента. Полезно индексаторам и аналитическим сервисам.

Если вы оператор валидатора, эти изменения хороши для production — но в production их стоит брать только из stable тега.

Мелкие фиксы и dev-tooling

Несколько менее заметных, но полезных правок:

• Fix bad assertion in MtCarloComputeShare — фикс некорректного assert в расчёте share. Не баг-критик, но устраняет источник ложных паник на нагрузке.
• Fix wrong getOriginalFwdFee formula in docs — поправили формулу getOriginalFwdFee в документации. Разработчики смарт-контрактов: проверьте, не считаете ли вы forward-fee по старой формуле в собственных контрактах.
• Fix persistent state split part formatting — формат вывода persistent state split parts.
• Switch to clang-format-22 for linting — обновление линтера. Внешним контрибьюторам нужно будет иметь свежий clang-format локально.
• tontester: Add FullNode.fullnode_key getter — расширение тестовой инфраструктуры.
• Remove old-style BlockId formatting — старый формат вывода BlockId убран.
• Remove two CMake options — упрощение сборочной конфигурации.

Кому что делать

Когда ждать stable

Команда не публикует точной даты выхода stable v2026.05. Опираясь на ритм предыдущих релизов, обычно stable выходит в течение 1–4 недель после RC — при условии, что критических багов на тестнете не нашли. Следить удобнее на странице релизов в ton-blockchain/ton.

В контексте более крупных апгрейдов сети — Simplex, шардирование, мост-обновления — наш TON roadmap Q2-Q3 2026. Если интересует, как сейчас устроено шардирование (фундамент, на котором живёт TVM), см. материал про сharding.