Audyt Uma – Faza 6

Wprowadzenie

UMA to platforma, która umożliwia użytkownikom zawieranie umów finansowych o minimalnym zaufaniu na blockchainie Ethereum. Już wcześniej sprawdzaliśmy zdecentralizowaną wyrocznię, konkretny wzór umowy finansowej, niektóre żądania ściągnięcia ad hoc, szablon Wieczystej Wielopartyjności, różne przyrostowe żądania ściągnięcia w trakcie dłuższego zaangażowania i ubezpieczony most.

Podczas tej kontroli dokonaliśmy przeglądu nowej umowy dotyczącej propozycji zarządzania, mechanizmu rozszerzania ekosystemu UMA na wiele łańcuchów, mechanizmu dystrybucji nagród wśród posiadaczy tokenów ERC721 zgodnie ze specyfikacją poza łańcuchem oraz aktualizacji ubezpieczonego mostu w celu obsługi WETH w łańcuchu optymizmu.

Sprawdzone zatwierdzenie to 0c4cea3c3d5e48da6f8984b8ba3afdfea4ce47cc a zakres obejmuje następujące umowy:

• oracle/implementation/Proposer.sol
• cross-chain-oracle/* (z wyłączeniem umów testowych i wielokątnych)
• financial-templates/optimistic-rewarder/* (z wyłączeniem umów testowych)

Sprawdziliśmy także zmiany w plikach solidności w Wyciągnij żądanie 3611.

Założono, że wszystkie zależności kodu zewnętrznego i kontraktu działają zgodnie z dokumentacją.

Przegląd systemu

Prąd Governance Umowa pozwala Fundacji Risk Labs zaproponować nowe działania zarządcze, które mogą zostać ratyfikowane przez posiadaczy tokenów UMA. Nowa Proposer Umowa ma na celu przyjąć rolę oferenta, umożliwiając każdemu składanie nowych propozycji, o ile zapewniają one gwarancję, która zostanie poświęcona w przypadku niepowodzenia propozycji. Nie ma szczególnej zachęty do składania wniosków. Celem jest zapewnienie, że zaproponowane zostaną jedynie te działania, które z dużym prawdopodobieństwem zostaną zaakceptowane.

Nowy mechanizm międzyłańcuchowy umożliwia przekazywanie propozycji zarządzania z głównej sieci Ethereum do łańcuchów Optimism i Arbitrum. W ten sposób mechanizm zarządzania UMA w warstwie 1 może być używany do zarządzania kontraktami UMA w obsługiwanych łańcuchach warstwy 2. Mechanizm umożliwia także przekazywanie żądań cenowych i rozwiązań między warstwami, zatem optymistyczne wyrocznie w łańcuchach warstwy 2 mogą być zabezpieczone przez mechanizm weryfikacji danych sieci głównej w taki sam sposób, w jaki optymistyczna wyrocznia warstwy 1 jest zabezpieczona przez DVM.

Warto zauważyć, że komunikaty te są wysyłane przy użyciu natywnej mechaniki mostu, co oznacza, że ​​są one ograniczone charakterystyką odpowiednich łańcuchów warstwy 2. W szczególności przesłanie komunikatów z warstwy 2 do warstwy 1 przez most może zająć tydzień lub dłużej. Co więcej, mechanizm zarządzania UMA obsługuje propozycje obejmujące wiele uporządkowanych transakcji, ale ogranicza to jedynie kolejność, w jakiej można je dodawać do mostu. Możliwe jest, że niektóre z tych transakcji zostaną wykonane w innej kolejności lub w ogóle nie zostaną wykonane w warstwie 2.

Umowa Optimistic Rewarder po prostu wybija tokeny ERC721 każdemu, kto o nie poprosi. Pozwala także każdemu powiązać dowolne dane z dowolnym tokenem i zdeponować różne tokeny ERC20 w celu dystrybucji jako nagrody. Interpretacja dowolnych danych i oczekiwany podział nagród wśród posiadaczy tokenów są ustalane przy użyciu nieokreślonej procedury poza łańcuchem. Każdy może twierdzić, że konkretny token ERC721 jest mu należny zestaw nagród, jeśli chce zdeponować kaucję. Standardowy mechanizm Optimistic Oracle umożliwia innej osobie zakwestionowanie roszczenia, które zostanie rozpatrzone przez DVM. Roszczenia, które nie zostaną zakwestionowane w terminie, uznaje się za uzasadnione i zgodnie z umową następuje podział nagród. Jedynym ograniczeniem (w celu uproszczenia księgowości) jest to, że żeton obligacji wyroczni nie może być używany jako żeton nagrody.

Na koniec PR3611 modyfikuje mechanizm ubezpieczonego mostu, aby uniknąć wysyłania WETH przez most tokenu optymizmu, który nie jest obsługiwany. Zamiast tego każdy L2 WETH zdeponowany w skrzynce depozytowej Optimism jest rozpakowywany do L2 ETH przed przejściem przez most. W warstwie 1 ETH jest konwertowany na WETH przed przesłaniem do puli mostów WETH.

Krytyczna dotkliwość

[C01] Nie można zakwestionować nieprawidłowej nagrody

W przypadku kwestionowania prośby o nagrodę OptimisticRewardBase najpierw umowa wywołuje propozycję na SkinnyOptimisticOracle , a następnie kwestionuje tę propozycję. Jednak propozycja ustawia czas ważności jako offset od czasu bieżącego (spornego), podczas gdy spór określa termin ważności jako przesunięcie w stosunku do czasu pierwotnego żądania nagrody. W większości przypadków ta rozbieżność uniemożliwi wyroczni zidentyfikowanie propozycji, która ma zostać zakwestionowana, co oznacza, że ​​uzasadnione spory nie będą rozpatrywane, a nieważne prośby o nagrodę zostaną zaakceptowane.

Rozważ aktualizację zaproszenia do sporu, aby poprawnie określić propozycję, która ma zostać zakwestionowana.

aktualizacja: Naprawiono od momentu zatwierdzenia 9e15557 in PR3690.

[C02] Wielokrotnie rozstrzygaj propozycje

Połączenia resolveProposal funkcja Proposer umowa po prostu potwierdza że wyrocznia rozwiązała sprawę, ale nie sprawdza, czy kaucja została rozdzielona. Oznacza to, że tę samą propozycję można rozpatrywać wielokrotnie, co skutkuje podwójną płatnością obligacji. Rozważ oznaczenie lub usunięcie istniejących propozycji po ich rozwiązaniu.

aktualizacja: Naprawiono od momentu zatwierdzenia b152718 in PR3689.

Wysoka dotkliwość

Brak.

Średni stopień nasilenia

[M01] Nieprawidłowe parametry zdarzenia

Połączenia OptimisticRewarderBase umowa określa a Requested wydarzenie który jest emitowany z requestRedemption pełnić funkcję w przypadku żądania wykupu. To zdarzenie jest zdefiniowane tak, aby emitować termin wygaśnięcia wykupu jako ostatni parametr. Jednakże, kiedy zdarzenie zostanie wyemitowane, jego ostatni parametr jest niepoprawnie ustawiony na Obecny czas.

Podobnie Redeemed wydarzenie odczytuje czas wygaśnięcia po usunięciu rekordu, więc zostanie on błędnie ustawiony na zero.

Biorąc pod uwagę, że tego zdarzenia można użyć do uruchomienia obliczeń poza łańcuchem, należy rozważyć odpowiednią aktualizację emitowanej wartości.

aktualizacja: Naprawiono od momentu zatwierdzenia f04eef9 in PR3694.

Niska dotkliwość

[L01] Brak emisji zdarzenia po zakwestionowaniu wykupu

Połączenia OptimisticRewarderBase umowa określa a Disputed wydarzenie który ma zostać uruchomiony w przypadku kwestionowania wykupu. Jednak to zdarzenie nie jest emitowane ani wewnątrz ani na zewnątrz OptimisticRewarderBase kontrakt.

Rozważ wyemitowanie zdarzenia po wprowadzeniu wrażliwych zmian w pliku dispute funkcjonować, aby ułatwić śledzenie i powiadamianie klientów spoza łańcucha o aktywności związanej z umowami.

aktualizacja: Naprawiono od momentu zatwierdzenia c275e92 in PR3695.

[L02] Niespójny strażnik ponownego wejścia

Połączenia Optimism_ParentMessenger i Arbitrum_ParentMessenger umowy niekonsekwentnie stosują ww nonReentrant modyfikator. Rozważ włączenie go do wszystkich funkcji publicznych.

aktualizacja: Naprawiono od momentu zatwierdzenia 6275c39 in PR3677.

[L03] Wprowadzające w błąd komentarze

Oto kilka wprowadzających w błąd komentarzy, które znaleźliśmy podczas naszej recenzji:

• ChildMessengerConsumerInterface.sol:
  • linia 5 mówi „posłaniec rodzica” zamiast „posłaniec dziecka”
• GovernorSpoke.sol:
  • Linie 49-51 linki do Gnosis plik, mimo że komentarz mówi, że fragment został skopiowany Governor.sol. Dodatkowo fragment nie jest identyczny z tym w Governor.sol

aktualizacja: Naprawiono od momentu zatwierdzenia cc350f9 in PR3678.

[L04] Brak dodatkowego stempla danych

Pytając o cenę na OracleSpoke umowy, podanych danych pomocniczych jest ostemplowany z identyfikatorem łańcucha podrzędnego. Jednakże hasPrice i getPrice funkcje nie stemplują danych pomocniczych podczas identyfikacji zapytania cenowego. Zmusza to zamawiających do samodzielnego nałożenia stempla, co powoduje niespójność pomiędzy mechanizmami zapytania o cenę a mechanizmami wyszukiwania ceny. Rozważ nałożenie stempla w hasPrice i getPrice funkcje.

aktualizacja: Naprawiono od momentu zatwierdzenia fdb845d in PR3668.

[L05] Brak parametru NatSpec

Wiele funkcji w OptimisticRewarderBase umowa brakuje im @return parametr w swoich komentarzach dotyczących specyfikacji naturalnej. Rozważ uwzględnienie go w celu zapewnienia kompletności.

aktualizacja: Naprawiono od momentu zatwierdzenia 8920f38 in PR3679.

[L06] Zasiłek rezydualny

Aby przywołać Optymistyczną Wyrocznię, OptimisticRewarderBase umowa przyznaje mu symboliczny dodatek, więc może zaciągnąć spłatę obligacji. Jeżeli propozycja nie powiedzie się, realizacja nagrody zostaje anulowana ale zasiłek nie jest resetowany. Dlatego też Optymistyczna Wyrocznia zachowa niepotrzebny dodatek rezydualny do następnego uruchomienia sporu. Rozważ cofnięcie dodatku, jeśli propozycja nie powiedzie się.

aktualizacja: Naprawiono od momentu zatwierdzenia c2d444b in PR3698.

[L07] Nieprawidłowy adres zwrotu

Adres L2 zwrotu środków Arbitrum_ParentMessenger jest inicjowany właścicielowi kontraktu, którym powinien być gubernator L1. Podobnie, setRefundL2Address ma komentarz stwierdzając, że należy to przekazać gubernatorowi. Jednak podczas przesyłania wiadomości przez most ta wartość wynosi ustawiony jako użytkownik L2, czyli adres na Arbitrum, na który otrzymają nadwyżki środków po rozpatrzeniu zgłoszenia. Ponieważ adres gubernatora L1 nie będzie dostępny na Arbitrum, wszelkie środki wysłane na ten adres zostaną utracone.

Rozważ ustawienie go na prawidłowy adres L2.

aktualizacja: Naprawiono od momentu zatwierdzenia b3f2dd1 in PR3687.

[L08] Mechanizm zmiany komunikatorów dziecięcych

Połączenia GovernorSpoke i OracleSpoke kontrakt każdy inicjuje komunikator podrzędny w konstruktorze, bez mechanizmu umożliwiającego jego aktualizację. Oznacza to, że gdy Komunikator dziecięcy ulega zmianieumowy dotyczące obu szprych stają się przestarzałe.

Ponieważ kontrakty na szprychy są prawdopodobnie bardziej stabilne niż komunikatory, rozważ włączenie mechanizmu aktualizacji komunikatora na szprychach.

aktualizacja: Naprawiono od momentu zatwierdzenia 7c9e061 in PR3688.

Uwagi i dodatkowe informacje

[N01] Zmień token obligacji

Połączenia Proposer umowa obejmuje mechanizm dla właściciela zmiany wielkości wadium. Zastanów się, czy oni również powinni mieć możliwość zmiany tokenu obligacji. Należy zauważyć, że wymagałoby to mechanizmu identyfikującego właściwą walutę obligacji po rozpatrzeniu istniejących propozycji.

aktualizacja: To nie jest problem. Oświadczenie UMA w tej sprawie:

N01 zaleca umożliwienie umowie oferenta zmiany tokena obligacji na inny niż UMA. Nie mamy zamiaru wspierać w tej funkcji żadnego tokena innego niż $UMA, dlatego postanowiliśmy nie wprowadzać żadnych zmian w tym przypadku. Co więcej, jeden token na umowę sprawia, że ​​ta logika jest tak prosta, jak to tylko możliwe. Na koniec, jeśli konieczna była zmiana (na przykład w przypadku migracji tokena), moglibyśmy po prostu wdrożyć nową umowę z propozycją z drugim tokenem i zainicjować propozycję migracji systemu w celu użycia tego tokena.

[N02] Niekompletny interfejs

Połączenia ChildMessengerInterface nie określa A processMessageFromCrossChainParent nawet jeśli zakłada się, że istnieje przez posłańców nadrzędnych. Rozważ uwzględnienie go w celu zapewnienia kompletności.

aktualizacja: Nie naprawiony. Oświadczenie UMA w tej sprawie:

Celowo zdecydowaliśmy się pozostawić ten interfejs niespójny, ponieważ zaimplementowanie go w ChildMessengerInterface przerywa kompatybilność z Polygon_ChildMessenger, ponieważ metoda Polygon do przetwarzania komunikatów z innych łańcuchów wymaga nieco niestandardowej logiki, w której metoda wewnętrzna nazywa się _processMessageFromRoot.

[N03] Nieprawidłowy interfejs

Połączenia GovernorSpoke błędnie zawrzeć umowę używa ChildMessengerConsumerInterface rodzaj opisać to messenger zmienny. Rozważ użycie ChildMessengerInterface zamiast.

aktualizacja: Naprawiono od momentu zatwierdzenia f31a527 in PR3680.

[N04] Przeciągnij tokeny do sklepu

W poprzedni audyt kwestionowaliśmy cel Store umowy payOracleFeesErc20 funkcjonować (w numerze L19). Zespół UMA zdecydował się zachować tę funkcję ujednolicić interfejs dla potencjalnych przyszłych modyfikacji. Ponieważ cel funkcji nie jest w pełni określony, nie jest jasne, czy powinna ona zostać wywołana, gdy Proposer umowa konfiskuje obligacje. Prawdopodobnie należy go używać, gdy OracleHub płaci za żądanie ceny. Zastanów się, czy tej funkcji należy użyć w którymkolwiek scenariuszu.

aktualizacja: Uznany. Oświadczenie UMA w tej sprawie:

N04 zaleca stosowanie dostępnej w Sklepie metody payOracleFeeErc20 w celu uiszczania opłat zarówno w umowie Oferenta, jak i OracleHub, aby zachować zgodność z korzystaniem ze Sklepu. Zdecydowaliśmy się nie używać tej funkcji, ponieważ oznaczałoby to konieczność zaimportowania dodatkowego interfejsu (dla sklepu) i wymagałoby rzutowania kwoty obligacji na FixPoint (co również wymagałoby dodatkowego importu. Aby kod był prosty i czysty zdecydowaliśmy się tego nie robić.Opinie OZ dotyczące payOracleFeeErc20 z pierwszej fazy audytu w kwietniu 1 r. potwierdziły, że ta metoda nie jest zbyt użyteczna, co utrudnia uzasadnienie tego rodzaju integracji.

[N05] TODO w kodzie

W bazie kodu znajdują się komentarze „TODO”, które należy śledzić w rejestrze zadań projektu. Na przykład:

• Linia 37 of Arbitrum_ParentMessenger umowa
• Linia 25 of Optimism_ChildMessenger umowa
• Kwestia 83 i 146 of OracleHub kontrakt.

Dobrze opisane komentarze „TODO” podczas programowania ułatwią proces ich śledzenia i rozwiązywania. Bez tych informacji komentarze te mogą ulec zniszczeniu, a informacje ważne dla bezpieczeństwa systemu mogą zostać zapomniane przed wprowadzeniem ich do środowiska produkcyjnego.

Komentarze TODO powinny zawierać krótki opis zadania oczekującego na wykonanie oraz link do odpowiedniego problemu w repozytorium projektu.

Rozważ aktualizację komentarzy TODO w celu dodania tych informacji. Aby zapewnić kompletność i identyfikowalność, można dodać podpis i znacznik czasu. Na przykład:

// TODO: point this at an interface instead.

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

// --mrice32 - 20211209

aktualizacja: Naprawiono od momentu zatwierdzenia 5d57b5b in PR3684.

[N06] Błędy typograficzne

Baza kodu zawiera następujące błędy typograficzne:

• W Admin_ChildMessenger kontrakt, impleenting powinno być implementing
• W OptimisticRewarderBase kontrakt, timestap powinno być timestamp.
• W OptimisticRewarderBase kontrakt, liveness liveness powinno być liveness.
• W GovernorSpoke kontrakt, only called powinno być only be called.
• W Optimism_ChildMessenger kontrakt:

aktualizacja: Naprawiono od momentu zatwierdzenia 9b92b0b in PR3681.

[N07] Niewykorzystany import

Aby poprawić czytelność kodu, rozważ usunięcie następujących nieużywanych importów:

aktualizacja: Naprawiono od momentu zatwierdzenia 40b7221 in PR3682.

[N08] Zlecenie transakcji L2

Połączenia Governor zapewnia transakcje w ramach oferty realizowane są w kolejności. Jeżeli jednak transakcje te obejmują transakcje międzyłańcuchowe, gwarantuje to jedynie, że dotrą do kontraktu pomostowego L1 we właściwej kolejności. W przypadku Arbitrum można je ponownie uporządkować, zanim zostaną sfinalizowane na L2. Dlatego też propozycje zarządzania powinny być tak skonstruowane, aby dopuszczały możliwość zmiany kolejności transakcji L2.

aktualizacja: Naprawiono od momentu zatwierdzenia 0fb2e7b in PR3703, GovernorHub może teraz przekazywać szereg transakcji L2.

Wnioski

W kodzie znaleziono dwa krytyczne problemy. Znaleziono jeden problem o średniej wadze i kilka mniejszych luk, po czym zasugerowano zalecenia dotyczące poprawek.

Źródło: https://blog.openzeppelin.com/uma-audit-phase-6/?utm_source=rss&utm_medium=rss&utm_campaign=uma-audit-phase-6