Rejoignez-Nous sur

Bitcoin et activation de la fourche souple moderne – Bitcoin Magazine

Bitcoin Magazine taproot1b 1200x630 cropped

News

Bitcoin et activation de la fourche souple moderne – Bitcoin Magazine

Racine pivotante, une proposition de mise à niveau du protocole qui améliorerait la confidentialité et la flexibilité de Bitcoin, en est à ses derniers stades de développement. Les contributeurs de Bitcoin Core conviennent que la mise à niveau bénéficierait à Bitcoin, et jusqu'à présent, elle semble généralement bien accueillie par l'écosystème Bitcoin plus large. Il est donc probable que Taproot fera son chemin dans une version Bitcoin Core, avec d'autres implémentations Bitcoin à suivre.

Mais une question demeure: comment le réseau Bitcoin lui-même devrait-il se mettre à niveau? Taproot est un changement de protocole consensuel, ce qui signifie que les nœuds Bitcoin doivent en quelque sorte passer des anciennes règles aux nouvelles règles sans diviser le réseau en factions appliquant des règles différentes. Pour diverses raisons, cela s'est parfois avéré être un défi dans le passé.

Des stratégies améliorées pour activer les mises à niveau de protocole sont actuellement envisagées.

Précédent Fourches souples et BIP 9

La bonne nouvelle est que Taproot sera un soft fork. Ce type de mise à niveau ajoute ou resserre les règles – par opposition à un hard fork qui supprime ou assouplit les règles. L'avantage d'ajouter ou de resserrer des règles est que tout ce qu'un nœud mis à niveau considère comme valide, un nœud non mis à niveau le considère également comme valide. (Si un ancien nœud accepte les deux types de transaction A et B, mais que les nouvelles règles n'autorisent que le type de transaction A, l'ancien nœud resterait compatible sur un réseau appliquant les nouvelles règles.)

Les premières fourches souples de Bitcoin ont été activées pendant les jours de drapeau. Développeurs (en particulier, Satoshi Nakamoto) a intégré une date future dans le code d'une nouvelle version du client logiciel Bitcoin, spécifiant un moment où les nœuds mis à niveau appliqueraient les nouvelles règles. Les mineurs et les utilisateurs ont été encouragés à mettre à niveau avant cette date pour éviter les divisions du réseau. (En passant, à cette époque, les mineurs et les utilisateurs étaient plus souvent les mêmes personnes qu'aujourd'hui.)

Étant donné que les nœuds non mis à niveau restent compatibles avec les nouvelles règles, un avantage pratique des fourchettes logicielles est que si une majorité de puissance de hachage applique la mise à niveau, l'ensemble du réseau Bitcoin trouve un consensus sur leur version de la blockchain. Cela signifie également qu'il est moins urgent que tous les nœuds soient mis à niveau immédiatement lorsque les nouvelles règles de protocole sont appliquées, ce qui permet aux utilisateurs une certaine flexibilité. (Bien que les utilisateurs soient néanmoins encouragés à mettre à niveau; ce sont finalement eux qui appliquent les nouvelles règles en rejetant les transactions et les blocages qui les cassent.)

Depuis 2012 environ, les soft forks utilisent de plus en plus la puissance de hachage comme mécanisme de coordination pour coordonner le passage à de nouvelles règles. En incorporant un peu de données dans leurs blocs, les mineurs peuvent signaler aux autres mineurs et au reste du réseau qu'ils ont mis à niveau leur logiciel et sont donc prêts à appliquer les nouvelles règles. Une fois que suffisamment de signaux de puissance de hachage sont pris en charge, tous les nœuds mis à niveau sont déclenchés pour appliquer les nouvelles règles.

