Core Lightning v23.11: "Bitcoin Orangepaper"
Lightning Network

Core Lightning v23.11: "Bitcoin Orangepaper"

Peter Neuroth

Aujourd'hui, nous présentons la dernière version de Core Lightning, la v23.11, dont le nom de code est Bitcoin Orangepaper (avec l'autorisation de Shahana Farooqui). Après l’imposante version v23.08, cette mise à jour est un peu plus sobre. Néanmoins, elle comprend quelques fonctionnalités intéressantes.

Le double financement enfin compatibilite avec les autres implémentations : Le processus de double financement est maintenant compatible avec les autres implémentations Lightning.

Mise à jour des commandes RPC : Cette version contient des ajouts et des mises à jour intéressantes pour l'API Core Lightning, notamment une commande de check beaucoup plus puissante et une toute nouvelle commande restore.

Core Lightning pour les développeurs : Les différentes interfaces de Core Lightning continuent de s'enrichir et les runes ont maintenant une nouvelle restriction permettant plus de flexibilité. Nous avons ajouté de nouvelles options !

Le double financement à portée de main !

La proposition pour le double financement date de plusieurs années maintenant. Étant donné que Core Lightning a été le première implémentation de nœud Lightning à supporter officiellement le double financement, il n'est pas surprenant que nous soyons si enthousiastes à le voir se démocratiser !

Au cours d'un processus traditionnel de financement des canaux, la transaction est financée uniquement par la partie qui initie un nouveau canal. Cela signifie que, bien qu'elle ait été créée en coopération, seule cette partie peut ajouter des entrées et des sorties à la transaction.

Grâce au protocole de double financement interactif, les deux parties peuvent participer au processus de financement en contribuant aux entrées et aux sorties de la transaction (interactive-tx sub-protocol). Pour ce faire, elles échangent de l’information concernant les entrées et les sorties qu'elles souhaitent créer au cours d'une phase de négociation. Une fois que les deux parties se sont mises d'accord sur leurs ajouts à la transaction, elles échangent les signatures nécessaires et peuvent procéder à la transaction de financement et de la transaction d'engagement initiale.

Ce processus permet de créer des canaux avec des soldes non nuls aux deux extrémités. L'un des avantages est la possibilité d'établir des canaux pour l'envoi et la réception de paiements instantanés sans devoir préalablement modifier les soldes.

Passons maintenant aux nouvelles :

Un aspect fondamental du processus basé sur les spécifications BOLT est l'exigence de deux implémentations compatibles avant qu'elle ne puisse être incluse dans un BOLT.

Les récentes contributions de Lisa Neigut à la mise en œuvre du double financement dans Core Lightning permettent au processus de financement de se poursuivre en cas de perte temporaire de connexion. Il s'agissait de la dernière étape pour que Core Lightning et Eclair puissent être compatibles.

Mises à jour de la commande RPC

Cette version de Core Lightning apporte des mises à jour et des ajouts à l'API.

S'appuyant sur les fondations posées par l'option --recover de la version précédente, cette version l'élève au rang de la commande RPC recover accessible par le biais des plugins et de diverses interfaces. La commande provoque le redémarrage du nœud avec l'option --recover activée. Cette fonctionnalité est particulièrement avantageuse pour les applications front-end.

Avec l'introduction de recover, check a reçu une mise à jour importante. En plus de valider le format et les paramètres de la commande, check effectue une analyse approfondie sans altérer l'état du système.

La combinaison des deux commandes permet de vérifier si une récupération peut être effectuée (sans avoir à le faire), ce qui peut être utile pour construire des interfaces utilisateur robustes.

Un autre exemple des capacités améliorées de la commande check est la commande delinvoice. delinvoice utilise les paramètres label et status pour supprimer une facture de la base de données. Auparavant, la commande check validait la commande en s'assurant de la présence des deux paramètres requis. Avec cette mise à jour, la commande check effectue une analyse plus approfondie en vérifiant la présence d'une facture avec le label et en confirmant que le status est approprié.

Exemple:

$ lightning-cli check delinvoice "l1" "paid"
{
	"code": 906,
	"message": "Invoice status is unpaid not paid",
	"data": {
	"current_status": "unpaid",
	"expected_status": "paid"
  }
}

La commande decode a également été mise à jour. decode peut désormais gérer une chaîne de récupération d'urgence, ce qui permet à un utilisateur de vérifier l'intégrité et la validité du fichier emergency.recover. La chaîne de récupération d'urgence peut être obtenue avec la nouvelle commande getemergencyrecover de hsmtool.

