Solana Потроює Розмір Транзакції до 4 096 Байт у Форматі V1

Кожен, хто коли-небудь реалізовував multisig-флоу на Solana, знає цю схему: ви ділите операцію на три транзакції, склеюєте їх бандлером і сподіваєтесь, що друга потрапить у ланцюг до того, як стан зміниться. Саме цей обхідний шлях і покликаний знищити новий формат Transaction V1. Він запрацював у вівторок приблизно о 01:00 UTC, і наслідки другого порядку вдарять по командах індексерів раніше, ніж по кінцевих користувачах.

Що Сталося

Solana Foundation випустив Transaction V1 — новий формат транзакцій, який підвищує максимальний обсяг даних в одній транзакції до 4 096 байт із попереднього жорсткого обмеження у 1 232 байти. Як повідомляє CoinDesk, оновлення більш ніж утричі збільшує простір, доступний для інструкцій, підписів та іншого виконавчого метадата в одній транзакції.

Це не зміна пропускної здатності. Solana не обробляє більше транзакцій за секунду завдяки V1. Вона просто дозволяє кожній транзакції нести більше даних. Ця відмінність важлива, бо багато заголовків змішуватимуть ці поняття, і будь-який технічний лід, який побачить цю новину у форварді Slack, має виправити таке формулювання до того, як CTO запитає про показники TPS.

Старе обмеження у 1 232 байти було структурним вузьким місцем. Розробники, які створювали будь-що інформаційно насичене — multisig-гаманці компаній, доази з нульовим розголошенням (zero-knowledge proofs), складні мульти-хоп угоди — мусили розбивати логіку на кілька транзакцій або бандлити їх на клієнтській стороні. У Ethereum ніколи не було такого жорсткого обмеження на рівні протоколу. Він використовує гнучкий ліміт газу в блоці та дозволяє користувачам платити вищі комісії, щоб вмістити важкі операції в один виклик. Ця модель, задокументована в документації Ethereum, пояснює, чому складна DeFi-хореографія перейшла на EVM-ланцюги попри переваги Solana у швидкості та вартості.

V1 скорочує цей розрив. Але не закриває його. Еластичність Ethereum на основі газу все ще перевершує фіксований ліміт у 4 096 байт для найбільших навантажень. Але для 80% випадків, де розробники розбивали операції лише щоб подолати ліміт у 1 232 байти, — це реальний прорив. Старіші формати залишаються підтримуваними, тому нічого не зламається на стороні відправлення.

Технічна Анатомія

Інженерний зсув простий на папері та складний на практиці. Transaction V1 розширює контейнер. Правила виконання щодо того, що в нього входить — підписи, посилання на акаунти, дані інструкцій — залишаються незмінними за духом. Просто стало більше місця. Модель акаунтів у документації Solana як і раніше актуальна. Змінюється лише стеля композиції.

Найбільша семантична перемога — атомарність. За старим обмеженням, робочий процес, якому потрібно, скажімо, сім інструкцій у трьох програмах, розрізався на дві або три окремі транзакції. Розробники бандлили їх, але бандли не дають мережевої гарантії того, що кожен крок або виконується, або відкидається разом. Якщо другий крок пройшов, а третій — ні, ви потрапляли в пекло узгодження станів. Я бачив продакшн-інциденти у фінтех-компаніях, де стани часткового заповнення від пакетних блокчейн-викликів розплутувалися днями, бо ніхто не написав компенсаційну логіку для п'ятнадцяти граничних сценаріїв, яких ніхто не передбачив.

З V1 більша частина таких робочих процесів вміщується в одну транзакцію типу «все або нічого». Один підпис, один атомарний результат, один відкат, якщо щось іде не так. Ось у чому різниця між станавим автоматом, про який можна міркувати, і розподіленою сагою, про яку не можна.

Другий технічний факт важливіший, ніж дозволяє маркетинг: читання транзакцій V1 не є зворотно сумісним. Будь-який індексер, RPC-сервіс, гаманець або аналітична платформа, які не були оновлені, відмовлятимуть на окремих запитах транзакцій V1. Гірше того, запит на цілий блок може відмовити, якщо цей блок містить навіть одну транзакцію V1. Foundation називає це попередженнями про сумісність, а не свідченням масштабного збою. Справедливо. Але в операційному сенсі відмова читання на рівні блоку, яка зачіпає ендпоінт балансу гаманця о 2-й ночі, виглядає для чергового інженера дуже схоже на збій.

