#termmax @TermMax ...Je passais en revue les derniers correctifs V2 de TermMax, et un point ne cessait de me déranger.
Je pensais que la plupart des bugs DeFi venaient d’un mauvais calcul.
Cette fois, le calcul était presque correct.
Le vrai problème venait d’une mauvaise représentation de la réalité.
Prenons apr().
L’ancienne logique se basait sur le solde brut XT de l’ordre.
Ça paraît raisonnable, non ?
Mais en V2, le solde brut XT n’est pas utilisé comme état de tarification. Il utilise virtualXtReserve.
Cette distinction compte...
Imaginez une boutique où l’étiquette de prix est contrôlée par le grand livre interne du magasin, mais où vous commencez à calculer les prix à partir de la somme de cash qu’une personne a déposée aléatoirement au comptoir.
Le cash a changé.
Le modèle de prix, lui, ne changeait pas.
C’est exactement ce qu’un transfert direct en XT pourrait faire avec l’ancien calcul d’APR.
Un solde peut bouger sans que la courbe ne bouge, et pourtant apr() peut traiter ce solde comme le nouvel état de tarification.
Le correctif fait correspondre le modèle de comptabilité au modèle économique.
Et je pense que c’est la leçon la plus intéressante.
Dans les smart contracts financiers, la question dangereuse n’est pas toujours :
« La formule est-elle correcte ? »
Parfois, c’est plutôt :...
« Donne-t-on à la formule le bon état ? »
Le même thème ressort du correctif de liquidation.
Un oracle de dette sur 18 décimales pourrait faire s’effondrer la conversion décimale lors de la comparaison des garanties, transformant des positions qui devraient permettre une liquidation à 50% en une liquidation totale.
Encore une fois, ce n’est pas vraiment un problème de formule compliquée.
C’était un problème d’unités.
C’est pourquoi je commence à prêter davantage attention à ces changements qui ont l’air ennuyeux.
Un correctif de comptabilité en une ligne peut compter plus qu’une nouvelle fonctionnalité spectaculaire, parce qu’il détermine si le protocole interprète correctement le marché.
Pour TermMax, je surveillerais une chose de près dès maintenant :
pas seulement la quantité de liquidité que le système possède, mais aussi si la tarification, la valorisation des garanties et la logique de liquidation lisent toutes la même réalité économique.....
C’est là que « le code fonctionne » commence à devenir « l’infrastructure financière fonctionne ».
Plutôt que d’auditer les formules d’abord, l’état comptable d’abord, ou les hypothèses de l’oracle/des unités d’abord ?....
Je pensais que la plupart des bugs DeFi venaient d’un mauvais calcul.
Cette fois, le calcul était presque correct.
Le vrai problème venait d’une mauvaise représentation de la réalité.
Prenons apr().
L’ancienne logique se basait sur le solde brut XT de l’ordre.
Ça paraît raisonnable, non ?
Mais en V2, le solde brut XT n’est pas utilisé comme état de tarification. Il utilise virtualXtReserve.
Cette distinction compte...
Imaginez une boutique où l’étiquette de prix est contrôlée par le grand livre interne du magasin, mais où vous commencez à calculer les prix à partir de la somme de cash qu’une personne a déposée aléatoirement au comptoir.
Le cash a changé.
Le modèle de prix, lui, ne changeait pas.
C’est exactement ce qu’un transfert direct en XT pourrait faire avec l’ancien calcul d’APR.
Un solde peut bouger sans que la courbe ne bouge, et pourtant apr() peut traiter ce solde comme le nouvel état de tarification.
Le correctif fait correspondre le modèle de comptabilité au modèle économique.
Et je pense que c’est la leçon la plus intéressante.
Dans les smart contracts financiers, la question dangereuse n’est pas toujours :
« La formule est-elle correcte ? »
Parfois, c’est plutôt :...
« Donne-t-on à la formule le bon état ? »
Le même thème ressort du correctif de liquidation.
Un oracle de dette sur 18 décimales pourrait faire s’effondrer la conversion décimale lors de la comparaison des garanties, transformant des positions qui devraient permettre une liquidation à 50% en une liquidation totale.
Encore une fois, ce n’est pas vraiment un problème de formule compliquée.
C’était un problème d’unités.
C’est pourquoi je commence à prêter davantage attention à ces changements qui ont l’air ennuyeux.
Un correctif de comptabilité en une ligne peut compter plus qu’une nouvelle fonctionnalité spectaculaire, parce qu’il détermine si le protocole interprète correctement le marché.
Pour TermMax, je surveillerais une chose de près dès maintenant :
pas seulement la quantité de liquidité que le système possède, mais aussi si la tarification, la valorisation des garanties et la logique de liquidation lisent toutes la même réalité économique.....
C’est là que « le code fonctionne » commence à devenir « l’infrastructure financière fonctionne ».
Plutôt que d’auditer les formules d’abord, l’état comptable d’abord, ou les hypothèses de l’oracle/des unités d’abord ?....
