Solana увеличи максималния размер на данните в една транзакция, което позволява на по-сложни приложения да включват повече подписи, доказателства и свързани инструкции в една операция.
Обобщение
- V1 увеличава максималния размер до 4,096 байта.
- Legacy и V0 транзакциите остават напълно поддържани.
- Доказателствата и multisig операциите получават повече място.
- Приложенията трябва изрично да добавят поддръжка за V1.
- По-големите транзакции може да изискват по-високи приоритетни такси.
Solana активира функцията txv1 в основната мрежа около 04:00 ч. българско време на 15 септември, в началото на епоха 1035. Ъпгрейдът увеличи максималния размер на една транзакция от 1,232 на 4,096 байта.
Допълнителното пространство е достъпно чрез новия формат V1. Приложенията трябва да добавят поддръжка за него, преди да могат да го използват, докато legacy и V0 транзакциите продължават да работят при досегашните си ограничения.
Новият лимит не увеличава количеството SOL, което може да се изпрати
Промяната засяга количеството информация, което може да се включи в една транзакция, а не броя SOL, които потребителят може да прехвърли. Обикновеният трансфер използва сравнително малко данни, защото включва ограничен брой акаунти, инструкции и подписи.
По-сложните операции могат да изискват повече инструкции, множество адреси, няколко одобрения или криптографски доказателства. Когато необходимите данни надхвърляха стария лимит, разработчиците трябваше да опростят операцията, да я разделят на няколко транзакции или да използват решения като address lookup tables и transaction bundles.
Solana може да обработва несвързани транзакции паралелно, както е обяснено в това ръководство за начина, по който работи Solana. V1 не променя този модел. Новият формат просто позволява повече свързани инструкции да бъдат събрани в една транзакция.
Когато няколко инструкции са включени в една атомарна транзакция, те се изпълняват като едно цяло. Или всички промени се записват успешно, или цялата операция се отменя. Така не може само част от действията да бъдат записани в мрежата.
Кои операции могат да се възползват от допълнителното пространство?
- Сделки с няколко свързани действия: Търговско приложение може да включи повече инструкции в една транзакция, вместо да чака отделни потвърждения.
- По-сложни multisig операции: Корпоративни портфейли и портфейли за управление на средства могат да включват повече подписи и информация за акаунти, когато няколко души трябва да одобрят една операция.
- Zero-knowledge доказателства: Приложенията могат да доказват, че дадено условие е изпълнено, без да разкриват цялата информация зад него, но самото доказателство може да заема значителна част от транзакцията.
- Криптографски подписи, проверявани в мрежата: Някои формати за подписи досега генерираха повече данни, отколкото една Solana транзакция можеше да побере.
Фондация Solana посочва поверителните трансфери, вложените multisig структури, групираните операции и определени схеми за криптографски подписи сред потенциалните приложения на новия формат.
Повечето потребители на портфейли не трябва да правят нищо
Активирането не изисква потребителите да местят своите SOL, да създават нов адрес или да променят съществуващ акаунт. Приложенията, които продължат да използват legacy или V0 транзакции, ще работят както досега.
Съвместим портфейл ще е необходим само когато дадено приложение реши да използва V1 транзакция. Затова е достатъчно портфейлният софтуер да бъде поддържан актуален, докато доставчиците постепенно добавят съвместимост с новия формат. Самото приложение също трябва да проверява дали портфейлът може да подпише V1 транзакцията.
За потребителите промяната може да означава по-малко отделни заявки за потвърждение при сложни операции. Услуга, която досега е използвала няколко свързани транзакции, може вместо това да обедини действията в една операция.
Разработчиците и индексаторите трябва да обновят софтуера си
Използването на V1 за изпращане на транзакции е по избор, но инфраструктурата трябва да може и да разпознава новия формат.
RPC услугите, които извличат транзакции или блокове, трябва да задават maxSupportedTransactionVersion: 1. Без тази настройка заявка за V1 транзакция може да върне грешка, а една неподдържана транзакция може да провали заявката за целия блок.
При индексаторите рискът е различен. V1 съхранява лимита за изчислителен ресурс, лимита за данни от заредени акаунти и приоритетната такса в transactionConfig, а не в Compute Budget инструкциите. Софтуер, който продължава да търси тези стойности на старото място, може да класифицира транзакцията неправилно или да отчете ресурсните лимити и приоритетната такса като нула.
Приложенията, които създават V1 транзакции, трябва изрично да задават лимитите за compute units и данните от заредени акаунти. И двете стойности по подразбиране са нула в новия формат, така че пропускането им може да доведе до отказ още преди изпълнението.
Транзакциите над 1,232 байта трябва да бъдат изпращани с base64 кодиране. При изпращане чрез base58 остава старият лимит.
V1 увеличава размера, но променя част от правилата за транзакцията
V1 не е просто по-голяма версия на V0. Форматът може да съдържа директно до 64 адреса на акаунти, но не поддържа address lookup tables. Повтарящите се адреси също не са разрешени.
Това означава, че разработчиците ще избират между двата формата според конкретната операция. V0 остава по-подходящ, когато lookup таблиците дават по-ефективен начин за посочване на множество акаунти. V1 е насочен към случаи, в които са нужни повече място за инструкции, подписи или доказателства.
За обикновено плащане новият формат едва ли ще донесе полза. V1 има смисъл, когато позволява сложна поредица от действия да бъде събрана в една транзакция или побира данни, които досега не са се събирали в стария лимит.
По-големите транзакции може да изискват по-висока такса
По-високият лимит не означава автоматично, че всяка V1 транзакция ще струва повече. Цената зависи от заявените ресурси, броя подписи и приоритетната такса, избрана от приложението.
По-големите транзакции обаче използват повече от мрежовия капацитет на валидаторите. Според документацията на Solana при еднакъв желан приоритет по-голямата транзакция може да изисква по-висока приоритетна такса от по-малката, особено когато търсенето на блоково пространство е високо.
При V1 приоритетната такса се задава като обща сума в lamports. При V0 тя се изразява като цена за compute unit, което означава, че платформите за анализ трябва да уеднаквяват двата формата, преди да сравняват таксите.
Търсенето на приоритетни такси може да се променя значително според активността в мрежата, както показват и последните данни за таксите в Solana. Затова разработчиците ще трябва да преценяват дали ползата от една по-голяма транзакция оправдава по-високата цена в периоди на натоварване.
Реалният тест за V1 започва след активирането
Ъпгрейдът премахва ограничение, което досега принуждаваше някои приложения да разделят по-сложните операции на няколко транзакции. Самото активиране в основната мрежа обаче не означава, че новият формат веднага ще се използва широко.
Първите приложения вероятно ще бъдат именно там, където старият лимит създаваше най-големи затруднения – при поверителни трансфери, сложни multisig операции и транзакции с много инструкции.
Значението на V1 ще зависи от това дали допълнителното пространство действително ще позволи на разработчиците да намалят броя отделни транзакции, потвърждения и неуспешни опити достатъчно, за да оправдае необходимите промени в инфраструктурата.
Информацията, публикувана в TradeNews, има единствено информационен характер и не представлява финансов, инвестиционен, правен или какъвто и да е друг професионален съвет. Пазарите на акции, криптовалути, форекс и дигитални активи са силно волатилни и миналото представяне не е гаранция за бъдещи резултати. Читателите следва самостоятелно да правят собствено проучване и, при необходимост, да се консултират с лицензирани финансови или други професионални консултанти. TradeNews не носи отговорност за каквито и да е загуби или щети, произтичащи от използването на публикуваната информация.
