💻 computer science

HFIPay: Privacy-Preserving, Cross-Chain Cryptocurrency Payments to Human-Friendly Identifiers

HFIPay propose une architecture de paiement cryptographique non custodiale qui préserve la vie privée en séparant la résolution d'identifiants humains hors chaîne de l'autorisation de claim on-chain via des preuves à divulgation nulle de connaissance, empêchant ainsi la divulgation des soldes et l'interception des fonds par les relais.

Auteurs originaux : Jian Sheng Wang

Publié 2026-03-31

📖 5 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Jian Sheng Wang

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

🌟 Le Problème : Envoyer de l'argent crypto, c'est comme envoyer un colis sans adresse

Imaginez que vous voulez envoyer un colis à votre ami Paul.

Aujourd'hui (avec la crypto) : Vous devez connaître son adresse exacte, qui ressemble à une suite de chiffres et de lettres incompréhensibles (ex: 0x4a3b...). Si vous faites une faute d'une seule lettre, le colis est perdu pour toujours. De plus, n'importe qui peut voir l'adresse de Paul, vérifier combien d'argent il a, et voir avec qui il a déjà fait des affaires. C'est comme si votre adresse postale était affichée sur une affiche publicitaire géante dans la rue.
Ce qu'on veut (l'expérience bancaire) : Vous voulez juste taper paul@exemple.com ou +33 6 12 34 56 78 et envoyer l'argent. Simple, rapide, et privé.

Le problème ? Si on lie directement l'email à l'adresse crypto, tout le monde peut voir la vie financière de Paul.

🚀 La Solution : HFIPay, le "Secret Agent" des paiements

HFIPay est un système qui permet d'envoyer de la crypto à une adresse email ou un numéro de téléphone, sans révéler qui est le destinataire sur la blockchain (le grand livre public des transactions).

Voici comment ça marche, avec une analogie simple :

1. Le Relais (Le Facteur Secret)

Imaginez un service appelé HFIPay qui agit comme un facteur très discret.

Vous (l'expéditeur) dites au facteur : "Je veux envoyer 100€ à l'email paul@exemple.com".
Le facteur ne regarde pas la blockchain. Il va dans son carnet d'adresses privé (que personne d'autre ne voit) pour trouver où Paul habite vraiment.
Au lieu de vous donner l'adresse de Paul, le facteur crée une boîte aux lettres temporaire et unique (une adresse jetable) pour cette transaction précise.

2. Le "Blindage" (Le Masque)

C'est la partie la plus magique.

Le facteur met l'argent dans cette boîte temporaire.
Sur la blockchain, tout le monde voit : "Quelqu'un a envoyé 100€ dans la boîte temporaire #12345".
Mais personne ne sait pour qui est cette boîte. Ni l'adresse de Paul, ni son nom. C'est comme si le facteur avait mis un masque sur le colis.
Résultat : Même si un espion sait que Paul a un email paul@exemple.com, il ne peut pas relier cet email à la boîte #12345. Paul reste invisible.

3. La Preuve (Le Mot de Passe Zéro-Connaissance)

Comment Paul récupère-t-il l'argent ?

Paul reçoit un message : "Il y a un colis pour vous".
Il ne donne pas son adresse. Au lieu de ça, il utilise une clé secrète mathématique (une preuve à divulgation nulle de connaissance, ou Zero-Knowledge Proof).
Il dit à la blockchain : "Je prouve que je suis le propriétaire de la clé qui ouvre cette boîte temporaire, sans révéler quelle est ma clé ni qui je suis".
La blockchain vérifie la preuve, dit "C'est bon, c'est bien le bon propriétaire", et libère l'argent vers le compte de Paul.

🛡️ Pourquoi c'est plus sûr que les systèmes actuels ?

Le papier décrit deux façons de faire, comme deux niveaux de sécurité :

Le mode "Confiance de base" : Vous faites confiance au facteur (le Relais) pour ne pas voler l'argent ou l'envoyer à un faux Paul. C'est simple, mais vous devez lui faire confiance.
Le mode "Vérifié" (Le plus sécurisé) : Avant même d'envoyer l'argent, le facteur doit vous montrer un sceau officiel qui prouve mathématiquement que la boîte temporaire qu'il a créée est bien liée au vrai Paul.
- Analogie : C'est comme si le facteur vous montrait un passeport scellé par la police avant de vous donner le numéro de la boîte. Vous pouvez vérifier que le passeport est vrai, mais vous ne voyez pas l'adresse de Paul. Si le facteur essaie de tricher en mettant l'argent dans une boîte pour un autre, votre vérification échouera et vous ne paierez pas.

