Slow Mist: Podręcznik audytu bezpieczeństwa Compound Finance V2

Wprowadzenie

Wraz z szybkim rozwojem ekosystemu DeFi, Compound Finance V2 jako jeden z pionierów w tej dziedzinie przyciągnął wielu użytkowników dzięki innowacyjnemu modelowi pożyczek. Jednak każde skomplikowane zdalne zastosowanie napotyka potencjalne zagrożenia bezpieczeństwa, zwłaszcza gdy mowa o przepływie funduszy wartości milionów, a nawet setek milionów dolarów. Dlatego przeprowadzenie pełnego i szczegółowego audytu bezpieczeństwa Compound Finance V2 i jego projektów typu fork jest szczególnie ważne. Niniejszy podręcznik ma na celu dostarczenie deweloperom, badaczom bezpieczeństwa i entuzjastom DeFi szczegółowego przewodnika po audycie bezpieczeństwa, aby pomóc w skuteczniejszym identyfikowaniu i zapobieganiu potencjalnym ryzykom.

1. Przegląd tła projektu

Compound Finance V2 to otwarta platforma pożyczkowa zbudowana na blockchainie Ethereum, która pozwala użytkownikom wpłacać różne podstawowe tokeny ERC-20 i zarabiać na nich odsetki, a także pożyczać tokeny z rynku w zamian za płacenie odsetek. Wprowadzając koncept „rynku stóp procentowych”, osiąga zdecentralizowane zarządzanie funduszem i automatyczną mechanikę dostosowywania stóp procentowych.

2. Analiza architektury projektu

Kluczowe komponenty architektury Compound Finance V2 obejmują:

• Comptroller: kontroluje logikę całego systemu, taką jak obliczanie stóp procentowych, utrzymanie stanu konta itp.

• cToken: niestandardowy token zgodny ze standardem ERC-20, reprezentujący prawa użytkownika w systemie.

• InterestRateModel: model obliczający stopy procentowe depozytów i pożyczek.

• PriceOracle: dostarcza oracle cen aktywów.

• Zarządzanie: odpowiedzialne za funkcje związane z zarządzaniem społecznością.

2.1 Comptroller

Kontrakt Comptroller jest centralnym układem nerwowym Compound Finance V2, odpowiedzialnym za koordynację działań różnych instancji cToken. Główne odpowiedzialności obejmują:

• Zarządzaj listą rynków, aby ustalić, które rynki są aktywne.

• Wykonuj różne kontrole operacji między rynkami, takie jak kontrole zdrowia pozycji użytkownika itp.

• Ustawiaj i aktualizuj globalne parametry, takie jak limity pożyczek, współczynniki zabezpieczenia, progi likwidacji itp.

2.2 cToken

Każdy wspierany token ERC-20 ma odpowiadający mu egzemplarz cToken (tj. kontrakt CErc20 / CEther), który obsługuje wszystkie operacje interakcji tego tokena z projektem. Każdy cToken, oprócz podstawowej funkcji transferu tokenów, dodaje również kilka specyficznych dla Compound funkcji, takich jak pożyczki, akumulacja odsetek i przydzielanie nagród. Możemy więc postrzegać cToken jako dowód na aktywa wpłacone przez użytkownika na Compound i wejście do operacji pożyczkowych.

Gdy użytkownik wpłaca podstawowe tokeny aktywów do kontraktu, może mintować odpowiadające mu tokeny cToken, a kurs wymiany cToken z aktywami podstawowymi jest obliczany według poniższej formuły:

Uwaga: borrows oznacza kwotę pożyczek, cash oznacza saldo funduszu, a reserves oznacza rezerwy. Stopa procentowa pożyczek zależy od wskaźnika wykorzystania, a stopa procentowa depozytów zależy od stopy procentowej pożyczek.

Użytkownik zazwyczaj dokonuje operacji pożyczek tokenów na różnych rynkach poprzez interakcję z różnymi kontraktami cToken:

2.3 InterestRateModel

Umowa InterestRateModel definiuje sposób obliczania stóp procentowych. Różne rynki mogą stosować różne rodzaje modeli stóp procentowych, aby dostosować się do własnych preferencji ryzyka i potrzeb płynności.

Dostępne modele stóp procentowych używane na rynku Compound V2 to głównie dwa: model liniowy i model punktów przegięcia.

Formuła obliczania stopy procentowej w modelu liniowym jest następująca:

Formuła obliczania wskaźnika wykorzystania funduszy jest następująca:

