Блокчейн Jinjin Finance, 10 июня Ошибка в коде сортировщика Arbitrum на этой неделе привела к тому, что функция сети по пакетной отправке транзакций была временно прервана, и транзакции не могли быть подтверждены в основной цепочке. С тех пор уязвимость была устранена, и функция отправки пакета транзакций была восстановлена. 10 июня фонд Arbitrum Foundation опубликовал отчет об анализе ошибки сортировщика Arbitrum. Далее давайте рассмотрим случай и выясним, почему эта ошибка не привела к потере средств пользователей.
Хронология события ошибки Arbitrum Sorter
В 06:04:53 7 июня 2023 г. эмитент пакета не смог обновить свое представление состояния L1 из-за временной проблемы с узлом сопоставления Arbitrum L1. Из-за проблемы с первопричиной сортировщик Arbitrum продолжал пытаться запросить состояние своего предыдущего номера блока представления L1. Это означает, что даже после того, как проблема с временным узлом L1 разрешится сама собой, пакетный издатель будет продолжать пытаться запросить статус старых номеров блоков L1, а узел L1 больше не будет иметь своего статуса, поскольку он не является архивным узлом.
В 09:38:28 7 июня 2023 г. пакетный плакат Arbitrum прекратил публикацию транзакций, так как был достигнут настроенный максимальный лимит транзакций в очереди (256), который совпадает с лимитом мемпула. Если этот предел не достигнут, массовая публикация будет продолжаться в обычном режиме.
В 11:09 7 июня 2023 г. из-за неопубликованных пакетов в смарт-контракте Sequencer Inbox было активировано предупреждение о проверке новых пакетов, и предупреждение было отправлено в канал Slack.
В 11:10 отсутствие последних пакетных выпусков вызвало оповещение на основе журнала и отправило оповещение о критическом уровне в канал Slack.
В 11:13 член команды сообщества инициировал PagerDuty вместе с членом команды SRE, который сразу признал инцидент и начал реагировать.
Утром в 11:19:02 команда SRE перезапустила пакетный плакат, но из-за ранее упомянутого максимального лимита транзакций в очереди пакетный плакат не смог опубликовать транзакции. Команда SRE заметила эту проблему и начала переключаться на стороннего поставщика L1 RPC, пытаясь смягчить проблему.
В 11:24:16, через 5 минут после запуска пакетного плаката, он обновил представление состояния L1 и опубликовал первый пакет транзакций.
В 11:25:09 конфигурация плаката пакетной обработки была изменена для использования стороннего поставщика RPC L1 и перезапущена, поскольку группа SRE уже начала вносить это изменение и не заметила пакетную обработку. После перезапуска пакетные транзакции продолжают выполняться.
В 11:30:21 утра, через 5 минут после запуска плаката партии, представление состояния L1 было обновлено, что привело к рассинхронизации состояния L1, что также было основной причиной проблемы. Состояние L1 было обновлено до конечного номера блока 17428199, но он использовал последний одноразовый номер 178078, который соответствует последнему блоку в то время, вместо последнего блока, хранящегося в его состоянии, в результате чего все транзакции в очереди в Redis были стерты, кроме , так как Redis считает эти транзакции подтвержденными.
В 11:30:26 постер партии опубликовал новую партию. Redis полагается на представление состояния L1, чтобы определить, что публиковать, но на данный момент очередь Redis пуста, как указывалось ранее, состояние L1 неверно, и пакет был опубликован со случайным числом в состоянии 178078, но для определения партии для публикации с использованием нерелевантного номера блока 17428199, в результате чего была опубликована старая партия с серийным номером 229209, которая была фактически опубликована в 11:24:16 ранее, а затем перезапуск плаката партии. Поскольку старый пакет 229209 уже опубликован, транзакция L1, отправленная пакетом, была отменена.
В 11:36:35 на адресе плаката партии закончился эфир, потому что он не возместил плату за газ, поэтому он прекратил публикацию.Это преднамеренный механизм, предотвращающий потребление плакатом партии всего газа, хранящегося в стоимость восстановительной партии.
В 11:46 члену команды Nitro позвонили, чтобы решить программную проблему с пакетным восстановлением.
Около 11:58 Arbitrum начал получать отчеты о том, что некоторые пользователи обнаружили проблему с сортировщиком (передача вновь отсортированных транзакций на узлы RPC), поскольку все больше и больше упорядоченных транзакций возникало из-за проблем с пакетной публикацией. в цепочке эта проблема в первую очередь затрагивает клиентов канала с плохим подключением к Интернету или недостаточным выделением памяти, поскольку они с большей вероятностью отключатся и столкнутся с проблемами повторного подключения. Arbitrum рекомендует пользователям, использующим несколько узлов RPC, запускать локальную ретрансляцию каналов, чтобы уменьшить требуемую внешнюю полосу пропускания.
В 12:03 Arbitrum снял ограничение скорости подачи Cloudflare, чтобы облегчить проблему достижения клиентами ограничения скорости при попытке повторного подключения после отключения из-за подключения к Интернету.
В 12:05 Arbitrum снял все ограничения скорости Cloudflare, чтобы увеличить использование общедоступных RPC для тех, чьи узлы испытывали проблемы с поддержанием соединений с каналами.
В 12:12:09 постер ошибочной партии был закрыт, а хранилище очередей Redis очищено для удаления плохого состояния.
В 12:12:40 на старой версии v2.0.14 запустилась батч постер, и рут проблемы не было.
В 12:21:56 первая партия недавно открытых плакатов была успешно запущена, и с тех пор они работают непрерывно.
Извлеченные уроки событий ошибки сортировщика Arbitrum
Сбой был вызван ошибкой в пакетном плакате. Сам секвенсор не был затронут или прерван и продолжал обрабатывать транзакции на протяжении всего процесса. Сообщения о том, что секвенатору не хватило средств, неверны. Механизм финансирования Arbitrum состоит из двух кошельков, а именно: кошелька «секвенсора» и кошелька «возврата газа». Только когда секвенсор сможет успешно выпустить пакет, он будет возвращен. Сеть Arbitrum не возместила секвенатору для этого сбой средств и связанные с этим проблемы не были вызваны тем, что у секвенатора закончились средства, поэтому средства пользователей не подвергались риску.
Arbitrum очистит параметры конфигурации, которые были добавлены во временное решение. Позже он планирует переоценить проблемы тайм-аута клиента и сервера секвенсора, чтобы повысить надежность сети в случае невыполненных транзакций. .2" бета-версия. Кроме того, Arbitrum создаст общедоступную страницу состояния сети, чтобы избежать путаницы в случае возникновения проблем с сервисом.
Эта статья взята с официального сайта Arbitrum Foundation.
Посмотреть Оригинал
Содержание носит исключительно справочный характер и не является предложением или офертой. Консультации по инвестициям, налогообложению или юридическим вопросам не предоставляются. Более подробную информацию о рисках см. в разделе «Дисклеймер».
Golden Observation | Обзор события ошибки сортировщика Arbitrum
Автор: Голден Финанс Джейсон
Блокчейн Jinjin Finance, 10 июня Ошибка в коде сортировщика Arbitrum на этой неделе привела к тому, что функция сети по пакетной отправке транзакций была временно прервана, и транзакции не могли быть подтверждены в основной цепочке. С тех пор уязвимость была устранена, и функция отправки пакета транзакций была восстановлена. 10 июня фонд Arbitrum Foundation опубликовал отчет об анализе ошибки сортировщика Arbitrum. Далее давайте рассмотрим случай и выясним, почему эта ошибка не привела к потере средств пользователей.
Хронология события ошибки Arbitrum Sorter
В 06:04:53 7 июня 2023 г. эмитент пакета не смог обновить свое представление состояния L1 из-за временной проблемы с узлом сопоставления Arbitrum L1. Из-за проблемы с первопричиной сортировщик Arbitrum продолжал пытаться запросить состояние своего предыдущего номера блока представления L1. Это означает, что даже после того, как проблема с временным узлом L1 разрешится сама собой, пакетный издатель будет продолжать пытаться запросить статус старых номеров блоков L1, а узел L1 больше не будет иметь своего статуса, поскольку он не является архивным узлом.
В 09:38:28 7 июня 2023 г. пакетный плакат Arbitrum прекратил публикацию транзакций, так как был достигнут настроенный максимальный лимит транзакций в очереди (256), который совпадает с лимитом мемпула. Если этот предел не достигнут, массовая публикация будет продолжаться в обычном режиме.
В 11:09 7 июня 2023 г. из-за неопубликованных пакетов в смарт-контракте Sequencer Inbox было активировано предупреждение о проверке новых пакетов, и предупреждение было отправлено в канал Slack.
В 11:10 отсутствие последних пакетных выпусков вызвало оповещение на основе журнала и отправило оповещение о критическом уровне в канал Slack.
В 11:13 член команды сообщества инициировал PagerDuty вместе с членом команды SRE, который сразу признал инцидент и начал реагировать.
Утром в 11:19:02 команда SRE перезапустила пакетный плакат, но из-за ранее упомянутого максимального лимита транзакций в очереди пакетный плакат не смог опубликовать транзакции. Команда SRE заметила эту проблему и начала переключаться на стороннего поставщика L1 RPC, пытаясь смягчить проблему.
В 11:24:16, через 5 минут после запуска пакетного плаката, он обновил представление состояния L1 и опубликовал первый пакет транзакций.
В 11:25:09 конфигурация плаката пакетной обработки была изменена для использования стороннего поставщика RPC L1 и перезапущена, поскольку группа SRE уже начала вносить это изменение и не заметила пакетную обработку. После перезапуска пакетные транзакции продолжают выполняться.
В 11:30:21 утра, через 5 минут после запуска плаката партии, представление состояния L1 было обновлено, что привело к рассинхронизации состояния L1, что также было основной причиной проблемы. Состояние L1 было обновлено до конечного номера блока 17428199, но он использовал последний одноразовый номер 178078, который соответствует последнему блоку в то время, вместо последнего блока, хранящегося в его состоянии, в результате чего все транзакции в очереди в Redis были стерты, кроме , так как Redis считает эти транзакции подтвержденными.
В 11:30:26 постер партии опубликовал новую партию. Redis полагается на представление состояния L1, чтобы определить, что публиковать, но на данный момент очередь Redis пуста, как указывалось ранее, состояние L1 неверно, и пакет был опубликован со случайным числом в состоянии 178078, но для определения партии для публикации с использованием нерелевантного номера блока 17428199, в результате чего была опубликована старая партия с серийным номером 229209, которая была фактически опубликована в 11:24:16 ранее, а затем перезапуск плаката партии. Поскольку старый пакет 229209 уже опубликован, транзакция L1, отправленная пакетом, была отменена.
В 11:36:35 на адресе плаката партии закончился эфир, потому что он не возместил плату за газ, поэтому он прекратил публикацию.Это преднамеренный механизм, предотвращающий потребление плакатом партии всего газа, хранящегося в стоимость восстановительной партии.
В 11:46 члену команды Nitro позвонили, чтобы решить программную проблему с пакетным восстановлением.
Около 11:58 Arbitrum начал получать отчеты о том, что некоторые пользователи обнаружили проблему с сортировщиком (передача вновь отсортированных транзакций на узлы RPC), поскольку все больше и больше упорядоченных транзакций возникало из-за проблем с пакетной публикацией. в цепочке эта проблема в первую очередь затрагивает клиентов канала с плохим подключением к Интернету или недостаточным выделением памяти, поскольку они с большей вероятностью отключатся и столкнутся с проблемами повторного подключения. Arbitrum рекомендует пользователям, использующим несколько узлов RPC, запускать локальную ретрансляцию каналов, чтобы уменьшить требуемую внешнюю полосу пропускания.
В 12:03 Arbitrum снял ограничение скорости подачи Cloudflare, чтобы облегчить проблему достижения клиентами ограничения скорости при попытке повторного подключения после отключения из-за подключения к Интернету.
В 12:05 Arbitrum снял все ограничения скорости Cloudflare, чтобы увеличить использование общедоступных RPC для тех, чьи узлы испытывали проблемы с поддержанием соединений с каналами.
В 12:12:09 постер ошибочной партии был закрыт, а хранилище очередей Redis очищено для удаления плохого состояния.
В 12:12:40 на старой версии v2.0.14 запустилась батч постер, и рут проблемы не было.
В 12:21:56 первая партия недавно открытых плакатов была успешно запущена, и с тех пор они работают непрерывно.
Извлеченные уроки событий ошибки сортировщика Arbitrum
Сбой был вызван ошибкой в пакетном плакате. Сам секвенсор не был затронут или прерван и продолжал обрабатывать транзакции на протяжении всего процесса. Сообщения о том, что секвенатору не хватило средств, неверны. Механизм финансирования Arbitrum состоит из двух кошельков, а именно: кошелька «секвенсора» и кошелька «возврата газа». Только когда секвенсор сможет успешно выпустить пакет, он будет возвращен. Сеть Arbitrum не возместила секвенатору для этого сбой средств и связанные с этим проблемы не были вызваны тем, что у секвенатора закончились средства, поэтому средства пользователей не подвергались риску.
Arbitrum очистит параметры конфигурации, которые были добавлены во временное решение. Позже он планирует переоценить проблемы тайм-аута клиента и сервера секвенсора, чтобы повысить надежность сети в случае невыполненных транзакций. .2" бета-версия. Кроме того, Arbitrum создаст общедоступную страницу состояния сети, чтобы избежать путаницы в случае возникновения проблем с сервисом.
Эта статья взята с официального сайта Arbitrum Foundation.