Перевірка сумісності перед переходом на новий формат транзакцій Solana v1 обсягом 4096 байт

Новий формат транзакцій v1 для Solana (SOL) проходить перевірку сумісності інфраструктури перед активацією основної мережі. Зміна полягає в збільшенні максимальної величини однієї транзакції з 1232 байт до 4096 байт, але основна проблема полягає в тому, чи зможуть RPC, індексатори, gRPC та спонсори комісій правильно обробити новий формат, а не в згоді ланцюга.

Фонд Solana повідомив на сторінці оновлення мережі, що Agave 4.2 вже активовано в основній мережі, але функція "Більші розміри транзакцій" наразі чекає активації до 4 вересня 2026 року. Ця функція передбачає збільшення існуючих лімітів транзакцій приблизно в 3,3 рази через новий формат v1.

Ця зміна не є простою зміною розміру. SIMD-0296 та SIMD-0385 були представлені на основі великих мульти-підписів, доказів нульового знання (ZK proof) та пакетних передач. У v1 зменшується залежність від таблиці адрес, яка використовувалася в попередніх транзакціях, а інформація про комісії та обмеження ресурсів переноситься в окрему налаштування transactionConfig.

Старий спосіб читання системи може стати проблемою на цьому етапі. Якщо індексатор та спонсор комісій лише переглянуть інструкцію ComputeBudget, щоб спочатку розрахувати комісію або ліміт обчислювальних одиниць, вони можуть пропустити верхній ліміт комісії для транзакцій v1 або прочитати його як 0. Приклад репозиторію transaction-v1 Фонду Solana пояснює, що повідомлення v1 містить TransactionConfig замість інструкції ComputeBudget.

Документація Solana RPC вказує, що потрібно включити maxSupportedTransactionVersion: 1 в виклики getTransaction, getBlock, blockSubscribe. Якщо це значення пропустити або встановити в 0, то при надходженні транзакцій v1 getTransaction може видати помилку, а getBlock може зазнати невдачі при читанні всього блоку.

Підписка через веб-сокети також не є винятком. Якщо налаштування неправильні, blockSubscribe може повернути block: null. Документація розробників Solana вказує, що це слід трактувати не як порожній блок, а як невдачу. Транзакції v1 ідентифікуються першим байтом серіалізованої транзакції 129, тобто 0x81.

У шляхах gRPC та Geyser можуть виникнути менш помітні помилки. Документація розробників Solana попереджає, що в gRPC немає опцій, таких як maxSupportedTransactionVersion, і старі прототипи protobuf можуть ігнорувати поле Message.config. У цьому випадку система не зупиниться, але транзакції v1 можуть бути сприйняті як v0, що призведе до пропуску налаштувань комісій.

Приклад репозиторію Фонду Solana пропонує мінімальні версії, такі як @solana/kit 8.0.0, yellowstone-grpc-proto 12.6.0, yellowstone-grpc geyser 15.1.1. Також надаються окремі приклади для читання, передачі, індексації блоків та gRPC.

Перевірка основних інструментів також триває. Проблема #831 solana-sdk від anza-xyz підняла питання про те, що максимальний розмір v1 у 4096 байт не забезпечується належним чином у десеріалізаторі та санітайзері. Однак статусна сторінка Solana показує, що станом на 4 вересня 2026 року основні вузли RPC працюють, і не було зареєстровано жодних інцидентів.

Ця справа має сильний характер перевірки сумісності інфраструктури, пов'язаної з розширенням ліміту транзакцій Solana v1. Якщо попередні питання стосувалися ліміту в 4096 байт та активації функцій за кластерами, то тепер основним є те, чи зможе бекенд-система прочитати нову структуру, коли реальні транзакції v1 надійдуть.

Сторінка оновлення Solana вказує, що функція "Більші розміри транзакцій" станом на 4 вересня 2026 року чекає активації. Ця дата більше нагадує технічну дорожню карту, яку повинні послідовно підготувати гаманці, RPC, індексатори та інструменти розробки, а не одноразову подію, що змінює структуру обробки Solana.

Технічно транзакції v1 не замінюють існуючі v0 та спадкові транзакції. Існуючий формат продовжує працювати, але застосунки, що використовують більші розміри транзакцій та transactionConfig, повинні підтримувати новий формат. Зазвичай при оновленні інфраструктури блокчейну сумісність не лише правил консенсусу, але й навколишніх систем, що читають та зберігають дані, визначає реальні операційні ризики.

Спонсори комісій та індексатори можуть бути особливо піддані впливу. Якщо неправильно прочитати верхній ліміт комісії або ліміт обчислювальних одиниць, служби, які несуть витрати замість користувачів, можуть бути піддані несподіваній структурі витрат, а системи аналізу транзакцій можуть неправильно зафіксувати налаштування ресурсів транзакцій v1. Це не є збоєм, що зупиняє ланцюг, але є областю, що потребує окремої перевірки для операторів послуг.

Внутрішні біржі або постачальники гаманців, які також здійснюють виведення та введення Solana та моніторинг в онлайні, не можуть уникнути тих самих проблем. Вони повинні перевірити, чи обробляють шляхи запитів на блоки, транзакції, індексацію, моніторинг ризиків та розрахунок комісій структуру повідомлень v1, а особливо у випадках, коли використовуються зовнішні постачальники вузлів або дані на основі Geyser, необхідно перевірити відтворюваність protobuf та версії бібліотек.

До фактичного надходження транзакцій v1 основними пунктами перевірки є: △ налаштування maxSupportedTransactionVersion: 1 для викликів RPC △ відображення шляху збереження transactionConfig △ відтворення прототипу gRPC protobuf △ визнання префіксу версії 0x81. Станом на сторінку оновлення Solana функція "Більші розміри транзакцій" чекає активації станом на 4 вересня 2026 року.