Petite mais importante chose que j’ai apprise sur les outils de dev de Newton — la différence entre un « test réussi » et une « approbation réelle » 🧠
Donc Newton a cette fonctionnalité appelée simulateTask : elle permet, en gros, aux développeurs d’exécuter une politique AVANT de soumettre quoi que ce soit onchain. Ça paraît simple, mais voilà la subtilité : une simulation qui se termine avec succès ne veut PAS dire que la politique a dit « oui ». Ce sont deux choses totalement différentes.
Pensez-y comme ça : le test peut parfaitement s’exécuter et quand même retourner un résultat « denied » (refusé). Tout se déroule bien ≠ être approuvé. C’est littéralement juste vérifier si la logique de la politique se comporte correctement avec les données que vous lui avez fournies, rien de plus.
Le vrai événement, c’est en production. C’est là que les opérateurs évaluent l’intention en direct, donnent leur accord avec des signatures BLS, attendent d’avoir assez de signatures pour atteindre le quorum, et ce n’est qu’ensuite que le smart contract vérifie tout et autorise l’exécution de la transaction. La simulation omet TOUTES ces vérifications lourdes.
Donc, en gros, une exécution de test propre est vraiment utile pour repérer les bugs tôt, mais elle ne garantit pas que le vrai système passera le quorum ni qu’il réussira les contrôles onchain par la suite.
Ça fait réfléchir — est-ce qu’une simulation fluide rend les devs plus confiants, de manière positive, ou est-ce qu’elle risque de créer une fausse confiance avant même que les vrais contrôles de sécurité aient lieu ? 👇
#Newt $NEWT @NewtonProtocol
Donc Newton a cette fonctionnalité appelée simulateTask : elle permet, en gros, aux développeurs d’exécuter une politique AVANT de soumettre quoi que ce soit onchain. Ça paraît simple, mais voilà la subtilité : une simulation qui se termine avec succès ne veut PAS dire que la politique a dit « oui ». Ce sont deux choses totalement différentes.
Pensez-y comme ça : le test peut parfaitement s’exécuter et quand même retourner un résultat « denied » (refusé). Tout se déroule bien ≠ être approuvé. C’est littéralement juste vérifier si la logique de la politique se comporte correctement avec les données que vous lui avez fournies, rien de plus.
Le vrai événement, c’est en production. C’est là que les opérateurs évaluent l’intention en direct, donnent leur accord avec des signatures BLS, attendent d’avoir assez de signatures pour atteindre le quorum, et ce n’est qu’ensuite que le smart contract vérifie tout et autorise l’exécution de la transaction. La simulation omet TOUTES ces vérifications lourdes.
Donc, en gros, une exécution de test propre est vraiment utile pour repérer les bugs tôt, mais elle ne garantit pas que le vrai système passera le quorum ni qu’il réussira les contrôles onchain par la suite.
Ça fait réfléchir — est-ce qu’une simulation fluide rend les devs plus confiants, de manière positive, ou est-ce qu’elle risque de créer une fausse confiance avant même que les vrais contrôles de sécurité aient lieu ? 👇
#Newt $NEWT @NewtonProtocol