Анализ кратковременных аномалий слоя согласования Ethereum за две ночи подряд

Недавно на слое согласия Ethereum произошел кратковременный сбой, вызвавший широкий интерес в отрасли. В этой статье будет проведен глубокий анализ данного события.

Обзор событий

11 и 12 мая два вечера подряд на уровне соглашения Эфира произошли кратковременные сбои. Анализ показывает, что это произошло в основном из-за чрезмерной нагрузки на некоторые клиентские узлы уровня соглашения Эфира, что привело к сбою и отключению узла проверки (Validator). Это напрямую повлияло на голосование Epoch, не позволив ему достичь необходимого порога в 2/3, что привело к невозможности подтверждения окончательности на уровне соглашения.

Стоит отметить, что, несмотря на аномалии, сеть Ethereum быстро восстановила нормальную работу. Это демонстрирует устойчивость и самовосстанавливающую способность алгоритма консенсуса PoS Ethereum.

Подробности события

Обычно состояние сети Ethereum PoS соглашения будет окончательно утверждено в течение 2-х эпох (Finalized). Однако на прошлой неделе в двух событиях наблюдалось задержка в утверждении эпох:

• 11 мая: Epoch был отложен на 3 Epoch, примерно на 20 минут.
• 12 мая: Эпоха была задержана на 8 Эпох, примерно на 51 минуту.

Несмотря на то, что Эпоха не смогла быть завершена вовремя, сеть Ethereum продолжает генерировать блоки и обрабатывать транзакции. Однако из-за недостаточной голосуемости узлов проверки Эпоха не может получить уровень безопасности соглашения сети Ethereum PoS.

Стоит отметить, что во втором инциденте, из-за того что задержка подтверждения превышала установленный порог, была активирована механика утечки бездействия соглашения Эфира. Это привело к штрафу в размере около 28 ETH и невыдаче около 50 ETH.

Анализ причин

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

1. Когда узел получает свидетельство, указывающее на устаревший блок (Attestation), необходимо пересчитать состояние цепочки Beacon для проверки этих свидетельств, этот процесс требует значительных ресурсов ЦП и памяти.

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

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

В настоящее время клиенты уровня соглашения Teku и Prysm выпустили патч-версии для решения этой проблемы. Патч-версии будут фильтровать эти устаревшие свидетельства, игнорируя свидетельства, когда они указывают на устаревший Slot или на Checkpoint, который узел никогда не видел.

Преимущества дизайна Ethereum

В этом событии Эфир продемонстрировал свои проектные преимущества:

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

2. Дизайн алгоритма Gasper: отделяет производство блоков от их подтверждения, даже если подтверждение блока затруднено, производство блоков не останавливается, что обеспечивает доступность сети.

Опыт и выводы

1. Разнообразие клиентов все еще нуждается в улучшении: в настоящее время разнообразие клиентов Ethereum все еще имеет пространство для улучшения, особенно уровень выполнения клиентов сосредоточен в Geth, который занимает 61%, что создает потенциальный риск.

2. Механизм переключения клиентов необходимо улучшить: когда у какого-либо клиента возникает проблема, как безопасно переключиться на нормальную реализацию клиента по-прежнему остается проблемой.

3. Соглашение мониторинг необходимо усилить: требуется подобный сервис Safe Head для постоянного мониторинга реального состояния сети Ethereum PoS, своевременно выявлять и предупреждать о аномалиях.

4. Укрепление образовательной работы с пользователями: популяризация механизма соглашения PoS Ethereum, чтобы избежать ненужной паники среди пользователей.

5. Приложения на уровне приложения должны быть готовы к реагированию: приложения, такие как Layer2, биржи, Oracle и т. д., должны правильно обрабатывать ситуации с нестабильностью сети, такие как соответствующее продление времени подтверждения или приостановка обслуживания.

Резюме

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