- Retour au menu
- Retour au menuTarifs
- Retour au menuRecherche
- Retour au menu
- Retour au menu
- Retour au menu
- Retour au menu
- Retour au menuWebinaires et Événements
Entre le marteau et l'enclume : le plan de Jeff Garzik pour éviter une scission du Bitcoin
Peut-être qu'aucun codeur n'est plus au centre du débat houleux sur la mise à l'échelle du bitcoin que Jeff Garzik – il parle ici de l'avenir du réseau.

Jeff Garzik a été accusé de beaucoup de choses ces derniers temps.
Depuis qu'il a pris les devants en tournant leSegwit2x accord de mise à l'échelle dans le code, le PDG de la startup blockchain Bloq a été accusé de tout, depuisfermetureLe développement open source de Bitcoin encourage inutilementagressifLe réseau change pour jouer avec les faits afin d'influencer l'opinion publique sur le plan.
Mais si le développeur de longue date, ONEun des premiers employé par une startuptravailler directement avec le logiciel sous-jacent de Bitcoin, est apparu comme un paratonnerre, Garzik semble enthousiaste à propos du rôle.
Aimeaffronter les critiques Dans de longs échanges sur Twitter, Garzik est peut-être le seul parmi les développeurs de Bitcoin à afficher un état d'esprit entrepreneurial largement axé sur la prise en charge, ce qui le place en désaccord avec le groupe de développeurs plus soucieux de la sécurité du projet, Bitcoin CORE.
Mais si Garzik est sous surveillance maintenant, il est probable qu'il y reste encore un certain temps.

