Minage, nœuds plus légers et sécurité Lightning
Bitcoin évolue rarement par de grandes révolutions visibles du jour au lendemain.
Une bonne partie du travail consiste plutôt à identifier des situations limites : un mineur qui ralentit, un nœud qui doit télécharger énormément de données ou un logiciel Lightning qui se comporte mal face à un participant malveillant.
Le bulletin Bitcoin Optech #423 en fournit plusieurs bons exemples.
Quand ralentir peut vous empêcher de repartir
Imaginez une route dont la limitation de vitesse s’adapterait automatiquement à votre voiture.
Tant que vous roulez normalement, le système observe votre passage et ajuste ses paramètres.
Mais votre voiture ralentit brutalement.
Problème : le système attend votre prochain passage pour comprendre que vous avez ralenti. Et puisque ses réglages sont désormais trop exigeants… votre prochain passage devient justement beaucoup plus rare.
C’est, en simplifiant, le problème étudié cette semaine dans certaines pools de minage.
Une pool doit pouvoir mesurer le travail fourni par chaque mineur. Elle lui demande donc de produire régulièrement des preuves de travail, appelées shares, à une difficulté adaptée à sa puissance.
Un système appelé vardiff, pour variable difficulty, ajuste automatiquement cette difficulté.
Plus le mineur est puissant, plus le travail demandé peut être difficile.
Mais que se passe-t-il lorsqu’un mineur ralentit ?
Si le logiciel ne recalcule la difficulté que lorsqu’il reçoit une nouvelle share, il peut continuer à attendre un résultat correspondant à l’ancienne puissance du mineur.
Et attendre longtemps.
La solution proposée est conceptuellement très simple : utiliser aussi le temps écoulé.
Si aucune share n’arrive pendant une certaine durée, le système réduit progressivement la difficulté au lieu d’attendre indéfiniment.
L’implémentation de référence de Stratum V2, le protocole moderne de communication entre mineurs et pools, utilise déjà ce principe, même si son comportement peut encore être amélioré dans certains cas.
Ce sujet paraît extrêmement spécialisé. Pourtant, il illustre un principe beaucoup plus général : un système automatique doit aussi savoir interpréter l’absence d’information.
Peut-on avoir un nœud Bitcoin complet sans conserver une énorme base de données ?
Lorsqu’un nœud Bitcoin valide le réseau, il doit notamment savoir quels bitcoins peuvent encore être dépensés.
Cet ensemble est appelé UTXO : les sorties de transactions qui n’ont pas encore été dépensées.
Imaginez une immense liste de chèques encore valables.
Pour vérifier un nouveau paiement, il faut pouvoir déterminer rapidement si le « chèque » présenté existe toujours et n’a pas déjà été utilisé.
Utreexo cherche à changer la manière dont cette information est conservée.
Au lieu de stocker toute la liste, le nœud pourrait conserver une sorte d’empreinte cryptographique extrêmement compacte et recevoir les preuves nécessaires au moment de vérifier les transactions.
Le bénéfice potentiel est important : réduire fortement le stockage nécessaire à un nœud validant.
Mais il y a un prix.
Ce que vous ne stockez plus localement doit souvent vous être fourni par le réseau.
Dans l’approche actuelle étudiée par les développeurs, les preuves nécessaires pendant la synchronisation initiale peuvent représenter énormément de données : Optech évoque environ 1,3 To au total, et encore environ 200 Go pour certaines preuves de suppression même avec une importante mise en cache.
La nouvelle proposition cherche précisément à supprimer une grande partie de cette surcharge pendant la première synchronisation.
L’idée est astucieuse : si l’on sait déjà qu’une sortie Bitcoin a été dépensée plus tard dans l’histoire de la blockchain, pourquoi l’ajouter temporairement à la structure pour devoir ensuite prouver sa suppression ?
On peut éviter une partie de ce travail.
Les développeurs envisagent pour cela de réutiliser des informations issues de SwiftSync, une autre technique développée pour accélérer la synchronisation initiale. La proposition pourrait rendre la surcharge liée à ces preuves de suppression presque nulle pendant cette phase.
Ce n’est encore qu’un travail de développement.
Mais l’enjeu mérite d’être suivi : plus il devient simple et peu coûteux de faire fonctionner son propre nœud, plus la vérification individuelle de Bitcoin reste accessible.
Lightning : une mise à jour à ne pas ignorer pour les opérateurs Eclair
Le troisième sujet est beaucoup plus immédiatement opérationnel.
Eclair 0.14.3 est une version de sécurité de cette implémentation de Lightning.
Elle corrige plusieurs problèmes pouvant être exploités par des pairs malveillants, notamment autour de la fermeture des canaux, du splicing et de certains financements à la volée. Les développeurs recommandent fortement la mise à niveau.
Un cas est particulièrement parlant.
Lors de certaines négociations de fermeture d’un canal, un pair pouvait proposer des frais excessifs. Le mécanisme de repli pouvait dans certaines circonstances accepter ces frais et réduire fortement le solde local du canal.
La correction ajoute notamment des limites permettant de refuser des taux de frais anormalement élevés.
Pour un utilisateur classique d’un wallet Lightning, ces détails resteront probablement invisibles.
Pour une entreprise ou un opérateur qui administre sa propre infrastructure Lightning, le message est beaucoup plus simple :
la sécurité ne s’arrête pas à la protection de la seed.
Maintenir ses logiciels à jour, surveiller les annonces de sécurité et comprendre les changements susceptibles d’affecter ses fonds font partie intégrante de l’auto-hébergement.
Un autre changement concret : BitBoxApp expérimente Spark
Cette édition signale également l’arrivée dans BitBoxApp 4.52.0 mobile d’un portefeuille chaud Lightning en bêta publique utilisant le SDK Breez et les statechains Spark.
C’est intéressant parce que cela illustre une tendance plus large : différentes solutions cherchent à rendre l’expérience de paiement Bitcoin plus fluide sans demander à l’utilisateur de comprendre toute l’infrastructure sous-jacente.
Je traiterais néanmoins ce sujet séparément plutôt que de le mélanger au cœur de cette édition.
Ce qu’il faut retenir
Cette semaine, trois problèmes très différents conduisent finalement à la même question :
comment rendre l’infrastructure Bitcoin plus robuste sans la rendre inaccessible ?
Pour le minage, cela signifie mieux adapter les systèmes aux changements réels de puissance.
Pour les nœuds, réduire les ressources nécessaires peut rendre la validation personnelle plus accessible.
Et pour Lightning, cela signifie aussi corriger rapidement les situations dans lesquelles un autre participant pourrait provoquer une perte ou un dysfonctionnement.
C’est souvent ainsi que Bitcoin progresse : moins par des fonctionnalités spectaculaires que par l’élimination progressive de petits points faibles.