Retour sur la conférence à l’INSA – Améliorations apportées à Bitcoin

Retour sur la conférence à l’INSA – Améliorations apportées à Bitcoin

Bonjour à tous. En cette semaine ensoleillée –bien éclairée par 2-3 chandelles– je vais donner une suite au premier article qui revenait sur la conférence à l’INSA. Il s’agit ici de suivre l’ordre choisi pour la présentation : à savoir le fonctionnement de Bitcoin (fait), puis les améliorations apportées (le thème d’aujourd’hui), et enfin les nouveaux réseaux (qui pourra faire l’objet d’un dernier article). C’est donc parti pour les améliorations.

Le premier bloc (Genesis bloc) de la blockchain Bitcoin a été miné le 3 Janvier 2009 (comment je sais la date exacte ?), nous sommes aujourd’hui le 25 Juin 2018. Cela fait plus de 9ans et demi que Bitcoin est né. Il n’était au début qu’un réseau expérimental posté par une personne remplie de convictions (Satoshi), sur un petit forum fréquenté uniquement par des adeptes de p2p et de justice (lien vers le post). Avant de devenir le réseau mondial largement utilisé que l’on connait aujourd’hui, il va sans dire que le protocole Bitcoin était loin d’être parfait, bien que le fait de l’avoir mis en place soit déjà un coup de génie. Durant ces 9 années, la communauté a œuvré à le perfectionner, et le temps (les changements indépendants, évènements extérieurs survenus, etc..) a contribué à son utilisation, son développement et bientôt, on l’espère, sa large acceptation. Je vous ai résumé quelques uns de ces améliorations et changements, que je trouve parmi les plus importants. Quelques rappels :

 

0 – La limitation de la taille des blocs

La taille des blocs sur Bitcoin n’a pas toujours été limitée à 1MO. Cette contrainte a été appliquée par Satoshi arbitrairement (sans le dire ni le demander à personne) plus d’un an et demi après son lancement, soit le 12 septembre 2010 (bloc 79400).

Contexte

Nous sommes fin 2010, le réseau est à peine utilisé, les blocs sont loin d’être remplis. Il n’y a en moyenne qu’une seule transaction par bloc (la coinbase transaction).

Pourquoi limiter la taille ?

Jusqu’à ce moment, il n’y a jamais eu de limitation sur la taille : n’importe quel mineur pouvait créer un bloc énorme. C’est un très gros vecteur d’attaque sur le réseau : un énorme bloc signifierait qu’il ne soit pas accepté par tous les nœuds. Si le bloc est accepté et ajouté à la chaîne que par certains nodes, tout le monde n’aura pas la même version de la chaîne (autrement dit tout le monde n’aura pas la même histoire) : cela aura pour effet un split. Certains auront la version de la blockchain avec l’énorme bloc et partageront la chaîne sous cette version / mineront de nouveau blocs sur cette chaîne, d’autres auront la version sans ce bloc. Le réseau se diviserait donc en 2 réseaux ne partageant plus la même histoire. Si vous pouvez déjà imaginer le coup dur que ce serait pour Bitcoin si le réseau se divisait en 2 parties aujourd’hui, alors à l’époque ça aurait été radical.

Pourquoi le cacher ?

Bitcoin est décentralisé et est censé avoir une gouvernance plate, avec aucune personne n’ayant plus d’influence sur le réseau qu’une autre. C’est le but et la volonté de Satoshi. On peut alors légitimement se demander pourquoi avoir fait passé une règle -qui a les conséquences que l’on connait aujourd’hui- sans demander l’avis de la communauté, voire pire : en le cachant.

Étant donné que n’importe quel node peut miner (créer des nouveaux blocs), et que n’importe qui peut devenir un node, l’attaque pouvait être effectuée à tout moment. Il fallait donc agir vite. Demander l’avis de la communauté aurait pris du temps et, en plus, aurait averti tout le monde de la faille potentielle. Si des mineurs malintentionnés avaient voulu utilisé cette faiblesse ils auraient très bien pu faire trainer les choses (le temps requit pour trouver un consensus), voire même convaincre la majeure partie de la communauté de ne pas accepter cette réforme : ce qui aurait tôt ou tard conduit à un split du réseau, voire à la mort de Bitcoin.

