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

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

Предложение, опубликованное 30 октября, исходит от Бреннана Уотта, генерального директора Anza, компании по разработке блокчейнов, стоящей за Agave, одной из основных программного обеспечения, используемого для работы сети Solana.

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

Изменение может решить растущую проблему, поскольку Solana расширяется за пределы своего первоначального программного обеспечения для валидаторов, включая независимо разработанные альтернативы, такие как Firedancer, созданная торговой компанией Jump Crypto.

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

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

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

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

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

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

Новый свод правил может изменить процесс обновления Solana

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

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

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

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

Где начинается и заканчивается проект свода правил Solana

Прямое соответствие начинается с доверенного состояния и остается в пределах эталонной эпохи 1072.
ДОВЕРЕННЫЙ ВХОД ПРОЕКТ ЭТАЛОННОЙ ЭПОХИ 1072 Доверенное состояние Снимок состояния или состояние, аутентифицированное для Прямого соответствия Применить указанные правила в пределах E Первый банк E+1 Вне этой версии Ранее отмененные правила не нужно воспроизводить. Схематическая граница области; расстояние не представляет времени. эпоха-E корень
ПРОЕКТ ЭТАЛОННОЙ ЭПОХИ 1072 Доверенный вход Доверенное состояние Снимок состояния или состояние, аутентифицированное для Прямого соответствия Применить указанные правила В пределах E только Первый банк E+1 Вне этой версии Ранее отмененные правила не нужно воспроизводить. Схематическая; расстояние не представляет времени. к эпохе-E корень

Где начинается клиент?

Где начинается клиент? Последний банк перед E Уже внутри E Строительство дочернего банка применяет переход границы эпохи-E один раз перед своими транзакциями. ПОСЛЕДНИЙ БАНК ПЕРЕД E Доверенное состояние Применить один раз Переход границы эпохи ВНУТРИ E Транзакции Перед транзакциями дочернего банка Последний банк перед E Применить один раз Переход границы эпохи Транзакции внутри E Переход предшествует этим транзакциям Доверенное состояние уже включает переход границы эпохи, поэтому его не следует применять снова. ВНУТРИ E ВНУТРИ E Доверенное состояние Транзакции Переход границы уже включен в начальное состояние Уже внутри E Доверенное состояние Переход границы уже включен в начальное состояние Транзакции в E Продолжайте без повторного применения перехода.

Общее правило делает цель явной. Доверие начального состояния и следующая эпоха остаются отдельными требованиями.

Это проект спецификации, а не принятые изменения протокола. Он не устанавливает правильность начального состояния, историческую репликацию или непрерывную работу в E+1. Никакое увеличение надежности клиента не количественно оценено. Источники и доказательства

Источники

1. Область применения и соответствие
2. Проект справочного периода эпохи

Поддерживающие факты

• Проектная целевая страница определяет его основную сеть как справочный период эпохи E=1072; область применения начинается с реализации из доверенного снимка для этой эпохи или другого состояния, аутентифицированного к корню эпохи-1072. [2] [1]
• Проект требует соответствия в пределах его справочного периода и не требует воспроизведения кодировок или веток правил, которые перестали приниматься до этой эпохи. [1]
• Проект применяется только к банкам в справочном периоде E и явно не определяет первый банк E+1, поэтому соответствие только этой версии не устанавливает непрерывную работу через эту границу. [1]
• В соответствии с проектом реализация, начинающаяся в последнем банке перед E, применяет переход границы эпохи один раз; начальное состояние, уже находящееся внутри E, не должно применять его снова. [1]
• Соответствие вперед оставляет начальный снимок или аутентифицированный корень в качестве входных данных доверия: проект начинается после того, как этот ввод был принят, а не требует от нового клиента доказательства всей предыдущей цепочки путем воспроизведения. [1]

Метод

Схема, основанная на проектной целевой странице и главе области применения, зафиксирована 4 ноября 2026 года. Два выбираемых состояния инициализации воспроизводят правило границы проекта; геометрия качественная, без продолжительности или шкалы производительности.

Область применения

Это проект спецификации, а не принятые изменения протокола. Он не устанавливает правильность начального состояния, историческую репликацию или непрерывную работу в E+1. Никакое увеличение надежности клиента не количественно оценено. Инфографика от CryptoSlate

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

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

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

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