Chargement
keyboard_arrow_up
BitcoinTechnique

Avant-dernière partie de la série Scaling Bitcoin ! Le soleil californien était absent lors de la deuxième journée de conférences, mais cela n'a pas altéré l'enthousiasme des participants à cet événement important pour la communauté : les chercheurs et les développeurs y présentent leurs études et projets destinés à améliorer les performances du réseau. Pour cette fin de matinée, les intervenants ont abordé les mécanismes de consensus dont pourrait bénéficier Bitcoin.

Consensus

Sommaire :

Microchains

Par David Vorick (Nebulous Inc.)

David Vorick est chercheur pour le réseau Bitcoin depuis 2011; il est également le co-fondateur et lead developer de la solution de stockage décentralisé Sia.

David VorickCes dernières années de recherche et de création l'ont amené à s'intéresser de près aux algorithmes de consensus distribué et à la preuve de travail. Il a donc présenté ici des méthodes alternatives pour sécuriser les transactions contre la double dépense[1], là où le consensus de Satoshi Nakamoto ne suffirait pas, comme dans le cas de "petites" chaînes qui sont facilement vulnérables à une attaque de type 51 %.

En effet, l'écosystème de demain sera constitué de centaines de "petites" blockchains, car pour désengorger la couche primaire du protocole, il est nécessaire d'avoir une multitude de "micro-chaînes" interconnectées; chaque utilisateur se retrouvera sur plusieurs d'entre elles. L'idée derrière ces solutions de couche secondaire est d'avoir un grand nombre de chaînes, légères et facilement vérifiables, plutôt qu'une énorme blockchain unique et coûteuse à vérifier. Par "facilement vérifiables", le chercheur entend bien rendre possible la maintenance d'un nœud complet sur un téléphone mobile. Il faudra tirer parti du Lightning Network pour rendre ces micro-chaînes hautement inter-opérables, et permettre ainsi aux utilisateurs d'envoyer des paiements d'une chaîne à l'autre sans même nécessiter la connaissance de la chaîne en question.

C'est évidemment l'attaque des 51 % qui représente la plus grosse menace pour les chaînes de petite taille : le coût du matériel donnant la puissance requise pour mener cette attaque sur une blockchain valorisée, disons à 100 000 dollars, est faible. De plus, les mineurs sont peu fidèles et minent les blockchains en fonction de leur rentabilité; il faut donc trouver un nouveau mécanisme de sécurisation pour ces micro-chaînes.

Quels sont les pré-requis des micro-chaînes ?

  • Le minage doit être ouvert. Il faut le plus grand nombre de mineurs possible afin que leurs ressources soient librement accessibles pour un prix correct.
  • Le nombre de nœuds complets doit être très important.
  • Il faut combattre le "découragement mutuel" : lorsqu'un utilisateur observe une attaque réussie contre une chaîne, il perd rapidement foi en celle-ci et arrête d'y effectuer des transactions, n'achète plus de coins et vend les siens, cette perte de foi se propage ensuite à tous les utilisateurs du réseau.

L'open mining

L'idée derrière l'open mining est de soumettre aléatoirement aux mineurs un en-tête de bloc à résoudre, assorti d'un paiement. Une API se charge d'envoyer l'en-tête et le mineur est financièrement incité à le résoudre, sans qu'il ait besoin de savoir à quelle blockchain il correspond. Si le paiement est suffisamment intéressant pour le mineur, c'est-à-dire s'il génère plus de revenus en louant sa puissance de hachage plutôt qu'en minant sa crypto-monnaie par défaut, de plus en plus de mineurs se mettront à l'open mining.