bitcointalk screen

Un message qui résume bien le problème – source ci-dessous

 

Satoshi a donc œuvré pour le bien du réseau, mais en passant un peu outre les règles. C’est un bon exemple pour questionner ce modèle de gouvernance.

Quelques liens pour aller plus loin :

 

1 – La communauté devient acéphale

Oui j’ai découvert un nouveau mot en lisant le livre d’Adli Takkal-Bataille et je voulais l’utiliser. Pour les noobs « acéphale » signifie « sans-tête » 😉 . Je vais donc dans cette partie, fortement liée à la précédente, parler du moment où Bitcoin a perdu sa tête. Commençons par un screen du thread de la discussion sur la limite de la taille des blocs

screenshot bitcointalk

dans lequel un utilisateur vient demander (3 ans plus tard ^^’ ) pourquoi Satochi est parti. ArticMine lui répond que l’on ne sait pas pourquoi mais qu’une explication pourrait être : est-ce que Bitcoin peut continuer de fonctionner sans une sorte de « chef », de « meneur », un peu comme si Satoshi avait dit  » C’est bon j’ai fait ma part maintenant pour que ça marche vraiment il faut que vous vous débrouilliez ». Il rajoute aussi que cette histoire de limitation peut être prise comme un défi lancé à la communauté (remarque, on a toujours le même problème 8ans plus tard, mais on est sur le point de le résoudre).

Cette conversation résume tout. Je vous conseille par ailleurs fortement de lire ce thread et d’autres qui lui sont liés. On ne sait pas pourquoi Satoshi est parti, mais on connait quelles sont les influences d’un leader sur une communauté : on peut prendre Vitalik ou Charlie Lee comme exemple, on voit bien le rôle qu’ils jouent dans les décisions prises pour Ethereum et Litecoin. On remarque donc fortement cette absence sur Bitcoin, où de petits groupes ont plus ou moins d’influence sur le réseau et où les réformes sont difficiles à faire accepter.

2 – Les BIPs (Bitcoin Improvement Proposal)

Dans une communauté qui avait (a toujours d’ailleurs) une révolution technologique et philosophique (et pleins d’autres trucs en ique aussi) majeure, mais personne pour coordonner les « équipes » ni orienter les « recherches », si on prend l’analogie avec une entreprise. Il fallait mettre de l’ordre. Comment ? Standardiser. Quoi ? Les propositions d’évolution. C’est bon, vous l’avez.

En 2011, Amir Taaki a dit ok les gars (et les filles) c’est bien, on tient vraiment un truc énorme mais ça prend de l’ampleur et il faut qu’on s’organise : maintenant quand on voudra apporter un changement, une évolution, ou faire passer une information importante on structurera ça dans un fichier dans un gestionnaire de version (typiquement git) et on demandera un consensus de la communauté (ce sont les mineurs qui votent sur Bitcoin) si c’est un changement majeur. Ce fichier présentera l’auteur du BIP, la date de création, son titre, son type, son état et ses détails. Il y a 3 types de BIP : standard, informational, process. Un BIP de type « standard » affecte l’interopérabilité des nodes et requiert un consensus pour être appliqué, un BIP « informational » (comme son nom l’indique ^^) permet de présenter des choses à la communauté, et un BIP « process » affecte les utilisations faites de Bitcoin : toutes les choses dites « on-top-of Bitcoin ». Les BIP passent par plusieurs état, voici un schéma (pris du bip-001) qui résume bien et évite une longue phrase.

BIPs' status from BIP-001

Quelques BIPs notoires :

 

– Entracte –

