SPV pourrait-il soutenir un milliard d'utilisateurs de Bitcoin ? Évaluer une demande de scalabilité

Jameson Lopp est ingénieur logiciel chez BitGo, créateur de statoshi.info et fondateur de bitcoinsig.com.

Dans cet article Analyses , Lopp examine en profondeur les affirmations selon lesquelles il serait sûr de supprimer la limite de taille de bloc du Bitcoin et de s'appuyer plutôt sur les méthodes existantes de « vérification simplifiée des paiements » (SPV).

Une nouvelle affirmation est perpétuée dans le débat sur la mise à l’échelle du Bitcoin .

Nous entendons dire qu'il est prudent de supprimer la limite de taille de bloc, car Bitcoin peut facilement s'adapter à des tailles de blocs énormes, prenant en charge des milliards d'utilisateurs grâce aux méthodes existantes de « vérification simplifiée des paiements » (SPV). La SPV est censée être très évolutive en raison de la faible quantité de données qu'elle nécessite pour stocker, envoyer et recevoir un client SPV.

Examinons cette affirmation sous plusieurs angles.

Comment fonctionne SPV

Satoshi

décrit la conception de haut niveau pour SPV dans lelivre blanc sur le Bitcoin, bien qu'il T été mis en œuvre que deux ans plus tard, lorsque Mike Hearn a créé BitcoinJ.

En supprimant les transactions T pertinentes pour le portefeuille du client SPV, il a pu réaliser des économies substantielles en termes d'utilisation du disque. Il a fallu attendre 18 mois supplémentaires pour BIP 37À publier, fournissant une spécification pour le filtrage Bloom des transactions, s'appuyant ainsi sur la racine Merkle de l'en-tête de bloc pour prouver l'inclusion d'une transaction dans un bloc, comme l'avait décrit Satoshi. Cela a permis de réduire considérablement l'utilisation de la bande passante.

Lorsqu'un client SPV se synchronise avec le réseau Bitcoin , il se connecte à un ou plusieurs nœuds Bitcoin entièrement validés, détermine le dernier bloc à l'extrémité de la chaîne, puis demande tous les en-têtes de bloc avec une commande « getheaders » pour les blocs du dernier bloc synchronisé jusqu'à l'extrémité de la chaîne.

Si le client SPV est uniquement intéressé par des transactions spécifiques correspondant à un portefeuille, il construira un filtre Bloom basé sur toutes les adresses pour lesquelles son portefeuille possède des clés privées et enverra une commande « filterload » au(x) nœud(s) complet(s) afin qu'ils sachent qu'ils doivent uniquement renvoyer les transactions correspondant au filtre.

Après avoir synchronisé les en-têtes de bloc et éventuellement chargé un filtre Bloom, le client SPV envoie une commande « getdata » pour Request chaque bloc (éventuellement filtré) qu'il a manqué de voir depuis la dernière fois qu'il était en ligne, séquentiellement.

Une fois le client synchronisé, s'il reste connecté au(x) homologue(s) du nœud complet, il ne recevra que les messages d'inventaire « inv » pour les transactions correspondant au filtre Bloom chargé.

Mise à l'échelle du client SPV

Du point de vue du client, le filtrage Bloom est un moyen très efficace de trouver des transactions pertinentes dans la blockchain, tout en utilisant un minimum de ressources CPU, de bande passante et d'espace disque.

Chaque en-tête de bloc Bitcoin ne représente que 80 octets, ce qui représente, au moment de la rédaction de cet article, seulement 38 mégaoctets de données pour l'ensemble des plus de huit ans d'histoire de la blockchain. Chaque année (environ 52 560 blocs) n'ajoute que 4,2 mégaoctets, quelle que soit la taille des blocs de la blockchain.

L'arbre de Merkle utilisé pour prouver l'inclusion d'une transaction dans un bloc est également extrêmement évolutif. Comme chaque nouvelle « couche » ajoutée à l'arbre double le nombre total de « feuilles » qu'il peut représenter, il n'est T nécessaire d'avoir un arbre très profond pour prouver de manière compacte l'inclusion d'une transaction, même au sein d'un bloc contenant des millions de transactions.

