Allgemeine Eigenschaftstests für ERC4626-Tresore

Da DeFi wächst und reift, stehen skalierbare Infrastruktur und Zusammensetzbarkeit für Entwickler an erster Stelle. Ethereum Requests for Comments (oder ERCs) – standardisierte Toolkits zum Erstellen von Ethereum-basierten Apps, wie z. B. der weit verbreitete Token-Standard ERC20 – dienen der wesentlichen Rolle, konsistente Richtlinien für Entwickler bereitzustellen, damit sie zum Ökosystem beitragen können, ohne bei Null anzufangen. Früher in diesem Jahr, tokenisierter Vault-Standard ERC4626 wurde geschaffen, um die Kreuzkompatibilität zwischen ertragsstarken Token zu fördern. Durch die Standardisierung von Implementierungsdetails können auch dringende Probleme bei der Zusammensetzbarkeit behoben werden, wodurch die Protokollintegration einfacher und letztendlich weniger fehleranfällig wird.

Mehrere DeFi-Projekte haben dies bereits getan angenommen den Standard, um die Zusammenstellbarkeit ihrer Tresore zu verbessern, und wir erwarten eine breitere Akzeptanz im gesamten Ökosystem. Das Anpassen bestehender Gewölbe verursacht jedoch einige Wachstumsschmerzen; Entscheidend ist, dass bestimmte Implementierungsfehler neue Angriffsziele offenlegen können. Selbst kleine Fehler (so klein wie die Fehlinterpretation der Standardschnittstelle) können erhebliche Konsequenzen sowohl für die Sicherheit als auch für die Benutzererfahrung haben, was die Notwendigkeit weiterer Sicherheitstools und -maßnahmen unterstreicht, insbesondere innerhalb eines besser zusammensetzbaren DeFi-Ökosystems. 

Glücklicherweise können einfache Fehler relativ einfache Lösungen haben, wenn sie erkannt werden, bevor sie ausgenutzt werden (und idealerweise bevor sie überhaupt eingesetzt werden). Zu diesem Zweck haben wir veröffentlicht ERC4626-Eigenschaftstests für Fuzzing und symbolische Ausführung, um Tresorbauern dabei zu helfen, Standardverletzungen zu erkennen, die Integrationen unterbrechen oder später zu Schwachstellen führen können. In diesem Beitrag erklären wir das Motivationsproblem, gehen unseren Ansatz durch und schließen mit einigen umsetzbaren Ratschlägen ab.

Zunächst ein wenig Hintergrundinformationen zum ERC4626-Standard

Abgeschlossen im März, ERC4626 ist der Standard für tokenisierte Tresore. Es wurde eingeführt, um das weit verbreitete zu erweitern ERC20 Standard (derzeit die Basis für Hunderte von Token), Förderung der Standardisierung über Yield-tragende Tresore hinweg und Sicherstellung der Zusammensetzbarkeit für die Apps und Protokolle (z. B. Yield-Aggregatoren), die mit ihnen interagieren müssen. Dies bedeutet, dass jede App, die auf einem ERC4626-Tresor erstellt wurde, problemlos erweitert werden kann, um mit jedem anderen ERC4626-Tresor zu funktionieren. 

Tokenisierte Tresore ermöglichen es Benutzern, Vermögenswerte frei in Tresoranteile zu hinterlegen und diese Anteile später einzulösen, um Kapital und Zinsen aus dem Tresor abzuheben. Diese Tresoranteile sind ERC20-Token und können daher leicht gehandelt oder als Sicherheit zum Ausleihen anderer Vermögenswerte verwendet werden. Beispielsweise können Benutzer ihre Vermögenswerte in Yearn-Tresoren hinterlegen, um yVault-Token zu prägen, die dann auf Uniswap gehandelt, für zusätzliche Erträge eingesetzt oder als Sicherheit für Kreditvergabeprotokolle verwendet werden können.