🌍 Et si je veux changer d'appareil ?

Si vous perdez votre téléphone, comment récupérez-vous vos fonds ?
HFIPay utilise un système appelé Va-Dar. Imaginez que votre identité est comme un coffre-fort. Vous avez une clé principale (votre mot de passe) et une "graine" secrète.

Même si vous changez de téléphone, tant que vous avez votre mot de passe, vous pouvez reconstruire votre identité mathématique exacte.
Vous n'avez pas besoin d'un annuaire public pour retrouver votre compte. Le système vous permet de retrouver votre "clé" partout, sans que personne ne sache que c'est vous.

🔄 Et pour les autres blockchains ?

HFIPay est conçu pour fonctionner partout. Si vous envoyez de l'argent depuis la blockchain Ethereum vers Solana (ou même Bitcoin), le système agit comme un pont magique.

L'argent est verrouillé d'un côté, transformé en "jeton temporaire", et débloqué de l'autre côté par la même preuve mathématique.
Pour l'utilisateur, c'est invisible : il envoie à un email, et l'argent arrive sur la blockchain de son choix.

📝 En résumé

HFIPay est comme un service de messagerie ultra-sécurisé pour l'argent numérique :

Facile : On envoie à un email ou un téléphone, pas à une adresse compliquée.
Privé : Personne ne peut voir qui envoie quoi à qui sur la blockchain avant que l'argent ne soit réclamé.
Sûr : Même si le service intermédiaire (le Relais) est compromis, il ne peut pas voler l'argent ni le rediriger, car la blockchain ne libère les fonds que si la preuve mathématique du destinataire est parfaite.

C'est la fin de la complexité des adresses crypto, sans sacrifier la vie privée.

1. Problématique

L'adoption massive des cryptomonnaies est entravée par une barrière fondamentale d'expérience utilisateur (UX) : la nécessité de gérer des adresses hexadécimales opaques, de sélectionner le réseau correct et de posséder des tokens natifs pour les frais de transaction. Bien que l'utilisation d'identifiants humains (e-mails, numéros de téléphone, pseudos réseaux sociaux) résolve ce problème d'UX, les schémas naïfs qui mappent directement ces identifiants vers des adresses blockchain (par exemple via une fonction déterministe comme keccak256(identifier) → address) créent une vulnérabilité critique de confidentialité.

Le risque : Toute tierce partie connaissant l'identifiant d'un utilisateur peut déduire son adresse blockchain, inspecter l'intégralité de son historique de transactions, de ses soldes et de ses relations contreparties. Cela expose particulièrement les personnalités publiques à une surveillance financière totale.

2. Méthodologie et Architecture

HFIPay propose une architecture non-custodiale (non dépositaire) assistée par un relais, qui découple la routage des identifiants, la vérification des devises côté émetteur et l'autorisation de réclamation sur la chaîne. Le protocole repose sur quatre piliers techniques :

A. Séparation des couches de confiance

Le système introduit trois rôles distincts :

L'Émetteur (Sender) : Initie le paiement via un identifiant humain.
Le Récepteur (Recipient) : Contrôle une identité déterministe racine (via Va-Dar) et peut récupérer cette identité sur différents appareils sans registre public.
Le Service Relais (Relay) : Maintient un annuaire privé mappant les identifiants normalisés aux engagements d'identité, mais ne détient jamais les fonds ni ne peut rediriger les paiements une fois l'intention enregistrée.
Couche de Liaison (Binding Layer - Optionnelle) : Dans le mode "Verified-Quote", un tiers atteste de la liaison entre l'identifiant et la clé de liaison du destinataire.

B. Flux du Protocole

Le processus se déroule en plusieurs phases :

Configuration du Récepteur : Le destinataire génère une identité déterministe et dérive des "handles" de liaison (binding handles) par période (epoch). Il enregistre ces données dans le répertoire privé du relais.
Génération de Devis et Vérification (Quote) :
- L'émetteur demande un paiement.
- Le relais résout l'identifiant, génère un intentId aléatoire et calcule une adresse de dépôt déterministe unique.
- Le relais calcule un engagement aveuglé spécifique à l'intention ( $\rho_i$ ) en hachant le handle du destinataire et l'intentId.
- Mode "Verified-Quote" : Le relais fournit à l'émetteur une preuve hors chaîne (ZK) attestant que $\rho_i$ est bien lié à l'engagement de la clé du destinataire attendu, sans révéler l'identité. L'émetteur vérifie cette preuve avant d'envoyer les fonds.
Financement (Funding) : L'émetteur envoie les fonds à l'adresse de dépôt déterministe. Le contrat intelligent enregistre les métadonnées de l'intention (incluant $\rho_i$ ) sur la chaîne.
Réclamation (Claim) : Le destinataire, ayant récupéré son identité, génère une preuve à connaissance nulle (ZK-ACE). Cette preuve démontre qu'il contrôle l'identité déterministe correspondant à l'engagement aveuglé $\rho_i$ enregistré sur la chaîne, autorisant ainsi le transfert des fonds vers une adresse de son choix.

