Управление Solana: комплексный анализ

Практические выводы

• Голосования по вопросам управления Solana не имеют обязательной силы и носят рекомендательный характер, отражая настроения сообщества. Возможность для валидаторов обозначить свою позицию до полной реализации помогает направлять разработку и сводить разногласия к минимуму. Окончательное решение принимается, когда валидаторы выбирают, какое ПО запускать. Предложения могут меняться даже после голосования, и в конечном счете управление отражает консенсус, а не обеспечивает принудительное исполнение.
• Владельцы токенов SOL участвуют косвенно, делегируя застейканные SOL валидаторам, чьи решения при голосовании соответствуют их ценностям или предпочтениям. Это система пропорционального представительства, в которой валидаторов можно считать избранными представителями. Стейкеры Solana делегируют свой стейк валидаторам, а вес голоса каждого валидатора зависит от делегированного ему стейка.
• Голосование по вопросам управления Solana проводится с помощью токенов SPL. Валидаторам выделяются токены пропорционально активному стейку, после чего они отправляют эти токены на специальные адреса, соответствующие разным вариантам голосования. Валидаторы могут разделять свои голоса между несколькими вариантами. После отправки голоса становятся окончательными и не могут быть изменены.
• Все нарушающие консенсус обновления протокола активируются через шлюзы функций, которые представляют собой несовместимые с предыдущими версиями хардфорки. В отличие от Bitcoin или Ethereum, где при разногласиях хардфорк может привести к постоянному разделению цепочки, подход Solana обеспечивает активацию шлюзов функций во всем кластере в конкретном слоте. Валидаторы обновляются заранее, что предотвращает разделение цепочки.
• Несколько экономических изменений на раннем этапе развития Solana, в частности введение приоритетных комиссий со сжиганием 50%, были реализованы без формального голосования, поскольку система управления в тот период оставалась незрелой.
• Текущая модель голосования по вопросам управления, в которой голосуют только валидаторы, была утверждена после консультативного голосования в октябре 2023 года. В нем приняли участие более 170 валидаторов, представлявших 14,3% общего стейка. Более 70% этого стейка поддержали голосование только валидаторов как наиболее практичную и эффективную отправную точку.
• Недавнее голосование по SIMD-228 достигло рекордного уровня участия в 74,3% и стало крупнейшим событием в истории управления блокчейнами по числу участников и представленной рыночной капитализации. В нем участвовали 281 млн SOL (~$35 млрд), а более 900 валидаторов отдали свыше 1000 голосов. Это был первый случай активного участия крупных валидаторов бирж, таких как Coinbase, Kraken и Bybit, что подчеркивает рост институционального участия в Solana.
• Одна из постоянных проблем процесса управления Solana — ограниченная роль делегаторов в принятии решений. Сегодня не существует формального механизма, который позволял бы делегаторам выражать свои предпочтения или отменять решения валидаторов. Поэтому голоса валидаторов могут противоречить предпочтениям их делегаторов.
• Наличие установленного кворума при голосованиях по вопросам управления Solana также вызывает опасения. На практике кворум может создавать искаженные стимулы: участники стратегически воздерживаются от голосования, чтобы предложение не достигло необходимого порога. Такое поведение наблюдалось при голосовании по SIMD-228.
• Solana Foundation Delegation Program делегирует 10% общего застейканного объема SOL (41,01 млн) 897 валидаторам, увеличивая вес их голосов. Анализ недавнего голосования по SIMD-288 показывает, что стейк SFDP преимущественно использовался для голосования против предложения. Если бы этот стейк был отдан за вариант YES, предложение прошло бы. Если бы делегированный SFDP стейк воздержался, предложение все равно не прошло бы, но с меньшим отрывом: 64,77% вместо фактических 61,39%.
• По-прежнему неясно, какие вопросы требуют голосования. В марте 2025 года запланированное голосование по SIMD-218 (IVC) отменили после достижения консенсуса о том, что одобрение через систему управления не требуется. Аналогично, прошедшее SIMD-123 не было однозначно экономическим изменением и, вероятно, не требовало формального голосования.

Введение

Управление — критически важный компонент децентрализации, влияющий на все: от обновлений протокола и экономической политики до поведения валидаторов и стандартов сообщества. Эффективная система управления повышает прозрачность, справедливость и доверие, тогда как неэффективное управление может привести к путанице, стагнации или централизации власти.

Система управления Solana все еще находится на ранней стадии развития. Как и многие блокчейн-сети, Solana не запускалась с полностью зрелой или формализованной системой управления. Она развивалась постепенно под влиянием практик сообщества, технических ограничений и полученных уроков. Совершенствование управления Solana — непрерывный итеративный процесс.

