У Solana виявили баг у форматі транзакцій v1
Баг у форматі v1 може зупиняти RPC‑клієнти, індексери та релеї або показувати нульові compute‑бюджети; getTransaction повертає помилку -32015, blockSubscribe зупиняється на ураженому слоті.
Формат транзакцій v1 у Solana змінює структуру повідомлення і збільшує максимальний розмір даних із 1 232 байтів до 4 096 байтів. Офіційний changelog опубліковано 28 серпня 2026 року. Паралельно зростає спосіб передачі лімітів обчислень і пріоритетних комісій — вони тепер містяться в полі transactionConfig замість інструкцій ComputeBudget.
У кількох випадках зафіксовано технічні збої при обробці v1‑транзакцій: запити getTransaction повертають помилку -32015, getBlock може перестати обробляти блоки, а підписки через blockSubscribe зупиняються на першому слоті з v1‑транзакцією і відображають block: null. Проблеми виникають, якщо клієнт RPC не передає maxSupportedTransactionVersion: 1 або не читає нові поля повідомлення.
Першу лінію вразливості становлять індексери та RPC‑споживачі. Індексери, що продовжують читати ліміти з інструкцій ComputeBudget, можуть записувати нульові compute‑бюджети для v1‑транзакцій без помилок, що призводить до некоректних даних аналітики. При використанні Geyser або gRPC прапорець versioned у protobuf може мати значення true і для v0, і для v1, що спричиняє помилкове маркування версії і збереження порожніх полів.
Релеї, paymasters та серверні підписанти можуть втратити контроль над політикою комісій: інструкції ComputeBudget у v1 можуть бути no‑op, а реальні обмеження лімітів застосовуються з transactionConfig. On‑chain програми не отримують доступу до конфігурації v1 через поточні sysvar/syscall, тому неможливо інтерроспектувати параметри повідомлення через звичні виклики.
Для сумісності оператори рекомендують регенерувати protobuf‑stubs і перевіряти наявність поля Message.config (поле 7) перед читанням прапорця версії. Необхідно ідентифікувати префікс 0x81 як маркер v1 і застосовувати ліміти з transactionConfig. Розробникам, які створюють v1‑транзакції, потрібно явно встановлювати compute‑unit і ліміти даних, видаляти no‑op інструкції ComputeBudget, припинити використання Address Lookup Tables для сумісності та кодувати payload у base64, якщо його розмір перевищує 1 232 байти.
Мережевий статус: testnet уже працює з оновленням v1, devnet активний з епохи 1140, тоді як активація feature gates у mainnet досі перебуває в статусі pending і дата активації не оголошена. Формати legacy і v0 залишаються робочими, тому масова міграція гаманців наразі не потрібна.
Мінімальні версії SDK і інструментів для підтримки створення v1‑транзакцій зазначено так: @solana/kit 8.0.0, @solana/web3.js 3.0.0‑rc.3, Rust solana-* 4.2.x, Python solders 0.29.0, solana‑go 1.23.0. Для користувачів Yellowstone і gRPC потрібні відповідні оновлені пакети у стеку.
Матеріали на GNcrypto надаються виключно з інформаційною метою і не є фінансовою порадою. Ми намагаємось забезпечувати точність та актуальність даних, однак не можемо гарантувати їхню повну достовірність чи надійність. GNcrypto не несе відповідальності за можливі помилки, упущення або фінансові збитки, що можуть виникнути внаслідок використання цієї інформації. Усі дії ви здійснюєте на власний ризик. Завжди проводьте власне дослідження та звертайтесь до фахівців. Детальніше дивіться на наших сторiнках Умови, Політика конфіденційності та Дисклеймер.
Статті цього автора