Avec l'open mining, n'importe quel utilisateur peut lancer une attaque des 51 % sur n'importe quelle chaîne car la puissance de hachage est librement disponible. Dans la théorie, chaque utilisateur peut utiliser la totalité de la puissance de hachage du réseau à n'importe quel moment. C'est donc la quantité d'électricité payable par un attaquant qui compte : avec de toutes petites chaînes, un attaquant peut se débarrasser de la totalité d'un coin basé sur la preuve de travail en quelques heures. Cela signifie cependant que n'importe quel utilisateur du réseau peut répondre à cette attaque : s'il observe une tentative de réorganisation de la chaîne ou de double dépense, il peut ajouter du travail à la version "honnête" de la chaîne pour la défendre, ce qui rend la méthode cohérente. C'est le jeu de la terre brûlée : l'attaquant souhaitant réaliser une double dépense va voler les avoirs de quelqu'un d'autre. Les défenseurs qui sont en ligne et témoins de l'attaque seront motivés par le désir de vengeance ou celui de protéger leur paiement. Si l'attaquant doit faire face à des défenseurs motivés, qui peuvent ajouter du travail à la "vraie" chaîne, l'incitation économique de l'attaquant diminue.

Obtenir une participation maximale

Pour inciter le plus grand nombre possible d'utilisateurs à maintenir un nœud complet, il faut fortement réduire leur taille (le chercheur donne un ordre de grandeur : 100 ko par jour plutôt que 100 Mo par jour). Il deviendra alors possible d'utiliser un téléphone portable pour devenir un nœud complet, tant que cela ne ralentit pas l'appareil de l'utilisateur ou ne raccourcit pas l'autonomie de sa batterie. Les chaînes où la participation est faible seront moins sécurisées que les autres, ce qui devrait amener plus de participation de la part des acteurs institutionnels.

Un nœud qui se connecte au milieu d'une attaque peut voir que deux chaînes sont en conflit, mais ne peut pas déterminer quelle est l'originale. Le seul moyen de le savoir est d'être connecté avant et durant l'attaque : c'est pour cela qu'une participation des nœuds maximale est requise. Avec ce modèle, il faut une proportion non négligeable du réseau connectée en permanence pour observer ces attaques en temps réel : les plus gros participants (mineurs, market makers, commerçants, hubs du Lightning Network...)

Le découragement mutuel

Les chaînes seront très petites, ainsi les utilisateurs seront sur un grand nombre de chaînes à la fois. Perdre la totalité d'une chaîne ne sera plus si grave. Si une chaîne est attaquée une première fois avec succès, cela pourrait arriver à nouveau, aussi l'utilisateur devrait accepter ses pertes.

Un observateur qui voit une chaîne se faire attaquer sans que personne puisse la défendre vendra sûrement ses coins, persuadé que si l'attaque a réussi une première fois, elle pourra se reproduire à l'avenir : le risque de détenir des coins qui pourraient être sujets à une double dépense découragera tous les participants et la valeur du coin tombera rapidement à zéro. L'attaquant se retrouvera donc avec des coins qui n'ont plus aucune valeur, ce qui le décourage de tenter ce genre d'attaques.

Du point de vue de la théorie des jeux, si la blockchain est attaquée, un détenteur de coins a tout intérêt à aider les défenseurs en achetant de la puissance de hachage car il court le risque de voir la valeur de ses avoirs tomber à zéro : s'il possède 100 euros de coins, alors il a une incitation économique équivalente à défendre la blockchain attaquée. Cela rend la mise en place d'une double dépense très coûteuse pour l'attaquant.

Autres avantages des microchains

  • Avec des micro-chaînes, nul besoin de memory pool ou transaction pool[2] : il est même tout simplement possible de se contenter d'une transaction par bloc. Chaque utilisateur pourrait même miner son propre bloc pour inclure sa transaction plutôt que d'attendre qu'un autre s'en charge. L'absence de mempool fait que les mineurs qui centralisent la puissance de hachage ont moins d'incitation économique que les utilisateurs directs : cette pression à la décentralisation renforce l'open mining.
  • Les micro-chaînes sont antifragiles : si l'une d'entre elles échoue à présenter les pré-requis sus-cités, cela n'a aucun impact sur celles qui réunissent ces critères. Le faible market cap des micro-chaînes rend un échec beaucoup moins dramatique que s'il s'agissait d'une blockchain plus importante.