Bien qu'il reste encore quelques étapes avant que la mise à niveau de capacité tant attendue du Bitcoin ne soit une réalité,affaire conclue(il semble de plus en plus probable que les mineurs de Bitcoin pousseront une mise à niveau de mise à l'échelle d'ici la fin août), les changements de code qu'il supervise ne devraient T être conclus avant l'automne.
C'est à ce moment-là qu'ils atteindront peut-être un point de fièvre quiéclipse le débat actuel, et dans une nouvelle interview, Garzik a réitéré son intention d'introduire le code d'un hard fork qui renforcerait encore les capacités du réseau tout en le remettant sur unchemin vers une scission.
Dans ce contexte, Garzik s'est assis avec CoinDesk pour discuter de ses réflexions sur l'avenir de Segwit2x, abordant les questions clés et les controverses qui ont surgi dans les coulisses ces derniers temps.
Ci-dessous, cette interview est reproduite, bien que certains commentaires de Garzik aient été raccourcis pour plus de clarté.
Les pools miniers ont commencé à signaler le BIP 91 plus tôt que prévu cette semaine – pourquoi étant donné qu'ils ont été réticents à propos de SegWit dans le passé ?
Ils ont rongé leur BIT. ONEun des récits les plus absurdes qui circulent est que les pools miniers bloquent SegWit et n'en veulent T pour diverses raisons.
Dans la vraie vie, ils sont BIT d'activer SegWit.
Ils sont vraiment prêts à franchir le pas et à passer à la deuxième étape du scaling, qui consiste à augmenter la taille des blocs. Ils étaient prêts à passer à l'action dès que chacun pourrait lancer ses nœuds.
Le déploiement initial de SegWit n'a- T pas été bloqué en raison du manque de support du pool de minage ?
Eh bien, il ne s’agissait pas seulement de mineurs.
C'est précisément la particularité de Segwit2x. SegWit n'allait T augmenter la taille des blocs à une vitesse réaliste pour la plupart des acteurs du secteur. En soi, il s'agit d'une mise à niveau en deux étapes. D'abord, il faut mettre à niveau les nœuds pour prendre en charge ces nouvelles règles, puis il y a un processus d'un an pour mettre à jour les portefeuilles. C'est lors de cette mise à niveau des portefeuilles, deuxième étape, que SegWit apporte réellement de nouvelles capacités.
Après ce long débat controversé, un chemin uniquement SegWit ne nous laisserait qu’avec la même capacité que celle dont nous disposons actuellement.
C'est pourquoi il a stagné. Et c'est pourquoi Segwit2x fait avancer les choses. Il offre une capacité garantie à court terme. C'est l'augmentation de la taille de bloc de base. Et il pose les bases du long terme : c'est SegWit.
Les pools de minage exécutent déjà le code. Est-il prudent pour eux de le faire même si la version finale T disponible ?
Absolument. Les règles de consensus n'ont pas été modifiées. Ce sont les règles de sécurité qui ont été modifiées pour l'ensemble du réseau.
Nous publierons la version finale dès qu'elle sera prête. En cas de bugs, nous proposerons une deuxième, une troisième, voire une quatrième version candidate.
Il est publié dès qu'il est prêt. Il n'y a jamais de garantie avec un logiciel.
Segwit2x introduit le code SegWit sur le réseau, mais vous avez critiqué SegWit par le passé, ou du moins, vous avez procédé à des soft forks. Avez-vous changé d'avis et soutenu Segwit2x ?
Non. En gros, avec Segwit2x, il y a un soft fork court et intermédiaire, puis un hard fork qui verrouille les règles SegWit. Ce verrouillage est d'une manière A ou B. C'est ce qu'un hard fork fait, T à un soft fork. Il donne aux utilisateurs le choix de Réseaux sociaux ou non la chaîne.
Mais avec un soft fork, toutes les règles sont déjà acceptées par toutes les règles du soft fork. Vous pouvez imaginer de nombreuses situations où vous ne souhaitez T accepter automatiquement de nouvelles règles.
Un hard fork est différent dans le sens où le réseau n'accepte T automatiquement les nouvelles règles.
J'ai toujours été partisan de SegWit en tant que hard fork, car cela permet de verrouiller les règles de manière à ce que les gens les approuvent ou non. C'est le résultat de Segwit2x. Après le hard fork, les règles de SegWit sont verrouillées.
Segwit2x devrait probablement aboutir à une ONE cryptomonnaie, alors qu'un hard fork de gros blocs ou une simple mise à niveau de SegWit se retrouverait bloqué à 30 % de taux de hachage et sans consensus des nœuds économiques. Il y a les partisans de SegWit uniquement, partisans du Bitcoin CORE . Et puis il y a les partisans de l'autre camp : « Nous avons besoin de gros blocs, de Bitcoin Unlimited, ETC ».
Aucune de ces deux initiatives n'a vraiment réussi à s'imposer sur le marché. Le marché a atteint 30 %, puis s'est enlisé. La communauté était dans une impasse.
Segwit2x tente de dépasser ce blocage à un niveau élevé, dépassant le blocage des communautés, ce qui aboutit à une cryptomonnaie ONE qui ne provoque T de division de la chaîne. Cela irrite les membres de la communauté des gros bloqueurs, ainsi que certains membres de la communauté Bitcoin CORE , exclusivement dédiée à SegWit. Mais le projet bénéficie d'un soutien important et est en cours de déploiement sur le réseau, car Segwit2x est, ironiquement, le moyen le plus rapide d'activer SegWit.
De nombreux membres de la communauté ont critiqué Segwit2x pour son processus de développement fermé.
C'est assez typique des propos tenus par Peter Todd et Adam Back. C'est totalement faux. GitHub est entièrement ouvert, la liste de diffusion également. Tous les commentaires reçus ont été soigneusement pris en compte.
Les commentaires que nous avons reçus de Bitcoin CORE à ce jour ont été en grande partie des changements de type « faites ce changement qui casse tous les portefeuilles », signalant le hard fork d'une manière différente, ou simplement des commentaires GitHub perturbateurs et trollés.
On jette toutes sortes de boue. Certaines personnes n'aiment T que les choses soient faites d'une manière qu'elles T voulu faire.
La principale critique concerne le hard fork de 2 Mo. Certains développeurs pensent qu'il pourrait être réalisé de manière plus sûre ou que le délai de trois mois est trop court.
Cela nous amène au cœur du débat sur la mise à l'échelle. Ces critiques proviennent de personnes qui ont retardé la planification d'un hard fork pendant des années. C'est précisément pour cette raison que les partisans de Segwit2x souhaitent passer à autre chose. Ils n'ont T obtenu plus de 30 % de succès. SegWit est une excellente Technologies, mais elle n'est pas très performante en termes de capacité.
Capacité, vitesse de transaction élevée – et la proposition propose de prolonger un délai de plusieurs années à mesure que la capacité de SegWit augmente. C'est là le CORE du désaccord.
Ceux qui n'ont pas anticipé un hard fork et qui ont critiqué tous les hard forks le font encore plus. C'est tout à fait prévisible. Cela fait partie du processus visant à rapprocher les deux camps.
Il n’est pas surprenant que les démocrates du Bitcoin n’aiment T les républicains du Bitcoin.
Il semble que certains soient complètement opposés à un hard fork, mais certains développeurs pensent que le délai devrait être prolongé à un an au lieu de trois mois.
Je ne suis pas d'accord. Si vous parcourez l'historique de Twitter, vous verrez qu'ils le disent depuis des années. Il n'y a jamais assez de temps pour un hard fork, et pourtant cette planification n'a jamais lieu.
La communauté a perdu patience face à ce message. Il n'y a d'autre issue que le report.
Segwit2x ajoutera-t-il une protection contre la relecture en cas de hard fork ?
Certainement. Il y a eu quelques propositions.
ONE a été proposée par un contributeur de Bitcoin CORE . Cette protection contre le rejeu perturberait tous les portefeuilles ; nous considérons donc cette proposition comme peu sérieuse et perturbatrice.
L'autre proposition émanait de Gavin Andresen [ancien responsable de la maintenance de Bitcoin ]. D'autres ont proposé des formes de protection contre la rediffusion par option d'adhésion.
C’est certainement quelque chose que nous étudions, mais nous ne souhaitons pas ruiner tous les portefeuilles.
Certains utilisateurs de Bitcoin sont en désaccord avec le hard fork de Segwit2x. Cela aura-t-il un impact sur son succès ?
C'est en fait pourquoi je pense que les hard forks sont meilleurs que les soft forks.
Avec les soft forks, vous acceptez automatiquement les nouvelles règles. Si vous n'êtes pas d'accord avec un hard fork, vous n'acceptez pas automatiquement les nouvelles règles. Du point de vue de la gouvernance, c'est très, très sain.
Pour répondre à votre question, cela ne perturbera T le hard fork.
De plus, c'est une bonne chose que les gens puissent être en désaccord avec le hard fork. Le désaccord et la liberté de choix sont primordiaux et c'est ce qui fait la grandeur de Bitcoin .
Pensez-vous que cela pourrait conduire à une scission ?
Oui. Je prédis que les mineurs adopteront le logiciel BTC1, comme nous le constatons actuellement. La grande majorité des logiciels de minage resteront donc sur une ONE cryptomonnaie.
Par définition, une chaîne minoritaire se comporte d'une certaine manière. Si une grande partie de la puissance de hachage se détache de la chaîne ou, dans un scénario UASF, où de nombreux utilisateurs s'enfuient, le logiciel se comporte de manière prévisible et connue. La chaîne s'arrête. Au lieu de 10 minutes pour miner un bloc, il faut, disons, quelques heures par bloc. Il reste 2016 blocs avant une baisse progressive de la difficulté.
Pour les utilisateurs, cela signifie qu'il sera inutilisable pendant un certain temps. En cas de hard fork, la grande majorité de la puissance de hachage sera activée et sécurisera la chaîne de 2 Mo.
Il y aura une chaîne que personne n'utilisera. Troisièmement, il y aura un petit nombre d'utilisateurs activistes qui ne souhaiteront absolument T de hard fork. Et cela restera un niveau de sécurité bien plus faible.
Supposons qu'il y ait une division et que la monnaie des minorités ne fonctionne T aussi bien que vous l'avez décrit. N'est- ce T une contrainte de choix ?
Je suis d'accord. C'est tout à fait vrai. Il existe incontestablement des incitations à s'en tenir à la chaîne ayant la plus grande puissance de hachage.
Mais le problème de gouvernance est qu'il y a un choix à faire. Alors que dans un soft fork, ce n'est pas le cas. Mais chaque utilisateur doit faire ce choix.
Je pense que plus chaque utilisateur est informé, mieux c'est.
Que pensez-vous d’autres propositions de mise à l’échelle comme BIP 148 ou BitcoinABC ?
L'UASF n'a pas de puissance de hachage ni de nœuds économiques pour les soutenir.
Si Segwit2x n'avait T activé SegWit, ils se seraient retrouvés dans le scénario de chaîne inutilisable que j'ai décrit.
Il leur faudrait créer une deuxième branche de chaîne pour corriger la difficulté et revenir aux temps de bloc de 10 minutes. C'est ainsi que cela se passera sans puissance de hachage, ce qui LOOKS peu probable. Avec la puissance de hachage, comme c'est le cas actuellement, SegWit sera activé et les joueurs de l'UASF obtiendront ce qu'ils demandaient, sans division de chaîne.
BitcoinABC crée une nouvelle cryptomonnaie. Segwit2x n'aura pas d'impact majeur sur BitcoinABC lui-même. Il y aura une légère réduction de la puissance de hachage, peut-être 4 % de transferts vers BitcoinABC. Il s'agit essentiellement d'un altcoin, où chaque détenteur de Bitcoin détient une participation dans la nouvelle cryptomonnaie.
Cela ne devrait T avoir d'impact majeur sur les utilisateurs de Bitcoin ou de Segwit2x.
Certaines personnes disent que l'UASF est ce qui a conduit à Segwit2x, et que les pools miniers signalent actuellement le BIP 91 pour éviter un UASF.
Il s'agit essentiellement de maintenir l'unité. Non pas d'éviter l'UASF, mais de s'assurer que tous les membres de la chaîne principale y restent en activant SegWit. C'est la voie de l'unité. Chacun, y compris les militants de l'UASF, obtient ce qu'il veut : l'activation de SegWit.
Il parcourt le chemin Segwit2x en activant le BIT 4, ce qui devrait se verrouiller aujourd'hui. Cela activera le BIT 1, ce qui activera SegWit.
Cette activation du «BIT 4 » dans trois mois déclenchera également le changement de règle de fork.
Certains ont avancé que les chaînes latérales sont une meilleure alternative à un hard fork de 2 Mo, puisque les utilisateurs peuvent opter pour un système avec le paramètre de taille de bloc qu'ils souhaitent.
Bloq sponsorise le projet Drivechain, qui vise à ajouter des chaînes latérales utilisables à Bitcoin à l'avenir. Blockstream est à l'origine de cette proposition, mais celle-ci n'a jamais véritablement été intégrée à Bitcoin.
La Technologies Drivechain vous permet potentiellement d'avoir une chaîne latérale qui contient d'énormes blocs, T importe les règles qui s'y trouvent.
Le problème réside dans le niveau de maturité. Il s'agit d'un projet scientifique en laboratoire. Plus sécurisé, il constituerait peut-être une meilleure solution aujourd'hui, mais comme Lightning, c'est une Technologies très prometteuse qui est encore en phase de développement.
L'augmentation du paramètre de 2 Mo est donc une solution à court terme. Drivechain pourrait-il arriver plus tard ?
Exactement. En fait, le hard fork de 2 Mo est la ONE solution que nous connaissons avec une certitude absolue pour garantir une capacité accrue.
Nous ne connaissons T la capacité offerte par SegWit, car nous T combien de personnes mettront à jour leur logiciel de portefeuille pour l'activer. C'est une inconnue. Concernant Lightning, nous T connaissons rien du modèle de confiance ni des aspects économiques de ce système. Nous ne savons donc T s'il sera utilisé.
Les chaînes latérales sont également en phase de développement. Ce sont tous des projets prometteurs, mais nous ne savons T encore s'ils constitueront une solution.
Le hard fork de 2 Mo est sans aucun doute une solution provisoire en attendant une amélioration. Mais comme je le dis toujours, il faut faire attention à l'écart. C'est une question de pragmatisme, contrairement à un projet scientifique de plusieurs années qui pourrait bien aboutir.
Combien de temps prévoyez-vous de travailler sur Segwit2x ? Êtes-vous là pour le long terme ou comptez-vous arrêter après le hard fork ?
Non, c'est un projet très ciblé. Sa charte n'est pas étendue du tout. Cela correspond aux groupes de travail de l'IETF. Nous avons une charte ONE pour activer SegWit et un hard fork, et c'est tout. C'est une opération unique. On observe la même chose chez Red Hat, où je travaillais, pour le développement de spécifications logicielles et matérielles.
Lors de l'élaboration du noyau Linux, nous avons rencontré des personnes qui se détestaient, mais qui ont en réalité collaboré de manière ciblée, pour atteindre un objectif précis, comme le développement de spécifications USB. Segwit2x s'inspire de ce modèle. Il sera dissous une fois ce dernier mis en place.
Maintenant, le projet BTC1, je l'appelle le Fedora du Bitcoin. Il sera disponible après Segwit2x.
Avez-vous des projets sur ce que vous ferez avec BTC1 après cela ?
Je souhaite vraiment créer une communauté plus professionnelle, T discours ni calomnies, et accueillant davantage de développeurs. Lorsque je travaillais chez Linux, nous aidions les nouveaux développeurs à franchir la difficile courbe d'apprentissage.
Nous pourrions le faire, mais au lieu de cela, à ma grande tristesse, nous avons certaines parties de la communauté qui sont très négatives à l’égard de tout nouveau développement et qui refusent de repousser les limites.
Ethereum a été très bien accueilli. Bitcoin est de loin la blockchain la plus sécurisée du marché, et bien plus Ethereum. Mais Ethereum parvient mieux à attirer de nouveaux développeurs.
Je souhaite que BTC1 soit en quelque sorte le signe d'accueil que j'ai choisi comme ICON pour le projet. Nous souhaitons accueillir de nouveaux projets et de nouvelles idées, plutôt que de nous attaquer à des idées qui se situent en dehors d'une bulle auto-définie.
Le projet est-il de remplacer Bitcoin CORE?
Absolument pas. Il s'agit d'un ensemble de correctifs basé sur Bitcoin CORE. Nous utiliserons le meilleur de Bitcoin CORE, et nous accueillons avec plaisir vos contributions, ainsi que celles d'autres personnes.
Nous souhaitons collaborer avec Bitcoin CORE, et non contre CORE. Même s'ils refusent notre collaboration, nous souhaitons collaborer avec eux.
C'est ce qui est ironique et amusant. Les auteurs originaux de SegWit font tout ce qu'ils peuvent pour retarder le déploiement de SegWit, ce que Segwit2x est en train de faire.
Vous avez mentionné Ethereum. Beaucoup affirment qu'il est plus ouvert aux nouveaux développeurs ou aux nouvelles idées. Mais certains affirment que cela pourrait nuire à la sécurité du logiciel.
C'est tout à fait exact. Nous sécurisons les fonds. Les nouvelles idées impliquent de nouveaux risques.
Là où Segwit2x intervient, c'est que le contingent CORE est beaucoup trop conservateur et que nous laissons Bitcoin s'écraser contre ce mur de frais, ce qui était prévisible il y a des années, plutôt que de nous préparer à un hard fork.
Vous pouvez vous retrouver coincé dans une situation risquée et nuire à votre part de marché en étant si conservateur que personne ne peut l’utiliser.
Maintenant que BIP91 est verrouillé, que voyez-vous à l’avenir ?
En fin de compte, je pense que la meilleure solution pour SegWit, ce qui n'arrivera pas, serait de le déployer sur une chaîne latérale, de le tester sur des devises pendant un an et de l'intégrer à Bitcoin. Il a été testé en monnaie réelle sur Litecoin, mais c'est tout.
Litecoin, ils n'ont franchi que la première étape. Les portefeuilles n'utilisent T SegWit. Le scénario idéal aurait été un cycle beaucoup plus long de tests en argent réel sur une chaîne latérale. C'était la vision initiale des chaînes latérales.
Mais nous avons ce que nous avons aujourd'hui. Je pense que Segwit2x est la meilleure option pour déployer SegWit et permettre à tous de KEEP sur une ONE cryptomonnaie.
Il bénéficie clairement d’un large soutien, nous sommes donc confiants quant à son succès.
Déclaration de transparence:CoinDesk est une filiale de Digital Currency Group, qui détient une participation dans Bloq.
Image de Jeff Garzik viaVidéo TEDx
Alyssa Hertig
Journaliste spécialisée dans les technologies chez CoinDesk, Alyssa Hertig est programmeuse et journaliste spécialisée dans le Bitcoin et le Lightning Network. Au fil des ans, ses articles ont également été publiés dans VICE, Mic et Reason. Elle écrit actuellement un livre explorant les tenants et aboutissants de la gouvernance du Bitcoin . Alyssa possède des BTC.
