Солана розкриває помилку, що може заморозити мережеві рідери

Головне за хвилину:

• Формат транзакцій Solana v1 збільшує розмір даних із 1,232 байти до 4,096 байти — зріст у 3,3 рази;
• RPC-клієнти, індексери та релеї без оновлення можуть зависати або показувати нульові бюджети без помилок;
• Оновлення активне в testnet, devnet працює з епохи 1140, mainnet досі чекає активації;
• Мінімальні версії для сумісності: @solana/kit 8.0.0, web3.js 3.0.0-rc.3, Rust 4.2.x.

Команда Octobit розібрала технічні деталі та ризики для операторів інфраструктури.

Що змінює v1 і де загроза

Формат транзакцій v1 — це не косметичний патч. Максимальний розмір даних зростає з 1,232 байтів до 4,096 байтів, що дає розробникам утричі більше місця для складних операцій. Старі формати legacy та v0 залишаються робочими, тому користувачі можуть не мігрувати негайно.

Проблема в тому, що v1 переносить ліміти compute-unit, дані завантажених акаунтів і пріоритетні комісії з інструкцій ComputeBudget у новий об’єкт transactionConfig. Якщо RPC-споживач не передає параметр maxSupportedTransactionVersion: 1, система падає. За даними xroot.dev, запит getTransaction повертає помилку -32015, getBlock ламається для всього блоку, а blockSubscribe зупиняється на першому ураженому слоті з виводом block: null.

Це не теоретична загроза. Індексери, які продовжують сканувати інструкції ComputeBudget, показують нульовий compute budget для кожної v1-транзакції без викидання помилки — тихий збій, який руйнує аналітику. Схожі кейси по інших 👉 блокчейн-мережах ми регулярно розбираємо в розділі 👉 новини альткоїнів.

Хто під ударом

RPC-клієнти та індексери — перша лінія вразливості. Якщо ви використовуєте Geyser або gRPC, є пастка: прапорець versioned у protobuf дорівнює true як для v0, так і для v1. Застарілий споживач може помилково маркувати v1 як v0 і зберігати порожній бюджет.

Рішення: регенерувати protobuf stubs і перевіряти наявність Message.config (поле 7) перед читанням прапорця. Без цього крок за кроком ви накопичуєте неправильні дані.

Релеї, paymasters та інші серверні підписанти стикаються з ризиком контролю політики. Спонсор, що обмежує комісію через сканування ComputeBudget instructions, втрачає зв’язуючий кап — ці інструкції можуть з’являтися у v1, але виконуються як no-ops. Сервери мають ідентифікувати префікс 0x81 для v1 і застосовувати ліміти з transactionConfig. За інформацією з офіційного changelog Solana, опубліковано 28 серпня 2026, це не консенсусна вразливість, але контроль застосунків може провалитися.

Onchain-програми у найгіршій позиції: жодний поточний sysvar або syscall не розкриває конфігурацію повідомлення v1. Програми, що блокують поведінку на основі інтроспекції ComputeBudget instructions, мають припинити покладатися на цю перевірку після активації v1.

Yellowstone і gRPC: окрема історія

Користувачі Yellowstone потребують щонайменше yellowstone-grpc-proto 12.6.0, geyser plugin 15.1.1, gRPC client 12.0.0 або @triton-one/yellowstone-grpc 6.0.0 — залежно від стека.

Створення v1-транзакцій опціональне, але якщо ви вирішили використовувати новий формат, потрібно:

• Встановити compute-unit і ліміти даних явно — обидва за замовчуванням дорівнюють нулю;
• Видалити no-op ComputeBudget instructions;
• Припинити використання address lookup tables;
• Застосовувати base64 для payload розміром понад 1,232 байти.

Негайний дедлайн — це не масова міграція гаманців. Це перевірка кожного сервісу, який може зіткнутися з v1-транзакцією інших користувачів.

🔮 Чого чекати далі?

Оновлення v1 розширює можливості Solana, але створює технічний розрив між підготовленими та неготовими операторами. Якщо ви запускаєте RPC-вузол, індексер або платіжний шлюз — оновлення критичне. Mainnet активація може статися без попередження, і ваш сервіс просто зависне або видаватиме порожні дані. Ризик не в консенсусі, а в інфраструктурі.