On va aborder deux parties un peu plus techniques, j’omettrai intentionnellement certaines choses, ne les ayant pas abordées lors de la conférence car elles faisaient appel à des notions que je n’avais pas présenté. Je n’ai pas non plus présenté ces dernières dans l’article précédent, je resterai donc encore une fois un peu « en surface ». Pour ceux qui sont intéressés, n’hésitez pas à me dire (en commentaire, sur Discord) si vous souhaitez des articles un peu plus poussés sur ces 2 parties (voire même des ateliers pour lightning 😉 ). Je mettrai aussi des liens pour aller plus loin.

meme_segwit

3 – Segregated Witness (Segwit)

Avant toute chose je précise que je parle bien de Segwit pas de Segwit2x, le hard fork avorté.

Segwit est un soft fork, proposé pour la première fois à la communauté le 21 Décembre 2015 (cf le bip-0141), et activé le 24 Août 2017. Segwit propose principalement de régler 2 problèmes majeurs sur Bitcoin : la malléabilité des transactions, et la scalabilité du réseau (vous pouvez retrouver le reste des améliorations ici (en anglais), et ici (la traduction)).

Pour bien comprendre je vous propose déjà de bien cibler les termes. Segregated witness signifie littéralement « témoin isolé », bon jusque là ça ne nous aide pas plus. Mais il faut savoir que sur Bitcoin, on appelle « witness » (« témoin ») les données de signature des transactions (lorsque l’on effectue une transaction, on la signe cryptographiquement pour prouver que l’on possède la clef privée qui peut débloquer ces bitcoins-là, sans dévoiler cette clef. C’est la magie de la cryptographie asymétrique 😉 . Plus d’infos sur la proof of ownership).

Le problème avec ces données de signature, c’est que c’est lourd et nécessaire : autrement dit ça prend de la place dans le bloc mais on peut pas l’enlever ou mettre hors du bloc (sinon on perd l’utilité même des blocs). Alors qu’il n’y a déjà pas assez de place pour rentrer toutes les transactions, ces données prennent 60% de la taille du bloc.
Bon, on a donc toutes les clefs en mains pour cibler un peu le problème et sa solution : on va mettre plus de transactions dans les blocs en isolant les données qui servent aux signatures. On va donc maintenant répondre à la question : comment concrètement ?

A – La malléabilité

Qu’est-ce qu’on entend par « malléabilité des transactions » ? On peut trouver déjà un synonyme de ce mot barbare : on va utiliser « déformation ». Lorsqu’une transaction transite sur le réseau (dans les mempool des nodes) mais n’est pas encore ajoutée dans un bloc, il est possible d’en déformer une partie : l’identifiant. Ne vous inquiétez pas, ne retweetez pas BITCOIN IS BROKEN comme avec le selfish mining et tout ces articles à sensation qui s’en sont suivis (auxquels voici d’ailleurs une réponse), buvez un coup : c’est juste un id. Ce qui est modifiable est la référence vers la transaction, comme ce qu’est un id dans une base de donnée classique, on ne peut donc pas changer la transaction, « voler des bitcoins » ou toute autre chose que l’on puisse imaginer. C’est juste que certains (le wallet qui a envoyé la transaction) croyaient que la transaction était à telle place et en fait elle est ailleurs.

Bon et du coup quel est le problème ?et_là_c'est_le_drame

Cela ne pose aucun problème tant que l’on utilise des transactions confirmées (c’est à dire inclues dans des blocs). Mais le temps le temps de confirmation peut être long et un utilisateur peut être tenté d’utiliser une transction valide mais pas encore confirmée

Pour bien visualiser, je vais prendre un exemple (pris sur bitcoin.fr) qui illustre très bien ce qu’il peut se passer.