Die Geschäftslogik zum Generieren und Ausschütten von Renditen (und zum Bestimmen des Anteilspreises) kann je nach Implementierung variieren. Um so viele Tresore wie möglich abzudecken (mit dem Ziel, sie interoperabel bzw. identisch zu machen), konzentriert sich der ERC4626-Standard auf die Beschreibung der Benutzeroberfläche und lässt die meisten Implementierungsdetails unspezifiziert. Dies ermöglicht Variationen in der Geschäftslogik, solange der Tresor die spezifischen Anforderungen der Schnittstelle erfüllt und fördert Interoperabilität über viele verschiedene Arten von Apps und Arten von ERC4626-Tresoren hinweg.

Wenn mehr Tresore erstellt werden, erwarten wir, dass sie von Anfang an gemäß dem ERC4626-Standard implementiert werden; aber wir befinden uns derzeit in einer gewissen Übergangsphase, in der Entwickler, die die Vorteile einer größeren Zusammensetzbarkeit nutzen möchten, vorhandene Tresore, Apps und Protokolle aktualisieren müssen, damit sie dem Standard entsprechen. Und während sie aufrüsten, kämpfen sie mit einer Reihe von Komplexitäten und Herausforderungen. 

Die Herausforderungen der Standardkonformität (und die Fallstricke der Nichtkonformität)

Einem neuen Standard zu folgen ist nicht immer einfach. Jeder ERC4626-Tresor muss die Anforderungen des Standards wie beschrieben originalgetreu (und genau) implementieren. Andernfalls wird die Integration von ERC4626-Tresoren immer komplexer, um unterschiedliche Variationen zu berücksichtigen. Diese Komplexität macht Integrationen von Natur aus fehleranfällig; und weil sie nicht ausreichend zukunftssicher sind, können sie im Laufe der Zeit zu Sicherheitslücken führen.

Nicht standardmäßige ERC20-Token (z. B. Tether USD) erfordern, dass viele DeFi-Systeme eine zusätzliche Bibliothek (z. B. SafeERC20) verwenden, wenn sie Token-Transfers durchführen, um sicher mit abweichendem Verhalten umzugehen (z. B. nichts zurückgeben, wenn eine Übertragung erfolgreich ist, anstatt zurückzukehren true). Dies bedeutet, dass alle Systeme, die mit diesen Token interagieren, angreifbar werden könnten, wenn das System nicht dafür ausgelegt ist, Fälle von „fehlenden Renditen“ richtig zu behandeln. Diese Szenarien können möglicherweise zu einer häufigen Sicherheitsfalle führen und die Gesamtentwicklungs- und Wartungskosten erhöhen (wenn die zusätzliche Logik und Abhängigkeiten berücksichtigt werden, die zur Minderung von Problemen erforderlich sind). Die Einhaltung des Standards ist daher nicht nur für einzelne Implementierungen, sondern auch für die Sicherheit des gesamten Ökosystems von entscheidender Bedeutung. Eine Schwachstelle in einem einzelnen System oder einer Abhängigkeit kann weit verbreitete Probleme verursachen.

Idealerweise würden Standards ohne Mehrdeutigkeit formal spezifiziert (z. formale Spezifikation von ERC20), und jede Implementierung konnte formal gegen die Standardspezifikation verifiziert werden. In der Praxis ist dies jedoch aufgrund der Kosten und des Aufwands, der von der Community verlangt wird, nicht einfach in kurzer Zeit zu erreichen.

Einführung ausführbarer ERC4626-Eigenschaften zur Identifizierung von Konformitätsproblemen 

Während wir auf einen idealen Zustand hinarbeiten (jeder Tresor wird formal anhand strenger formaler Spezifikationen überprüft), haben wir den ERC4626-Standard geschrieben immobilien Abweichungen in subtilen, leicht zu übersehenden Details der Standardanforderungen zu erkennen.  

Vault-Entwickler können die Tests ausführen, um potenzielle Standardverletzungen in ihren Implementierungen vor der Bereitstellung zu erkennen. Und Tresorintegratoren können prüfen, ob die angegebenen Tresore dem Standard entsprechen, bevor sie sie in ihr System integrieren. Die Eigenschaften können auch mit den bereits im Mainnet bereitgestellten Live-Vaults über Mainnet-Fork-Tests getestet werden. Das Testen von Live-Tresoren kann nützlich sein – insbesondere wenn die Tresore kürzlich bereitgestellt oder aktualisiert wurden – um sicherzustellen, dass alle Systemparameter korrekt eingestellt wurden. 