Моя думка: сторона відправлення — це легка частина. Кожен серйозний застосунок на Solana має вважати свій шлях читання зламаним, доки не доведено зворотне, і діяти відповідно цього тижня.

Хто Постраждає

Три групи команд наражаються на ризик протягом наступних 90 днів, у порядку спадання болю.

Перші — сторонні постачальники даних. Якщо ви керуєте індексером, RPC-шлюзом, аналітичним сховищем або бекендом гаманця, який споживає блоки Solana, ви отримуєте жорсткий дедлайн, якого не обирали. Щойно транзакції V1 почнуть з'являтися у продакшн-блоках — а це вже відбувається — ваш конвеєр прийому даних має їх парсити, інакше читання на рівні блоків почне відмовляти. Команди, з якими я працював у подібних міграціях, завжди недооцінюють хвіст: справа не в бібліотеці прийому, а у сімнадцяти внутрішніх сервісах, які три роки покладалися на стабільну схему.

Другі — фронтенди гаманців і dApp. Навіть якщо ваш застосунок продовжує надсилати транзакції старого формату, вам все одно потрібно читати нові від інших застосунків, щоб відображати актуальний стан. Перегляди портфелів, історія транзакцій, стрічки активності — все це непомітно ламається, якщо V1-блоби пропускаються або парсяться неправильно. Користувачі не відкриватимуть тікети з написом «помилка парсингу V1». Вони скажуть: «мій баланс неправильний».

Треті — кастодіани та вендори комплаєнсу. Multisig-гаманці компаній прямо згадані в пропозиції дизайну V1 як ключовий варіант використання. Це прямий удар по інституційним кастодіальним робочим процесам. Якщо ваш комплаєнс-стек інспектує транзакції на Solana, йому тепер потрібно обробляти пейлоади розміром 4 096 байт із більшою кількістю інструкцій в одному конверті. Рушії правил, які припускали обмежену кількість інструкцій, видаватимуть хибно-негативні результати.

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

Посібник для Crypto та DeFi

Конкретні дії на цей тиждень, у порядку пріоритетності.

Проаудитуйте ваш шлях читання. Кожен сервіс, який торкається даних блоків або транзакцій Solana, потребує явної перевірки підтримки V1. Не довіряйте заявам вендорів. Пропустіть синтетичну V1-транзакцію через ваш конвеєр від початку до кінця та переконайтесь, що вона потрапляє у вашу базу даних у цілісному вигляді. Якщо ви використовуєте керованого RPC-провайдера, запитайте у них письмово, коли підтримка парсингу V1 з'явилась у їхньому стеку. Отримайте дату.

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

Для команд, які будують на Solana: стримайте бажання переписати все у великі V1-транзакції в перший же день. Більші атомарні операції потужні, але вони також концентрують режими відмов. Починайте з робочих процесів, які справді були зламані за старим обмеженням: multisig-підтвердження, надсилання ZK-доказів, мульти-хоп DEX-маршрути. Решту залиште, доки екосистема стабілізується.

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

Нарешті, стратегічна нотатка. Це оновлення не робить Solana магічно конкурентоспроможною з Ethereum для кожного навантаження. Воно закриває один конкретний розрив. Команди, які обирають ланцюг для нового продукту, мають оцінювати за реальним обмеженням, яке стосується їхнього застосунку, а не за тим, яка мережа нещодавно випустила більш гучний заголовок.

Ключові Висновки

• Transaction V1 підвищує ліміт даних на транзакцію в Solana до 4 096 байт із 1 232 байт — це зміна розміру, а не пропускної здатності.
• Реальна перемога — атомарність: multisig і ZK-робочі процеси, які раніше потребували бандлингу на стороні клієнта, тепер вміщуються в одну транзакцію «все або нічого».
• Сумісність читання — це ризик. Одна транзакція V1 у блоці може призвести до відмови повного запиту блоку для непоновлених індексерів та RPC-сервісів.
• Ethereum зберігає структурну перевагу завдяки гнучкій моделі газу блоку; Solana скорочує розрив, але не закриває його.
• Кожна команда з шляхом читання Solana має перевірити парсинг V1 від початку до кінця цього тижня та інструментувати метрики відмов на рівні блоків до того, як це помітять клієнти.