Alice Bob et Charlie sont 3 utilisateurs de Bitcoin. Alice et Bob se connaissent et se font confiance. Alice doit 0.01 bitcoin(s) à Bob, elle effectue donc cette transaction et Bob voit apparaître sur son wallet une transaction entrante de 0.01BTC valide (l’adresse d’Alice « a » bien les fonds et cette dernière possède la clef privée pour les débloquer) mais non confirmée. C’est à dire qu’un nœud mineur ne l’a pas encore ajouté dans un bloc, donc tout les nœuds (ordinateurs ayant la blockchain connectés entre eux) ne peuvent pas attester que cette transaction (avec cet identifiant!) a été effectuée.

Bob veut donc ensuite payer 0.01BTC à Charlie. Rappelez-vous que chaque transaction effectuée provient d’une précédente, elles sont chaînées -> un paiement provient d’un revenu. Sur ce schéma Bob paye donc Charlie en utilisant la transaction qu’Alice a effectuée en le mettant comme « destinataire », disons que cette transaction a pour identifiant 34. Charlie voit donc apparaître cette transaction dans son wallet en tant que valide mais non confirmée.

Si une attaque par malléabilité est effectuée sur la transaction faite par Alice vers Bob, l’identifiant change (disons qu’il est affecté à 62) avant que la transaction soit « scellée » dans la blockchain. Vous le voyez donc venir : puisque Bob a utilisé cette transaction qui avait, au moment où il l’aeffectuée, pour id 34 pour payer Charlie, ce dernier ne recevra pas son paiement car cette transaction (la deuxième, celle de Bob à Charlie) utilise une transaction qui a pour id 34, qui n’existe plus. Enfin elle existe mais sous l’id 62 : le paiement ayant été effectué avant ce changement n’est donc plus valide. Cette transaction devient donc orpheline.

Voici un (magnifique) petit schéma pour résumer.

schema_malleability_bitcoin

A ce moment les 2 transactions se propagent sur le réseau, puis celle d’Alice vers Bob est ajoutée dans un bloc après avoir été déformée.

schema_malleability_transaction_bitcoin

Segwit va donc pour répondre à ce problème, changer la structure des transactions. Je ne détaillerai pas plus dans cet article, pour ceux qui connaissent déjà la structure d’une transaction et veulent savoir ce qui a changé avec Segwit, je vous invite à suivre ce lien.

B – La scalabilité

En plus d’avoir permis de résoudre ce problème majeur (et d’autres), Segwit va permettre d’avoir plus de transactions par bloc, en augmentant la taille des blocs. Mais attention ! Ce n’est pas une augmentation de la taille des blocs en mode je me réveille ce matin je fork je crée Bcash, non, il ne faut pas oublier que Segwit est un soft fork, le changement ne doit pas affecter l’interopérabilité des nœuds du réseau. Autrement dit, il faut que les noeuds encore à l’ancienne version puisse aussi accepter les blocs, avec les règles qu’ils connaissent : donc il ne faut pas qu’ils reçoivent des blocs >1M, mais ils faut en même temps qu’ils aient les mêmes que tout le monde.

meme_stupeur

Pour se faire, les données de signature des transactions vont être déplacées. En clair ces données ne seront pas « en plein milieu » des transactions, mais dans un nouveau champs en fin de transactions. Ce champs ne sera lu que par des noeuds « comprenant » cette nouvelle structure, des noeuds à jour. Puisque les noeuds pas encore à jour ne lise pas cette structure, la transaction paraît plus petite et laisse donc de la place pour d’autres avant que le bloc n’atteigne le mega-octet.

De l’autre côté, pour les noeuds à jour et qui peuvent lire cette structure, une nouvelle limitation de la taille des blocs est mise en place : on remplace le bien connu


static const unsigned int MAX_BLOCK_SIZE = 1000000;

par


static const unsigned int MAX_BLOCK_WEIGHT = 4000000;

Avec les données non-segwit (en gros tout sauf le champs en fin de transaction dont j’ai parlé tout à l’heure) ayant un poids de 4, c’est à dire que leur poids est 4*nbOctetsDesDonnées, et les données Segwit ayant un poids de 1. On a donc :