C. Résistance à la censure et Interopérabilité

Cross-Chain (n-Vm) : Le protocole s'étend aux paiements inter-chaînes via une architecture n-Vm (n Virtual Machines). Les fonds sont verrouillés sur la chaîne source, mintés sous forme de tokens enveloppés, et réclamés sur la chaîne de destination via la même relation de preuve ZK.
Récupération Portable : Utilisation de Va-Dar pour permettre la récupération de l'identité sur de nouveaux appareils sans dépendre d'un registre public.

3. Contributions Clés

Conception de Protocole : Définition d'une couche de routage assistée par relais avec des engagements aveuglés spécifiques à chaque intention et des devises vérifiables par l'émetteur, empêchant la substitution de destinataire avant le financement.
Composition d'Autorisation : Intégration de ZK-ACE pour l'autorisation de réclamation et de Va-Dar pour la récupération privée, éliminant le besoin d'un registre d'identifiants public.
Analyse de Confidentialité : Formalisation de deux objectifs de confidentialité :
- Résistance à l'énumération (Enumeration Resistance) : Impossible de déterminer à quel identifiant appartient une intention financée sur la chaîne.
- Déliabilité pré-réclamation (Pre-Claim Unlinkability) : Impossible de relier deux paiements distincts au même destinataire avant la réclamation, même avec des métadonnées publiques identiques.
Modèles de Liaison : Distinction entre un déploiement de base (confiance dans le relais pour la liaison) et un déploiement à "devis vérifiée" (preuve vérifiable par l'émetteur).
Implémentation : Esquisses d'implémentation pour l'EVM (via CREATE2 et contrats proxy) et Solana (via PDA - Program Derived Addresses).

4. Résultats et Propriétés de Sécurité

Confidentialité sur la chaîne : Les observateurs ne voient que des identifiants d'intention aléatoires, des adresses dérivées et des engagements aveuglés. L'identifiant humain (e-mail, etc.) n'apparaît jamais sur la chaîne.
Intégrité du paiement : Une fois l'intention financée et l'engagement aveuglé enregistré, le relais ne peut pas rediriger les fonds. Seul le destinataire possédant la clé privée de l'identité déterministe peut prouver sa légitimité via ZK.
Résistance aux attaques :
- L'attaque par substitution de destinataire est bloquée dans le mode "Verified-Quote" grâce à la vérification hors chaîne par l'émetteur.
- La compromission de la base de données du relais permet de reconstituer le graphe des transactions passées (comme dans les banques traditionnelles), mais ne permet pas de voler les fonds déjà engagés sur la chaîne.
Limites : La confidentialité post-réclamation dépend de la réutilisation des adresses de destination ou des engagements d'identité publics. Le protocole ne protège pas contre l'analyse de trafic réseau (IP) ni contre la compromission de l'appareil du destinataire.

5. Signification et Impact

HFIPay représente une avancée significative vers l'adoption grand public des cryptomonnaies en éliminant la friction de l'UX (pas d'adresses hexadécimales, pas de gestion de frais de gaz) tout en préservant la confidentialité bien mieux que les systèmes centralisés actuels (qui sont des "boîtes noires" de confiance) ou que les systèmes décentralisés naïfs (qui exposent les graphes de transactions).

En déplaçant la vérification de l'identité vers des preuves cryptographiques (ZK) et en utilisant un modèle de confiance hybride (relais pour le routage, chaîne pour l'autorisation), HFIPay offre :

Une expérience utilisateur fluide ("Envoyer à un e-mail").
Une traçabilité légale possible via les processus juridiques auprès du relais et des fournisseurs d'identité (contrairement aux mixers comme Tornado Cash).
Une interopérabilité native entre différentes blockchains sans nécessiter de ponts de confiance externes complexes pour la logique de réclamation.

Ce travail pose les bases d'une infrastructure de paiement cryptographique qui est à la fois conviviale, privée et vérifiable, comblant le fossé entre l'infrastructure financière traditionnelle et la technologie blockchain.