View tags
Un octet qui accélère nettement le balayage du portefeuille
Depuis août 2022 (hard fork v15), chaque sortie porte 1 octet — le view tag (étiquette de visualisation) = le premier octet de Keccak("view_tag" ‖ 8rA ‖ i). Le portefeuille compare d’abord cet octet et ne fait la vérification coûteuse qu’en cas de correspondance (≈1 fois sur 256). Le balayage devient environ 40 % plus rapide.
Le problème
Pour vérifier si une sortie est à lui, le portefeuille effectue deux opérations coûteuses : 8·a·R (une par transaction) et Hs(…)·G + B (une pour chaque sortie). Cette dernière — une multiplication par le point de base plus une addition — représente une part notable du temps de synchronisation. Et dans 99,99 % des cas, la réponse est « pas à nous ».
La solution
L’expéditeur place cet octet à côté de la sortie. Le destinataire, après avoir calculé le secret partagé 8·a·R, calcule le même hachage (peu coûteux : un hachage, pas une opération sur la courbe) et compare l’octet. Pas de correspondance — la sortie n’est certainement pas à nous, on s’arrête. Correspondance — on fait la vérification complète (dans 1 cas sur 256, ce sera une coïncidence).
Le coût
Un octet supplémentaire par sortie. La confidentialité n’en souffre presque pas : le view tag est calculé à partir du secret partagé connu seulement de l’expéditeur et du destinataire, donc pour les autres c’est un octet aléatoire. La seule fuite concerne quelqu’un qui connaît la clé de visualisation (par exemple un serveur de portefeuille léger) : le hachage lui permet d’écarter les sorties des autres — mais il pourrait le faire de toute façon.
Dans Carrot, le view tag passe à 3 octets et l’échange de clés passe à X25519 — le balayage devient encore plus rapide et les faux positifs environ 65 000 fois plus rares.