Экосистема Solana включает разные пересекающиеся группы заинтересованных сторон: владельцев токенов, стейкеров, пользователей, валидаторов, операторов RPC, разработчиков приложений и инженеров ядра протокола. У каждой группы свои взгляды, стимулы и цели. В некоторых областях их интересы могут совпадать, но часто расходятся, особенно в вопросах распределения ресурсов, контроля протокола и экономической политики.

В децентрализованных системах управление основано на социальном консенсусе не меньше, чем на коде. Блокчейны часто описывают принципом «код — это закон», однако история показывает, что код может и действительно будет изменен, если этого требует консенсус сообщества. Поэтому устройство механизмов управления и возможность развивать их со временем не менее важны, чем исходная техническая архитектура.

Цель этого отчета — прояснить структуру, развитие и текущее состояние управления Solana. В нем всесторонне рассматривается, как в сети принимаются решения и чем ее управление отличается от других блокчейн-экосистем. Материал разделен на четыре основных раздела:

• Элементы управления Solana — рассматриваются основные компоненты процесса управления Solana, включая SIMDs, активацию шлюзов функций и формальные ончейн-голосования.
• Анализ голосований по вопросам управления — подробный обзор всех состоявшихся формальных голосований, включая результаты, поведение голосующих и показатели участия.
• Проблемы и рекомендации — анализ ключевых проблем текущей модели управления Solana и практические рекомендации, где это уместно.
• Сравнение с альтернативными сетями — обзор управления в сопоставимых экосистемах Cosmos и Ethereum с выделением практик, которые могли бы помочь улучшить Solana.

Хотя отчет лучше читать по порядку, каждый раздел самодостаточен и может быть прочитан отдельно.

Элементы управления Solana

В таблице ниже представлен обзор системы управления Solana, структурированный с помощью аналитической модели, адаптированной из статьи Анализ принятия решений в управлении блокчейнами за авторством Schädler, Lustenberger и Spychiger (2023). Мы адаптировали эту модель с учетом конкретных механизмов и динамики экосистемы Solana.

Изменения протокола Solana проходят многоэтапный процесс, который зависит от характера и последствий изменения. Ключевые факторы: нарушает ли изменение консенсус, как оно влияет на заинтересованные стороны и насколько велики связанные с ним разногласия или сложность. Нарушающим консенсус считается любое обновление протокола, из-за которого ноды с разными версиями ПО расходятся во мнении о состоянии блокчейна. 

В следующей таблице перечислены типичные этапы для изменений разного масштаба. «Крупными» считаются изменения, которые могут иметь экономические последствия.

Ниже мы подробно опишем процессы активации шлюзов функций, SIMDs и голосований по вопросам управления.

Активация шлюзов функций

Команды разработчиков ядра Anza и Firedancer регулярно выпускают новые функции, включая системные вызовы, нативные программы и экономические изменения, нарушающие консенсус. Эти функции создаются, включаются в новые версии клиентского ПО и по умолчанию отключаются с помощью флага функции. Программа Feature Gate, недавно перенесенная в программу Core BPF, отслеживает каждую новую функцию как аккаунт. Приватный ключ, уникальный для каждого шлюза функции, принадлежит разработчику ядра, связанному с этим шлюзом. Когда достаточная доля застейканных валидаторов обновляется до новой версии и она признается стабильной, переключатель функции среды выполнения активируется вручную с помощью инструкции. Функция запускается на всех нодах сети в начале следующей эпохи. Точный порядок и время активаций можно отслеживать в расписании шлюзов функций. Активация функций не зависит от кластера: сначала она происходит в Testnet, затем в Devnet и наконец в Mainnet. Это позволяет убедиться в надежности новых версий до окончательной активации в Mainnet.

«Минимальная версия» — текущая минимальная поддерживаемая версия ПО кластера. По мере активации новых шлюзов функций минимальная версия повышается до версии ПО, в которую была включена соответствующая функция. Новые функции в Solana активируются регулярно, обычно на границах эпох, приходящихся на рабочее время в будние дни. Во время перехода между версиями активации приостанавливаются и возобновляются примерно через две эпохи после того, как 95% стейка обновятся до нового минорного релиза (например, с версии 2.2 до 2.3).

Активации шлюзов функций — это несовместимые с предыдущими версиями хардфорки, для вступления которых в силу требуется всеобщее принятие. Если валидатор не обновится до версии, распознающей активированный шлюз функции, он не сможет продолжать валидацию глобального состояния и разойдется с сетью.

В отличие от Bitcoin или Ethereum, где при разногласиях хардфорк может привести к постоянному разделению цепочки, подход Solana гарантирует активацию шлюзов функций во всем кластере в конкретном слоте. Валидаторы должны обновиться заранее, что предотвращает разделение цепочки. Поэтому шлюзы функций являются хардфорками, поскольку меняют правила консенсуса, но не могут привести к появлению конкурирующих цепочек.

