diff --git a/_includes/specials/policy/fr/07-ressources-du-reseau.md b/_includes/specials/policy/fr/07-ressources-du-reseau.md new file mode 100644 index 000000000..b7e367304 --- /dev/null +++ b/_includes/specials/policy/fr/07-ressources-du-reseau.md @@ -0,0 +1,81 @@ +Un article précédent traitait de la protection des ressources des nœuds, qui peut être unique +à chaque nœud et donc parfois configurable. Nous avons également expliqué pourquoi il est préférable +de converger vers une seule politique, mais qu'est-ce qui doit faire partie de cette politique ? +Ce billet aborde le concept de ressources à l'échelle du réseau, essentielles pour des aspects tels +que l'évolutivité, la mise à niveau et l'accessibilité du démarrage et de la maintenance d'un nœud complet. + +Comme nous l'avons vu dans les [articles précédents][policy01], de nombreux objectifs idéologiques +du réseau Bitcoin sont incarnés par sa structure distribuée. La nature pair-à-pair de Bitcoin permet +aux règles du réseau d'émerger d'un consensus approximatif des choix des opérateurs de nœuds individuels +et limite les tentatives d'acquisition d'une influence indue sur le réseau. Ces règles sont ensuite +appliquées par chaque nœud qui valide individuellement chaque transaction. Une population de nœuds +diversifiée et saine exige que le coût d'exploitation d'un nœud soit maintenu à un niveau bas. Il est +difficile de faire évoluer un projet avec une audience mondiale, mais le faire sans sacrifier la +décentralisation revient à se battre avec une main attachée dans le dos. Le projet Bitcoin tente +de trouver cet équilibre en protégeant farouchement les ressources partagées du réseau : le stock +d'UTXO, l'empreinte des données de la blockchain et l'effort de calcul nécessaire pour les traiter, +ainsi que les mises à jour permettant de faire évoluer le protocole Bitcoin. + +Il n'est pas nécessaire de revenir sur la guerre des tailles de blocs pour comprendre qu'une limite à +la croissance de la blockchain est nécessaire pour que l'exploitation de son propre nœud reste abordable. +Cependant, la croissance de la blockchain est également dissuadée au niveau politique par le `minRelayTxFee` +de 1 sat/vbyte, assurant un coût minimum pour exprimer une partie de la " [demande illimitée de stockage +perpétuel hautement répliqué][unbounded] ". + +À l'origine, l'état du réseau était déterminé en conservant toutes les transactions dont les résultats +n'avaient pas encore été dépensés. Cette partie beaucoup plus importante de la blockchain a été réduite de +manière significative avec l'[introduction du jeu d'UTXO][ultraprune] comme moyen de suivre les fonds. +Depuis lors, le jeu d'UTXO est une structure de données centrale. En particulier pendant les IBD, mais +aussi de manière générale, les consultations d'UTXO représentent une part importante de tous les accès +à la mémoire d'un nœud. Bitcoin Core utilise déjà une [structure de données optimisée manuellement pour +le cache UTXO][pooled resource], mais la taille du jeu d'UTXO détermine la quantité qu'il ne peut pas +contenir dans le cache d'un nœud. Un ensemble d'UTXO plus important se traduit par un plus grand nombre +d'échec du cache, ce qui ralentit la vitesse de validation des blocs, de l'IBD et de la transaction. +La limite des poussières (dust limit) est un exemple de politique qui restreint la création d'UTXO, en particulier les +UTXO qui pourraient ne jamais être dépensés parce que leur montant [n'est pas à la hauteur][topic uneconomical outputs] +du coût de leur dépense. Malgré cela, des ["tempêtes de poussière" avec des milliers de transactions se +sont produites pas plus tard qu'en 2020][lopp storms]. + +Lorsqu'il est devenu populaire d'utiliser des sorties multisig brutes pour publier des données sur la +blockchain, la définition des transactions standards a été modifiée pour permettre une sortie OP_RETURN +unique en tant qu'alternative. Les gens ont réalisé qu'il serait impossible d'empêcher les utilisateurs +de publier des données sur la blockchain, mais qu'au moins ces données n'auraient pas besoin de vivre dans +le jeu d'UTXO pour toujours lorsqu'elles sont publiées dans des sorties qui ne peuvent jamais être dépensées. +Bitcoin Core 0.13.0 a introduit une option de démarrage `-permitbaremultisig` que les utilisateurs peuvent +activer pour rejeter les transactions non confirmées avec des sorties multisig brutes. + +Bien que les règles de consensus permettent aux scripts de sortie d'être libres, seuls quelques modèles bien +compris sont relayés par les nœuds de Bitcoin Core. Il est ainsi plus facile de comprendre les nombreuses +préoccupations du réseau, notamment les coûts de validation et les mécanismes de mise à jour du protocole. +Par exemple, un script d'entrée qui contient des op-codes, une entrée P2SH avec plus de 15 signatures, ou une +entrée P2WSH dont la pile de témoins contient plus de 100 éléments chacun, rendrait une transaction non standard. +(Consultez cette [vue d'ensemble des politiques][instagibbs policy zoo] pour plus d'exemples de politiques et leurs motivations). + +Finalement, le protocole Bitcoin est un projet logiciel vivant qui devra continuer à évoluer pour répondre aux +défis futurs et aux besoins des utilisateurs. À cette fin, il existe un certain nombre de mécanismes de mise à +jour qui ont délibérément laissé le consensus valide mais inutilisé, tels que l'annexe, les versions des leaf +taproots, les versions des témoins, OP_SUCCESS et un certain nombre d'opcodes no-op. Cependant, tout comme les +attaques sont entravées par l'absence de points centraux de défaillance, les mises à jour logicielles à l'échelle +du réseau impliquent un effort coordonné entre des dizaines de milliers d'opérateurs de nœuds indépendants. +Les nœuds ne relaieront pas les transactions qui utilisent les hooks de mise à niveau réservés tant que leur +signification n'aura pas été définie. Cette mesure vise à dissuader les applications de créer indépendamment des +normes contradictoires, ce qui rendrait impossible l'adoption de la norme d'une application dans le consensus sans +invalider celle d'une autre application. En outre, lorsqu'un changement de consensus se produit, les nœuds qui ne +sont pas mis à niveau immédiatement---et qui ne connaissent donc pas les nouvelles règles de consensus---ne peuvent +pas être "trompés" en acceptant une transaction désormais invalide dans leur pool de mémoires. Ce découragement +proactif aide les nœuds à être compatibles avec l'avenir et permet au réseau de mettre à jour les règles de +consensus en toute sécurité sans nécessiter une mise à jour logicielle entièrement synchronisée. + +Nous pouvons voir que l'utilisation d'une politique pour protéger les ressources partagées du réseau aide à protéger +les caractéristiques du réseau, et maintient ouvertes les voies pour le développement de protocoles futurs. Pendant +ce temps, nous voyons comment la friction de la croissance du réseau contre une blockchain strictement limitée a +conduit à l'adoption de meilleures pratiques, d'une bonne conception technique et de l'innovation : le billet de +la semaine prochaine explorera la politique de mempool comme une interface pour les protocoles de deuxième couche +et les systèmes de contrats intelligents. + +[policy01]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[unbounded]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html +[lopp storms]: https://blog.lopp.net/history-bitcoin-transaction-dust-spam-storms/ +[ultraprune]: https://github.com/bitcoin/bitcoin/pull/1677 +[pooled resource]: /fr/newsletters/2023/05/03/#bitcoin-core-25325 +[instagibbs policy zoo]: https://gist.github.com/instagibbs/ee32be0126ec132213205b25b80fb3e8 diff --git a/_posts/fr/2023-05-17-policy.md b/_posts/fr/2023-05-17-policy.md index b9c8dd5cb..f9e1a9edb 100644 --- a/_posts/fr/2023-05-17-policy.md +++ b/_posts/fr/2023-05-17-policy.md @@ -63,6 +63,12 @@ h2:not(:first-of-type) { margin-top: 3em; } {% include specials/policy/fr/06-consistence.md %} +## Ressources du réseau + +*Originally published in [Newsletter #257](/fr/newsletters/2023/06/28/#en-attente-de-confirmation-7--ressources-du-réseau)* + +{% include specials/policy/fr/07-ressources-du-reseau.md %} + {% comment %}{% endcomment %} +{% assign bse = "https://bitcoin.stackexchange.com/a/" %} + +- [Pourquoi les nœuds Bitcoin acceptent-ils des blocs contenant autant de transactions exclues ?]({{bse}}118707) + L'utilisateur commstark se demande pourquoi un nœud accepte un bloc de mineurs + qui exclut les transactions prévues pour ce bloc selon le [modèle de bloc][reference getblocktemplate] + de ce nœud. Il existe divers [outils][miningpool observer] qui [montrent][mempool space] + les blocs prévus par rapport aux blocs réels. Pieter Wuille souligne qu'en raison de la + variance inhérente aux [mempools][waiting for confirmation 1] des différents nœuds liés + à la propagation des transactions, il n'est pas possible d'établir une règle de consensus + imposant le contenu des blocs. {% assign timestamp="57:38" %} + +- [Pourquoi tout le monde prétend-il que les soft forks restreignent l'ensemble des règles existantes ?]({{bse}}118642) + Pieter Wuille utilise les règles ajoutées lors des [activations][topic soft fork activation] + des soft forks [taproot][topic taproot] et [segwit][topic segwit] comme exemples + de renforcement des règles de consensus : + + - taproot a ajouté l'exigence que les dépenses de sortie `OP_1 <32 bytes>` (taproot) + adhèrent aux règles de consensus de taproot. + - segwit a ajouté l'exigence que `OP_{0..16} <2..40 bytes>` (segwit) adhèrent aux + règles de consensus segwit et exigent également des données témoins vides pour + les sorties pré-segwit. {% assign timestamp="1:05:28" %} + +- [Pourquoi la limite par défaut du canal LN est-elle fixée à 16777215 sats ?]({{bse}}118709) + Vojtěch Strnad explique l'histoire de la limite de 2^24 satoshi et la motivation + pour les grands canaux (wumbo). Il renvoie également au [thème des grands canaux][topic large channels] + d'Optech pour plus d'informations. {% assign timestamp="1:07:47" %} + +- [Pourquoi Bitcoin Core utilise-t-il le score de l'ascendant au lieu de son taux de frais pour sélectionner les transactions ?]({{bse}}118611) + Sdaftuar explique que l'optimisation des performances est la raison pour laquelle + l'algorithme de sélection des transactions du modèle de bloc minier utilise à la fois + le taux de frais et le score des ascendants. (Voir + [En attente de confirmation n° 2 : Incitations][waiting for confirmation 2]). {% assign timestamp="1:10:28" %} + +- [Comment le protocole Lightning multipart payments (MPP) définit-il les montants par part ?]({{bse}}117405) + Rene Pickhardt souligne que [les paiements par trajets multiples][topic multipath payments] + n'ont pas de taille de part spécifiée par le protocole ou d'algorithme pour choisir la taille + de la part et indique quelques recherches pertinentes sur le fractionnement des paiements. {% assign timestamp="1:14:15" %} + +## Mises à jour et versions candidates + +*Nouvelles versions et versions candidates pour les principaux projets d’infrastructure Bitcoin. + Veuillez envisager de passer aux nouvelles versions ou d’aider à tester les versions candidates.* + +- [BTCPay Server 1.10.3][] est la dernière version de ce logiciel de traitement de paiement + auto-hébergé. Consultez leur [billet de blog][btcpay 1.10] pour une visite des principales + fonctionnalités de la branche 1.10. {% assign timestamp="1:16:08" %} + +## Changements notables dans le code et la documentation + +*Changements notables cette semaine dans [Bitcoin Core][bitcoin core repo], [Core +Lightning][core lightning repo], [Eclair][eclair repo], [LDK][ldk repo], +[LND][lnd repo], [libsecp256k1][libsecp256k1 repo], [Hardware Wallet +Interface (HWI)][hwi repo], [Rust Bitcoin][rust bitcoin repo], [BTCPay +Server][btcpay server repo], [BDK][bdk repo], [Bitcoin Improvement +Proposals (BIPs)][bips repo], [Lightning BOLTs][bolts repo], et +[Bitcoin Inquisition][bitcoin inquisition repo].* + +- [Core Lightning #6303][] ajoute une nouvelle RPC `setconfig` qui permet + de changer certaines options de configuration sans redémarrer le démon. {% assign timestamp="1:21:14" %} + +- [Eclair #2701][] commence l'enregistrement à la fois au moment où un + [HTLC][topic htlc] offert est reçu et au moment où il est réglé. Cela + permet de savoir combien de temps le HTLC a été en attente du point de + vue du nœud. Si de nombreux HTLC, ou quelques HTLC de grande valeur, + sont en attente pendant de longues périodes, cela peut indiquer qu'une + [attaque par brouillage de canal][topic channel jamming attacks] est en + cours. Le suivi de la durée des HTLC permet de détecter de telles attaques + et peut contribuer à les atténuer. {% assign timestamp="1:22:21" %} + +- [Eclair #2696][] modifie la façon dont Eclair permet aux utilisateurs de + configurer les taux de frais à utiliser. Auparavant, les utilisateurs pouvaient + spécifier la vitesse à utiliser avec un _block target_, par exemple, un + réglage de "6" signifiait qu'Eclair essaierait de faire confirmer une + transaction dans un délai de six blocs. Désormais, Eclair accepte les + termes "lent", "moyen" et "rapide", qu'il traduit en taux de frais spécifiques + à l'aide de constantes ou de cibles de blocs. {% assign timestamp="1:25:03" %} + +- [LND #7710][] ajoute la possibilité pour les plugins (ou le démon lui-même) + de récupérer les données reçues plus tôt dans un HTLC. Ceci est nécessaire pour + le [route aveugle][topic rv routing] et peut être utilisé par diverses contre-mesures + de [brouillage de canal][topic channel jamming attacks], parmi d'autres idées + pour de futures fonctionnalités. {% assign timestamp="1:26:51" %} + +- [LDK #2368][] permet d'accepter de nouveaux canaux créés par un pair qui utilise + des [sorties d'ancrage][topic anchor outputs] mais exige que le programme de contrôle + choisisse délibérément d'accepter chaque nouveau canal. En effet, pour régler correctement + un canal d'ancrage, l'utilisateur doit avoir accès à un ou plusieurs UTXO de valeur suffisante. + LDK, en tant que bibliothèque ignorant quels UTXOs non-LN le portefeuille de l'utilisateur + contrôle, utilise cette requête pour donner au programme de contrôle une chance de vérifier + qu'il a les UTXOs nécessaires. {% assign timestamp="1:27:43" %} + +- [LDK #2367][] rend les [canaux d'ancrage][topic anchor outputs] accessibles aux consommateurs + réguliers de l'API. {% assign timestamp="1:33:34" %} + +- [LDK #2319][] permet à un pair de créer un HTLC qui s'engage à payer moins que le montant que + le contributeur original a dit devoir être payé, ce qui permet au pair de garder la différence + pour lui-même en tant que frais supplémentaires. Ceci est utile pour la création de [JIT channels][topic jit channels] + où un pair reçoit un HTLC pour un destinataire qui n'a pas encore de canal. Le pair crée une + transaction onchain qui finance le canal et s'engage dans le HTLC au sein de ce canal---mais + il encourt des frais de transaction supplémentaires en créant cette transaction onchain. En prenant + des frais supplémentaires, il est compensé pour ses coûts si le destinataire accepte le nouveau canal + et règle le HTLC à temps. {% assign timestamp="1:34:40" %} + +- [LDK #2120][] ajoute la prise en charge de la recherche d'un itinéraire vers un destinataire + qui utilise des [chemins aveugles][topic rv routing]. {% assign timestamp="1:37:09" %} + +- [LDK #2089][] ajoute un gestionnaire d'événement qui permet aux portefeuilles de déclencher + facilement les [HTLC][topic htlc] qui doivent être réglés onchain. {% assign timestamp="1:38:12" %} + +- [LDK #2077][] remanie une grande partie du code pour faciliter l'ajout ultérieur de la prise + en charge des [canaux à double financement][topic dual funding]. {% assign timestamp="1:39:08" %} + +- [Libsecp256k1 #1129][] implémente la technique [ElligatorSwift][ElligatorSwift paper] pour introduire + un encodage de clé publique de 64 octets qui est informatiquement indiscernable des données aléatoires. + Le module `ellswift` fournit des fonctions pour encoder et décoder les clés publiques dans le nouveau + format ainsi que des fonctions de commodité pour générer de nouvelles clés uniformément aléatoires et + effectuer un échange de clés Diffie-Hellman à courbe elliptique (ECDH) sur les clés encodées ellswift. + L'ECDH basé sur ellswift doit être utilisé pour établir des connexions pour le protocole [transport P2P + chiffré version 2] [topic v2 p2p transport] ([BIP324][]). {% assign timestamp="1:40:37" %} + +{% include references.md %} +{% include linkers/issues.md v=2 issues="6303,2701,2696,7710,2368,2367,2319,2120,2089,2077,1129" %} +[policy series]: /fr/blog/waiting-for-confirmation/ +[sanders v3cj]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021780.html +[linus spec]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021781.html +[BTCPay Server 1.10.3]: https://github.com/btcpayserver/btcpayserver/releases/tag/v1.10.3 +[btcpay 1.10]: https://blog.btcpayserver.org/btcpay-server-1-10-0/ +[miningpool observer]: https://miningpool.observer/template-and-block +[mempool space]: https://mempool.space/graphs/mining/block-health +[waiting for confirmation 1]: /fr/newsletters/2023/05/17/#en-attente-de-confirmation-1--pourquoi-avons-nous-un-mempool- +[reference getblocktemplate]: https://developer.bitcoin.org/reference/rpc/getblocktemplate.html +[waiting for confirmation 2]: /fr/newsletters/2023/05/24/#en-attente-de-confirmation-2--mesures-dincitation +[ElligatorSwift paper]: https://eprint.iacr.org/2022/759