En conclusion, le chercheur a incité l'auditoire à tester les micro-chaînes, en les considérant comme des expérimentations hautement risquées mais prometteuses, comme l'était Bitcoin à ses débuts.

Les slides de la conférence.

Incentives and Trade-offs in Transaction Selection in DAG-based Protocols

Par Yonatan Sompolinsky (The Hebrew University)

Yonathan SompolinskyYonatan Sompolinsky a présenté les avantages des protocoles DAG, pour Directed Acyclic Graph of blocks, c'est-à-dire les protocoles basés sur les graphes orientés acycliques, une méthode utilisée notamment par IOTA.
Ces protocoles diffèrent des blockchains :
  • Une blockchain cherche à maintenir son unicité, ignorer les fourches concurrentes, et les forks sont rares et risqués.
  • Un graphe dirigé acyclique maintient son intégralité en considérant tous les blocs; et les forks y sont fréquents.
Le fait de conserver une quantité beaucoup plus importante d'informations implique possiblement plus de sécurité, une meilleure scalabilité et plus d'équité.
Blockchains vs graphes orientés acycliques
Blockchain vs graphe orienté acyclique

Scalabilité de la couche primaire grâce aux graphes orientés acycliques

Les protocoles basés sur les graphes orientés acycliques permettent d'améliorer la scalabilité de la couche primaire du réseau :

  • Augmentation de la vitesse de production de blocs sur le réseau : plutôt qu'un bloc toutes les 10 minutes ou toutes les 21 secondes, l'ordre de grandeur est plutôt de 50 blocs par seconde.
  • Plutôt que de chercher à étendre une chaîne, le protocole de minage cherche à référencer tous les blocs précédents et toutes les "pointes" des forks observées en un seul graphe.
  • Le challenge consiste à extraire de ce graphe un ensemble cohérent de transactions. Il peut y exister des conflits et le vrai défi des DAGs est de trier et d'ordonner les informations pour obtenir cette cohérence : Sompolinsky a évoqué la méthode qu'il a développée avec ses associés, nommée SPECTRE.

Les DAGs ne sont pas une solution mais plutôt un cadre sur lequel les développeurs peuvent bâtir de nouveaux protocoles. Si les blockchains pouvaient s'apparenter à des petites routes de campagne, les DAGs seraient des autoroutes : une mauvaise conception entraîne très rapidement des embouteillages. Comment utiliser les graphes orientés acycliques pour améliorer la scalabilité des blockchains ? Il faut résoudre de nombreux défis :

  • La cohérence des données de transactions ;
  • Le débit et les délais de confirmation ;
  • Le niveau de décentralisation ;
  • L'équité entre les participants ;
  • La structure des frais de transactions ;
  • Le stockage des données ;
  • Le calcul de la preuve de travail ;
  • L'utilisation de la bande passante.

Obtenir un débit proche du maximum théorique atteignable est loin d'être trivial : imaginons par exemple un cas simple où 4 transactions se trouvent dans le mempool, qui ne sont pas en conflit. Deux mineurs peuvent choisir à la fois la TX 1 et la TX 2 et laisser de côté les TXs 3 et 4. Ainsi, deux transactions ont pris la place de quatre. Il faut donc trouver une méthode qui permet de s'approcher au plus près de cet objectif de cohérence. Comment s'assurer que les transactions ne sont pas dupliquées ?

Si le protocole laisse simplement les mineurs sélectionner les transactions les plus intéressantes (financièrement) pour eux dans le mempool, alors les DAGs ne sont d'aucune utilité en termes de débit. Il faut donc inciter les mineurs à éviter d'inclure des transactions similaires dans leurs blocs : les collisions entraînent la perte des frais de transactions.

Différents débits en fonction du comportement des mineurs.
Différents débits en fonction du comportement des mineurs.

Le jeu de la poule mouillée

