fluxswap
Un protocole d'échange décentralisé (DEX) en Solidity, construit avec Foundry. Pools de liquidité, routeur, staking et timelock - avec invariants et couverture de tests complète.
Un protocole d'échange décentralisé (DEX) en Solidity : pools de liquidité, un routeur, du staking et un timelock. Le contrat déplace de vrais fonds, donc un bug n'est pas une correction pour la prochaine version, c'est de l'argent perdu. C'est pourquoi les invariants et une couverture de tests complète dans Foundry comptent, pas le fait de dire que cela a l'air de fonctionner.
Introduction
La plupart des logiciels vivent sur le fait que les bugs peuvent être corrigés. Un contrat on-chain vous retire ce confort : il est immuable et détient l'argent d'autrui. Cela inverse la façon dont vous écrivez le code, car vous ne vérifiez plus que le chemin heureux fonctionne, vous vérifiez qu'une règle censée toujours tenir ne peut pas être brisée.
fluxswap est construit autour de cette différence. Les pools de liquidité, un routeur, le staking et un timelock sont des fonctionnalités, mais le vrai travail réside dans les invariants qui doivent tenir après toute séquence possible d'opérations, y compris celle que personne n'a prévue.
Du code que vous ne pouvez pas mettre à jour après coup
Une application ordinaire a un bug, vous livrez une correction, la vie continue. Un contrat on-chain est immuable et détient l'argent d'autrui, donc un bug dans la logique du pool de liquidité n'est pas un défaut, c'est un vecteur par lequel quelqu'un draine des fonds. Il n'y a pas de version numéro deux où vous le corrigez.
Cette seule propriété change tout. Vous écrivez en supposant que quiconque regarde le contrat cherche un moyen de briser ses règles, et que la seule défense est de prouver qu'elles ne peuvent pas être brisées.
Les tests individuels vérifient des entrées précises que vous inventez vous-même, donc ils ne vérifient que ce que vous avez déjà anticipé. Les tests d'invariants dans Foundry font quelque chose de plus fort : ils bombardent le contrat au hasard avec des milliers de séquences d'opérations et vérifient après chacune que la règle tient toujours.
Les sommes de tokens correspondent, le produit des réserves ne baisse pas, personne n'a retiré plus qu'il n'a déposé. La différence est fondamentale, car c'est le fuzzer, pas vous, qui invente le scénario qui brise le contrat, et il le fait des milliers de fois d'affilée.
Le timelock, ou le temps de réagir
Le timelock sur les opérations sensibles existe pour qu'un changement de paramètres ne puisse pas être poussé d'une minute à l'autre. Même le propriétaire attend, et la communauté voit ce qui arrive avant que cela n'arrive, avec le temps de réagir si le changement est hostile.
Cette protection ne protège pas contre un bug dans le code mais contre l'abus de privilège. Sans timelock, le propriétaire pourrait discrètement rerégler les paramètres du protocole juste avant une attaque. Avec lui, chaque changement de ce genre est visible et différé, ce qui lui retire l'effet de surprise.
La preuve plutôt que l'espoir
Le résultat est un protocole dont la sécurité repose sur une preuve, pas sur la conviction que nous avons testé les cas les plus importants. Les invariants tiennent à travers des milliers de séquences aléatoires, les changements sensibles sont différés par le timelock, et les règles les plus dangereuses, comme le produit constant des réserves, sont appliquées directement dans le code du contrat.
Les invariants et ce qu'ils garantissent
| Invariant | Ce qu'il garantit |
|---|---|
| Produit constant | le produit des réserves ne baisse pas après un swap |
| Somme de tokens | les dépôts égalent les retraits plus le solde |
| Retrait | personne ne prend plus qu'il n'a mis |
| Timelock | les changements de paramètres sont différés et publics |
Plus de projets
D'autres réalisations de la même catégorie - découvrez comment nous abordons des défis similaires.
Vous avez un projet similaire ?
Contactez-nous - le devis est gratuit et arrive sous une heure.