Bitcoin – La guerre des blocs #2

Les débats autour de la taille des blocs et des améliorations du protocole Bitcoin n’en finissent pas, tout comme la croissance de la capitalisation totale du réseau. Les frais moyens pour voir sa transaction confirmée dans un intervalle de temps correct (30 minutes maximum) frôlent désormais les 2 euros.

Face à cette situation, les utilisateurs mais aussi de nombreuses industries de l’écosystème urgent les mineurs d’adopter Segregated Witness, l’une des propositions – Bitcoin Improvment Proposals – les plus prometteuses. SegWit est une amélioration du protocole pouvant augmenter le nombre de transactions au sein de chaque bloc^[1] et ouvrant la voie au déploiement d’extensions comme le Lightning Network. Les enjeux de ces débats sont importants car dans tout système, accroître la scalabilité^[2] ne doit pas se faire aux dépends de la sécurité. Voir : Bitcoin – La guerre des blocs.

SegWit est une soft fork, c’est-à-dire une restriction des règles de consensus du réseau. C’est un changement rétro-compatible, contrairement à une hard fork, où les nouvelles règles de consensus sont incompatibles avec les précédentes – par exemple si l’on modifie dans le code source la taille des blocs acceptés par les noeuds.

Pour de plus amples informations sur les règles de consensus, vous pouvez relire “Hard fork, soft fork, règles de consensus et majorité économique“.

Les développeurs ont proposé différentes méthodes afin de faciliter le signalement d’une soft fork, son déploiement puis son activation.

La BIP 9 – Faciliter le déploiement d’une soft fork :

La BIP 9 – Version bits with timeout and delay proposée par Pieter Wuille, Peter Todd, Greg Maxwell et Rusty Russell, a pour but de faciliter le déploiement de soft forks sur le réseau. Le champ “version” des blocs permet aux mineurs de signaler qu’ils sont prêts à appliquer de nouvelles règles, et permet également de configurer une soft fork parallèle. Il est ainsi possible de déployer plusieurs fonctionnalités en même temps tout en ne sachant pas laquelle sera appliquée en premier. Il y a également un système d’avertissement qui permet aux noeuds anciens de se mettre à jour lorsqu’ils voient que de nouvelles règles de consensus sont activées.

Paramètres :

• name – Brève description de la la soft fork (généralement bipN où N est le numéro de la BIP)
• bit – Détermine quel bit sur les 28 que comporte le champ “version” sera utilisé pour signaler la soft fork, sa clôture et son activation.
• starttime – Date à partir de laquelle le “bit” correspondant à une soft fork entre en fonction.
• timeout – Délai à partir duquel le réseau considère que le déploiement a échoué.

Les différents états de déploiement de la soft fork pour chaque bloc :

• defined – Les blocs de genèse sont par définition… définis.
• started – Le start time est passé. Le déploiement de la soft fork a commencé.
• locked_in – Période de redéploiement des blocs started pour lesquels le pourcentage d’adoption^[3] minimal associé au bit considéré a été atteint (2016 blocs/2 semaines de plus)
• active – Etat final des blocs qui ont passé les étapes précédentes.
• failed – Echec : le niveau d’adoption requis dans l’intervalle temporel défini n’a pas été atteint.

En l’état actuel, SegWit sera activé via la BIP 9 si 95% de la puissance de hachage signale son support durant une période de deux semaines avant mi-novembre. Ce pourcentage stagne pour l’instant à 33% : les mineurs n’ont visiblement pas tous le même avis.

Lors du Consensus 2017, événement organisé par CoinDesk à New York, certains gros acteurs de l’écosystème Bitcoin ont manifesté leur volonté d’activer SegWit le plus vite possible, mais également d’augmenter la taille des blocs.

Les accords de New-York :

Menées par le Digital Currency Group de Barry Silbert, environ 50 compagnies ont publié et signé un agrément en faveur d’une modification des règles de consensus. Il est basé sur SegWit2Mb, une proposition de Sergio Lerner consistant à doubler la taille des blocs seulement si SegWit est activé, à une date fixée. Les compagnies signataires de l’accord comptent abaisser le niveau d’approbation requis :

