Lightning : pourquoi un portefeuille on-chain ne peut pas simplement l’ajouter
C’est la question la plus fréquente au sujet de Sparrow, et elle mérite mieux qu’un refus d’un seul mot. Lightning n’est pas une fonction qu’un portefeuille Bitcoin peut activer. C’est un système différent qui se règle sur Bitcoin, et le faire tourner signifie exploiter de l’infrastructure.
Ce qu’est réellement Lightning
Un paiement Lightning ne touche pas la blockchain. Deux parties verrouillent des fonds dans un canal deux-sur-deux au moyen d’une transaction on-chain, puis elles mettent à jour le solde entre elles, en privé, autant de fois qu’elles le souhaitent, en échangeant des états signés. Les paiements se routent le long de chaînes de canaux : vous pouvez donc payer quelqu’un avec qui vous n’avez aucun canal direct. Seules l’ouverture et la fermeture du canal sont des événements on-chain. C’est ce qui rend le système rapide et peu coûteux, et c’est aussi ce qui le rend structurellement différent de tout ce que fait Sparrow.
Pourquoi « il suffit d’ajouter Lightning » n’est pas une petite demande
Quatre obstacles s’y opposent, et aucun n’est une question d’effort.
- Un canal n’est pas une adresse. L’argent placé dans un canal n’est pas un UTXO que vous dépensez à volonté : c’est une position détenue conjointement avec une contrepartie qui doit coopérer, ou être forcée on-chain par une procédure de fermeture à verrou temporel.
- La liquidité se gère. Vous ne pouvez recevoir que ce que vos partenaires de canal peuvent vous envoyer. La liquidité entrante est une préoccupation opérationnelle permanente, souvent payante, et elle n’a aucun équivalent dans les portefeuilles on-chain.
- Le système veut rester allumé. Un nœud hors ligne ne peut pas router, ne reçoit pas de façon fiable et ne surveille pas la chaîne au cas où une contrepartie fermerait un canal sur un état ancien. Un portefeuille de bureau que vous ouvrez deux fois par semaine n’a pas la bonne forme pour ce travail.
- Les sauvegardes n’ont rien d’une phrase de récupération. C’est le point qui piège tout le monde. On-chain, douze mots écrits sur papier restituent tout, pour toujours. Dans Lightning, votre phrase ne suffit pas : l’état du canal change à chaque paiement, et restaurer une sauvegarde périmée peut vous coûter le solde du canal. Il faut une sauvegarde d’état continue, avec une sémantique complètement différente.
Greffer cela sur un portefeuille dont toute la proposition de valeur est une construction on-chain délibérée et vérifiable dégraderait les deux moitiés. La réponse du projet consiste à traiter une seule couche, correctement.
L’installation réaliste en 2026
En pratique, les gens font tourner les deux avec une division du travail claire. Le logiciel de nœud Lightning — auto-hébergé sur une petite machine toujours allumée, ou un portefeuille Lightning mobile si vous acceptez les compromis — détient un solde de dépense modeste pour des paiements instantanés à frais réduits. Sparrow détient la réserve on-chain qui se trouve en dessous : l’épargne, le stockage à froid, le quorum multisig, les pièces que vous ne dépenserez pas ce mois-ci.
Les deux se touchent en exactement deux points. Quand vous financez un canal, vous effectuez un paiement on-chain ordinaire vers une sortie deux-sur-deux, et Sparrow est un bon endroit d’où l’émettre : vous choisissez les pièces employées et vous voyez les frais avant de signer. Quand un canal se ferme, les fonds reviennent on-chain sur une adresse que vous contrôlez, et Sparrow est un bon endroit pour les recevoir. Voyez-y un compte courant et un coffre, non un portefeuille auquel il manquerait un onglet.