Stopy procentowe depozytów zmieniają się liniowo w zależności od stóp procentowych pożyczek:

Wzrost wskaźnika wykorzystania oznacza, że pieniądze w funduszu stopniowo maleją. Gdy osiągnie określony szczyt, może to uniemożliwić użytkownikom dokonywanie normalnych wpłat i pożyczek. Aby jak najlepiej uniknąć tej sytuacji, Compound wprowadził drugi model stóp procentowych - model punktów przegięcia.

Formuła obliczania stopy procentowej w modelu punktów przegięcia jest następująca:

Gdy wskaźnik wykorzystania osiągnie określony szczyt, znacznie zwiększa to stopy procentowe pożyczek i depozytów, zachęcając użytkowników do większych wpłat i mniejszych pożyczek, aby kontrolować wskaźnik wykorzystania w odpowiednim zakresie. Ten szczyt nazywany jest punktem przegięcia (zwykle przy wskaźniku wykorzystania wynoszącym 80%).

2.4 PriceOracle

Kontrakt PriceOracle odpowiada za pozyskiwanie informacji o cenach zewnętrznych rynków i przekształcanie ich w wartości używane wewnętrznie w systemie, co jest kluczowe dla dokładnego obliczania wartości pozycji użytkownika.

2.5 Mechanizm zarządzania i model zachęt

Compound wprowadza unikalny mechanizm zarządzania, który pozwala użytkownikom posiadającym tokeny zarządzające (COMP) uczestniczyć w głosowaniu nad ważnymi decyzjami, takimi jak zmiana niektórych parametrów lub dodawanie nowych typów aktywów. Poprzez emisję tokenów zarządzających (COMP), Compound zachęca użytkowników do aktywnego uczestnictwa w działaniach platformy i nagradza wkład. Szczegółowe informacje można znaleźć w dokumentacji i repozytorium kodu Compound (https://docs.compound.finance/v2/; https://github.com/compound-finance/compound-protocol)

3. Proces interakcji

Następnie przedstawimy prosty przykład ilustrujący ogólny proces interakcji użytkownika na Compound Finance V2:

3.1 Proces wpłaty i wykupu

Jeśli użytkownik Alicja chce wpłacić 1 WBTC do Compound, wywoła funkcję mint kontraktu cWBTC, aby dokonać wpłaty. Kontrakt dziedziczy po kontrakcie cToken i najpierw przez funkcję mintInternal wewnętrznie wywołuje funkcję accrueInterest, aby zaktualizować stopy procentowe pożyczek i depozytów, a następnie wywołuje mintFresh, aby przeprowadzić konkretne operacje mintowania.

Funkcja mintFresh zewnętrznie wywołuje funkcję mintAllowed kontraktu Comptroller, aby sprawdzić, czy aktualny rynek zezwala na depozyt, a następnie przesyła 1 WBTC użytkownika do kontraktu przez funkcję doTransferIn, a następnie na podstawie najnowszego kursu wymiany mintuje odpowiednią ilość tokenów cToken (zakładając, że aktualny kurs wymiany wynosi 0,1, Alicja otrzyma 10 tokenów cWBTC).

Jeśli Alicja zdecyduje się na wykup depozytu w przyszłości, może wywołać funkcję redeem, aby wymienić cWBTC na WBTC, a kurs wymiany może się zmienić (zakładając 0,15), co oznacza, że Alicja może wykupić 1,5 WBTC, z czego 0,5 WBTC to dochód z odsetek.

3.2 Proces pożyczania i spłaty

Alicja najpierw musi wywołać funkcję enterMarkets kontraktu Comptroller, aby ustawić jej cWBTC jako stan, w którym może być używane jako zabezpieczenie, a następnie może przeprowadzić pożyczkę.

Zakładając, że Alicja zdecyduje się pożyczyć 70 USDC, ponieważ współczynnik zabezpieczenia WBTC wynosi 0,75, Alicja może pożyczyć maksymalnie równowartość 75% wartości WBTC, więc nie przekroczy swojego maksymalnego limitu pożyczki.

Uwaga: aby uniknąć ryzyka likwidacji, Alicja powinna zachować pewną przestrzeń buforową, a nie całkowicie zużywać swój limit pożyczek.

Alicja wywołuje funkcję borrow kontraktu cUSDC, która najpierw poprzez funkcję borrowInternal wywołuje wewnętrznie funkcję accrueInterest, aby zaktualizować stopy procentowe pożyczek i depozytów, a następnie wywołuje borrowFresh, aby przeprowadzić konkretne operacje pożyczkowe.

Po przeprowadzeniu sprawdzenia wartości pozycji użytkownika przez funkcję borrowAllowed kontraktu Comptroller, najpierw rejestruje się dane pożyczkowe, a następnie przez funkcję doTransferOut tokeny są przekazywane użytkownikowi.

Jeśli Alicja potrzebuje spłacić pożyczkę, może to zrobić, wywołując funkcję repayBorrow kontraktu cUSDC, lub pozwolić innym osobom wywołać funkcję repayBorrowBehalf, aby spłacić w jej imieniu.

3.3 Proces likwidacji

Jeśli cena WBTC znacznie spadnie, a wartość zabezpieczenia Alicji spadnie poniżej 75% jej limitu pożyczki, pozycja pożyczkowa Alicji znajdzie się w stanie likwidacji.

Zewnętrzny likwidator (np. Bob) może wywołać funkcję likwidacji liquidateBorrow w kontrakcie cUSDC, aby pomóc Alicji w spłacie części długu. Najpierw zaktualizuje stopy procentowe cUSDC i zabezpieczenia cToken przy użyciu funkcji liquidateBorrowInternal, a następnie wywoła liquidateBorrowFresh, aby przeprowadzić konkretne operacje likwidacyjne.

Po wykonaniu kontroli, czy likwidacja jest dozwolona przez funkcję liquidateBorrowAllowed kontraktu Comptroller, najpierw wywołuje się funkcję repayBorrowFresh, aby przelać USDC do kontraktu na spłatę, a następnie aktualizuje dane pożyczkowe likwidowanego. Następnie wywołuje się funkcję liquidateCalculateSeizeTokens kontraktu Comptroller, aby obliczyć, ile odpowiednich zabezpieczeń Bob może uzyskać od Alicji, a na końcu przez kontrakt cToken wskazujący rynek zabezpieczeń (np. cWBTC) wywołuje się funkcję seize, aby przenieść cTokeny do Boba i Alicji.

Otwórz ten link, aby zobaczyć wersję w wysokiej rozdzielczości powyższego obrazu, klikając na przeczytaj oryginalny tekst, aby przejść bezpośrednio: https://www.figma.com/board/POkJlvKlWWc7jSccYMddet/Compound-V2?node-id=0-1&node-type=canvas.

Bob spłaca część pożyczki Alicji (na przykład 20 USDC) i w zamian otrzymuje odpowiednią wartość zabezpieczenia Alicji (np. WBTC), a ponadto Bob może otrzymać dodatkową premię likwidacyjną (zakładając 5%). Ostateczny wynik to WBTC o wartości 21 USDC (20 USDC pożyczki + 1 USDC premii likwidacyjnej).

4. Lista kontrolna luk bezpieczeństwa

4.1 Luki w zaokrągleniu wynikające z pustego rynku

Jeśli cToken jest w sytuacji pustego rynku (tj. nikt nie dokonuje pożyczek ani wpłat na rynku), to wartość exchangeRate w funkcji exchangeRateStoredInternal zależy od liczby tokenów aktywów bazowych odpowiadających kontraktowi, więc można manipulować ceną cToken, przekazując do kontraktu dużą ilość aktywów bazowych.

W związku z tym można pożyczyć dużą ilość innych tokenów przy użyciu niewielkiej ilości cTokenów, a następnie wywołać funkcję redeemUnderlying cToken, aby wydobyć aktywa bazowe. Przy obliczaniu wykupu liczba cTokenów, które należy odjąć, może być znacznie mniejsza od oczekiwanej z powodu zaokrąglenia wynikającego z dzielenia (prawie tylko połowa).

Zakładając, że liczba posiadanych cTokenów wynosi 2 (co jest również całkowitym totalSupply), a exchangeRate po manipulacji wzrosło do 25,015,031,908,500,000,000,000,000,000, liczba tokenów aktywów bazowych do wykupu wynosi 50,030,063,815. Oczekiwana liczba cTokenów do odjęcia powinna wynosić:

A faktycznie obliczona liczba cTokenów wynosiła:

W związku z tym wystarczy, że do likwidacji wymagana jest niewielka ilość cTokenów, aby uzyskać dużą ilość aktywów z innych rynków.

Można zobaczyć transakcję, w której projekt fork Compound Hundred Finance został zhakowany z powodu tej luki: https://optimistic.etherscan.io/tx/0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

Punkty audytu: podczas audytu należy zwrócić uwagę na to, czy sposób obliczania kursu wymiany jest łatwy do manipulacji oraz czy metoda zaokrąglania jest odpowiednia. Można zasugerować zespołowi projektu natychmiastowe mintowanie małej ilości cTokenów po utworzeniu nowego rynku, aby zapobiec manipulacji rynkiem, gdy jest pusty.

4.2 Problemy z rekurencją spowodowane tokenami ERC677 / ERC777

ERC677 / ERC777 to rozszerzenie kontraktów ERC20, które jest zgodne ze standardem protokołu tokenów ERC20. Te tokeny pozwalają na wywołanie funkcji zwrotu adresu, jeśli adres odbiorcy jest kontraktem w trakcie transferu (np. transferAndCall lub tokensReceived).

W starych wersjach kodu Compound Finance V2, gdy użytkownik dokonuje pożyczki w rynku cToken, najpierw przekazywane są pożyczane tokeny, a następnie rejestrowane są dane pożyczki.

Jeśli pożyczone tokeny to tokeny ERC677 / ERC777 z funkcją zwrotu, można skonstruować złośliwy kontrakt odbierający tokeny, aby ponownie wejść do funkcji borrow przez funkcję zwrotu, ponieważ dane pożyczki użytkownika nie zostały jeszcze zapisane, więc można ponownie pożyczyć tokeny pomyślnie, przechodząc kontrolę zdrowia konta.

Można zobaczyć transakcję, w której projekt fork Compound Hundred Finance został zhakowany z powodu tej luki: https://blockscout.com/xdai/mainnet/tx/0x534b84f657883ddc1b66a314e8b392feb35024afdec61dfe8e7c510cfac1a098

Punkty audytu: w najnowszej wersji kodu Compound V2 naprawiono logikę pożyczek, zmieniając ją na najpierw rejestrowanie danych pożyczek, a następnie przekazywanie pożyczanych tokenów. Podczas audytu należy zwrócić uwagę na to, czy kod związany z funkcjonalnością pożyczek jest zgodny z normą CEI (Checks-Effects-Interactions) oraz uwzględnić wpływ tokenów z funkcją zwrotu.

4.3 Ryzyko manipulacji cenowej wynikające z niewłaściwego mechanizmu oracle

Ponieważ Compound Finance stosuje model pożyczek z nadkonsumpcją, liczba tokenów, które użytkownik może pożyczyć, zależy od tego, czy wartość zabezpieczeń jest wystarczająca.

Dlatego, jeśli mechanizm cenowy oracle używany do obliczania wartości zabezpieczeń jest łatwy do manipulacji, można łatwo pożyczyć tokeny przekraczające oczekiwania.

Na przykład, w przypadku ataku na projekt fork Compound, Lodestar Finance, mechanizm pozyskiwania ceny tokena plvGLP przez oracle polegał na tym, że najpierw liczba tokenów plsGLP w kontrakcie plvGLP (totalAssets) była dzielona przez całkowite zaopatrzenie plvGLP (totalSupply), aby obliczyć kurs wymiany, a następnie kurs wymiany mnożono przez cenę tokena GLP, aby obliczyć cenę tokena plvGLP.

A plvGLP ma funkcję darowizny, która pozwala użytkownikom darować sGLP, aby mintować odpowiednie tokeny plsGLP dla kontraktu plvGLP.

W związku z tym atakujący mogą najpierw wykorzystać pożyczkę błyskawiczną do utworzenia dużej pozycji zabezpieczeń plvGLP na rynku Lodestar Finance, a następnie na GMX wykorzystać pożyczkę błyskawiczną do masowego mintowania sGLP, a następnie przez funkcję donate mintować tokeny plsGLP dla kontraktu plvGLP, aby zwiększyć wartość totalAssets. Wraz ze wzrostem całkowitych aktywów, kurs plvGLP wzrośnie, co spowoduje, że cena tokenów plvGLP nagle wzrośnie, co umożliwi pożyczanie innych tokenów przekraczających oczekiwania na rynku.

Można zobaczyć transakcję, w której Lodestar Finance zostało zhakowane: https://arbiscan.io/tx/0xc523c6307b025ebd9aef155ba792d1ba18d5d83f97c7a846f267d3d9a3004e8c

Należy również zauważyć, że Compound Finance lub jego projekty fork korzystają z off-chain oracle, takich jak ChainLink lub CoinBase, aby uzyskać ceny zabezpieczeń. W przypadku wystąpienia silnych wahań rynkowych może to prowadzić do różnic cen między cenami off-chain a on-chain, co zagraża bezpieczeństwu funduszy projektu.

Na przykład cena tokena LUNA dramatycznie spada z powodów rynkowych, a protokoły fork Compound Finance, Venus Protocol i Blizz Finance, korzystają z oracle Chainlink jako źródła cenowego do obliczania wartości zabezpieczeń, w tym minimum dla tokena LUNA (minAnswer), które zostało zakodowane na sztywno na poziomie 0,10 USD.

Gdy cena tokenu LUNA spadnie poniżej 0,1 USD (na przykład 0,001 USD), ktokolwiek może kupić dużą ilość LUNA po cenie rynkowej i wykorzystać je jako zabezpieczenie (o wartości 0,10 USD), aby pożyczyć inne aktywa z platformy.

Punkty audytu: podczas audytu należy zwrócić uwagę na mechanizm cenowy oracle stosowany przy obliczaniu wartości zabezpieczeń, aby upewnić się, że nie jest łatwy do manipulacji przez zewnętrzne źródła. Można zasugerować projektowi zastosowanie różnych źródeł cenowych do oceny, aby uniknąć ryzyka związanego z pojedynczym źródłem cenowym.

4.4 Ryzyko manipulacji kursami związane z tokenami z wieloma punktami wejścia

W kodzie Compound znajduje się funkcja o nazwie sweepToken, której celem jest umożliwienie użytkownikom, którzy nieumyślnie przelali tokeny do kontraktu, wyciągnięcie tych tokenów. Stara wersja kodu była następująca: ta funkcja miała ważne sprawdzenie bezpieczeństwa: przekazywany parametr token nie może być aktywem bazowym kontraktu.

Jednak, jeśli rynek cToken ma wiele punktów wejścia w aktywach bazowych (przez wiele adresów kontraktów można uzyskać dostęp do tego samego salda podstawowego, a interakcje zewnętrzne wpływają na salda wszystkich punktów wejścia, to jest to wczesny model podobny do agenta), atakujący mogą wywołać funkcję sweepToken, przekazując inny punkt wejścia, aby przenieść aktywa podstawowe z kontraktu.

Na przykład, TUSD ma dwa punkty wejścia w kontrakcie, a pomocniczy punkt wejścia 0x8dd5fbce przekazuje wszelkie wywołania (np. transfer lub balanceOf) do głównego kontraktu, co oznacza, że interakcja z którymkolwiek z tych kontraktów wpłynie na dane salda obu kontraktów (tj. dwa różne kontrakty dzielą te same dane salda).

W tym przypadku, zakładając, że ustawiony adres aktywów bazowych na rynku to adres głównego kontraktu TUSD, możemy przy wywoływaniu funkcji sweepToken użyć adresu pomocniczego punktu wejścia 0x8dd5fbce jako przekazywanego parametru token, co pozwoli na pomyślne sprawdzenie address(token) != underlying, a następnie kontrakt przeniesie wszystkie aktywa bazowe TUSD do adresu administratora.

Kurs wymiany TUSD / cTUSD będzie miał wpływ na ilość aktywów bazowych TUSD w kontrakcie cTUSD, a gdy TUSD zostanie całkowicie przeniesiony na adres administratora, kurs wymiany TUSD / cTUSD spadnie nagle. W tym momencie atakujący mogą wykonać likwidację innych użytkowników po bardzo niskim kursie wymiany lub spłacić mniejszą ilość tokenów niż oczekiwana ilość, aby zyskać.

Warto zauważyć, że w najnowszej wersji kodu Compound V2 dodano weryfikację uprawnień do funkcji sweepToken, aby zapewnić, że tylko rola administratora może wywołać ten kontrakt, a wszystkie rynki, które miały tokeny z wieloma punktami wejścia, zostały usunięte.

Punkty audytu: podczas audytu, w przypadku funkcji przenoszenia tokenów w kontrakcie, należy wziąć pod uwagę scenariusze, w których obecność tokenów z wieloma punktami wejścia może wpłynąć na projekt. Można zasugerować projektowi, aby nie stosował tokenów z wieloma punktami wejścia lub weryfikował, czy liczba tokenów aktywów podstawowych w kontrakcie nie zmienia się przed i po przeniesieniu tokenów, oraz dokładnie sprawdził uprawnienia powiązanych funkcji.

4.5 Problemy z kompatybilnością kodów umowy nowych i starych wersji

Jeśli w projekcie fork Compound Finance V2 kod jednego z kluczowych kontraktów to nowa wersja kodu Compound Finance V2, podczas gdy inny kontrakt, który z nim współdziała, korzysta z wersji starszej, mogą wystąpić problemy z kompatybilnością.

Na przykład w starym modelu cToken funkcja getBorrowRate do obliczania stóp procentowych zwracała dwie wartości typu uint, podczas gdy w nowej wersji funkcji InterestRateModel funkcja getBorrowRate zwraca tylko jedną wartość typu uint.

Jednak w projekcie fork Compound Finance V2, Percent Finance, zespół projektu korzystał ze starej wersji kodu cToken, podczas gdy kontrakt InterestRateModel używał nowej wersji, co spowodowało, że funkcja accrueInterest w cToken nie mogła pomyślnie wywołać funkcji getBorrowRate. Funkcja accrueInterest była używana zarówno w wypłatach, jak i pożyczkach, ostatecznie uniemożliwiając prawidłowe funkcjonowanie tych funkcji, a środki w kontrakcie zostały całkowicie zablokowane.

Punkty audytu: podczas audytu należy zwrócić uwagę na zmiany w interfejsach kontraktów, zmiennych stanu, sygnaturach funkcji i zdarzeniach w zaktualizowanym kodzie, aby upewnić się, że nie naruszają one normalnego działania istniejącego systemu, zapewniając spójność aktualizacji wersji kodów wszystkich kontraktów lub zapewniając kompatybilność z kodami starszych wersji po aktualizacji.

4.6 Problemy z twardym kodowaniem wynikające z wielołańcuchowego wdrażania

W kodzie Compound Finance V2 stała blocksPerYear oznacza szacunkową liczbę bloków wydobywanych w ciągu roku, której wartość w modelu stóp procentowych jest zakodowana na sztywno jako 2102400, ponieważ średni czas wydobycia bloków w Ethereum wynosi 15 sekund.

Jednak czasy bloków na różnych łańcuchach niekoniecznie są takie same, a także całkowita liczba bloków wydobywanych przez cały rok również nie musi być taka sama. Jeśli jakiś projekt fork Compound jest wdrażany na innych łańcuchach, ale nie zmienia twardo zakodowanych wartości zgodnie z sytuacją na różnych łańcuchach, może to spowodować, że końcowy wynik obliczeń stóp procentowych będzie wyższy niż oczekiwano. Dzieje się tak, ponieważ wartość blocksPerYear ma wpływ na wartości baseRatePerBlock i multiplierPerBlock, a baseRatePerBlock i multiplierPerBlock ostatecznie wpływają na stopy procentowe pożyczek.

Na przykład, czas wydobycia bloków na łańcuchu BSC wynosi 3 sekundy, więc szacunkowa liczba wydobywanych bloków w ciągu roku (blocksPerYear) powinna wynosić 10512000. Jeśli przed wdrożeniem nie zmieniono wartości blocksPerYear, to w rezultacie obliczone stopy procentowe pożyczek będą pięciokrotnie wyższe niż oczekiwano.

Punkty audytu: podczas audytu należy zwrócić uwagę na to, czy twardo zakodowane stałe lub zmienne w kontrakcie projektu mogą prowadzić do nieprzewidzianych rezultatów w różnych łańcuchach, zaleca się zespołowi projektu prawidłowe dostosowanie ich wartości do sytuacji na różnych łańcuchach.

Inne

Oprócz wymienionych powyżej głównych problemów, projekty fork Compound V2 zwykle zmieniają część logiki biznesowej zgodnie z projektowaniem zespołu projektu, na przykład dodając kod do interakcji z zewnętrznymi protokołami. Wymaga to oceny podczas audytu, aby sprawdzić, czy może to wpłynąć na rdzeń modelu pożyczek Compound Finance V2 oraz na sam projekt.

Na koniec

Mam nadzieję, że ten podręcznik audytu bezpieczeństwa Compound Finance V2 i jego projektów typu Fork pomoże wszystkim lepiej zrozumieć i ocenić bezpieczeństwo takich skomplikowanych systemów podczas audytów. Wraz z aktualizacjami technologii podręcznik ten również będzie aktualizowany i doskonalony.

Referencja:

[1] https://github.com/YAcademy-Residents/defi-fork-bugs

[2] https://medium.com/chainsecurity/trueusd-compound-vulnerability-bc5b696d29e2

[3] https://github.com/code-423n4/2023-05-venus-findings/issues/559

[4] https://learnblockchain.cn/article/2593

[5] https://github.com/compound-finance/compound-protocol

Autor | Jiu Jiu

Redaktor | Liz