Visualisation et explication des Bolts (Basic of Lightning Technology):
Objet:
Les spécifications Basics of Lightning Technology (BOLTS) sont un ensemble de directives pour la création et le maintien d’un réseau pair à pair hors de la première couche du réseau du Bitcoin. Ce dernier se nomme LIGHTNING NETWORK , il repose sur un échange de contrats mutuels et se base ultimement sur la première couche du Bitcoin en cas de conflits. Ce article est une traduction et interprétation des Bolts à partir de leur emplacement originel (soit le dépôt GitHub des Bolts) agrémenté par un article de Rusty Russel décrivant sommairement les Bolts. Celui-ci est maintenant connu comme un développeur prolifique du Lightning Network, présentement travaillant à Blockstream.
Nous avons également inclus un schémas visuel des Bolts pour faciliter la compréhension de ceux-ci. Il s’agit d’une simplification qui ne rassemble pas l’ensemble des relations et détails qui rendent le Lightning Network fonctionnel. Pour une compréhension approfondie, nous suggérons la lecture complète des bolts ainsi que de suivre régulièrement les développements qui s’ajoutent à ceux-ci.
Bolt #1: Protocole de Base (Établissement de connexion entre pairs).
- Le port TCP de Lightning est 9735. ( Lightning en Unicode http://www.unicode.org/charts/PDF/U2600.pdf ) Tout protocole sur Internet établissant des liens de connectivités hôte à hôte utilise des spécification de port. Cela permet une plus grande uniformité de communications.
- Mécanisme sous-jacent d’authentification et de transport d’information.
- Utilisation de l’orientation de big-Endian https://fr.wikipedia.org/wiki/Endianness.
- Messages PING -PONG. Pour le maintien d’une connexion TCP de longue durée, il est possible que l’on demande des échanges entre les nœuds pour le maintien de celle-ci
- Ping: Message d’envoi (peut spécifier la taille du message de renvoi)
- Pong: Message de Renvoi après la réception d’un message de type Ping
- Possibilité de création d’un trafic synthétique (peut être utilisé à des fins d’obfuscation).
- Spécification au niveau de la taille des messages sur le Lightning Network;
- Capé à 65535 bytes puisqu’ils répondent à des critères de 2-Bytes non signé. https://en.wikipedia.org/wiki/Integer_(computer_science)
- Paquets au-delà de la taille permise: possible extension facile dans le futur.
Bolt #2: Protocole pair à pair pour la gestion de canaux.
Suite à l’établissement d’une connexion entre nœuds (Bolt #1- #8), l’établissement d’un canal peut suivre. Cela consiste à une suite de messages échangés entre deux nœuds. Les messages (1) et (2) (Graphique #1 ici-bas) définissent les termes de l’ouverture d’un canal ainsi que le message correspondant qui accepte ces-derniers. Avec les spécifications acceptées, le nœud ‘’financeur’’ est en mesure de créer les termes de la transaction (message 3) et peut recevoir par la suite une confirmation des termes du nœud B (message 4) — plus de détails sur ces termes dans le Bolt #3.
Suite à la réception par le nœud A du message des termes de financement signé par le nœud B, la transaction est propagée sur le réseau du Bitcoin. Les deux parties doivent respecter le nombre de confirmations recommandées avant de pouvoir compléter l’ouverture du canal en envoyant un message confirmant le financement bloqué (message 5 et 6).
Graphique #1: Création d’un canal
Chacun des messages correspondants contient son lots de spécifications.
+-------+ +-------+
| |--(1)--- Ouverture_Canal----->| |
| |<-(2)- acceptation_Canal ----| |
| | | |
| A |--(3)-- financement_crée ---->| B |
| |<-(4)-- financement_signé ---| |
| | | |
| |--(5)--financement bloqué --->| |
| |<-(6)--financement bloqué ----| |
+-------+ +-------+
- Ou le noeud A est le ''financeur'' et le noeud B est le ''financé''. Graphiques # 2: Opérations normales
Une fois que les nœuds ont échangés mutuellement les messages de financement bloqué (funding_locked), les deux parties peuvent procéder à des paiements basés sur des Hashed Time Locked Contracts (HTLC). Les HTLCs sont des contrats de paiements incluant une date limite qui forcent le récipient de la transaction à révéler un secret cryptographique afin de pouvoir dépenser les fonds de la transaction en question.
+-------+ +-------+
| |--(1)---- update_add_htlc ---->| |
| |--(2)---- update_add_htlc ---->| |
| |<-(3)---- update_add_htlc -----| |
| | | |
| |--(4)--- commitment_signed --->| |
| A |<-(5)---- revoke_and_ack ------| B |
| | | |
| |<-(6)--- commitment_signed ----| |
| |--(7)---- revoke_and_ack ----->| |
| | | |
| |--(8)--- commitment_signed --->| |
| |<-(9)---- revoke_and_ack ------| |
+-------+ +-------+Schéma représentant le processus de mise à jour de l’état des transactions entre deux nœuds sur le lightning network. (Celui-ci n’a pas été traduit)
- Plusieurs mises à jour HTLC peuvent être envoyés en paquet pour justifier les transactions. À savoir les HTLC particulier d’un nœud concernent les mises à jour des autres nœuds uniquement. Le nœud envoyant le HTLC peut appliquer les mises à jours après que les autres nœuds aient envoyés l’acceptation de mises à jour avec la commande ‘’revoke_and_ack’’.
- Les mises à jour sont donc effectuées de manière indépendante par chacun des nœuds. Ils peuvent donc être parfois désynchronisé, cela n’a pas d’importance sachant qu’il suffit que les deux nœuds partagent le même état final.
- L’envoi d’un HTLC est normalement utilisé pour initialiser un paiement de la part de l’expéditeur ou encore pour pousser vers l’avant (forward) le paiement d’un autre nœud.
- Dans le cas d’un forward, il est primordial de s’assurer que le HTLC de l’expéditeur ne peut être appliqué à condition de recevoir le HTLC correspondant du récipient.
- De nombreuses conditions sont évoqués dans le Bolt #2 afin de s’assurer que les updates finales de transactions soient les mêmes pour les nœuds ayant pris part à un échange. Sachant que le maintien d’un réseau peut s’avérer difficile puisque le maintien de canaux/ opérationnalité d’un nœud ne sont pas garantis.
Graphique #3: Fermeture d’un canal
Les nœuds désirant fermer un canal peuvent le faire en négociant mutuellement la fermeture de celui-ci. Cela permet la fermeture immédiate du canal avec des frais plus bas, en conséquent un accès au fonds plus rapide pour les deux partis. Des fermetures unidirectionnelles peuvent également être effectué avec la date limite d’un HTLC qui arrive à échéance.
+-------+ +-------+
| |--(1)----- shutdown ------->| |
| |<-(2)----- shutdown --------| |
| | | |
| | <complete all pending HTLCs> | |
| A | ... | B |
| | | |
| |--(3)-- closing_signed F1--->| |
| |<-(4)-- closing_signed F2----| |
| | ... | |
| |--(?)-- closing_signed Fn--->| |
| |<-(?)-- closing_signed Fn----| |
+-------+ +-------+Schéma représentant le processus de fermeture d’un canal entre deux nœuds sur le Lightning network. (Celui-ci n’a pas été traduit)
Chacun des nœuds peut initier la fermeture d’un canal en envoyant un message. Les deux partis doivent s’assurer d’avoir résolu l’ensemble des HTLC en attente dans le canal afin de pouvoir initier le processus de fermeture.
Les partis doivent s’entendre sur un frais de transaction pour être en mesure de pouvoir partager la transaction de fermeture sur la première couche du Bitcoin.
Bolt #3: Format de transactions et des scripts Bitcoin.
Le Bolt #3 décrit le format de scripts ainsi que la taille utilisée pour chaque transaction. Il s’agit de directives importantes pour les calculs des frais de transactions. Un script est la méthode utilisée par le Bitcoin pour décrire les termes sous lesquels les fonds d’une transaction peuvent être dépensés par le récipient de la transaction.
Dans le bolt correspondant on spécifie plus en détails les termes de/du :
- Script output P2WSH (Pay to witness script hash) pour la transaction de financement. (décrite dans le Bolt #2).
- La méthode P2WSH consiste à placer à la fin de la transaction le scriptSig (la partie de la transaction contenant la signature ainsi que la pubkey). Normalement celui-ci se retrouvait au milieu de la transaction, prenant la majorité de l’espace dans celle-ci. Il est possible d’envoyer la transaction à un nœud Legacy (un nœud Legacy n’accepte pas les blocs au-delà de 1 MB), et de la faire valider sans présenter le pubkey. Les transactions P2WSH peuvent donc être déconstruite au besoin dépendant de la nature des sorties (outputs) à dépenser.
- L’ordonnance des sorties pour la transaction d’engagement. (Suivant les recommandations du BIP 69).
- Le BIP propose une méthode de randomisation de l’ordre sous lequel des outputs sont présenté.
- Script output P2WSH pour la transaction d’engagement ‘to-self’.
- La transaction d’engagement est la transaction que les deux parties d’un canal créent mutuellement pour mettre à jour l’état des comptes. Il s’agit de la deuxième transaction réalisée après la transaction de financement. La forme qu’une transaction d’engagement peut prendre est nombreuse pour permettre des fonctionnalités de punition si l’un des partis essaye de tricher.
- Les scripts des outputs et inputs pour les HTLC réussis.
- Sous quelles circonstances les outputs poussières (dust) sont rognées et incluses dans les frais de transactions plutôt que d’avoir leur propre output.
- Parfois la balance d’un canal peut être significativement petite pour ne pas valoir la peine une création d’un output singulier pour celle-ci. Elle sera alors incluse dans les frais de transaction de la transaction de fermeture. (À priori, lors de la création d’un canal, cette limite doit être établie)
- La méthode de calcul approximative des frais de transactions pour les transactions d’engagements.
Bolt #4: Protocole de Routage Onion.
L’importance de l’anonymat est la raison de ce bolt. Il est facile de router des paquets sur Internet, mais il est très difficile de le faire de façon anonyme. Il était donc important de parler de ce concept très tôt pour l’implémenter par défaut dans le protocole de Lightning le plus rapidement possible. Certaines mesures peuvent considérablement influencer le développement de la suite du protocole Lightning.
Le bolt #4 décrit la construction de la route nécessaire pour la transmission d’une transaction à partir d’un nœud originel jusqu’à la réception de la transaction par le nœud final. L’ensemble des nœuds qui ont fait partis du processus de transmission sont surnommés ‘’hops’’. Pour être anonyme il faut qu’il soit impossible pour un nœud de déterminer le nombre de hops effectués par la transaction jusqu’à ce même nœud ou combien de hops il reste pour la destination finale de celle-ci.
L’adaptation du schémas de routage est inspiré de la méthode Sphinx. (A Compact and Provably Secure Mix Format). Les intermédiaires (hops) ne sont pas en mesure de déterminer la voie (direction) empruntée par la transaction, ni la longueur de celle-ci (nombre de hops). Le paquet est également obscurcis à chaque hop pour éviter l’association entre paquets dans un cas d’attaque sur le réseau. Le nœud originel construit la route à l’aide d’un secret cryptographique partagé le long de la route.
Dans le bolt on spécifie les conventions générales de la méthode, la méthode de génération des clés nécessaire à l’obscurcissement des hops, la structure des paquets, l’encryption utilisée pour le secret partagé, la construction et la mise vers l’avant de paquets.
Bolt #5: Recommandation pour la gestion des transactions sur la première couche.
Le réseau Lightning permet à deux parties de transiger en Bitcoin hors de la chaîne à l’aide d’une transaction d’engagement mutuelle qui attribue les balances respectives pour chacun des parties. Cette transaction d’engagement subie une mise à jour à chaque fois qu’une nouvelle transaction est effectuée.
Il y a trois façons pour la résolution d’un canal:
- La bonne façon: Entente mutuelle des deux parties pour la terminaison de leur canal. La transaction finale est publiée sur le Blockchain. Cette méthode est décrite dans le bolt # 2.
Lors de cette situation, les fonds peuvent être récupérer immédiatement par les deux parties.
- La mauvaise façon: L’un des parties ne parvient pas à maintenir le canal de la bonne façon, résultant à la terminaison précoce du canal. Cela peut arriver sans de mauvaise invention.
- Lors de cette situation, vu qu’il n’y pas eus de tentatives malicieuses de tricherie, le nœud qui est resté en ligne peut attendre la résolution du plus récent HTLC. Il y a également d’autres méthodes de réclamation des fonds dépendamment du moment où le nœud est tombé hors ligne.
- La façon malicieuse: Un des parties essaye de tricher en publiant une transaction d’engagement ultérieure. (Une transaction d’engagement ultérieure qui favorise le partie malicieux).
- Lors de cette situation, le nœud bienveillant peut utiliser une clé de révocation qui lui permettra de récupérer les fonds initiaux de la transaction de financement.
Le but de Lightning est de ne pas avoir à faire confiance en des parties tierces. Dans les trois cas décrits ci-dessus, aucune perte de fonds ne peut avoir lieu. Le bolt # 5 donne des directives par rapport aux comportements des nœuds lors de ces trois situations.
Une nomenclature de base est décrite à priori pour comprendre la façon que les sorties (outputs) sont classifiées:
Output non résolu: La première transaction non résolue est la transaction de financement réalisé lors de la création d’un canal (Bolt #2), toutes transactions d’engagement ultérieures à celle-ci sont considérées comme non résolue tant qu’elles ne sont pas publiées sur la première couche du Bitcoin.
Output résolu: Un output peut être considéré comme résolu une fois que les conditions de dépense de celui-ci sont spécifiées. Un output est considéré irrévocablement résolu une fois qu’il est inclus dans un bloc antécédent à 100 blocs sur la chaîne contenant la plus grande preuve de travail (Proof-of-work).
Bolt # 6:
L’ancien Bolt # 6 concernait la façon que les avancements du réseau seraient annoncés sur les canaux de IRC. Il a été joint au Bolt #7.
https://github.com/lightningnetwork/lightning-rfc/issues/551
Bolt # 7: Nœuds pair à pair et découvertes de canaux.
Cette spécification repose sur la découverte simple de nœuds, découverte de canaux et la mise à jour de canaux qui ne repose pas sur une partie tierce pour le partage d’information.
Les processus décrits ci-dessus ne sont pas obligatoire et ne servent qu’aux nœuds qui désirent router des transactions au-delà de leurs nœuds voisins :
- Le processus de découverte de canaux permet la création et le maintien d’une vue locale de la topologie de réseau. Ce processus sert à la découverte de routes pour les destinations de paiements désirées.
- Le processus de découverte de nœuds permet la propagation du ID (numéro d’identification du nœud, l’hôte, le port) afin que les autres nœuds puissent établir des connections avec celui-ci et établir de canaux de paiement.
Le processus de découverte de canaux supporte trois types de messages:
- Message ‘’d’annonce de canal ‘’ qui contient l’information concernant de nouveaux canaux entre deux nœuds. Le partage du message requiert les signatures respectives des nœuds prouvant la création à priori du canal en question. La création d’un canal requiert la création d’une transaction de financement signé par les 2 parties. (Comme indiqué dans le bolt #2). Les deux nœuds doivent signés indépendamment pour indiquer le désir de transiger des transactions du réseau par leur canal. En d’autres mots, faire partie du réseau public.
- Message ‘’d’annonce de nœud ‘’, qui contient des informations supplémentaires sur le nœud. Contient l’adresse IP, ipv6, ipv4, tor v2 et tor v3 pour se connecter au nœud en question. D’autres précisions au sujet du nœud tel l’alias choisi pour le nœud ainsi que la couleur du canal sur des représentations graphiques du Lightning Network, peuvent être incluses dans le message.
- Message de ‘’mise à jour du canal ‘’, permet de spécifier le minimum de frais accepté pour relayer un paiement à travers le canal en question ainsi que le temps d’expiration du canal.
À des fins de prévention contre des attaques DOS, l’ordre des actions nécessaires pour partager les messages ci-haut est :
- Création de la transaction de financement
- Annonce de canal
- Annonce de nœud
L’ensemble des recommandations du Bolt # 7 concernent la construction et le maintien du réseau public du Lightning Network composé de nœuds et de canaux mise à la disposition pour le relayage de paiements. De nombreuses informations et conditions supplémentaires sont expliquées en détail sur le Git correspondant.
Pour plus d’informations supplémentaires sur de possibles scénarios d’attaques DOS sur le Lightning Network, explorez les liens ci-dessous. De nombreuses propositions en cours permettraient de renforcer la sécurité du réseau tel que Eltoo, proposé par Blockstream.
https://homepages.staff.os3.nl/~delaat/rp/2017-2018/p92/report.pdf
https://www.reddit.com/r/Bitcoin/comments/80nufg/lets_talk_about_what_peter_toddbitcoin_core/
Bolt # 8 Transport crypté et authentifié.
L’ensemble des communications entre les nœuds du réseau du Lightning Network doit être encrypté à des fins de confidentialité et permettre l’authentification pour éviter de l’interférence malicieuse. Chaque nœud a un identifiant qui lui est propre et qui est une adresse publique répondant au critère de la courbe secp256k1.
Le processus de communication entre nœuds se déroule en deux phases, soit la phase d’initiation et d’authentification de la communication et la phase de communication même. La communication ne peut se résumer que suite à une première phase réussie.
La première phase consiste à participer à un approbation de clé authentifié, (authenticated key agreement handshake), qui s’appuie sur le ‘’Noise Protocol Framework’’.
Suite à la première phase réussie, les nœuds peuvent procéder à l’échange de messages de leur interaction sur le Lightning Network. L’entièreté des messages sont des CypherText, s’assurant de l’authentification et l’encryption de données associées. Pour en apprendre plus sur l’encryption derrière ces processus : Authenticated Encryption with Associated Data de Phillip Ragaway.
Bolt # 9: Drapeaux d’identification de fonctionnalités.
Pour l’utilisation de fonctionnalités supplémentaires, des « drapeaux » spécifiques peuvent être assignés au message d’initiation. (Décrit dans le Bolt #1).
La liste de ces spécifications et leur assignation respective se retrouve sous le git du bolt #9: https://github.com/lightningnetwork/lightning-rfc/blob/master/09-features.md
Bolt # 10: DNS Bootstrap et assistance de l’emplacement du nœud.
Le bolt correspondant décrit le mécanisme de découverte de nœuds grâce au système de noms de domaine. (Domain Name System).
Bolt # 11: Protocole de Facture pour le Lightning Network.
Façon pour demander une facture Lightning Network à l’aide d’un QR CODE. Le format des factures Lightning répond aux critères d’encodage bech32.
Questions Supplémentaires:
Différence entre une transaction d’engagement versus un HTLC ?
Les deux termes peuvent sembler similaire puisqu’il s’agit des mécanismes à travers lesquels les nœuds communiquent pour mettre à jour leur balances. Voici un échange sur github qui fait la distinction entre un HTLC et une transaction d’engagement.
Sources Principales:
