Il y a deux jours, une affaire a circulé dans la communauté. Ça donne des frissons. Un certain utilisateur n’a pourtant signé qu’un virement de 500 U : mais sur la chaîne, c’est 50 000 U qui sont sortis. Ce n’est qu’à la fin qu’ils ont reconstitué toute la chaîne—le front-end avec lequel il interagissait avait été trafiqué. L’écran affichait 500 U, tandis que les données réellement signées indiquaient 50 000 U. La clé privée, c’était lui qui la contrôlait ; la signature, il l’a confirmée de sa propre main. Pourtant, il ne savait même pas ce qu’il signait.
Cette histoire m’a ramené à un concept qui revient dans le livre blanc @NewtonProtocol , mais que peu de gens approfondissent : l’intention de transaction. Le schéma du processus d’autorisation de la section 5.3 l’explique très clairement : l’utilisateur ne soumet pas une « signature de transaction brute », mais une « intention de transaction ». Le moteur de stratégie examine d’abord si cette intention est conforme. Une fois validée, il lui associe la signature agrégée, puis l’envoie pour exécution. À première vue, n’est-ce pas juste une signature en deux étapes ? Mais en y réfléchissant, j’ai l’impression qu’en dessous se cache un changement plus profond : on force l’alignement entre « ce que vous signez » et « ce que vous avez l’intention de signer ».
Les portefeuilles traditionnels ont une zone aveugle qu’on ne peut pas vraiment éviter. La signature avec la clé privée, c’est un problème mathématique ; l’intention de transaction, c’est un problème sémantique. Les mathématiques peuvent garantir que la signature est bien réelle, mais elles ne peuvent pas garantir que l’acte que vous avez en tête corresponde à l’acte qui s’exécute réellement en chaîne. La solution de Newton consiste à transformer l’intention en données structurées, pour que le moteur de stratégie puisse la vérifier de manière indépendante. Ce que reçoivent les opérateurs n’est pas une suite de charabia hexadécimal, mais une description lisible immédiatement du type « qui doit transférer combien à qui ». Ils doivent d’abord vérifier si cette description claire est conforme, puis seulement après, apposer leur propre signature BLS pour la certifier. #Newt
Mais cela fait aussi apparaître une nouvelle antinomie. Si l’intention elle-même est générée à partir d’un front-end compromis—l’utilisateur croit saisir 500 U, tandis que le front-end modifie secrètement en 50 000 U avant de soumettre l’intention—alors l’opérateur reçoit une intention de transfert de 50 000 U « qui a l’air conforme ». Ils la vérifient : conforme. Ils la signent : exécution. $NEWT Le staking des tokens peut empêcher que la stratégie soit altérée, et il peut empêcher les opérateurs de paresser. Mais il ne peut pas combler le fossé entre « l’idée dans votre tête » et « ce qui s’exécute réellement sur l’écran et finalement en chaîne ».
C’est peut-être la couche la plus profonde de l’aveuglement dans l’ensemble de la couche d’autorisation. DYOR.
Cette histoire m’a ramené à un concept qui revient dans le livre blanc @NewtonProtocol , mais que peu de gens approfondissent : l’intention de transaction. Le schéma du processus d’autorisation de la section 5.3 l’explique très clairement : l’utilisateur ne soumet pas une « signature de transaction brute », mais une « intention de transaction ». Le moteur de stratégie examine d’abord si cette intention est conforme. Une fois validée, il lui associe la signature agrégée, puis l’envoie pour exécution. À première vue, n’est-ce pas juste une signature en deux étapes ? Mais en y réfléchissant, j’ai l’impression qu’en dessous se cache un changement plus profond : on force l’alignement entre « ce que vous signez » et « ce que vous avez l’intention de signer ».
Les portefeuilles traditionnels ont une zone aveugle qu’on ne peut pas vraiment éviter. La signature avec la clé privée, c’est un problème mathématique ; l’intention de transaction, c’est un problème sémantique. Les mathématiques peuvent garantir que la signature est bien réelle, mais elles ne peuvent pas garantir que l’acte que vous avez en tête corresponde à l’acte qui s’exécute réellement en chaîne. La solution de Newton consiste à transformer l’intention en données structurées, pour que le moteur de stratégie puisse la vérifier de manière indépendante. Ce que reçoivent les opérateurs n’est pas une suite de charabia hexadécimal, mais une description lisible immédiatement du type « qui doit transférer combien à qui ». Ils doivent d’abord vérifier si cette description claire est conforme, puis seulement après, apposer leur propre signature BLS pour la certifier. #Newt
Mais cela fait aussi apparaître une nouvelle antinomie. Si l’intention elle-même est générée à partir d’un front-end compromis—l’utilisateur croit saisir 500 U, tandis que le front-end modifie secrètement en 50 000 U avant de soumettre l’intention—alors l’opérateur reçoit une intention de transfert de 50 000 U « qui a l’air conforme ». Ils la vérifient : conforme. Ils la signent : exécution. $NEWT Le staking des tokens peut empêcher que la stratégie soit altérée, et il peut empêcher les opérateurs de paresser. Mais il ne peut pas combler le fossé entre « l’idée dans votre tête » et « ce qui s’exécute réellement sur l’écran et finalement en chaîne ».
C’est peut-être la couche la plus profonde de l’aveuglement dans l’ensemble de la couche d’autorisation. DYOR.