- Stellar publie une preuve de concept open source pour les paiements privés utilisant les preuves zk Groth16 pour les dépôts, transferts et retraits privés.
- Stellar ajoute l’adhésion ASP et les arbres Merkle de non-adhésion, permettant aux pools d’appliquer des règles d’autorisation/interdiction sans révéler les détails des transactions.
Stellar a publié une preuve de concept open source pour les paiements privés sur son réseau. Le prototype permet les dépôts, transferts et retraits de tokens tout en gardant les montants et les liens entre expéditeur et destinataire hors de la vue du public.
Le flux de paiements privés utilise des preuves à divulgation nulle de connaissance Groth16 construites avec des circuits Circom. La génération de preuves s’effectue côté client via WebAssembly, permettant aux utilisateurs de créer des preuves dans un navigateur web. Le système fonctionne sur les smart contracts Soroban et utilise un modèle de pool qui suit les engagements, similaire aux notes UTXO.
Stellar Private Payments (SPP) est désormais open source !
Cela signifie des dépôts, transferts et retraits privés sur Stellar avec des preuves ZK et des garde-fous configurables.
Privacy Builders → Commencez à construire !https://t.co/1nGgBWyZTy
— Stellar (@StellarOrg) 13 février 2026
Les utilisateurs déposent des tokens dans le pool et reçoivent un nouvel engagement. Aucune note précédente n’est dépensée lors d’un dépôt. Les transferts dépensent des engagements existants et en créent de nouveaux liés à une nouvelle clé publique, sans exposer les détails du transfert. Les retraits dépensent des notes et libèrent des tokens du pool. Une option « transact » est disponible pour les utilisateurs souhaitant créer des transactions personnalisées dans le respect des mêmes règles de paiement privé.
Contrôles ASP et confidentialité ZK de Stellar
Le prototype de paiements privés de Stellar introduit une sécurité administrative via les Association Set Providers (ASP). Les ASP gèrent deux systèmes d’arbres Merkle qui permettent des vérifications de politiques sans révéler l’activité des utilisateurs. Un arbre suit les clés publiques approuvées via une structure d’adhésion, tandis que l’autre suit les clés publiques bloquées via une structure de non-adhésion.
Grâce à ces arbres, il est possible de démontrer qu’une transaction respecte les normes réglementaires et évite les ensembles bloqués, tout en gardant les informations de paiement confidentielles.
Le bundle de démonstration se compose du frontend, des circuits et des smart contracts Soroban. L’interface utilisateur est construite sur le frontend, qui inclut également une page d’administration ASP permettant d’ajouter des clés publiques à l’arbre d’adhésion et de gérer une liste d’exclusion. Les insertions de clés doivent être signées par un compte administrateur ASP, même si l’interface peut dériver des clés pour n’importe quel compte à des fins de test.
La logique du circuit vérifie plusieurs conditions dans une seule preuve. Elle empêche la double dépense et valide les preuves Merkle pour les engagements. Elle impose également la validité des engagements de sortie et la conservation du solde, où les entrées sont égales aux sorties plus tout montant public. Les éléments on-chain impliquent un contrat de pool où les dépôts, transferts et retraits sont effectués, et un contrat de vérification Groth16 à partir duquel la preuve est récupérée.
Stellar a également élargi l’accessibilité des portefeuilles dans les marchés émergents en s’associant à TopNod pour lancer un portefeuille non-custodial en Asie, en Afrique et en Amérique latine. Comme nous l’avons couvert, l’intégration repose sur le partage de clés et la technologie Trusted Execution Environment pour éliminer les phrases de récupération et se concentre sur les stablecoins et les actifs réels tokenisés.
Au moment du rapport, Stellar (XLM) se négociait à