BLOCK_WEIGHT = 4 * NON_SEGWIT_DATA + 1 * SEGWIT_DATA

Et pour que le bloc soit valide il faut que :

BLOCK_WEIGHT <= MAX_BLOCK_WEIGHT

Donc que :

4 * NON_SEGWIT_DATA + 1 * SEGWIT_DATA <= 4000000

Ainsi, cette mise à jour a pu faire passer une augmentation de la taille des blocs en douceur et au final les blocs ont une taille entre 1 et 1.8 MB, en fonction de l’adoption de Segwit (il y a encore des transactions non-segwit, qui prennent donc plus de place dans un bloc).

Quelques liens utiles :

 

C – Et plus encore !

Segwit ayant résolu de nombreux problèmes (comme notamment la malléabilité des transactions), dont certains ne sont même pas mentionnés dans cet article, a posé des bases solides pour des innovations sur Bitcoin. Parmis celles-ci on peut citer le lightning network, qui sera l’objet du prochain et dernier pargraphe de cet article.

 

5 – Le lightning network

Le lightning network est une utilisation du réseau Bitcoin, ayant pour but de résoudre les problèmes de scalabilité de ce dernier, et de rendre à nouveau possible les micro-paiements en bitcoins. Quand je dis « utilisation », c’est pour appuyer sur le fait que le Lightning network n’est pas un changement du protocole Bitcoin, ne requiert pas de consensus ni de fork. Juste la confiance et l’utilisation des solutions par la communauté. Le développement de solutions utilisant cette innovation est lead par 3 sociétés offrant 3 solutions différentes.

Comment ?

En utilisant des smart contracts. Eh oui sur Bitcoin aussi c’est possible, bien que le champs des possibles soit beaucoup plus restreint. Lien 1. Lien 2.

I made this you made this bitcoin smart contracts

Lightning network adoption

Ce schéma parle de lui même

Quand ?

Quand les services proposés seront opérationels (ce qui est déjà le cas pour la plupart), que beaucoup de nodes auront ouvert des canaux, et surtout surtout que les utilisateurs commenceront à l’accepter. Il reste encore à cette dernière étape d’être complétée, ce qui sera sûrement bientôt chose faite étant donné que l’on en entend de plus en plus parler.

 

Pour qui ?

Nous tous ! On devrait voir de plus en plus de wallets intégrant Lightning network dans un futur très proche, l’utilisation sera similaire à celle d’un wallet classique : n’importe qui pourra l’utiliser.

 

 

 

A – Les canaux de paiements

Les canaux de paiements, en anglais « state channels » sont une application des smart contracts (cf les liens ci-dessus). Le principe d’un canal de paiement (bidirectionnel) est de permettre des transactions entre 2 (ou plus, mais pour simplifier disons 2) participants hors-chaîne, par conséquent instantanées et sans frais : les transactions « on-chain » mettent du temps car il faut les inscrire dans la blockchain, c’est à dire attendre qu’un node qui mine le mette dans un bloc, et que le mineur gagne le challenge (hash<target) ce qui arrive toutes les 10 minutes (et les frais découlent du fait qu’il n’y a pas assez de place dans les blocs). Ces transactions n’étant jamais inscrites dans la chaîne, elles n’ont donc pas ces contraintes.

Comment est-ce mis en place ?

Grossièrement, les deux participants vont créer une adresse MULTISIG (une adresse dont les fonds ne pourront être débloqués que si N clefs privées des M totales de l’adresse signent la transaction) « 2-of-2 » (N=2 et M=2, 2 clefs disponibles pour cette adresse et les 2 sont nécessaires pour effectuer une transaction) avec chacune des deux clefs détenue par chacun des participants. Ces 2 participants envoient tous les deux des fonds à cette adresse.

