Аудит Uma – Фаза 6

Вступ

UMA це платформа, яка дозволяє користувачам укладати мінімізовані довірчі фінансові контракти на блокчейні Ethereum. Раніше ми проводили аудит децентралізований оракул, шаблон конкретного фінансового договору, деякі спеціальні запити на вилучення, шаблон Perpetual Multiparty, різні інкрементні запити на вилучення протягом більш тривалого залучення та застрахований міст.

Під час цього аудиту ми розглянули новий контракт пропозицій щодо управління, механізм розширення екосистеми 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. Механізм також дозволяє пересилати запити щодо цін і рішення між рівнями, тому Optimistic Oracle на ланцюжках рівня 2 можуть бути захищені механізмом перевірки даних основної мережі так само, як Optimistic Oracle рівня 1 захищено DVM.

Варто зазначити, що ці повідомлення надсилаються за допомогою власної механіки мосту, що означає, що вони обмежені характеристиками відповідних ланцюжків рівня 2. Зокрема, передача повідомлень від рівня 2 до рівня 1 може тривати тиждень або більше. Крім того, механізм управління UMA підтримує пропозиції, які включають кілька замовлених транзакцій, але це лише обмежує порядок, у якому їх можна додавати до мосту. Деякі з цих транзакцій можуть виконуватися в іншому порядку або не виконуватися взагалі на рівні 2.

Контракт Optimistic Rewarder просто карбує токени ERC721 для будь-кого, хто їх запитує. Це також дозволяє будь-кому пов’язувати довільні дані з будь-яким токеном і вносити різні токени ERC20 для розподілу в якості винагороди. Інтерпретація довільних даних і очікуваний розподіл винагород між власниками токенів визначаються за допомогою невизначеної процедури поза мережею. Будь-хто може заявити про те, що певний токен ERC721 має набір винагород, якщо він бажає внести заставу. Стандартний механізм Optimistic Oracle використовується, щоб хтось інший міг оскаржити претензію, яка буде вирішена DVM. Претензії, які не були оскаржені вчасно, вважаються дійсними, і відповідно до контракту розподіляються винагороди. Єдине обмеження (для спрощення обліку) полягає в тому, що токен облігації oracle не можна використовувати як токен винагороди.

Нарешті, PR3611 змінює механізм застрахованого мосту, щоб уникнути надсилання WETH через міст маркера Optimism, який не підтримується. Натомість будь-який WETH L2, внесений у депозитну скриньку Optimism, розгортається до ETH L2 перед проходженням мосту. На рівні 1 ETH перетворюється на WETH перед перенаправленням до мостового пулу WETH.

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

[C01] Неможливо оскаржити недійсну винагороду

При оскарженні вимоги про винагороду OptimisticRewardBase договір спочатку викликає пропозицію на SkinnyOptimisticOracle , А потім заперечує цю пропозицію. Проте пропозиція встановлює час закінчення як зміщення від поточного (спірного) часу, поки суперечка вказує термін дії як зміщення від часу початкового запиту винагороди. У більшості випадків ця розбіжність перешкоджає оракулу ідентифікувати пропозицію, яка буде оскаржена, що означає, що дійсні суперечки не розглядатимуться, а недійсні запити на винагороду прийматимуться.

Розгляньте можливість оновлення виклику оскарження, щоб правильно вказати пропозицію, яка буде оскаржена.

Оновлення: Виправлено станом на фіксацію 9e15557 in PR3690.

[C02] Повторно розглядайте пропозиції

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

Оновлення: Виправлено станом на фіксацію b152718 in PR3689.

Високий ступінь тяжкості

Ні.

Середня тяжкість

[M01] Неправильні параметри події

Команда OptimisticRewarderBase договір визначає а Requested подія який виділяється з requestRedemption функціонувати, коли запитується викуп. Ця подія визначена для випромінювання термін дії викупу як його останній параметр. однак, коли видається подія, для його останнього параметра неправильно встановлено значення Поточний час.

Так само Redeemed подія зчитує час закінчення терміну дії після видалення запису, тому його буде неправильно встановлено на нуль.

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

Оновлення: Виправлено станом на фіксацію f04eef9 in PR3694.

Низька тяжкість

[L01] Відсутність емісії події після оскарження викупу

Команда OptimisticRewarderBase договір визначає а Disputed подія який призначений для ініціювання, якщо погашення оскаржується. Однак ця подія не випромінюється ні всередині, ні за межами OptimisticRewarderBase договір.

Розгляньте можливість випромінювання події після того, як у файлі відбудуться важливі зміни dispute функція, щоб полегшити відстеження та сповістити клієнтів поза мережею про дії контрактів.

Оновлення: Виправлено станом на фіксацію c275e92 in PR3695.

[L02] Непослідовний захист від повторного входу

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

Оновлення: Виправлено станом на фіксацію 6275c39 in PR3677.

[L03] Оманливі коментарі

Ось кілька оманливих коментарів, які ми виявили під час перевірки:

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