Wir haben eigenschaftsbasierte Tests gewählt – geschrieben in Foundry und bereit, von seinem Fuzzer ausgeführt zu werden – um die Eigenschaften ausführbar (und damit testbar) zu machen. In Zukunft können sie auch von symbolischen Ausführungs- oder Modellprüfungswerkzeugen ausgeführt werden, um formal zu verifizieren, dass der angegebene Tresor die Eigenschaften für alle möglichen Eingaben und Bedingungen erfüllt.

Wir haben die Eigenschaften so allgemein gehalten, dass sie auf eine Vielzahl von Tresoren angewendet werden können, die unterschiedliche Geschäftslogik implementieren. Wir haben nur öffentliche Schnittstellenfunktionen verwendet, um sie unabhängig von Implementierungsdetails zu machen. (Aufgrund dieser Einschränkung wurden jedoch bestimmte Standardanforderungen, die sich auf implementierungsspezifische interne Daten beziehen, bei den Eigenschaften weggelassen.)

Beispielsweise entspricht die folgende Eigenschaft einer der Anforderungen der convertToShares() Funktion, „DÜRFEN KEINE Variationen je nach Anrufer aufweisen.“ Angesichts der beiden Kontoadressen und des Betrags macht es jedes der Konten zum Aufruf convertToShares() mit dem gleichen Betrag und stellt sicher, dass die beiden Rückgabewerte gleich sind. Diese Eigenschaft ist unabhängig von den Implementierungsdetails von convertToShares(), die je nach Tresor variiert und von allen Tresoren erfüllt werden muss, die ERC4626 implementieren. Diese Eigenschaft kann ausgeführt werden, indem bestimmte Eingabewerte (für Komponententests), viele zufällige Eingaben (für Fuzz-Tests) oder symbolische Werte (für symbolische Ausführung und formale Überprüfung) bereitgestellt werden. Es kann auch lokal oder gegen einen Mainnet-Fork (für Integrationstests) ausgeführt werden.

Anwendungsfall: Eigenschaften, die auf Rundungsfehler testen

Rundungsfehler sind beispielsweise eine wichtige Klasse von (scheinbar geringfügigen) Fehlern, die Auswirkungen auf Serien haben können. Die zugrunde liegende Abrechnungslogik von ERC4626, z. B. die Berechnung der Anzahl der zu prägenden Aktien oder der Höhe des abzuziehenden Vermögens, wird mit Festkommaarithmetik implementiert – Rundungsfehler sind unvermeidlich. Zum Sicherheitdienst, der Standard gibt jedoch explizit die bevorzugte Rundungsrichtung für jede Schnittstellenfunktion an, während die Fehlergrenzen unspezifiziert und implementierungsabhängig bleiben. Insbesondere die deposit() machen redeem() Funktionen sollten ein zurückgeben für-Annäherung an den genauen Wert, während die mint() machen withdraw() Funktionen sollten ein zurückgeben übrig-Annäherung. Wenn beispielsweise der aktuelle Aktienkurs (dh die Höhe des Vermögens pro Aktie) 2 beträgt, dann deposit() mit 3 Wei an Vermögenswerten sollte nur bis zu 1 Wei an Aktien prägen (d.h. floor(3/2)), während withdraw() mit 3 Wei an Vermögenswerten sollten mindestens 2 Wei an Aktien verbrennen (d. h. ceil(3/2)).

