1 grudnia 2021 r.
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 i różne przyrostowe żądania ściągnięcia w trakcie dłuższego zaangażowania. Podczas tego audytu sprawdziliśmy nowy mechanizm szybkiego wysyłania tokenów z łańcucha warstwy 2 do sieci głównej Ethereum i powiązane zmiany w Optymistycznej Oracle. Przegląd został wykonany przez 2 audytorów w ciągu 3 tygodni.
Zakres
Sprawdzone zatwierdzenie to f24ad501c8e813cf685f72217e7f13c8f3c366df
a zakres obejmuje następujące umowy:
- umowy/ubezpieczony-pomost/* (z wyłączeniem umów testowych)
- umowy-ovm/ubezpieczony-pomost/realizacja/*
- kontrakty/common/implementation/AncillaryData.sol
- kontrakty/oracle/implementacja/SkinnyOptimisticOracle.sol
Sprawdziliśmy także zmiany w plikach solidności w Wyciągnij żądanie 3445.
Założono, że wszystkie zależności kodu zewnętrznego i kontraktu działają zgodnie z dokumentacją.
Przegląd systemu
Obsługiwane łańcuchy warstwy 2 (L2), Optimism i Arbitrum, zapewniają mechanizm przesyłania środków do sieci głównej Ethereum (L1). Jednakże ze względów bezpieczeństwa sfinalizowanie tych przekazów następuje ze znacznym opóźnieniem. Aby rozwiązać ten problem, posiadacze tokenów L2 mogą zdeponować środki w umowie UMA, skrzynce depozytowej, wiedząc, że tokeny zostaną ostatecznie przeniesione (jako partia) do kontraktu L1 UMA, czyli puli mostów. Dla każdego tokenu, który ma zostać przeniesiony, istnieje osobna Pula Mostów.
Po złożeniu depozytu L2 każdy może przekazać szczegóły do puli mostów L1, która czeka przez krótki czas na wypadek, gdyby ktoś chciał zakwestionować przekazane informacje. Wszelkie spory są rozpatrywane przez Chudą Optymistyczną Wyrocznię (opisaną poniżej). Przed zaakceptowaniem przekaźnika dostawcy płynności muszą wstępnie zasilić kontrakt Bridge Pool w zamian za tokeny LP. Zakłada się, że niekwestionowane przekazy są ważne, a Pula Pomostowa realizuje transfer przy użyciu własnych rezerw, przy czym część przekazu jest kierowana do przekazującego, a część jest zatrzymywana jako opłaty za płynność. Fundusze zostaną ostatecznie uzupełnione po sfinalizowaniu depozytu L2, a opłaty za płynność zostaną przypisane posiadaczom tokenów LP.
Bridge Pool umożliwia także każdemu indywidualne sfinansowanie przelewu (bez rezerw Bridge Pool) przed upływem okresu spornego, w zamian za ułamek kwoty przelewu. Ponieważ przekaźnik nadal może być kwestionowany, środki te zostaną utracone, jeśli przekaźnik zostanie uznany za nieprawidłowy. Oczekuje się, że w większości przypadków mechanizm ten umożliwi użytkownikom natychmiastowe transfery tokenów L2 do L1.
Chuda Wyrocznia Optymistyczna jest koncepcyjnie bardzo podobna do istniejącej Wyroczni Optymistycznej. Zapewnia mechanizm motywacyjny dla użytkowników, aby po prostu potwierdzili wynik żądania Oracle, który zakłada się, że jest dokładny, jeśli nie jest kwestionowany. Spory są kierowane do wolniejszego mechanizmu DVM opisanego w naszych poprzednich raportach z audytu. Główna różnica polega na tym, że nowa wersja wymaga od użytkowników podania wszystkich istotnych informacji podczas wykonywania wywołań funkcji, więc wartości nie muszą być zapisywane ani pobierane z pamięci. Eliminuje także możliwość zmiany parametrów konfiguracyjnych w aktywnych żądaniach przez requestery.
Już wcześniej dokonaliśmy przeglądu kontraktu Long-Short-Pair, który zapewnia ogólny mechanizm tworzenia różnych instrumentów finansowych. Kontrakty te można rozwiązać po upływie terminu ich wygaśnięcia i znany jest kurs rozliczeniowy. Zmiany wprowadzone przez Pull Request 3445 wprowadzają możliwość wcześniejszego rozwiązania kontraktów, jeżeli przed terminem ich wygaśnięcia znana jest cena rozliczeniowa.
Role uprzywilejowane
Skrzynki depozytowe L2 mają kilka parametrów konfiguracyjnych, w tym obsługiwane tokeny i maksymalną szybkość wysyłania tokenów wsadowych przez most do L1. Muszą być również skonfigurowane w celu zapewnienia spójności między umową tokenu L1, umową tokenu L2 i odpowiednią pulą mostów. Parametry te są ustalane na podstawie umowy administratora na L1, która parametryzuje również proces rozstrzygania sporów w pulach pomostowych. Oczekuje się, że umowa będzie kontrolowana przez mechanizm zarządzania UMA, dlatego użytkownicy muszą zaufać temu procesowi, aby zarządzać systemem w sposób rozsądny i uczciwy.
Zależności ekosystemowe
Wszystkie recenzowane komponenty wykorzystują logikę opartą na czasie, co oznacza, że zależą od dostępności Ethereum. W szczególności, jeśli transakcje sporne są znacznie opóźnione, nieprawidłowe przekaźniki lub propozycje cenowe mogą zostać błędnie potwierdzone.
Dodatkowo most tokenowy domyślnie zakłada, że wszystkie środki wysłane do skrzynek depozytowych L2 zostaną ostatecznie przeniesione do odpowiedniej puli mostu L1. Zależy to od prawidłowego i ciągłego funkcjonowania mostów Optymizmu i Arbitrum oraz ich mechanizmów rozstrzygania sporów.
Wreszcie tokeny wysłane do skrzynki depozytowej L2 są przypisywane do puli pomostowej w L1, a nie do zamierzonego odbiorcy. Aby odzyskać środki z puli, posiadacze tokenów L1 muszą najpierw dopasować je do dodatkowych tokenów. Dlatego mechanizm opiera się na wystarczająco głębokim rynku tokenów L1, aby zapewnić zawsze płynność.
Problemy zgłoszone przez klienta
Podczas audytu zespół UMA niezależnie zidentyfikował szereg kwestii i zachowań wartych podkreślenia:
Jeżeli parametry Optymistycznej Wyroczni lub Administratora mostu ulegną zmianie w okresie wyzwania przekaźnika, wówczas kwestionowanie przekaźnika powoduje usunięcie przekaźnika bez dodatkowych środków dla zgłaszającego lub kwestionującego. Załóżmy na przykład, że przekaźnik jest wysyłany po token zabezpieczający
TOKEN_A
, ale w środku przekaźnikaTOKEN_A
zostaje usunięty z białej listy zabezpieczeń. Spór zostanie teraz wycofany, ponieważ nie możesz przesyłać żadnych żądań cenowych do OO lub DVM w przypadku zabezpieczenia nie znajdującego się na białej liście. Ponieważ nie chcemy blokować ważnych wniosków o spór, plikBridgePool
usunie oczekujący przekaźnik dlaTOKEN_A
w przypadku sporu. Konsekwencje tej decyzji projektowej są następujące:
1. Wzrost opłaty końcowej spowoduje, że: Wszelkie zaległe przelewy na tym tokenie będą „anulowane” w drodze sporu, czy są one słuszne, czy błędne. Anulowanie nie przynosi korzyści żadnej ze stron, dlatego zakłada istnienie uczciwych dyskutantów, którzy są skłonni wyeliminować (rzadko) złe żądanie, które zdarza się podczas realizacji ostatecznej zmiany opłaty. Oznacza to również, że żałobnik może wydać gaz, aby anulować przekaźniki i zmusić je do ponownego przekazania.
2. Usunięcie białej listy identyfikatora lub tokena, co nie powinno mieć miejsca, chyba że coś pójdzie bardzo źle, spowodowałoby:
3. Wydłużony okres bezspornych wniosków, w przypadku którego każdy wniosek można anulować i nie istnieją żadne zachęty ekonomiczne do kwestionowania. Wydaje się to lepsze niż alternatywa polegająca na całkowitym blokowaniu sporów, ale jest całkiem zła, ponieważ każdy żałobnik może blokować przekaźniki na czas nieokreślony, płacąc za gaz lub wysyłać wadliwe przekaźniki bez kary (innej niż opłaty za gaz).Uwaga: jest to alternatywa dla OO, który „zamraża” na jakiś czas takie parametry, jak opłata końcowa lub biała lista zabezpieczeń, ale wymagałoby to dodatkowych rozmów z OO, co byłoby kosztowne dla szczęśliwej ścieżki.
Przekaźniki można przyspieszyć poprzez
speedUpRelay()
po tym jak przeminą żywotność. Chociaż nie widzimy w tym żadnego ryzyka, otwiera to możliwość pożyczek flash + przyspieszeń + rozliczenia po wygaśnięciu umowy, dając pożyczkobiorcy flash natychmiastową opłatę za pośrednictwo „za darmo”. W tej propozycji zapobiegamy temu PR.
On
settle
, jeśliBridgePool
jestWETH
puli, a odbiorca jest umową, która nią nie jestpayable
(nie można zaakceptować ETH), a następniesettle
zawiedzie. Planujemy to naprawić i przywrócić opcję wysyłaniaWETH
, ale nie wykonano jeszcze w tej kwestii żadnych wyjątkowych prac.
In
relayDeposit
, sprawdzamy, czyBridgePool
saldo jest większe niż kwota przekazywana PLUS w ramach kaucji wnioskodawcy. Jest to przestarzały czek i zbyt konserwatywny, ponieważ po sprawdzeniu kaucja wnioskodawcy jest pobierana od użytkownika. Zajmujemy się tym w niniejszym wniosku PR.
Właśnie złapałem błąd gdzie
chainId
inBridgePool
, zawarte jako częśćDeposit
struct i jako funkcja wejściowa dla wszystkich funkcji związanych z przekaźnikiem (tjrelayDeposit
,speedUpRelay
,settle
) jest typemuint8
. Jest to zbyt mały typ, aby obsłużyć na przykład Arbitrum o identyfikatorze 421611. Właściwie wyłapaliśmy ten błąd i naprawiliśmy go po stronie L2:BridgeDeposit
ustalił swojechainId
wpisz douint256
. Ten PR sprawi, żechainId
onBridgePool
pasuje do typuBridgeDepositBox
: Protokół UMA/protokół nr 3463
Poprzednio funkcja sporu nie odejmowała kwoty depozytu
pendingReserves
(jest to zmienna, która śledzi, jaka część puli rezerw jest zablokowana z powodu przekaźników, które jeszcze się nie rozwiązały). W rezultacie każdy spór blokował kwotę przekaźnikową w puli na czas nieokreślony. Nie może zostać wycofany przez LP ani wykorzystany w przyszłych sztafetach. Poprawka jest tutaj: Protokół UMA/protokół nr 3473.
Znaleźliśmy błąd w
BridgeDepositBox
gdziehasEnoughTimeElapsedToBridge
nie sprawdza, czy auint256
wartość jest równa0
domyślnie: Naprawiono w PR 3484
Metoda kursu wymiany (która polega na modyfikowaniu stanu) jest wywoływana pomiędzy transferem tokenów a wybijaniem tokenów LP w metodzie addLiquidity kontraktu puli pomostowej. To obliczenie należy przenieść na początek metody. Powoduje to bardzo dziwne wartości stanu. Zobacz PR tutaj naprawić.
Metoda widoku
liquidityUtilizationPostRelay
(który jest używany tylko w trybie offchain) zgłasza nieprawidłowy numer wykorzystania. Mianownik włączony ta linia nie powinno być sprawiedliweliquidReserves
zamiast tego powinno to być przedstawienie niewykorzystanych i wykorzystanych rezerw. Naprawił tutaj.
Aktualizacja
Oprócz poprawek błędów sprawdziliśmy także następujące zmiany przyrostowe:
- PR3500 usuwa nadmiarowy parametr tokenu z
BridgePool
wydarzenia. - PR3478 dodaje końcową opłatę DVM do listy zmiennych buforowanych lokalnie.
- PR3460 uwzględnia możliwy przypadek skrajny ujemnego wykorzystania płynności (oprócz rozwiązania N04)
- PR3482 usuwa zbędne pliki i aktualizuje stałe OVM zgodnie ze zmianami OVM 2.0.
- PR3585 aktualizuje
BridgeDepositBox
interfejs zapewniający spójność i wykorzystuje OpenZeppelinSafeERC20
biblioteka.
Przeglądając poprawki, znaleźliśmy inny problem. Przy ustalaniu wartości BridgePool
tokeny LP, istnieje obliczenia pośrednie, które mogą spowodować nieoczekiwane ujemne przepełnienie, co tymczasowo uniemożliwiałoby dodawanie i usuwanie płynności. Należy zmienić kolejność obliczeń, aby dodać wykorzystane rezerwy przed odjęciem niepodzielonych opłat.
Krytyczna dotkliwość
[C01] Nagroda dla Uwięzionego Wnioskodawcy
Połączenia LongShortPair
umowa odbiera nagrodę dla proponującego z dowolnego adresu powoduje wygaśnięcie, co jest wykorzystywane do zachęcania do propozycji cenowych w Optymistycznej Wyroczni. Jednakże LongShortPairCreator
umowa również pobiera i przekazuje środki z adresu wdrażającego. Te dodatkowe fundusze nie są przekazywane Optymistycznej Wyroczni i zamiast tego pozostają uwięzione w jej wnętrzu LongShortPair
kontrakt.
Rozważ usunięcie duplikatu przelewu.
aktualizacja: Naprawiono od momentu zatwierdzenia 9bab1ff353a417952ba8c96a098773f340d9da17
in PR3523.
Wysoka dotkliwość
[H01] Przekaźniki współbieżne wyczerpują rezerwy
Połączenia relayDeposit
funkcja BridgePool
umowa zapewnia, że w ramach zamówienia znajdują się wystarczające środki finansowe w celu wykonania przelewu. Nie uwzględnia to jednak oczekujące rezerwy, który śledzi środki przeznaczone na aktywne przekaźniki. W związku z tym wiele jednoczesnych przekazów może opierać się na tych samych środkach i nie wszystkie mogą zostać rozliczone natychmiast. W szczególności przy stałym strumieniu transferów natychmiastowe zwroty przekaźników mogą być opóźnione w nieskończoność.
Należy rozważyć zapobieganie przekaźnikom, które spowodowałyby przekroczenie rezerw oczekujących nad rezerwami cieczy.
aktualizacja: Naprawiono od momentu zatwierdzenia 6290f3facbca8d878605a1d390ed59d4b6b6db02
in PR3501.
[H02] Granice parametrów mostkowania nie są zgodne
Połączenia deposit
funkcjonować ukończenia BridgeDepositBox
kontrakt, wdrożony w łańcuchach warstwy 2, służy do łączenia funduszy pomiędzy L2 i L1. W szczególności zachęca się do tego przekaźników przekaźnik szczegóły transakcji na powiązanym L1 BridgePool
. Jednak skrytka depozytowa korzysta granice włączające ograniczyć opłaty za sztafetę, podczas gdy pula pomostowa korzysta wyłączne granice. Oznacza to, że niektórych depozytów (z 25% opłatami pośrednimi) nie można przekazać, a środki będą niedostępne na obu poziomach.
Rozważ synchronizację walidacji na obu warstwach, aby mieć pewność, że wszystkie ważne depozyty będą mogły zostać przekazane.
aktualizacja: Naprawiono w zatwierdzeniu 2345966b3a2ace0159379b3a13256cc1a4c5d52f
of PR3494. Pierwotnie zostało to sklasyfikowane jako Dotkliwość krytyczna, ale zostało obniżone, gdy zespół UMA wskazał, że fundusze nie zostaną ściśle uwięzione i mogą zostać uwolnione, jeśli wyborcy DVM zgodzą się zaakceptować zmodyfikowany opis przekaźnika dla dotkniętych depozytów.
Średni stopień nasilenia
[M01] Oddzwanianie na zły adres
Połączenia SkinnyOptimisticOracle
wywołuje funkcje wywołania zwrotnego na żądającym cenie, jeśli takie istnieją, aby żądający mógł zareagować na znaczące zmiany stanu. Jednak wywołanie zwrotne jest nieprawidłowo wywoływane w odniesieniu do proponującego cenę, a nie żądającego ceny w dotychczasowy proposePriceFor
funkcjonować. Oznacza to, że osoba żądająca ceny nie jest w stanie odpowiedzieć na propozycje cenowe.
Na szczęście ta funkcja nie jest używana w bieżącej bazie kodu. Niemniej jednak rozważ wywołanie metody priceProposed
oddzwonienie do osoby żądającej.
aktualizacja: Naprawiono przy zatwierdzeniu 7bd3faeb6f3706132f77b9ba2dce192d1a151e74
in PR3531.
[M02] Wadliwa funkcja dodawania
Połączenia appendKeyValueBytes32
funkcjonować powinien połączyć swoje dane wejściowe w sformatowany plik bytes
szyk. Jednakże currentAncillaryData
is błędnie wyrzucone.
Ponieważ dane pomocnicze wpływa na proces rozwiązywania problemów Oracle, niepoprawna wartość może podważyć wyniki Oracle. Na szczęście jest tylko jedno wezwanie do appendKeyValueBytes32
w bazie kodu i używa pustego currentAncillaryData
bufor, więc błąd nie ma wpływu na ten przypadek.
Rozważ aktualizację appendKeyValueBytes32
funkcjonować tak, że currentAncillaryData
jest zawarty w zwracanej tablicy bajtów.
aktualizacja: Naprawiono w zatwierdzeniu 5609433c154f47e8ee9c52f9b6d7c787fbe3e455
of PR3532.
[M03] Niekompletna walidacja danych pomocniczych
Połączenia LongShortPair
konstruktor potwierdza, że customAncillaryData
jest na tyle mała. Nie uwzględnia to jednak pole wcześniejszej wygaśnięcia. Oznacza to Optymistyczną Wyrocznię może nieoczekiwanie odrzucić żądania ceny z wcześniejszym wygaśnięciem, co spowodowałoby wyłączenie tej funkcji.
Rozważ aktualizację walidacji w celu uwzględnienia dodatkowego pola.
aktualizacja: Naprawiono od momentu zatwierdzenia 4a56e66492f40e20254cebb145c2d91304f7cb43
in PR3524.
[M04] Źle obsłużony zerowy znacznik czasu
W LongShortPair
umową, znacznik czasu wcześniejszego wygaśnięcia wynosi zero używany jako flaga aby wskazać, że nikt nie uruchomił mechanizmu wcześniejszego wygaśnięcia. Jednak jest to możliwe uruchomić ten mechanizm z zerowym znacznikiem czasu. W tym scenariuszu zostanie wywołana Wyrocznia Optymistyczna, ale ochrona przed kolejnymi zapytaniami cenowymi nie będzie skuteczne. Na szczęście raz wybierana jest cena rozliczeniowa, nie zostanie on zastąpiony, więc nie będzie to prowadzić do niespójnych rozliczeń. Niemniej jednak późniejsze zapytanie o cenę mogłoby zmienić zarejestrowany znacznik czasu wcześniejszej wygaśnięcia, nawet jeżeli do określenia ceny rozliczeniowej stosowany jest zerowy znacznik czasu. Mogło też emitować wprowadzające w błąd wydarzenie.
Rozważ zapobieganie przedwczesnemu wygaśnięciu przy użyciu zerowego znacznika czasu.
aktualizacja: Naprawiono od momentu zatwierdzenia 11d287c07c93c04f534b2ef3c869966d9f18ac60
in PR3526.
[M05] Możliwe wiązanie zerowe
Połączenia requestPrice
funkcja SkinnyOptimisticOracle
umowa wykorzystuje opłatę końcową jako zabezpieczenie jeżeli obligacja nie jest określona. Jednakże requestAndProposePriceFor
funkcjonować może używać wiązania zerowego, co jest jej sprzeczne @notice
i @param
uwagi. Zerowa obligacja osłabia zachętę do nieważnych propozycji lub sporów.
Na szczęście, wywołaj tylko tę funkcję w bazie kodu ustawia obligację wnioskodawcy. Niemniej jednak rozważ zastosowanie opłaty końcowej, jeśli kaucja nie jest określona.
aktualizacja: Naprawiono od momentu zatwierdzenia daaabfc342ba1395a577159b6eb26adb20fcd232
in PR3534.
[M06] Niepotrzebne uprawnienia administratora
Połączenia BridgePool
umowa dziedziczy z ExpandedERC20
aby mógł wydawać tokeny LP dostawcom płynności. Dziedziczy to funkcjonalność OpenZeppelin ERC20
kontrakt i także zapewnia uprawnienia administratora do wdrażającego kontrakt, co pozwala mu na wybicie i spalenie tokenów LP. Uprawnienie to nie jest jednak wymagane, a jego wykorzystanie mogłoby niesprawiedliwie ukarać dostawców płynności.
Rozważ modyfikację BridgePool
dziedziczyć bezpośrednio ERC20
zamiast ExpandedERC20
.
aktualizacja: Naprawiono w zatwierdzeniu 370e8b21b660543eadbd764fed984a5bdeddce24
in PR3492.
Niska dotkliwość
[L01] Nie można rozliczyć po wygaśnięciu
Połączenia settle
funkcja LongShortPair
umowa bierze pod uwagę warunki rozliczenia gdy bieżący czas przypada dokładnie przed lub po znaczniku czasu wygaśnięcia. Jednak przywraca to niepoprawnie, gdy bieżący czas odpowiada sygnaturze czasowej wygaśnięcia.
Rozważ użycie powiązania włączającego w celu dopasowania postExpiration
modyfikator.
aktualizacja: Naprawiono w zatwierdzeniu f03cdaa50b16d29e8f42f000bf7cd50a042cf616
in PR3527.
[L02] Brakujący komunikat o błędzie w instrukcji require
W pliku znajduje się instrukcja require BridgePool
umowa bez komunikatu o błędzie.
Rozważ uwzględnienie konkretnych i informacyjnych komunikatów o błędach we wszystkich instrukcjach require.
aktualizacja: Naprawiono od momentu zatwierdzenia 67e60faa3a44c842c37211d2e903a983ff192e57
in PR3536.
[L03] Brakujące dokumenty
Istnieje kilka przypadków w całej bazie kodu, w których plik Naturalna specyfikacja Ethereum brakuje lub jest niekompletny. Przykłady obejmują:
Rozważ dokładne udokumentowanie wszystkich funkcji (i ich parametrów), które są częścią publicznego interfejsu API kontraktów.
aktualizacja: Wyróżnione komentarze zostały naprawione w zatwierdzeniu e943e85a7dae60acd17a6d6aa027fbb1017c95ee
of PR3533. Nie sprawdziliśmy kompletności NatSpec w pozostałej części bazy kodu.
Uwagi i dodatkowe informacje
[N01] Nie sprawdzono wartości zwrotnej wywołania
W deposit
funkcjonować L2 BridgeDepositBox
kontraktu, istnieje wywołanie niskiego poziomu do l2Token
kiedy l1Token
is l1Weth
. To wywołanie niskiego poziomu jest skierowane do deposit()
funkcja należąca do MOC interfejs. Jeśli to l2Token
zachowuje się dokładnie tak jak WETH i nigdy nie powinien zawieść. Ale w przypadku l2Token
zachowuje się inaczej i kończy się niepowodzeniem, nie będzie powrotu, ponieważ flaga powodzenia tego wywołania niskiego poziomu nigdy nie jest sprawdzana.
Rozważ sprawdzenie i odpowiednią reakcję na wartości zwracane przez wszystkie wywołania niskiego poziomu.
[N02] Brak indeksowanych parametrów w zdarzeniach
Wiele zdarzeń zdefiniowanych w tym kodzie ma parametry, które należy zaindeksować:
Rozważać indeksowanie parametrów zdarzeń aby uniknąć utrudniania wyszukiwania i filtrowania usług poza łańcuchem pod kątem określonych zdarzeń.
aktualizacja: Częściowo naprawiono w zatwierdzeniu d156b40b2ddb109806336c4d169dbdea91ed1c3e
of PR3535, chainId
parametr WhitelistToken
nie został zaktualizowany.
[N03] Ukryta niespójność rzutowania
Połączenia LongShortPair
umowa ogólnie traktuje znaczniki czasu jako uint64
wartości, które są domyślnie rzutowane na uint256
wartości, gdy przekazane Optymistycznej Wyroczni. Jednakże requestTimestamp
parametr dotychczasowy _requestOraclePrice
funkcjonować jest przedwcześnie rzutowany na a uint256
. Nie ma to żadnych konsekwencji funkcjonalnych.
Niemniej jednak, w trosce o spójność, rozważ użycie a uint64
dla tego parametru i umożliwienie jego niejawnego rzutowania na a uint256
po przekazaniu Optymistycznej Wyroczni.
aktualizacja: Naprawiono w zatwierdzeniu 1c3c5c000ef450f5e2da056e41caff468c3fcdcb
of PR3528. Znacznik czasu jest teraz jawnie rzutowany.
[N04] Nieprawidłowy typ
Połączenia sendMessage
funkcja iOptimism_CrossDomainMessenger
Interfejs używa a uint256
limit gazu podczas gdy Optymizm OVM_CrossDomainEnabled
używa a uint32
limit gazu.
Aby zapewnić spójność i przewidywalność, rozważ aktualizację pliku iOptimisim_CrossDomainMessenger
sendMessage
funkcja do użycia a uint32
limit gazu.
aktualizacja: Naprawiono od momentu zatwierdzenia 381951aad988bbba6b2ef1b136ed5c48df50aa88
in PR3460.
[N05] Brak walidacji
Wszystkie funkcje w BridgeAdmin
ten telefon _relayMessage
załóżmy, że wartość transakcji jest zgodna z l1CallValue
parametr, ale nie jest to wymuszane.
Rozważ zapewnienie prawidłowego msg.value
jest ustawiona.
aktualizacja: Naprawiono od momentu zatwierdzenia f19b8d04c2343051ff2a8145abd41c39bd025063
in PR3537.
[N06] Czytelność
Połączenia _getDepositHash
funkcjonować ukończenia BridgePool
umowa rozwija depositData
struktura, która ma przeplatać l1Token
jako argument w składzie keccak256
z abi
kodowanie. To sprawia, że operacja jest niepotrzebnie rozwlekła i może prowadzić do błędów w przypadku ponownego wdrożenia na innych warstwach.
Rozważ uproszczenie argumentów, aby były po prostu uporządkowaną parą depositData
i l1Token
.
aktualizacja: Naprawiono od momentu zatwierdzenia 31754be4a818109fa12131f854c3f70d6c72dba7
in PR3538.
[N07] Funkcja ponownego wchodzenia
Połączenia requestAndProposePriceFor
funkcjonować ukończenia SkinnyOptimisticOracle
kontrakt wywołuje niezaufanego msg.sender
ale nie jest strzeżony przez a nonReentrant
modyfikator. Chociaż w tym przypadku nie wydaje się to stanowić problemu bezpieczeństwa, może to spowodować nieoczekiwane zachowanie.
Rozważ dodanie nonReentrant
modyfikator do wszystkich funkcji wywołujących potencjalnie niezaufane kontrakty.
aktualizacja: Naprawiono w zatwierdzeniu b744d24e7579b7afa2c778f4dd680f26117b3990
of PR3539.
[N08] seqNum
niezalogowany
Połączenia relayMessage
funkcjonować ukończenia Arbitrum_Messenger
kontrakt nie emituje odpowiedniego zdarzenia po wykonaniu wrażliwej akcji. The relayMessage
wywołania funkcji jako podprogram sentTxToL2NoAliasing
który sam zwraca uint256
wartość seqNum
, ale ta zwracana wartość nie jest rejestrowana w pliku relayMessage
funkcja.
Rozważ emisję zdarzeń po zaistnieniu wrażliwych zmian, aby ułatwić śledzenie i powiadamianie klientów spoza łańcucha o aktywności w ramach kontraktu.
aktualizacja: Naprawiono od momentu zatwierdzenia 30343f33532a6c255dc4cc18c3b497d9b2767a7c
in PR3541.
[N09] Błędy typograficzne
Baza kodu zawiera następujące literówki:
Rozważ poprawienie tych literówek, aby poprawić czytelność kodu.
aktualizacja: Naprawiono od momentu zatwierdzenia 2dccbe1c2c82fe2a21c179ac06c2d4f0d911a2ca
in PR3540.
[N10] Nieudokumentowany wymóg zatwierdzenia ERC20
Połączenia requestEarlyExpiration
i expire
Funkcje ukończenia LongShortPair
umowy zakładają, że dzwoniący udzielił umowie ulgi wyciągnąć nagrodę dla proponującego.
Ze względu na przewidywalność rozważ udokumentowanie tego wymagania w komentarzach funkcji.
aktualizacja: Naprawiono w zatwierdzeniu da3754f50284480df57b90b80002da06a1ce0d02
in PR3529.
[N11] Niewykorzystany modyfikator
W BridgePool
kontrakt, plik onlyFromOptimisticOracle
modyfikator jest zdefiniowany, ale nigdy nie jest używany w bazie kodu i dlatego powinien zostać usunięty.
aktualizacja: Naprawiono w zatwierdzeniu 7abece6377637e8c4cd3bd07ab9adcfa051d4e94
in PR3542.
wnioski
Znaleziono 2 problemy krytyczne i 1 o dużej wadze. Zaproponowano pewne zmiany, aby zastosować się do najlepszych praktyk i zmniejszyć potencjalną powierzchnię ataku.
- &
- 7
- Konto
- Działania
- aktywny
- Ad
- Dodatkowy
- adres
- Admin
- Korzyść
- Wszystkie kategorie
- Pozwalać
- api
- argumenty
- Audyt
- dostępność
- jest
- BEST
- Najlepsze praktyki
- blockchain
- Pudełko
- BRIDGE
- Bug
- błędy
- wezwanie
- Etui
- złapany
- Spowodować
- wyzwanie
- zmiana
- kontrola
- kod
- komentarze
- systemu
- zawiera
- umowa
- umowy
- mógłby
- Aktualny
- dane
- Zdecentralizowane
- opóźnienie
- Wnętrze
- określaniu
- ZROBIŁ
- Spierać się
- Nie
- Wcześnie
- Gospodarczy
- krawędź
- Efektywne
- ERC20
- ETH.
- ethereum
- Ethereum blockchain
- wydarzenie
- wydarzenia
- przykład
- wymiana
- spodziewany
- doświadczenie
- Cecha
- Opłaty
- budżetowy
- i terminów, a
- Fix
- Migać
- obserwuj
- znaleziono
- funkcjonować
- fundusz
- fundusze
- przyszłość
- GAS
- opłaty za gaz
- Dający
- zarządzanie
- Zaoszczędzić
- mający
- tutaj
- Wysoki
- Podświetlony
- posiadacze
- W jaki sposób
- HTTPS
- zachęcania
- włączony
- Włącznie z
- Zwiększać
- Informacja
- odsetki
- Interfejs
- problemy
- IT
- znany
- prowadzić
- Biblioteka
- Ciecz
- Płynność
- dostawcy płynności
- Lista
- Kredyty
- lokalnie
- zamknięty
- LP
- LP
- rynek
- Mecz
- większość
- koncepcja
- wyrocznia
- Inne
- Platforma
- basen
- Baseny
- power
- zapobieganie
- Cena
- wygląda tak
- wniosek
- zapewniać
- zapewnia
- publiczny
- Przyczyny
- zmniejszyć
- Raporty
- REST
- Efekt
- powraca
- przeglądu
- Ryzyko
- bezpieczeństwo
- Usługi
- zestaw
- osada
- Short
- znaczący
- podobny
- mały
- So
- solidność
- Ktoś
- coś
- prędkość
- wydać
- Stan
- Zestawienie sprzedaży
- przechowywanie
- sukces
- Utrzymany
- Powierzchnia
- system
- test
- Przez
- poprzez
- czas
- żeton
- Żetony
- Top
- Śledzenie
- transakcja
- transakcje
- Zaufaj
- Aktualizacja
- Nowości
- UPS
- Użytkownicy
- wartość
- Zobacz i wysłuchaj
- whitelist
- KIM
- w ciągu
- bez
- Praca
- wartość
- zero