fluxswap
Ein Protokoll für eine dezentrale Börse (DEX) in Solidity, gebaut mit Foundry. Liquiditätspools, Router, Staking und Timelock - mit Invarianten und vollständiger Testabdeckung.
Ein Protokoll für eine dezentrale Börse (DEX) in Solidity: Liquiditätspools, ein Router, Staking und ein Timelock. Der Vertrag bewegt echte Gelder, also ist ein Bug keine Korrektur für das nächste Release, sondern verlorenes Geld. Deshalb zählen Invarianten und volle Testabdeckung in Foundry, nicht die Aussage, dass es aussieht, als funktioniere es.
Einführung
Die meiste Software lebt davon, dass sich Fehler beheben lassen. Ein On-Chain-Vertrag nimmt Ihnen diesen Komfort: Er ist unveränderlich und hält fremdes Geld. Das kehrt die Art um, wie Sie Code schreiben, denn Sie prüfen nicht mehr, ob der Glücksfall funktioniert, sondern ob eine Regel, die immer halten soll, nicht gebrochen werden kann.
fluxswap ist um diesen Unterschied herum gebaut. Liquiditätspools, ein Router, Staking und ein Timelock sind Funktionen, aber die eigentliche Arbeit steckt in den Invarianten, die nach jeder möglichen Folge von Operationen halten müssen, auch nach der, die niemand vorhergesehen hat.
Code, den Sie nachträglich nicht aktualisieren können
Eine gewöhnliche App hat einen Bug, Sie liefern eine Korrektur, es geht weiter. Ein On-Chain-Vertrag ist unveränderlich und hält fremdes Geld, also ist ein Fehler in der Logik des Liquiditätspools kein Defekt, sondern ein Vektor, über den jemand Gelder abzieht. Es gibt hier kein Release Nummer zwei, in dem Sie es reparieren.
Diese eine Eigenschaft ändert alles. Sie schreiben unter der Annahme, dass jeder, der auf den Vertrag schaut, nach einem Weg sucht, seine Regeln zu brechen, und dass die einzige Verteidigung der Beweis ist, dass sie nicht gebrochen werden können.
Einzelne Tests prüfen konkrete Eingaben, die Sie sich selbst ausdenken, also prüfen sie nur das, was Sie bereits vorausgesehen haben. Invariantentests in Foundry tun etwas Stärkeres: Sie bombardieren den Vertrag zufällig mit Tausenden von Operationsfolgen und prüfen nach jeder, dass die Regel weiterhin gilt.
Die Tokensummen stimmen, das Produkt der Reserven fällt nicht, niemand hat mehr abgehoben, als er eingezahlt hat. Der Unterschied ist grundlegend, denn es ist der Fuzzer, nicht Sie, der das Szenario erfindet, das den Vertrag bricht, und er tut es Tausende Male hintereinander.
Der Timelock, oder Zeit zum Reagieren
Der Timelock auf empfindlichen Operationen ist dazu da, dass eine Parameteränderung nicht von einer Minute auf die andere durchgesetzt werden kann. Selbst der Besitzer wartet, und die Community sieht, was kommt, bevor es geschieht, und hat Zeit zu reagieren, falls die Änderung feindlich ist.
Diese Absicherung schützt nicht vor einem Bug im Code, sondern vor dem Missbrauch von Berechtigungen. Ohne Timelock könnte der Besitzer die Protokollparameter still kurz vor einem Angriff umstellen. Mit ihm ist jede solche Änderung sichtbar und verzögert, was ihr das Moment der Überraschung nimmt.
Beweis statt Hoffnung
Das Ergebnis ist ein Protokoll, dessen Sicherheit auf einem Beweis ruht und nicht auf der Überzeugung, dass wir die wichtigsten Fälle getestet haben. Die Invarianten halten über Tausende zufälliger Folgen, empfindliche Änderungen sind durch den Timelock verzögert, und die gefährlichsten Regeln, wie das konstante Produkt der Reserven, werden direkt im Vertragscode durchgesetzt.
Invarianten und was sie garantieren
| Invariante | Was sie garantiert |
|---|---|
| Konstantes Produkt | das Produkt der Reserven fällt nach einem Swap nicht |
| Tokensumme | Einzahlungen gleich Auszahlungen plus Saldo |
| Auszahlung | niemand nimmt mehr, als er eingelegt hat |
| Timelock | Parameteränderungen sind verzögert und öffentlich |
Weitere Projekte
Weitere Projekte aus derselben Kategorie - sehen Sie, wie wir ähnliche Herausforderungen angehen.
Haben Sie ein ähnliches Projekt?
Melden Sie sich - ein Angebot ist kostenlos und kommt innerhalb einer Stunde.