Новые версии клиентов также включают множество изменений, не нарушающих консенсус, например рефакторинг кода и оптимизацию эффективности. Для них шлюзы функций не требуются.

Документы по улучшению Solana (SIMDs)

Предложения Solana Improvement Document (SIMD) — это формальная документация, необходимая для любого существенного изменения основных компонентов Solana. «Существенными» считаются изменения, которые обычно затрагивают сетевой протокол, действительность транзакций или совместимость. Несущественные изменения, такие как небольшой рефакторинг кода или объективные улучшения производительности, не требуют предложений. В предложениях следует документировать обоснование функции и приводить достаточно сведений для понимания реализации. 

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

Существует два типа предложений: 

• Стандартные предложения: затрагивают основные функции Solana (например, консенсус, сетевое взаимодействие и интерфейсы API)
• Метапредложения: касаются процессов или рекомендаций за пределами кодовой базы

SIMDs обычно проходят этапы проверки идеи, подготовки черновика, рассмотрения и принятия. Формальное рассмотрение проходит публично на GitHub. Автор предложения отвечает за сбор отзывов соответствующих разработчиков ядра из команд клиентов Agave и Firedancer. С учетом безопасности, компромиссов и обратной совместимости они решают, принять, пересмотреть или отозвать предложение.

Авторы не обязаны реализовывать свои предложения, но обычно им рекомендуют это сделать, поскольку так выше вероятность успешного завершения работы. Принятые предложения часто включают связанную задачу для отслеживания реализации функции и обычно требуют активации через механизм шлюзов функций Solana. 

Хотя SIMD требуется не для каждой активации шлюза функции, большинство из них сопровождаются таким документом, который предоставляет контекст, обоснование и стандартизированную запись предлагаемого изменения.

Голосования по вопросам управления

Для существенных SIMDs, изменяющих протокол, особенно тех, которые влияют на экономические параметры, требуется голосование по вопросам управления. Процесс управления Solana, возглавляемый опытными участниками сообщества валидаторов, сосредоточен только на критически важных вопросах, чтобы поддерживать вовлеченность и не допускать усталости от управления. Поэтому ежегодно проводится лишь несколько голосований.  

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

Голосование проводится с помощью токенов SPL. На аккаунт идентификации каждого активного валидатора выделяются токены пропорционально его активному стейку, измеренному в лампортах. Затем валидатор может отправить эти токены на специальные адреса, соответствующие разным вариантам голосования, включая воздержание. Валидаторы могут разделять голоса между несколькими вариантами, например выделить 80% варианту YES и 20% варианту NO. Это позволяет гибко учитывать разные предпочтения их стейкеров. После отправки голоса становятся окончательными и не могут быть изменены.

В этой структуре владельцы токенов SOL участвуют косвенно, делегируя застейканные SOL валидаторам, чьи решения при голосовании соответствуют их ценностям или предпочтениям. Это система пропорционального представительства, в которой валидаторов можно считать избранными представителями. Стейкеры Solana делегируют свой стейк валидаторам, а вес голоса каждого валидатора зависит от его активного стейка.

Ограничения ончейн-управления

toly 🇺🇸

@toly

@garious14 There is no “governance”. It’s just a signal to check if the proposed upgrade would cause a contentious fork. It has to come from validators.

17 мар. 2025 г., 3:56 PM

Управление Solana в конечном счете не имеет обязательной силы и носит рекомендательный характер. На практике настоящее голосование происходит, когда валидаторы выбирают, какую версию ПО запускать. Голосования по вопросам управления могут указывать на широкую поддержку или неприятие со стороны сообщества, но не обязывают валидаторов принимать какой-либо конкретный код. Предложения могут меняться даже после голосования, а валидаторы сохраняют полный контроль над тем, что работает в их инфраструктуре. Это означает, что управление скорее сигнализирует о консенсусе, чем обеспечивает принудительное исполнение решений.

В этих условиях основные разработчики, такие как Anza, Jump и Jito, а также поставщики инфраструктуры, такие как Helius и Triton, обладают значительным неформальным влиянием. Валидаторы вряд ли станут выступать против этих групп, рискуя потерять стейк или нарушить синхронизацию с сетью. Поэтому такие организации могут фактически определять результаты обновлений независимо от наличия у них формальных полномочий на принятие решений.

В крайнем случае, если валидаторы откажутся от обновления, может произойти форк. Предостерегающим примером остается DAO Fork в Ethereum в 2016 году, который привел к созданию Ethereum Classic. По мере развития процесса управления Solana необходимо прояснить связь между сигнальными голосованиями, выпусками ПО и фактическим принятием обновлений валидаторами. Это обеспечит прозрачность и поможет избежать маловероятного, но опасного разделения цепочки.

