#dusk $DUSK @Dusk
La documentation des transactions Moonlight comporte une section que la plupart des gens traitent comme un simple texte « passe-partout » — la liste complète des propriétés de sécurité que le livre blanc nomme officiellement. Elles sont au nombre de quatre, et la dernière est plus intéressante qu’elle n’en a l’air.
Propriétés de sécurité de Moonlight : l’inaltérabilité (garantie par des signatures numériques), la prévention de la double dépense (le réseau vérifie les soldes avant d’accepter), la non-modifiabilité (la signature couvre le hachage de tous les champs de la transaction ; toute modification la rend donc invalide), et la prévention des attaques par rejeu (garantie par le nonce).
Cela vaut la peine de réfléchir à ce que fait réellement le nonce ici.
Une attaque par rejeu, c’est lorsqu’une personne récupère une transaction signée valide et la renvoie. La signature est authentique — c’est bien vous qui l’avez signée — mais vous n’avez pas autorisé cet envoi précis. Sans mécanisme de prévention du rejeu, une transaction valide envoyée une fois pourrait être retransmise indéfiniment par quiconque l’a interceptée.
Le nonce résout ce problème. Chaque compte Moonlight dispose d’un nonce courant — un compteur qui s’incrémente à chaque transaction acceptée. Lorsque vous envoyez une transaction, le champ nonce doit être exactement current_nonce + 1. Le réseau rejette toute tentative où ce contrôle échoue. Une fois acceptée, le nonce du compte s’incrémente, de sorte que la même transaction ne puisse plus être renvoyée.
Je ne dis pas que c’est inhabituel. Toute chaîne sérieuse basée sur des comptes utilise des nonces pour remplir exactement ce rôle. Ethereum fait pareil.
Je ne dis pas non plus que c’est trivial. Le nonce accomplit une tâche distincte de la signature — la signature prouve l’autorisation, le nonce prouve que cette instance précise de la transaction est nouvelle. Il faut les deux, et ils couvrent des vecteurs d’attaque différents.
Ce que je n’ai pas encore déterminé, c’est si les nonces de Moonlight sont globaux au compte ou propres à chaque contrat — autrement dit, si l’appel d’un contrat et l’envoi direct d’un transfert depuis le même compte partagent un seul compteur de nonce, ou si chaque type d’interaction possède sa propre séquence. @Dusk
$DUSK #dusk
La documentation des transactions Moonlight comporte une section que la plupart des gens traitent comme un simple texte « passe-partout » — la liste complète des propriétés de sécurité que le livre blanc nomme officiellement. Elles sont au nombre de quatre, et la dernière est plus intéressante qu’elle n’en a l’air.
Propriétés de sécurité de Moonlight : l’inaltérabilité (garantie par des signatures numériques), la prévention de la double dépense (le réseau vérifie les soldes avant d’accepter), la non-modifiabilité (la signature couvre le hachage de tous les champs de la transaction ; toute modification la rend donc invalide), et la prévention des attaques par rejeu (garantie par le nonce).
Cela vaut la peine de réfléchir à ce que fait réellement le nonce ici.
Une attaque par rejeu, c’est lorsqu’une personne récupère une transaction signée valide et la renvoie. La signature est authentique — c’est bien vous qui l’avez signée — mais vous n’avez pas autorisé cet envoi précis. Sans mécanisme de prévention du rejeu, une transaction valide envoyée une fois pourrait être retransmise indéfiniment par quiconque l’a interceptée.
Le nonce résout ce problème. Chaque compte Moonlight dispose d’un nonce courant — un compteur qui s’incrémente à chaque transaction acceptée. Lorsque vous envoyez une transaction, le champ nonce doit être exactement current_nonce + 1. Le réseau rejette toute tentative où ce contrôle échoue. Une fois acceptée, le nonce du compte s’incrémente, de sorte que la même transaction ne puisse plus être renvoyée.
Je ne dis pas que c’est inhabituel. Toute chaîne sérieuse basée sur des comptes utilise des nonces pour remplir exactement ce rôle. Ethereum fait pareil.
Je ne dis pas non plus que c’est trivial. Le nonce accomplit une tâche distincte de la signature — la signature prouve l’autorisation, le nonce prouve que cette instance précise de la transaction est nouvelle. Il faut les deux, et ils couvrent des vecteurs d’attaque différents.
Ce que je n’ai pas encore déterminé, c’est si les nonces de Moonlight sont globaux au compte ou propres à chaque contrat — autrement dit, si l’appel d’un contrat et l’envoi direct d’un transfert depuis le même compte partagent un seul compteur de nonce, ou si chaque type d’interaction possède sa propre séquence. @Dusk
$DUSK #dusk