• Activation de SegWit si 80% de la puissance de hachage du réseau signale sa volonté de le faire via la BIP 9,
• Activation d’une hard fork augmentant la taille des blocs à 2 Mo “sous six mois”.

Cette initiative ne fait pas l’unanimité. Rappelons que ces compagnies ne sont pas spécialement représentatives des utilisateurs de Bitcoin, et aucun des développeurs de l’équipe Core n’était présent ce jour-là. De plus, les risques que font peser une hard fork augmentant la taille des blocs ne sont pas négligeables.

. . .

Qu’est-ce qu’une UASF (User Activated Soft Fork) ?

Le principe d’une UASF est de laisser les utilisateurs disposant d’un noeud complet activer une soft fork à un moment convenu. Rappelons que chaque noeud complet a le pouvoir d’accepter ou de refuser les blocs soumis au réseau par les mineurs, selon les règles de consensus qu’il désire. Chaque noeud complet peut ainsi modifier ces règles (par exemple, en activant SegWit).

Si les noeuds ayant effectué la soft fork représentent la majorité économique du réseau Bitcoin, les mineurs sont incités financièrement à suivre les nouvelles règles : s’ils ne le font pas, ils pourraient miner des blocs sans valeur. Une fois que la majorité de la puissance de hachage du réseau applique les nouvelles règles, le reste des mineurs devra suivre automatiquement sous peine de voir ses blocs minés devenir orphelins.

Dans le cas où la nouvelle chaîne cumule une preuve de travail inférieure à celle de l’ancienne chaîne, les deux peuvent coexister. On parle de chain split. Le détenteur de bitcoins voit donc ses coins dédoublés : ils existent sur les deux chaînes. Tout comme en cas de hard fork, c’est une situation délicate que nous allons aborder.

Un développeur répondant au pseudonyme de Shaolin Fry, partant du principe que la méthode choisie pour l’activation de SegWit n’est pas la bonne, à cause du faible pourcentage de mineurs réfractaires requis pour y opposer leur veto, a récemment soumis deux UASFs à l’approbation du réseau : les BIPs 148 et 149.

L’avatar bien choisi du développeur Shaolin Fry, Krilin (Dragon Ball)

La BIP 148 –  Ultimatum pour les mineurs

BIP 148 – Mandatory activation of segwit deployment

L’idée est de forcer l’activation de SegWit en faisant pression sur les mineurs. A partir du 1er août :

• Les noeuds du réseau ayant déployé la BIP 148 refuseront les blocs qui ne signalent pas SegWit via la BIP 9.
• Si ces noeuds composent la majorité économique du réseau, les mineurs devront signaler qu’ils supportent SegWit s’ils veulent produire des blocs sur la chaîne qui a le plus de valeur.
• Le fait que de plus en plus de mineurs activent la BIP 148 incitera ensuite les noeuds pro-SegWit à faire de même, même s’ils n’y ont pas participé.

Il y a bien entendu des risques :

• Les blocs rejetés ne le seront que parce qu’il manque le signal SegWit, pas parce qu’ils ne sont pas valides en termes de preuve de travail. Cela entraîne un gaspillage des ressources minières, donc un affaiblissement du niveau de sécurité général du réseau.
• Si la BIP 148 n’est finalement que très peu adoptée, il y a un risque de chain split avec une blockchain “SegWit on” et une blockchain “SegWit off”.

Les arguments de Shaolinfry sont les suivants :

• Même en cas de chaîne BIP 148 minoritaire, la chaîne sans SegWit sera désavantagée car elle aura toujours moins de valeur que la nouvelle et sera donc théoriquement vouée à disparaître.
• Il y a une limite basse d’adoption à partir de laquelle le risque de chain split devient extrêmement faible. L’engouement de nombreux acteurs de l’écosystème tend à faire penser que cette limite a été franchie.

La BIP 149 – Temporisation et dernier recours

