Хто може запропонувати зміну в Solana і хто реально впливає на рішення

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

Контекст цієї теми — загальна система управління Solana й пропозиції SIMD, а також ширший огляд того, як влаштована мережа під капотом. Якщо ви ще не знайомі з тим, що таке SIMD і як читати таку пропозицію, корисно почати з окремого матеріалу про формат SIMD. А як пропозиція проходить шлях до релізу — описано тут.

Що має витримати технічну перевірку

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

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

Механізм крок за кроком

Процес змін у Solana не має централізованого голосування на кшталт DAO з токен-базовою владою. Він побудований навколо інженерного консенсусу з подальшим узгодженням через оновлення клієнтів та перехід мережі на нову версію. SIMD (Solana Improvement Document) — це формальний контейнер для пропозиції, але сам по собі він не є механізмом голосування.

Формальний шлях: від пропозиції до коду

Пропозиція створюється у вигляді документа у відповідному репозиторії. Формально для цього потрібен лише акаунт на платформі хостингу коду. Пропозиція проходить стадії: від чернетки до активної, далі — до прийнятої або відхиленої. Проте ці статуси є описовими, а не примусовими. Немає смарт-контракту, який би автоматично блокував або дозволяв зміну на основі статусу SIMD.

Реальний механізм такий: зміна реалізується в коді одного або кількох клієнтів (передусім Agave — форк референсного клієнта на Rust). Валідатори оновлюють свої ноди до нової версії. Коли достатня частка стейку переходить на нову версію, мережа фактично працює за новими правилами. Точка «достатньої частки» визначається консенсусним механізмом і залежить від конфігурації конкретного оновлення.

Хто є ключовими акторами

Систему учасників можна розділити на кілька ролей, кожна з яких має різний тип впливу:

• Автор SIMD — особа або група, яка формулює проблему та пропонує рішення. Формально не має жодної влади, окрім здатності ініціювати обговорення.
• Розробники клієнтів — інженери, які мають право коміту в репозиторій клієнта. Їхня згода реалізувати SIMD є необхідною умовою, але не достатньою: без оновлення валідаторами зміна не стає частиною протоколу.
• Валідатори — оператори нод, які утримують стейк делегаторів. Їхнє рішення оновити клієнт є фінальним актом прийняття зміни. Проте валідатори зазвичай не читають SIMD безпосередньо — вони спираються на сигнали від розробників та інфраструктурних команд.
• Інфраструктурні команди — провайдери RPC, стейкінг-платформи, біржі. Вони не голосують формально, але їхня позиція впливає на валідаторів, оскільки ці команди керують значними делегованими стейками або забезпечують критичну інфраструктуру.
• Широка спільнота — розробники смарт-контрактів, користувачі, дослідники. Їхній вплив опосередкований: через обговорення, виявлення вад у пропозиції, формування публічного тиску.

Типи влади в системі

Тип влади	Хто володіє	Механізм	Обмеження
Формальна ініціатива	Будь-хто	Створення SIMD у репозиторії	Не гарантує розгляду чи уваги
Технічна реалізація	Розробники клієнтів із правом коміту	Пул-реквест у репозиторій клієнта	Потребує код-рев’ю та узгодження всередині команди клієнта
Активація в мережі	Валідатори (через оновлення нод)	Перехід на нову версію клієнта	Залежить від координації та сигналу «безпечно оновлюватись»
Опосередкований вплив	Інфраструктурні команди, великі делегатори	Публічна позиція, консультації з валідаторами	Не має формального механізму примусу
Експертний вплив	Досвідчені інженери, дослідники безпеки	Обґрунтована критика або підтримка в обговоренні	Діє лише тоді, коли інші учасники прислухаються

Що можна перевірити

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

Де шукати докази впливу

• Обговорення в SIMD — коментарі від розробників клієнтів є найсильнішим сигналом. Якщо інженер з правом коміту в Agave пише, що пропозиція потребує переробки, це практично блокує просування без змін.
• Пул-реквести в клієнтах — наявність відкритого PR, хто його автор, хто робить код-рев’ю, чи є він злитим — це фактичний трекер реалізації.
• Анонси оновлень валідаторами — публічні заяви або канали комунікації валідаторів щодо планованого оновлення показують, чи набуває зміна чинності.
• Дані про розподіл стейку — щоб оцінити, чи достатньо валідаторів оновились, потрібні дані про частку стейку на новій версії клієнта. Методологія розрахунку цієї частки варіюється залежно від джерела даних.

Типові позиції та їхня вага

Різні групи учасників займають передбачувані позиції, хоча кожен конкретний SIMD може створювати нетипові альянси:

• Розробники ядра зазвичай оцінюють пропозицію за критеріями: складність реалізації, вплив на продуктивність, зворотна сумісність, довгострокова підтримка. Їхня позиція має найбільшу вагу, оскільки без неї зміна фізично не існує в коді.
• Валідатори оцінюють ризики оновлення: чи може нова версія призвести до простою, чи є зворотний шлях, чи узгоджено оновлення з іншими валідаторами. Вони схильні оновлюватись лише тоді, коли є явний консенсус серед розробників.
• Інфраструктурні команди часто фокусуються на сумісності: чи зламає зміна їхні інтеграції, чи потребує міграції RPC-ендпоінтів, чи впливає на тарифікацію.
• Розробники застосунків цікавляться зворотною сумісністю смарт-контрактів та зміною моделі ціноутворення транзакцій. Їхній вплив зростає, коли пропозиція прямо зачіпає інтерфейс між протоколом і застосунками.

Щоб перевірити реальний вплив у конкретному випадку, необхідно зіставити: хто ініціював обговорення, хто відповів від імені команд клієнтів, чи з’явився PR, хто його рев’ювив, і які валідатори публічно заявили про оновлення. Без такої перевірки будь-яке твердження про «хто вирішив» є інтерпретацією, а не фактом.

Що ще залежить від умов

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

Швидкість проти широкого консенсусу

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

Ризик концентрації впливу

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

Невизначеність із зворотною сумісністю

Відсутність формального механізму голосування означає, що зворотна сумісність не гарантується процедурно — вона залежить від інженерного рішення в кожному конкретному випадку. Для розробників застосунків це означає, що моніторинг SIMD та пул-реквестів клієнтів є не бажаною практикою, а необхідною умовою підтримки продукту.

Прозорість проти ефективності

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

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

Що варто перевірити далі

Відповідь на запитання «хто може запропонувати зміну» проста: будь-хто. Відповідь на запитання «хто реально впливає на рішення» складніша: це розробники клієнтів із правом коміту, валідатори, які приймають рішення про оновлення, та інфраструктурні гравці, що формують контекст для цих рішень. Між формальним правом і реальним впливом лежить значна відстань, яку не можна подолати лише добре написаним SIMD.

Для практичної орієнтації корисно розрізняти три рівні:

1. Чи буде розглянуто? — залежить від якості пропозиції, репутації автора та актуальності проблеми. Критерій перевірки: наявність відповідей від розробників клієнтів у обговоренні.
2. Чи буде реалізовано? — залежить від ресурсу команди клієнта, технічної здійсненності та пріоритетів. Критерій перевірки: наявність відкритого пул-реквесту з активним рев’ю.
3. Чи буде активовано? — залежить від координації валідаторів та відсутності критичних зауважень після тестування. Критерій перевірки: публічні заяви валідаторів про оновлення та дані про частку стейку на новій версії.

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

Редакція солана.укр

Джерела для перевірки. Первинні джерела для перевірки цього механізму: офіційний репозиторій.