Ils changent ensuite l’état en créant des transactions qu’ils signent tous les deux, par exemple BTC vers A, BTC vers B, et BTC restent sur l’adresse partagée. Mais ces transactions ne sont jamais envoyées sur le réseau, afin de ne pas être ajoutée dans la chaîne. Pour « fermer le canal », la dernière transaction (synonyme de dernier « état ») est broadcast puis inscrite dans la chaîne. Toutes les transactions entre celle qui ouvre le canal et celle qui le ferme (celle qui envoie des bitcoins à l’adresse MULTISIG et celle qui est la dernière des échanges) sont presques instantanées et sans frais. Le seul coût (à la fois en temps et en bitcoins) d’un canal de paiement repose sur 2 transactions : ce qui peut être largement amorti si le canal dure longtemps.

Puisque l’on comprend mieux avec des cas concrets des exemples et des schémas en voici un : Neo et Cypher veulent ouvrir un canal de paiement entre eux, afin d’effectuer des paiements l’un vers l’autre. C’est encore une fois une représentation grossière et simplifiée.

Ils créent donc une adresse dont les fonds correspondant (à cette adresse) ne pourront être débloqués que par 2 clefs privées, détenues par chacun d’eux. Ils envoient ensuite des fonds à cette adresse, disont que Neo envoie 10 bitcoins et Cypher 20. Pourquoi Cypher a plus ? Je ne sais pas et de toute façon, ignorance is bliss 😉 .

state channel explanation part 1

 

On va dire que de base ils se renvoient les fonds comme au départ, 10BTC pour Neo, 20 pour Cypher (moins les frais de tx, puisque c’est une transaction on-chain mais je ne les ai pas comptés pour simplifier), donc « état 1 » :

state channels explanation 2

Ensuite, si, imaginons, Cypher veut payer 5BTC à Neo, il n’y a qu’à changer l’état, c’est à dire que Neo et Cypher signent tous les 2 une transaction accordant 5 bitcoins de plus à Neo et 5 de moins à Cypher. Ce nouvel état « prend la place » du précédent.

state channels explanation part 3

Si ensuite Neo achète un steak à Cypher contre 2BTC, on refait la même chose :

state channels part 4

 

Etc, etc… Vous avez compris le principe. Si ensuite Neo paye 3BTC à Cypher qui lui paye ensuite 8BTC puis Neo lui repaye 4BTC puis qu’ils décident de fermer le channel, la dernière transaction, qui sera inscrite dans la chaîne sera :

state channels final

Neo et cypher auront donc fait 5 transactions entre eux, tandis que ça ne leur en aura coûté que 2.

B – De canal en canal, Lightning network

L’idée du lightning network est de relier les canaux de paiements les uns avec les autres, afin de créer un réseau de canaux de paiements.

lightning network explorer

Vous pouvez cliquer sur l’image pour accéder au site sur lequel j’ai pris le screenshot. Tous ces traits sont des canaux de paiements ouverts et le lightning network permet à chque noeud (représenter sur le graph par un point) d’en payer un autre sans ouvrir de canal directement avec lui. C’est à dire que en ouvrant un canal avec un seul noeud, même le plus isolé (comme celui en bas à gauche de mon screen), vous pourriez payer quelqu’un ayant ouvert un canal avec quelqu’un à l’autre bout du réseau (en haut à droite par exemple), et n’importe quel autre noeud du réseau.

C’est donc une technologie géniale, (ré-)ouvrant largement le champs des possibilités sur Bitcoin. Attention toutefois, on en est qu’au début du réseau et on n’est pas encore sûrs de la stabilité de toutes les solutions (proposées par les 3 principales entreprises développant Lightning). De plus, bien que souvent présentée comme une solution miracle, Lightning n’est pas un remède complet et radical aux problèmes de Bitcoin, cf le whitepaper (parties 9 et 10) en lien ci-dessous.

Quelques liens :

 

Pour éviter les phrases bateau je ne finirai pas cet article par une conclusion. Merci de m’avoir lu et n’hésitez pas en commentaire ou sur Discord si vous avez des questions/propositions/pullrequest.

Articles Similaires

1 Comment

Laisser une réponse