Community Trust ScoreVérifié
Lightning Network Daemon (LND) a publié la version v0.21.5-beta.rc1 le 22 octobre, un candidat de pré-version qui introduit un plafond de 10 000 satoshis par octet virtuel pour les estimations de frais Bitcoin externes. Cette mise à jour comble une lacune dans la gestion par le logiciel des données reçues des API de frais externes, qui disposaient auparavant d’une borne inférieure mais manquaient d’une limite supérieure correspondante.
Protection contre les entrées de frais extrêmes
Les notes de version précisent que la nouvelle modification applique un plafond strict aux valeurs fournies par des services externes. Cette limite borne également l’estimation de relais minimale de l’API. Les développeurs décrivent ce seuil comme une garde-fou contre les valeurs extrêmes, plutôt que comme une indication que de tels frais sont normaux, économiques ou requis par les conditions actuelles du réseau.
Une estimation de frais fonctionne comme une entrée dans un processus de décision, plutôt que comme une instruction qui doit être suivie à tout prix. Les services externes peuvent retourner des valeurs inutilisables en raison d’erreurs, de formats de données modifiés ou de dépendances compromises. En bornant l’entrée, le logiciel limite un chemin par lequel un problème en amont peut influencer les opérations du portefeuille. Le contexte opérationnel plus large implique le besoin pour un logiciel qui gère de l’argent de disposer à la fois d’une méthode pour identifier les problèmes et d’un chemin pour déployer des réparations.
Vérification et tests de déploiement
La page de publication GitHub identifie la construction comme une pré-version et indique qu’aucune migration de base de données n’est requise. La page fournit des instructions pour la vérification des signatures et des binaires, qui soutiennent la vérification de l’intégrité des fichiers téléchargés. Cependant, ces étapes de vérification ne démontrent pas comment la construction se comportera dans chaque configuration de nœud spécifique.
Les notes de version décrivent également une correction pour un verrouillage (deadlock) de la piscine de connexions SQL native. Cette modification est pertinente car la fiabilité des nœuds dépend du comportement du stockage ainsi que de la communication réseau. Un processus qui reste en cours d’exécution alors que les requêtes cessent de se terminer peut toujours faire échouer les applications qui en dépendent. Par conséquent, tester une construction candidate nécessite de couvrir le travail réel du service, y compris la réception des requêtes, l’accès au stockage, la gestion des pannes et le redémarrage propre.
L’absence de migration de base de données élimine une catégorie de changement potentiel, mais ne prouve pas que chaque interaction avec les données existantes reste inchangée. Pour les fournisseurs de paiement, cette maintenance logicielle est distincte des contrôles de garde. Maintenir l’autorité de signature en sécurité et maintenir un nœud de paiement fonctionnel sont des responsabilités distinctes. Les arrangements de garde et de récupération ne peuvent pas remplacer le besoin d’une maintenance logicielle continue. La décision finale de publication et la décision de déploiement d’un opérateur restent des étapes supplémentaires au-delà de l’évaluation de cette construction candidate.
Questions Fréquentes
Quel est le plafond de frais dans LND v0.21.5-beta.rc1 ?
La publication applique un plafond de 10 000 satoshis par octet virtuel aux estimations de frais Bitcoin externes. Cette limite borne également l’estimation de relais minimale de l’API.
LND v0.21.5-beta.rc1 nécessite-t-il une migration de base de données ?
Non, la page de publication GitHub indique que la construction ne nécessite aucune migration de base de données. Elle est classée comme un candidat de pré-version.
