Après trois mois et 418 commits soumis par 36 contributeurs, nous sommes ravis d'annoncer la sortie de Core Lightning v24.02. Bien qu'il s'agisse principalement d'une version de maintenance, de nombreux petits changements plairont aux opérateurs de nœuds, ainsi que quelques améliorations internes qui rendront l'utilisation de CLN plus simple et moins coûteuse pour les utilisateurs.
Dans ce qui suit, nous donnerons un bref aperçu du double financement, qui a enfin quitté l'état de proposition pour devenir une partie de la spécification. Ensuite, nous couvrirons brièvement les plus grandes fonctionnalités et optimisations de cette version.
Note : Cette version contient une correction pour un bug de crash qui peut se produire sur testnet. Si vous utilisez CLN sur testnet, veuillez mettre à jour dès que possible.
Le double financement est maintenant largement disponible
Lisa Neigut a publié le premier brouillon du double financement dès 2017 (une période turbulente), et il a depuis subi plusieurs itérations. Après des années de perfectionnement et de durcissement contre les abus, la proposition a finalement été fusionnée dans la spécification de Lightning.
C'est une avancée incroyable pour le réseau dans son ensemble et pour CLN et Eclair, qui prennent désormais en charge le double financement. Le double financement permet aux nœuds de mieux utiliser leur liquidité, évitant ainsi la nécessité d'ouvrir un deuxième canal pour contribuer des fonds à une connexion. Il est également beaucoup plus robuste contre les participants malveillants que d'autres protocoles d'ouverture de canaux équilibrés : d'autres protocoles permettent souvent à une partie de s'enfuir avec les fonds. En revanche, dans le double financement, toutes les parties contribuant des fonds effectuent un protocole coinjoin, créant ensemble la transaction de financement et ne déléguant la propriété à personne d'autre, même temporairement. Cela signifie que chaque partie est en contrôle total et exclusif de ses fonds jusqu'à ce que le canal soit entièrement créé, supprimant ainsi les exigences de confiance des autres protocoles.
[Vidéo explicative](https://youtu.be/PyJxG7h-GRA)
À ce stade, nous aimerions remercier nos amis d'ACINQ pour avoir travaillé avec nous sur la proposition et fourni la deuxième implémentation de la proposition, ce qui nous a finalement permis de progresser. Pour rappel, l'exigence de deux implémentations vise à garantir que la proposition de spécification contient toutes les informations nécessaires à sa mise en œuvre et à s'assurer que la proposition fonctionne pour plus d'une implémentation. Étant donné la diversité des utilisateurs des produits de CLN et d'ACINQ, c'était une très bonne confirmation que la proposition résout des problèmes pour un ensemble de cas d'utilisation tout aussi diversifié.
Mais le voyage n'est pas encore tout à fait terminé. Une partie de la spécification du double financement comprend également le sous-protocole de transaction interactive, qui se trouve également être la fonctionnalité habilitante du splicing. Alors restez à l'écoute pour plus de fonctionnalités excitantes à venir.
Nouveau Plugin de Récupération
Les bugs logiciels et les problèmes matériels sont inévitables dans le monde réel, il est donc important pour nous de réduire les conséquences négatives autant que possible. Avec les capacités de sauvegarde en temps réel que nous avons introduites il y a quelques années, nous avons un système qui permet de restaurer un nœud sans impact opérationnel à part un bref temps d'arrêt. Cependant, les sauvegardes en temps réel peuvent être un peu fastidieuses à configurer, nécessitant généralement un emplacement secondaire pour écrire et une compression régulière des sauvegardes.
Aditya Sharma a poursuivi ses travaux antérieurs sur la construction d'un système de récupération d'urgence similaire aux sauvegardes de canal statiques (SCB) dans d'autres implémentations. La sauvegarde de canal statique et notre système de récupération d'urgence consistent tous deux en un petit fichier contenant des métadonnées sur les canaux qui ont été ouverts. En cas de perte de données, nous pouvons prendre ce fichier, le développer en fragments de canal et commencer à nous connecter aux pairs dans l'espoir de leur demander de fermer en notre nom afin que nous puissions ensuite récupérer les fonds de la fermeture. Cela peut être utilisé comme complément aux sauvegardes en temps réel ou comme un dernier recours si vous n'avez pas configuré la sauvegarde.
Cette dernière itération ajoute le plugin de récupération. Là où auparavant vous deviez comprendre et passer manuellement par le processus de récupération, le nouveau plugin prend en charge la plupart du processus. Cela signifie que la récupération est devenue beaucoup plus fiable. Ne sous-estimez pas l'importance de la fiabilité et de la facilité d'utilisation dans ce cas, surtout dans une situation où votre système vient de planter et que vous essayez de récupérer vos fonds.
Améliorations de Performance et de Stabilité
Comme à chaque version, celle-ci comprend également un grand nombre d'optimisations, et bien que nous ne puissions pas toutes les mettre en avant, il y a quelques sujets généraux que nous aimerions mentionner ici.
Par exemple, la vitesse à laquelle nous traitons les blocs a été augmentée de plus de 50 %, grâce à quelques optimisations dans le code de gestion. Cela signifie que si votre nœud est arrêté, il faudra moins de temps pour rattraper la blockchain.
Une refonte majeure de la manière dont le gossip est géré a abouti à la séparation du gossip en public et privé, et le gossip privé n'est plus stocké dans gossip_store. Cela signifie que le fichier gossip_store peut maintenant être partagé entre plusieurs nœuds, et vous pouvez également en fournir un lors du démarrage d'un nouveau nœud, évitant ainsi la re-vérification et vous permettant de provisionner les nœuds beaucoup plus rapidement.
Mise à Jour vers la Dernière Version de CLN
Parmi tous les changements, fonctionnalités et optimisations mentionnés ci-dessus, cette version contient également une correction pour un problème sur testnet. Le problème est dû à libwally tentant d'appliquer certaines politiques de relais lors de l'analyse du bloc, qui ne doit pas adhérer aux politiques de relais. Une transaction plus grande que la limite autorisée dans le bloc 2578284 a provoqué le rejet erroné de la transaction par libwally, puis du bloc. Si vous utilisez CLN sur testnet, veuillez mettre à jour vers la v24.02 dès que possible. Le réseau principal de Bitcoin n'est pas impacté.
En plus de la correction pour testnet, il y a également une petite correction dans elementsd concernant le support de Liquid, où nous pouvions échouer à analyser correctement un peg-in, causant ainsi le blocage du nœud lors de la tentative d'analyse de la transaction.
Pour mettre à jour vers la dernière version de CLN, rendez-vous sur la page de la version, ou si vous souhaitez approfondir les détails, consultez le changelog et dites-nous ce que vous aimez ou ce que nous pourrions améliorer.
Et comme toujours, un grand merci aux nombreux contributeurs et bénévoles qui continuent à nous aider à améliorer CLN au fil du temps. Nous sommes reconnaissants pour vos contributions et nous nous réjouissons de continuer à collaborer avec vous pour développer Lightning.