Au cours de quelques mises à niveau, cette stratégie est devenue Proposition d'amélioration Bitcoin 9 (BIP 9). Le BIP 9 était, par exemple, le mécanisme utilisé pour activer la dernière mise à jour du soft fork de Bitcoin, Témoin séparé (SegWit). Les mineurs ont eu un an pour activer la mise à niveau, nécessitant 95% des blocs dans n'importe quel intervalle de difficulté pour inclure un bit de signal de disponibilité. Si, après un an, cela ne s'était pas produit, la période d'activation expirait et la mise à niveau aurait échoué. (Il pourrait alors bien sûr être simplement réessayé.)

Pour SegWit, cependant, BIP 9 ne s'est pas bien déroulé. Comme pour certaines des mises à niveau précédentes, certains mineurs n'ont probablement pas réussi à se mettre à niveau pendant un certain temps en raison de l'apathie: il n'y a souvent pas une très grande incitation pour les mineurs à effectuer une mise à niveau rapide. Mais un problème plus important était que certains mineurs en étaient venus à comprendre le processus de signalisation comme une sorte de vote sur la mise à niveau, où au lieu de signaler la disponibilité, ils signalaient (ou ne voulaient pas) le soutien. Pire, certains mineurs ont fini par utiliser ce «vote» pour bloquer la mise à niveau afin d'essayer d'obtenir un effet de levier politique sur le processus de développement de Bitcoin, et / ou ils ont «voté» contre la mise à niveau afin de bénéficier secrètement d'une bizarrerie dans le Bitcoin protocole que la mise à niveau corrigerait.

Après une longue période de drame intense, SegWit s'est finalement activé, mais seulement après que les clients Bitcoin alternatifs aient inclus de nouveaux schémas d'activation. Le BIP 148, inclus dans le client BIP 148 géré par certains utilisateurs, a été programmé pour n'accepter que la prise en charge de la signalisation des blocs pour la mise à niveau du protocole commençant un jour de drapeau. Pendant ce temps, le BIP 91, inclus dans le client btc1 et géré par des mineurs juste avant le jour du drapeau BIP 148, a effectivement réduit les besoins en puissance de hachage de 95% à 75%. Face à un potentiel de réseau fractionné et à une éventuelle perte de revenus, les mineurs encombrants ont concédé. Mais pour la plupart des développeurs Bitcoin Core, BIP 9 s'était révélé être une solution sous-optimale, et ils ont commencé à penser à des alternatives.

BIP 8

BIP 8 était une première alternative pour BIP 9, proposée par l'auteur de BIP 148 Shaolinfry et le contributeur de Bitcoin Knots et Bitcoin Core Luke-jr. Il ressemblait initialement au BIP 9, mais avec une différence cruciale: au lieu que la mise à niveau échoue après un an de prise en charge insuffisante de la puissance de hachage, il ferait exactement le contraire et activerait la fourche souple à ce moment-là. Semblable à un jour de drapeau, tous les nœuds mis à niveau commenceraient dès lors à appliquer les nouvelles règles. Les mineurs qui n’auraient toujours pas réussi à mettre à niveau risqueraient d’exploiter des blocs que les mineurs et les utilisateurs améliorés rejetteraient.

L'idée principale derrière BIP 9 est que – en supposant bien sûr que les utilisateurs se mettent à niveau – les mineurs ne peuvent pas bloquer le soft fork et ne peuvent donc pas utiliser cet effet de levier à leur avantage. Ils peuvent accélérer l'activation et aider à coordonner une mise à niveau fluide du protocole, mais la mise à niveau se produira éventuellement même s'ils ne l'activent pas eux-mêmes.

Une version plus récente du BIP 8 inclut des changements notables. D'une part, BIP 8 permet aux nœuds d'être configurés pour deux politiques différentes lorsque la période de signalisation est sur le point d'expirer: activation forcée, comme expliqué dans les deux paragraphes précédents, ou pas d'activation forcée, comme avec BIP 9. En outre, au lieu d'activer le se mettre à niveau, les nœuds (s'ils sont configurés) appliquent réellement signalisation pour la mise à niveau. Les blocs qui ne signalent pas la prise en charge de la mise à niveau sont ensuite rejetés, garantissant ainsi la mise à niveau, au moins pour les nœuds mis à niveau. La combinaison de ces deux changements a la propriété intéressante que si la majorité de toute la puissance de hachage Bitcoin est obligée de signaler la prise en charge de la mise à niveau, même les nœuds BIP 8 qui ne sont pas configurés pour appliquer la signalisation suivront la mise à niveau,

