#newt L’année dernière, lorsque j’ai configuré la quantification, une erreur de précision a rendu le stop-loss sur grille inefficace, et le compte a été violemment touché en un instant. Cela m’a complètement réveillé : dès lors qu’un agent on-chain implique une cession de permissions, même une infime faille logique peut être extrêmement fatale. Quand @NewtonProtocol a lancé le Newton Mainnet Beta en vantant une gestion des risques par cryptographie, j’ai choisi d’ignorer les discours marketing et de m’attaquer directement à la logique robuste de son environnement d’exécution fiable et de l’intégration des preuves à connaissance nulle.
Objectivement, ce zkPermissions cible précisément les douleurs du secteur. L’hébergement API classique traite les actifs comme un “boîte noire” aveugle ; ce protocole, lui, est écrit en langage Rego comme un moteur de règles qui force la vérification des risques à s’exécuter hors chaîne dans une isolation au niveau matériel. Avant toute diffusion d’une transaction, l’exécution doit passer par une correspondance de règles dans un espace clos ; la chaîne ne fait ensuite que la vérification en zéro-connaissance. Au niveau cryptographique, cela réduit le risque de dépassement malveillant de privilèges à un niveau très faible.
Mais après l’avoir simulé en pratique, j’ai décelé une faille cognitive dangereuse. Tout le monde croit qu’un agent validé par ZK est absolument sûr, mais on oublie que la cryptographie ne peut pas détecter si les instructions d’entrée correspondent réellement à vos intentions. Par exemple, lors de la configuration automatique des positions, si l’on se trompe de la précision des jetons : au lieu de n’utiliser qu’un petit montant pour des tests, le contrat sous-jacent ajuste selon la précision maximale et mobilise alors les actifs $ETH ou $BTC que vous déteniez en position importante. Le système passe quand même au vert et exécute frénétiquement, si bien qu’à la fin, votre principal est épuisé instantanément par un arbitrage, le tout via un chemin parfaitement conforme.
Dans ce contexte impitoyable, il est impossible de recouvrer une perte aussi importante causée uniquement par une erreur d’entrée. À l’heure actuelle, dans l’ensemble du $NEWT en boucle fermée, je n’ai encore vu aucun outil de configuration visuelle permettant de réaliser un audit de prévention d’erreurs secondaire. Cette technologie construit une ossature solide pour le mécanisme de confiance des agents, mais tant que le seuil de sécurité reste abaissé, des paramètres complexes demeurent un risque pour le grand public. Concernant l’évolution ultérieure de #Newt , mon avis est que le socle logique est solide, mais que l’accompagnement côté interface n’est pas complet : rester rationnel et observer en conditions réelles, c’est pour l’instant la meilleure solution si l’on veut favoriser la solidité des fonds.
Objectivement, ce zkPermissions cible précisément les douleurs du secteur. L’hébergement API classique traite les actifs comme un “boîte noire” aveugle ; ce protocole, lui, est écrit en langage Rego comme un moteur de règles qui force la vérification des risques à s’exécuter hors chaîne dans une isolation au niveau matériel. Avant toute diffusion d’une transaction, l’exécution doit passer par une correspondance de règles dans un espace clos ; la chaîne ne fait ensuite que la vérification en zéro-connaissance. Au niveau cryptographique, cela réduit le risque de dépassement malveillant de privilèges à un niveau très faible.
Mais après l’avoir simulé en pratique, j’ai décelé une faille cognitive dangereuse. Tout le monde croit qu’un agent validé par ZK est absolument sûr, mais on oublie que la cryptographie ne peut pas détecter si les instructions d’entrée correspondent réellement à vos intentions. Par exemple, lors de la configuration automatique des positions, si l’on se trompe de la précision des jetons : au lieu de n’utiliser qu’un petit montant pour des tests, le contrat sous-jacent ajuste selon la précision maximale et mobilise alors les actifs $ETH ou $BTC que vous déteniez en position importante. Le système passe quand même au vert et exécute frénétiquement, si bien qu’à la fin, votre principal est épuisé instantanément par un arbitrage, le tout via un chemin parfaitement conforme.
Dans ce contexte impitoyable, il est impossible de recouvrer une perte aussi importante causée uniquement par une erreur d’entrée. À l’heure actuelle, dans l’ensemble du $NEWT en boucle fermée, je n’ai encore vu aucun outil de configuration visuelle permettant de réaliser un audit de prévention d’erreurs secondaire. Cette technologie construit une ossature solide pour le mécanisme de confiance des agents, mais tant que le seuil de sécurité reste abaissé, des paramètres complexes demeurent un risque pour le grand public. Concernant l’évolution ultérieure de #Newt , mon avis est que le socle logique est solide, mais que l’accompagnement côté interface n’est pas complet : rester rationnel et observer en conditions réelles, c’est pour l’instant la meilleure solution si l’on veut favoriser la solidité des fonds.
