Бип, бип, бип. Бип, бип, бип.

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

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

Знакомство

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

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

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

Исторические случаи сбоев и ухудшения производительности Solana

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

Живучесть и безопасность

Согласно теореме CAP, также известной как теорема Брюэра, распределенная система может достичь только двух из трех свойств:

• Согласованность — при каждом чтении отображаются все предыдущие записи.
• Доступность - каждый запрос получает ответ.
• Отказоустойчивость - Система продолжает работать несмотря на разделение сети.

Для блокчейнов устойчивость к разделам имеет важное значение — сбои в работе сети неизбежны. Это вынуждает выбирать между AP (доступность + допуск секций) и CP (согласованность + допуск секций). Как и большинство PoS-цепочек с быстрым завершением, Solana отдает приоритет согласованности, а не доступности, что делает ее CP-системой. Он останавливается во время критических сбоев, а не обслуживает устаревшие данные или разрешает небезопасную запись. Хотя это означает, что программное обеспечение узла может перейти в невосстановимое состояние, требующее ручного вмешательства, это гарантирует, что средства пользователей останутся в безопасности.

Позиция Solana в компромиссах теоремы CAP

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

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

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

Перезапуск сети

Перезапуск сети Solana включает в себя определение последнего оптимистично подтвержденного слота блока и перезагрузку узлов из доверенного локального снимка состояния этого слота. Поскольку слот перезапуска не определяется в блокчейне, операторы валидаторов должны достичь консенсуса вне сети, чтобы договориться о безопасной точке отката. Эта координация происходит публично в канале #mb-валидаторов в Solana Tech Discord, где профессиональные операторы валидаторов общаются в режиме реального времени. Большинство операторов имеют автоматизированные системы оповещения, которые уведомляют их о моменте остановки производства блока, обеспечивая быстрое реагирование.

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

Сообщение об ошибках

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

Награды предлагаются за действительные отчеты о критических уязвимостях, с выплатами, основанными на серьезности:

• Потеря средств: до 25 000 SOL
• Нарушения консенсуса или безопасности: до 12 500 SOL
• Живучесть или потеря доступности: до 5,000 SOL

Кроме того, клиент FireDancer имеет отдельную программу по поиску ошибокразмещенный через Immunefi, предлагающий максимальную награду в размере 500 000 долларов США в USDC за критические результаты.

Инциденты сбоев

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

Ошибка турбины: декабрь 2020

Время простоя: примерно шесть часов

Проблема: Ошибка распространения блока

Исправления:

• Отслеживать блоки по хэшу вместо номера слота
• Исправьте места в турбине, где обнаружение сбоев можно провести раньше
• Распространите первое обнаруженное неисправность на всех валидаторов через сплетни

Это простой был вызван предыдущая известная проблема восстановления блока и обработки кодавызванный неопознанной ошибкой вМеханизм передачи блоков Solana. Сбой произошел, когда валидатор передал два разных блока для одного и того же слота и распространил их на два отдельных раздела (A и B), в то время как третий раздел независимо обнаружил несоответствие.

Поскольку каждый раздел владел лишь миноритарным пакетом акций, ни один из них не мог достичь консенсуса абсолютного большинства для продвижения цепочки. Основная проблема заключалась в том, как внутренние структуры данных Solana отслеживают блоки и их вычислительное состояние. Система использовала номер слота Proof of History (PoH) (идентификатор u64) для ссылки на состояние и блок в этом слоте. После того, как сеть разделилась на разделы, узлы неправильно интерпретировали блоки A и B как идентичные, что препятствовало правильному восстановлению и синхронизации блоков.

Каждый раздел предполагал, что у другого есть тот же блок, что привело к фундаментальному конфликту:

• Узлы, удерживающие блок A, отклонили вилки, происходящие от блока B
• Узлы, содержащие блок B, отклонили форки, производные от блока A

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

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

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

IDO Протокола Grape: сентябрь 2021

Время простоя: Семнадцать часов

Основная проблема: Переполнение памяти, вызванное транзакциями ботов

Исправления:

• Игнорировать блокировки записи в программах
• Ограничения скорости на пересылку транзакций
• Настроенное поведение повторных RPC
• Приоритизация транзакций по голосованию TPU

14 сентября 2021 года Solana пережила крупную сетевую задержку после запуска Grape Protocol своего ончейн предложения по инициальному декстоку (IDO) на краудфандинговой платформе Raydium AcceleRaytor. В течение 12 минут после IDO сеть была перегружена непревзойденным потоком транзакций, вызванных ботами, и перестала производить корневые слоты. Эти боты эффективно осуществили распределенную атаку отказом в обслуживании (DDoS), выталкивая нагрузку транзакций за пределы пропускной способности сети.