Un argument contre BIP 8, et sa signalisation forcée (ou activation automatique) en particulier, est qu'il peut être risqué, en particulier sur une chronologie plus courte. Si une majorité de puissance de hachage et au moins certains utilisateurs ne mettent pas à niveau, ce schéma pourrait diviser le réseau entre les nœuds mis à niveau et non mis à niveau. En supposant que la plupart des utilisateurs prennent en charge la mise à niveau, cela se résoudrait probablement en faveur de la partie mise à niveau du réseau. Mais les utilisateurs non mis à niveau risqueraient de perdre des fonds entre-temps, tandis que les mineurs non améliorés gaspilleraient de l'énergie de hachage au détriment de la sécurité de Bitcoin.

Ce risque est probablement mieux contré en offrant suffisamment de temps pour la mise à niveau. Malheureusement, tout le monde n'est pas d'accord sur le temps suffisant; certains pensent que la signalisation forcée pourrait démarrer d'ici un an, d'autres pensent que cela devrait prendre plusieurs années.

Une autre complication avec BIP 8 est la définition des valeurs par défaut pour la signalisation forcée. Si la signalisation forcée est désactivée par défaut, les utilisateurs peuvent se retrouver sans coordination, augmentant le risque de fractionnement du réseau. Si, d'autre part, la signalisation forcée est choisie comme valeur par défaut dans une version Bitcoin Core, l'adoption historiquement répandue de Bitcoin Core garantit pratiquement que la mise à niveau se produira. Certains pensent que cela donnerait aux développeurs Bitcoin Core une trop grande influence sur les règles de protocole de Bitcoin. Pour cette raison, le co-auteur du BIP 8, Luke-jr, préfère que le BIP 8 avec signalisation forcée soit exclusivement déployé via des clients spéciaux, similaire au client BIP 148.

D'autres soutiennent que les développeurs Bitcoin Core publient toujours des logiciels à leur meilleur jugement, tout en gardant à l'esprit la demande des utilisateurs et en évitant les mises à niveau litigieuses; la définition des valeurs par défaut de BIP 8 ne devrait pas faire exception à cette politique. Si quelqu'un n'est pas d'accord avec les choix des développeurs Bitcoin Core, ils peuvent simplement choisir de ne pas mettre à niveau vers une nouvelle version ou même de bifurquer le code Bitcoin Core pour lancer un client concurrent.

Activation de fourche souple moderne

Bien que les développeurs Bitcoin Core cherchent en effet à prendre en compte la demande des utilisateurs et à éviter les mises à niveau litigieuses, tout le monde n'est pas convaincu que cela soit toujours parfaitement possible. Les préoccupations concernant une mise à niveau proposée n'apparaissent peut-être que lorsque le logiciel est déployé dans une nouvelle version. Peut-être que de nouveaux problèmes surviennent après cette version. Ou peut-être que les développeurs de Bitcoin Core ont tout simplement manqué quelque chose.

C'est l'une des raisons pour lesquelles le contributeur de Bitcoin Core, Matt Corallo, a proposé une stratégie baptisée «Activation de fourche souple moderne. » L'activation moderne de Soft Fork se compose de trois étapes, réalisant ensemble une combinaison de BIP 9 (ou: BIP 8 sans signalisation forcée) et BIP 8 avec activation du jour du drapeau (bien que la signalisation forcée puisse également être une option).

