Цього тижня в мережі Solana запущено Transaction v1: максимальний розмір транзакції збільшено до 4096 байтів

Solana офіційно запустить функцію Transaction v1 у мейннеті 9 вересня (у середу), збільшивши максимальний розмір транзакції з 1 232 байтів до 4 096 байтів — більш ніж утричі. Це оновлення визначається двома пропозиціями щодо вдосконалення Solana: SIMD-0296 («Більші транзакції») та SIMD-0385 (формат Transaction v1).

Технічні характеристики Transaction v1

Transaction v1 спільно визначається двома пропозиціями щодо вдосконалення Solana: SIMD-0296 встановлює більший ліміт розміру транзакції, а SIMD-0385 визначає формат Transaction v1. Обидві пропозиції спільно підготували Jacob Creech та Andrew Fitzgerald. Нова функція вже певний час стабільно працює в тестнеті й девнеті та офіційно запрацює в мейннеті 9 вересня 2026 року.

Transaction v1 розроблено із забезпеченням зворотної сумісності: наявний формат v0 продовжить діяти, а гаманці та застосунки використовуватимуть формат v1 лише за потреби в більшому обсязі транзакції, без обов’язкової міграції.

Три типи транзакцій, які безпосередньо отримають найбільшу користь від Transaction v1

Після збільшення місткості з 1 232 байтів до 4 096 байтів найбільшу безпосередню користь отримають такі три типи транзакцій:

Великі криптографічні докази: верифікаційні дані, такі як докази ZK, раніше часто доводилося розподіляти між кількома транзакціями через обмеження в 1 232 байти, а Transaction v1 дає змогу надіслати повні дані для перевірки ZK в одній транзакції.

Процеси затвердження мультипідписом: для переказів коштів, які потребують схвалення кількох підписантів, наприклад у корпоративній скарбниці або пропозиціях DAO, кожен підпис займає місце, а v1 дає змогу завершити процес затвердження мультипідписом в одній транзакції.

Конфіденційні перекази: деякі механізми приватних транзакцій потребують додаткового зашифрованого обгортання, а недостатній попередній обсяг призводив до помилок транзакцій або зниження ефективності; 4 096 байтів забезпечують достатньо місця для таких операцій.

Причини встановлення ліміту в 4 096 байтів

Встановлення ліміту в 4 096 байтів (4 КБ) має апаратне обґрунтування: це стандартний розмір сторінки пам’яті, який використовують вузли-валідатори. Якщо одна транзакція перетинає кілька сторінок пам’яті, витрати на обробку суттєво зростають, що негативно позначається на підтриманні високого показника TPS Solana (кількості транзакцій за секунду). Тому 4 КБ — це компроміс між збільшенням місткості та збереженням продуктивності мережі.

Попереднє обмеження в 1 232 байти походило з ранньої мережевої архітектури Solana: кожна транзакція мала вміщуватися в IP-пакет розміром приблизно 1 280 байтів. У 2022 році Solana змінила спосіб передавання транзакційного трафіку, через що ця жорстка стеля більше не була необхідною, а запуск Transaction v1 є офіційним скасуванням цього історичного архітектурного обмеження.

Необхідні оновлення RPC-вузлів і сервісів читання

Transaction v1 сильніше впливає на сервіси, що зчитують дані з блокчейна, ніж на сервіси, які надсилають транзакції. Усі сервіси, які отримують дані блоків і транзакцій (RPC-вузли, постачальники ончейн-даних, бекенди гаманців), повинні оновити код, інакше під час зустрічі з транзакцією у форматі v1 вони безпосередньо повертатимуть помилку.

Ще один конкретний вплив стосується розташування поля комісії пріоритету (priority fee): у v1 інформація про комісію пріоритету зберігається в іншому полі, ніж у v0, тому застаріле програмне забезпечення під час зчитування транзакції v1 показуватиме «нульову комісію», навіть якщо користувач фактично сплатив комісію за пришвидшення. Якщо інтерфейси гаманців, блокчейн-оглядачі та застосунки для роботи з транзакціями не оновити, користувачі бачитимуть неточну інформацію про комісії.

Порівняння місткості з Ethereum

Якщо порівнювати дизайн протоколів, Ethereum не має обмеження розміру транзакції на рівні протоколу: розробники можуть виконувати операції з великим обсягом даних в одній транзакції, сплачуючи вищу комісію в газі. Раніше Solana мала суттєві обмеження щодо того, скільки інструкцій може вмістити одна транзакція. Після підвищення ліміту до 4 096 байтів Transaction v1 скорочує розрив між двома мережами, але 4 096 байтів усе ще не є великим обсягом для L1 Ethereum: складна комбінована DeFi-транзакція в Ethereum (наприклад, арбітраж між кількома пулами або позика й повернення кількох активів) часто перевищує цей обсяг.

Практичне технічне значення для екосистеми Solana полягає в усуненні обхідних рішень для розробників: коли раніше операції доводилося розподіляти між кількома транзакціями, потрібно було опрацьовувати залежності стану між транзакціями та відкочування в разі помилки. Transaction v1 дає змогу виконувати складну логіку в одній атомарній операції, що більше відповідає традиційним моделям програмування.

Поширені запитання

Коли запрацює Solana Transaction v1, як зміниться максимальна місткість і які пропозиції її визначають?

Solana Transaction v1 запрацює в мейннеті 9 вересня 2026 року (у середу), а максимальний розмір транзакції збільшиться з 1 232 байтів до 4 096 байтів (більш ніж утричі). Оновлення визначається двома пропозиціями — SIMD-0296 і SIMD-0385, які спільно підготували Jacob Creech та Andrew Fitzgerald, — після стабільної роботи в тестнеті й девнеті.

Чому ліміт у 4 096 байтів встановлено саме на цьому рівні, а не вище?

4 096 байтів — це стандартний розмір сторінки пам’яті, який використовують вузли-валідатори. Якщо одна транзакція перетинає кілька сторінок пам’яті, витрати на обробку суттєво зростають, що негативно позначається на підтриманні високого показника TPS Solana; 4 КБ — це компроміс між збільшенням місткості та збереженням продуктивності мережі.

Як потрібно оновити RPC-вузли та сервіси читання і який конкретний вплив матиме зміна поля комісії пріоритету?

Усі сервіси, що отримують дані блоків і транзакцій, повинні оновити код, інакше під час зустрічі з транзакцією v1 вони безпосередньо повертатимуть помилку. Поле комісії пріоритету у v1 розташоване інакше, ніж у v0, тому застаріле програмне забезпечення показуватиме «нульову комісію», навіть якщо користувач сплатив комісію за пришвидшення, а неоновлені гаманці й блокчейн-оглядачі відображатимуть неточну інформацію про комісії.