Pour formaliser un peu mieux ce problème, il existe un cas d'école en théorie des jeux : le jeu de la poule mouillée. Il s'agit d'un jeu à somme non nulle, c'est-à-dire que les participants ont intérêt à coopérer (le fait qu'un des participants gagne n'implique pas que les autres perdent). Le joueur a intérêt à trahir lorsque l'adversaire coopère, mais si l'adversaire trahit, c'est la coopération qui donne de meilleurs résultats. L'exemple classique est celui de deux voitures qui se foncent dessus. Les joueurs peuvent choisir de s'écarter (coopération), ou de continuer tout droit au risque d'entrer en collision (défection). Le dilemme est donc le suivant : intimider l'adversaire et gagner, au risque de mourir s'il choisit également la défection, ou s'écarter et devenir la poule mouillée, ce qui est la garantie que lorsque la situation se reproduira, la partie est perdue d'avance. Par exemple, lorsque deux pays se regardent en chiens de faïence, au bord de la déclaration de guerre, passer pour la poule mouillée rend certain que la situation se reproduira, mais maintenir sa réputation de dominant entraîne de lourdes dépenses militaires et peut conduire à la guerre.

C'est analogue à la sélection des transactions par les mineurs : prenons par exemple une TX 1 avec 3 mBTC de frais et une TX 2 avec 2 mBTC de frais. Les mineurs sont incités à sélectionner la TX 1, mais s'il y a collision, les mineurs partagent la récompense, et s'il y a collision sur la TX 2, la récompense est encore plus faible. Il faut donc se coordonner et sélectionner correctement les transactions. Sur le réseau Bitcoin, les mineurs sélectionnent les transactions présentant les frais les plus élevés; sur un DAG, les mineurs vont sélectionner les transactions aléatoirement parmi une distribution.

En théorie des jeux, il y a plusieurs approches pour résoudre ce problème :

  • L'approche accusatoire : le mineur paranoïaque considère que tous les autres veulent minimiser ses revenus. La solution est donc de trouver la meilleure réponse à n'importe qui voudrait saboter ses profits. Cette approche conflictuelle ne sied pas à Bitcoin.
  • L'approche égoïste : se rapprocher de l'équilibre de Nash, c'est-à-dire trouver une stratégie qui maximise les profits de chaque partie, et où tout participant y perdra s'il en dévie.
  • L'approche altruiste : les joueurs ne jouent que dans l'intérêt global du système, comme ce fut le cas pour Bitcoin au début, lorsque les mineurs minaient des transactions ne donnant aucune récompense.

L'approche altruiste consisterait à sélectionner les transactions de manière uniforme en se rapprochant le plus possible du débit maximal du réseau. Il n'y pas de collisions, mais c'est une stratégie instable, car elle force les délais de confirmation à être égaux et ne laisse donc pas la place au traitement de transactions prioritaires. Celui qui voudra un temps de traitement très court risque la collision et cela lui coûtera des frais plus élevés. Le risque de collision augmente donc lorsque la latence diminue.

La stratégie d'équilibre est difficile à trouver; il s'agit d'un compromis - "si je te vois coopérer, je coopérerai aussi". Le chercheur a effectué plusieurs simulations, menant à un résultat surprenant : même si tous les participants sont égoïstes et au-dessous de la stratégie d'équilibre, 70 % des transactions du graphe sont uniques. Cela vient du fait que même si la probabilité de traitement d'une transaction augmente avec ses frais, aucun mineur ne sera suffisamment avare pour traiter 100 % de ces transactions à frais élevés.

Si les mineurs sont mieux coordonnés, il est sans doute possible d'obtenir de meilleurs résultats que par l'approche égoïste. Le chercheur a évoqué des méthodes utilisant le caractère aléatoire des blocs précédents, qui sont encore à expérimenter et à améliorer. Les attaques de type minage égoïste sont plus faciles à mener sur un DAG que sur une blockchain, car moins risquées. Les incitations économiques des différents participants à un DAG sont donc très importantes pour maintenir la cohérence du système.