Dans un premier temps, le BIP 9 permettrait aux mineurs d'activer le soft fork via la puissance de hachage. Si les mineurs ne l’activent pas (disons) dans un an, la première fenêtre d’activation expire. Ensuite, comme deuxième étape, les développeurs prennent un certain temps pour analyser pourquoi l'activation a échoué et reconsidérer la proposition s'ils trouvent un problème avec elle. S'ils trouvent qu'il n'y a pas eu de problème avec la proposition, cependant, la troisième étape est le redéploiement de la fourchette souple, cette fois en utilisant BIP 8 avec activation du jour du drapeau: les mineurs ont une autre chance d'activer la proposition avec la puissance de hachage, mais s'ils échouent à nouveau , la fourche souple s'active à la fin de cette seconde période de signalisation. (Au cours de cette deuxième période de signalisation, le seuil d'activation de la puissance de hachage pourrait également être abaissé progressivement au fil du temps, contributeur de Bitcoin Core AJ Towns suggère.)

En s'engageant explicitement à redéployer le BIP 8 s'il s'avère qu'il n'y a rien de mal à la proposition, Corallo pense que la stratégie offrirait les avantages du BIP 9 sans l'inconvénient. Le code est publié pendant la première période de signalisation pour que tout le monde puisse en tenir compte, les mineurs peuvent coordonner une mise à niveau en douceur s'ils le souhaitent, et sans activation forcée, les développeurs peuvent prendre leur temps pour reconsidérer la proposition si l'activation échoue initialement. Pendant ce temps, les mineurs auraient beaucoup moins à gagner à bloquer la mise à niveau sans raison valable, car tout le monde sait qu'elle s'activera de toute façon.

L'argument principal contre l'activation de Soft Soft Modern est que sans la coopération des mineurs, le processus prendrait relativement de temps et certains considèrent l'étape BIP 9 comme une perte de temps. La proposition originale de Corallo comprend un an de signalisation BIP 9, suivi de six mois pour reconsidérer, et enfin deux ans de signalisation BIP 8 avant activation automatisée: un total de trois ans et demi. Bien que ce calendrier ne soit bien sûr pas encore gravé dans le marbre, raccourcir trop les différentes étapes laisserait moins de temps pour la reconsidération et / ou la mise à niveau (augmentant le risque de fractionnement du réseau).

En raison du long délai avant l'activation forcée potentielle, certains affirment également que les mineurs peuvent essayer d'obtenir un certain poids politique après tout: ils peuvent retarder la mise à niveau pendant des années.

BIP 8 + BIP 91

Une autre suggestion récente circulant dans les canaux technologiques de Bitcoin est peut-être mieux décrite comme une fusion entre BIP 8 et Modern Soft Fork Activation, du moins dans l'esprit. La proposition sans nom déploierait une longue période de signalisation BIP 8, peut-être aussi longue que les trois ans et demi de Modern Soft Fork Activation, après quoi la signalisation forcée se déclenche. Cependant, si après (par exemple) un an, la mise à niveau n'était pas encore activée, les développeurs prendraient un certain temps pour reconsidérer la proposition, comme ils le feraient avec l'activation de Modern Soft Fork.

Si les développeurs ne trouvaient aucun problème avec la proposition et devaient plutôt conclure qu'elle ne s'était tout simplement pas activée en raison de l'apathie des mineurs ou d'une autre raison invalide, ils pourraient choisir de déployer un nouveau soft fork dans le style de BIP 91, utilisé pendant SegWit Activation. Cela abaisserait effectivement le seuil de puissance de hachage pour l'activation, accélérant vraisemblablement le processus.

Si, d'un autre côté, les développeurs trouvaient un problème avec la proposition après tout, ils pourraient déployer un nouveau soft fork qui résoudrait le problème, ou même annuler complètement le soft fork d'origine (dans ce cas, Taproot). En supposant que le délai de trois ans et demi de l'activation de Soft Fork moderne jusqu'à la signalisation forcée, il devrait y avoir suffisamment de temps pour s'occuper de cela.