Во время пика загруженности:

• Некоторые валидаторы получали более 300 000 транзакций в секунду.
• Скорость необработанных транзакций превысила 1 Гбит/с, а количество пакетов — 120 000 в секунду.
• Иногда трафик превышал физические пределы сетевых интерфейсов, вызывая потерю пакетов на порту коммутатора еще до достижения валидаторов.

Скорость слотов Solana во время сбоя Grape IDO 14 сентября 2021 года(Источник данных: Jump Crypto)

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

Исправление, которое игнорирует блокировки на запись программ, уже было разработано и запланировано к выпуску. Позже перезагрузка сети позволила это обновление, окончательно удалив этот вектор атаки.

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

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

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

Ошибка вторая: целочисленное переполнение

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

Высокая загруженность: Январь 2022

Время простоя: Нет

Корень проблемы: Чрезмерное количество дублирующихся транзакций

Частичное исправление:

• Релизы 1.8.12 и 1.8.14 Solana
• Оптимизация дедупликации SigVerify
• Улучшена производительность кэша исполнителя

В период с 6 по 12 января 2022 года в основной сети Solana наблюдалась серьезная перегрузка сети, что привело к снижению производительности и частичным отключениям. Сбой был вызван тем, что боты рассылали спам с чрезмерным количеством повторяющихся транзакций, что значительно снизило пропускную способность сети. Обработка блоков заняла больше времени, чем ожидалось, что привело к разветвлению следующего лидера и дальнейшему снижению пропускной способности. На пике успешность транзакций упала на целых 70%. Клиент изо всех сил пытался справиться со все более сложными и ресурсоемкими транзакциями сети, что выявило ограничения в его способности удовлетворять спрос.

