Ума Аудит – Этап 6

Введение

UMA — это платформа, которая позволяет пользователям заключать финансовые контракты с минимальным доверием в блокчейне Ethereum. Ранее мы проверяли децентрализованный оракул, конкретный шаблон финансового контракта, некоторые специальные запросы на включение, шаблон «Вечная многопартийность», различные дополнительные запросы на включение в течение более длительного взаимодействия и застрахованный мост.

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

Проверяемый коммит 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc и объем включает следующие контракты:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (за исключением контрактов на тестирование и полигон)
• financial-templates/optimistic-rewarder/* (за исключением контрактов на тестирование)

Мы также рассмотрели изменения в файлах Solidity в Запрос на извлечение 3611.

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

Системный Обзор

В настоящее время Governance Контракт позволяет Фонду Risk Labs Foundation предлагать новые действия по управлению, которые могут быть ратифицированы держателями токенов UMA. Новый Proposer Контракт предназначен для того, чтобы взять на себя роль предлагающего, позволяя любому делать новые предложения, пока они обеспечивают залог, которым можно будет пожертвовать, если предложение потерпит неудачу. Конкретного стимула для внесения предложений не существует. Цель состоит в том, чтобы гарантировать, что будут предложены только те действия, которые с большой вероятностью будут приняты.

Новый межцепочный механизм позволяет передавать предложения по управлению из основной сети Ethereum в цепочки Optimism и Arbitrum. Таким образом, механизм управления UMA на уровне 1 можно использовать для управления контрактами UMA в поддерживаемых цепочках уровня 2. Этот механизм также позволяет пересылать ценовые запросы и решения между уровнями, поэтому оптимистические оракулы в цепочках уровня 2 могут быть защищены механизмом проверки данных основной сети таким же образом, как оптимистический оракулы уровня 1 защищен DVM.

Стоит отметить, что эти сообщения отправляются с использованием собственной механики моста, а это означает, что они ограничены характеристиками соответствующих цепочек уровня 2. В частности, передача сообщений с уровня 2 на уровень 1 может занять неделю или больше, чтобы пройти мост. Более того, механизм управления UMA поддерживает предложения, включающие несколько упорядоченных транзакций, но это лишь ограничивает порядок их добавления в мост. Некоторые из этих транзакций могут выполняться в другом порядке или вообще не выполняться на уровне 2.

Контракт Optimistic Rewarder просто чеканит токены ERC721 для всех, кто их запрашивает. Это также позволяет любому связать произвольные данные с любым токеном и вносить различные токены ERC20 для распределения в качестве вознаграждений. Интерпретация произвольных данных и ожидаемое распределение вознаграждений среди держателей токенов определяются с использованием неуказанной оффчейн процедуры. Любой может заявить, что за конкретный токен ERC721 причитается набор вознаграждений, если он готов внести залог. Стандартный механизм Optimistic Oracle используется, чтобы позволить кому-либо другому оспорить претензию, которая будет разрешена DVM. Претензии, которые не были оспорены вовремя, считаются обоснованными, и контракт распределяет вознаграждение соответствующим образом. Единственное ограничение (для упрощения учета) заключается в том, что токен облигации Oracle не может использоваться в качестве токена вознаграждения.

Наконец, PR3611 изменяет механизм застрахованного моста, чтобы избежать отправки WETH через мост токенов Optimism, который не поддерживается. Вместо этого любой L2 WETH, депонированный в депозитной ячейке Optimism, разворачивается в L2 ETH перед передачей через мост. На уровне 1 ETH преобразуется в WETH перед пересылкой в ​​пул мостов WETH.

Критическая степень тяжести

[C01] Невозможно оспорить недействительное вознаграждение.

При оспаривании запроса на вознаграждение OptimisticRewardBase контракт сначала вызывает предложение на SkinnyOptimisticOracle , а затем оспаривает это предложение. Однако предложение устанавливает срок годности как смещение от текущего (спорного) времени, при этом спор указывает срок действия как смещение со времени первоначального запроса на вознаграждение. В большинстве случаев это несоответствие не позволит оракулу идентифицировать оспариваемое предложение, что означает, что действительные споры не будут обработаны и будут приняты недействительные запросы на вознаграждение.

Рассмотрите возможность обновления вызова оспаривания, чтобы правильно указать оспариваемое предложение.

Обновление: Исправлено на момент фиксации 9e15557 in PR72.

[C02] Повторное решение предложений

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

Обновление: Исправлено на момент фиксации b152718 in PR72.

Высокая степень тяжести

Нет.

Средней степени тяжести

[M01] Неправильные параметры события

Ассоциация OptimisticRewarderBase контракт определяет Requested мероприятие который излучается из requestRedemption функция, когда запрашивается погашение. Это событие определено для генерации срок окончания выкупа в качестве последнего параметра. Однако, когда событие генерируется, его последний параметр неправильно установлен на Текущее время.

Точно так же Redeemed мероприятие считывает время истечения срока действия после удаления записи, поэтому оно будет ошибочно установлено на ноль.

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

Обновление: Исправлено на момент фиксации f04eef9 in PR72.

Низкая степень серьезности

[L01] Отсутствие генерации событий после оспаривания погашения

Ассоциация OptimisticRewarderBase контракт определяет Disputed мероприятие это предназначено для инициирования, если выкуп оспаривается. Однако это событие не генерируется внутри или за пределами OptimisticRewarderBase контракт.

Рассмотрите возможность отправки события после того, как в файле произойдут важные изменения. dispute функция, чтобы облегчить отслеживание и уведомлять офчейн-клиентов о деятельности контрактов.

Обновление: Исправлено на момент фиксации c275e92 in PR72.

[L02] Непоследовательная защита повторного входа

Ассоциация Optimism_ParentMessenger и Arbitrum_ParentMessenger контракты непоследовательно применяют nonReentrant модификатор. Рассмотрите возможность включения его во все государственные функции.

Обновление: Исправлено на момент фиксации 6275c39 in PR72.

[L03] Вводящие в заблуждение комментарии

Вот некоторые вводящие в заблуждение комментарии, которые мы выявили в ходе нашего обзора:

• ChildMessengerConsumerInterface.sol:
  • Линия 5 написано «родительский мессенджер» вместо «детский мессенджер»
• GovernorSpoke.sol:
  • Строки 49-51 ссылки на Gnosis файл, хотя в комментарии говорится, что фрагмент был скопирован из Governor.sol. Кроме того, фрагмент не идентичен приведенному в Governor.sol

Обновление: Исправлено на момент фиксации cc350f9 in PR72.

[L04] Отсутствует штамп вспомогательных данных

При запросе цены на OracleSpoke договор, предоставленные дополнительные данные штампован с идентификатором дочерней цепи. Однако hasPrice и getPrice функции не отмечают вспомогательные данные при идентификации ценового запроса. Это вынуждает контракты самостоятельно применять штамп, что приводит к несогласованности между механизмами запроса цены и получения цены. Рассмотрите возможность применения штампа в hasPrice и getPrice функции.

Обновление: Исправлено на момент фиксации fdb845d in PR72.

[L05] Отсутствует параметр NatSpec

Многие функции в OptimisticRewarderBase контракт не хватает @return параметр в комментариях к естественной спецификации. Рассмотрите возможность включения его для полноты картины.

Обновление: Исправлено на момент фиксации 8920f38 in PR72.

[L06] Остаточный припуск

Чтобы вызвать Оптимистического Оракула, OptimisticRewarderBase контракт предоставляет ему символическое пособие, поэтому он может получить выплаты по облигациям. Если предложение провалится, выкуп вознаграждения отменен но пособие не обнуляется. Таким образом, Оптимистический Оракул сохранит ненужный остаток до тех пор, пока в следующий раз не возникнет спор. Рассмотрите возможность отмены пособия, если предложение не удастся.

Обновление: Исправлено на момент фиксации c2d444b in PR72.

[L07] Неверный адрес возврата

Адрес возврата L2 Arbitrum_ParentMessenger инициализирован владельцу контракта, которым должен быть управляющий L1. Аналогичным образом, setRefundL2Address есть комментарий заявив, что это должно быть передано губернатору. Однако при передаче сообщений по мосту это значение установить как пользователя L2, то есть адрес в Arbitrum, на который поступают избыточные средства после разрешения заявки. Поскольку адрес управляющего L1 не будет доступен в Arbitrum, любые средства, отправленные на этот адрес, будут потеряны.

Рассмотрите возможность установки действительного адреса L2.

Обновление: Исправлено на момент фиксации b3f2dd1 in PR72.

[L08] Механизм изменения дочерних мессенджеров

Ассоциация GovernorSpoke и OracleSpoke каждый контракт инициализирует дочерний мессенджер в конструкторе без механизма его обновления. Это означает, что когда дочерний мессенджер изменен, оба контракта устарели.

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

Обновление: Исправлено на момент фиксации 7c9e061 in PR72.

Примечания и дополнительная информация

[N01] Изменить токен облигации

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

Обновление: Не ошибка. Заявление UMA по этому вопросу:

N01 рекомендует разрешить контракту предлагающего изменить токен облигации на что-то другое, кроме UMA. Мы не собираемся поддерживать для этой функции какой-либо токен, кроме $UMA, поэтому решили не вносить никаких изменений по этой проблеме. Более того, один токен на контракт максимально упрощает эту логику. Наконец, если требовалось изменение (например, в случае миграции токена), мы могли просто развернуть новый контракт предлагающего с другим токеном и инициировать предложение по миграции системы для использования этого токена.

[N02] Неполный интерфейс

Ассоциация ChildMessengerInterface не указывает processMessageFromCrossChainParent функция, даже несмотря на то, что родительские мессенджеры предполагают ее существование. Рассмотрите возможность включения его для полноты картины.

Обновление: Не зафиксировано. Заявление UMA по этому вопросу:

Мы намеренно решили оставить этот интерфейс непоследовательным, поскольку его реализация в ChildMessengerInterface нарушает совместимость с Polygon_ChildMessenger, поскольку метод Polygon для обработки сообщений из других цепочек требует некоторой специальной логики, в которой вызывается внутренний метод под названием _processMessageFromRoot.

[N03] Неправильный интерфейс

Ассоциация GovernorSpoke заключать контракт неправильно использует ChildMessengerConsumerInterface напишите описать его messenger переменная. Рассмотрите возможность использования ChildMessengerInterface .

Обновление: Исправлено на момент фиксации f31a527 in PR72.

[N04] Извлечение жетонов в хранилище

В предыдущий аудит мы поставили под сомнение цель Store контракт payOracleFeesErc20 функция (в выпуске Л19). Команда УМА решил сохранить функцию стандартизировать интерфейс для возможных будущих модификаций. Поскольку цель функции не определена полностью, неясно, должна ли она запускаться при Proposer контракт конфискует залог. Вероятно, его следует использовать, когда OracleHub платит за запрос цены. Подумайте, следует ли использовать эту функцию в любом сценарии.

Обновление: Признано. Заявление UMA по этому вопросу:

N04 рекомендует использовать метод payOracleFeeErc20 Магазина для оплаты сборов как в контрактах Proposer, так и в контрактах OracleHub, чтобы обеспечить соответствие использованию Store. Мы решили не использовать эту функцию, так как это означало бы необходимость импортировать дополнительный интерфейс (для магазина) и приводить сумму залога к фиксированной точке (что также потребовало бы дополнительного импорта. Чтобы код был простым и понятным). мы решили не делать этого. Отзывы OZ о payOracleFeeErc20 на этапе аудита 1 в апреле 2020 года подтвердили, что этот метод на самом деле бесполезен, что затрудняет обоснование такого рода интеграции.

[N05] TODOs в коде

В базе кода есть комментарии «TODO», которые следует отслеживать в журнале невыполненных задач проекта. Например:

• линия 37 of Arbitrum_ParentMessenger контракт
• линия 25 of Optimism_ChildMessenger контракт
• Линии 83 и 146 of OracleHub контракт.

Во время разработки хорошо описанные комментарии «TODO» упростят процесс их отслеживания и решения. Без этой информации эти комментарии могут иметь тенденцию к гниению, а важная информация для безопасности системы может быть забыта к моменту ее выпуска в производство.

Эти комментарии TODO должны содержать краткое описание задачи, которую предстоит выполнить, и ссылку на соответствующую проблему в репозитории проекта.

Рассмотрите возможность обновления комментариев TODO, чтобы добавить эту информацию. Для полноты и отслеживаемости можно добавить подпись и временную метку. Например:

// TODO: point this at an interface instead.

// https://github.com/UMAprotocol/protocol/issues/XXXX

// --mrice32 - 20211209

Обновление: Исправлено на момент фиксации 5d57b5b in PR72.

[N06] Типографические ошибки

База кода содержит следующие опечатки:

• В Admin_ChildMessenger контракт, impleenting должно быть implementing
• В OptimisticRewarderBase контракт, timestap должно быть timestamp.
• В OptimisticRewarderBase контракт, liveness liveness должно быть liveness.
• В GovernorSpoke контракт, only called должно быть only be called.
• В Optimism_ChildMessenger контракт:

Обновление: Исправлено на момент фиксации 9b92b0b in PR72.

[N07] Неиспользованный импорт

Чтобы улучшить читаемость кода, рассмотрите возможность удаления следующих неиспользуемых импортов:

Обновление: Исправлено на момент фиксации 40b7221 in PR72.

[N08] Порядок транзакций L2

Ассоциация Governor обеспечивает транзакции в рамках предложения выполняются по порядку. Однако, когда эти транзакции включают в себя транзакции между цепочками, это просто гарантирует, что они придут к мостовому контракту L1 в правильном порядке. В случае Arbitrum они могут быть переупорядочены до того, как они будут завершены на L2. Следовательно, предложения по управлению должны быть построены так, чтобы обеспечить возможность переупорядочения транзакций L2.

Обновление: Исправлено на момент фиксации 0fb2e7b in PR72, GovernorHub теперь может ретранслировать массив транзакций L2.

Заключение

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

Источник: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6