Ces mises à jour fournissent une plateforme solide qui permettra aux utilisateurs d’opérer plus facilement leur nœud Core Lightning de manière sécurisée.

Parlant de noeud Core Lightning, les runes ont obtenu une nouvelle restriction qui permet une plus grande flexibilité et une gestion plus fine des accès. La contrainte per permet une limitation générale du débit et s'adapte à une gamme d'unités de temps telles que sec, msec, etc. Pour ce faire, Core Lightning garde désormais la trace d'un timestamp last_used par rune, qui est également ajouté à la commande showrunes.

Cette version met également à jour tous les champs de temps en nanosecondes. Cela concerne les champs listforwards received_time, resolved_time ainsi que les champs listpays et listsendpays created_at.

Outre la recover, qui rend Core Lightning plus accessible aux applications front-end, les APIs wait et pagination ont été améliorées. wait prend désormais en charge deux sous-systèmes supplémentaires, listforwards et listsendpay. Ces mises à jour permettent d'attendre tout changement d'état sur les HTLC et les paiements transmis, et ajoutent la pagination à listforwards et listsendpays. Ces ajouts sont particulièrement utiles pour les développeurs front-end afin d'améliorer l'expérience utilisateur. Pour les rendre accessibles à un plus grand nombre, le système wait a été activé pour les interfaces Rust et gRPC.

Une autre commande a été ajoutée à l'arsenal de Core Lightning : datastoreusage. Cette commande offre une vue de l'espace occupé par les entrées du datastore dans la base de données, sans qu'il soit nécessaire de quantifier manuellement les données.

Cette série de mises à jour de commandes améliore non seulement les fonctionnalités de Core Lightning, mais aussi l'expérience utilisateur (et du développeur), mettant ainsi en évidence l'évolution continue de la plateforme.

Autres mises à jour notables

Avec cette version, Core Lightning a délaissé l'ancienne façon d'activer la fonctionnalité de développement sur un nœud. Auparavant, il était nécessaire de compiler Core Lightning à partir de zéro. Pour activer la fonctionnalité développeur, il suffit maintenant de lancer lightningd avec la variable d'exécution --developer. Il s'agit d'une amélioration très utile pour les développeurs.

Core Lightning active désormais les canaux de grande taille par défaut. Au début du développement du Lightning Network, les développeurs ont décidé de limiter temporairement la taille maximale des canaux à moins de 0,16777216 BTC. Cette décision a été prise pour limiter le montant qu'un utilisateur pourrait perdre en raison de bogues logiciels. Aujourd'hui, les canaux peuvent dépasser cette limite, mais un nœud doit signaler sa volonté de le faire. Cette version active par défaut l’option la "wumbology for all". Les utilisateurs peuvent toujours désactiver les canaux wumbo en définissant l'option --large-channels=false.

Enfin, cette version ajoute la possibilité de créer des factures qui incluent une adresse P2TR de repli. De cette manière, une facture peut également être payée sur la chaîne, par exemple lorsqu'il n'y a pas suffisamment de liquidités entrantes au moment du paiement. Core Lightning assure désormais le suivi des paiements aux adresses de repli et gère les commandes en attente. Les adresses de repli peuvent être activées en définissant l'option de configuration invoices-onchain-fallback.

Joignez-vous à la communauté CLN

Nous tenons à saluer les contributeurs (29 au total pour la version 23.11) qui continuent à nous aider à améliorer CLN à chaque mise à jour. Nous vous remercions de votre soutien ; votre dévouement et vos commentaires ont rendu cette nouvelle version possible.

Comme toujours, faites-nous savoir ce que vous aimez ou ce que nous pourrions améliorer en démarrant un fil de discussion sur Build On L2, où nous avons des pages spéciales pour les développeurs et les opérateurs de nœuds afin de faciliter la discussion. L'inscription est gratuite et vos commentaires sont les bienvenus !

Vous pouvez également nous joindre sur nos canaux sociaux habituels : Twitter, Telegram ou Discord. Une dernière surprise : gardez un œil sur la chaîne YouTube de Blockstream. Nous avons prévu une série d'épisodes spéciaux de podcast avec Rusty Russell, Christian Decker et d'autres contributeurs de CLN, dans lesquels nous discutons de la nouvelle version.

Merci encore à la communauté et à tous ceux qui continuent à rendre Core Lightning formidable !

If you have specific preferences, please, mark the topic(s) you would like to read: