Wprowadzenie

Wraz z szybkim rozwojem ekosystemu DeFi, Compound Finance V2 jako jeden z pionierów w tej dziedzinie przyciągnęło dużą liczbę użytkowników dzięki innowacyjnemu modelowi pożyczek. Jednak każdy złożony rozproszony system staje przed potencjalnymi zagrożeniami bezpieczeństwa, zwłaszcza gdy chodzi o przepływ funduszy o wartości milionów, a nawet setek milionów dolarów. Dlatego przeprowadzenie kompleksowego i szczegółowego audytu bezpieczeństwa Compound Finance V2 i jego projektów fork jest niezwykle ważne. Ten podręcznik ma na celu dostarczenie programistom, badaczom bezpieczeństwa i entuzjastom DeFi szczegółowego przewodnika audytowego, aby pomóc im bardziej efektywnie identyfikować i zapobiegać potencjalnym ryzykom.

1. Ogólny przegląd tła projektu

Compound Finance V2 to otwarta platforma pożyczkowa zbudowana na blockchainie Ethereum, która pozwala użytkownikom na wpłacanie różnych tokenów bazowych ERC-20 i zarabianie na nich odsetek, a także na pożyczanie tokenów z rynku w zamian za płacenie odsetek. Dzięki wprowadzeniu koncepcji "rynku stóp procentowych" osiąga zdecentralizowane zarządzanie pulą funduszy i automatyczny mechanizm dostosowywania stóp procentowych.

2. Analiza architektury projektu

Główne 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 z standardem ERC-20, reprezentujący prawa użytkownika w systemie.

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

  • PriceOracle: dostarcza informacje o cenach aktywów.

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

2.1 Comptroller

Umowa Comptroller jest centralnym układem nerwowym Compound Finance V2, odpowiada za koordynację działań różnych instancji cToken. Główne zadania to:

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

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

  • 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 przykład cToken (tj. CErc20 / CEther), który obsługuje wszystkie operacje związane z tym tokenem w projekcie. Każdy cToken, oprócz podstawowych funkcji transferu tokenów, dodaje również funkcje specyficzne dla Compound, takie jak pożyczki, gromadzenie odsetek i dystrybucja nagród. Dlatego możemy traktować cToken jako dowód wpłaty aktywów przez użytkownika w Compound oraz jako punkt wejścia do dokonywania operacji pożyczkowych.

Gdy użytkownik wpłaci aktywa bazowe do kontraktu, może wyemitować odpowiednie tokeny cToken, a stosunek wymiany cToken do aktywów bazowych oblicza się według następującego wzoru:

Uwaga: borrows oznacza kwotę pożyczki, cash oznacza saldo puli, reserves oznacza rezerwy. Stawka procentowa pożyczki zależy od wykorzystania, natomiast stawka procentowa depozytu zależy od stawki procentowej pożyczki.

Użytkownicy zazwyczaj wykonują operacje pożyczania tokenów w różnych rynkach, interakcjonując z różnymi umowami cToken:

2.3 InterestRateModel

Umowa InterestRateModel definiuje metodę obliczania stóp procentowych. Różne rynki mogą stosować różne typy modeli stóp procentowych, aby dostosować się do swoich preferencji ryzyka i potrzeb płynnościowych.

W modelu stawki procentowej używanym na rynku Compound V2 są dwie główne formy, jedna to model liniowy, a druga to model punktu przegięcia.

Wzór na stawkę procentową pożyczki w modelu liniowym jest następujący:

Wzór na obliczanie wskaźnika wykorzystania funduszy jest następujący:

Stawka procentowa depozytu zmienia się liniowo wraz ze stawką procentową pożyczki:

Wzrost wskaźnika wykorzystania oznacza, że pieniądze w puli stopniowo się zmniejszają, a osiągnięcie pewnego szczytu może uniemożliwić użytkownikom normalne wpłaty i pożyczki. Aby jak najbardziej uniknąć takiej sytuacji, Compound wprowadził drugi model stóp procentowych — model punktu przegięcia.

