Note : Le 31 octobre 2008, Satoshi Nakamoto a publié le livre blanc de Bitcoin sur le site P2P foundation (Bitcoin : un système de monnaie électronique pair-à-pair). À l'occasion du 16e anniversaire de la publication du livre blanc, Gold Finance republie à nouveau la version chinoise du livre blanc de Bitcoin pour relire ce classique qui a changé à jamais le monde de la finance.

Auteur : Satoshi Nakamoto ; Traducteur : Li Xiaolai

Résumé : Un système de paiement électronique entièrement basé sur le pair-à-pair, permettant des paiements en ligne directement d'une partie à l'autre, sans passer par des institutions financières. Bien que la signature numérique offre une partie de la solution, si un tiers de confiance est toujours nécessaire pour prévenir la double dépense, alors le principal avantage des paiements électroniques est annulé. Nous proposons une solution qui utilise un réseau pair-à-pair pour résoudre le problème de la double dépense. Le réseau pair-à-pair date chaque transaction en inscrivant les données de hachage de la transaction dans une chaîne de preuve de travail qui s'étend continuellement, formant un enregistrement qui ne peut être modifié sans une réexécution complète. La chaîne la plus longue sert à prouver les événements qui ont été témoins et leur ordre, tout en prouvant qu'elle provient du plus grand pool de puissance CPU. Tant que la grande majorité de la puissance CPU est contrôlée par des nœuds bienveillants - c'est-à-dire qu'ils ne coopèrent pas avec des nœuds qui tentent d'attaquer le réseau - alors les nœuds bienveillants généreront la chaîne la plus longue, et ce à une vitesse qui dépassera celle de l'attaquant. Ce réseau nécessite une structure minimale. Les informations seront propagées avec un maximum d'effort, les nœuds vont et viennent librement ; cependant, lors de leur ajout, ils doivent toujours accepter la chaîne de preuve de travail la plus longue comme preuve de tout ce qui s'est passé pendant leur absence.

1. Introduction (Introduction)

Le commerce sur Internet dépend presque entièrement des institutions financières comme tiers de confiance pour traiter les paiements électroniques. Bien que pour la plupart des transactions, ce système soit plutôt bon, il est néanmoins alourdi par les défauts inhérents à un modèle basé sur la confiance. Des transactions complètement irréversibles ne sont en réalité pas possibles, car les institutions financières ne peuvent éviter l'arbitrage des litiges. Les coûts d'arbitrage augmentent le coût des transactions, limitant ainsi la taille des transactions minimales possibles et empêchant même de nombreuses petites transactions. De plus, il y a un coût encore plus élevé : le système ne peut offrir des paiements irréversibles pour les services irréversibles. La possibilité de renversement engendre un besoin omniprésent de confiance. Les commerçants doivent se méfier de leurs clients, et demander à ceux-ci plus d'informations que nécessaire (sinon pour la confiance). Un certain pourcentage de fraude est considéré comme inévitable. Ces coûts et cette incertitude des paiements, bien qu'évitables lors de paiements directs entre personnes avec de l'argent physique ; mais aucun mécanisme ne peut être utilisé pour effectuer des paiements dans un canal de communication où l'une des parties n'est pas digne de confiance.

Ce dont nous avons vraiment besoin, c'est d'un système de paiement électronique basé sur des preuves cryptographiques plutôt que sur la confiance, permettant à deux parties de traiter directement sans avoir besoin de faire confiance à un tiers. Les transactions irréversibles garanties par la puissance CPU peuvent aider les vendeurs à éviter la fraude, tandis que le mécanisme de garantie quotidien pour les acheteurs est également facile à mettre en œuvre. Dans cet article, nous proposerons une solution au problème de la double dépense, utilisant des serveurs de timestamp distribués pair-à-pair pour générer des preuves basées sur la puissance de calcul, enregistrant chaque transaction dans l'ordre chronologique. Ce système est sécurisé tant que les nœuds honnêtes détiennent globalement plus de puissance CPU que les attaquants coopérants.

2. Transactions (Transactions)

Nous définissons une pièce électronique comme une chaîne de signatures numériques. Lorsqu'un propriétaire passe une pièce à une autre personne, il le fait en ajoutant la signature numérique suivante à la fin de cette chaîne de signatures numériques : le hachage de la transaction précédente, ainsi que la clé publique du nouveau propriétaire. Le destinataire peut vérifier la propriété de la chaîne de signatures numériques en vérifiant la signature.

Le problème de cette voie est que le destinataire ne peut pas vérifier qu'aucun des anciens propriétaires n'a effectué de double dépense. Une solution courante consiste à introduire une autorité centralisée de confiance, ou une « mint », pour vérifier si chaque transaction comporte une double dépense. Après chaque transaction, les pièces doivent revenir à la mint, qui émet ensuite une nouvelle pièce. Ainsi, seules les pièces émises directement par la mint sont dignes de confiance et non soumises à une double dépense. Le problème de cette solution est que le sort de l'ensemble du système monétaire est lié à l'entreprise qui gère la mint (comme une banque), chaque transaction doit passer par elle.

Nous avons besoin d'un moyen permettant au destinataire de confirmer qu'aucun des propriétaires précédents n'a signé aucune transaction antérieure. Pour nos objectifs, seule la première transaction compte, donc nous ne nous soucions pas des tentatives de double dépense suivantes. La seule façon de confirmer qu'une transaction n'existe pas est de connaître toutes les transactions. Dans le modèle de la mint, la mint connaît toutes les transactions et peut confirmer leur ordre. Pour accomplir cette tâche sans la participation d'une « partie de confiance », les enregistrements des transactions doivent être publiquement annoncés, et nous avons besoin d'un système permettant aux participants de reconnaître qu'ils reçoivent tous le même historique de transactions unique. Le destinataire doit prouver qu'à chaque fois qu'une transaction a eu lieu, la majorité des nœuds ont pu s'accorder à dire qu'il s'agissait de la première reçue.

3. Serveur de timestamp (Timestamp Server)

Cette solution commence par un serveur de timestamp. Un serveur de timestamp fonctionne ainsi : il appose un timestamp sur le hachage d'un groupe (bloc) d'enregistrements (items), puis diffuse le hachage, tout comme un journal ou un message dans un groupe de discussion. Évidemment, le timestamp peut prouver que ces données existaient avant ce moment, sinon le hachage n'aurait pas pu être généré. Chaque timestamp contient dans son hachage le timestamp précédent, formant ainsi une chaîne ; chaque nouveau timestamp est ajouté après le timestamp précédent.

4. Preuve de travail (Proof-of-Work)

Pour mettre en œuvre un serveur de timestamp distribué basé sur le pair-à-pair, nous devons utiliser un système de preuve de travail semblable à celui de Adam Back avec Hashcash, plutôt que quelque chose comme des journaux ou des messages de groupes de discussion. La preuve de travail consiste à chercher une valeur ; cette valeur doit satisfaire les conditions suivantes : après avoir extrait la valeur de hachage - par exemple en utilisant SHA-256 pour calculer la valeur de hachage - cette valeur de hachage doit commencer par un certain nombre de 0. Exiger un 0 supplémentaire augmentera exponentiellement la charge de travail, et cette charge de travail ne peut être vérifiée qu'en calculant un hachage.

Dans notre réseau de timestamp, nous réalisons la preuve de travail en ajoutant continuellement un nombre aléatoire (Nonce) dans les blocs, jusqu'à ce qu'une valeur satisfaisant les conditions soit trouvée ; cette condition est que le hachage de ce bloc commence par un nombre spécifié de 0. Une fois que le résultat de la puissance CPU dépensée satisfait la preuve de travail, ce bloc ne pourra plus être modifié, sauf si tout le travail précédent est refait. Au fur et à mesure que de nouveaux blocs sont ajoutés, changer le bloc actuel signifie qu'il faut refaire tout le travail des blocs suivants.

La preuve de travail résout également la question de savoir qui peut représenter la majorité pour prendre des décisions. Si la « majorité » est déterminée sur la base de « une adresse IP un vote », alors quiconque peut gérer de nombreuses adresses IP pourrait être considéré comme la « majorité ». Fondamentalement, la preuve de travail est « un CPU un vote ». La « décision de la majorité » est représentée par la chaîne la plus longue, car c'est la chaîne sur laquelle le plus de travail a été investi. Si la majorité de la puissance CPU est contrôlée par des nœuds honnêtes, alors la chaîne honnête croît le plus rapidement, à un rythme qui dépasse de loin celui des autres chaînes concurrentes. Pour modifier un bloc déjà produit, l'attaquant devra refaire la preuve de travail de ce bloc ainsi que de tous les blocs suivants, puis rattraper et dépasser le travail des nœuds honnêtes. La suite montre pourquoi la probabilité qu'un attaquant retardé puisse rattraper diminuera exponentiellement avec l'augmentation du nombre de blocs.

Pour faire face à l'augmentation continue de la puissance de calcul du matériel, et aux variations possibles dans le nombre de nœuds participants au fil du temps, la difficulté de la preuve de travail est donc déterminée : sur la base d'une moyenne mobile du nombre de blocs produits par heure. Si les blocs sont générés trop rapidement, la difficulté augmentera.

5. Réseau (Network)

Les étapes pour faire fonctionner le réseau sont les suivantes :

  1. Toutes les nouvelles transactions sont diffusées à tous les nœuds ;

  2. Chaque nœud regroupe les nouvelles transactions dans un bloc ;

  3. Chaque nœud commence à chercher une preuve de travail difficile pour ce bloc ;

  4. Lorsque ce bloc trouve sa preuve de travail, il doit diffuser ce bloc à tous les nœuds ;

  5. De nombreux autres nœuds n'accepteront ce bloc que si les conditions suivantes sont remplies : toutes les transactions y sont valides et n'ont pas été dépensées deux fois ;

  6. La façon dont de nombreux nœuds indiquent au réseau qu'ils acceptent ce bloc est, lors de la création du prochain bloc, d'inclure le hachage du bloc accepté comme hachage précédent du nouveau bloc.

Les nœuds considèrent toujours que la chaîne la plus longue est la bonne, et continueront à y ajouter de nouvelles données. S'il y a deux nœuds qui diffusent simultanément deux versions différentes du « prochain bloc », certains nœuds recevront d'abord l'un, tandis que d'autres recevront d'abord l'autre. Dans ce cas, les nœuds continueront à travailler sur le bloc qu'ils ont reçu en premier, mais garderont également l'autre branche au cas où elle deviendrait la chaîne la plus longue. Lorsque la prochaine preuve de travail est trouvée et qu'une des branches devient une chaîne plus longue, cette divergence temporaire sera résolue, et les nœuds travaillant sur l'autre branche passeront à la chaîne plus longue.

Les nouvelles transactions n'ont pas nécessairement besoin d'être diffusées à tous les nœuds. Tant qu'elles atteignent un nombre suffisant de nœuds, ces transactions seront bientôt incluses dans un bloc. La diffusion des blocs permet également de rejeter certains messages. Si un nœud n'a pas reçu un certain bloc, il réalisera qu'il a manqué ce bloc lorsqu'il recevra le prochain, et demandera alors à récupérer le bloc manquant.

6. Récompense (Incentive)

Conformément à l'accord, la première transaction de chaque bloc est une transaction spéciale qui génère une nouvelle pièce, dont la propriété appartient au créateur de ce bloc. Cela permet aux nœuds de soutenir le réseau d'être récompensés et fournit un moyen d'introduire des pièces en circulation - dans ce système, il n'y a pas d'autorité centralisée pour émettre ces pièces. Ainsi, en ajoutant de manière stable un certain nombre de nouvelles pièces en circulation, c'est comme si les mineurs de l'or dépensaient continuellement leurs ressources pour ajouter de l'or à la circulation. Dans notre système, les ressources dépensées sont le temps de travail CPU et l'électricité qu'ils utilisent.

Les récompenses peuvent également provenir des frais de transaction. Si la valeur de sortie d'une transaction est inférieure à sa valeur d'entrée, alors la différence est le frais de transaction ; ce frais de transaction est utilisé pour récompenser les nœuds qui incluent cette transaction dans le bloc. Une fois qu'une quantité déterminée de pièces est en circulation, la récompense sera entièrement attribuée aux frais de transaction, et il n'y aura absolument pas d'inflation.