Les slides de la présentation.

Pour aller plus loin : Inclusive Block Chain Protocols - Yoad Lewenberg, Yonatan Sompolinsky et Aviv Zohar.

Changes without unanimous consent

Par Anthony Towns

Le développeur a traité dans cette intervention le sujet délicat des chain splits : dans le cas où un changement des règles de consensus au niveau algorithmique ne fait pas consensus au niveau social, la blockchain se sépare en deux.

Anthony TownsSi le consensus social est unanime, rien de plus simple : les développeurs fournissent le nouveau code, les mineurs l'implémentent et tout le monde y gagne. Les problèmes commencent lorsque les nouvelles règles sont loin de faire l'unanimité : des désagréments qui se multiplieront au fur et à mesure de la croissance de Bitcoin, surtout si les gouvernements s'en mêlent. Les participants au réseau peuvent avoir des objectifs totalement incompatibles, et il ne peut exister aucun compromis, ce qui conduit irrémédiablement à un chain split.

Les désagréments peuvent aussi être mineurs; certains participants peuvent ne pas comprendre l'impact d'un changement proposé, et leur désaccord mène à une séparation de la blockchain, même s'ils ont tort. Idéalement, il ne faudrait implémenter que des améliorations bénéficiant à tout le monde, ce qui est peut-être impossible à cause de la taille du réseau et de la diversité de ses participants. La croissance de Bitcoin attire toujours plus de développeurs, qui sont susceptibles de créer plus de bugs, et qui, dans le même temps, vont découvrir sans doute des failles inobservées jusqu'alors dans certains proposals... Il peut y avoir des "incitations au désaccord" si l'on pense que rejeter une proposition peut permettre d'établir un compromis avantageux pour une des parties.

Anthony Towns est catégorique : il y aura toujours des désaccords et ces derniers mèneront sans aucun doute à de nouveaux chain splits. Mais il précise que ces splits sont peu coûteux : prenant l'exemple de Bitcoin Gold, séparer une blockchain valorisée à plus de 100 milliards n'a pas coûté quelques millions mais seulement quelques lignes de codes sur Github, un peu de publicité sur les réseaux sociaux et les blogs spécialisés et le temps que les développeurs y auront consacré. Avec des coûts aussi faibles et des bénéfices importants, ce genre d'événement se reproduira. En réalité les coûts d'un split sont externes : ceux qui n'en veulent pas sont les acteurs investis dans l'écosystème qui souhaitent que Bitcoin conserve les mêmes règles, car l'implémentation de nouvelles règles de consensus requiert la mise à jour des codes sources, des sites web, des agréments légaux, etc... Si quelqu'un d'autre décide de provoquer un split, ces compagnies doivent réagir à l'annonce. Il n'est plus possible de rester passif en répétant que Satoshi a déjà fait un travail suffisant, que nous n'avons pas besoin d'un nouveau système de script ou d'agrégation des signatures : n'importe qui peut proposer un nouveau logiciel client intégrant ces améliorations, donnant droit à des coins gratuits aux utilisateurs. En ce sens, il parait impossible d'éviter des splits supplémentaires dans le futur. Il est tout à fait possible de mettre en place des changements qui ne portent pas à controverse, par exemple par des soft forks, ou même des hard forks d'urgence. Un hard fork non controversé peut cependant donner lieu à un split s'il est mis en place trop rapidement (certains participants pourraient ne pas effectuer la mise à jour à temps). Les UASF (User Activated Soft Forks) peuvent également donner lieu à des splits si les mineurs les refusent tandis que les utilisateurs forcent son activation. Ce sont beaucoup d'arguments qui laissent à penser qu'il faudra vivre avec ces splits.

Les décisionnaires

