Концентрація стейку: коли велика частка стає системним ризиком

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

Що беремо за основу перевірки

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

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

Механізм і зв’язки

Solana використовує механізм делегованого доказу частки (delegated proof-of-stake). Власники токенів SOL делегують свою голосуючу вагу валідаторам, не передаючи їм права власності на токени. Валідатори з більшим стейком частіше стають лідерами блоків і мають більший вплив на консенсус.

Розподіл ролей у стейкінгу

• Валідатор — вузол, який може голосувати в консенсусі, перевіряти дані мережі та, коли призначений лідером слоту, виробляти блок. Потребує технічної інфраструктури й стабільного з’єднання з мережею.
• Делегатор — власник SOL, який обирає валідатора й передає йому свою голосуючу вагу. Зберігає контроль над токенами та може перевести делегування в будь-який момент, хоча зміна не є миттєвою через період деактивування (deactivation epoch).
• Протокол ліквідного стейкінгу (LST) — смарт-контракт, який агрегує делегування від багатьох користувачів і розподіляє стейк між валідаторами за власним алгоритмом. Створює додатковий рівень опосередкованого контролю: кінцевий делегатор не обирає валідатора безпосередньо.

Консенсус і пороги впливу

Solana використовує алгоритм Tower BFT — варіацію практичної візантійської толерантності (Practical BFT). У таких системах існують два критичні пороги, які визначають межі безпеки:

• 33% голосуючої ваги — достатньо для порушення життєздатності (liveness). Коаліція з такою часткою може блокувати фіналізацію блоків, фактично зупиняючи мережу. Мережа не зможе досягти супербільшості для підтвердження нових блоків.
• 67% голосуючої ваги — достатньо для порушення безпеки (safety). Коаліція може підписати конфліктні блоки на різних гілках, що теоретично дозволяє подвійні витрати (double-spend).

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

Валідатори, голосування і розклад лідерів

У поточній Tower-era моделі Solana немає фіксованої протокольної межі кількості активних валідаторів, які можуть брати участь у консенсусі. Водночас документація про формування leader schedule використовує термін active set для вибірки стейкованих ідентичностей, що голосували протягом визначеного інтервалу; з цієї вибірки лідери слотів обираються зі зважуванням за стейком.

Ці два поняття не варто змішувати. Leader-schedule active set не є «малим закритим комітетом», який Solana штучно обмежує заради продуктивності. Для аналізу концентрації важливі насамперед розподіл голосуючої ваги, фактична участь валідаторів у голосуванні та те, скільки незалежних суб’єктів контролюють критичні частки стейку.

Механізм делегування: що насправді контролює делегатор

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

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

Де факти, а де інтерпретація

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

Позиція A: Концентрація — це насамперед ризик економічної координації

З цього погляду головна загроза полягає не в технічній відмові, а в тому, що великі валідатори або протоколи ліквідного стейкінгу можуть координуватися для екстракції MEV (Maximal Extractable Value — максимальна цінність, яку можна вилучити з порядку транзакцій), цензури транзакцій або спільної атаки на мережу. Навіть якщо вони технічно незалежні, спільні економічні інтереси створюють де-факто координацію.

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

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

Позиція B: Концентрація — це насамперед технічна крихкість

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

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

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

Спільні принципи

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

• Ризик не лінійний відносно частки — він різко зростає при наближенні до порогів консенсусу. Збільшення частки з 5% до 10% має інший характер наслідків, ніж з 28% до 33%.
• Номінальний розподіл стейку між валідаторами — неповний показник. Важлива ефективна контрольна здатність: хто приймає рішення про делегування й хто контролює ключі підпису.
• Протокольний slashing у Solana за актуальною документацією зараз не реалізований. Тому аналіз варто будувати на чинних механізмах консенсусу, вартості участі, втраті винагород, репутаційних наслідках і здатності делегаторів переміщувати стейк, а не на уявній автоматичній конфіскації.
• Оцінка концентрації потребує не лише даних про стейк, а й даних про операційну зв’язність — що розглядається в сусідніх матеріалах цього кластера.

Що потрібно для перевірки позицій

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

• Розподіл стейку за валідаторами з урахуванням прямого делегування та делегування через LST-протоколи, із зазначенням дати зрізу та джерела даних.
• Коефіцієнт Накамото (Nakamoto coefficient) — мінімальна кількість незалежних сутностей, якій потрібно скомпрометувати, щоб зупинити мережу. Розраховується для різних порогів (33%, 67%) і потребує чіткого визначення «незалежності» — номінальної, інфраструктурної, економічної.
• Дані про перекриття інфраструктури між великими валідаторами: спільні хостинг-провайдери, спільні версії клієнтського ПЗ, спільні практики управління ключами.
• Аналіз делегування через LST-протоколи: яка частка загального стейку проходить через них, як ці протоколи розподіляють стейк, чи є перекриття в наборах валідаторів, які вони використовують.

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

Тип ризику	Критерій порогу	Що змінюється при досягненні порогу	Метод перевірки
Порушення життєздатності (liveness)	Сукупна голосуюча вага коаліції ≥ 33%	Можливість блокувати фіналізацію блоків, зупинка мережі	Розрахунок коефіцієнта Накамото за актуальними даними стейку з урахуванням ефективного контролю
Порушення безпеки (safety)	Сукупна голосуюча вага коаліції ≥ 67%	Можливість подвійних витрат через конфліктні гілки	Те саме для порогу 67%; додатково — оцінка економічної доцільності атаки порівняно з вартістю втраченого стейку
Каскадна деградація	Чіткого порогу немає; залежить від кореляції відмов	Тимчасове уповільнення мережі, пропуски слотів, збільшення затримок транзакцій	Аналіз інфраструктурного перекриття між валідаторами (див. сусідній матеріал про хмарних провайдерів)
Економічна координація (MEV, цензура)	Чіткого протокольного порогу немає; залежить від стимулів	Зміна порядку транзакцій, виключення певних транзакцій з блоків	Аналіз делегування через LST-протоколи, моделі комісій, виявлення спільного володіння або управління