Анализ голосований по вопросам управления

Раннее управление Solana: 2020–2022 годы

Первоначальный подход Solana к управлению заметно отличался от нынешней модели. Раннее управление строилось вокруг программы Feature Proposal, которая позволяла валидаторам голосовать за изменения протокола с помощью токенов SPL, взвешенных по стейку. Когда новый выпуск функции был готов к активации, валидаторам выделялись токены для голосования пропорционально их активному стейку. Возвращая эти токены на специальный аккаунт в течение двух недель, валидаторы могли выразить поддержку активации предлагаемой функции. После достижения порога в 67% стейка изменение напрямую активировалось ончейн в следующую эпоху.

Программа Feature Proposal неоднократно использовалась для голосований валидаторов по вопросам управления как в Testnet, так и в Mainnet. Самым заметным из них стала активация текущего графика инфляции.

В интернете сохранилось мало сведений об этих ранних голосованиях: первоначальные форумы Solana отключены и теперь доступны только в архивных версиях Wayback Machine.

Хотя этот механизм обеспечивал некоторую ончейн-координацию, его широко критиковали. Валидаторы не могли выразить несогласие: учитывались только голоса YES, а формального способа проголосовать против или воздержаться не было. Система также создавала социальное давление в пользу одобрения изменений, особенно после того, как на реализацию уже были затрачены значительные инженерные ресурсы. 

Что еще важнее, система не позволяла заранее оценить поддержку. Поэтому сложные функции могли разрабатываться без понимания того, будут ли они приняты, что приводило к неэффективности и напрасной трате времени разработчиков.

В целом программа Feature Proposal стала важным первым шагом в развитии управления Solana, а ее ограничения помогли сформировать более гибкие механизмы, используемые сегодня.

Стоит отметить, что несколько крупных экономических изменений того раннего периода, включая введение приоритетных комиссий со сжиганием 50%, были реализованы без формальных голосований. Это отражает незрелость системы управления на тот момент.

Текущее управление Solana: с 2023 года

После использования программы Feature Proposal Solana перешла к нынешней системе голосования по вопросам управления. На данный момент состоялось пять официальных голосований:

• Первоначальное консультативное голосование в октябре 2023 года
• SIMD-33 «Своевременное начисление баллов за голоса» в апреле 2024 года, авторы Bryan Ischo и Zantetsu, Shinobi Systems
• SIMD-96 «Полная приоритетная комиссия валидаторам» в мае 2024 года, автор Tao Zhu, Anza
• SIMD-123 «Внутрипротокольное распределение вознаграждений за блоки», автор Justin Starry, Anza
• SIMD-228 «Рыночный механизм эмиссии», авторы Tushar Jain и Vishal Kankani, Multicoin Capital, а также Max Resnick, Anza, март 2025 года

Первоначальное консультативное голосование

Одним из первых критически важных решений при формировании нынешней системы управления Solana было определение участников голосования. Сообществу предложили три варианта:

1. Голосуют только валидаторы, а голоса взвешиваются по стейку
2. Голосуют валидаторы и аккаунты стейка, причем делегаторы могут отменить голос своего валидатора
3. Голосуют валидаторы, аккаунты стейка и другие заинтересованные стороны, например операторы RPC и разработчики

В консультативном голосовании приняли участие более 170 валидаторов, представлявших 14,3% общего стейка. Из участвовавшего в голосовании стейка более 70% поддержали голосование только валидаторов, а 24% предпочли модель с участием валидаторов и делегаторов. Минимальный порог участия для этого голосования не устанавливался.

Голосование только валидаторов сочли наиболее практичной и эффективной отправной точкой, поскольку необходимая инфраструктура уже существовала и была проверена на практике. Более сложные системы с участием делегаторов или других заинтересованных сторон сочли преждевременными и потенциально обременительными для зарождающегося процесса управления. Сообщество признало, что по мере развития управления альтернативные модели голосования можно будет внедрять и совершенствовать через будущие предложения.

Закономерности голосований по вопросам управления

После первоначального консультативного голосования состоялось еще четыре голосования по вопросам управления с теми же тремя вариантами: YES, NO и «Воздержаться». Эти варианты обозначают отношение к предлагаемому SIMD. Чтобы предложение прошло, его должны поддержать не менее двух третей от общей суммы голосов YES и NO, то есть проголосовать YES. 

SIMD-33: своевременное начисление баллов за голоса было одобрено подавляющим большинством — 98,4% голосов YES. Это не вызвавшее разногласий изменение консенсуса устранило несогласованные стимулы, лишив валидаторов выгоды от поздней отправки голосов. Тем самым оно улучшило поведение сети и ее справедливость.