Le mécanisme de récompense peut également encourager les nœuds à rester honnêtes. Si un attaquant avide peut rassembler plus de puissance CPU que tous les nœuds honnêtes, il doit faire un choix : utiliser cette puissance pour voler l'argent qu'il a dépensé pour tromper les autres ? Ou utiliser cette puissance pour générer de nouvelles pièces ? Il devrait être capable de constater qu'agir conformément aux règles est plus rentable, car les règles actuelles lui permettent d'acquérir plus de pièces que tous les autres réunis, ce qui est manifestement plus avantageux que de détruire secrètement le système et de voir sa richesse disparaître.

7. Récupération d'espace disque (Reclaiming Disk Space)

Si une transaction récente d'une pièce a eu lieu suffisamment de blocs auparavant, alors l'historique des transactions de dépenses de cette pièce peut être abandonné - dans le but d'économiser de l'espace disque. Pour réaliser cela sans altérer le hachage du bloc, l'historique des transactions sera inclus dans un arbre Merkle, et seul le hachage de la racine de l'arbre sera inclus dans le hachage de ce bloc. En coupant les branches, les anciens blocs peuvent être compressés. Les hachages internes n'ont pas besoin d'être conservés.

Un en-tête de bloc sans aucun enregistrement de transaction fait environ 80 octets. Supposons qu'un bloc soit produit toutes les dix minutes, 80 octets multipliés par 6 multipliés par 24 multipliés par 365, égalent 4,2M par an. En 2008, la plupart des ordinateurs disponibles à la vente étaient équipés de 2 Go de mémoire, et selon la loi de Moore, la mémoire augmenterait de 1,2 Go par an, même si les en-têtes de blocs devaient être stockés en mémoire, cela ne poserait pas de problème.

8. Confirmation de paiement simplifiée

Il est même possible de confirmer un paiement sans faire fonctionner un nœud complet du réseau. L'utilisateur a seulement besoin d'une copie de l'en-tête de bloc de la chaîne la plus longue avec preuve de travail - il peut vérifier en consultant des nœuds en ligne qu'il détient effectivement une chaîne la plus longue - puis obtenir les nœuds de branche de l'arbre Merkle, reliant ainsi à la transaction au moment où ce bloc a été timestampé. L'utilisateur ne peut pas vérifier la transaction lui-même, mais en se connectant à un endroit sur la chaîne, il peut voir qu'un nœud du réseau a accepté cette transaction, et les blocs ajoutés par la suite confirment que le réseau a accepté cette transaction.

Tant que les nœuds honnêtes contrôlent toujours le réseau, la validation est fiable. Cependant, lorsque le réseau est contrôlé par un attaquant, la validation n'est pas aussi fiable. Bien que les nœuds du réseau puissent vérifier les enregistrements des transactions eux-mêmes, tant que l'attaquant peut continuer à contrôler le réseau, la méthode de validation simplifiée pourrait être trompée par les enregistrements de transactions falsifiés par l'attaquant. Une des stratégies d'atténuation consiste à ce que le logiciel client accepte des avertissements des nœuds du réseau. Lorsque les nœuds du réseau détectent un bloc invalide, ils émettent une alerte, notifiant l'utilisateur par un message sur son logiciel pour lui dire de télécharger le bloc complet et l'avertir de vérifier la cohérence des transactions. Les commerçants qui effectuent des paiements fréquents devraient encore vouloir faire fonctionner leur propre nœud complet pour garantir une sécurité plus indépendante et une confirmation des transactions plus rapide.

9. Combinaison et division de valeur

Bien qu'il soit possible de traiter les pièces une par une, le fait de créer un enregistrement séparé pour chaque centime est peu pratique. Pour permettre la division et la fusion de la valeur, les enregistrements de transactions contiennent plusieurs entrées et sorties. En général, il s'agit soit d'une seule entrée provenant d'une transaction précédente relativement importante, soit de plusieurs entrées provenant de montants plus petits ; pendant ce temps, il y a au maximum deux sorties : l'une est le paiement (dirigé vers le destinataire), et si nécessaire, l'autre est la monnaie (dirigée vers le payeur).

Il convient de noter que la « diffusion » n'est pas un problème ici - ce que l'on appelle la « diffusion » fait référence à une transaction qui dépend de plusieurs transactions, et ces transactions dépendent à leur tour d'encore plus de transactions. Il n'est jamais nécessaire d'extraire une copie complète et indépendante de l'historique de chaque transaction.

10. Vie privée (Privacy)

Le modèle bancaire traditionnel atteint un certain degré de protection de la vie privée en limitant l'accès des autres aux informations concernant les commerçants et les tiers de confiance. Le besoin de rendre toutes les transactions publiques a rejeté cette approche. Cependant, maintenir la vie privée peut être réalisé en coupant le flux d'informations à un autre endroit - l'anonymat des clés publiques. Le public peut voir qu'une personne a transféré un certain montant à une autre, mais aucune information ne pointe vers une personne précise. Ce niveau de publication d'informations ressemble à la négociation boursière, où seul le temps et le montant de chaque transaction sont publiés, mais personne ne sait qui sont les deux parties de la transaction.

Il y a une autre couche de pare-feu. Les commerçants devraient activer une nouvelle paire de clés publiques et privées pour chaque transaction afin que les autres ne puissent pas retracer ces transactions à un même propriétaire. Certaines transactions à multiples entrées peuvent toujours être retracées, car ces entrées seront inévitablement identifiées comme provenant du même propriétaire. Le danger est que si le propriétaire d'une clé publique est exposé, toutes les autres transactions associées seront également exposées.

11. Calculs (Calculations)

Supposons un scénario où un attaquant essaie de générer une chaîne alternative plus rapide que la chaîne honnête. Même s'il réussit, il ne peut pas faire de modifications arbitraires au système, c'est-à-dire qu'il ne peut pas créer de valeur à partir de rien ni obtenir de l'argent qui ne lui a jamais appartenu. Les nœuds du réseau ne considèrent pas une transaction invalide comme un paiement, et les nœuds honnêtes n'accepteront jamais un bloc contenant un tel paiement. L'attaquant ne peut modifier que les transactions qui lui appartiennent et essayer de récupérer l'argent qu'il a déjà dépensé.

La concurrence entre la chaîne honnête et l'attaquant peut être décrite par un mouvement aléatoire binomial. L'événement de succès est qu'un nouveau bloc a été ajouté à la chaîne honnête, augmentant son avance de 1 ; l'événement d'échec est qu'un nouveau bloc a été ajouté à la chaîne de l'attaquant, faisant diminuer l'avance de la chaîne honnête de 1.

La probabilité que l'attaquant parvienne à rattraper est similaire au problème de la faillite des joueurs. Supposons un joueur avec des jetons infinis, commençant en déficit, lui permettant de parier un nombre infini de fois avec pour objectif de combler ses pertes. Nous pouvons calculer la probabilité qu'il finisse par combler ses pertes, c'est-à-dire la probabilité que l'attaquant rattrape la chaîne honnête, comme suit :

Puisque nous avons supposé p > q, et que le nombre de blocs que l'attaquant doit rattraper augmente, alors sa probabilité de succès diminuera exponentiellement. Lorsque la chance est défavorable, si l'attaquant n'a pas pu faire un grand bond en avant dès le départ, sa probabilité de gagner s'effacera à mesure qu'il sera de plus en plus en retard.

Considérons maintenant combien de temps un destinataire d'une nouvelle transaction doit attendre pour être suffisamment sûr que le payeur ne peut pas modifier cette transaction. Supposons que le payeur est un attaquant, essayant de faire croire au destinataire pendant un certain temps qu'il a payé pour le paiement, puis de renvoyer cet argent à lui-même. Dans ce cas, le destinataire recevra bien sûr un avertissement, mais le payeur espère que ce sera trop tard.

Le destinataire génère une nouvelle paire de clés publiques et privées, puis informe le payeur de la clé publique peu avant de signer. Cela empêche une situation où le payeur prépare à l'avance un bloc sur une chaîne par des calculs continus, et avec un peu de chance, il pourrait être suffisamment en avance pour exécuter la transaction plus tard. Une fois les fonds émis, ce payeur malhonnête commence secrètement à travailler sur une autre chaîne parallèle, essayant d'y inclure une version inversée de la transaction.

