Paiements instantanés et garantis à 100% sans tiers de confiance : Les Lightning Network

J’ai enfin pris le temps de m’intéresser sérieusement aux Lightning Network (qu’on notera LN) et c’est beaucoup plus puissant que ce que je pensais !

Les avantages

  • Paiement instantanés validés définitivement en quelques secondes.
  • Trustless, pas de tiers de confiance. On peut passer par des intermédiaires dans certains cas (voir plus bas) mais pas besoin de leur faire confiance, on est assuré à 100% qu’ils ne peuvent pas nous voler. C’est le point le plus important, ce n’est pas le cas de g1sms par exemple (il faut faire confiance au tiers gérant le serveur g1sms de référence).
  • Permet des paiements en mode hors-ligne entre 2 personnes qui se connaissent au préalable.
  • Allège la blockchain : les paiement instantanés se font hors-blockchain, c’est ce qui permet l’instantanéité et ça permet aussi d’alléger fortement la blockchain (moins de transactions dans les blocs).

Le principe général

Pour utiliser les Lightning Network, l’utilisateur doit ouvrir un « chanel » avec d’autres comptes (personnes ou/et robots), qu’on nommera ses « contacts ». Il peut alors réaliser des échanges instantanés avec tous ses contacts mais également avec n’importe-quel entité qui a au moins un contact commun avec lui.

Les comptes et les chanel forment un graphe, un peu comme notre toile de confiance, sauf que les liens sont bidirectionnels. Pour faire l’analogie c’est comme si vous pouviez échanger instantanément avec n’importe-quel entité se trouvant à 2 pas de vous.

J’utilise le terme « entité » et non personne car les chanels LN peuvent être utilisées indifféremment avec des simples portefeuilles ou des comptes membres.

2 types de paiement

Le paiement direct

Nécessite que les 2 personnes qui échangent se connaissent au préalable.
Ce paiement peut s’effectuer hors-ligne par échange de qrcode (ou échange de fichiers par n’importe-quel canal).
Il peut également s’effectuer en ligne pour s’échanger les données par le réseau (on peut alors passer par un serveur pour faire l’intermédiaire, mais ce dernier ne réalise aucun traitement, c’est juste un messagé).

Le paiement relais

Nécessite une connexion à internet lors du paiement. Les 2 personnes qui souhaitent échanger vont passer par un intermédiaire (le plus souvent un robot qui tournent 24/7 sur un serveur) mais sans avoir besoin de faire confiance en cet intermédiaire car il lui sera mathématiquement impossible de détourner le transfert.
On peut voir ces robots intermédiaires comme des pod Diaspora ou Mastodon par exemple. Il suffit que les 2 personnes aient au moins un compte sur le même pod pour réaliser un paiement instantanné.

Dans le cas où le serveur relais n’est pas honnête, les 2 personnes qui souhaitaient échanger sont garanties à 100% de pouvoir récupérer leur monnaie d’avant l’échange. Il leur suffit alors de blacklister ce serveur et d’en utiliser un autre. Ou de créer un channel entre eux pour ne plus avoir besoin d’intermédiaire.

Trois remarques très importantes :

  • Les 2 personnes qui échangent ne donnent pas leur clé privée à l’intermédiaire, il n’en a pas besoin.
  • L’utilisation d’un intermédiaire n’est pas nécessaire, c’est juste plus pratique car cela permet de ne pas ouvrir un nouveau channel chaque fois qu’on échange avec une nouvelle personne.
  • Chaque partie peut décider unilatéralement de récupérer ses fonds à tout moment, et n’a pas besoin de l’accord des autres.

Dans la pratique

L’utilisateur qui souhaite réaliser des paiements instantanés devra installer et utiliser un client spécial (nom à trouver, type « light transfert »). Depuis ce client spécial il pourra :

  1. Demander à ouvrir un channel avec un nouveau contact (une clé publique quelconque)
  2. Envoyer un paiement instantané a un de ses contacts.
  3. Envoyer un paiement relais (il suffirait de scanner ou saisir la clé publique du destinataire et le client donnera la liste des intermédiaires possibles, la liste des « pod » en commun).
  4. Fermer un channel (avec une personne physique ou un pod), ce qui lui permet de récupérer les fonds.

Pour ouvrir un channel il faut injecter de la monnaie dedans (montant à choisir). La monnaie injectée reste ensuite dans le réseau LN (elle peut être récupérée a tout moment).
Le réseau LN fonctionne un peu comme une monnaie complémentaire mais garantie à 100% sur la monnaie de base via des preuves cryptographiques et surtout ce réseau fonctionne de façon totalement décentralisée ET trustless (pas besoin de faire confiance à qui que ce soit).

Pour que la Ğ1 en bénéficie

