velve

Je reviens sans cesse à cette question parce qu’elle met le doigt sur la vraie différence entre ces deux conceptions : qui a réellement le droit de façonner la transaction avant sa mise en ligne ?
Avec NEWT, la réponse me paraît assez claire. Le cœur de Newton, c’est que les politiques sont appliquées avant que la transaction ne soit finalisée. Le projet se présente comme une couche d’autorisation pour les transactions onchain, et sa documentation le décrit comme une « politique programmable » qui est vérifiée avant le règlement, ainsi que comme un système qui applique des politiques à chaque transaction avant qu’elle ne s’exécute. C’est un modèle mental très différent de l’approche habituelle « envoyer la transaction et espérer que les règles seront respectées plus tard ».

J’ai passé trop d’années à voir des gens essayer d’automatiser l’erreur humaine, pour finalement comprendre que nous automatisons le plus souvent seulement l’ampleur du désastre. Au début des cryptomonnaies, la formule « le code, c’est la loi » était un mensonge rassurant. C’était rigide et stupide, mais au moins on pouvait lire le fichier Solidity et savoir exactement comment il échouerait. Désormais, nous nous dirigeons vers un monde où ce sont des modèles qui font loi, et franchement, ce changement me met extrêmement mal à l’aise.
Nous n’écrivons pas seulement des instructions ; nous déléguons désormais une forme d’autonomie. Nous finançons des portefeuilles, nous les confions à des scripts autonomes, et nous espérons que leurs pondérations statistiques correspondent à nos intentions réelles. Mais il existe une énorme différence entre générer une idée de transaction logique et l’exécuter de manière responsable dans un marché en direct, hostile. Les logiciels traditionnels fonctionnent de manière déterministe. L’IA agit de façon probabiliste. Si un modèle rencontre un état de marché qu’il n’a jamais vu auparavant, sa décision « intelligente » peut ressembler à un cauchemar halluciné on-chain. S’il vide sa réserve de liquidités à cause d’une mauvaise entrée, la transaction reste pourtant valablement authentifiée sur le plan cryptographique. La chaîne ne se soucie pas de l’intention du modèle ; elle ne s’intéresse qu’à la signature.

Le risque lié à la confidentialité peut commencer après que l’autorisation a déjà fait son travail.
Imaginez qu’une trésorerie institutionnelle approuve un transfert vers un contrepartie vérifiée.
Avant le règlement, l’action est vérifiée par rapport à la politique active. La destination est éligible. Le montant reste à l’intérieur de la limite autorisée. Le processus d’autorisation se termine et un enregistrement signé est créé.
À cet instant, les preuves sont utiles.
L’application doit savoir que le transfert a été autorisé.
La trésorerie peut avoir besoin d’un enregistrement pour une révision interne.