Wir haben die rundungsbezogenen Eigenschaften so geschrieben, dass sie von der zugrunde liegenden Buchhaltungslogik unabhängig sind, indem wir sie als Black Box behandeln. Konkret haben wir sie als sogenannte „Round-Trip“-Eigenschaften formuliert, die den Zusammenhang zwischen zwei gegensätzlichen Funktionen beschreiben. Beispielsweise legt die folgende Eigenschaft fest, dass beim Abheben von Vermögenswerten, die gerade durch Prägen von N-Aktien hinterlegt wurden, nicht weniger als N-Aktien verbrannt werden müssen. Mit anderen Worten, niemand kann einen kostenlosen Gewinn erzielen, indem er Vermögenswerte und Tresoranteile hin und her umwandelt, indem er wiederholt prägt und abhebt.

Tatsächlich haben wir festgestellt, dass mehrere ERC4626-Tresore im Mainnet die obige Eigenschaft aufgrund von Rundungsfehlern nicht erfüllen. Das bedeutet, dass jeder zum Beispiel ein paar Satoshi BTC (1 Satoshi ~= 0.02 Cent zum Zeitpunkt des Schreibens) verdienen könnte, indem er einfach (und wiederholt) prägt und abhebt, wodurch der Tresor langsam geleert wird. Dies kann Ketten mit sehr niedrigen Gasgebühren (z. B. Fantom) tatsächlich einen Gewinn bringen, oder wenn der Vermögenspreis in Zukunft hoch genug wird.

Testen des ERC4626-Standards in freier Wildbahn

Wir haben unsere Eigenschaften mit ~100 ERC4626-Tresoren im Mainnet getestet und viele Tresore gefunden, die den Standardanforderungen nicht entsprachen – hauptsächlich aufgrund von Rundungsfehlern (z. B. Verwendung von Bodenrundungen, wo die Decke gewünscht wird, wie wir beschrieben haben). Insbesondere bestimmte Tresore versäumten es, die genaue Anzahl der von der angeforderten Aktien zu prägen mint() funktionieren, obwohl der Standard dies ausdrücklich verlangt fehlen uns die Worte.. Einige von ihnen gaben auch ein Inkonsistenz aus Deposit Ereignis, bei dem sich die protokollierten Daten von den tatsächlich geprägten Daten unterscheiden. Zu unserer Überraschung wurden einige Tresore überhaupt nie vor Ort geprägt; Stattdessen stellen sie die Mint-Anforderungen einfach in eine Warteschlange und verarbeiten sie später in einem Stapel als separate Transaktion.

Obwohl diese abweichenden Verhaltensweisen per se nicht ausnutzbar waren, können sie angreifbar werden, wenn sie in andere Systeme integriert werden, die nur die Standardverhaltensweisen erwarten. Diese Probleme werden die Vault-Integration viel schwieriger machen, die laufenden Bemühungen neutralisieren und die Motivation hinter der Standardisierung antreiben.

Verwendung unserer Eigenschaftstests und anderer umsetzbarer Schritte zur Standardkonformität

Das genaue Befolgen des Standards kann abweichendes Verhalten verhindern (idealerweise bevor es überhaupt zum Einsatz kommt). Wir hoffen, dass unsere Eigenschaften zusammen mit einigen zusätzlichen Aktionselementen helfen. Für diejenigen, die ERC4626-Tresore entwickeln und/oder integrieren:

• Wir empfehlen dringend, unser Eigentum zu führen Tests gegen deine Gewölbe. Sie finden Probleme schnell, wenn es klare Verstöße gegen den Standard gibt.
• Wir empfehlen auch, unsere zu überprüfen immobilien um Ihr Verständnis der Standardanforderungen zu überprüfen und Ihre Implementierung anzupassen, wenn es unbeabsichtigte Abweichungen gibt.
• Wenn Ihr Tresor vom Standard abweichen muss, empfehlen wir, die nicht standardmäßigen Verhaltensweisen klar zu dokumentieren, damit andere diese Abweichungen bei der Integration in Ihren Tresor ordnungsgemäß handhaben können. Bitte beachten Sie, dass dies als letzter Ausweg betrachtet werden sollte.

***
ERC4626-Tresore haben das Potenzial, in absehbarer Zeit ein wichtiger Baustein für DeFi zu werden – und aus Gründen der Zusammensetzbarkeit ist es wichtig, dass sowohl neue als auch bestehende Tresore dem Standard folgen. Neue Implementierungen werden nach dem Standard entstehen, daher gibt es keinen besseren Zeitpunkt als die Gegenwart, um bestehende Tresore zu standardisieren. 

