Carrot : les nouvelles adresses
Le nouveau schéma d’adresses et de clés qui arrive avec FCMP++
Carrot (Cryptonote Address on Rerandomizable-RingCT-Output Transactions) est le schéma d’adresses et de sorties à usage unique de l’ère FCMP++. Il conserve le format d’adresse existant mais introduit une hiérarchie de clés plus souple (des clés distinctes pour « voir les entrées », « tout voir », « générer les key images », « prouver l’autorisation de dépense »), ferme l’attaque Janus et accélère le balayage.
Pourquoi changer ce qui fonctionne
Une sortie FCMP++ a la forme O = x·G + y·T, et les anciennes formules d’adresses à usage unique n’en tiennent pas compte. Puisqu’il faut de toute façon changer, Carrot corrige de vieux désagréments de CryptoNote :
- Les portefeuilles en lecture seule ne voient pas les dépenses. Il fallait importer les key images.
- L’attaque Janus sur les sous-adresses : un expéditeur pouvait tester si deux sous-adresses étaient liées.
- Le « burning bug » : on pouvait envoyer deux sorties avec la même clé à usage unique, et le destinataire ne pouvait en dépenser qu’une.
- Un balayage lent — opérations Ed25519 et view tag d’un octet.
Hiérarchie des clés
| Clé | Permet |
|---|---|
k_vi — view-incoming | de trouver les paiements entrants (comme l’ancienne clé de visualisation) |
k_gi — generate-image | de calculer les key images → voir quelles sorties sont dépensées |
s_vb — view-balance | de voir tous les paiements entrants et sortants, le solde exact ; de reconnaître sa propre monnaie rendue |
s_ga — generate-address | de créer des sous-adresses (par exemple sur le serveur d’une boutique) sans le droit de voir les paiements |
k_ps — prove-spend | la seule clé vraiment nécessaire pour dépenser ; peut résider sur un portefeuille matériel |
Compatibilité avec les anciens portefeuilles
Un portefeuille existant se transpose dans Carrot ainsi : k_vi = a, k_gi = b, k_ps = 0. On a alors K_s = b·G = B, et les anciennes adresses restent identiques — on peut y envoyer des fonds et les balayer. Les nouvelles possibilités (une clé view-balance distincte, etc.) sont réservées aux portefeuilles créés selon le nouveau schéma.
Ce qui change encore dans les sorties
- Échange de clés sur X25519 (une courbe de Montgomery au lieu d’Edwards) — un balayage plus rapide.
- View tag de 3 octets au lieu de 1 : 65 536 fois moins de faux positifs.
- Protection contre Janus : une « ancre » est ajoutée à la sortie pour que le destinataire puisse vérifier que l’expéditeur connaissait l’adresse complète au lieu de l’avoir collée à partir de morceaux de différentes sous-adresses.
- Protection contre le burning bug : la clé à usage unique est liée à la première key image de la transaction, si bien que deux sorties identiques ne peuvent pas exister.
- Sorties internes (envoi à soi-même) : la monnaie rendue est construite via
s_vb, et un portefeuille doté de la clé view-balance la reconnaît de façon fiable.
La spécification de Carrot est publiée dans le dépôt jeffro256/carrot, celle de FCMP++ dans les articles de kayabaNerve et le dépôt monero-oxide. Ce site les paraphrase ; en cas de désaccord, fiez-vous à la spécification.