via Maîtriser Bitcoin

La structure de données de l'arbre de Merkle est si efficace qu'elle peut représenter 16 millions de transactions avec une profondeur de seulement 24 %, soit suffisamment pour représenter un bloc de 8 Go. Pourtant, la preuve de l'arbre de Merkle pour une telle transaction reste inférieure à 1 Ko !

📷viaMaîtriser Bitcoin

Il est assez clair que du point de vue d'un client SPV, le réseau Bitcoin pourrait être étendu à des blocs de plusieurs gigaoctets et les clients SPV n'auraient pas de difficulté à traiter les petites quantités de données requises, même sur un téléphone mobile avec une connexion 3G.

Mais hélas, faire évoluer le réseau Bitcoin n’est pas aussi simple.

Mise à l'échelle du serveur SPV

Si SPV est incroyablement efficace pour les clients, il n'en va pas de même pour le serveur, c'est-à-dire l'ensemble des nœuds auxquels les clients SPV adressent leurs requêtes. Cette méthode présente une faible évolutivité pour plusieurs raisons.

Les nœuds du réseau doivent traiter une quantité considérable de données pour renvoyer les résultats d'un seul pair, et ils doivent répéter cette opération sur chaque bloc pour chaque pair qui le demande. Les E/S disque deviennent rapidement un goulot d'étranglement.

Chaque client SPV doit synchroniser l'intégralité de la blockchain depuis son dernier contact avec le réseau. S'il estime avoir manqué des transactions, il devra réanalyser l'intégralité de la blockchain depuis la date de création du portefeuille. Dans le pire des cas, au moment de la rédaction de cet article, cela représente environ 150 Go. Le nœud complet doit charger chaque bloc depuis le disque, le filtrer selon les spécifications du client et renvoyer le résultat.

Les blockchains étant une forme de registres à ajout uniquement, ce volume ne cessera de croître. Sans modifications importantes du protocole, l'élagage de la blockchain est incompatible avec la norme BIP 37 : elle suppose que tous les blocs sont disponibles sur tous les nœuds complets annonçant NODE_BLOOM.

Les clients SPV du protocole BIP 37 peuvent être trompés par omission. Pour éviter ce problème, les clients SPV se connectent à plusieurs nœuds (généralement quatre) Bien que cela ne soit pas encore garanti, les clients SPV peuvent être isolés du réseau principal par une attaque Sybil. Cela multiplie par quatre la charge sur le réseau des nœuds complets.

Pour chaque client SPV connecté et synchronisé à l'extrémité de la blockchain, chaque bloc et transaction entrants doivent être filtrés individuellement. Cela nécessite un temps processeur non négligeable et doit être effectué séparément pour chaque client SPV connecté.

Analyser les chiffres

Au moment de la rédaction de ce document, environ 8 300 nœuds complets acceptent les connexions entrantes ; environ 8 000 d'entre eux annoncent NODE_BLOOM et devraient donc être capables de traiter les requêtes des clients SPV. Mais combien de clients SPV le nombre actuel de nœuds complets en écoute peut-il raisonnablement prendre en charge ?

Que faudrait-il pour que le réseau soit composé de nœuds complets capables de prendre en charge à la fois un milliard d’utilisateurs quotidiens et des blocs suffisamment grands pour accueillir leurs transactions ?

Bitcoin CORE utilise par défaut un maximum de 117 connexions entrantes, ce qui porte le nombre de sockets disponibles à 936 000 sur le réseau. Cependant, la majorité de ces sockets sont déjà utilisés aujourd'hui.

Chaque nœud complet se connecte par défaut à huit autres nœuds complets. Le développeur de Bitcoin CORE, Luke-Jr (très approximatif) nombre de nœuds On estime à 100 000 le nombre total de nœuds au moment de la rédaction ; 92 000 d'entre eux ne mettent T de sockets à disposition des clients SPV. Cela représente 800 000 sockets disponibles pour les nœuds complets, ne laissant que 136 000 sockets disponibles pour les clients SPV.