Дополнительная нестабильность произошла с 21 по 23 января, с сохранением заторов. 22 января общедоступная конечная точка RPC (https://api.mainnet-beta.solana.com) был отключен из-за злоупотреблений, поскольку заспамленные пакетные вызовы RPC перегрузили систему.

Для решения этих проблем, Solana 1.8.12 релиз был специально направлен на исчерпание кэша программы, в то время версия 1.8.14 внесла улучшения в кэш Sysvar, отбрасывание SigVerify и дедупликацию SigVerify.

Спам от автоматов с конфетами: апрель / май 2022

Время простоя: восемь часов

Основная проблема: Спам транзакций от бот-аккаунтов

Исправления:

• Налог на бота в программе автомата с конфетами
• Улучшения памяти в Solana v1.10

30 апреля 2022 года Solana пережила беспрецедентный всплеск запросов на транзакции. Некоторые узлы сообщили о достижении шести миллионов запросов в секунду, генерируя более 100 Гбит/с трафика на узел. Этот всплеск был вызван ботами, пытающимися обезопасить недавно отчеканенные NFT через программу Metaplex Candy Machine. Этот механизм чеканки работал в порядке живой очереди, создавая сильный экономический стимул наводнить сеть транзакциями и выиграть монетный двор.

30 апреля / 1 мая 2022 г. Сбой Candy Machine, пакетов в секунду(Источник данных: Jump Crypto)

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

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

30 апреля / 1 мая 2022 года сбой в работе автомата для сладостей, активные валидаторы (Источник данных: Jump Crypto)

Перезапуск сети занял менее 1,5 часов после того, как было согласовано каноническое снимок. Solana v1.10 включила улучшения использования памяти, чтобы продлить время, в течение которого узлы могут выдерживать медленное или застывшее согласие.

Однако фундаментальные вопросы остались нерешенными. Лидер до сих пор обрабатывал транзакции, борясь за те же данные учетной записи на основе принципа "кто первый встал, того и тапки", без эффективной борьбы со спамом, из-за чего пользователи были не в состоянии определить срочность своих транзакций. Для решения этой проблемы были предложены три долгосрочные механизмы в качестве практических решений.

Принятие QUIC: Ранее Solana полагалась на сетевой протокол UDP (User Datagram Protocol) для отправки транзакций через Gulf Stream от узлов RPC текущему лидеру. Несмотря на то, что UDP является быстрым и эффективным, он не требует соединения, в нем отсутствует управление потоком и подтверждение приема. Соответственно, не существует действенного способа предотвратить или смягчить оскорбительное поведение. Для контроля над сетевым трафиком протокол приема транзакций валидатора (т. е. Fetch Stage TPU) был перереализован с помощью QUIC.

QUIC пытается предложить лучшее от TCP и UDP. Он облегчает быструю, асинхронную связь, подобную UDP, но с безопасными сеансами и передовыми стратегиями контроля потока TCP. Это позволяет ограничивать отдельные источники трафика, чтобы сеть могла сосредоточиться на обработке подлинных транзакций. QUIC также имеет понятие отдельных потоков, поэтому, если одна транзакция отбрасывается, остальные не блокируются. QUIC в конечном итоге был интегрирован в клиент Solana Labs с выпуском 1.13.4.

Стоимостно-взвешенное качество обслуживания (SWQoS): Была представлена новая система, которая приоритизирует сетевой трафик на основе доли, удерживаемой валидаторами, обеспечивая более эффективную отправку транзакций тем, у кого больше доля. По этой схеме валидатор с 3% от общей доли может отправлять до 3% от общего количества пакетов лидеру. SWQoS действует как мера устойчивости к Сибилловым атакам, что делает более сложным затопление сети низкокачественными транзакциями злонамеренными участниками. Данный подход заменяет предыдущую модель принятия транзакций «первым поступил — первым обслужен», которая принимала транзакции без различия, не учитывая их источник.

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

Налог бота на конфетную машину

Metaplex быстро ввела жесткий налог на ботов в размере 0,01 SOL на транзакции по майнтингувзаимодействие с программой Candy Machine для борьбы со спамом, генерируемым ботами. Этот механизм борьбы со спамом вводил минимальную плату, чтобы отпугнуть злонамеренную деятельность, не наказывая законных пользователей, совершивших случайные ошибки. Налог взимался в определенных сценариях, включая:

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

Этот экономический сдерживающий фактор оказался очень эффективным. Снайперы монет были быстро истощены, и спам-активность прекратилась. В течение первых нескольких дней боттеры коллективно потеряли более 426 SOL.

Прочный баг Nonce: июнь 2022

Простой: четыре с половиной часа

Основная проблема: Устойчивая ошибка nonce, приводящая к сбою консенсуса

Исправления:

• Временное отключение устойчивых транзакций с одноразовым кодом
• Solana 1.10.23 обновление

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

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

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

Прочтите наш предыдущий блог-пост Helius, чтобы Узнайте больше о долговечных одноразовых номерах и их использовании.

Ошибка дублирования блока: сентябрь 2022 года

Время простоя: восемь с половиной часов

Основная проблема: ошибка в правилах выбора форка привела к сбою консенсуса

Исправить:

• Патч клиента

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

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

Форки - это регулярное явление на Solana, и валидаторы обычно их устраняют, выравниваясь на ветке с большинством голосов (самой тяжелой ветке). Когда валидатор выбирает неправильную ветку, ему нужно переключиться на самую тяжелую ветку, чтобы оставаться синхронизированным с сетью. Однако в этом случае валидаторы не могли вернуться к самому тяжелому банку, если его слот соответствовал их последнему проголосованному слоту. Этот недочет заставил валидаторов застрять, препятствуя прогрессу консенсуса и, в конечном итоге, приведя к остановке сети.

Сентябрь 2022: сбой в выборе вилки из-за ошибки дублирования блока (Источник: Лэйн, Майкл Хаббард)

В приведенном выше примере неисправный валидатор C создает дубликаты блоков для своих лидерных слотов с 5 по 8. Когда валидатор G становится следующим лидером, он замечает только один из дубликатов и соответственно расширяет свой форк. Однако следующий лидер, валидатор D, обнаруживает оба дублирующихся блока от валидатора C и решает отбросить их, вместо этого построив свой форк поверх слота 4.

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

Проблема была решена после проверки основной командой. Патч был объединен в основную ветку и обратно портирован во все ветки релизов.

Большой блок перегружает турбину: февраль 2023 г.

Время простоя: почти 19 часов

Корневая проблема: Сбой логики дедупликации в службах пересылки фрагментов

Исправления:

• Несколько улучшений логики дедупликации и фильтрации в Turbine
• Добавьте клиентский патч, заставляющий блок-продюсеров прерывать работу, если они генерируют большие блоки

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

Отключение крупного блока, шредов на блок, февраль 2023 г. (Источник: Лэйн, Майкл Хаббард)

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

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

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

Бесконечный цикл перекомпиляции: февраль 2024 г.

Время простоя: почти пять часов

Корневая проблема: Ошибка, вызывающая бесконечный цикл перекомпиляции в JIT-кэше

Исправления:

• Отключение устаревшего загрузчика v1.17.20

Валидатор Agave JIT компилирует все программы перед выполнением транзакций, которые на них ссылаются. Для оптимизации производительности JIT-вывод часто используемых программ кэшируется, что сокращает количество ненужных повторных компиляций. В Agave v1.16 существующий механизм кэширования, LoadedPrograms, был заменен новой реализацией под названием ExecutorsCache, которая обеспечила несколько улучшений эффективности.

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

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

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

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

В Agave v1.16 LoadedPrograms не поддерживал совместную загрузку, что позволяло упаковывать инициирующую транзакцию в блок. Затем этот блок распространялся по сети, заставляя каждого валидатора воспроизводить его и входить в один и тот же бесконечный цикл перекомпиляции. Поскольку более 95% стейка кластера работало под управлением Agave v1.17 во время сбоя, большинство валидаторов застряли на этом блоке, что привело к остановке сети.

Эта ошибка была обнаружена на прошлой неделе во время расследования сбоя кластера Devnet, и патч был запланирован для развертывания.@jeff.washington/2024-02-06-solana-mainnet-beta-outage-report-619bd75b3ce0">Выбранным методом смягчения было возврат изменений в Agave v1.17 и немедленное удаление функционального гейта при перезапуске сети. Это отключило устаревший загрузчик, ответственный за вызов ошибки, что предотвратило дальнейшие возникновения.

Согласованный патч уязвимости: август 2024 года

Время простоя: Нет

Основная проблема: неверное предположение о выравнивании адресов ELF

Исправления:

• Обновление патча

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

Программы Solana компилируются с помощью LLVM в файл Исполняемый и связываемый формат (ELF). Уязвимость возникла из-за неверного предположения о выравнивании адресов в этих сгенерированных ELF-файлах. Несмотря на то, что очистка ELF обычно приводит к выполнению различных проверок целостности, она не проверяет выравнивание раздела .text. Эта оплошность могла позволить вредоносному файлу ELF определить неправильно выровненный раздел .text, что привело бы к переходу виртуальной машины по недопустимому адресу. Это приведет к ошибке сегментации хоста, что приведет к сбою валидатора.

Злоумышленник мог воспользоваться этой уязвимостью следующим образом:

• Создание вредоносной программы Solana, использующей код операции CALL_REG.
• Манипулирование файлом ELF для смещения раздела .text.
• Развёртывание и вызов программы в сети, срабатывание валидатора.

Процесс обновления патча

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

К 7 августа несколько членов Solana Foundation связалась с валидаторами через личные сообщения на различных коммуникационных платформах, информируя их о предстоящем критическом исправлении и делясь хешированным сообщением, подтверждающим дату и уникальный идентификатор инцидента. Несколько известных членов Anza, Jito и Solana Foundation поделились этим хешем на X, GitHub и LinkedIn, чтобы проверить точность сообщения. Пример хэша shared:

В течение следующего дня основные участники продолжали обращаться к валидаторам, подчеркивая важность срочности и конфиденциальности. В заранее определенное время, 8 августа, в 14:00 UTC, операторы валидаторов получили дополнительное сообщение, содержащее инструкции по загрузке, проверке и применению патча. Патч был размещен в репозитории Github известного инженера Anza, а не в основном репозитории агавы. Инструкции включали проверку загруженных файлов исправлений на соответствие поставляемым шасумам.

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

Тихое распространение патча и закулисная координация валидаторов вызвали опасения относительно децентрализации Solana. Незадолго до инцидента исполнительный директор Solana Foundation Дэн Альберт высказался об этих критиках в интервью для СМИ.

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

Корейская неделя блокчейна (KBW) 2024

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

Заключение

На момент написания этого сообщения Solana проработала более года без сбоев, что является важным этапом для удаления тега «бета» из mainnet-beta. Частота сбоев, по-видимому, снижается по мере зрелости сети, и ожидается, что внедрение Firedancer улучшит разнообразие клиентов, уменьшая риск обнаружения ошибок или граничных случаев, вызывающих полное отключение кластера. Тем не менее, некоторые лидеры сообщества, включая основателя Helius Mert Mumtaz, предсказали, что сбои будут продолжаться. Время покажет.

Большое спасибо Zantetsu (Shinobi Systems) и OxIchigo за рецензирование более ранних версий этой работы.

Отказ:

1. Эта статья перепечатана с [Helius]. Все авторские права принадлежат оригинальному автору [Lostin]. Если есть возражения против этой перепечатки, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно решат эту проблему.
2. Отказ от ответственности: Взгляды и мнения, высказанные в этой статье, являются исключительно точкой зрения автора и не являются инвестиционными советами.
3. Команда Learn Gate занимается переводом статей на другие языки. Копирование, распространение или плагиат переведенных статей запрещены, если не указано иное.