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

Методологія відбору значущих змін

Не кожен коміт у репозиторії, реліз бібліотеки чи анонс токена становить інфраструктурну зміну. Огляд фокусується на подіях, що задовольняють принаймні одному з трьох критеріїв:

  • Зміна поведінки мережі. Оновлення клієнта (Agave, Firedancer), що впливає на пропускну здатність, час фіналізації, вартість транзакцій або сумісність інструкцій.
  • Зміна інструментарію розробника. Релізи Anchor, нові версії RPC-провайдерів, зміни в моделі обчислювального бюджету (compute units), оновлення PDA-адресації або CPI-механіки.
  • Зміна економіки інфраструктури. Перегляд комісійних моделей, зміни в розподілі інфляції, оновлення механізмів MEV-захисту або вимоги до апаратного забезпечення валідаторів.

Джерела відбору: офіційні RFC Solana, релізи на GitHub клієнтів та ключових бібліотек, протокольні пропозиції (SIMD), дискусії в робочих групах та зворотний зв'язок від інфраструктурних команд. Кожна зміна супроводжується посиланням на первинне джерело — без нього подія не потрапляє до огляду.

Що свідомо виключається: зміни цін токенів, маркетингові анонси без технічної складової, списки «топ-протоколів за TVL» та коментарі впливових осіб, якщо вони не містять конкретних технічних тверджень.

Ключові події місяця: оновлення протоколу, нові проєкти

Цей розділ фіксує події інфраструктурного рівня, що змінили стан мережі або розширили її можливості.

Оновлення протоколу

Тут фіксуються релізи клієнтів мережі, активації SIMD-пропозицій та зміни в консенсусі. Для кожного оновлення вказується:

  • Версія клієнта та дата активації на mainnet-beta (якщо є підтверджене джерело).
  • Суть зміни: нова інструкція, зміна лімітів, оптимізація серіалізації тощо.
  • Чи потребує оновлення оркестраторів стейкінгу, інфраструктурних провайдерів або dApps.

Приклад типу події (без прив'язки до конкретного місяця): перехід на нову версію Agave, що змінює обробку пам'яті в транзакціях, або активація SIMD, що впроваджує новий тип акаунта.

Нові інфраструктурні проєкти

До цього підрозділу потрапляють не всі нові dApps, а лише ті, що пропонують новий інфраструктурний примітив: альтернативні RPC-кластери, нові фреймворки для індексування даних, інструменти моніторингу валідаторів, рішення для кросс-chain комунікації на рівні консенсусу. Критерій — чи може цей проєкт стати залежністю для інших проєктів в екосистемі.

Зміни, що впливають на користувачів

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

  • Комісії та швидкість. Зміни базової комісії за транзакцію, динаміка пріоритизації (local fees), зміни в часі підтвердження транзакцій.
  • Сумісність гаманців. Оновлення формату транзакцій, що вимагають оновлення гаманців, або зміни в підписанні повідомлень (наприклад, перехід на нові версії memo-інструкцій).
  • Доступність RPC. Зміни в політиках рейт-лімітів публічних RPC-вузлів, що впливають на здатність користувачів відправляти транзакції через стандартні налаштування.
  • Безпека. Виявлені вразливості в поширених гаманцях чи мостах, що безпосередньо загрожують коштам користувачів, із вказівкою на джерело та рекомендовані дії.

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

Зміни, що впливають на розробників

Розділ для команд, що будують на Solana. Фокус — на breaking changes, нових можливостях та змінах у процесі розробки. Детальніші інструкції та гайди доступні в розділі розширеної розробки на Solana.

  • Оновлення Anchor. Зміни в макросах, нові обмеження на розмір акаунтів, зміни в обробці помилок, сумісність із новими версіями solana-program.
  • Зміни в моделі обчислювальних бюджетів. Перегляд лімітів compute units, зміни в ціноутворенні пріоритизації, нові інструкції для запиту бюджету.
  • PDA та CPI. Зміни в механіці створення PDA-адрес, нові обмеження на глибину виклику CPI, зміни в перевірці прав власності на акаунти.
  • Інструменти тестування та розгортання. Оновлення test-validator, зміни в поведінці локальної мережі порівняно з mainnet-beta, нові можливості CLI для діагностики.
  • Зміни в екосистемних бібліотеках. Релізи @solana/web3.js, @coral-xyz/anchor, spl-token, що містять breaking changes або нові API.

Для кожної зміни вказується мінімальна версія, з якою вона з'явилася, та попередження про сумісність, якщо розробник не оновлюється негайно.

Зміни, що впливають на валідаторів

Цей блок стосується операторів вузлів та інфраструктурних провайдерів. Більше про інфраструктуру валідації — у матеріалі про валідатори Solana.

  • Вимоги до заліза. Зміни в рекомендованих специфікаціях (RAM, SSD, CPU), що випливають із оновлень клієнта або зростання розміру леджера.
  • Оновлення клієнта. Обов'язкові та рекомендовані версії Agave або Firedancer, терміни міграції, наслідки запізнення з оновленням (наприклад, відстеження від генезису).
  • Зміни в економіці валідації. Перегляд комісій за голосування (vote credits), зміни в розподілі інфляційних винагород, оновлення механізмів делегування через stake-пули.
  • MEV та пріоритизація. Зміни в протоколі, що впливають на можливості екстракції MEV, нові інструменти для Jito або альтернативних блок-движків, зміни в політиці щодо tip-транзакцій.
  • Моніторинг та інциденти. Зміни в метриках, що варто відстежувати, виявлені проблеми зі стабільністю мережі за минулий місяць та їхній вплив на uptime валідаторів.

Для критичних оновлень вказується порядок безпечного відкату, якщо оновлення спричинило проблеми на mainnet-beta.

Обмеження: що не включено та чому

Щоб огляд залишався інфраструктурним і не перетворювався на загальну стрічку новин, з нього свідомо вилучено:

  • Цінову динаміку SOL та токенів екосистеми. Ціни не є інфраструктурною зміною, а їхня кореляція з технічними оновленнями часто хибно інтерпретується як причинність.
  • Рейтинги протоколів за TVL, кількістю користувачів чи обсягом транзакцій. Ці метрики розглядаються окремо в матеріалі про метрики для аналізу Solana — тут вони не дублюються.
  • Маркетингові партнерства та брендові колаборації. Без технічної складової (інтеграція протоколів, спільна інфраструктура) такі анонси не впливають на мережу.
  • Кейси побудови спільнот навколо продуктів. Це окрема тема, що вимагає іншого методологічного підходу і не належить до інфраструктурного огляду.
  • Спекулятивні прогнози. Огляд фіксує фактичні зміни, що вже відбулися або мають підтверджену дату активації.

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

Джерела