Polygon Crypto защитила клиенты Bor и Heimdall до публичного раскрытия
Polygon Crypto провела два скоординированных хардфорка — Austin для Bor v2.10.0 и Kyoto для Heimdall v0.11.0 — чтобы устранить риски отказа в обслуживании, истощения ресурсов и усилить защиту консенсуса в стеке клиентов Polygon PoS.
Оба обновления были развернуты в закрытом режиме и проверены в тестовой сети Amoy до активации в основной сети, согласно публикации на форуме Polygon от 27 августа.
Нарушений работы основной сети из-за уязвимостей, устраненных Austin, не наблюдалось. К моменту публичного раскрытия информации оба хардфорка уже были активны в Amoy и основной сети.
Последовательность действий имеет значение: Polygon сначала исправила проблемы, подтвердила безопасность сети и только затем раскрыла информацию о том, что было уязвимо.
Что именно исправили Austin и Kyoto
Исправления Austin для Bor
Austin устранил два пути для DoS-атак при обработке блоков Bor.
События state-sync, которые обрабатывают депозиты из моста L1-to-L2, выполняют код контрактов и precompiles так же, как обычные транзакции. Однако ранее их потребление газа не ограничивалось жестким лимитом на блок.
Блок с достаточным количеством событий state-sync или с одним особенно затратным событием мог замедлить обработку настолько, чтобы временно остановить работу сети. Austin добавил явное ограничение газа на блок, чтобы закрыть этот риск.
Второе исправление Austin полностью удалило wire-поле TxDependency из Bor. Это поле служило подсказкой для параллельного выполнения и не имело ограничения по размеру. Производитель блока мог поместить произвольно большой объем данных в формально действительный sibling block и вызвать сбой у любого узла, пытающегося его обработать.
Поскольку для корректной работы параллельного выполнения узлам не требуется доверять подсказке производителя блока, удаление поля не повлияло на дальнейшую работу системы.
Исправления Kyoto для Heimdall
Наиболее серьезное исправление Kyoto было направлено на глубоко вложенные поля google.protobuf.Any в транзакциях Heimdall. При отсутствии ограничения одна дешево сформированная транзакция могла заставить каждого валидатора одновременно выполнять непропорционально затратную работу по декодированию.
Это создавало не требующий разрешений способ вызвать дорогостоящую и согласованную нагрузку на весь набор валидаторов.
Kyoto добавил предварительную проверку на уровне байтов, которая одинаково применяется при добавлении в mempool и на пути консенсуса. Благодаря этому транзакция не сможет пройти одну проверку и быть отклоненной другой.
Kyoto также включил дополнительные меры защиты:
- ограничение количества fee-coin;
- нормализацию байтов восстановления подписи checkpoint;
- идемпотентную обработку повторных сообщений о простое producer;
- привязку голосов по диапазонам milestone к подписанному parent hash;
- проверки непрерывности окна checkpoint;
- создание future-span без остановки работы;
- инъективные ключи повтора для событий L1 topup, clerk и stake.
Все эти изменения неактивны ниже высоты форка — обычный трафик не видит изменений в поведении. Такая многоуровневая защита проверок похожа на более широкие усилия отрасли по устранению пограничных случаев при обработке транзакций до их возможной эксплуатации.
Почему обновления потребовались и Bor, и Heimdall
| Хардфорк | Активация в Amoy | Активация в основной сети |
|---|---|---|
| Austin | Блок 44,120,000 | Блок 91,949,700 |
| Kyoto | Высота 42,252,000 | Высота 51,533,000 |
Bor отвечает за выполнение блоков, тогда как Heimdall обеспечивает консенсус. Исправления Kyoto затрагивают обработку ABCI, milestone, bor, stake, topup, clerk и bridge.
Это означает, что обновление одновременно коснулось финализации checkpoint, учета milestone и логики повторной обработки событий L1.
| Клиент | Версия | Требование |
|---|---|---|
| Bor | v2.10.0 | Обязательна для всех узлов |
| Heimdall | v0.11.0 | Обязательна для всех валидаторов и полных узлов |
Оба обновления представляют собой обычное обновление бинарных файлов. Для операторов, уже использующих актуальные версии, не требуется миграция состояния или изменение genesis.
Ситуация отличается для узлов, которые продолжают работать на версиях до форка после высоты активации. Такие узлы уже отделились от канонического консенсуса и должны обновиться, выполнить откат и повторную синхронизацию, а не просто обновиться на месте.
Скоординированные обновления клиентов такого типа имеют важное значение для любой высокопроизводительной сети. Подобная ситуация наблюдается и в других сетях, где обсуждаются рост состояния, риски выполнения и частота обновлений, включая продолжающуюся дискуссию о пути обновления Ethereum Glamsterdam.
Для Polygon PoS вывод прост: уязвимости были связаны с истощением ресурсов и пограничными случаями консенсуса, а не с ошибками корректности. Все они были устранены до того, как в основной сети была замечена какая-либо эксплуатация.
