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

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

Визначення та призначення SIMD

Solana Improvement Document: формат та процес

SIMD — це структурований текстовий документ у форматі Markdown, який описує конкретну пропозицію щодо зміни протоколу. Кожен SIMD містить:

  • Мотивацію — яку проблему вирішує пропозиція та чому це важливо для мережі
  • Специфікацію — технічний опис змін, часто з фрагментами коду на Rust та описом нових інтерфейсів
  • Вплив на сумісність — чи ламає зміна існуючі інтерфейси, які смарт-контракти або інструменти можуть перестати працювати
  • Альтернативи — які інші підходи розглядалися й чому їх відхилили

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

Аналогія з EIP у Ethereum та BIP у Bitcoin

У Ethereum аналогічну роль виконують EIP (Ethereum Improvement Proposal), у Bitcoin — BIP (Bitcoin Improvement Proposal). Принципова подібність у тому, що всі три системи:

  • Фіксують пропозицію в стандартизованому форматі з обов'язковими розділами
  • Вимагають публічного обговорення перед реалізацією
  • Розділяють пропозиції на категорії (консенсусні, стандартні, інформаційні)

Відмінність Solana полягає в архітектурних наслідках. Оскільки історично Solana використовує єдиний клієнт на Rust (з появою додаткових реалізацій ситуація може змінюватися), рішення щодо SIMD часто безпосередньо впливають на конкретну кодову базу, а не на узгодження між кількома незалежними реалізаціями, як у Ethereum з його клієнтами на Rust, Go, Java та Nim.

Життєвий цикл SIMD-пропозиції

Стадії: Draft → Review → Implemented → Active

Життєвий цикл SIMD не є жорстко формалізованим бюрократичним процесом, але на практиці виділяють кілька стадій:

  • Draft — автор подає початкову версію документа. На цьому етапі пропозиція може бути незавершеною, містити відкриті питання або кілька альтернативних варіантів рішення. Це етап розвідки, а не фінальна специфікація.
  • Review — спільнота та ключові інженери аналізують пропозицію. Тут відбувається технічна критика, виявлення вразливостей, оцінка впливу на продуктивність та безпеку. Ця стадія може тривати тижнями або місяцями.
  • Implemented — зміни закодовані в гілці клієнта, зазвичай у форматі feature flag. Це означає, що код існує, але ще не активований у мережі.
  • Active — зміна активована в мережі через оновлення клієнта валідаторами. З цього моменту пропозиція фактично працює.

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

Хто має право подавати та затверджувати SIMD

Подати SIMD може будь-хто. Формального бар'єра входу не існує — достатньо створити Pull Request у відповідному репозиторії. Проте практичний вплив пропозиції залежить від технічної обґрунтованості, якості аналізу альтернатив та авторитету автора в спільноті.

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

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

Як відстежувати SIMD

Офіційні джерела та репозиторії

Основне джерело — репозиторій solana-foundation/solana-improvement-documents на GitHub. Саме тут зберігається канонічний перелік усіх SIMD із їхніми поточними статусами та текстами пропозицій. Додатково варто моніторити:

  • Обговорення в категорії SIMD на офіційному форумі спільноти Solana
  • Pull Request у репозиторії клієнта Agave, де реалізуються конкретні SIMD
  • Комунікації ключових інженерів та команд, що працюють над конкретними пропозиціями

Критичне ставлення: SIMD ≠ активована функція

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

Типова помилка — будувати операційні рішення або економічні прогнози на основі SIMD, який перебуває на стадії Draft або Review. Для прийняття рішень використовуйте лише підтверджені факти: активовані зміни в мережі, версії клієнтів, які запущені валідаторами, та реальну поведінку консенсусу.

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