Polygon Labs выпускает срочное уведомление об обновлении клиента после ‘hardforks’ Austin и Kyoto

Polygon хардфорк Austin Kyoto Bor Heimdall cryptoslate.com

Проверьте, не остался ли ваш узел Polygon PoS вне канонического консенсуса после хардфорков Austin и Kyoto. Узнайте, какие риски закрыли обновления Bor v2.10.0 и Heimdall v0.11.0, и как вернуть узел в актуальную цепь. Внутри — детали об ограничении газа, проверке вложенности и действиях операторов.

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

В обзоре безопасности от 27 августа компания описала последствие для совместимости клиентов. Polygon заявила, что не наблюдала сбоев в основной сети из-за Austin, и представила раскрытые изменения как упреждающие исправления.

Bor — это клиент исполнения Polygon PoS, а Heimdall отвечает за консенсус и формирование контрольных точек. Версии Bor ниже v2.10.0 несовместимы после активации Austin на блоке основной сети 91 949 700; это ограничение распространяется на все роли узлов Bor.

Валидаторам и полным узлам Heimdall требуется v0.11.0 после активации Kyoto на высоте 51 533 000. В уведомлении о выпуске Heimdall Polygon относит активацию в основной сети к 18 августа, 10:10:31 UTC.

Austin и Kyoto устранили отдельные клиентские риски

Austin ограничил объем газа, расходуемого Bor при обработке событий синхронизации состояния от мостовых депозитов L1-to-L2. Эти события выполняют код контрактов и прекомпилированные контракты, но ранее их расход газа не учитывался в фиксированном потолке на уровне блока.

Достаточное количество событий или одно достаточно затратное событие могло замедлить обработку блока настолько, что цепочка временно останавливалась.

Вторая уязвимость находилась в поле extra-data TxDependency в Bor — подсказке, используемой для параллельного исполнения. Поскольку это поле, предоставляемое производителем, не имело ограничения по размеру, производитель блока мог поместить произвольно большой фрагмент данных (blob) в родственный блок, который в остальном был валидным, и вызвать падение пиров, пытавшихся его обработать.

Austin убрал это поле из сетевого формата, а Polygon классифицировала обе уязвимости как риски исчерпания ресурсов.

В публичном релизе Bor v2.10.0 указаны блоки активации Austin в основной сети и в Amoy. GitHub при проверке 28 августа показывал v2.10.1 как последний релиз Bor, при этом совместимость с Austin обеспечивается начиная с v2.10.0.

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

Самое критичное исправление Kyoto нацелено на глубоко вложенные сообщения google.protobuf.Any. Отправитель мог дёшево создать одну транзакцию, которая заставляла каждого валидатора тратить значительные ресурсы на декодирование. Хардфорк добавил побайтовую проверку вложенности и при приёме в мемпул, и при обработке предложений блоков, сохраняя согласованность этих путей.

Отдельно он ограничил списки монет для комиссий перед проверкой с вычислительной сложностью O(n), а интеграция с Heimdall допускает только одну такую монету.

Другие изменения Kyoto касаются отдельных граничных случаев. Они нормализуют байты восстановления подписи контрольных точек, чтобы восстановление допустимой подписи в Ethereum не могло завершиться сбоем и остановить закрепление; делают повторные сообщения о простое производителя идемпотентными; привязывают голоса по диапазону milestone к подписанному хэшу родительского блока; и предотвращают блокировку фиксации milestone из-за неудачного создания будущего спана.

Ключи воспроизведения для событий topup, clerk и stake также сделаны инъективными для лог-индексов вне допустимого диапазона, чтобы разные события первого уровня не могли незаметно затенять друг друга.

Оба хардфорка представляют собой обычные обновления бинарных файлов без миграции состояния и без изменения genesis; узлы, не отклонившиеся от канонической цепи, не требуют повторной синхронизации.

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

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

Похожие новости: