Livre blanc de Bitcoin : un système de cash peer-to-peer

PANews note de l’éditeur : Le 31 octobre 2008, Satoshi Nakamoto a publié le Livre blanc de Bitcoin, aujourd’hui marque le 17ème anniversaire. Ci-dessous, retrouvez la traduction du Livre blanc par Li Xiaolai, pour redécouvrir ce classique.

Résumé : Une version purement pair-à-pair d’un système de monnaie électronique permettrait aux paiements en ligne d’être envoyés directement d’une partie à une autre sans passer par une institution financière. Les signatures numériques offrent une partie de la solution, mais si une tierce partie de confiance est toujours nécessaire pour empêcher la double dépense, le principal avantage du paiement électronique est annulé. Nous proposons une solution utilisant un réseau pair-à-pair pour résoudre le problème de la double dépense. Le réseau pair-à-pair horodate chaque transaction en enregistrant les données de hash de la transaction dans une chaîne de preuve de travail basée sur le hash, qui s’étend continuellement, formant un enregistrement qui ne peut être modifié sans refaire toute la chaîne. La chaîne la plus longue sert à la fois à prouver la séquence des événements et à démontrer qu’elle provient du plus grand pool de Puissance de hachage CPU. Tant que la majorité de la Puissance de hachage CPU est contrôlée par des Nœuds honnêtes — c’est-à-dire qu’ils ne coopèrent pas avec ceux qui tentent d’attaquer le réseau — les Nœuds honnêtes généreront la chaîne la plus longue et dépasseront les attaquants en vitesse. Le réseau lui-même nécessite une structure minimale. Les informations sont diffusées au mieux, les Nœuds sont libres de rejoindre ou de partir ; mais lors de l’adhésion, 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 tierces parties de confiance pour traiter les paiements électroniques. Bien que ce système fonctionne assez bien pour la plupart des transactions, il reste limité par les défauts inhérents au modèle basé sur la confiance. Les transactions totalement irréversibles ne sont en réalité pas possibles, car les institutions financières ne peuvent éviter d’arbitrer les litiges. L’arbitrage augmente les coûts de transaction, limite la taille minimale des transactions et empêche de nombreuses transactions de faible montant. De plus, il existe un coût plus important : le système ne peut fournir de paiement irréversible pour des services irréversibles. La possibilité de réversibilité crée un besoin omniprésent de confiance. Les Marchands doivent se méfier de leurs clients, leur demandant plus d’informations que nécessaire (sauf en cas de confiance). Un certain taux de fraude est considéré comme inévitable. Ces coûts et incertitudes de paiement peuvent être évités lors de paiements directs en monnaie physique entre personnes ; mais aucun mécanisme ne permet de payer via un canal de communication lorsque l’une des parties n’est pas digne de confiance.

Ce dont nous avons réellement besoin, c’est d’un système de paiement électronique basé sur la preuve cryptographique plutôt que sur la confiance, permettant à deux parties quelconques de transacter directement sans avoir besoin d’une tierce partie de confiance. Les transactions irréversibles garanties par la Puissance de hachage protègent les Marchands contre la fraude, tandis que des mécanismes de protection courants pour les acheteurs sont faciles à mettre en œuvre. Dans ce document, nous proposons une solution au problème de la double dépense, utilisant un serveur d’horodatage distribué pair-à-pair pour générer une preuve basée sur la Puissance de hachage, enregistrant chaque transaction dans l’ordre chronologique. Ce système est sécurisé tant que les Nœuds honnêtes contrôlent collectivement plus de Puissance de hachage 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 transfère une pièce à quelqu’un d’autre, il ajoute à la fin de la chaîne une Signature numérique contenant le hash de la transaction précédente et la Clé publique du nouveau propriétaire. Le destinataire peut vérifier la propriété de la chaîne de Signatures numériques en validant la Signature.

Le problème de ce procédé est que le destinataire ne peut pas vérifier qu’aucun des précédents propriétaires n’a effectué une double dépense. La solution courante consiste à introduire une autorité centralisée de confiance, appelée « Monnaie centrale », qui vérifie chaque transaction pour détecter la double dépense. Après chaque transaction, la pièce doit retourner à la Monnaie centrale, qui émet alors une nouvelle pièce. Ainsi, seules les pièces émises directement par la Monnaie centrale sont considérées comme fiables et non dépensées deux fois. Le problème de cette solution est que le destin de tout le système monétaire dépend de l’entreprise qui gère la Monnaie centrale (comme une banque), et chaque transaction doit passer par elle.

Nous avons besoin d’un moyen permettant au destinataire de s’assurer qu’aucun des précédents propriétaires n’a signé une transaction antérieure. Pour notre objectif, seule la première transaction compte, donc nous ne nous soucions pas des tentatives ultérieures de double dépense. 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 Monnaie centrale, celle-ci connaît toutes les transactions et peut confirmer leur ordre. Pour accomplir cela sans une « partie de confiance », les enregistrements de transaction doivent être publiquement annoncés, et nous avons besoin d’un système permettant aux participants de s’accorder sur une histoire unique des transactions reçues. Le destinataire doit prouver qu’au moment de la transaction, la majorité des Nœuds reconnaît qu’elle est la première reçue.

3. Serveur d’horodatage (Timestamp Server)

Notre solution commence par un serveur d’horodatage. Le serveur d’horodatage fonctionne ainsi : il prend le hash d’un groupe (bloc) d’enregistrements et l’horodate, puis diffuse le hash, comme le ferait un journal ou un post sur un forum Usenet[2-5]. L’horodatage prouve que les données existaient à ce moment-là, sinon le hash n’aurait pas pu être généré. Chaque horodatage inclut le hash de l’horodatage précédent, formant ainsi une chaîne ; chaque nouvel horodatage est ajouté après le précédent.

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

Pour réaliser un serveur d’horodatage distribué pair-à-pair, nous utilisons un système de preuve de travail similaire au hashcash d’Adam Back, plutôt qu’un journal ou un post sur un forum. La preuve de travail consiste à rechercher une valeur ; cette valeur, une fois hashée (par exemple avec SHA-256), doit commencer par un certain nombre de zéros. Chaque zéro supplémentaire augmente exponentiellement la difficulté, mais la vérification ne nécessite qu’un calcul de hash.

Dans notre réseau d’horodatage, la preuve de travail est réalisée en ajoutant continuellement un nonce au bloc jusqu’à ce qu’une valeur satisfaisante soit trouvée ; la condition étant que le hash du bloc commence par le nombre requis de zéros. Une fois qu’un bloc satisfait la preuve de travail, il ne peut plus être modifié sans refaire tout le travail précédent. À mesure que de nouveaux blocs sont ajoutés, modifier un bloc existant nécessite de refaire le travail de tous les blocs suivants.

La preuve de travail résout également la question de savoir qui décide pour la majorité. Si la « majorité » était déterminée par « une adresse IP, un vote », alors quiconque peut obtenir de nombreuses adresses IP serait considéré comme la majorité. La preuve de travail est essentiellement « un CPU, un vote ». La « majorité » est représentée par la chaîne la plus longue, car c’est celle à laquelle le plus de travail a été consacré. Si la majorité de la Puissance de hachage CPU est contrôlée par des Nœuds honnêtes, la chaîne honnête croît plus vite que les autres. Pour modifier un bloc existant, un attaquant doit refaire la preuve de travail de ce bloc et de tous les suivants, puis rattraper et dépasser le travail des Nœuds honnêtes. Nous montrerons plus loin pourquoi la probabilité qu’un attaquant retardé rattrape la chaîne diminue exponentiellement à mesure que de nouveaux blocs sont ajoutés.

