roundedEinleitung

Mit der raschen Entwicklung des DeFi-Ökosystems hat Compound Finance V2 als einer der Pioniere dieses Bereichs mit seinem innovativen Kreditmodell eine große Anzahl von Benutzern angezogen. Jedes komplexe verteilte Anwendung steht jedoch vor potenziellen Sicherheitsbedrohungen, insbesondere wenn es um Geldströme in Millionenhöhe oder sogar Milliarden geht. Daher ist eine umfassende und detaillierte Sicherheitsprüfung von Compound Finance V2 und seinen Fork-Projekten von besonderer Bedeutung. Dieses Handbuch soll Entwicklern, Sicherheitsforschern und DeFi-Enthusiasten eine detaillierte Sicherheitsprüfungsrichtlinie bieten, um potenzielle Risiken effektiver zu identifizieren und zu verhindern.

1. Überblick über den Projektbackground

Compound Finance V2 ist eine offene Kreditplattform, die auf der Ethereum-Blockchain aufgebaut ist und es Benutzern ermöglicht, verschiedene ERC-20-Basis-Token einzuzahlen und Zinsen zu verdienen, während sie gleichzeitig Tokens aus dem Markt leihen können, indem sie Zinsen zahlen. Durch die Einführung des Konzepts des "Zinssatzmarktes" ermöglicht es eine dezentrale Verwaltung des Liquiditätspools und einen automatisierten Mechanismus zur Anpassung der Zinssätze.

2. Projektarchitekturanalyse

Die Kernarchitekturkomponenten von Compound Finance V2 umfassen:

  • Comptroller: Steuert die gesamte Systemlogik, wie z. B. die Berechnung von Zinssätzen, die Pflege des Kontostatus usw.

  • cToken: Implementiert benutzerdefinierte Tokens, die dem ERC-20-Standard entsprechen und die Ansprüche der Benutzer im System repräsentieren.

  • InterestRateModel: Modell zur Berechnung der Einzahlungs- und Kredit-Zinssätze.

  • PriceOracle: Bereitstellung von Preisprognosen für Vermögenswerte.

  • Governance: Verantwortlich für Funktionen im Zusammenhang mit der Gemeinschaftsverwaltung.

2.1 Comptroller

Der Comptroller-Vertrag ist das zentrale Nervensystem von Compound Finance V2 und koordiniert das Verhalten der einzelnen cToken-Instanzen. Zu den Hauptaufgaben gehören:

  • Verwalten Sie die Marktliste, um festzustellen, welche Märkte aktiv sind.

  • Durchführung verschiedener Überprüfungen für cross-market-Operationen, wie z. B. Überprüfungen der Positionen der Benutzer.

  • Globale Parameter wie Kreditlimits, Sicherheitenfaktoren, Liquidationsschwellen usw. festlegen und aktualisieren.

2.2 cToken

Jeder unterstützte ERC-20-Token hat eine entsprechende cToken-Instanz (d. h. CErc20 / CEther-Vertrag), die alle Interaktionen mit dem Projekt für diesen Token verarbeitet. Jedes cToken hat zusätzlich zu den grundlegenden Token-Überweisungsfunktionen auch einige spezifische Funktionen von Compound, wie z. B. Kreditvergabe, Zinsakkumulation und Belohnungsverteilung. Daher können wir das cToken als Quittung für den Benutzer betrachten, der Vermögenswerte in Compound hinterlegt, und als Eingang für die Kreditoperationen.

Wenn Benutzer die Basis-Token in den Vertrag einzahlen, können sie die entsprechenden cToken minten. Das Verhältnis zwischen cToken und dem zugrunde liegenden Asset wird wie folgt berechnet:

Hinweis: borrows bedeutet den Kreditbetrag, cash bedeutet den Saldo des Liquiditätspools, reserves bedeutet die Rücklagen. Der Zinssatz für Kredite wird durch die Auslastung bestimmt, der Zinssatz für Einlagen wird durch den Zinssatz für Kredite bestimmt.

Benutzer führen normalerweise Kreditoperationen in verschiedenen Märkten durch, indem sie mit verschiedenen cToken-Verträgen interagieren:

2.3 InterestRateModel

Das InterestRateModel-Vertrag definiert die Methode zur Berechnung der Zinssätze. Verschiedene Märkte können unterschiedliche Arten von Zinssatzmodellen verwenden, um ihren jeweiligen Risikopräferenzen und Liquiditätsbedürfnissen gerecht zu werden.

Die Zinssatzmodelle, die in den Märkten von Compound V2 verwendet werden, sind hauptsächlich zwei: eines ist das lineare Modell, das andere ist das Wendepunktmodell.

Die Berechnungsformel für den Zinssatz eines linearen Modells lautet wie folgt:

Die Berechnungsformel für die Kapitalnutzung lautet wie folgt:

Der Zinssatz für Einlagen ändert sich linear mit dem Zinssatz für Kredite:

Steigende Nutzung bedeutet, dass das Geld im Liquiditätspool allmählich abnimmt. Wenn ein bestimmter Höchstwert erreicht wird, kann dies dazu führen, dass Benutzer nicht mehr normal einzahlen oder leihen können. Um dies zu vermeiden, hat Compound ein zweites Zinssatzmodell - das Wendepunkt-Modell - eingeführt.

Die Berechnungsformel für den Zinssatz des Wendepunktmodells lautet:

Wenn die Auslastung einen bestimmten Höchstwert erreicht, wird der Zinssatz für Kredite und Einlagen sofort stark erhöht, um Benutzer zu ermutigen, mehr einzuzahlen und weniger zu leihen, um die Auslastung in einem angemessenen Bereich zu halten. Dieser Höchstwert wird auch als Wendepunkt bezeichnet (normalerweise wenn die Auslastung 80% erreicht).

2.4 PriceOracle

Der PriceOracle-Vertrag ist verantwortlich für die Erfassung von externen Marktpreisinformationen und deren Umwandlung in Zahlen, die im System verwendet werden, was für die genaue Berechnung des Wertes der Positionen der Benutzer von entscheidender Bedeutung ist.

2.5 Governance-Mechanismus und Anreizmodell