Le destinataire attend que cette transaction soit incluse dans un bloc, et que z blocs aient été ajoutés par la suite. Il ne sait pas comment progresse le travail de l'attaquant, mais il peut supposer le temps moyen nécessaire pour générer chaque bloc sur la chaîne honnête ; les progrès potentiels de l'attaquant suivent une distribution de Poisson, dont l'espérance est :

Pour calculer la probabilité que l'attaquant puisse encore rattraper, nous devons multiplier la densité de probabilité de la distribution de Poisson du nombre de blocs que l'attaquant doit rattraper par la probabilité de rattraper avec ce nombre de blocs en retard :

Convertir en programme C...

En obtenant des résultats partiels, nous pouvons voir que la probabilité diminue exponentiellement avec l'augmentation de z :

Si P est inférieur à 0,1 %...

12. Conclusion

Nous proposons un système de transaction électronique qui ne doit pas dépendre de la confiance ; le point de départ est un cadre de pièces utilisant des signatures numériques ordinaires, bien qu'il offre un contrôle robuste de la propriété, il ne peut éviter la double dépense. Pour résoudre ce problème, nous proposons d'utiliser un réseau pair-à-pair utilisant un mécanisme de preuve de travail pour enregistrer un historique public des transactions, tant que les nœuds honnêtes contrôlent la majorité de la puissance CPU, les attaquants ne pourront pas réussir à falsifier le système sur le plan de la puissance de calcul. La robustesse de ce réseau réside dans sa simplicité non structurée. Les nœuds peuvent fonctionner instantanément avec peu de collaboration. Ils n'ont même pas besoin d'être identifiés, car le chemin des messages ne dépend pas d'une destination spécifique ; les messages doivent simplement être propagés avec un maximum d'effort. Les nœuds viennent et partent librement, et lorsqu'ils se reconnectent, ils n'ont qu'à accepter la chaîne de preuve de travail comme preuve de tout ce qui s'est produit pendant leur période hors ligne. Ils votent avec leur puissance CPU, en ajoutant constamment de nouveaux blocs valides à la chaîne et en rejetant les blocs invalides, pour indiquer leur acceptation ou non des transactions valides. Toutes les règles et récompenses nécessaires peuvent être appliquées par ce mécanisme de consensus.

Références (References)

  1. b-money Dai Wei (1998-11-01) http://www.weidai.com/bmoney.txt

  2. Conception d'un service de timestamp sécurisé avec des exigences minimales de confiance Henri Massias, Xavier Serret-Avila, Jean-Jacques Quisquater 20e Symposium sur la théorie de l'information dans les Benelux (1999-05) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.13.6228

  3. Comment timestamp un document numérique Stuart Haber, W. Scott Stornetta Journal of Cryptology (1991) https://doi.org/cwwxd4 DOI : 10.1007/bf00196791

  4. Améliorer l'efficacité et la fiabilité du timestamp numérique Dave Bayer, Stuart Haber, W. Scott Stornetta Sequences II (1993) https://doi.org/bn4rpx DOI : 10.1007/978-1-4613-9323-8_24

  5. Noms sécurisés pour les chaînes de bits Stuart Haber, W. Scott Stornetta Actes de la 4e conférence ACM sur la sécurité des ordinateurs et des communications - CCS '97 (1997) https://doi.org/dtnrf6 DOI : 10.1145/266420.266430

  6. Hashcash - Une contre-mesure contre les attaques par déni de service Adam Back (2002-08-01) http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.15.8

  7. Protocoles pour les systèmes de cryptographie à clé publique Ralph C. Merkle 1980 IEEE Symposium on Security and Privacy (1980-04) https://doi.org/bmvbd6 DOI : 10.1109/sp.1980.10006

  8. Une introduction à la théorie des probabilités et à ses applications William Feller John Wiley & Sons (1957) https://archive.org/details/AnIntroductionToProbabilityTheoryAndItsApplicationsVolume1

#BTC