Solana планує 9 вересня запустити Transaction v1, новий формат, який збільшує максимальний розмір серіалізованої транзакції з 1 232 байтів до 4 096 байтів.
Підсумок
- Solana планує збільшити максимальний розмір транзакції з 1 232 байтів до 4 096 байтів у середу на основній мережі.
- Transaction v1 залишається необов'язковим, тоді як формати legacy та v0 продовжують працювати з існуючими обмеженнями розміру.
- Застосунки, які читають блоки, повинні підтримувати версію один, інакше вони можуть отримати помилки при зустрічі з новим форматом.
- V1 видаляє таблиці пошуку адрес і зберігає ліміти ресурсів безпосередньо в метаданих конфігурації кожної транзакції.
- Офіційна дорожня карта Solana позначає активацію основної мережі як очікувану, тому розклад на 9 вересня може ще змінитися.
Це збільшення дає розробникам приблизно в 3,3 рази більше простору для транзакцій. Офіційна дорожня карта Solana зазначає, що додаткова ємність може вмістити докази з нульовим розголошенням, великі мультипідписні операції, пакетні операції та деякі схеми підпису в ланцюжку.
Раніше великі операції доводилося розділяти на кілька транзакцій, коли їхні інструкції, підписи та інформація про акаунти перевищували межу в 1 232 байти. Цей процес додавав складності, оскільки одна транзакція могла виконатися успішно, а інший крок зазнати невдачі.
Transaction v1 може дозволити розробникам об'єднати більше таких інструкцій в одну атомарну операцію. Або всі інструкції виконуються успішно, або вся транзакція зазнає невдачі. Ця модель може бути корисною для торгових маршрутів, конфіденційних переказів, крос-чейн операцій та застосунків, які обробляють складні криптографічні докази.
Оновлення не підвищує ліміт Solana на 64 посилання на акаунти в одній транзакції. Застосунки можуть включати більше даних та інструкцій, але вони не можуть автоматично взаємодіяти з більшою кількістю акаунтів.
Існуючі транзакції Solana залишаться дійсними
Transaction v1 є необов'язковим. Гаманці та застосунки можуть продовжувати надсилати транзакції legacy та v0 з існуючим лімітом у 1 232 байти. Користувачам не потрібно мігрувати токени, обмінювати SOL або завершувати претензію перед активацією.
Розробники повинні свідомо прийняти новий формат, щоб отримати доступ до його більшої ємності. Документація Solana визначає три підтримувані формати: legacy, v0 та v1. Кожен формат організовує адреси акаунтів та ліміти ресурсів по-різному.
Формат v0 використовує таблиці пошуку адрес (ALT) для представлення адрес акаунтів через стиснуті однобайтові індекси. V1 видаляє ALT і розміщує повні 32-байтові адреси акаунтів безпосередньо в транзакції.
Це створює компроміс. V1 забезпечує більший загальний обсяг, але застосунки, які сильно покладаються на таблиці пошуку, можуть витрачати більше байтів для представлення тих самих акаунтів. Технічний аналіз Solana показав, що 90% вибіркових транзакцій додадуть менше 1 400 байтів при конвертації з v0 у v1.
Постачальники інфраструктури повинні оновити своє програмне забезпечення
Основний ризик сумісності стосується сервісів, які читають блоки та транзакції. Постачальники RPC-викликів повинні встановити максимальну підтримувану версію транзакцій на одиницю. Інакше запити можуть завершуватися помилкою при зустрічі з транзакцією v1.
Індексатори, оглядачі та аналітичні сервіси також повинні змінити спосіб отримання лімітів ресурсів. Транзакції legacy та v0 розміщують обчислювальні ліміти та налаштування пріоритетної комісії в інструкціях ComputeBudget. V1 зберігає їх у спеціальній конфігурації транзакції.
Застарілі сервіси можуть відображати неправильну інформацію. Наприклад, провідник може показувати нульову пріоритетну комісію, навіть якщо користувач її сплатив. Спонсори комісій та застосунки, які перевіряють ліміти транзакцій, повинні читати нову конфігурацію, а не сканувати старі інструкції.
Застосунки, які надсилають транзакції v1, повинні явно встановлювати ліміти обчислювальних одиниць та завантажених даних, оскільки обидва за замовчуванням дорівнюють нулю. Розробники повинні протестувати створення, підписання та декодування транзакцій перед переведенням виробничого трафіку на цей формат.
9 вересня залишається цільовою датою активації
Віце-президент з технологій Solana Foundation Джейкоб Кріч визначив 9 вересня як заплановану дату для основної мережі. Як раніше повідомляло crypto.news, оновлення включено в розгортання Agave 4.2 від Anza.
Однак офіційна дорожня карта все ще позначає функцію основної мережі як «не активовано». Також зазначається, що графік випуску Anza є «попереднім і може змінюватися». Згідно з останньою сторінкою статусу Фонду, функцію вже активовано в тестових мережах testnet та devnet.
Збільшення розміру походить від SIMD-0296, тоді як SIMD-0385 визначає формат v1. Джейкоб Кріч та Ендрю Фіцджеральд є співавторами обох пропозицій.
Межа в 4096 байт була обрана частково тому, що чотири кілобайти відповідають типовому розміру сторінки пам'яті, який використовується апаратним забезпеченням валідаторів. Більші транзакції також споживатимуть додаткову пропускну здатність, хоча оновлення не вводить окремої плати за байт.
Транзакція v1 залишається окремою від зниження орендної плати Solana, коротших цільових інтервалів слотів та редизайну консенсусу Alpenglow. У пов'язаному матеріалі crypto.news повідомляло, що Alpenglow націлений на фіналізацію приблизно за 150 мілісекунд, причому жовтень залишається цільовим показником розробки, а не гарантованою датою активації.