Оновлення: Виправлено станом на фіксацію cc350f9 in PR3678.

[L04] Відсутній штамп допоміжних даних

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

Оновлення: Виправлено станом на фіксацію fdb845d in PR3668.

[L05] Відсутній параметр NatSpec

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

Оновлення: Виправлено станом на фіксацію 8920f38 in PR3679.

[L06] Залишкова надбавка

Щоб викликати оптимістичного оракула, OptimisticRewarderBase контракт надає йому символічну допомогу, тож він може стягувати виплати облігацій. Якщо пропозиція не вдається, погашення винагороди скасовано але надбавка не скидається. Таким чином, Optimistic Oracle збереже непотрібну залишкову надбавку до наступного разу, коли буде ініційовано спір. Розгляньте можливість скасування надбавки, якщо пропозиція буде невдалою.

Оновлення: Виправлено станом на фіксацію c2d444b in PR3698.

[L07] Недійсна адреса повернення коштів

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

Спробуйте встановити дійсну адресу L2.

Оновлення: Виправлено станом на фіксацію b3f2dd1 in PR3687.

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

Команда GovernorSpoke та OracleSpoke кожен контракт ініціалізує дочірній месенджер у конструкторі без механізму його оновлення. Це означає, що коли дочірній месенджер змінено, договори обох спиць застаріли.

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

Оновлення: Виправлено станом на фіксацію 7c9e061 in PR3688.

Примітки та додаткова інформація

[N01] Змінити маркер облігації

Команда Proposer договір включає в себе механізм власник може змінити розмір застави пропозиції. Подумайте, чи повинні вони також мати можливість змінювати маркер облігації. Зауважте, що для цього знадобиться механізм для визначення правильної валюти облігації, коли існуючі пропозиції будуть вирішені.

Оновлення: Не проблема. Заява UMA щодо цього питання:

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

[N02] Неповний інтерфейс

Команда ChildMessengerInterface не вказує а processMessageFromCrossChainParent функція, навіть якщо батьківські месенджери припускають її існування. Розгляньте можливість включити його для повноти.

Оновлення: Не виправлено. Заява UMA щодо цього питання:

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

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

Команда GovernorSpoke укласти договір неправильно використовує ChildMessengerConsumerInterface тип щоб описати його messenger змінна. Розгляньте можливість використання ChildMessengerInterface замість цього.

Оновлення: Виправлено станом на фіксацію f31a527 in PR3680.

[N04] Витягнути жетони до магазину

В попередній аудит ми поставили під сумнів мету Store контракт payOracleFeesErc20 функція (у випуску L19). Команда УМА вирішив зберегти функцію стандартизувати інтерфейс для можливих майбутніх модифікацій. Оскільки мета функції визначена не повністю, незрозуміло, чи слід її запускати, коли Proposer контракт конфіскує заставу. Ймовірно, його слід використовувати, коли OracleHub платить за запит ціни. Подумайте, чи слід використовувати функцію в будь-якому сценарії.

Оновлення: Визнано. Заява UMA щодо цього питання:

N04 рекомендує використовувати метод payOracleFeeErc20 магазину для сплати комісій як у контрактах Proposer, так і в OracleHub, щоб відповідати використанню магазину. Ми вирішили не використовувати цю функцію, оскільки це означатиме потребу в імпорті додаткового інтерфейсу (для магазину) і потребуватиме приведення суми облігації до FixedPoint (що також потребуватиме додаткового імпорту. Щоб код був простим і зрозумілим). Ми вирішили не робити цього на етапі аудиту OZ у квітні 20 року.

[N05] TODO в коді

У базі коду є коментарі «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 PR3684.

[N06] Друкарські помилки

Кодова база містить такі друкарські помилки:

• У Admin_ChildMessenger договір, impleenting повинно бути implementing
• У OptimisticRewarderBase договір, timestap повинно бути timestamp.
• У OptimisticRewarderBase договір, liveness liveness повинно бути liveness.
• У GovernorSpoke договір, only called повинно бути only be called.
• У Optimism_ChildMessenger договір:

Оновлення: Виправлено станом на фіксацію 9b92b0b in PR3681.

[N07] Невикористаний імпорт

Щоб покращити читабельність коду, подумайте про видалення таких невикористаних елементів імпорту:

Оновлення: Виправлено станом на фіксацію 40b7221 in PR3682.

[N08] Упорядкування транзакцій L2

Команда Governor гарантує операції в рамках пропозиції виконуються в порядку. Однак, коли ці транзакції включають міжланцюгові транзакції, це лише гарантує, що вони надходять до мостового контракту L1 у правильному порядку. У випадку Arbitrum їх можна змінити, перш ніж вони будуть завершені на L2. Таким чином, пропозиції щодо управління мають бути розроблені таким чином, щоб дозволити можливість перевпорядкованих транзакцій L2.

Оновлення: Виправлено станом на фіксацію 0fb2e7b in PR3703, GovernorHub тепер може ретранслювати масив транзакцій L2.

Висновок

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

Джерело: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6