Polygon устранил две уязвимости в BlockSTM V2 — системе параллельного исполнения внутри клиента Bor, на котором работает блокчейн Polygon PoS, которые могли позволять корректным транзакциям замедлять работу узлов сети. Согласно опубликованному Polygon техническому разбору, эти ошибки не изменяли результаты транзакций и не угрожали консенсусу. Риск касался доступности: узел мог вычислить корректный результат для блока, но тратить столько времени на его обработку, что отставал от остальной сети. Компания раскрыла эту информацию одновременно с публичным релизом Bor v2.10.3 — версии клиента, содержащей исправления.

Polygon сообщает, что ему неизвестно о каких-либо случаях эксплуатации в основной сети или тестнете Amoy.

Почему завершение сериального исполнения первым не прекращало задержку

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

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

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

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

Две ошибки создавали работу, которую газ не полностью оплачивал

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

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

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

Что изменяет патч Bor v2.10.3

Исправления в v2.10.3 ограничивают эти издержки, не изменяя результатов исполнения. Обновление ограничивает общий кеш, используемый при спекулятивном исполнении, и позволяет Bor повторно использовать результат хеширования кода вместо его пересчёта при повторных чтениях. Цель — предотвратить потребление чрезмерных ресурсов или необоснованное увеличение времени обработки блоков корректной, но неудобной нагрузкой.

Согласно замечаниям к релизу Bor v2.10.3, публичный релиз не требует хардфорка, миграции базы данных или ресинхронизации узла. Операторы могут обновлять свои узлы по отдельности.

Приватное исправление предшествовало публичному раскрытию

Polygon сообщил, что распространил приватную сборку для тестнета Amoy 5 октября, за которой 8 октября последовала приватная сборка для основной сети. Техническое раскрытие было опубликовано на форуме управления Polygon 15 октября, после того как обновления достигли большей части сети. Отдельное объявление о релизе описывает развёртывание в основной и тестовой сетях.

В замечаниях к релизу указано, что большинство валидаторов и крупнейших RPC-провайдеров уже использовали приватную версию. Это не означает, что все подключённые узлы обновились, поэтому в объявлении для операторов Polygon призывает пользователей Bor v2.10.2 или более ранних версий оперативно обновиться. Операторы, уже использующие приватные сборки, могут перейти на публичный релиз в ближайшее окно технического обслуживания.

Оставшийся вопрос — охват патчем

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

Поскольку v2.10.3 выпущен без хардфорка, протокольного дедлайна, вынуждающего отстающих обновиться, не существует; внедрение происходит по графику каждого оператора. Поэтому именно охват патчем является наблюдаемым сигналом: как быстро операторы Bor на версии v2.10.2 или более ранней перейдут на исправленный релиз.

Более широкая работа Polygon над ускорением обработки и платёжной инфраструктурой делает эту операционную надёжность важной. Патч устраняет два выявленных источника избыточной работы; практический следующий шаг — применение его оставшимися операторами Bor.

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

Источник: Coindoo