Нові пропозиції щодо управління Солани: Стратегічний зсув

Фонд Solana офіційно запустив пропозиції щодо управління Solana (SGP), що є значним кроком у тому, як мережа ухвалює рішення. SGP проти SIMD: «Чому» проти «Як» Щоб зрозуміти SGP, спершу потрібно зрозуміти, чим воно не є. Багато хто природно порівнюватиме його з існуючим процесом документів удосконалення Solana (SIMD), але вони служать двом різним цілям:
SIMD — це інженерні плани: вони відповідають на «як» має бути реалізована технічна зміна. Вони перевіряються основними розробниками для забезпечення цілісності протоколу.

• SGP — це директивні мандати: вони відповідають на «чи варто нам це робити?». Це стосується волі спільноти та стратегії високого рівня. Думайте про це так: SGP — це політична воля, тоді як SIMD — це інженерна реалізація.

Чудовим прикладом цього є пропозиція «Alpenglow». Раніше спільнота намагалася просунути її через процес SIMD до того, як технічні деталі були повністю готові. Це створювало тертя, оскільки розробникам потрібне було «зелене світло» на концепцію, перш ніж витрачати час на створення плану. Завдяки SGP спільнота тепер може спершу проголосувати «так», підтвердивши напрямок, перш ніж починається важка інженерна робота.

| Особливість | | --- | SGP (Пропозиції управління Solana) | SIMD (Документи вдосконалення Solana) | | --- | --- | --- | | Основне питання | «Чи варто нам це робити?» | «Як саме це зробити?» | | Рівень | Високорівневий, директивний | Детальна специфікація протоколу | | Хто ухвалює рішення | Голосування в мережі з урахуванням частки | Технічний огляд основними розробниками | | Необхідна зрілість | Чітка ідея, що заслуговує сигналу спільноти | Повний, реалізовний дизайн |

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

• Поріг: Щоб запустити голосування SGP, пропозиція має отримати підтримку щонайменше 15% від загальної активної частки мережі.
• Мета: Цей високий бар’єр гарантує, що мережа не засмічується тривіальними голосуваннями. Це «запобіжний клапан», призначений для питань з довгостроковим економічним впливом, де спільнота вимагає місця за столом.

Як працює механіка Коли ініціюється SGP, він слідує структурованому, прозорому шляху. Кожна пропозиція складається з документа у форматі Markdown (з детальним обґрунтуванням) та запису в мережі, прив’язаного до конкретного, незмінного SHA коміту. Це гарантує, що пропозиція, за яку голосують, не може бути змінена під час процесу. Правила голосування:

• Подання: Вимагає валідатора з часткою щонайменше 100 000 SOL.
• Запуск: 15% активних часток мають висловити підтримку для переходу до формального голосування.
• Схвалення: Вимагає кваліфікованої більшості у дві третини (66,67%) часток, що беруть участь у голосуванні «За» та «Проти» (утримані виключаються).
• Терміни: Повний цикл триває приблизно 22 дні (11 епох) з моменту досягнення порогу підтримки до остаточного результату.

Загальна картина: Дозрівання управління Роками критики Solana полягали в тому, що її управління було надто централізованим і покладалося на досвід основних розробників. Хоча такий підхід дозволяв досягти неймовірної швидкості та продуктивності, він залишав стейкерів та валідаторів почуватися пасажирами в чужому автобусі. SGP змінює цю динаміку, кодифікуючи голос спільноти. Він не передає ключі від королівства DAO і не сповільнює критично важливу інженерію. Натомість він створює формальний канал для економічних і стратегічних рішень, які раніше покладалися на неформальний консенсус. Справжнім випробуванням стануть наступні місяці. Ми спостерігатимемо, як часто досягається поріг у 15% і чи будуть суперечливі економічні зміни успішно проведені через цей новий процес. Наразі це є зрілою, виваженою еволюцією для Solana — спосіб збалансувати потребу в швидкій, експертній інженерії з необхідністю управління через спільноту.