SIMD-96: полная приоритетная комиссия валидаторам прошло с 77,7% голосов YES. Это экономическое предложение было призвано препятствовать обработке транзакций через сторонние каналы, направляя 100% приоритетных комиссий валидаторам. Хотя оно эффективно согласовало стимулы, предложение вызвало некоторые разногласия из-за небольшого увеличения инфляции и предполагаемого предпочтения валидаторов владельцам SOL.

SIMD-123: внутрипротокольное распределение вознаграждений за блоки было одобрено 74,91% голосов YES. Предложение ввело необязательный стандартизированный механизм, позволяющий валидаторам напрямую распределять вознаграждения за блоки среди стейкеров. Хотя несколько валидаторов уже делали это вручную, перенос механизма в протокол вызвал споры о конкурентном давлении и опасения, что ставки комиссии с вознаграждений за блоки могут начать «гонку к нулю».

SIMD-228: рыночный механизм эмиссии не прошло, получив лишь 61,39% голосов YES. Предложение должно было сделать уровень инфляции Solana более чувствительным к участию в стейкинге. Его авторы утверждали, что текущая эмиссия слишком высока, не реагирует на спрос на доходность и заставляет сеть переплачивать за безопасность.

Противники выражали опасения по поводу экономической жизнеспособности небольших валидаторов и дополнительной неопределенности доходности стейкинга. Голосование вызвало острые разногласия и широкую дискуссию, подчеркнув различия во взглядах на долгосрочную экономическую модель Solana.

Подробные сведения о голосовании доступны на открытых панелях для SIMD-96, SIMD-123 и SIMD-228. Кроме того, мы подготовили таблицу с доступными здесь данными голосования.

Для SIMD-228 и SIMD-123 применялся порог кворума в 33% стейка с учетом воздержавшихся. В отличие от них, более ранние предложения SIMD-96 и SIMD-33 не предусматривали минимального уровня участия и могли пройти независимо от доли проголосовавшего общего стейка.

Уровень участия

Со временем уровень участия в голосованиях рос. В первоначальном консультативном голосовании в октябре 2023 года участвовали лишь 14,3% стейка. С тех пор участие стабильно увеличивалось и достигло 74,3% в голосовании марта 2025 года по SIMD-228, рыночному механизму эмиссии. В трех других состоявшихся голосованиях уровень участия был относительно стабильным — от 51,2% до 57,1%.

Голосование по SIMD-228 стало крупнейшим событием в истории управления криптовалютами как по числу участников, так и по общей представленной рыночной капитализации. Во время обсуждения рыночная капитализация Solana была сопоставима с капитализацией Bitcoin в период споров о размере блока в середине 2017 года, что подчеркивает значимость решения. В голосовании участвовал 281 млн SOL стоимостью $35 млрд, а более 900 валидаторов отдали свыше 1000 голосов. Примечательно, что крупные валидаторы бирж, включая Coinbase, Kraken и Bybit, впервые активно участвовали в ончейн-управлении Solana. Это указывает на растущее институциональное присутствие в процессе принятия решений сетью. Недавний рост участия, особенно со стороны организаций из США, также может быть частично связан с более благоприятным регулированием блокчейнов при нынешней администрации.

Проблемы и рекомендации

В следующем разделе мы рассмотрим ключевые проблемы процесса голосования по вопросам управления и, где это уместно, предложим рекомендации по повышению прозрачности, безопасности и эффективности.

Недостаточное участие стейкеров

Одна из постоянных проблем процесса управления Solana — ограниченная роль делегаторов в принятии решений. Валидаторы голосуют за предложения с весом, зависящим от стейка, но формального механизма, позволяющего делегаторам выразить свои предпочтения или отменить решения валидаторов, не существует. Поэтому голоса валидаторов могут противоречить интересам их делегаторов, а стейкеры не имеют прямого способа повлиять на результаты управления.

Валидаторам с тысячами делегаторов трудно собирать индивидуальные предпочтения, а уровень вовлеченности стейкеров обычно низок. Некоторые валидаторы частично решают эту проблему, консультируясь перед голосованием с крупнейшими делегаторами и разделяя голоса с учетом их предпочтений. Другие экспериментировали со специальными инструментами, воспроизводящими существующую систему голосования токенами: они выпускали новые токены управления для своих стейкеров пропорционально их стейку. Однако это остается решением отдельных валидаторов, а не стандартизированной функцией всего протокола.

Противники участия стейкеров отмечают, что большинство делегаторов не обладают техническими знаниями, редко внимательно следят за решениями в сфере управления и недостаточно глубоко понимают механизмы и компромиссы блокчейна для принятия обоснованных решений. Сторонники, однако, утверждают, что опора исключительно на валидаторов создает конфликт интересов: нереалистично ожидать, что большинство валидаторов проголосует за полезные для сети предложения, если они противоречат их собственным экономическим интересам.