Невизначеність і межі

Що насправді означає «активність» валідатора

Для оцінки концентрації потрібно відрізняти три речі: право будь-якого оператора приєднатися до permissionless-кластера, фактичне голосування валідатора в консенсусі та потрапляння його ідентичності до вибірки, з якої формується stake-weighted leader schedule. Документація Anza прямо зазначає, що фіксованого ліміту на кількість активних валідаторів у консенсусі немає.

Тому ризик не варто описувати як «стейк усередині малого active set проти стейку поза ним». Практичне питання інше: яка частка голосуючої ваги реально зосереджена під спільним контролем або спільними операційними залежностями, і як ця концентрація впливає на здатність мережі досягати супербільшості та продовжувати роботу.

Роль ліквідного стейкінгу в структурі концентрації

Протоколи ліквідного стейкінгу змінюють не лише розподіл стейку, а й структуру стимулів для всіх учасників. Індивідуальний делегатор має прямий стимул обирати валідатора з високою надійністю та прийнятною комісією. Користувач LST-токена має стимул обирати протокол із найвищою доходністю та найнижчим ризиком депегування (зменшення співвідношення токену до базового активу). Рішення про те, які валідатори отримують стейк, приймає керуючий протокол за власним алгоритмом.

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

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

Що змінює відсутність протокольного slashing

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

Це не дає простого висновку, що атака «дешева» або «дорога»: така оцінка потребує окремої моделі загроз, актуального розподілу стейку, вартості інфраструктури й аналізу того, як мережа та її учасники реагують на конфліктну поведінку. Якщо slashing буде реалізовано в майбутньому, ці стимули доведеться переоцінити за фактичними правилами нової реалізації.

Невизначеність, яку не можна усунути без даних

• Реальний коефіцієнт Накамото з урахуванням ефективного контролю (не номінального делегування) — потребує аналізу структури LST-протоколів та виявлення прихованих зв’язків між валідаторами.
• Ступінь операційної зв’язності між великими валідаторами — без аналізу інфраструктури (хостинг, клієнтське ПЗ, управління ключами) цей параметр невідомий.
• Реальна здатність великих валідаторів або LST-протоколів координуватися — це питання мотивів, можливостей та довіри, які не вимірюються безпосередньо з даних ланцюга.
• Поведінка мережі при частковій втраті активних валідаторів — теоретичні моделі існують, але емпіричні дані залежать від конкретних інцидентів, які неможливо відтворити в контрольованих умовах.
• Динаміка переведення делегування при кризовій ситуації — чи делегатори швидко переведуть стейк від проблемних валідаторів, чи їхня поведінка посилить кризу через масове переведення.

Висновок і наступна перевірка

Концентрація стейку стає системним ризиком при наближенні до порогів консенсусу (33% для життєздатності, 67% для безпеки), але реальна небезпека часто виникає раніше — через приховану координацію, інфраструктурну зв’язність або каскадні ефекти від комбінації цих факторів. Жоден із цих вимірів неможливо оцінити лише за номінальним розподілом стейку між валідаторами.

Межа висновку. Матеріал пояснює, як концентрація голосуючої ваги створює різні класи ризику, але не оголошує поточний розподіл стейку «прийнятним» чи «неприйнятним». Така оцінка потребує датованого набору даних і явно заданої моделі загроз.

Що потрібно перевірити перед публікацією

• Актуальний розподіл стейку за валідаторами з розбивкою на пряме делегування та LST-делегування. Джерело: експлорер мережі або незалежний аналітичний інструмент. Метод: агрегація даних з ланцюга з фільтрацією за типом делегування. Обов’язкова вказівка дати зрізу.
• Коефіцієнт Накамото для порогів 33% і 67% з урахуванням щонайменше двох визначень «незалежності»: номінального (різні адреси валідаторів) та економічного (різні ефективні контролери).
• Технічна коректність опису Tower BFT, механізмів стейкінгу та leader schedule — з окремою перевіркою, щоб термін active set у розкладі лідерів не подавати як фіксований ліміт консенсусних валідаторів.
• Поточний статус slashing — за актуальною документацією він не реалізований у протоколі; будь-яку майбутню зміну треба перевіряти за первинними джерелами перед публікацією.

Обмеження цього матеріалу

Цей матеріал не містить оцінки поточного стану концентрації стейку в мережі Solana, не наводить конкретних цифр розподілу стейку, не ідентифікує конкретних валідаторів або LST-протоколів як ризикових чи безпечних. Він описує принципову структуру ризику та критерії його оцінки. Географічний та інфраструктурний виміри розглядаються в сусідніх матеріалах цього кластера: Географія валідаторів: що вона говорить про стійкість мережі та Хмарні провайдери й дата-центри: де виникає спільна точка відмови.

Наступний крок для читача

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

Первинні джерела. Розмежування між permissionless-участю валідаторів і active set у leader schedule звірено з FAQ Anza для валідаторів та документацією про leader rotation. Поточний статус slashing звіряється окремо з документацією Solana про стейкінг.

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