Qui sont-ils ? Les développeurs, les mineurs, les utilisateurs et les régulateurs. On ne peut ajouter un autre groupe de participants, comme les développeurs de Bitcoin Core, car il n'y a pas de lead developer sur Bitcoin. En réalité, les mineurs n'ont un pouvoir de décision que lorsque la plupart des participants au réseau se reposent sur eux, mais il a été prouvé que c'est de moins en moins le cas. Les nœuds complets du réseau, qui veillent à faire appliquer les règles, ont certes du pouvoir décisionnaire, mais il est très facile pour eux de rejeter un changement, leurs décisions ne font donc pas vraiment sens. C'est donc l'économie et le marché libre qui ont le plus gros pouvoir décisionnel.

Ces deux éléments sont les raisons qui poussent les développeurs, les mineurs et les nœuds à opérer. Il y a souvent des idéaux philosophiques derrière leur implication (l'envie de créer une économie plus vertueuse), mais c'est le marché qui décide du prix du bitcoin si ces derniers ne sont intéressés que par le profit financier.

Changer... ou pas ?

Après une proposition, comme par exemple augmenter la taille des blocs, il y a trois issues :

  • Tout le monde adopte le changement, le logiciel client est mis à jour et les nœuds font de même. Les participants profitent des gains que les changements apportent.
  • Personne n'adopte la proposition et les règles restent les mêmes.
  • Certains adoptent les nouvelles règles consensus et d'autres non : il y a chain split.

Si la valeur de la nouvelle chaîne est jugée supérieure à celle de l'ancienne, alors il est dans l'intérêt de l'utilisateur que les nouvelles règles soient appliquées ! Bien évidemment, trouver ces valeurs en tant qu'individu est impossible, il faut donc se reposer sur l'économie de marché pour faire des approximations. Par exemple, les marchés prédictifs permettent d'avoir une idée assez précise du sentiment concernant tel ou tel fork. Déterminer le coût des externalités générées par un split est difficile mais possible si l'algorithme de preuve de travail ne change pas.

Réussir un split

Le premier point à respecter pour ne pas générer trop de problèmes lors du split de la blockchain est d'implémenter une forte replay protection (protection contre le rejeu). Idéalement, il faudrait implémenter cette protection à la base du protocole, pour que tout le monde en bénéficie dans le cas d'un split aléatoire ou accidentel.

Selon le développeur, la meilleure méthode consiste à utiliser le SIGHASH[3] plutôt qu'un opcode spécial : deux octets de données supplémentaires dans le SIGHASH permettant de spécifier la hauteur du bloc où le split a eu lieu et le hash du premier bloc de notre chaîne préférée à la signature. Ainsi, la chaîne de référence est toujours mentionnée lors de la signature d'une transaction : cela évite les attaques rejeu et permet d'appréhender un chain split avec seulement deux informations.

Dans le cas d'un soft fork, Anthony Towns préconise également d'indiquer dans le SIGHASH le BIP correspondant et son état d'activation afin que les nœuds du réseau puissent facilement déterminer de quel soft fork il s'agit et rejeter les BIPs inconnus.

En conclusion, Towns a déclaré que les splits sont faciles à gérer, mais qu'obtenir un consensus autour d'un consensus était très difficile et le deviendrait plus encore. Il est persuadé que c'est l'économie qui peut aider à prendre les meilleures décisions et qu'il est possible de mettre en place des mécanismes permettant de limiter les externalités négatives des splits.

Les slides de la présentation.

À suivre !

Image d'en-tête : Neural Network par Kevin Rheese - License CC BY 2.0

Commentaires

Indice des prix

Sécurisez vos cryptos

Ledger Nano S
Ledger Blue
Trezor Hardware wallet

Flux Twitter

Achetez des bitcoins/ethers

Acheter bitcoins et ethers sur Coinhouse
Acheter des bitcoins sur ZeBitcoin
Achat / Vente de crypto-monnaies sur coinbase
BitIt, achat de crypto-monnaies facile et rapide
SpectroCoin, le multi-services
Cex.io, Achat / Vente et échange de crypto-monnaies
Coinmama, l’achat bitcoin ethereum facile