Bitcoin et Lightning Network : quelle est la différence ?

Architecture de base et modèle de transaction

1. Bitcoin fonctionne sur une blockchain monocouche et sans autorisation où chaque transaction est vérifiée cryptographiquement, propagée sur des milliers de nœuds complets et enregistrée en permanence dans des blocs séquentiels toutes les dix minutes environ.

2. Lightning Network fonctionne comme un réseau superposé peer-to-peer construit directement sur le modèle UTXO de Bitcoin, s'appuyant sur des canaux de paiement bidirectionnels renforcés par des transactions d'engagement révocables et verrouillées dans le temps.

3. Dans Bitcoin, chaque transfert nécessite une inclusion dans un bloc et au moins une confirmation pour être considéré comme sécurisé ; la finalité est probabiliste et grandit avec des confirmations supplémentaires.

4. Dans Lightning, le règlement est instantané et atomique dans les canaux ouverts : aucune confirmation de blocage n'est nécessaire pour les mises à jour du solde, et seuls l'établissement et la fermeture du canal déclenchent une activité en chaîne.

5. Bitcoin impose le consensus grâce à l'exploration de preuves de travail ; Lightning s'appuie sur des délais cryptographiques et des mécanismes de pénalité tels que RSMC (Revocable Sequence Maturity Contract) et PTLC (Point Time-Locked Contracts) pour garantir un comportement honnête sans nécessiter un consensus mondial par opération.

Caractéristiques de débit et de latence

1. Le débit théorique de Bitcoin est limité à 7 à 10 transactions par seconde sous des contraintes standard de taille de bloc et d'intervalle, bien que les optimisations SegWit et Taproot améliorent légèrement l'efficacité.

2. Lightning Network démontre une latence inférieure à la seconde pour les paiements acheminés, avec des délais de livraison mesurés de bout en bout en moyenne inférieurs à 300 millisecondes sur les principaux nœuds de routage.

3. Le débit au niveau du réseau s'adapte à la liquidité des canaux et à la topologie de routage plutôt qu'aux paramètres de blocs fixes : les déploiements réels ont supporté plus de 50 000 TPS lors de tests de résistance contrôlés impliquant l'utilisation de canaux parallèles.

4. Bitcoin Les délais de propagation des transactions sont affectés par la congestion du pool de mémoire et la dynamique du marché des frais, ce qui entraîne souvent des délais de confirmation dépassant 30 minutes en période de pointe.

5. Lightning évite complètement la dépendance au pool de mémoire ; le transfert des paiements s'effectue via des paquets cryptés acheminés par oignons qui traversent plusieurs sauts sans exposer les soldes ou les identités intermédiaires.

Incitations économiques et structures tarifaires

1. Les mineurs Bitcoin perçoivent des frais de base déterminés par le poids des transactions et la concurrence dans le pool de mémoire, les frais médians fluctuant entre 0,50 $ et 15 $ en fonction de la charge et de l'urgence du réseau.

2. Les nœuds de routage Lightning perçoivent des frais de base proportionnels et des frais proportionnels facultatifs libellés en satoshis par million transféré, allant généralement de 1 à 50 satoshis par saut.

3. L'ouverture et la fermeture des canaux entraînent des frais obligatoires en chaîne, mais ceux-ci sont amortis sur des milliers de transferts hors chaîne, ce qui rend les microtransactions économiquement viables.

4. Les frais de routage sont annoncés et mis à jour de manière dynamique via des protocoles de potins ; les nœuds peuvent les ajuster en fonction de la profondeur de la liquidité, de la disponibilité et de l'âge du canal sans nécessiter de consensus.

5. Les outils d'estimation des frais Bitcoin s'appuient sur des données de bloc historiques et des modèles prédictifs, tandis que la découverte des frais Lightning se produit en temps réel via des mises à jour de canaux authentifiées diffusées sur le graphique.

Garanties de sécurité et hypothèses de confiance

1. Bitcoin offre une sécurité inconditionnelle en supposant un pouvoir de hachage majoritaire honnête et des confirmations suffisantes – il est résistant à la censure et définitif une fois profondément enfoui.

2. Lightning hérite de la sécurité de règlement de Bitcoin mais introduit de nouveaux vecteurs de menaces, notamment les risques de fermeture forcée des canaux, la dépendance à la tour de guet et les erreurs de calcul d'expiration du délai d'expiration.

3. Les utilisateurs doivent surveiller activement leurs chaînes ou déléguer la surveillance à des tiers de confiance appelés tours de guet. Dans le cas contraire, cela peut entraîner une perte de fonds en raison de diffusions avec engagement obsolète.

4. Bitcoin n'exige pas que les utilisateurs maintiennent une présence en ligne persistante ; Lightning exige une disponibilité continue pour réagir rapidement aux mauvais comportements de la contrepartie, en particulier dans les scénarios de clôture peu coopératifs.

5. Le protocole RSMC garantit que la fermeture unilatérale du canal ne peut pas conduire à un vol , à condition que les deux parties conservent des clés de révocation valides et respectent les délais de verrouillage – cela constitue le fondement cryptographique de l'intégrité du canal.

Foire aux questions

Q : Puis-je envoyer Bitcoin depuis un portefeuille Lightning vers une adresse en chaîne standard ? R : Oui – la plupart des portefeuilles Lightning prennent en charge le « retrait en chaîne » en initiant une clôture de canal coopératif, qui déclenche une transaction de règlement diffusant le solde final à une adresse BTC spécifiée.

Q : Dois-je exécuter un nœud Bitcoin complet pour faire fonctionner un nœud Lightning ? R : Pas strictement : de nombreuses implémentations telles que LND et Core Lightning permettent de se connecter à des backends Bitcoin distants via RPC ou à l'aide de clients neutrino light, bien que l'exécution d'un nœud local complet améliore la confidentialité et le contrôle de validation.

Q : Que se passe-t-il si mon nœud Lightning se déconnecte pendant un itinéraire de paiement actif ? R : Si votre nœud est un intermédiaire de routage et se déconnecte à mi-paiement, le HTLC (Hashed Timelock Contract) expirera avant la résolution, provoquant un remboursement automatique le long du chemin – aucun fonds n'est perdu, mais la tentative d'itinéraire échoue.

Q : La capacité du canal est-elle partagée de manière égale entre les participants ? R : Non – la capacité est directionnelle et définie par les contributions financières initiales ; le solde disponible de chaque participant dépend de la dernière transaction d'engagement signée, et non de la taille totale de la chaîne.