Ошибка в архитектурном проектировании, которая потребовала 5 лет, чтобы понять
В декабре 2024 года Solana объявила о важном прорыве: клиент validator Firedancer перешел в режим основной сети после 100 дней успешных тестов, в ходе которых некоторые валидаторы успешно обработали 50 000 блоков. Но это событие — не только о производительности — впервые Solana действительно решила проблему структуры, которая за пять лет вызвала пять самых серьезных сбоев.
Корень проблемы очень прост: почти 90% валидаторов в сети работают на одном и том же программном обеспечении — клиенте Agave. Когда 70-90% мощности консенсуса блокчейна работают на базе одного кода, любая ошибка в этом клиенте — не локальная проблема, а проблема всей сети. Время подтверждения менее одной секунды или способность обрабатывать тысячи транзакций в секунду теряют смысл, если программная ошибка может заблокировать всю цепочку.
Ethereum понял этот урок еще при переходе на Proof-of-Stake: разнообразие клиентов — не оптимизация, а требование жесткой безопасности. Solana сейчас пытается догнать, но стартует с гораздо более централизованной позиции.
Сеть, страдающая из-за выбора технологий
История сбоев Solana — это коллекция катастроф, которые происходили по очереди. Остановка в июне 2022 года длилась 4,5 часа после ошибки в функции durable-nonce, которая вызвала рассинхрон валидаторов. Затем возникали сбои из-за утечек памяти, чрезмерного дублирования транзакций и условий гонки при создании блоков.
Анализ от Helius всей истории сбоев показывает, что пять из семи случаев связаны с ошибками валидатора или клиента, а не с ошибками в дизайне консенсуса. Иными словами, Solana останавливалась не из-за ошибок в основном механизме, а из-за багов в программном обеспечении, реализующем этот механизм.
Текущий уровень централизации делает это особенно опасным. Отчет о состоянии сети за июнь 2025 года от Solana Foundation показывает, что Agave и его вариация Jito-modified контролируют 92% SOL, поставленных в стейк. К октябрю 2025 года эта цифра снизилась лишь немного. По данным Cherry Servers, клиент Jito-Agave по-прежнему удерживает более 70% стейка, хотя появился гибридный клиент под названием Frankendancer — использующий сетевой слой Firedancer, но сохраняющий бэкенд согласования Agave — примерно 21%. Первый оригинальный Firedancer еще не имеет стейка, так как находится в стадии «голого» режима основной сети без голосования.
То, что 70% стейка зависит от одного кода, означает, что ошибка в Agave все равно может вывести сеть из строя.
Firedancer: архитектура с нуля, а не исправление
Firedancer — не обновление или форк Agave. Это полностью переписанный на C/C++ клиент, созданный Jump Crypto по архитектуре, заимствованной из систем высокоскоростных транзакций. Эти два клиента не делят исходный код, язык программирования или даже структуру обслуживания.
Важно: эта независимость создает отдельные области ошибок.
Утечка памяти в Agave (на C++), написанном на Rust###, не перейдет в код Firedancer, написанный на C/C++. Логическая ошибка в планировщике блоков Agave не повлияет на модель исполнения по ячейкам Firedancer. Когда два клиента могут терпеть неудачу независимо, сеть может пережить серьезную ошибку одного из клиентов, если стейк достаточно широко распределен, чтобы исключить блокировку консенсуса из-за отключения одного клиента.
( Frankendancer: умный переход
Frankendancer — промежуточная точка. Он использует сетевые компоненты и создание блоков Firedancer, но сохраняет слой согласования и исполнения Agave. Это позволяет валидаторам получать улучшения по производительности Firedancer, не рискуя всей сетью из-за неподтвержденного кода согласования.
Рост доли Frankendancer с примерно 8% в июне до 21% в октябре показывает, что гибридная модель привлекает. Но важно: пока все валидаторы используют слой Agave для согласования, ошибка в этом слое все равно может вывести сеть из строя — даже при 21% стейка у Frankendancer.
Именно поэтому полноценный mainnet Firedancer в декабре — настоящий прорыв.
Что изменит Firedancer в производительности и надежности
Бенчмарки показывают, что Firedancer обрабатывает от 600 000 до более 1 000 000 транзакций в секунду в тестах, превосходя доказанную пропускную способность Agave. Но цифры по пропускной способности — не главное.
Главное — восстановление. Firedancer спроектирован с четкими модулями: сетевой компонент, слой согласования и исполнение транзакций — разделены. Ошибка в одном компоненте не распространяется на другие. 100 дней работы и 50 000 блоков доказали, что этот клиент может участвовать в согласовании, создавать валидные блоки и поддерживать состояние без зависимости от Agave.
Пока что это ограниченный опыт — всего 100 дней на нескольких узлах по сравнению с многолетней работой Agave в основной сети. Но этого достаточно, чтобы открыть дверь. У валидаторов есть реальная альтернатива, и восстановление сети будет прямо пропорционально скорости перехода от однобокой культуры.
Выбор клиента оператором: бизнес-решение, а не только техническое
Термин «оператор» )оператор/администратор( в контексте блокчейна обозначает организации, запускающие валидаторские узлы — от инфраструктурных компаний вроде Lido или Rocket Pool до частных операторов. Их решение о выборе клиента — бизнес-решение, а не только техническое.
Организации рассматривают Solana как платформу для производства — и задаются вопросом: что произойдет при сбое? Сеть, где 90% валидаторов работают на одном клиенте, — это одна точка отказа. Сеть, где ни один клиент не контролирует более 33% стейка, — это сеть, которая может потерять один клиент из-за ошибки, но продолжить работу.
Разрыв между Solana )767 миллионов долларов активов, токенизированных( и Ethereum )12,5 миллиардов долларов — не только о сетевом эффекте или внимании разработчиков. Это о доверии к времени работы. Организационные рисковые менеджеры требуют надежности, прежде чем вкладывать в создание важных приложений.
Levex отметил, что Firedancer «решает ключевые опасения, которые высказали институциональные инвесторы относительно надежности Solana», и что разнообразие клиентов «обеспечивает устойчивость, необходимую бизнесу для важных приложений».
Будущее: от централизации к децентрализации
Переход от доминирования Agave с 70% к многообразной сети с несколькими клиентами — не произойдет быстро. Операторам придется столкнуться с затратами на переход: Firedancer требует настройки аппаратного обеспечения, изменения процедур эксплуатации и других характеристик. 100-дневный опыт, хоть и успешный, — еще малая часть многолетней работы Agave. Осторожные операторы будут ждать больше данных.
Но текущая структура стимулов поддерживает диверсификацию. Публичные отчеты о состоянии валидаторов отслеживают распределение клиентов, создавая репутационное давление на крупных операторов. История сбоев сети — ясное напоминание. А история принятия решений организациями — с ETF, RWA, корпоративными платежами — зависит от доказательств, что Solana преодолела проблемы надежности.
Сейчас у Solana есть два клиента, написанных на разных языках, с независимым исходным кодом. Архитектура готова. Вопрос — смогут ли операторы перейти достаточно быстро?
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Firedancer официально запущен: Solana наконец-то избавилась от опасной "одинокого клиента"
Ошибка в архитектурном проектировании, которая потребовала 5 лет, чтобы понять
В декабре 2024 года Solana объявила о важном прорыве: клиент validator Firedancer перешел в режим основной сети после 100 дней успешных тестов, в ходе которых некоторые валидаторы успешно обработали 50 000 блоков. Но это событие — не только о производительности — впервые Solana действительно решила проблему структуры, которая за пять лет вызвала пять самых серьезных сбоев.
Корень проблемы очень прост: почти 90% валидаторов в сети работают на одном и том же программном обеспечении — клиенте Agave. Когда 70-90% мощности консенсуса блокчейна работают на базе одного кода, любая ошибка в этом клиенте — не локальная проблема, а проблема всей сети. Время подтверждения менее одной секунды или способность обрабатывать тысячи транзакций в секунду теряют смысл, если программная ошибка может заблокировать всю цепочку.
Ethereum понял этот урок еще при переходе на Proof-of-Stake: разнообразие клиентов — не оптимизация, а требование жесткой безопасности. Solana сейчас пытается догнать, но стартует с гораздо более централизованной позиции.
Сеть, страдающая из-за выбора технологий
История сбоев Solana — это коллекция катастроф, которые происходили по очереди. Остановка в июне 2022 года длилась 4,5 часа после ошибки в функции durable-nonce, которая вызвала рассинхрон валидаторов. Затем возникали сбои из-за утечек памяти, чрезмерного дублирования транзакций и условий гонки при создании блоков.
Анализ от Helius всей истории сбоев показывает, что пять из семи случаев связаны с ошибками валидатора или клиента, а не с ошибками в дизайне консенсуса. Иными словами, Solana останавливалась не из-за ошибок в основном механизме, а из-за багов в программном обеспечении, реализующем этот механизм.
Текущий уровень централизации делает это особенно опасным. Отчет о состоянии сети за июнь 2025 года от Solana Foundation показывает, что Agave и его вариация Jito-modified контролируют 92% SOL, поставленных в стейк. К октябрю 2025 года эта цифра снизилась лишь немного. По данным Cherry Servers, клиент Jito-Agave по-прежнему удерживает более 70% стейка, хотя появился гибридный клиент под названием Frankendancer — использующий сетевой слой Firedancer, но сохраняющий бэкенд согласования Agave — примерно 21%. Первый оригинальный Firedancer еще не имеет стейка, так как находится в стадии «голого» режима основной сети без голосования.
То, что 70% стейка зависит от одного кода, означает, что ошибка в Agave все равно может вывести сеть из строя.
Firedancer: архитектура с нуля, а не исправление
Firedancer — не обновление или форк Agave. Это полностью переписанный на C/C++ клиент, созданный Jump Crypto по архитектуре, заимствованной из систем высокоскоростных транзакций. Эти два клиента не делят исходный код, язык программирования или даже структуру обслуживания.
Важно: эта независимость создает отдельные области ошибок.
Утечка памяти в Agave (на C++), написанном на Rust###, не перейдет в код Firedancer, написанный на C/C++. Логическая ошибка в планировщике блоков Agave не повлияет на модель исполнения по ячейкам Firedancer. Когда два клиента могут терпеть неудачу независимо, сеть может пережить серьезную ошибку одного из клиентов, если стейк достаточно широко распределен, чтобы исключить блокировку консенсуса из-за отключения одного клиента.
( Frankendancer: умный переход
Frankendancer — промежуточная точка. Он использует сетевые компоненты и создание блоков Firedancer, но сохраняет слой согласования и исполнения Agave. Это позволяет валидаторам получать улучшения по производительности Firedancer, не рискуя всей сетью из-за неподтвержденного кода согласования.
Рост доли Frankendancer с примерно 8% в июне до 21% в октябре показывает, что гибридная модель привлекает. Но важно: пока все валидаторы используют слой Agave для согласования, ошибка в этом слое все равно может вывести сеть из строя — даже при 21% стейка у Frankendancer.
Именно поэтому полноценный mainnet Firedancer в декабре — настоящий прорыв.
Что изменит Firedancer в производительности и надежности
Бенчмарки показывают, что Firedancer обрабатывает от 600 000 до более 1 000 000 транзакций в секунду в тестах, превосходя доказанную пропускную способность Agave. Но цифры по пропускной способности — не главное.
Главное — восстановление. Firedancer спроектирован с четкими модулями: сетевой компонент, слой согласования и исполнение транзакций — разделены. Ошибка в одном компоненте не распространяется на другие. 100 дней работы и 50 000 блоков доказали, что этот клиент может участвовать в согласовании, создавать валидные блоки и поддерживать состояние без зависимости от Agave.
Пока что это ограниченный опыт — всего 100 дней на нескольких узлах по сравнению с многолетней работой Agave в основной сети. Но этого достаточно, чтобы открыть дверь. У валидаторов есть реальная альтернатива, и восстановление сети будет прямо пропорционально скорости перехода от однобокой культуры.
Выбор клиента оператором: бизнес-решение, а не только техническое
Термин «оператор» )оператор/администратор( в контексте блокчейна обозначает организации, запускающие валидаторские узлы — от инфраструктурных компаний вроде Lido или Rocket Pool до частных операторов. Их решение о выборе клиента — бизнес-решение, а не только техническое.
Организации рассматривают Solana как платформу для производства — и задаются вопросом: что произойдет при сбое? Сеть, где 90% валидаторов работают на одном клиенте, — это одна точка отказа. Сеть, где ни один клиент не контролирует более 33% стейка, — это сеть, которая может потерять один клиент из-за ошибки, но продолжить работу.
Разрыв между Solana )767 миллионов долларов активов, токенизированных( и Ethereum )12,5 миллиардов долларов — не только о сетевом эффекте или внимании разработчиков. Это о доверии к времени работы. Организационные рисковые менеджеры требуют надежности, прежде чем вкладывать в создание важных приложений.
Levex отметил, что Firedancer «решает ключевые опасения, которые высказали институциональные инвесторы относительно надежности Solana», и что разнообразие клиентов «обеспечивает устойчивость, необходимую бизнесу для важных приложений».
Будущее: от централизации к децентрализации
Переход от доминирования Agave с 70% к многообразной сети с несколькими клиентами — не произойдет быстро. Операторам придется столкнуться с затратами на переход: Firedancer требует настройки аппаратного обеспечения, изменения процедур эксплуатации и других характеристик. 100-дневный опыт, хоть и успешный, — еще малая часть многолетней работы Agave. Осторожные операторы будут ждать больше данных.
Но текущая структура стимулов поддерживает диверсификацию. Публичные отчеты о состоянии валидаторов отслеживают распределение клиентов, создавая репутационное давление на крупных операторов. История сбоев сети — ясное напоминание. А история принятия решений организациями — с ETF, RWA, корпоративными платежами — зависит от доказательств, что Solana преодолела проблемы надежности.
Сейчас у Solana есть два клиента, написанных на разных языках, с независимым исходным кодом. Архитектура готова. Вопрос — смогут ли операторы перейти достаточно быстро?