Il y a 3 choses à faire :

  1. Modifier le protocole DUBP pour le rendre compatible avec les Lightning Network
  2. Développer les « pod LN »
  3. Développer le client spécial (au moins sous version app mobile, on peut aussi avoir une version desktop bien sur, on peut trouver un nom sympa du style « lightĞ1 » pour « La Ğ1 a la vitesse de la lumière »).

Autant dire qu’il y a du boulot :yum:
La partie pod LN pourrait me tenter (ça pourrait être un module optionnel de Dunitrust), j’ouvrirai bien un crowfunding pour ça.
Pour la partie client si ça tente quelqu’un je peux aider sur toute la compréhension de la cryptographie et user story (oui j’aime bien le fonctionnel aussi).

Les modifications à faire sur le protocole DUBP

  1. Modifier le comportement de la fonction CSV pour qu’elle se base sur les temps d’écriture des transactions et pas les temps d’émission.
  2. Supprimer la contrainte txWindow, les transactions d’engagement émises sur le réseau LN doivent rester valides indéfiniment. Pour élaguer les mempool, il suffit aux noeuds d’associer un « timestamp de réception » a chaque document tx reçue puis a fréquence régulière de supprimer les tx reçues il y a plus de X secondes.

Et je crois que c’est tout.

Comment ça marche

Bien entendu les LN ne sont pas magiques, ils se basent sur des enchevêtrements cryptographiques très complexes et avec beaucoup de subtilités.
Ils sont le fruit de nombreuses années de recherches de différents expert en crypto à travers le monde, et toutes les spéc sont libres (sous licence CC-BY), on peut donc en faire bénéficier la Ğ1 :smiley:

Bien sûr ça demandera des centaines voir milliers d’heures de travail, mais de mon point de vue le jeu en vaut la chandelle.

Une explication détaillée et en français du fonctionnement cryptographique des LN :

Le white paper officiel : http://lightning.network/lightning-network-paper.pdf

Les RFC techniques des implémentations existantes (dans d’autres crypto-currencies) : https://github.com/lightningnetwork/lightning-rfc/blob/master/00-introduction.md


Peut-être que certains connaissaient déjà très bien, mais je pense que beaucoup de lecteurs de ce forum ne connaissent pas ou mal les LN et ne savent donc pas ce que les LN pourraient apporter à la Ğ1. Perso c’était mon cas, j’ai entendu parler des LN il y a 3 ans déjà mais je ne m’étais jamais penché dessus et j’étais loin de me douter de tout leur potentiel.

12 J'aimes

Si j’en parle maintenant c’est aussi pour que l’on discute des changements de protocole que cela implique, @cgeek @Inso êtes vous ok avec les changements que ça demanderai dans le protocole ?

Implémenter les LN n’est bien sûr pas prioritaire mais j’aimerais au moins qu’il soit théoriquement possible de le faire (protocole compatible), comme ça n’importe-quel contributeur présent ou futur pourrait se lancer dans ce chantier s’il en a envie :slight_smile:

Oui ça doit être tout, j’avais précisément ajouté ces fonctions CSV (ticket#895) et CLTV (ticket#894) pour faire du paiement Lightning.

Sur le point 1) en effet, c’est le coup du TxTime qui n’est pas bon.
Sur le point 2), disons que le channel ne dure que 7 jours maximum aujourd’hui ce qui est trop peu.

Je suis favorable à ces modifications évidemment, pour le protocole v13.

12 J'aimes

Attention tout de même, si sur le layer 1, on a des TX qui « monte » des Junes dans LN, et qu’on ne résous pas le souci des TX non rejouable en cas de fork, ça risque de complexifier la chose.

Ex :
Layer 1 ; je monte des junes sur LN
Layer 2 : je paie.
Layer 1 : Fork
Layer 2 : fatal error ^^

J’y est pensé et ce n’est pas un souci car il suffit de blostamper les transactiosn d’engagement a 100 blocs avant le bloc courant (ou encore plus dans le passé). Les dates d’émission des tx n’ont pas d’importance dans le process LN :wink:

1 J'aime

Tu contournes le problème, par contre si on a un fork en dehors de la fenetre comme on a eu il y a deux noels. Le problème subsiste. Les TX sont perdues car non rejouable.

Théoriquement ce n’est pas possible, en pratique c’est arrivé plusieurs fois par le passé.

Je maintiens que levé cette contrainte, simplifie plein de choses en aval.

My 2Cts,

1 J'aime

Si on a un hard fork type réécriture de l’histoire du a un bug, on pète tout les changements d’états de chanels pendant la période réécrite, mais c’est le cas aussi pour les transaction classiques, c’est le principe même d’un hard fork.

Effectivement la proposition de ne plus utiliser le hash pour dater l’émission de la tx permet de ne pas avoir ce problème, mais ce n’est pas spécifique aux LN, le problème est le même pour les paiements classiques, c’est pourquoi je ne le liste pas ici :slight_smile:

1 J'aime