Среди возможных улучшений — более эффективные каналы связи между валидаторами и делегаторами, например панели управления, инструменты отслеживания настроений или даже уведомления кошелька о событиях управления. Мы вернемся к этой теме в одном из следующих разделов отчета и рассмотрим подход экосистемы Cosmos.

Проблемы дискуссий об управлении

Эффективное управление в децентрализованных экосистемах зависит от ясной и содержательной коммуникации. Однако во время недавнего предложения SIMD-288 ожесточенные споры, личные нападки и фракционность создали нездоровую среду управления и в итоге помешали продуктивному обсуждению. Обсуждение ключевых предложений по Solana может страдать от неэффективности и снижения качества полезной информации на разных платформах. Технические обсуждения на GitHub и официальных форумах Solana структурированы и содержательны, но к моменту перехода в Discord и Twitter осмысленный диалог порой вырождается во взаимные оскорбления и переходы на личности, снижая общее качество принятия решений.

Кроме того, большинство участников подключается лишь в последние дни перед голосованием, вместо того чтобы использовать весь период обсуждения. Более раннее участие и более четкая структура графика управления, при которой ключевые дискуссии проходят задолго до финального окна голосования, могли бы смягчить эти проблемы.

Созвоны по вопросам управления доказали свою эффективность: они обеспечивают прямое взаимодействие, быстрое прояснение вопросов и сокращают возможности для троллинга или введения в заблуждение. Для поддержания конструктивного процесса управления критически важно усилить модерацию, поощрять структурированные обсуждения и отдавать приоритет анализу фактов, а не конфронтации.

Объединение предложений по управлению

Решения по вопросам управления часто наиболее эффективны, когда по каждому предложению голосуют отдельно и участники могут оценить каждый вопрос по существу. Главная проблема объединения предложений — неосознанная предвзятость. Участники с твердым мнением по одному вопросу могут непреднамеренно перенести его на другие, даже если они не связаны. Это снижает вероятность взвешенного принятия решений и может помешать реализации полезных изменений.

Еще один риск заключается в том, что объединение повышает операционную сложность и вероятность ошибок. Это наблюдалось во время совместного голосования по SIMD-228 и SIMD-123, когда небольшое количество токенов, предназначенных для SIMD-123, было по ошибке отправлено на адрес воздержания для SIMD-228. Такие ошибки редки, но искажают результаты голосования и подрывают доверие к процессу управления.

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

Более эффективным подходом может быть разделение предложений по управлению везде, где это возможно, чтобы каждый вопрос оценивался независимо. Если объединение необходимо, его следует четко обосновать.

Кворумы голосования

Наличие установленного кворума в голосованиях по вопросам управления Solana вызывает опасения. На практике кворум может создавать искаженные стимулы: участники стратегически воздерживаются от голосования, чтобы предложение не достигло необходимого порога. В недавнем голосовании по SIMD-228 это было особенно заметно среди сторонников NO. В течение первых двух эпох голосования они считали воздержание более эффективной стратегией, чем активное голосование против предложения. 

Видимость текущего количества голосов влияет на участие. Некоторые валидаторы могут не голосовать, если ожидаемый результат уже соответствует их предпочтениям. Чтобы предотвратить манипуляции кворумом, можно скрывать результаты до завершения периода голосования.

С учетом этих проблем все больше участников поддерживают пересмотр или отмену требований к кворуму, чтобы участие в управлении стало более прямым и прозрачным.

Влияние SFDP

На момент написания статьи Solana Foundation Delegation Program делегирует SOL 897 валидаторам, которые составляют 66% всех активных валидаторов сети. Общая делегированная сумма равна 41,01 млн SOL, или 10% всего застейканного SOL. Подробные сведения о программе и ее стратегиях делегирования представлены в предыдущем отчете блога Helius о SFDP.

При нынешней модели управления валидаторы программы фактически получают дополнительный вес голоса и голосуют от имени Solana Foundation. Наш внутренний анализ и публичная панель недавнего голосования по SIMD-288 подтверждают, что стейк SFDP играет важную роль в результатах. В этом голосовании стейк SFDP преимущественно использовался для голосования NO против предложения. Если бы контролируемый SFDP стейк, отданный за NO или воздержавшийся, вместо этого проголосовал YES, предложение прошло бы. Если бы весь контролируемый SFDP стейк сохранил нейтралитет и воздержался, предложение все равно не прошло бы, но с меньшим отрывом: 64,77% вместо фактических 61,39% при необходимых для принятия 66,6%.

Ясность критериев проведения голосований

