- Тема
29k Популярность
10k Популярность
4k Популярность
15k Популярность
60k Популярность
31k Популярность
2k Популярность
111k Популярность
26k Популярность
26k Популярность
- Закрепить
29k Популярность
10k Популярность
4k Популярность
15k Популярность
60k Популярность
31k Популярность
2k Популярность
111k Популярность
26k Популярность
26k Популярность
Ethereum Соглашение слой непрерывно два вечера кратковременные аномалии Сеть самовосстановление подчеркивает устойчивость PoS
Анализ кратковременных аномалий Ethereum за две ночи подряд
11 и 12 мая в течение двух ночей произошли кратковременные аномалии на уровне консенсуса Эфира. Анализ показывает, что это было в основном вызвано чрезмерной нагрузкой на некоторые клиентские узлы уровня консенсуса Эфира, что привело к выходу из строя узлов валидаторов. Это напрямую повлияло на то, что голосование Epoch не смогло достичь порога в 2/3, что сделало невозможным подтверждение финальности на уровне консенсуса. Тем не менее, сеть Эфира быстро восстановила нормальную работу, что также демонстрирует устойчивость и способность к самоисцелению алгоритма консенсуса PoS Эфира.
Обзор событий
Как правило, состояние сети Ethereum PoS консенсуса будет окончательно определено в течение 2 эпох. Однако на прошлой неделе произошло два случая задержки окончательного определения эпох:
В этот период сеть Ethereum продолжала создавать блоки и обрабатывать транзакции. Однако из-за недостаточной ставки голосования узлов-валидаторов Эпоха не может быть утверждена, то есть не может быть достигнута гарантия уровня безопасности консенсуса сети Ethereum PoS. Это означает, что в крайних случаях транзакции внутри этой эпохи могут быть отменены.
На самом деле, в этот период в сети Ethereum не произошло ни одного форка, и узлы-валидаторы не проводили злонамеренное голосование. Прямой причиной того, что эпоха не могла быть завершена, стало недостаточное количество голосов из-за того, что большое количество узлов-валидаторов были оффлайн. Наблюдения показали, что у оффлайн узлов-валидаторов возникли аномалии, связанные с перегрузкой CPU.
Во втором событии, из-за задержки подтверждения более чем на 4 эпохи, была активирована механика утечки неактивности алгоритма консенсуса Эфира:
Анализ причин
Прямой причиной этого события стало чрезмерное количество нагрузки на некоторые узлы клиентов уровня консенсуса Ethereum, что привело к отключению узлов валидаторов и невозможности нормального участия в голосовании по консенсусу. Подробный анализ представлен ниже:
При получении свидетельства (, указывающего на устаревший блок, узлы должны заново вычислить состояние цепочки сигналов для проверки этих свидетельств, что потребует значительных ресурсов ЦПУ и памяти. Когда одновременно поступает множество свидетельств, указывающих на устаревшие блоки, ресурсы ЦПУ и памяти узлов исчерпываются, что приводит к отключению этих узлов-валидаторов.
Теоретически, такие проблемы можно решить с помощью кеша, основанного на указателе на блоки свидетельств. Однако из-за увеличения числа валидаторов и появления большого количества таких аттестаций, кеш клиентов, в котором произошла ошибка, был разрушен, и узлы были вынуждены расходовать много ресурсов для повторного вычисления состояния цепи Эфир.
Клиенты уровня консенсуса Teku и Prysm выпустили патч-версии для решения этой проблемы. Клиент патч-версии будет фильтровать эти устаревшие свидетельства, то есть игнорировать свидетельство, когда выполняются следующие условия:
![Почему Ethereum на протяжении двух ночей испытывал кратковременные сбои? Анализ причин события])https://img-cdn.gateio.im/webp-social/moments-93dc511107c2b8ba99b85fe1c242b76b.webp(
Преимущества дизайна Ethereum
В этом событии Ethereum сохранил доступность, продолжая генерировать блоки и обрабатывать транзакции, лишь отложив окончание Epoch. Это стало возможным благодаря двум основным факторам:
) Разнообразие клиентов Ethereum
Хотя у клиентов Teku и Prysm возникли проблемы, это не влияет на нормальную работу других клиентов уровня консенсуса. Например, клиент Lighthouse в этот раз не пострадал. Поскольку разные клиенты имеют различия в реализации дизайна, тем не менее, некоторые узлы валидаторов продолжают нормально функционировать.
Разнообразие клиентов Ethereum гарантирует, что даже если некоторые клиенты сталкиваются с проблемами ### или даже приводят к тому, что Epoch не может быть зафиксирован (, это не повлияет на нормальные клиенты, которые создают блоки и обрабатывают транзакции, что обеспечивает доступность Ethereum.
) Дизайн доступности алгоритма консенсуса Gasper
Гарантия доступности Ethereum является одной из отправных точек разработки алгоритма Gasper, который разделяет создание блоков и их подтверждение. Таким образом, даже если подтверждение блоков затруднено, создание блоков не прекращается. Учитывая, что в большинстве случаев подтверждение блоков в конечном итоге восстанавливается, реальное влияние на пользователей будет незначительным.
В отличие от этого, другие алгоритмы консенсуса BFT останавливают узлы консенсуса от создания следующего блока в случае неудачи подтверждения блока, что делает всю блокчейн-систему недоступной в этот период.
Кроме того, второе событие также активировало механизм утечки бездействия, который в основном предназначен для обеспечения того, чтобы Ethereum мог повторно зафиксировать блоки, даже если в экстремальных ситуациях ### большое количество валидаторов долгое время будет офлайн (.
![Почему Ethereum дважды подряд испытывал кратковременные сбои? Анализ причин события])https://img-cdn.gateio.im/webp-social/moments-3bbc1797156b2a00d2fe30c0b5c1a567.webp(
Опыт и выводы
) Проблемы многопользовательских клиентов Ethereum
Текущая разнообразие клиентов Ethereum все еще нуждается в дальнейшей пропаганде и рекламе. Если клиенты будут достаточно разнообразными, чтобы доля Prysm и Teku была меньше 1/3, то это событие даже не произойдет ### 2/3 клиентов нормально работают, чтобы подтвердить Epoch (.
Кроме того, когда у клиента возникает проблема, необходимо решить, как узлы-валидаторы безопасно переключаются на нормальную реализацию клиента. Этот процесс включает в себя:
) Мониторинг консенсуса Ethereum
Необходимы услуги, подобные Safe Head, для постоянного мониторинга реального состояния сети Ethereum PoS, чтобы заранее выявлять и предупреждать о подобных событиях, а не ждать, пока эпоха не сможет быть определена, чтобы обнаружить аномалии в состоянии сети.
Популяризация алгоритма консенсуса Ethereum
Это событие выявило необходимость популяризации механизма консенсуса PoS Эфира. Многие пользователи ошибочно считали, что "Эфир упал", что вызвало ненужную панику. На самом деле сеть Ethereum продолжала генерировать блоки и обрабатывать транзакции. Популяризация знаний о блокчейне для пользователей по-прежнему остается направлением, в котором специалистам необходимо продолжать работать.
Прозрения для приложений на Ethereum
Хотя сеть Ethereum достаточно устойчива, время от времени нестабильность может оказывать определенное влияние на приложения. Приложения должны правильно обрабатывать эти нестабильные сценарии:
Резюме
Это событие продемонстрировало устойчивость и способности к самовосстановлению алгоритма консенсуса PoS Эфира, а также быструю реакцию команды разработчиков клиентского ПО и их способности к исправлению ошибок. Для экосистемы Ethereum необходимо продолжать инвестировать в следующие направления: увеличение разнообразия клиентов, оптимизация мониторинга состояния сети в реальном времени и предупреждения, углубление образования пользователей, улучшение экосистемы участников в экстренных ситуациях сети.
![Почему Эфир не работал кратковременно две ночи подряд? Анализ причин события]###https://img-cdn.gateio.im/webp-social/moments-b286aa6918497b555cf460e5c4e5f0cb.webp(