Pour s’adapter à l’augmentation de la Puissance de hachage matérielle et aux variations du nombre de Nœuds au fil du temps, la difficulté de la preuve de travail est déterminée par une moyenne mobile du nombre de blocs générés par heure. Si les blocs sont générés trop rapidement, la difficulté augmente.

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 pour ce bloc ;
4. Lorsqu’un bloc trouve sa preuve de travail, il est diffusé à tous les Nœuds ;
5. Les autres Nœuds n’acceptent ce bloc que si toutes ses transactions sont valides et non dépensées deux fois ;
6. Les Nœuds indiquent qu’ils acceptent le bloc en incluant son hash comme hash précédent dans le prochain bloc qu’ils créent.

Les Nœuds considèrent toujours la chaîne la plus longue comme la bonne et continuent à y ajouter de nouvelles données. Si deux Nœuds diffusent simultanément deux versions différentes du « prochain bloc », certains Nœuds recevront l’un en premier, d’autres l’autre. Dans ce cas, les Nœuds travaillent sur le bloc qu’ils ont reçu en premier, mais gardent l’autre branche au cas où elle deviendrait la plus longue. Lorsque la prochaine preuve de travail est trouvée et qu’une branche devient plus longue, la divergence temporaire est résolue et les Nœuds travaillant sur l’autre branche passent à la chaîne la plus longue.

Les nouvelles transactions n’ont pas besoin d’être diffusées à tous les Nœuds. Il suffit qu’elles atteignent suffisamment de Nœuds pour être incluses dans un bloc rapidement. La diffusion des blocs tolère également la perte de certains messages. Si un Nœud ne reçoit pas un bloc, il le demandera lorsqu’il recevra le bloc suivant et remarquera qu’il lui manque un bloc précédent.

6. Récompenses (Incentive)

Par convention, la première transaction de chaque bloc est une transaction spéciale qui génère une nouvelle pièce, attribuée au créateur du bloc. Cela récompense les Nœuds qui soutiennent le réseau et fournit un moyen d’émettre les pièces dans la circulation — puisqu’il n’y a pas d’autorité centralisée pour émettre les pièces dans ce système. Ainsi, une quantité stable de nouvelles pièces entre en circulation, comme les mineurs d’or qui dépensent leurs ressources pour ajouter de l’or au marché. Dans notre système, la ressource dépensée est le temps CPU et l’électricité utilisée.

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, la différence est un frais de transaction, qui récompense le Nœud ayant inclus la transaction dans le bloc. Une fois qu’un nombre prédéfini de pièces est en circulation, la récompense proviendra entièrement des frais de transaction, et il n’y aura jamais d’Inflation.

Le mécanisme de récompenses peut aussi encourager les Nœuds à rester honnêtes. Si un attaquant avide parvient à réunir plus de Puissance de hachage CPU que tous les Nœuds honnêtes, il doit choisir : utiliser cette Puissance de hachage pour tromper les autres en récupérant l’argent qu’il a dépensé, ou l’utiliser pour générer de nouvelles pièces ? Il devrait constater que suivre les règles est plus rentable, car il peut obtenir plus de pièces que tous les autres réunis, ce qui est clairement préférable à détruire le système et rendre sa richesse inutile.

7. Récupération de l’espace disque (Reclaiming Disk Space)

Si la dernière transaction d’une pièce a eu lieu il y a suffisamment de blocs, les enregistrements de transactions antérieurs de cette pièce peuvent être supprimés pour économiser de l’espace disque. Pour ce faire sans compromettre le hash du bloc, les enregistrements de transaction sont hashés dans un arbre de Merkle[7,2,5], dont seule la racine est incluse dans le hash du bloc. En supprimant les branches, les anciens blocs peuvent être compressés. Les hash internes n’ont pas besoin d’être conservés.

Un en-tête de bloc sans enregistrement de transaction fait environ 80 octets. Supposons qu’un bloc soit généré toutes les dix minutes, 80 octets × 6 × 24 × 365 = 4,2 Mo par an. En 2008, la plupart des ordinateurs vendus étaient équipés de 2 Go de mémoire, et selon la loi de Moore, la capacité augmente de 1,2 Go par an ; même si les en-têtes de blocs doivent être stockés en mémoire, cela ne pose pas de problème.

8. Vérification simplifiée des paiements (Simplified Payment Verification)

Il est possible de vérifier les paiements sans exécuter un Nœud complet du réseau. L’utilisateur n’a besoin que d’une copie des en-têtes de la chaîne la plus longue avec preuve de travail — il peut vérifier auprès des Nœuds en ligne que sa copie provient bien de la chaîne la plus longue — puis obtenir les branches de l’arbre de Merkle pour relier la transaction à un bloc horodaté. L’utilisateur ne peut pas vérifier la transaction lui-même, mais en se connectant à un point de la chaîne, il voit qu’un Nœud du réseau a accepté la transaction, et les blocs ajoutés ensuite confirment que le réseau l’a acceptée.

Tant que les Nœuds honnêtes contrôlent le réseau, la vérification est fiable. Cependant, si le réseau est contrôlé par des attaquants, la vérification n’est plus fiable. Bien que les Nœuds du réseau puissent vérifier les enregistrements de transaction, si un attaquant contrôle le réseau, la vérification simplifiée peut être trompée par des enregistrements de transaction falsifiés. Une stratégie consiste à ce que le logiciel client accepte les alertes des Nœuds du réseau. Lorsqu’un Nœud détecte un bloc invalide, il envoie une alerte, affichant une notification dans le logiciel de l’utilisateur, l’invitant à télécharger le bloc complet et à vérifier la cohérence de la transaction. Les Marchands avec des transactions de Haute fréquence devraient toujours exécuter leur propre Nœud complet pour garantir une sécurité indépendante et une confirmation rapide des transactions.

9. Combinaison et division de la valeur (Combining and Splitting Value)

Bien qu’il soit possible de traiter les pièces une par une, enregistrer chaque centime séparément serait maladroit. Pour permettre la division et la combinaison de la valeur, les enregistrements de transaction contiennent plusieurs entrées et sorties. Généralement, il s’agit soit d’une seule entrée provenant d’une transaction précédente relativement importante, soit de plusieurs entrées combinant de petites sommes ; en même temps, il y a au maximum deux sorties : une pour le paiement (vers le destinataire), et si nécessaire, une pour la monnaie (vers l’expéditeur).

Il est à noter que le « fan-out » n’est pas un problème ici — le « fan-out » signifie qu’une transaction dépend de plusieurs transactions, qui elles-mêmes dépendent de nombreuses autres. Il n’est jamais nécessaire d’extraire une copie complète et indépendante de l’historique d’une transaction.

10. Vie privée (Privacy)

Le modèle bancaire traditionnel protège la vie privée en limitant l’accès aux informations des parties et de la tierce partie de confiance. Le besoin de rendre toutes les transactions publiques exclut cette méthode. Cependant, la vie privée peut être maintenue en coupant le flux d’informations ailleurs — l’anonymat des Clés publiques. Le public peut voir qu’une certaine somme a été transférée d’une Clé publique à une autre, mais aucune information ne relie ces Clés publiques à une personne spécifique. Ce niveau de publication d’informations ressemble à celui des transactions boursières, où seuls l’heure et le montant de chaque transaction sont publiés, mais personne ne sait qui sont les parties.

11. Calculs (Calculations)

Supposons qu’un attaquant tente de générer une chaîne alternative plus rapidement que la chaîne honnête. Même s’il réussit, le système ne se retrouve pas dans une situation ambiguë : il ne peut pas créer de la valeur à partir de rien, ni obtenir de l’argent qui ne lui appartient pas. Les Nœuds du réseau n’accepteront pas une transaction invalide comme paiement, et les Nœuds honnêtes n’accepteront jamais un bloc contenant une telle transaction. Au maximum, l’attaquant peut modifier ses propres transactions pour tenter de récupérer l’argent qu’il a déjà dépensé.

La compétition entre la chaîne honnête et l’attaquant peut être décrite comme une marche aléatoire binomiale. Un succès signifie qu’un nouveau bloc est ajouté à la chaîne honnête, augmentant son avance de 1 ; un échec signifie qu’un bloc est ajouté à la chaîne de l’attaquant, réduisant l’avance de la chaîne honnête de 1.

La probabilité que l’attaquant rattrape son retard est similaire au problème de la ruine du joueur. Supposons qu’un joueur avec des jetons illimités commence en déficit et peut parier un nombre illimité de fois pour combler ce déficit. Nous pouvons calculer la probabilité qu’il comble finalement son déficit, c’est-à-dire la probabilité que l’attaquant rattrape la chaîne honnête[8], comme suit :

Puisque nous avons supposé que , et que le nombre de blocs à rattraper augmente, la probabilité de succès de l’attaquant diminue exponentiellement. Si l’attaquant n’a pas la chance de prendre de l’avance au début, ses chances de succès disparaissent à mesure qu’il prend du retard.

Considérons maintenant combien de temps le destinataire d’une nouvelle transaction doit attendre pour être sûr que l’expéditeur ne peut pas modifier la transaction. Supposons que l’expéditeur est un attaquant, essayant de faire croire au destinataire qu’il a payé, puis de récupérer l’argent. Dans ce cas, le destinataire recevra une alerte, mais l’expéditeur espère que ce sera trop tard.

Le destinataire génère une nouvelle paire de Clés publiques et privées, puis communique la Clé publique à l’expéditeur juste avant de signer. Cela empêche l’expéditeur de préparer à l’avance une chaîne de blocs et, avec suffisamment de chance, de prendre de l’avance avant d’effectuer la transaction. Une fois le paiement effectué, l’expéditeur malhonnête commence secrètement à travailler sur une chaîne parallèle, tentant d’y inclure une version Inversée de la transaction.

Le destinataire attend que la transaction soit incluse dans un bloc, puis qu’un autre bloc soit ajouté. Il ne sait pas où en est l’attaquant, mais peut supposer que le temps moyen de génération des blocs honnêtes est connu ; la progression potentielle de l’attaquant suit une distribution de Poisson, dont l’espérance est :

Pour calculer la probabilité que l’attaquant puisse encore rattraper, nous multiplions la densité de Poisson de chaque progression possible de l’attaquant par la probabilité qu’il puisse rattraper à partir de ce point :

Pour éviter de sommer une série infinie sur la densité de distribution…

Converti en programme C…

En obtenant quelques résultats, on voit que la probabilité diminue exponentiellement avec l’augmentation de Z :

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

12. Conclusion (Conclusion)

Nous avons proposé un système de transaction électronique ne nécessitant pas de confiance. Il commence par un cadre classique de pièces utilisant des Signatures numériques, qui offre un contrôle robuste de la propriété mais ne résout pas la double dépense. Pour résoudre ce problème, nous proposons 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 de hachage CPU, les attaquants ne peuvent pas modifier le système par la Puissance de hachage seule. La robustesse du réseau réside dans sa simplicité non structurée. Les Nœuds peuvent travailler simultanément avec peu de coordination. Ils n’ont même pas besoin d’être identifiés, car le chemin des messages ne dépend pas d’un destinataire spécifique ; les messages sont simplement diffusés au mieux. Les Nœuds sont libres de rejoindre ou de partir, et lorsqu’ils reviennent, ils n’ont qu’à accepter la chaîne de preuve de travail comme preuve de tout ce qui s’est passé pendant leur absence. Ils votent avec leur Puissance de hachage CPU, en ajoutant continuellement de nouveaux blocs valides à la chaîne et en rejetant les blocs invalides, indiquant ainsi leur acceptation ou non des transactions valides. Toute règle ou récompense nécessaire peut être imposée par ce mécanisme de Consensus.