En cas d’échec de la BIP 148 et de la BIP 9 (qui expire mi-novembre), Shaolin Fry a fait une seconde proposition.

La BIP 149 – Segregated Witness (second deployment) est une UASF alternative soutenue par certains développeurs reconnus, dont Greg Maxwell. Cette proposition s’appuie sur un mécanisme différent pour activer une soft fork, la BIP 8 – Version bits with guaranteed lock-in.

Si la BIP 9 utilise un timeout – délai d’expiration, la BIP 8 définit une date limite d’activation : à cette date, tous les noeuds adoptent la soft fork indépendamment de la puissance de hachage qui la soutient.

Cette BIP inflige moins de pression aux mineurs : s’ils décident de ne pas supporter SegWit, il leur suffira à la date d’activation (juillet 2018) de configurer leurs noeuds de façon à rejeter les blocs post-fork.

Que faire en cas de chain-split ?

Les possibilités seront donc multiples à partir du 1er août ! Nicolas Dorier, développeur reconnu, a résumé l’arbre des possibles dans un article publié sur Medium :

Love it or hate it, but don’t ignore it

Dans le cas où certains mineurs décideraient de ne pas activer la BIP 148 et de rejeter les blocs correspondants, la blockchain sera séparée en deux. Contrairement à une hard fork :

• Dès que la chaîne issue de la soft fork (chaîne 148) repasse devant l’ancienne (chaîne non-148) en termes de preuve de travail cumulée, les blocs minés selon les règles de consensus de la non-148 deviennent orphelins, elle n’a donc plus aucune valeur ainsi que les tokens qui y sont présents.
• La survie de la chaîne respectant les nouvelles règles de consensus est donc assurée, mais pas celle de la chaîne “réfractaire” non-148.

En cas de chain split, le détenteur de bitcoins se retrouvera donc avec des tokens “doublés”, sur les deux côtés de la fourche, dont l’un courra le risque de disparaître.

Gestion de vos clefs privées :

Si vous confiez la gestion de vos clefs privées à une tierce partie (plateforme de change, wallet en ligne ou autre service qui a le pouvoir sur vos clefs privées) :

• Accepter telle ou telle chaîne, ou bien les deux à la fois, est une décision à discrétion de l’entreprise quand bien même la plupart des acteurs industriels sont censés tenir leurs utilisateurs informés.
• Ces derniers pourraient ne pas tenir leur engagement, ne pas communiquer à ce sujet, voire profiter de la situation.
• Pour éviter d’être dans le flou, il vous faut donc garder vous-même le contrôle de vos clefs privées avant le début de la soft fork.

L’attaque replay :

• Les transactions venant d’une chaîne ou de l’autre semblant identiques aux yeux des validateurs, il est possible qu’une transaction soit prise en compte à la fois par des noeuds 148 et des noeuds non-148. Le risque est donc d’envoyer des BTC non-148 en plus des BTC 148 ou inversement.
• Il est donc également possible pour une personne mal intentionnée d’utiliser votre signature de transaction afin de soumettre au réseau la même transaction, sur l’autre chaîne, mais vers une adresse de sortie dont il possède la clef privée.

Prévenir de tels risques est simple :

• Avant le 1er août, vous pouvez tout simplement vous séparer de vos bitcoins en échange d’une autre devise numérique ou de monnaie fiat. Cependant, si la soft fork se passe très bien, vous risquez de manquer le coup d’accélérateur nécessaire à la fusée Bitcoin qui doit se poser sur la Lune.
• A partir du moment où la soft fork a débuté (le 1er août), n’effectuez pas de transactions avant d’être assuré que la situation est stable. La situation la plus stable est évidemment le cas où la preuve de travail cumulée de la chaîne 148 dépasse celle de l’ancienne, la chaîne 148 devenant donc la seule et unique blockchain de Bitcoin.
• Si les deux chaînes coexistent, séparer les coins “dédoublés” qui existent des deux côtés de la fourche sans risque d’attaque replay est relativement compliqué^[4], il est donc préférable d’attendre que des plate-formes de change prennent en charge cette opération.

Suite au prochain épisode !