Compound hat einen einzigartigen Governance-Mechanismus eingeführt, der es Benutzern, die Governance-Token (COMP) halten, ermöglicht, an wichtigen Entscheidungen wie der Änderung bestimmter Parameter oder der Hinzufügung neuer Vermögensarten teilzunehmen. Durch die Ausgabe von Governance-Token (COMP) ermutigt Compound Benutzer, aktiv an den Aktivitäten der Plattform teilzunehmen und bietet Anreize für Beiträge. Weitere Informationen finden Sie in den offiziellen Dokumenten und dem Code-Repository von Compound. (https://docs.compound.finance/v2/; https://github.com/compound-finance/compound-protocol)

3. Interaktionsprozess

Als nächstes veranschaulichen wir den ungefähren Prozess, wie Benutzer mit Compound Finance V2 interagieren:

3.1 Einzahlungs- und Rückkaufsprozess

Wenn Benutzer Alice 1 WBTC in Compound einzahlen möchte, wird sie die Funktion mint des cWBTC-Vertrags aufrufen, um die Einzahlung vorzunehmen. Der Vertrag erbt vom cToken-Vertrag und ruft zunächst die Funktion mintInternal auf, um die Zinsraten für Kredit- und Einlagen zu aktualisieren, und ruft dann mintFresh für den spezifischen Mint-Vorgang auf.

Die Funktion mintFresh ruft die Funktion mintAllowed des Comptroller-Vertrags auf, um zu überprüfen, ob der aktuelle Markt Einzahlungen zulässt, und überträgt dann 1 WBTC des Benutzers durch die Funktion doTransferIn in den Vertrag, bevor er basierend auf dem aktuellen Wechselkurs die entsprechende Menge an cToken-Token für den Benutzer mintet (angenommen, der aktuelle Wechselkurs beträgt 0,1, dann erhält Alice 10 cWBTC-Token).

Wenn Alice in Zukunft entscheidet, ihre Einlagen zurückzuziehen, kann sie die Funktion redeem aufrufen, um cWBTC gegen WBTC einzutauschen. Der Wechselkurs könnte sich geändert haben (angenommen 0,15), was bedeutet, dass Alice 1,5 WBTC zurückziehen kann, wobei 0,5 WBTC Zinsen sind.

3.2 Kredit- und Rückzahlungsprozess

Alice muss zunächst die Funktion enterMarkets des Comptroller-Vertrags aufrufen, um ihren cWBTC in einen Status zu setzen, in dem er als Sicherheit verwendet werden kann, bevor sie einen Kredit aufnehmen kann.

Angenommen, Alice entscheidet sich, 70 USDC zu leihen. Da der Sicherheitenfaktor von WBTC 0,75 beträgt, kann Alice maximal einen Wert von 75% des WBTC-Wertes leihen, sodass dies nicht über ihrem maximalen Kreditlimit liegt.

Hinweis: Um das Risiko einer Liquidation zu vermeiden, sollte Alice einen gewissen Pufferraum einhalten, anstatt ihr Kreditlimit vollständig auszuschöpfen.

Alice ruft die Funktion borrow des cUSDC-Vertrags auf, die zunächst die Funktion borrowInternal aufruft, um die Zinsraten für Kredit- und Einlagen zu aktualisieren, und dann die Funktion borrowFresh für die spezifische Kreditoperation aufruft.

Nach der Überprüfung des Wertes der Position des Benutzers durch die borrowAllowed-Funktion des Comptroller-Vertrags werden zunächst die Kreditdaten verbucht und anschließend durch die doTransferOut-Funktion die Tokens an den Benutzer ausgegeben.

Wenn Alice eine Rückzahlung tätigen muss, kann sie die Funktion repayBorrow des cUSDC-Vertrags aufrufen, um selbst zurückzuzahlen, oder andere Personen können die Funktion repayBorrowBehalf aufrufen, um für sie zurückzuzahlen.

3.3 Liquidationsprozess

Wenn der Preis von WBTC stark fällt, sodass der Wert von Alices Sicherheiten unter 75% ihres Kreditlimits liegt, wird Alices Kreditposition in einen Liquidierungszustand versetzt.

Externe Liquidatoren (z. B. Bob) können die Liquidationsfunktion liquidateBorrow im cUSDC-Vertrag aufrufen, um Alice zu helfen, einen Teil ihrer Schulden zurückzuzahlen. Zunächst wird die cUSDC- und die Zinsrate des verwendeten Sicherheiten cToken durch die Funktion liquidateBorrowInternal aktualisiert, danach wird liquidateBorrowFresh für die spezifische Liquidationsoperation aufgerufen.

Nach der Überprüfung, ob die Liquidation durch die Funktion liquidateBorrowAllowed des Comptroller-Vertrags erlaubt ist, wird zuerst die Funktion repayBorrowFresh aufgerufen, um USDC in den Vertrag einzuzahlen und die Kreditdaten des Liquidierten zu aktualisieren. Anschließend wird die Funktion liquidateCalculateSeizeTokens des Comptroller-Vertrags aufgerufen, um die Anzahl der Sicherheiten zu berechnen, die Bob im entsprechenden Wert von Alice erhalten kann, und schließlich wird die seize-Funktion des cToken-Vertrags für den spezifischen Sicherheitenmarkt (z. B. cWBTC) aufgerufen, um cToken für Bob und Alice zu übertragen.

Öffnen Sie diesen Link, um die HD-Version des obigen Bildes zu sehen. Klicken Sie auf „Original lesen“, um direkt weitergeleitet zu werden: https://www.figma.com/board/POkJlvKlWWc7jSccYMddet/Compound-V2?node-id=0-1&node-type=canvas.

Bob zahlt einen Teil von Alices Darlehen zurück (z. B. 20 USDC) und erhält dafür Sicherheiten im entsprechenden Wert von Alice (z. B. WBTC). Gleichzeitig erhält Bob auch eine zusätzliche Liquidationsbelohnung (angenommen 5%). Das Endergebnis ist, dass Bob WBTC im Wert von 21 USDC erhält (20 USDC Darlehen + 1 USDC Liquidationsbelohnung).

4. Sicherheitsanfälligkeiten Checkliste

4.1 Rundungsanfälligkeit aufgrund leerer Märkte

Wenn cToken ein leerer Markt ist (d. h. keine Benutzer führen Kreditoperationen im Markt durch), kann der Wert von exchangeRate in der Funktion exchangeRateStoredInternal, die von der Anzahl der Basis-Asset-Tokens im Vertrag abhängt, manipuliert werden, indem eine große Menge an Basis-Asset-Tokens in den cToken-Vertrag eingezahlt wird.

Daher können mit einer kleinen Menge cToken viele andere Tokens geliehen werden, und anschließend kann die Funktion redeemUnderlying des cToken aufgerufen werden, um die Basis-Asset-Token abzuziehen. Bei der Berechnung des Rückkaufs kann die abzuziehende cToken-Anzahl aufgrund der Abrundung der Division weit unter der erwarteten Anzahl liegen (fast nur die Hälfte).

Angenommen, die Anzahl der cToken, die zu diesem Zeitpunkt gehalten wird, beträgt 2 (was auch die gesamte totalSupply ist), und der exchangeRate wurde nach Manipulation auf 25.015.031.908.500.000.000.000.000 angehoben, die Anzahl der zurückzuziehenden Basis-Asset-Token beträgt 50.030.063.815. Daher sollte die erwartete abzuziehende cToken-Anzahl sein:

Die tatsächlich berechnete cToken-Anzahl beträgt jedoch:

Daher muss am Ende nur eine sehr geringe Anzahl an cToken liquidiert werden, um eine große Menge an Vermögenswerten aus anderen Märkten zu erhalten.

Sie können die Transaktion einsehen, die aufgrund dieser Sicherheitsanfälligkeit zur Hack des Compound-Fork-Projekts Hundred Finance führte: https://optimistic.etherscan.io/tx/0x6e9ebcdebbabda04fa9f2e3bc21ea8b2e4fb4bf4f4670cb8483e2f0b2604f451

Audit-Punkte: Während des Audits sollte beachtet werden, ob die Methode zur Berechnung des Wechselkurses leicht manipuliert werden kann und ob die Rundungsmethode angemessen ist. Es kann auch empfohlen werden, dass das Projektteam nach der Erstellung neuer Märkte sofort eine geringe Menge an cToken mintet, um zu verhindern, dass der Markt leergeräumt und manipuliert wird.

4.2 Rückeinführungsanfälligkeit durch ERC677 / ERC777-Token

ERC677 / ERC777 ist eine Erweiterung des ERC20-Vertragsstandards, die mit ERC20-Token kompatibel ist. Diese Tokens ermöglichen es, dass während des Übertragungsprozesses, wenn die Empfangsadresse ein Vertrag ist, die Rückruffunktion der Empfangsadresse (z. B. transferAndCall oder tokensReceived) ausgelöst wird.

In der alten Version des Compound Finance V2-Codes wird beim Leihen von Tokens im cToken-Markt zunächst der geliehene Token aus dem Vertrag übertragen, gefolgt von der Buchung der Kreditdaten.

Wenn die geliehenen Tokens ERC677 / ERC777-Tokens mit Rückruffunktion sind, kann ein bösartiger Vertrag konstruiert werden, um durch die Rückruffunktion erneut in die borrow-Funktion einzutreten. Da bei der letzten Kreditaufnahme die Kreditdaten des Benutzers noch nicht verbucht wurden, kann der Benutzer erfolgreich erneut Tokens leihen, indem er die Gesundheitskennzahl des Kontos überprüft.

Sie können die Transaktion einsehen, die aufgrund dieser Sicherheitsanfälligkeit zur Hack des Compound-Fork-Projekts Hundred Finance führte: https://blockscout.com/xdai/mainnet/tx/0x534b84f657883ddc1b66a314e8b392feb35024afdec61dfe8e7c510cfac1a098

Audit-Punkte: In der neuesten Version des Compound V2-Codes wurde die Kreditlogik behoben, indem zunächst die Kreditdaten aufgezeichnet und dann die geliehenen Tokens übertragen werden. Im Audit sollte darauf geachtet werden, ob die relevanten Codes für die Kredit- und Darlehensfunktion den CEI (Checks-Effects-Interactions)-Standards entsprechen und ob die Auswirkungen von Tokens mit Rückruffunktionen berücksichtigt werden.

4.3 Risiken der Preismanipulation durch unangemessene Orakelmechanismen

Da Compound Finance ein überbesichertes Kreditmodell verwendet, hängt die Anzahl der Tokens, die ein Benutzer leihen kann, davon ab, ob der Wert der Sicherheiten ausreichend ist.

Daher, wenn der Preismechanismus des Orakels, das zur Berechnung des Wertes der Sicherheiten verwendet wird, leicht manipuliert werden kann, ist es sehr einfach, Tokens über die erwartete Menge zu leihen.

Zum Beispiel wurde im Vorfall, bei dem das Compound-Fork-Projekt Lodestar Finance gehackt wurde, der Preis der Sicherheiten plvGLP-Token durch die Methode bestimmt, dass die Anzahl der plsGLP-Token im plvGLP-Vertrag (totalAssets) durch die Gesamtversorgung von plvGLP (totalSupply) geteilt wurde, um den Wechselkurs zu berechnen, und dieser Wechselkurs dann mit dem Preis des GLP-Tokens multipliziert wurde, um den Preis des plvGLP-Tokens zu berechnen.

Der plvGLP hat eine Spendenfunktion, die es Benutzern ermöglicht, sGLP zu spenden, um die entsprechenden plsGLP-Token für den plvGLP-Vertrag zu minten.

Daher kann der Angreifer zunächst Flash-Loans nutzen, um eine große Anzahl von plvGLP-Sicherheiten im Lodestar Finance-Markt zu erstellen, anschließend auf GMX Flash-Loans nutzen, um große Mengen an sGLP zu minten, und dann die Funktion donate aufrufen, um plsGLP-Token für den plvGLP-Vertrag zu minten und den Wert von totalAssets zu erhöhen. Mit zunehmendem Gesamtvermögen wird der Wechselkurs von plvGLP größer, was zu einem plötzlichen Anstieg des Preises des plvGLP-Tokens führt, sodass auf dem Markt mehr als erwartete andere Tokens geliehen werden können.

Sie können die von Lodestar Finance gehackte Transaktion einsehen: https://arbiscan.io/tx/0xc523c6307b025ebd9aef155ba792d1ba18d5d83f97c7a846f267d3d9a3004e8c

Darüber hinaus ist es wichtig zu beachten, dass Compound Finance oder seine Fork-Projekte auch Off-Chain-Orakel wie ChainLink oder CoinBase verwenden, um die Preise der Sicherheiten zu ermitteln. Bei plötzlichen Marktschwankungen kann dies zu Preisabweichungen zwischen Off-Chain- und On-Chain führen und die Sicherheit der Projektmittel gefährden.

Zum Beispiel ist der Preis des LUNA-Tokens aufgrund von Marktentwicklungen stark gefallen, während die Fork-Protokolle von Compound Finance, Venus Protocol und Blizz Finance, Chainlink-Orakel als Preisquelle verwenden, um den Wert der Sicherheiten zu berechnen, wobei der Mindestpreis (minAnswer) für das LUNA-Token hart codiert wurde und einen Wert von 0,10 USD hat.

Wenn der Preis des LUNA-Tokens unter 0,1 USD fällt (z. B. 0,001 USD), kann jeder zum Marktpreis eine große Menge LUNA kaufen und diese als Sicherheit (Wert von 0,10 USD) verwenden, um andere Vermögenswerte von der Plattform zu leihen.

Audit-Punkte: Während des Audits sollte darauf geachtet werden, ob der Preismechanismus des Orakels zur Berechnung des Wertes der Sicherheiten leicht von außen manipuliert werden kann. Es kann empfohlen werden, dass die Projektteams verschiedene Preisquellen für eine umfassende Bewertung verwenden, um Risiken zu vermeiden, die aus einer einzelnen Preisquelle resultieren.

4.4 Risiken der Wechselkursmanipulation durch Multi-Entry-Point-Tokens

Im Code von Compound gibt es eine Funktion namens sweepToken, deren Zweck es ist, es Benutzern, die versehentlich Tokens in den Vertrag übertragen haben, zu ermöglichen, diese Tokens wieder abzuziehen. Der alte Code dieser Funktion enthält eine wichtige Sicherheitsüberprüfung: Das übergebene Token-Argument darf nicht das zugrunde liegende Asset des Vertrags sein.

Wenn jedoch in einem cToken-Markt die Basis-Asset-Token mehrere Eingangsverträge haben (d. h. über mehrere Vertragsadressen auf dasselbe Basisguthaben zugegriffen werden kann, wobei externe Interaktionen alle Eingangsverträge beeinflussen), kann der Angreifer die Funktion sweepToken aufrufen, indem er mit einem anderen Eingangspunktvertrag als dem underlying einen Transfer des Basis-Asset-Tokens aus dem Vertrag durchführt.

Hier ist TUSD das Beispiel, das über zwei Eingangsvertragsstellen verfügt. Der unterstützende Eingangspunktvertrag 0x8dd5fbce leitet jeden Aufruf (wie transfer oder balanceOf) an den Hauptvertrag weiter, was bedeutet, dass die Interaktion mit einem dieser Verträge die Salden in beiden Verträgen beeinflusst (d. h. zwei verschiedene Verträge teilen sich dieselben Salden).

Angenommen, die im Markt festgelegte Adresse des Basis-Token ist die Hauptvertragsadresse von TUSD. Dann können wir die Adresse des unterstützenden Eingangspunktvertrags 0x8dd5fbce als übergebenes Token-Argument beim Aufruf der Funktion sweepToken verwenden, um erfolgreich die Überprüfung address(token) != underlying zu bestehen, wonach der Vertrag alle Basis-Asset-Tokens TUSD an die Administratoradresse überträgt.

Der Wechselkurs zwischen TUSD und cTUSD wird von der Anzahl der im cTUSD-Vertrag enthaltenen Basis-Asset-Tokens TUSD beeinflusst. Wenn TUSD vollständig an die Administratoradresse überwiesen wird, fällt der Wechselkurs von TUSD / cTUSD sofort dramatisch. Zu diesem Zeitpunkt kann der Angreifer zu einem extrem niedrigen Wechselkurs andere Benutzer liquidieren oder nach der Kreditaufnahme weniger Tokens als erwartet zurückzahlen, um Gewinne zu erzielen.

Es ist erwähnenswert, dass in der neuesten Version des Codes von Compound V2 eine Berechtigungsprüfung zur Funktion sweepToken hinzugefügt wurde, um sicherzustellen, dass nur die Rolle des Administrators diese Funktion aufrufen kann, und dass alle Märkte, in denen es Multi-Entry-Point-Token gibt, entfernt wurden.

Audit-Punkte: Während des Audits müssen die Auswirkungen der Funktionalität zum Übertragen von Tokens innerhalb des Vertrags auf Szenarien mit Multi-Entry-Point-Tokens berücksichtigt werden. Es kann empfohlen werden, dass das Projektteam keine Multi-Entry-Point-Tokens verwendet oder prüft, ob sich die Anzahl der unterliegenden Asset-Tokens vor und nach der Übertragung des Tokens im Vertrag ändert, und entsprechende Berechtigungsprüfungen durchführt.

4.5 Kompatibilitätsprobleme zwischen alten und neuen Vertragscodes

Wenn in einem Fork-Projekt von Compound der Code eines Kernvertrags von der neuen Version des Compound Finance V2-Codes abgezweigt wird, während ein anderer Vertrag, der mit ihm interagiert, die alte Version des Codes verwendet, können Kompatibilitätsprobleme auftreten.

In der alten Version des cToken verwendeten die Funktionen des InterestRateModel-Vertrags zur Ermittlung des Zinssatzes die Funktion getBorrowRate, die zwei uint-Werte zurückgab, während die neue Version der Funktion getBorrowRate nur einen uint-Wert zurückgibt.

In dem Fork-Projekt Percent Finance von Compound Finance V2 verwendet das Projektteam jedoch die alte Version des cToken-Vertragscodes, während der InterestRateModel-Vertrag die neue Version verwendet, was zu einem Fehler führt, wenn die accrueInterest-Funktion im cToken den getBorrowRate aufruft. Da die accrueInterest-Funktion sowohl bei Abhebungen als auch bei Krediten verwendet wird, können Abhebungen und Kreditfunktionen nicht mehr ordnungsgemäß durchgeführt werden, und die Gelder im Vertrag bleiben vollständig gesperrt.

Audit-Punkte: Während des Audits sollte darauf geachtet werden, ob die Änderungen in den aktualisierten Codes, insbesondere in Bezug auf Vertragsinterfaces, Statusvariablen, Funktionssignaturen und Ereignisse, den normalen Betrieb des bestehenden Systems beeinträchtigen, um sicherzustellen, dass alle Versionen der Vertragscodes konsistent aktualisiert werden oder dass die aktualisierten Codes mit den alten Versionen kompatibel sind.

4.6 Hardcodierung durch Multi-Chain-Bereitstellung

Im Code von Compound Finance V2 repräsentiert die Konstante blocksPerYear die geschätzte Anzahl der jährlich produzierten Blöcke, deren Wert im Zinssatzmodellvertrag auf 2.102.400 hart kodiert ist, da die durchschnittliche Blockzeit von Ethereum 15 Sekunden beträgt.

Die Blockzeiten auf verschiedenen Ketten können jedoch unterschiedlich sein, und die geschätzte Anzahl der jährlich produzierten Blöcke kann ebenfalls variieren. Wenn ein Fork-Projekt von Compound auf einer anderen Kette bereitgestellt wird, aber die hartkodierten Werte nicht an die spezifischen Bedingungen der verschiedenen Ketten angepasst werden, kann es zu abweichenden Ergebnissen bei der Berechnung des Zinssatzes kommen. Dies liegt daran, dass der Wert von blocksPerYear den Wert von baseRatePerBlock und multiplierPerBlock beeinflusst, die schließlich den Zinssatz für Kredite beeinflussen.

Wenn die Blockzeit der BSC-Kette beispielsweise 3 Sekunden beträgt, sollte die geschätzte Anzahl der produzierten Blöcke pro Jahr (blocksPerYear) 10.512.000 betragen. Wenn der Wert von blocksPerYear vor der Bereitstellung nicht geändert wird, führt dies dazu, dass der berechnete Zinssatz letztendlich fünfmal höher ist als erwartet.

Audit-Punkte: Während des Audits sollte darauf geachtet werden, ob die hart codierten Konstanten oder Variablen in den Projektverträgen unter den Eigenschaften verschiedener Ketten unerwartete Ergebnisse hervorrufen, und es wird empfohlen, dass das Projektteam die Werte entsprechend den Bedingungen der verschiedenen Ketten korrekt anpasst.

Andere

Neben den oben genannten Hauptanliegen ändern Fork-Projekte von Compound V2 häufig bestimmte Geschäftspraktiken entsprechend dem Design des Projektteams, z. B. das Hinzufügen von Code zur Interaktion mit externen Drittanbieterprotokollen. Dies muss im Audit bewertet werden, um festzustellen, ob es Auswirkungen auf das Kern-Kreditmodell von Compound Finance V2 und das Projekt hat.

Abschließend

Wir hoffen, dass dieses Sicherheitsaudit-Handbuch für Compound Finance V2 und seine Fork-Projekte Ihnen hilft, bei Audits besser zu verstehen und die Sicherheit solcher komplexen Systeme zu bewerten. Mit der Iteration und Aktualisierung der Technologie wird dieses Handbuch ebenfalls aktualisiert und verbessert.

Referenz:

[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

Bearbeitet von | Liz