Три функціональні оновлення, що вмикаються за допомогою функціональних прапорців, почали активуватися в основній мережі Solana протягом тижня 17 серпня. Зниження плати за зберігання в ланцюжку на 90%, збільшення максимального розміру транзакції в 3,3 раза та поетапне скорочення часу слота з 400 мс до 200 мс є найбільшою зміною інфраструктури Solana з моменту виходу Firedancer в основну мережу.
Резюме
- Клієнт Agave 4.2 від Solana розпочав активацію функцій в основній мережі протягом тижня 17 серпня, надаючи три незалежні оновлення: зниження плати за зберігання на 90%, збільшення розміру транзакцій у 3,3 раза та поетапне скорочення часу слота з 400 мс до 200 мс.
- SIMD-0437 зменшує константу лампортів на байт з 6 960 до 696, знижуючи мінімальний депозит для стандартного облікового запису токена SPL приблизно з 0,16 долара до приблизно 0,016 долара, що зменшує вартість розгортання програм у ланцюжку та створення облікових записів токенів на порядок.
- SIMD-0296 збільшує максимальний розмір транзакції з 1 232 байтів до 4 096 байтів за допомогою нового формату транзакцій v1, що дозволяє ZK-докази, великі мультипідписи та схеми BLS-підписів у ланцюжку виконувати як єдині атомарні транзакції.
- SIMD-0525 націлений на час слота 200 мс чотирма послідовними зменшеннями на 50 мс, із запобіжником, який зупиняє прогрес, якщо рівень пропуску блоків перевищує визначений поріг на будь-якому етапі.
- Agave 4.2 також включає повну кодову базу консенсусу Alpenglow, хоча активація в основній мережі відкладена до Agave 4.3 у жовтні, коли Alpenglow замінить і Proof of History, і TowerBFT на алгоритм голосування Votor, націлений на фіналізацію приблизно за 150 мс.
Дорожня карта інфраструктури Solana на 2026 рік — це послідовність ставок, накладених одна на одну. Firedancer досяг основної мережі в грудні 2025 року і зараз несе приблизно 14% частки основної мережі серед понад 20% активних валідаторів. Agave 4.2 змінює економіку та характеристики продуктивності мережі, яку запускають ці валідатори. Alpenglow, який вийде в наступному випуску, повністю замінює механізм консенсусу. Кожен шар залежить від попереднього, і кожен змінює те, що розробники можуть будувати на Solana.
Ця стаття розбирає три оновлення Agave 4.2, вимірює, що кожне з них змінює на практиці, і досліджує, як вони позиціонують Solana проти дорожньої карти Hegota від Ethereum та ширшої конкуренції за увагу розробників і користувачів.
Зниження плати за зберігання: що означають облікові записи за 0,016 долара для розробників
Плата за зберігання в Solana — це мінімальний баланс, який користувач повинен внести, щоб обліковий запис залишався відкритим. Депозит масштабується залежно від обсягу збережених даних. За попередньою ставкою стандартний обліковий запис токена SPL вимагав приблизно 0,16 долара в SOL як депозит, звільнений від плати. Ця сума не є комісією. Вона заблокована в обліковому записі, поки існує обліковий запис, і повертається, коли обліковий запис закривається.
SIMD-0437 зменшує константу лампортів на байт у 10 разів, з 6 960 до 696. Депозит, звільнений від плати, для того самого облікового запису токена знижується приблизно до 0,016 долара. Для одного облікового запису різниця незначна. Для застосунків, які створюють тисячі або мільйони облікових записів, різниця є структурною.
Децентралізована біржа, яка веде книгу замовлень у ланцюжку, створює облікові записи для кожного відкритого замовлення. Ігровий протокол, який відстежує стан гравця, створює облікові записи для кожного активного гравця. Платформа токенізації, яка випускає дробові акції, створює облікові записи для кожного власника. У кожному випадку вартість запуску застосунку масштабується лінійно з кількістю облікових записів, і SIMD-0437 зменшує цю вартість на 90%.
Практичний ефект полягає в тому, що категорії застосунків, які були економічно невигідними на Solana за попередньою ставкою плати, стають життєздатними за новою. Ончейн-книги замовлень із детальними рівнями цін, повністю ончейн-ігри з постійним станом для мільйонів гравців і платформи токенізації з десятками тисяч власників стають значно дешевшими в експлуатації.
Контраргумент полягає в тому, що дешевше зберігання збільшує розростання стану. Кожен обліковий запис, який існує в Solana, займає простір, який валідатори повинні зберігати та обробляти. Зменшення вартості створення облікових записів на 90% може призвести до відповідного збільшення кількості облікових записів, що створює навантаження на апаратне забезпечення валідаторів. Anza, команда розробників Agave, стверджує, що стиснення стану та функції управління життєвим циклом облікових записів у майбутніх випусках вирішать проблему розростання незалежно від ставки плати.
Більші транзакції: від обхідних шляхів до атомарного виконання
Обмеження розміру транзакції в 1232 байти було однією з найбільш стійких проблем для розробників Solana. Це обмеження походить від ліміту розміру пакетів на основі UDP, який був встановлений під час запуску і ніколи не оновлювався. Розробникам, які працюють зі складними операціями, ZK-доказами, великими мультипідписами та багатоінструкційними DeFi-транзакціями, доводилося розбивати роботу на кілька транзакцій або використовувати таблиці пошуку адрес для стиснення посилань.
SIMD-0296 підвищує ліміт до 4096 байтів за допомогою нового формату транзакцій v1. Цей формат замінює інструкції ComputeBudgetProgram на конфігураційну маску, яка переноситься безпосередньо в заголовку транзакції, звільняючи місце для фактичних даних інструкцій. Транзакції v1 ідентифікуються провідним байтом версії 129 і не підтримують таблиці пошуку адрес, але при 4096 байтах повний список адрес у більшості випадків можна включити безпосередньо.
Вплив найбільше відчують три категорії розробників. Перевірка ZK-доказів, яка вимагає передачі даних доказів як вхідних даних транзакції, тепер може бути виконана як єдина атомарна транзакція замість розбиття на кілька викликів. Великі мультипідписні гаманці з багатьма підписантами можуть включити всі підписи в одну транзакцію. А схеми підпису в ланцюжку, такі як BLS, які вимагають більшого обсягу ключового матеріалу, можуть виконуватися без обхідних шляхів.
Існуючим додаткам не потрібно змінюватися. Формати транзакцій v0 та застарілі продовжують працювати так само, як і раніше. Лише додатки, які потребують більшого розміру, повинні перейти на v1. Індексатори та блокчейн-експлорери, які декодують необроблені байти транзакцій, повинні будуть розпізнавати новий макет, але шлях міграції є добровільним, а не примусовим.
Збільшення в 3,3 рази може здатися скромним порівняно з практично необмеженими calldata Ethereum. Різниця полягає в тому, що транзакції Solana виконуються в одному слоті з детермінованим порядком, тоді як транзакції Ethereum конкурують за включення в блок зі змінними витратами на газ. Підхід Solana обмінює гнучкість на швидкість: транзакція Solana розміром 4096 байтів підтверджується менш ніж за секунду, тоді як порівнянна транзакція Ethereum може чекати хвилини залежно від цін на газ та завантаженості блоків.
Шлях до слотів у 200 мс
SIMD-0525 є найамбітнішим із трьох оновлень і тим, яке має найбільш помітний вплив на користувачів. Поточний час слота Solana становить 400 мс, тобто новий блок створюється приблизно кожні 0,4 секунди. SIMD-0525 передбачає зменшення до 200 мс, що фактично подвоює швидкість виробництва блоків у мережі.
Зменшення не є миттєвим. Воно відбувається чотирма послідовними кроками по 50 мс: з 400 мс до 350 мс, потім до 300 мс, потім до 250 мс, потім до 200 мс. Кожен крок контролюється активацією функції, яку мають прийняти валідатори. Протокол включає критичний запобіжник: якщо рівень пропуску блоків перевищує визначений поріг на будь-якому етапі, мережа не перейде до наступного кроку, доки стабільність не буде відновлено.
Тестова мережа вже продемонструвала слоти 300 мс, підтвердивши перші два кроки. Решта кроків до 250 мс і 200 мс залежатимуть від продуктивності валідаторів основної мережі в умовах реального навантаження, яке відрізняється від умов тестової мережі за обсягом трафіку, географічним розподілом та різноманітністю обладнання.
Для користувачів швидші слоти означають швидші підтвердження. Обмін на Solana DEX зараз підтверджується приблизно за 400 мс. При слотах 200 мс той самий обмін підтверджується вдвічі швидше. Для маркет-мейкерів щільніші слоти означають щільніші спреди, оскільки вікно, протягом якого котирувана ціна може застаріти, скорочується з кожним кроком. Для валідаторів швидші слоти означають вищі вимоги до обладнання: обчислювальний бюджет на слот залишається тим самим, але час, доступний для його обробки, скорочується вдвічі.
Проблема обладнання валідаторів не є теоретичною. ETHNews повідомило, що оновлення Agave 4.2 «робить його дешевшим у використанні, але складнішим в експлуатації». Зниження орендної плати зменшує витрати для розробників. Скорочення часу слота збільшує витрати для валідаторів. Чи є компроміс чисто позитивним, залежить від того, чи привабить дешевша вартість розробки достатньо нової активності, щоб виправдати вищі інфраструктурні витрати, які валідатори повинні поглинути.
Роль Firedancer в оновленні
Вимоги до продуктивності Agave 4.2 було б важче виконати без присутності Firedancer в mainnet. Клієнт-валідатор Jump Crypto на C та C++, який досяг mainnet у грудні 2025 року, забезпечує базовий рівень продуктивності, який оригінальний клієнт Agave сам по собі не міг гарантувати.
Дані операторів за період розгортання з 2025 по 2026 рік показують, що валідатори Firedancer досягли покращення на 18-28 базисних пунктів у зменшенні пропусків, на 15% менше пропущених голосів, затримку голосування приблизно 1.002 слоти та повніші блоки в середньому 47 мільйонів проти 44.8 мільйонів обчислювальних одиниць під Agave. Ці показники мають значення, коли час слотів скорочується вдвічі, оскільки допуск на затримки обробки зменшується з кожним зменшенням.
Firedancer зараз несе приблизно 14% частки mainnet серед понад 20% активних валідаторів. Різноманітність клієнтів також є функцією стійкості: помилка, яка призводить до збою Agave, не обов'язково вплине на Firedancer, і навпаки. Для мережі, яка готується скоротити час слотів вдвічі, а потім повністю замінити механізм консенсусу, наявність двох незалежних клієнтів — це не розкіш, а вимога безпеки.
Alpenglow: переписування консенсусу, яке чекає в наступному випуску
Agave 4.2 постачає повний код Alpenglow, але не активує його в mainnet. Ця активація зарезервована для Agave 4.3, запланованого на жовтень 2026 року. Коли він вийде, Alpenglow замінить і Proof of History, і TowerBFT, дві системи, які Solana використовує з моменту запуску в 2020 році.
Заміною є Votor, алгоритм голосування, який націлений на фіналізацію приблизно 150 мс порівняно з поточною фіналізацією TowerBFT у 12.8 секунд. Votor повністю усуває транзакції голосування в ланцюжку. Під TowerBFT валідатори подають голоси як звичайні транзакції, які споживають простір блоку та обчислювальні одиниці. Під Votor валідатори обмінюються голосами безпосередньо через окремий канал, звільняючи пропускну здатність блоку для транзакцій користувачів.
Модель безпеки допускає одночасне перебування 20% частки в офлайні та 20% частки ворожої. Anza опублікувала програму винагород за помилки в розмірі 50 000 SOL для Alpenglow, з поданнями, що відкриваються 5 серпня, що свідчить про впевненість у кодовій базі, визнаючи, що заміна консенсусу такого масштабу потребує зовнішнього перегляду безпеки.
Послідовність має значення. Agave 4.2 зменшує орендну плату, збільшує розмір транзакцій і починає скорочувати час слотів. Agave 4.3 замінює механізм консенсусу. Кожне оновлення розроблене як незалежно корисне, але повне бачення — 200-мілісекундні слоти з фіналізацією 150 мс на протоколі консенсусу, який не споживає простір блоку для голосування — вимагає успішного випуску всіх.
Як це порівнюється з дорожньою картою Hegota Ethereum
Solana та Ethereum йдуть різними шляхами до однієї мети: нижчі витрати, вища пропускна здатність і швидша фіналізація. Контраст між Agave 4.2 та планом оновлення Hegota Ethereum ілюструє архітектурні відмінності.
Таймлайн Hegota Ethereum передбачає крайній термін для переваг у вересні, а саме оновлення заплановане на 2027 рік. Обсяг все ще визначається: було подано 66 пропозицій, і спільнота повинна скоротити більшість з них перед остаточним оформленням оновлення. Ключові кандидати включають EIP-8182 для нативної конфіденційності, FOCIL для стійкості до цензури та збільшення пропускної здатності blob для масштабованості rollup. Devnet Glamsterdam зірвався, відсунувши таймлайн ще далі.
Підхід Solana швидший і більш централізований у прийнятті рішень. Anza встановлює графік активації функцій, валідатори приймають його, і оновлення відбувається. Немає еквівалента багаторічного процесу EIP Ethereum з управлінням спільноти щодо того, які пропозиції потрапляють у фінальний список. Компроміс полягає в тому, що Solana може випустити три великі оновлення в одному релізі, тоді як Ethereum потрібно 12-18 місяців, щоб завершити порівнянний обсяг змін.
Розрив у продуктивності після Agave 4.2 є разючим. Solana зі слотами 200 мс і фіналізацією Alpenglow 150 мс підтверджувала б транзакції менш ніж за 400 мс. Поточна фіналізація Ethereum становить приблизно 13 хвилин, а покращення Hegota, якщо вони вийдуть, націлені на фіналізацію одного слота, яка все одно вимірюватиметься в секундах, а не мілісекундах.
Розрив у витратах також зростає. Зниження орендної плати в Solana робить зберігання в мережі на порядок дешевшим. Ethereum L1 залишається дорогим для зберігання, а ролапи поглинають більшу частину зниження витрат через дані blob. Для розробників, які обирають, де створювати нові застосунки, економіка інфраструктури все більше віддає перевагу Solana для випадків використання, що вимагають високої пропускної здатності, низьких витрат і швидкої фіналізації.
Контраргумент полягає в тому, що повільніший процес Ethereum забезпечує більш надійні, перевірені в бою оновлення з ширшим консенсусом спільноти. Перевага Solana у швидкості досягається ціною тиску на централізацію валідаторів і меншого запасу міцності під час великих інфраструктурних переходів. Ринок зрештою оцінить обидва підходи за впровадженням розробниками та активністю користувачів, а не лише за технічними характеристиками.
Сигнал міграції розробників
Оновлення інфраструктури мають значення лише якщо розробники реагують, створюючи застосунки, які їх використовують. Провідним індикатором є не ціна SOL або TVL, а швидкість розгортання нових програм і обсяг впровадження транзакцій v1 у тижні після активації.
Екосистема розробників Solana стабільно зростала протягом 2026 року: Фонд Solana повідомляє про понад 2500 активних щомісячних розробників у своєму останньому звіті про екосистему. Очікується, що зниження орендної плати прискорить розробку ончейн-ігор, децентралізованих соціальних протоколів і платформ токенізації, які раніше були обмежені витратами на створення акаунтів.
Конкурентна динаміка також актуальна. Розробники, які чекали на дешевшу інфраструктуру Solana, тепер її мають. Розробники, які розглядали ролапи Ethereum через вартість, повинні зважити додаткову складність мостів L2 і фрагментовану ліквідність проти інтегрованого досвіду L1 Solana за подібних або нижчих витрат.
Протилежний випадок: чому ці оновлення несуть ризик
Бичачий сценарій для Agave 4.2 полягає в тому, що він робить Solana дешевшою, швидшою та потужнішою. Ведмежий сценарій полягає в тому, що він ускладнює роботу Solana, посилюючи тиск на централізацію валідаторів, одночасно впроваджуючи три одночасні зміни в мережу, яка обробляє мільярди доларів щоденного обсягу.
Зниження орендної плати створює ризик зростання стану. Якщо кількість акаунтів у Solana збільшиться пропорційно до зниження витрат, валідаторам доведеться зберігати та обробляти в 10 разів більше даних стану. Фонд Solana не опублікував прогноз зростання стану для середовища після SIMD-0437.
Зменшення часу слоту підвищує вимоги до апаратного забезпечення в той час, коли витрати валідаторів Solana вже вищі, ніж у більшості конкуруючих мереж. Валідатору, що запускає Solana, потрібне високоякісне апаратне забезпечення зі швидким NVMe-сховищем, високошвидкісним мережевим з’єднанням і значним обсягом оперативної пам’яті. Зменшення часу слоту вдвічі не подвоює вартість апаратного забезпечення, але звужує запас для помилок і може виштовхнути менших валідаторів нижче порогу продуктивності, необхідного для уникнення штрафів за пропуск.
Збільшення розміру транзакцій вводить новий формат, який повинні підтримувати індексатори, гаманці та SDK. Хоча міграція є добровільною, фрагментація екосистеми між форматами транзакцій v0, legacy та v1 створює додаткову складність для розробників і постачальників інфраструктури.
Час також створює ризик виконання. Активація трьох основних функцій одночасно в мережі, яка щодня обробляє мільярди доларів, означає, що будь-які взаємодії між оновленнями, сценарій, який тестова мережа може не повністю відтворити, можуть проявитися під виробничим навантаженням. Поетапне зменшення часу слоту пом’якшує найбільший ризик, але зниження орендної плати та збільшення розміру транзакцій активуються без еквівалентних запобіжних заходів.
Існує також менш обговорюваний конкурентний ризик. Якщо Agave 4.2 досягне успіху, це підтвердить тезу про те, що одна команда може впроваджувати значні інфраструктурні зміни швидше, ніж децентралізований процес управління Ethereum. Ця теза приваблює розробників у короткостроковій перспективі. У довгостроковій перспективі вона створює залежність від постійної компетентності Anza та узгодженості з екосистемою. Повільніший процес Ethereum розподіляє цей ризик між ширшим колом учасників. Що важливіше — швидкість чи стійкість — залежить від часового горизонту.
Що могло б спростувати ведмежий сценарій: успішна активація всіх трьох функцій без збільшення рівня пропусків, без виходу валідаторів, а також помітне зростання активності розробників та ончейн-акаунтів протягом 90 днів. Вікно в 90 днів має значення, оскільки зміни в інфраструктурі часто проявляють свій ефект поступово, а не одразу.
Що дивитися
- Пропуск після кожного зменшення часу слота. Запобіжник у SIMD-0525 зупиняє прогрес, якщо рівень пропуску перевищує поріг. Чи пройде мережа через усі чотири зменшення, чи зупиниться на проміжному кроці, покаже реальні межі інфраструктури валідаторів Solana.
- Швидкість створення акаунтів після зниження орендної плати. Різке збільшення нових акаунтів підтверджує тезу, що орендна плата була суттєвим бар'єром для розробки. Плоске створення акаунтів свідчило б, що обмеження було деінде.
- Впровадження транзакцій v1. Те, наскільки швидко постачальники гаманців, DEX та DeFi-протоколи приймуть більший формат транзакцій, визначить, чи перетвориться збільшення розміру на нові можливості, чи залишиться невикористаним.
- Результати програми винагород за помилки Alpenglow. Програма винагород у 50 000 SOL, яка завершується перед випуском Agave 4.3, дасть публічні висновки з безпеки, які покажуть, чи відбудеться жовтневий перехід консенсусу за графіком.
- Траєкторія частки стейкінгу Firedancer. Різноманітність клієнтів є передумовою для профілю ризику цих оновлень. Чи зросте частка стейкінгу Firedancer з 14% до 33%, порогу, який широко вважається необхідним для значущої стійкості, має значення для безпеки мережі під час переходу.
Часті запитання
Що таке Solana Agave 4.2?
Agave 4.2 — це основний реліз клієнта від Anza, команди розробників, що стоїть за основним програмним забезпеченням валідатора Solana. Він надає три оновлення, керовані функціями: зниження орендної плати за зберігання в ланцюжку на 90%, збільшення максимального розміру транзакції в 3,3 раза та поетапне зменшення часу слота з 400 мс до 200 мс.
Коли Agave 4.2 активувався в основній мережі?
Активація функцій розпочалася на тижні 17 серпня 2026 року. Три оновлення активуються незалежно через механізм функціональних перемикачів Solana, що означає, що кожне з них може йти за власним графіком залежно від впровадження валідаторами.
Скільки економить розробникам зниження орендної плати?
Звільнений від орендної плати депозит для стандартного акаунта токена SPL знижується приблизно з $0,16 до приблизно $0,016, тобто на 90%. Для застосунків, які створюють тисячі або мільйони акаунтів у ланцюжку, сукупна економія є значною.
Що дозволяє більший розмір транзакцій?
Максимальний розмір транзакції збільшується з 1232 байтів до 4096 байтів через новий формат v1. Це дозволяє перевірку ZK-доказів, великі мультипідписні конфігурації та схеми підпису BLS виконувати як єдині атомарні транзакції, а не розбивати на кілька викликів.
Як працює зменшення часу слота?
SIMD-0525 зменшує час слота з 400 мс до 200 мс чотирма послідовними зменшеннями на 50 мс. Кожен крок керується активацією функції, і протокол зупиняє прогрес, якщо рівень пропуску блоків перевищує поріг безпеки на будь-якому етапі.
Що таке Alpenglow і коли він активується?
Alpenglow — це новий механізм консенсусу, який замінює і Proof of History, і TowerBFT на алгоритм голосування Votor, націлений на приблизно 150 мс фінальності. Кодова база постачається в Agave 4.2, але активація в основній мережі запланована на Agave 4.3 у жовтні 2026 року.
Чи впливає Agave 4.2 на існуючі застосунки?
Зниження орендної плати та зміни часу слота застосовуються автоматично до всіх застосунків. Більший розмір транзакцій є опціональним через новий формат v1. Існуючі транзакції v0 та застарілі продовжують працювати без змін.
Які ризики цих оновлень?
Основними ризиками є збільшення розростання стану через дешевше зберігання, вищі вимоги до апаратного забезпечення валідаторів через швидші слоти та фрагментація екосистеми через новий формат транзакцій v1. Поетапне розгортання із запобіжниками рівня пропуску призначене для зменшення ризику часу слота. Це освітній аналіз, а не інвестиційна порада.