Wzór na obliczanie stawki procentowej pożyczki o kształcie punktu przegięcia jest następujący:

Gdy wskaźnik wykorzystania osiągnie pewien szczyt, stawki pożyczek i depozytów gwałtownie wzrosną, motywując użytkowników do wpłacania więcej i pożyczania mniej, by utrzymać wskaźnik wykorzystania w odpowiednim zakresie, a ten szczyt jest znany jako punkt przegięcia (zazwyczaj przy wykorzystaniu 80%).

2.4 PriceOracle

Umowa 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żytkowników.

2.5 Mechanizm zarządzania i model zachęt

Compound wprowadził unikalny mechanizm zarządzania, który pozwala użytkownikom posiadającym tokeny zarządzania (COMP) uczestniczyć w głosowaniach dotyczących ważnych decyzji, takich jak zmiana niektórych parametrów lub dodawanie nowych typów aktywów. Poprzez wydanie tokenów zarządzania (COMP), Compound motywuje użytkowników do aktywnego uczestnictwa w działaniach na platformie i oferuje nagrody dla uczestników. Szczegóły można znaleźć w oficjalnej dokumentacji i repozytorium kodu Compound. (https://docs.compound.finance/v2/; https://github.com/compound-finance/compound-protocol)

3. Proces interakcji

Następnie za pomocą prostego przykładu ilustrujemy ogólny proces interakcji użytkownika na Compound Finance V2:

3.1 Proces depozytu i wykupu

Jeśli użytkownik Alice chce wpłacić 1 WBTC do Compound, wywoła funkcję mint umowy cWBTC, aby dokonać wpłaty. Ta umowa dziedziczy po umowie cToken i najpierw wywołuje wewnętrznie funkcję accrueInterest, aby zaktualizować stawki procentowe pożyczek i depozytów, a następnie wywołuje mintFresh w celu przeprowadzenia konkretnej operacji emisji.

Funkcja mintFresh wywołuje zewnętrznie funkcję mintAllowed umowy Comptroller, aby sprawdzić, czy aktualny rynek pozwala na wpłaty, a następnie przenosi 1 WBTC użytkownika do kontraktu przy użyciu funkcji doTransferIn, a następnie na podstawie aktualnego kursu wymiany tworzy odpowiednią liczbę tokenów cToken (załóżmy, że aktualny kurs wymiany wynosi 0,1, więc Alice otrzyma 10 tokenów cWBTC).

Jeśli Alice zdecyduje się w przyszłości wykupić depozyt, może wywołać funkcję redeem, aby wymienić cWBTC na WBTC, przy czym kurs wymiany mógł ulec zmianie (załóżmy 0,15), co oznacza, że Alice będzie mogła wykupić 1,5 WBTC, z czego 0,5 WBTC to dochód z odsetek.

3.2 Proces pożyczki i spłaty

Alice najpierw musi wywołać funkcję enterMarkets umowy Comptroller, aby ustawić jej cWBTC jako możliwe do zabezpieczenia, a następnie może przystąpić do pożyczki.

Załóżmy, że Alice wybiera pożyczenie 70 USDC, a ponieważ współczynnik zabezpieczenia WBTC wynosi 0,75, Alice może pożyczyć maksymalnie równowartość 75% wartości aktywów WBTC, więc nie przekroczy to jej maksymalnego limitu pożyczkowego.

Uwaga: aby uniknąć ryzyka likwidacji, Alice powinna zachować pewną przestrzeń buforową, a nie całkowicie wykorzystać swój limit pożyczkowy.

Alice wywołuje funkcję borrow umowy cUSDC, która najpierw wywołuje wewnętrznie funkcję borrowInternal, aby zaktualizować stawki procentowe pożyczek i depozytów, a następnie wywołuje borrowFresh w celu przeprowadzenia konkretnej operacji pożyczki.

Po przeprowadzeniu kontroli wartości pozycji użytkownika za pomocą funkcji borrowAllowed umowy Comptroller, najpierw rejestruje się dane pożyczki, a następnie przemieszcza tokeny do użytkownika za pomocą funkcji doTransferOut.

Jeśli Alice potrzebuje spłacić pożyczkę, może wywołać funkcję repayBorrow umowy cUSDC, aby samodzielnie spłacić pożyczkę, lub pozwolić innym na wywołanie funkcji repayBorrowBehalf, aby spłacić pożyczkę w jej imieniu.

3.3 Proces likwidacji

Jeśli cena WBTC spadnie znacznie, tak że wartość zabezpieczenia Alice spadnie poniżej 75% jej kwoty pożyczki, to pozycja pożyczkowa Alice będzie w stanie likwidacji.

Zewnętrzny likwidator (np. Bob) może wywołać funkcję likwidacyjną liquidateBorrow w umowie cUSDC, aby pomóc Alice spłacić część długu. Najpierw aktualizuje stawki procentowe zarówno cUSDC, jak i używanych zabezpieczeń cToken za pomocą funkcji liquidateBorrowInternal, a następnie wywołuje liquidateBorrowFresh w celu przeprowadzenia konkretnej operacji likwidacji.

Po przeprowadzeniu kontroli, czy likwidacja jest dozwolona za pomocą funkcji liquidateBorrowAllowed umowy Comptroller, najpierw wywołuje się funkcję repayBorrowFresh, aby przesłać USDC do umowy w celu spłaty, a następnie aktualizuje dane pożyczkowe osoby likwidowanej. Następnie wywołuje się funkcję liquidateCalculateSeizeTokens umowy Comptroller, aby obliczyć, ile zabezpieczeń Bob może otrzymać od Alice na podstawie wartości likwidacji, a na koniec za pomocą odpowiedniego rynku zabezpieczeń cToken (np. cWBTC) wywołuje się funkcję seize, aby przenieść cTokeny dla Boba i Alice.

Otwórz ten link, aby zobaczyć wersję w wysokiej rozdzielczości powyższej grafiki; kliknij "czytaj oryginał", aby bezpośrednio przejść do: https://www.figma.com/board/POkJlvKlWWc7jSccYMddet/Compound-V2?node-id=0-1&node-type=canvas.

Bob spłaca część pożyczki Alice (na przykład 20 USDC) i w zamian otrzymuje odpowiednią wartość zabezpieczenia (np. WBTC), a także dodatkowo uzyskuje premię likwidacyjną (załóżmy 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 Luka zaokrąglania spowodowana pustym rynkiem

W przypadku, gdy cToken jest rynkiem pustym (tj. nikt nie bierze udziału w pożyczkach na rynku), ponieważ wartość exchangeRate w funkcji exchangeRateStoredInternal zależy od liczby aktywów bazowych przypisanych do kontraktu, można manipulować ceną cToken, wpłacając dużą ilość aktywów bazowych do umowy cToken.

Dlatego można pożyczyć dużą ilość innych tokenów za pomocą niewielkiej ilości cTokenów, a następnie wywołać funkcję redeemUnderlying cToken, aby pobrać aktywa bazowe. Przy obliczaniu wykupu liczba cTokenów, które należy odliczyć, może być znacznie mniejsza niż oczekiwano z powodu zaokrąglenia w dół (prawie tylko połowa).

Załóżmy, że liczba posiadanych cTokenów wynosi 2 (co jednocześnie jest całkowitym totalSupply), a exchangeRate po manipulacji wzrasta do 25,015,031,908,500,000,000,000,000,000, a liczba aktywów bazowych do wykupu wynosi 50,030,063,815. W związku z tym oczekiwana liczba cTokenów do odliczenia powinna wynosić:

A rzeczywista liczba obliczonych cTokenów wynosi:

W związku z tym, na końcu wystarczy zlikwidować bardzo niewielką liczbę cTokenów, aby uzyskać dużą ilość tokenów aktywów pożyczonych z innych rynków.

Można odwołać się do transakcji, która doprowadziła do zhakowania projektu fork Compound Hundred Finance 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 podatny na manipulacje oraz czy sposób zaokrąglania jest odpowiedni; warto również zasugerować zespołowi projektu natychmiastowe stworzenie niewielkiej ilości cTokenów po utworzeniu nowego rynku, aby zapobiec manipulacjom w przypadku pustego rynku.

4.2 Luka reentrancy spowodowana tokenami ERC677 / ERC777

ERC677 / ERC777 to rozszerzenie umowy ERC20, które jest zgodne z protokołem ERC20. Te tokeny pozwalają na wywołanie funkcji zwrotu, jeśli adres odbiorcy jest kontraktem podczas procesu transferu (jak transferAndCall lub tokensReceived).

W starej wersji kodu Compound Finance V2, gdy użytkownik pożycza w rynku cToken, najpierw przenosi pożyczone tokeny, a następnie rejestruje dane pożyczki.

Jeśli pożyczone tokeny są tokenami ERC677 / ERC777 z funkcją zwrotu, można skonstruować złośliwy kontrakt odbiorcy, aby ponownie wejść do funkcji borrow za pomocą funkcji zwrotu; ponieważ dane pożyczki użytkownika nie zostały jeszcze zarejestrowane podczas ostatniej pożyczki, można pomyślnie przejść kontrolę zdrowia konta, aby ponownie pożyczyć tokeny.

Można odwołać się do transakcji, która doprowadziła do zhakowania projektu fork Compound Hundred Finance 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ą tak, aby najpierw rejestrowano dane pożyczki, a następnie przenoszono pożyczone tokeny. W audycie należy zwrócić uwagę na to, czy kod związany z funkcją pożyczek jest zgodny z normą CEI (Checks-Effects-Interactions) oraz rozważyć wpływ tokenów z funkcją zwrotu.

4.3 Ryzyko manipulacji cenowej spowodowane nieodpowiednim mechanizmem oracle

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

Z tego powodu, jeśli mechanizm ustalania cen oracle używany do obliczania wartości zabezpieczeń jest podatny na manipulacje, łatwo jest pożyczyć więcej tokenów niż oczekiwano.

Na przykład, w przypadku incydentu, w którym projekt fork Compound Lodestar Finance został zhakowany, sposób, w jaki oracle uzyskiwał cenę tokena zabezpieczenia plvGLP, polegał na podzieleniu liczby tokenów plsGLP w umowie plvGLP (totalAssets) przez całkowite dostarczone plvGLP (totalSupply), a następnie pomnożeniu tej wartości przez cenę tokenów GLP, aby obliczyć cenę tokena plvGLP.

Token plvGLP ma funkcję darowizny, która pozwala użytkownikom przekazywać sGLP do kontraktu tokena plvGLP, aby wyemitować odpowiednią liczbę tokenów plsGLP.

Dlatego atakujący może najpierw wykorzystać pożyczkę błyskawiczną na rynku Lodestar Finance, aby utworzyć dużą ilość pozycji zabezpieczeń plvGLP, a następnie na GMX wykorzystać pożyczkę błyskawiczną, aby wyemitować dużą ilość sGLP, a następnie za pomocą funkcji donate wyemitować tokeny plsGLP dla kontraktu plvGLP, aby zwiększyć wartość totalAssets. W miarę wzrostu całkowitych aktywów kurs wymiany plvGLP wzrośnie, co spowoduje nagły wzrost ceny tokenów plvGLP, co pozwoli na pożyczanie innych tokenów w większej ilości niż oczekiwano na rynku.

Można odwołać się do transakcji, w której Lodestar Finance został zhakowany: https://arbiscan.io/tx/0xc523c6307b025ebd9aef155ba792d1ba18d5d83f97c7a846f267d3d9a3004e8c

Należy również zwrócić uwagę, że Compound Finance lub jego projekty fork mogą korzystać z off-chain oracle, takich jak ChainLink lub CoinBase, aby uzyskać ceny zabezpieczeń. W przypadku gwałtownych wahań rynkowych może to prowadzić do rozbieżności między cenami off-chain a on-chain, zagrażając bezpieczeństwu funduszy projektu.

Na przykład cena tokena LUNA może gwałtownie spaść z powodów rynkowych, podczas gdy fork protokołu Compound, Venus Protocol i Blizz Finance, korzystają z oracle Chainlink jako źródła cenowego do obliczania wartości zabezpieczeń, gdzie dla tokena LUNA zdefiniowano zakodowaną minimalną cenę (minAnswer) na poziomie 0,10 USD.

Gdy cena tokena LUNA spadnie poniżej 0,1 USD (np. 0,001 USD), każdy może kupić dużą ilość LUNA po cenie rynkowej i wykorzystać ją 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 to, czy mechanizm ustalania cen używany do obliczania wartości zabezpieczeń jest podatny na manipulacje ze strony zewnętrznych podmiotów; można zasugerować, aby projekt korzystał z różnych źródeł cenowych do przeprowadzenia oceny zbiorczej, aby uniknąć ryzyka wynikającego z pojedynczego źródła cenowego.

4.4 Ryzyko manipulacji kursami spowodowane tokenami z wieloma punktami dostępu

W kodzie Compound istnieje funkcja o nazwie sweepToken, której celem jest umożliwienie użytkownikom, którzy przypadkowo przenieśli tokeny do kontraktu, ich wyciągnięcie. Stara wersja kodu wygląda tak: ta funkcja ma ważną kontrolę bezpieczeństwa: przekazany parametr token nie może być aktywem bazowym kontraktu.

Jednakże, jeśli w rynku cToken istnieje wiele kontraktów punktów dostępu dla aktywów bazowych (gdzie przez wiele adresów kontraktów można uzyskać dostęp do tego samego salda bazowego, a interakcje zewnętrzne wpływają na saldo wszystkich punktów dostępu, co jest wczesnym przykładem podobnym do proxy), atakujący może wywołać funkcję sweepToken, przekazując inny kontrakt punktu dostępu niż underlying, aby przenieść aktywa bazowe z kontraktu.

Na przykład w przypadku TUSD, który ma dwa punkty dostępu, pomocniczy punkt dostępu 0x8dd5fbce przekazuje wszystkie 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 w obu kontraktach (tj. dwa różne kontrakty dzielą te same dane salda).

Jeśli w tym momencie adres tokenu bazowego ustawionego na rynku jest głównym adresem kontraktu TUSD, możemy podczas wywoływania funkcji sweepToken przekazać pomocniczy adres kontraktu punktu dostępu 0x8dd5fbce jako przekazany parametr token, co pozwoli na pomyślne sprawdzenie address(token) != underlying, a następnie kontrakt przeniesie wszystkie aktywa bazowe TUSD na adres administratora.

Kurs wymiany TUSD / cTUSD będzie zależał od liczby aktywów bazowych TUSD w umowie cTUSD; kiedy TUSD zostanie całkowicie przeniesione na adres administratora, kurs wymiany TUSD / cTUSD nagle drastycznie spadnie. W tym przypadku atakujący może wykonać likwidację innych użytkowników lub pożyczając, zwrócić mniej tokenów niż oczekiwano, aby zyskać.

Warto zauważyć, że w najnowszej wersji kodu Compound V2 dodano weryfikację uprawnień do funkcji sweepToken, aby zagwarantować, że tylko administrator może wywołać tę umowę, a także usunięto wszystkie rynki, które miały wiele punktów dostępu.

Punkty audytu: podczas audytu funkcji przenoszenia tokenów w umowie należy uwzględnić wpływ scenariuszy z wieloma punktami dostępu na projekt; można zalecić, aby projekt nie stosował tokenów z wieloma punktami dostępu lub weryfikował, czy liczba aktywów bazowych w kontrakcie zmienia się przed i po przeniesieniu tokenów oraz przeprowadzał odpowiednie kontrole uprawnień dotyczące powiązanych funkcji.

4.5 Problemy z kompatybilnością między starymi a nowymi wersjami kodu umowy

Jeśli w projekcie fork Compound Finance V2 kod kluczowej umowy opiera się na nowej wersji kodu Compound Finance V2, a inna umowa, która z nią współdziała, korzysta ze starej wersji kodu, mogą wystąpić problemy z kompatybilnością.

Na przykład w starej wersji umowy cToken, funkcja getBorrowRate używana do uzyskiwania stawki procentowej pożyczki zwracała dwie wartości typu uint, podczas gdy w nowej wersji funkcji InterestRateModel, funkcja getBorrowRate zwraca tylko jedną wartość typu uint.

Jednakże w projekcie fork Compound Finance V2, Percent Finance, zespół projektowy używa starej wersji kodu umowy cToken, podczas gdy umowa InterestRateModel jest oparta na nowej wersji, co powoduje, że wywołanie funkcji accrueInterest w cTokenach, które wywołuje funkcję getBorrowRate, kończy się niepowodzeniem. Funkcja accrueInterest jest używana zarówno przy wypłatach, jak i pożyczkach, co ostatecznie uniemożliwia prawidłowe przeprowadzanie funkcji wypłat i pożyczek, a fundusze w kontrakcie zostają całkowicie zablokowane.

Punkty audytu: podczas audytu należy zwrócić uwagę na to, czy zmiany w interfejsach kontraktów, zmiennej stanu, podpisach funkcji i zdarzeniach w zaktualizowanym kodzie nie zakłócają normalnego działania istniejącego systemu, zapewniając spójność wersji kodu wszystkich kontraktów lub zapewniając, że zaktualizowany kod będzie kompatybilny z wersjami starszymi.

4.6 Problemy z zakodowaniem wynikającym z wdrożenia wielołańcuchowego

W kodzie Compound Finance V2 stała blocksPerYear reprezentuje szacunkową roczną liczbę bloków, której wartość jest zakodowana w umowie modelu stóp procentowych jako 2102400, ponieważ średni czas wydobywania bloków w Ethereum wynosi 15 sekund.

Jednak różne łańcuchy mogą mieć różne czasy bloków, i podobnie, roczna liczba bloków może się różnić. Jeśli jakiś projekt fork Compound jest wdrażany na innych łańcuchach, ale nie zmienia zakodowanych wartości w zależności od specyfiki łańcucha, może to prowadzić do nieoczekiwanych wyników obliczeń stóp procentowych. Dzieje się tak, ponieważ wartość blocksPerYear wpływa na wartości baseRatePerBlock i multiplierPerBlock, a te wartości wpływają na stawkę procentową pożyczek.

Na przykład, jeśli czas wydobywania bloków na łańcuchu BSC wynosi 3 sekundy, to roczna szacunkowa liczba bloków (blocksPerYear) powinna wynosić 10512000. Jeśli przed wdrożeniem nie zmieniono wartości blocksPerYear, spowoduje to, że ostatecznie obliczona stawka procentowa pożyczek będzie pięć razy wyższa niż oczekiwano.

Punkty audytu: podczas audytu należy zwrócić uwagę na to, czy stałe lub zmienne zakodowane w umowie projektu w kontekście cech różnych łańcuchów mogą prowadzić do nieoczekiwanych wyników; sugeruje się, aby projekt dostosował ich wartości odpowiednio do specyfiki różnych łańcuchów.

Inne

Oprócz wymienionych powyżej głównych problemów, projekty fork Compound V2 zazwyczaj modyfikują pewne logiki biznesowe zgodnie z projektami zespołów, na przykład dodając kod interakcji z zewnętrznymi protokołami. Należy to ocenić podczas audytu na podstawie konkretnej logiki biznesowej i wymagań projektowych, aby sprawdzić, czy wpłynie to na rdzeń modelu pożyczkowego Compound Finance V2 oraz projekt.

Na koniec

Mam nadzieję, że ten podręcznik audytowy dotyczący bezpieczeństwa Compound Finance V2 i jego projektów fork pomoże wszystkim lepiej zrozumieć i ocenić bezpieczeństwo tego rodzaju skomplikowanych systemów podczas audytów. Wraz z postępem technologicznym ten podręcznik będzie również aktualizowany i ulepszany.

Odwołanie:

[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 | Dziewiąty

Edycja | Liz