J’ai passé 9 heures sur 3 jours à construire un labo sur DuskEVM, en forkant Uniswap V3 Core, en exécutant les tests Foundry, puis en ouvrant Remix pour tracer chaque swap… à la 18e fois, je suis resté là, en silence, presque une demi-heure.
Pair.sol s’est compilé sans problème, le chainId était correct, les appels Router fonctionnaient, et à ce stade je croyais encore que l’équivalence EVM pouvait préserver le workflow familier.
puis _reserves ne m’a plus donné l’ancien moyen de déboguer.
Hedger détient la profondeur de liquidité, la fonction view ne lit plus l’état comme avant, et balanceOf n’expose non plus assez reserveIn et reserveOut.
J’ai essayé x = 1 200 et y = 2 400, avec un produit constant : k = x*y = 2 880 000.
j’ai mis une entrée de 120 avec des frais de 0,3 % : le montant restant est 119,64… la mathématique est élégante, mais tant que la part de LP vit à l’intérieur d’une note Zedger, obtenir un getAmountOut correct ne suffit toujours pas.
ConfidentialERC20 signifie que permit, approve et allowance changent de sémantique, SafeCast s’assemble avec HedgedUint256, tandis que swap consomme l’ancienne note puis en mint une nouvelle.
honnêtement, j’ai passé plus de temps ici qu’à écrire le Router !
le circuit doit prouver : ancien montant de note - entrée = nouveau montant de note + sortie, PLONK protège le montant, le market maker ne peut pas voir les données sensibles mais la clé de vue peut toujours les auditer.
alors, est-ce que la confidentialité rend le protocole plus solide, ou est-ce qu’elle ne fait que déplacer la difficulté vers les outils ?
L’Oracle est encore plus difficile.
TWAP nécessite des échantillonnages cohérents, mais quand l’objet d’échantillonnage devient un engagement de note et que la lecture directe disparaît, l’observabilité ne peut plus compter sur seulement quelques logs.
Je réutilise toujours Solidity, Foundry et Remix, mais avec Pair, Router, Oracle partageant le même chemin arithmétique pour mint, burn, swap, je préfère repenser le modèle d’état plutôt que d’essayer de sauver l’ancienne abstraction.
mon point de vue est assez rigide : un AMM confidentiel ne mûrit que lorsque la confidentialité et le débogage sont conçus ensemble.
si la liquidité peut être cachée, mais que les développeurs ont du mal à prouver que l’état est correct, est-ce que vous appelez ça un progrès, ou simplement une autre forme de complexité ?
#dusk $DUSK @Dusk
Pair.sol s’est compilé sans problème, le chainId était correct, les appels Router fonctionnaient, et à ce stade je croyais encore que l’équivalence EVM pouvait préserver le workflow familier.
puis _reserves ne m’a plus donné l’ancien moyen de déboguer.
Hedger détient la profondeur de liquidité, la fonction view ne lit plus l’état comme avant, et balanceOf n’expose non plus assez reserveIn et reserveOut.
J’ai essayé x = 1 200 et y = 2 400, avec un produit constant : k = x*y = 2 880 000.
j’ai mis une entrée de 120 avec des frais de 0,3 % : le montant restant est 119,64… la mathématique est élégante, mais tant que la part de LP vit à l’intérieur d’une note Zedger, obtenir un getAmountOut correct ne suffit toujours pas.
ConfidentialERC20 signifie que permit, approve et allowance changent de sémantique, SafeCast s’assemble avec HedgedUint256, tandis que swap consomme l’ancienne note puis en mint une nouvelle.
honnêtement, j’ai passé plus de temps ici qu’à écrire le Router !
le circuit doit prouver : ancien montant de note - entrée = nouveau montant de note + sortie, PLONK protège le montant, le market maker ne peut pas voir les données sensibles mais la clé de vue peut toujours les auditer.
alors, est-ce que la confidentialité rend le protocole plus solide, ou est-ce qu’elle ne fait que déplacer la difficulté vers les outils ?
L’Oracle est encore plus difficile.
TWAP nécessite des échantillonnages cohérents, mais quand l’objet d’échantillonnage devient un engagement de note et que la lecture directe disparaît, l’observabilité ne peut plus compter sur seulement quelques logs.
Je réutilise toujours Solidity, Foundry et Remix, mais avec Pair, Router, Oracle partageant le même chemin arithmétique pour mint, burn, swap, je préfère repenser le modèle d’état plutôt que d’essayer de sauver l’ancienne abstraction.
mon point de vue est assez rigide : un AMM confidentiel ne mûrit que lorsque la confidentialité et le débogage sont conçus ensemble.
si la liquidité peut être cachée, mais que les développeurs ont du mal à prouver que l’état est correct, est-ce que vous appelez ça un progrès, ou simplement une autre forme de complexité ?
#dusk $DUSK @Dusk