Cela m'amène à conclure qu'environ 85 % des sockets disponibles sont consommés par le maillage réseau des nœuds complets. (Il est à noter que la méthode d'estimation de Luke-Jr ne permet T de déterminer le temps de connexion des nœuds non à l'écoute ; certains d'entre eux se déconnectent et se reconnectent sûrement périodiquement.)

Mon nœud qui alimentestatoshi.infoEn moyenne, 100 nœuds complets (huit sortants, 92 entrants) et 25 clients SPV sont utilisés. Cela représente 80 % des sockets disponibles consommés par les nœuds complets.

Si nous voulons que même un milliard de clients SPV puissent utiliser un tel système, il faudra disposer de suffisamment de ressources de nœuds complètes pour les desservir : sockets réseau, cycles CPU, E/S disque, etc. Sommes-nous capables de calculer correctement ?

Afin de donner le bénéfice du doute aux affirmations sur la mise à l'échelle du SPV, j'utiliserai quelques hypothèses prudentes selon lesquelles chacun des milliards d'utilisateurs du SPV :

– Envoyez et recevez une transaction par jour.

– Synchroniser leur portefeuille avec la pointe de la blockchain une fois par jour.

– Interrogez quatre nœuds différents lors de la synchronisation pour réduire les risques d’être trompé par omission.

Un milliard de transactions par jour, si elles étaient réparties uniformément (ce qui ne serait certainement pas le cas), donnerait environ 7 millions de transactions par bloc. Grâce à la grande scalabilité des arbres de Merkle, il suffirait de 23 hachages pour prouver l'inclusion d'une transaction dans un tel bloc : 736 octets de données, plus 500 octets en moyenne pour la transaction.

Ajoutez 12 Ko supplémentaires d'en-têtes de bloc par jour et un client SPV n'utiliserait toujours qu'environ 20 Ko de données par jour.

Cependant, un milliard de transactions par jour génère 500 Go de données blockchain que les nœuds complets doivent stocker et traiter. Chaque fois qu'un client SPV se connecte et demande à retrouver les transactions de son portefeuille de la veille, quatre nœuds complets doivent lire et filtrer 500 Go de données chacun.

Rappelons qu'il existe actuellement environ 136 000 sockets disponibles pour les clients SPV sur le réseau de 8 000 nœuds complets desservant SPV. Si chaque client SPV utilise quatre sockets, seuls 34 000 clients peuvent se synchroniser avec le réseau à un instant T. Si le nombre de personnes connectées simultanément était supérieur à ce nombre, les autres utilisateurs essayant d'ouvrir leur portefeuille rencontreraient des erreurs de connexion lors de la synchronisation avec la partie supérieure de la blockchain.

Ainsi, pour que le réseau actuel puisse prendre en charge 1 milliard d'utilisateurs SPV qui se synchronisent une fois par jour, alors que seulement 34 000 peuvent se synchroniser à un moment donné, cela représente 29 400 « groupes » d'utilisateurs qui doivent se connecter, se synchroniser et se déconnecter : chaque utilisateur devrait pouvoir synchroniser les données de la veille en moins de trois secondes.

Cela pose un problème, car chaque nœud complet devrait pouvoir lire et filtrer 167 Go de données par seconde et par client SPV en continu. Avec 20 clients SPV par nœud complet, cela représente 3 333 Go par seconde. Je ne connais aucun périphérique de stockage capable d'un tel débit. Il devrait être possible de créer une immense matrice RAID 0. disques SSD haut de gammequi peuvent atteindre environ 600 Mo/s chacun.

Il faudrait 5 555 disques pour atteindre le débit cible. Le disque associé, utilisé à titre d'exemple, coûte 400 $ au moment de la rédaction de cet article et offre une capacité d'environ 1 To, soit suffisamment pour stocker l'équivalent de deux jours de blocs dans ce réseau théorique. Il faudrait donc un nouveau réseau de disques tous les deux jours, ce qui coûterait plus de 2,2 millions de dollars ; soit plus de 400 millions de dollars pour stocker l'équivalent d'une année de blocs tout en garantissant le débit de lecture requis.

Bien sûr, nous pouvons jouer avec ces hypothèses et ajuster différents chiffres. Pouvons-nous créer un scénario dans lequel le coût du nœud est plus raisonnable ?

Essayons :

Et si nous disposions de 100 000 nœuds complets exécutant tous des disques rotatifs haute capacité et moins chers, et que nous les convainquions d'accepter les connexions client SPV ? Et si nous parvenions également à modifier le logiciel du nœud complet pour prendre en charge 1 000 clients SPV connectés ?

Cela nous donnerait 100 millions de sockets disponibles pour les clients SPV, capables de prendre en charge 25 millions de clients SPV simultanés sur le réseau. Chaque client SPV disposerait ainsi de 2 160 secondes par jour pour se synchroniser avec le réseau. Pour qu'un nœud complet KEEP répondre à la demande, il devrait maintenir une vitesse de lecture constante de 231 Mo/s par client SPV, soit 231 Go/s pour 1 000 clients SPV connectés.

Un disque dur de 7 200 tr/min peut lire environ 220 Mo/s, vous pouvez donc atteindre ce débit de lecture avec une matrice RAID 0 d'un BIT plus de 1 000 disques.

Au moment de la rédaction de cet article, vous pouvez acheter unDisque dur de 10 To pour 400 $, ainsi, une matrice RAID de 400 000 $ de ces disques vous permettrait de stocker l'équivalent de 20 jours de blocs - cela équivaut à un montant beaucoup plus gérable de 7,2 millions de dollars pour stocker l'équivalent d'un an de blocs tout en répondant aux exigences de débit de lecture du disque.

Il est important de noter qu'aucune ONE sensée n'utiliserait une matrice RAID 0 avec autant de disques, car une panne d'un seul disque endommagerait l'ensemble de la matrice. Par conséquent, une matrice RAID avec tolérance aux pannes serait encore plus coûteuse et moins performante. Il semble également incroyablement optimiste que 100 000 organisations soient prêtes à débourser des millions de dollars par an pour exploiter un nœud complet.

Il convient également de noter que ces estimations prudentes supposent que les clients SPV coordonneraient leurs synchronisations de manière uniforme tout au long de la journée. En réalité, il y aurait des pics et des creux d'activité cycliques quotidiens et hebdomadaires ; le réseau devrait donc disposer d'une capacité nettement supérieure aux estimations précédentes pour répondre aux pics de demande.

Sinon, de nombreux clients SPV ne parviendraient pas à se synchroniser pendant les heures de pointe d’utilisation.

Il est intéressant de noter que la modification du nombre de sockets par nœud n'a T d'impact sur la charge globale d'un nœud complet donné ; celui-ci doit néanmoins traiter la même quantité de données. Ce qui compte vraiment dans cette équation, c'est le ratio nœuds complets/clients SPV. Et, bien sûr, la taille des blocs de la chaîne que les nœuds complets doivent traiter.

Le résultat final semble inévitable : le coût d’exploitation d’un nœud complet capable de répondre à la demande SPV d’un milliard de transactions quotidiennes en chaîne serait astronomique.

À la recherche d'un terrain d'entente

À ce stade, il est tout à fait clair qu’un milliard de transactions par jour met le coût d’exploitation d’un nœud entièrement validant hors de portée de toutes les entités, sauf des plus riches.

Mais que se passerait-il si nous inversions ce calcul et essayions plutôt de trouver une formule pour déterminer le coût de l’ajout de charge au réseau en augmentant le débit des transactions en chaîne ?

Pour que le réseau Bitcoin puisse prendre en charge un nombre cible de transactions par seconde (ajoutant une capacité de 86 400 nouveaux utilisateurs quotidiens nets), nous pouvons calculer les besoins en débit de disque par nœud comme suit :

Cela nous donne le débit de lecture disque minimal par seconde pour un nœud complet afin de répondre à la demande des clients SPV. Compte tenu des caractéristiques existantes du réseau et de la Technologies disponible, nous pouvons extrapoler une estimation du coût d'exploitation du nœud en utilisant le débit disque comme goulot d'étranglement supposé. Il est à noter que d'autres contraintes de ressources entreraient certainement en jeu, augmentant ainsi le coût d'exploitation du nœud complet.

Pour lecalculs suivants, J'ai utilisé ces hypothèses :

– Taille moyenne des transactions en octets = 500 octets sur la basestatoshi.info.

– Nombre total d’utilisateurs SPV = un par transaction et par jour.

– Sockets consommées par un client SPV = standard de quatre.

– Nombre de sockets disponibles pour les clients SPV sur chaque nœud complet = nombre calculé précédemment de 20.

– Nombre total de sockets réseau disponibles pour les clients SPV = nombre calculé précédemment de 136 000.

– Coût du débit et de l’espace du disque dur = 400 $ pour des disques de 10 To à 7 200 tr/min en configuration RAID 0.

Malheureusement, les besoins en débit du disque et donc le coût d'exploitation d'un nœud complet augmentent de manière quadratique avec le nombre de transactions par seconde. Ces coûts deviennent rapidement intenables pour la plupart des entités.

À titre de référence, rappelons que Visa traite environ 2 000 transactions par seconde. Sur Bitcoin , cela nécessiterait près de 200 000 dollars de disques pour KEEP à la demande SPV. ONE est important de noter que ces graphiques KEEP le nombre de nœuds complets à 8 000 ; en réalité, ce nombre diminuerait probablement avec l'augmentation des coûts, ce qui accélérerait encore les exigences de débit et les coûts d'exploitation des nœuds restants.

Il semble que cela soit une force aggravante de la centralisation des nœuds.

Les sondages (non scientifiques) que j'ai menés l'année précédente montraient que 98 % des opérateurs de nœuds ne paieraient pas plus de 100 $ par mois pour gérer un nœud, même s'ils étaient fortement investis en Bitcoin. Je suis prêt à parier qu'une augmentation d'un ordre de grandeur des transactions on-chain de bitcoins entraînerait la perte de la majorité des nœuds complets, tandis qu'une augmentation de deux ordres de grandeur entraînerait une perte de 90 % ou plus des nœuds.

Je pense qu'il est raisonnable de supposer que très peu d'entités seraient prêtes à se donner la peine de construire des matrices RAID pour exploiter un nœud complet. Si tel est le cas, il est intenable d'affirmer que de telles augmentations seraient acceptables pour l'utilisateur moyen, car le débit disque ou les sockets disponibles sur le nœud complet T loin d'être suffisants pour répondre à la demande SPV.

Autres faiblesses du SPV

Le SPV est idéal pour les utilisateurs finaux qui n'ont T besoin de la sécurité ou de la Politique de confidentialité d'un nœud entièrement validant. Cependant, de nombreuses raisons pourraient freiner l'adoption d'un réseau Bitcoin majoritairement SPV, quelle que soit son évolutivité.

SPV fait des hypothèses majeures qui font qu'il a une sécurité et une Politique de confidentialité plus faibles qu'un nœud entièrement validant :

• Les clients SPV font confiance aux mineurs pour valider et appliquer correctement les règles du Bitcoin; ils partent du principe que la blockchain présentant la preuve de travail cumulative la plus élevée est également une chaîne valide. Cet article vous permettra Guides sur la différence entre les modèles de sécurité SPV et les nœuds complets.
• Les clients SPV supposent que les nœuds complets ne leur mentiront pas par omission. Un nœud complet ne peut T mentir et prétendre qu'une transaction existait dans un bloc alors qu'elle T pas réellement, mais il peut mentir en affirmant qu'une transaction qui existe dans un bloc n'a pas eu lieu.
• Les clients SPV, soucieux d'efficacité, ne Request que les données relatives aux transactions qui leur appartiennent. Cela entraîne une perte massive de Politique de confidentialité.

Il est intéressant de noter que le co-auteur du BIP 37, Matt Corallo,regrette de l'avoir créé:

« Les filtres anti-éblouissement BIP37 SPV constituent un problème majeur pour la Politique de confidentialité des utilisateurs du système. Je suis désolé, j'ai écrit ça. »

Les clients SPV filtrés par Bloom du BIP 37 ontpratiquement aucune Politique de confidentialité, même en utilisant des taux de faux positifs déraisonnablement élevés. Jonas Nick [ingénieur en sécurité chez Blockstream] a découvert qu'à partir d'une seule clé publique, il pouvait déterminer 70 % des autres adresses appartenant à un portefeuille donné.

[intégrer]https://www.youtube.com/watch?v=HScK4pkDNds[/intégrer]

Vous pourriez contourner la faible Politique de confidentialité de SPV en répartissant les filtres Bloom entre plusieurs pairs, bien que cela rendrait l'évolutivité de SPV encore pire en plaçant plus de charge sur davantage de nœuds complets.

Le protocole BIP 37 est également vulnérable aux attaques par déni de service triviales. Le code de démonstration estdisponible iciqui est capable de paralyser des nœuds complets en effectuant de nombreuses demandes d'inventaire rapides via des filtres spécialement conçus qui provoquent une recherche continue du disque et une utilisation élevée du processeur.

L'auteur de la preuve de concept de l'attaque, le développeur CORE Peter Todd, explique :

« Le problème fondamental est que vous pouvez consommer une quantité disproportionnée de bande passante d'E/S disque avec très peu de bande passante réseau. »

À ce jour, les alertes à la fraude décrites par Satoshi dans le livre blanc n'ont toujours pas été mises en œuvre. En fait, les recherches dans ce domaine ont montré qu'il pourrait même être impossible de mettre en œuvre des alertes à la fraude légères.

Par exemple, une alerte à la fraude ne fonctionne que si vous pouvez obtenir les données nécessaires pour prouver la fraude. Si un mineur ne fournit pas ces données, l'alerte ne peut T être créée. De ce fait, les clients SPV ne bénéficient T du niveau de sécurité que Satoshi imaginait.

D'un point de vue général, un monde composé principalement de nœuds SPV facilite grandement les modifications de consensus, telles que le plafond de jetons ou même la modification du registre. La réduction du nombre de nœuds de validation complète implique une application plus centralisée des règles de consensus et donc une moindre résistance à leur modification. Certains pourraient considérer cela comme une fonctionnalité ; la plupart le considèrent certainement comme un défaut.

Améliorations potentielles

La sécurité et l'évolutivité du SPV pourraient être améliorées de plusieurs manières : preuves de fraude, indices de fraude, preuves d'entrée, preuves de dépenses, etc. Mais à ma connaissance, aucune de ces solutions n'a dépassé le stade de la conception, et encore moins n'est prête pour un déploiement en production.

Engagements du filtre Bloom

Cela pourrait améliorer la Politique de confidentialité, mais il y a un compromis d'utilité entre la taille du filtre et son taux de faux positifs : trop grossier signifie que les pairs téléchargent beaucoup trop de blocs de faux positifs, trop fin signifie que les filtres seront absolument gigantesques et peu pratiques à télécharger pour quiconque avec un client SPV.

Cela réduirait la charge sur le débit du disque du nœud complet, mais le compromis serait une augmentation de la bande passante à la fois pour les clients SPV et les nœuds complets, car des blocs entiers devraient être transférés sur le réseau.

Ce filtrage compact côté client récemment proposé élimine les problèmes de Politique de confidentialité , mais nécessite le téléchargement de blocs complets s'il y a une correspondance avec le filtre (mais pas nécessairement via le réseau p2p !).

Engagements de l'UTXO

Cela permettrait aux clients SPV de synchroniser leur ensemble d'UTXO actuel, et donc le solde de leur portefeuille, sans que le nœud complet ait à analyser l'intégralité de la blockchain. Cela fournirait plutôt une preuve de l'existence des UTXO.

Il peut être possible de se protéger contre les attaques DoS du filtre Bloom en exigeant des clients SPV qu'ils soumettent soit une preuve de travail (intenable sur un appareil alimenté par batterie comme un téléphone), soit des micropaiements basés sur un canal (impossible à démarrer si un client n'a T encore reçu d'argent), mais aucune de ces deux solutions n'offre une solution simple.

Les exigences de lecture de disque pour les nœuds complets pourraient probablement être réduites de plusieurs manières via une indexation améliorée des données et un traitement par lots des demandes des clients SPV.

Ryan X Charles a souligné dans les commentaires ci-dessous qu'utiliser le protocole de paiement BIP70 pour communiquer directement à un utilisateur l' ID UTXO du paiement envoyé lui éviterait d'avoir à utiliser des filtres Bloom, puisqu'il pourrait Request les données directement aux nœuds complets. C'est incroyablement efficace si l'on est prêt à accepter le compromis en Politique de confidentialité .

Il suffit de dire qu’il y a beaucoup de place pour l’amélioration : de nombreux défis devront être surmontés afin d’améliorer l’évolutivité de la chaîne.

Solutions de mise à l'échelle adaptées

Si nous ignorons la multitude d’autres problèmes divers liés à la mise à l’échelle vers des tailles de blocs plus grandes, tels que la latence de propagation des blocs, la mise à l’échelle des ensembles UTXO, les temps de synchronisation initiaux de la blockchain et les compromis en matière de sécurité et de Politique de confidentialité , il peut être techniquement possible de faire évoluer Bitcoin vers un milliard d’utilisateurs quotidiens sur la chaîne s’il existe des entités prêtes à investir des ressources importantes pour développer des améliorations logicielles et exploiter l’infrastructure requise.

Il semble toutefois hautement improbable que Bitcoin évolue naturellement de cette manière, car il existe des moyens bien plus efficaces de faire évoluer le système. Le plus efficace est une forme de mise à l'échelle déjà utilisée : la consolidation autour de fournisseurs d'API centralisés. L'utilisation de ces méthodes implique généralement d'importants compromis en matière de confiance et de Politique de confidentialité , mais nombre de ces interactions impliquent des accords contractuels qui atténuent certains des dangers.

En termes de mise à l'échelle sans confiance, les protocoles de couche 2 tels que Lightning offrent une évolutivité bien plus efficace, car les volumes importants de données transférés ne sont transmis qu'au petit nombre de parties directement impliquées dans une transaction hors chaîne donnée. On peut comparer cela à la différence entre une couche de communication Ethernet de type « broadcast-to-all » et une couche IP routée : Internet ne pourrait T évoluer sans routage, et l'Internet monétaire non plus.

Bien que cette approche de mise à l’échelle soit beaucoup plus complexe techniquement que la mise à l’échelle centralisée traditionnelle et nécessitera de surmonter certains défis uniques, l’investissement initial de ressources pour la recherche et le développement de ces protocoles de routage rapportera d’énormes dividendes à long terme, car ils réduisent la charge qui doit être supportée par l’ensemble du réseau de plusieurs ordres de grandeur.

Il existe également de nombreuses options intermédiaires qui peuvent être explorées :

– Systèmes de garde centralisés avec une Politique de confidentialité parfaite qui utilisent des jetons Chaum tels que HashCash.

– Systèmes centralisés de preuve de connaissance nulle non dépositaire tels queTumbleBit.

– Chaînes latérales fédérées (multisignatures semi-fiables)https://elementsproject.org/sidechains/.

– Sécurisé par les mineurs (semi-fiable)chaînes de transmission.

Je suis toujours convaincu qu'à long terme, Bitcoin aura besoin de blocs beaucoup plus gros.

Mais soyons patients et diplomates en essayant de faire évoluer le système aussi efficacement que possible tout en préservant ses propriétés de sécurité et de Politique de confidentialité .

Un PayPal auditable et légèrement décentralisé aurait sûrement une utilité s'il était fonctionnel du point de vue de l'utilisateur moyen, mais il n'offrirait pas le niveau de souveraineté financière dont bénéficient les bitcoiners aujourd'hui.

Merci à Matt Corallo, Mark Erhardt et Peter Todd pour avoir relu et fourni des commentaires sur cet article.

Déclaration de transparence: CoinDesk est une filiale de Digital Currency Group, qui détient une participation dans Blockstream.