Изначально голосования по вопросам управления в марте 2025 года включали три предложения: SIMD-228, SIMD-123 и SIMD-218: промежуточное начисление баллов за голоса (IVC). IVC устраняет необходимость в запускаемых валидаторами модификациях, которые оптимизируют баллы за голосование Tower BFT — варианта алгоритма консенсуса pBFT в Solana. Для этого баллы за все родительские блоки автоматически начисляются задним числом, когда валидаторы голосуют за дочерний блок.

В период обсуждения сформировался консенсус о том, что SIMD-218 не должно требовать одобрения через систему управления. Изменение широко воспринималось как исправление ошибки, а не существенное изменение протокола, поскольку оно лишь улучшало или исправляло обновление Timely Vote Credits (TVC). TVC уже прошло голосование и получило широкую поддержку сообщества. Неформальный опрос валидаторов в Solana Tech Discord подтвердил эту позицию почти единодушным согласием.

Кроме того, инженеры Anza отметили, что SIMD-123 «Внутрипротокольное распределение вознаграждений за блоки» не являлось экономическим изменением, несмотря на название. Предложение вводило необязательный внутрипротокольный способ распределения вознаграждений за блоки среди стейкеров. Оно формализовало практику, которую некоторые валидаторы уже применяли альтернативными способами, и стандартизировало ранее внепротокольную деятельность.

Это поднимает важные вопросы управления:

• Кто решает, требует ли предложение голосования? Сейчас нет официального органа или структурированного процесса, определяющего, должно ли предложение проходить через управление или может быть реализовано напрямую.
• Что считается «существенным изменением протокола», по-прежнему неясно. Граница между обычным обновлением и изменением, требующим формального вмешательства системы управления, размыта, а текущие определения во многом опираются на довольно неопределенное понятие «экономического воздействия».

Проблемы безопасности

Текущий процесс голосования по предложениям управления опирается на сторонний инструмент solgov-distributor, разработанный и размещенный участником сообщества Laine. Этот инструмент является форком распределителя токенов на основе Merkle, первоначально созданного Jito. Хотя Laine пользуется большим уважением в сообществе, зависимость от внешне контролируемого инструмента требует доверия и создает риски безопасности.

• Изменяемость — как инструмент, так и его документация изменяемы, то есть в любой момент могут быть модифицированы в одностороннем порядке.
• Использование ключевых пар идентификации валидаторов — валидаторы должны собирать CLI и получать токены с помощью крайне чувствительных ключевых пар идентификации валидатора. Любой процесс, который зависит от внешнего ПО при работе с такими критически важными учетными данными, создает угрозу безопасности.
• Зависимость от отдельного сопровождающего — официальный процесс управления не должен критически зависеть от внешних третьих сторон без формальных гарантий безопасности или независимого аудита.

Альтернативные механизмы голосования

Уже существует инструмент SPL Feature Proposal (документация здесь), первоначально созданный для ончейн-управления. Однако недавние процессы управления не использовали этот подход. Вместо него применялся solgov-distributor, что вызывает вопросы о необходимости дополнительного инструмента.

В принципе, система токенов SPL уже предоставляет нативный способ распределения права голоса в управлении. Инициатор процесса мог бы просто распределить токены SPL среди всех валидаторов, чтобы они голосовали с помощью стандартного CLI spl-token, без внешнего инструмента. Это устранило бы ненужные зависимости и снизило потребность в доверии в процессе голосования.

Будущие инструменты ончейн-управления: SIMD-133

Готовящееся SIMD-133: получение стейков эпохи, которое вскоре планируется активировать в Mainnet, вводит новые инструменты управления, позволяющие программам получать веса стейков ончейн. Сейчас ончейн-программы не располагают сведениями о распределении стейка в текущей эпохе и объеме стейка, делегированного каждому аккаунту голосования.

Благодаря SIMD-133 программы управления смогут с помощью новой системной переменной создавать ончейн-снимки объемов стейка валидаторов. Это устранит необходимость в офчейн- или ручных процессах проверки стейка, значительно упростит существующий процесс управления и избавит от ручной сверки стейка.

Сравнение с альтернативными сетями

Cosmos

Цепочки Cosmos SDK предлагают ориентированную на делегаторов модель управления, в которой стейкеры могут напрямую отменить голос своего валидатора через популярные кошельки, такие как Keplr и Leap. Валидатор изначально голосует с весом всего своего стейка, но несогласные делегаторы могут перенаправить свою долю стейка на другой вариант. Например, если валидатор владеет 2% общего стейка, но делегатор с весом стейка 1% не согласен, он может проголосовать отдельно. В результате эффективный вес голоса валидатора снизится до 1%, а 1% делегатора перейдет другому варианту.

