Fedimint est un logiciel libre et un protocole permettant à un groupe de gardiens, appelé fédération, d’exploiter un système de paiement commun. Il émet de l’e-cash : des jetons numériques destinés à être échangés contre les bitcoins de sa réserve. L’utilisateur détient ces jetons, sans pouvoir signer seul un retrait de la réserve.
Imaginez Anna utilisant un portefeuille relié à une fédération locale, dont Petr accepte l’e-cash dans son café. Chaque café n’a pas besoin de produire une transaction Bitcoin distincte. Les applications manipulent des jetons émis par un atelier monétaire commun, le mint. Les bitcoins restent dans la réserve de la fédération ; ce sont des jetons qu’Anna et Petr se transmettent. Fedimint fournit les composants, les gardiens exploitent une fédération précise et le portefeuille sert d’interface à Anna. Ce sont des éléments différents. Les modules standards gèrent Bitcoin, Lightning Network et l’e-cash ; d’autres peuvent ajouter des services. Chaque fédération a son fonctionnement et ses réserves. Ses jetons ne sont pas automatiquement acceptés par toutes les autres. Même lorsque les gardiens se mettent d’accord, les règles du réseau Bitcoin restent applicables. [1] [2]
La fédération évite de confier les opérations importantes à un seul opérateur. Avec un seuil illustratif 3-of-4, émettre un jeton nécessite trois parts de signature valides parmi quatre gardiens. Un gardien indisponible laisse encore assez de parts, deux non. Mais trois détenteurs coopérant peuvent aussi signer sans l’accord du dernier. Répartir les pouvoirs ne garantit ni honnêteté ni réserves suffisantes. C’est le Counterparty risk : dépendre de personnes ou d’organisations susceptibles de ne pas payer. La signature à seuil de l’e-cash et Multisig, l’autorité partagée sur la réserve Bitcoin, remplissent aussi des rôles différents. Vérifiez les règles de la fédération choisie. [3] [4]
Quand Anna dépose des bitcoins directement sur la blockchain, l’historique public des transactions confirmées, son application fournit une preuve de la sortie concernée, que la fédération doit accepter selon ses règles. Chaque sortie indique un montant et les conditions à remplir pour le dépenser. Au retrait, la fédération construit et signe une transaction Bitcoin depuis sa réserve. Le jeton seul ne donne pas à Anna une clé permettant de retirer sans les autres. C’est une différence essentielle avec Self-Custody, la maîtrise des clés servant à signer ses paiements Bitcoin. Gardiens disponibles, fonds suffisants, frais et confirmations requises restent nécessaires. Un paiement rapide dans le système ne promet donc pas un retrait aussi rapide de n’importe quel montant. [4] [7]
La confidentialité repose sur une Blind Signature, ou signature aveugle. Le logiciel masque mathématiquement le jeton précis, demande sa signature puis retire le masquage. Le résultat est vérifiable, mais le mint ne peut pas relier, à partir du seul jeton, son utilisation ultérieure à une demande d’émission particulière. Pour les lecteurs curieux de technique, la documentation décrit des signatures BLS à seuil sur BLS12-381, pas FROST pour signer les jetons. Le logiciel assemble assez de parts valides en une signature vérifiable. Chaque coupure a sa propre clé : masquer l’identité du jeton ne cache donc pas au mint les valeurs qu’il émet. [3]
Petr peut vérifier qu’un jeton porte une signature valide de la fédération. Cela ne dit pas si quelqu’un l’a déjà utilisé. Les données numériques se copient, et Anna pourrait encore conserver le même jeton. La fédération mémorise donc les identifiants dépensés, appelés nonces, et refuse leur réutilisation. Le destinataire doit réussir un échange contre de nouveaux jetons, plutôt que compter sur la promesse qu’une autre copie restera inutilisée. Signature authentique, jeton non dépensé et réserve suffisante sont trois questions distinctes. En vérifier une ne répond pas aux autres. [3]
Si le café accepte un paiement ordinaire via Lightning Network, une gateway, ou passerelle, peut effectuer le transfert. Elle relie la fédération à Lightning et doit disposer de liquidité, c’est-à-dire de fonds disponibles, des deux côtés. Elle n’est pas nécessairement un gardien. La documentation du module V2 décrit des contrats conditionnant le déblocage des fonds au paiement et une préimage, valeur secrète révélée à la réalisation de la condition. En cas d’échec, le contrat prévoit des voies de remboursement, sans garantir une disponibilité permanente. Une passerelle hors service ou sans liquidité peut bloquer un paiement même si le mint fonctionne. [5]
Une signature aveugle empêche le mint de relier, à partir du seul jeton, son émission à son utilisation ultérieure. Elle n’efface pas toutes les traces. Le destinataire peut savoir qu’Anna a payé ; la passerelle voit les informations nécessaires au paiement Lightning ; un observateur peut comparer horaires ou montants. Les données de connexion peuvent fournir d’autres indices. Demandez toujours ce qui doit rester caché et à qui : gardien, café, passerelle ou observateur du réseau. Des échanges plus privés n’anonymisent pas automatiquement tous les dépôts, retraits et contacts humains. [3] [5]
Perdre son téléphone ne signifie pas forcément perdre ses jetons si l’application prend en charge une restauration correctement configurée. Le mécanisme documenté utilise une valeur secrète principale permettant à l’application de recalculer les données nécessaires, des instantanés chiffrés et l’historique disponible de la fédération. La procédure dépend de l’application et de sa version. Elle ne consiste pas simplement à saisir une Seed Phrase Bitcoin dans n’importe quel portefeuille. Testez donc séparément la restauration du client et un petit retrait avant de dépendre du service. Une sauvegarde récupère des données ; elle ne remplit pas une réserve vide et n’oblige pas les gardiens nécessaires à coopérer. [6] [4]
Pour une vision complète, lisez aussi Cashu, Chaumian eCash, Lightning Network, Multisig, Counterparty risk, Auto-garde. Cette entrée est également citée par Chaumian eCash, Blind Signature, Cashu.