Le principal argument contre cette proposition est probablement qu'il n'est pas très élégant de déployer une fourche souple qui annule une autre fourche souple, si nécessaire. Plus concrètement, cela nécessite que les mineurs et les utilisateurs passent à de nouvelles versions avant que les délais ne soient atteints, ou risquent de diviser le réseau.

Sporks

Enfin, comme une idée quelque peu aberrante, Jeremy Rubin, contributeur de Bitcoin Core, a suggéré qu'un concept qu'il a inventé s'appelle les fourchettes logicielles probabilistes Bitcoin, ou "Sporks, ”Peut être plus compatible avec les incitations que les fourches souples classiques à puissance de hachage.

Le cœur du problème du BIP 9, soutient Rubin, est que les mineurs peuvent retarder les mises à niveau sans aucun coût. Le simple fait de refuser de signaler la disponibilité pour une mise à niveau est gratuit, alors qu'il peut potentiellement leur donner un poids politique.

Avec Sporks, le signal de préparation n'est plus pris à partir d'un peu de données que les mineurs incluent dans les blocs qu'ils extraient, mais dérivé du hachage d'en-tête de bloc: la preuve de travail générée aléatoirement qu'ils ont produite en investissant du temps et des ressources. Les nœuds mis à niveau conviendraient qu'un petit sous-ensemble de hachages d'en-tête de bloc valides – statistiquement disponible uniquement tous les six mois environ – déclencherait la mise à niveau.

Par le caractère aléatoire des hachages, un mineur ne contrôlerait pas s'il produit des hachages d'en-tête de bloc réguliers ou des hachages d'en-tête de bloc d'activation de mise à niveau; il arriverait statistiquement qu'il se produise un de ces derniers sporadiquement. Ainsi, si ses ressources investies génèrent un hachage d'en-tête de bloc d'activation de la mise à niveau, il aura deux choix. Soit, publiez-le sur le réseau Bitcoin, gagnez la récompense de bloc et activez le soft fork. Ou, ne pas publier, retarder le soft fork d'environ six mois en moyenne dans notre exemple… mais ce faisant, renoncer également à la récompense de bloc. Retarder la mise à niveau coûterait cher.

Le principal problème avec Sporks à l'heure actuelle est probablement qu'il s'agit d'une idée relativement nouvelle, qui n'a pas encore été développée – et encore moins testée dans la nature. Bien que certains considèrent le concept intéressant, ce n'est pas encore le candidat le plus probable à l'activation de Taproot.

Note de l’auteur: Le débat sur l’activation de la fourche souple (et l’activation de la racine pivotante en particulier) est en évolution; il s'agit d'un aperçu non exhaustif des différentes propositions de mise à niveau, en particulier lorsqu'il s'agit de variantes des propositions avec des paramètres alternatifs et d'autres ajustements, et tous leurs avantages et inconvénients.

Mettre à jour

Une autre idée, qui gagne du terrain depuis la rédaction de cet article (principalement), consiste à déployer d'abord le BIP 8 avec une période de signalisation relativement longue (disons deux ans), configuré sans signalisation forcée à la fin de cette période de signalisation. Cela permet aux mineurs d'activer le soft fork de manière relativement normale, comme ils l'ont fait à plusieurs reprises dans le passé. Cependant, si après un certain temps (par exemple, six mois), le soft fork n'est pas activé et qu'il ne semble pas y avoir de bonne raison pour le retard, un nouveau client peut être libéré avec BIP 8 configuré pour forcer la signalisation à proximité du fin de la période de signalisation existante, ou plus tôt. En supposant que la plupart des mineurs activent alors le soft fork avant ou pendant cette période de signalisation forcée, les deux ensembles de nœuds BIP 8 (avec et sans la configuration de signalisation forcée) appliqueraient le soft fork lors de l'activation.



Traduction de l’article de Aaron van Wirdum : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Les Plus Populaires

Acheter des Bitcoin

Acheter des Alt-Coins

Sécuriser vos Cryptos

Vêtements et Produits Dérivés

Top