Эта система гарантирует, что последнее слово всегда остается за делегаторами, обеспечивая прозрачный, удобный и эффективный процесс управления. Участие в управлении Cosmos хорошо заметно: голосование встроено непосредственно в кошельки и обозреватели блоков, поэтому оно легко доступно всем заинтересованным сторонам.

Показательный пример различий в поведении стейкеров и валидаторов наблюдался во время голосования о сокращении эмиссии Cosmos ATOM вдвое (предложение 848, ноябрь 2023 года), целью которого было снижение максимального уровня инфляции до 10%:

• 94,93% стейкеров проголосовали YES, поддержав ограничение инфляции.
• Только 53,44% валидаторов проголосовали YES, поскольку многие стремились сохранить более высокие доходы.

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

Модуль управления Cosmos встроен на уровне протокола, что закрепляет его роль как основной функции блокчейна. Некоторые решения по вопросам управления могут автоматически исполняться ончейн, повышая прозрачность и подотчетность. 

Эта модель предлагает демократическую структуру управления, но зависит от активного участия и предполагает, что у делегаторов есть время и знания для принятия обоснованных решений. Cosmos предоставляет убедительную альтернативную модель управления, которую Solana могла бы изучить для поиска возможных улучшений.

Ethereum

Управление Ethereum основано на социальном офчейн-процессе, а не на прямом голосовании по размеру стейка. Принятие решений главным образом опирается на предложения по улучшению Ethereum (EIPs), основных разработчиков и консенсус сообщества.

Изменения Ethereum предлагаются через EIPs, эквивалентные SIMDs в Solana. Эти EIPs описывают новые функции, стандарты или обновления протокола Ethereum. Ethereum Request for Comments (ERCs) определяют стандарты функций прикладного уровня, таких как токены ERC-20 и NFT ERC-721. Эти предложения открыто обсуждаются на исследовательских форумах Ethereum (Ethereum Magicians), популярных мероприятиях Ethereum (например, Devcon, ETHDenver и ETHCC), GitHub и созвонах основных разработчиков. Широкое сообщество участвует в управлении, обсуждая предложения на таких платформах, как Discord, Farcaster и X.

В отличие от Cosmos или Solana, Ethereum не использует управление на основе стейка или голосования токенами для принятия решений по протоколу. После перехода Ethereum на Proof-of-Stake валидаторы стали активнее участвовать в консенсусе, но формально не голосуют. Вместо этого примерный консенсус достигается через технические дискуссии и широкую поддержку сообщества. Изменения протокола Ethereum в значительной степени зависят от основных разработчиков, которые поддерживают клиенты исполнения и консенсуса Ethereum, например Geth, Nethermind и Prysm.

Крупные обновления активируются через хардфорки, для которых валидаторы и операторы нод должны обновить ПО. Валидаторы обеспечивают соблюдение правил сети, решая, принимать ли новые обновления. Хотя это происходит редко, спорное изменение без консенсуса может привести к разделению цепочки, как во время прошлых форков DAO Fork (2016 год, Ethereum Classic) и, в меньшей степени, перехода Ethereum на Proof-of-Stake (2022 год, EthereumPoW).

Социальная модель управления Ethereum ставит технический консенсус и обсуждение сообществом выше формальных механизмов голосования. Это помогло Ethereum сохранить гибкость и децентрализацию, но также означает, что изменения требуют длительных обсуждений и социальной координации вместо прямого управления на основе токенов. Кроме того, у владельцев или стейкеров ETH нет формального способа голосовать по предложениям, что ограничивает прямое влияние пользователей.

Заключение

Система управления Solana продолжает развиваться под влиянием реальных экспериментов и мнений сообщества. В этом отчете рассмотрены ее основные компоненты — SIMDs, активации функций и ончейн-голосование, — а также все состоявшиеся формальные голосования, ключевые проблемы и сравнения с такими сопоставимыми сетями, как Cosmos и Ethereum. 

Экосистема Solana основана на сильной инженерной культуре, которая ценит быстрые итерации и реализацию выше длительных обсуждений. Высокая скорость обновлений выделяет Solana среди многих сопоставимых сетей, но также создает напряжение с моделями управления, которые опираются на продолжительные обсуждения в сообществе и широкую социальную координацию. Это создает уникальные сложности при поиске баланса между скоростью и инклюзивным принятием решений.

Управление Solana все еще формируется, но одно уже ясно: вовлеченность сообщества никогда не была столь высокой. По мере того как все больше заинтересованных сторон активно определяют развитие сети, Solana получает уникальную возможность создать модель управления, соответствующую ее амбициям, скорости и растущей экосистеме.

Дополнительные материалы

• Оценка децентрализации Solana: факты и цифры — блог Helius
• Аналитический центр по управлению Solana
• Управление блокчейном: программируя наше будущее — Fred Ehrsam