Während wir auf einen idealen Zustand hinarbeiten (in dem verschiedene Tresore einheitlich zusammensetzbar sind), können ERC4626-Eigenschaftstests ausgeführt werden, um Standardverletzungen in Tresorimplementierungen einfacher zu erkennen. Die Eigenschaftstests (mit Dokumentation und Beispielen) sind alle öffentlich in unserem Github verfügbar Quelle. Wir freuen uns über Ihr Feedback und Ihre Beiträge!

***
Die hier geäußerten Ansichten sind die der einzelnen zitierten Mitarbeiter von AH Capital Management, LLC („a16z“) und nicht die Ansichten von a16z oder seinen verbundenen Unternehmen. Bestimmte hierin enthaltene Informationen stammen aus Drittquellen, einschließlich von Portfoliounternehmen von Fonds, die von a16z verwaltet werden. Obwohl sie aus als zuverlässig erachteten Quellen stammen, hat a16z solche Informationen nicht unabhängig überprüft und macht keine Zusicherungen über die aktuelle oder dauerhafte Genauigkeit der Informationen oder ihre Angemessenheit für eine bestimmte Situation. Darüber hinaus kann dieser Inhalt Werbung von Drittanbietern enthalten; a16z hat solche Anzeigen nicht überprüft und unterstützt keine darin enthaltenen Werbeinhalte.

Dieser Inhalt wird nur zu Informationszwecken bereitgestellt und sollte nicht als Rechts-, Geschäfts-, Anlage- oder Steuerberatung angesehen werden. Sie sollten diesbezüglich Ihre eigenen Berater konsultieren. Verweise auf Wertpapiere oder digitale Vermögenswerte dienen nur der Veranschaulichung und stellen keine Anlageempfehlung oder ein Angebot zur Erbringung von Anlageberatungsdiensten dar. Darüber hinaus richtet sich dieser Inhalt nicht an Anleger oder potenzielle Anleger und ist nicht für die Verwendung durch diese bestimmt, und es darf unter keinen Umständen darauf vertraut werden, wenn eine Entscheidung getroffen wird, in einen von a16z verwalteten Fonds zu investieren. (Ein Angebot zur Investition in einen a16z-Fonds wird nur durch das Privatplatzierungsmemorandum, den Zeichnungsvertrag und andere relevante Unterlagen eines solchen Fonds abgegeben und sollte vollständig gelesen werden.) Alle erwähnten, erwähnten oder erwähnten Investitionen oder Portfoliounternehmen oder Portfoliounternehmen Die beschriebenen Investitionen sind nicht repräsentativ für alle Investitionen in von a16z verwaltete Vehikel, und es kann nicht garantiert werden, dass die Investitionen rentabel sind oder dass andere Investitionen in der Zukunft ähnliche Merkmale oder Ergebnisse aufweisen werden. Eine Liste der Investitionen von Fonds, die von Andreessen Horowitz verwaltet werden (mit Ausnahme von Investitionen, für die der Emittent a16z keine Genehmigung zur öffentlichen Offenlegung erteilt hat, sowie unangekündigte Investitionen in öffentlich gehandelte digitale Vermögenswerte) ist unter https://a16z.com/investments verfügbar /.

Die darin bereitgestellten Diagramme und Grafiken dienen ausschließlich zu Informationszwecken und sollten bei Anlageentscheidungen nicht als verlässlich angesehen werden. Die Wertentwicklung in der Vergangenheit ist kein Hinweis auf zukünftige Ergebnisse. Der Inhalt spricht nur zum angegebenen Datum. Alle Prognosen, Schätzungen, Prognosen, Ziele, Aussichten und/oder Meinungen, die in diesen Materialien geäußert werden, können ohne Vorankündigung geändert werden und können von den Meinungen anderer abweichen oder ihnen widersprechen. Weitere wichtige Informationen finden Sie unter https://a16z.com/disclosures