Note : Cette page est sérieusement dépassée et largement non maintenue ; en raison d’incidents passés d’edit-warring, elle n’a pas été soumise à beaucoup d’examen par les pairs.
Un nœud complet Bitcoin pourrait être modifié pour s’échelonner à des taux de transaction beaucoup plus élevés que ceux observés aujourd’hui, en supposant que ledit nœud fonctionne sur des serveurs haut de gamme plutôt que sur un ordinateur de bureau. Bitcoin a été conçu pour supporter des clients légers qui ne traitent que de petites parties de la chaîne de blocs (voir la vérification simplifiée des paiements ci-dessous pour plus de détails à ce sujet).
Veuillez noter que cette page existe pour donner des calculs sur la scalabilité d’un nœud complet Bitcoin et des transactions sur la chaîne de blocs sans tenir compte de la sécurité du réseau et de la décentralisation. Elle n’est pas destinée à discuter de la scalabilité des protocoles alternatifs ou à essayer de résumer les débats philosophiques. Créez des pages alternatives si vous voulez faire cela.
Note aux lecteurs
Lorsque les techniciens entendent parler du fonctionnement du bitcoin, ils s’arrêtent fréquemment au mot « inondation » et disent « Oh-mon-dieu ! ça ne peut pas s’échelonner ! ». Le but de cet article est de prendre un exemple extrême, le pic de transaction de Visa, et de montrer que le bitcoin pourrait techniquement atteindre ce genre de taux sans aucune sorte de raisonnement douteux, de changements dans la conception de base, ou de superpositions inexistantes. En tant que tel, c’est simplement un exemple extrême- pas un plan pour la façon dont le bitcoin va se développer pour répondre à des besoins plus larges (en tant que système décentralisé, c’est le public utilisateur de bitcoin qui décidera de la façon dont le bitcoin se développe)- c’est juste un argument qui montre que la conception de base du bitcoin peut évoluer beaucoup mieux que ce qu’une personne intelligente pourrait deviner au départ.
Dan critique à juste titre l’analyse présentée ici- en soulignant que le fonctionnement à cette échelle réduirait considérablement la nature décentralisée du bitcoin : si vous devez avoir plusieurs téraoctets d’espace disque pour exécuter un nœud de « validation complète », alors moins de gens le feront, et tous ceux qui ne le font pas devront faire confiance à ceux qui le font pour être honnêtes. Dan semble (d’après ses diapositives) être allé trop loin avec cet argument : il semble suggérer que cela signifie que les bitcoins seront contrôlés par le type de banques centrales qui sont courantes aujourd’hui. Son analyse échoue pour deux raisons (et la seconde est la faute de cette page qui est un peu trompeuse):
Premièrement, même à l’échelle astronomique présentée ici, la capacité requise est bien dans le domaine des individus privés (riches), et le serait certainement à un moment futur où ce genre de capacité serait nécessaire. Un système qui met les particuliers, ou du moins de petits groupes de particuliers, sur un pied d’égalité avec les banques centrales peut difficilement être qualifié de centralisé, même s’il serait moins décentralisé que le bitcoin que nous avons aujourd’hui. Le système ne pourrait pas non plus atteindre ce type d’échelle sans que les utilisateurs de bitcoins acceptent collectivement d’augmenter la taille maximale des blocs, ce n’est donc pas un résultat qui peut se produire sans le consentement des utilisateurs de bitcoins.
Deuxièmement, et surtout, l’échelle supposée décrite ici traite du remplacement du visa par le bitcoin. C’est une mauvaise comparaison parce que le bitcoin seul n’est pas un remplacement parfait du visa pour des raisons complètement indépendantes de la mise à l’échelle : Le bitcoin n’offre pas de transactions instantanées, de crédit ou de divers mécanismes anti-fraude (que certaines personnes souhaitent, même si ce n’est pas le cas de tout le monde), par exemple. Bitcoin est un remplacement plus complet des chèques, des virements, des mandats, des pièces d’or, des CD, des comptes d’épargne, etc. et s’il est largement adopté, il remplacera probablement les utilisations des cartes de crédit qui seraient mieux servies par ces autres choses si elles fonctionnaient mieux en ligne.
Les utilisateurs de bitcoins glissent parfois trop rapidement sur ce fait parce que les gens sont trop prompts à le qualifier de défaut, mais c’est injuste. Aucun système n’est idéal pour tous les usages et le bitcoin possède un spectre de qualités plus large que la plupart des instruments monétaires. Si la communauté bitcoin n’est pas disposée à souligner que certaines choses seraient mieux réalisées par d’autres systèmes, il devient alors facile d’avancer des arguments de paille : Si nous admettons que le bitcoin pourrait être utilisé comme une cire pour le sol et une garniture pour le désert, quelqu’un fera toujours remarquer que ce n’est pas la meilleure cire pour le sol ou la meilleure garniture pour le désert.
Il est trivial de construire des systèmes de traitement des paiements et de crédit _sur_ le bitcoin, aussi bien les systèmes classiques (comme Visa lui-même !) que les systèmes » décentralisés » comme Lightning. Ces systèmes pourraient traiter des volumes de transactions plus importants à des coûts moindres, et effectuer des règlements fréquents sur les bitcoins qui les soutiennent. Ils pourraient utiliser d’autres techniques avec des compromis différents de ceux du bitcoin, mais ils seraient toujours soutenus et libellés par le bitcoin et bénéficieraient donc toujours de l’absence de contrôle central. Nous en voyons les prémices aujourd’hui avec les services d’échange et de portefeuille de bitcoins permettant des paiements instantanés entre membres.
Ces services bénéficieraient de la stabilité de la monnaie bitcoin résistante à l’inflation, les utilisateurs bénéficieraient des avantages des transactions instantanées, du crédit et de la lutte contre la fraude, le bitcoin dans son ensemble bénéficierait d’une meilleure mise à l’échelle grâce au volume de transactions déchargé sans compromettre sa nature décentralisée. Dans un monde où le bitcoin serait largement utilisé, les systèmes de traitement des paiements auraient probablement des prix plus bas parce qu’ils devraient concurrencer les transactions en bitcoin brut, mais ils pourraient aussi se permettre des prix plus bas parce que les règlements fréquents en bitcoin (et les transactions de séquestre en bitcoin sans confiance) réduiraient leur risque. Ceci est doublement vrai parce que le bitcoin pourrait concevablement s’échelonner pour les remplacer entièrement, même si cela ne serait pas la meilleure idée en raison de la réduction de la décentralisation qui en résulterait.
Cibles d’évolutivité
VISA traite en moyenne environ 2 000 transactions par seconde (tps), alors appelez-le un taux de pointe quotidien de 4 000 tps. Il a une capacité de pointe d’environ 56 000 transactions par seconde, cependant ils n’utilisent jamais réellement plus d’environ un tiers de cela, même pendant les périodes de pointe d’achats.
PayPal, en revanche, a traité environ 10 millions de transactions par jour pour une moyenne de 115 tps fin 2014.
Prenons 4 000 tps comme objectif de départ. Évidemment, si nous voulons que Bitcoin s’étende à toutes les transactions économiques dans le monde, y compris l’argent liquide, ce serait beaucoup plus que cela, peut-être plus dans la région de quelques centaines de milliers de tps. Et la nécessité de pouvoir résister à des attaques DoS (auxquelles VISA n’est pas confronté) implique que nous voudrions aller bien au-delà des taux de pointe standard. Néanmoins, choisir une cible nous permet de faire quelques calculs de base, même si c’est un peu arbitraire.
Aujourd’hui, le réseau Bitcoin est limité à un taux soutenu de 7 tps en raison du protocole bitcoin qui restreint la taille des blocs à 1MB.
CPU
Le protocole comporte deux parties. Les nœuds envoient des messages « inv » aux autres nœuds pour leur dire qu’ils ont une nouvelle transaction. Si le nœud récepteur n’a pas cette transaction, il la demande avec un getdata.
Le gros coût est la crypto et les recherches de la chaîne de blocs impliquées dans la vérification de la transaction. La vérification d’une transaction implique un hachage et des vérifications de signature ECDSA. RIPEMD-160 fonctionne à 106 mégaoctets/sec (appelons-le 100 pour simplifier) et SHA256 est à peu près le même. Ainsi, le hachage de 1 mégaoctet devrait prendre environ 10 millisecondes et le hachage de 1 kilooctet prendrait 0,01 milliseconde – assez rapide pour que nous puissions l’ignorer.
Bitcoin est actuellement capable (avec quelques optimisations simples qui sont prototypées mais pas encore fusionnées) d’effectuer environ 8000 vérifications de signature par seconde sur un processeur quadri-cœur Intel Core i7-2670QM 2.2Ghz. Le nombre moyen d’entrées par transaction est d’environ 2, nous devons donc diviser le taux par deux. Cela signifie que 4000 tps sont facilement réalisables du point de vue du CPU avec un seul CPU assez grand public.
Comme nous pouvons le voir, cela signifie que tant que les nœuds Bitcoin sont autorisés à maximiser au moins 4 cœurs des machines sur lesquelles ils fonctionnent, nous ne manquerons pas de capacité CPU pour la vérification des signatures, à moins que Bitcoin ne gère 100 fois plus de trafic que PayPal. Fin 2015, le réseau gère 1,5 transaction/seconde, donc même en supposant une énorme croissance de la popularité, nous n’atteindrons pas ce niveau avant longtemps.
Bien sûr, Bitcoin fait d’autres choses que la vérification des signatures, la plus évidente étant la gestion de la base de données. Nous utilisons LevelDB qui fait l’essentiel du travail lourd sur un thread séparé, et qui est capable de charges de lecture/écriture très élevées. Globalement, l’utilisation du CPU de Bitcoin est dominée par ECDSA.
Réseau
Supposons un taux moyen de 2000tps, donc juste VISA. La taille des transactions varie d’environ 0,2 kilooctet à plus de 1 kilooctet, mais c’est en moyenne un demi kilooctet aujourd’hui.
Cela signifie que vous devez suivre environ 8 mégabits/seconde de données de transaction (2000tps * 512 octets) / 1024 octets dans un kilooctet / 1024 kilooctets dans un mégaoctet = 0,97 mégaoctet par seconde * 8 = 7,8 mégabits/seconde.
Ce genre de bande passante est déjà commun pour les connexions même résidentielles aujourd’hui, et est certainement à l’extrémité inférieure de ce que les fournisseurs de colocation s’attendraient à vous fournir.
Lorsque les blocs sont résolus, le protocole actuel enverra à nouveau les transactions, même si un pair l’a déjà vu au moment de la diffusion. Corriger cela pour que les blocs ne soient que des listes de hachages résoudrait le problème et rendrait négligeable la bande passante nécessaire à la diffusion des blocs. Ainsi, alors que cette optimisation n’est pas entièrement mise en œuvre aujourd’hui, nous ne considérons pas la bande passante de transmission des blocs ici.
Stockage
À des taux de transaction très élevés, chaque bloc peut avoir une taille de plus d’un demi-gigaoctet.
Il n’est pas nécessaire pour la plupart des nœuds de validation complète de stocker la chaîne entière. Dans le document de Satoshi, il décrit « l’élagage », une façon de supprimer les données inutiles sur les transactions qui sont entièrement dépensées. Cela réduit la quantité de données nécessaires pour un nœud de validation complète à seulement la taille de la taille de la sortie actuelle non dépensée, plus quelques données supplémentaires qui sont nécessaires pour gérer les ré-orgs. En octobre 2012 (bloc 203258), il y a eu 7 979 231 transactions, cependant la taille de l’ensemble de sortie non dépensée est inférieure à 100MiB, ce qui est assez petit pour tenir facilement dans la RAM même pour des ordinateurs assez vieux.
Seul un petit nombre de nœuds d’archivage ont besoin de stocker la chaîne complète remontant au bloc de genèse. Ces nœuds peuvent être utilisés pour amorcer de nouveaux nœuds de validation complète à partir de zéro, mais sont autrement inutiles.
Le principal facteur limitant les performances de Bitcoin est la recherche sur disque une fois que l’ensemble de sortie des transactions non dépensées cesse de tenir en mémoire. Une fois que les disques durs seront progressivement éliminés en faveur des SSD, il est tout à fait possible que l’accès à l’ensemble UTXO ne devienne jamais un goulot d’étranglement sérieux.
Optimisations
La description ci-dessus s’applique au logiciel actuel avec seulement des optimisations mineures supposées (le type qui peut et a été fait par un seul homme en quelques semaines).
Cependant, il existe un potentiel pour des optimisations encore plus importantes à l’avenir, au prix d’une certaine complexité supplémentaire.
CPU
Des algorithmes existent pour accélérer la vérification des lots sur les signatures de courbes elliptiques. Il est possible de vérifier leurs signatures simultanément pour une accélération de 2x. Il s’agit d’une implémentation un peu plus complexe.
Vérification simplifiée des paiements
Il est possible de construire une implémentation de Bitcoin qui ne vérifie pas tout, mais s’appuie plutôt soit sur la connexion à un nœud de confiance, soit met sa foi dans la haute difficulté comme proxy pour la preuve de validité. bitcoinj est une implémentation de ce mode.
Dans le mode de vérification simplifiée des paiements (SPV), nommé d’après la section du papier de Satoshi qui le décrit, les clients se connectent à un nœud complet arbitraire et ne téléchargent que les en-têtes de bloc. Ils vérifient que les en-têtes de chaîne se connectent correctement et que la difficulté est suffisamment élevée. Ils demandent ensuite des transactions correspondant à des modèles particuliers au nœud distant (c’est-à-dire des paiements à vos adresses), qui fournit des copies de ces transactions ainsi qu’une branche de Merkle les reliant au bloc dans lequel elles apparaissent. Cela exploite la structure de l’arbre de Merkle pour permettre la preuve d’inclusion sans avoir besoin du contenu complet du bloc.
Comme une optimisation supplémentaire, les en-têtes de bloc qui sont enterrés suffisamment profondément peuvent être jetés après un certain temps (par exemple, vous avez seulement vraiment besoin de stocker aussi bas que 2016 en-têtes).
Le niveau de difficulté requis pour obtenir la confiance que le nœud distant ne vous fournit pas de transactions fictives dépend de votre modèle de menace. Si vous vous connectez à un nœud qui est connu pour être fiable, la difficulté n’a pas d’importance. Si vous choisissez un nœud aléatoire, le coût pour un attaquant de miner une séquence de blocs contenant une transaction fictive devrait être plus élevé que la valeur à obtenir en vous escroquant. En changeant la profondeur à laquelle le bloc doit être enterré, vous pouvez échanger le temps de confirmation contre le coût d’une attaque.
Les programmes mettant en œuvre cette approche peuvent avoir des frais généraux de stockage/réseau fixes dans le cas nul d’aucune utilisation, et une utilisation des ressources proportionnelle aux transactions reçues/envoyées.
Voir aussi : Thin Client Security.
Travaux connexes
Il existe quelques propositions pour optimiser la scalabilité de Bitcoin. Certaines d’entre elles nécessitent un alt-chain / hard fork.
- Compression ultime de la blockchain – l’idée que la blockchain peut être compressée pour obtenir des « nœuds lite sans confiance »
- Le papier Finite Blockchain qui décrit la division de la blockchain en trois structures de données, chacune mieux adaptée à son objectif. Les trois structures de données sont une blockchain finie (conserver N blocs dans le passé), un « arbre de compte » qui conserve le solde du compte pour chaque adresse avec un solde non nul, et une « chaîne de preuve » qui est une version réduite (toujours croissante) de la blockchain.
- Lightning Network, un protocole alternatif pour la compensation des transactions dans lequel les nœuds établissent des canaux de micropaiement entre eux et règlent sur la chaîne de blocs occasionnellement. Les utilisateurs ordinaires interagissent principalement ou uniquement avec les canaux de paiement et n’utilisent la blockchain que pour les transferts importants et le stockage à froid.
