Tout a commencé avec le livre blanc de Bitcoin, un document explicatif sur le concept d'une technologie qui, aujourd'hui, ne fait aucun doute. Bitcoin et sa technologie sous-jacente, blockchain, sont devenues l'une des plus grandes révolutions technologiques de ces derniers temps. Ses concepts permettent des applications au potentiel incroyable. Il reste encore beaucoup à découvrir, même en dehors du secteur financier, pour lequel il a été initialement créé.

Mais comment tout a commencé?

Comme nous l'avons expliqué dans l'article sur "Qui a créé Bitcoin?", Satoshi Nakamoto a publié un document dans un forum en 2008. Il y a théoriquement défini un mode de paiement global sans intermédiaires entre utilisateurs. Un écosystème composé de pièces combinées jamais vues à ce jour. Le document, avec une présentation de style académique, s'appelle «Bitcoin Paper», que vous pouvez vérifier ici.

Préparez-vous à plonger dans les mots originaux du créateur de Bitcoin. C'est la première mention officielle de l'outil qui a beaucoup plus changé que les finances. Découvrez comment ils ont voulu façonner tout un univers de révolutions technologiques autour d'eux.

Téléchargez le livre blanc Bitcoin

Le document qui a ouvert la voie à une révolution

Voici la version traduite en espagnol du livre blanc Bitcoin.

Bitcoin: un système de paiement électronique d'utilisateur à utilisateur

Satoshi Nakamoto

satoshin@gmx.com

www.bitcoin.org

Résumé

Une version purement électronique de l'argent liquide permettrait d'envoyer des paiements en ligne directement, d'une entité à une autre. Tout cela sans passer par une institution financière. Les signatures numériques fournissent une partie de la solution au problème, mais les principaux avantages sont perdus s'il doit y avoir un tiers de confiance pour empêcher le double dépense. Nous proposons une solution au problème de la double dépense en utilisant un réseau d'utilisateur à utilisateur.

Le réseau horodate les transactions qu'il entre dans une chaîne continue de preuve de travail basée sur le hachage. Avec cela, un enregistrement est formé qui ne peut pas être modifié sans recréer la preuve de travail complète. La plus longue chaîne ne sert pas seulement de témoin et de preuve de la séquence des événements. Mais cela garantit également qu'il provient du pool avec le plus grand traitement CPU.

Tant que la plus grande partie de la puissance de traitement du processeur est sous le contrôle de noeuds qui ne coopèrent pas pour attaquer le réseau. De cette façon, ils généreront la chaîne la plus longue et donneront un avantage aux attaquants. Le réseau lui-même nécessite une structure minimale. Les messages sont envoyés sous le principe du moindre effort, et les nœuds peuvent quitter et rejoindre le réseau quand ils le souhaitent. Accepter toujours la plus longue chaîne de preuves de travail, comme preuve de ce qui s'est passé pendant votre absence.

Introduction

Le commerce sur Internet repose exclusivement sur des institutions financières, qui font office de tiers de confiance, pour le traitement des paiements électroniques. Bien que le système fonctionne suffisamment bien pour la plupart des transactions, il souffre toujours des faiblesses inhérentes au modèle basé sur la confiance. Des transactions totalement irréversibles ne sont pas vraiment possibles, car les institutions financières ne peuvent éviter la médiation dans les litiges.

Le coût de la médiation augmente les coûts de transaction. Cela limite la taille pratique minimale par transaction et élimine la possibilité d'effectuer de petites transactions occasionnelles, avec un coût plus élevé pour cette perte et l'impossibilité d'effectuer des paiements irréversibles pour des services non réversibles. Avec la possibilité de revenir en arrière, le besoin de confiance augmente. Les commerçants doivent faire attention à leurs clients, les harcelant en leur demandant plus d'informations que ce qui serait autrement nécessaire.

Un certain pourcentage de fraude est accepté comme inévitable. Ces coûts et incertitudes dans les paiements peuvent être évités si la personne utilise de l'argent physique. Mais il n'existe aucun mécanisme pour effectuer des paiements via un canal de communication sans un tiers de confiance. Ce qu'il faut, c'est un système de paiement électronique basé sur des preuves cryptographiques plutôt que sur la confiance. Cela vise à permettre aux deux parties intéressées d'effectuer des transactions directement sans avoir besoin d'un tiers fiable. Les transactions qui sont peu susceptibles de s'inverser par calcul protégeraient les vendeurs contre la fraude. De même, des mécanismes d'entiercement de routine pourraient facilement être mis en œuvre pour protéger les acheteurs.

Dans cet article, nous proposons une solution au problème de la double dépense en utilisant un serveur d'horodatage distribué d'utilisateur à utilisateur pour générer une preuve informatique de l'ordre chronologique des transactions. Le système est sécurisé tant que les nœuds honnêtes contrôlent collectivement plus de puissance de traitement (CPU) que n'importe quel groupe de nœuds attaquants.

Transactions

Nous définissons une monnaie électronique comme une chaîne de signatures numériques. Chaque propriétaire transfère la pièce au suivant en signant numériquement un hachage de la transaction précédente et de la clé publique du propriétaire suivant et en ajoutant les deux à la fin de la pièce. Un bénéficiaire peut vérifier les signatures pour vérifier la chaîne de propriété.

livre blanc sur les transactions

Le problème est que le bénéficiaire ne peut pas vérifier si l'un des propriétaires précédents n'a pas dépensé deux fois la pièce. La solution courante consiste à mettre en place une autorité centrale de confiance. Une sorte de menthe, qui vérifierait si chaque transaction a une double dépense ou non. Après chaque transaction, la pièce doit être retournée à la Monnaie pour générer une nouvelle pièce. De cette manière, seules les pièces générées directement par cette menthe sont celles à qui on fait confiance pour ne pas avoir de double-dépenses.

Le problème avec cette solution est que le sort de tout le système monétaire dépend de l'entreprise qui gère la Monnaie. Toutes les transactions devant passer par eux, comme le ferait une banque. Par conséquent, nous devons trouver un moyen pour le bénéficiaire de savoir que les anciens propriétaires n'ont signé aucune transaction antérieure.

Pour nos besoins, la transaction la plus récente ou la plus ancienne est celle qui compte. Nous ne craindrons donc aucune autre tentative de double dépense ultérieure. La seule façon de confirmer l'absence de transaction est de connaître toutes les transactions existantes. Dans le modèle de la menthe, c'était cette maison qui était au courant de toutes les transactions et qui déciderait lesquelles venaient en premier. Pour y parvenir sans un tiers de confiance, les transactions doivent être annoncées publiquement [1], et nous aurons besoin d'un système de participants qui s'accordent sur une seule histoire, l'ordre dans lequel ces transactions ont été reçues. Le bénéficiaire doit savoir qu'au moment de chaque transaction, la majorité des nœuds se sont mis d'accord sur lequel était le premier reçu.

Serveur d'horodatage

La solution que nous proposons commence par un serveur d'horodatage. Un serveur d'horodatage fonctionne en hachant un bloc de données à dater et en le publiant largement, comme vous le feriez dans un journal ou une publication Usenet [2-5]. L'horodatage prouve que les données doivent évidemment avoir existé au moment pour être incluses dans le hachage. Chaque horodatage inclut l'horodatage précédent dans son hachage, formant une chaîne, de sorte que chaque horodatage supplémentaire renforce ceux précédant un horodatage donné.

horodatages du serveur

Test de travail

Pour implémenter un serveur d'horodatage suivant un schéma d'utilisateur à utilisateur, nous devrons utiliser un système de preuve de travail similaire à Adam Back's Hashcash [6], au lieu d'utiliser une publication dans un journal ou sur Usenet. La preuve de travail consiste à explorer une valeur telle que lors du calcul d'un hachage, tel que SHA-256, il commence par un nombre spécifié de zéro bits. Le travail moyen requis sera exponentiel au nombre de bits requis avec la valeur zéro mais cela peut être vérifié en exécutant un seul hachage.

Pour notre réseau d'horodatages, nous implémentons la preuve de travail en augmentant la valeur d'un champ nonce, appartenant au bloc, jusqu'à ce qu'une valeur soit trouvée qui donne le nombre requis de bits avec une valeur nulle pour le hachage de celui-ci. Une fois que l'effort CPU a été dépensé pour satisfaire la preuve de travail, le bloc ne peut pas être changé sans refaire tout le travail. Au fur et à mesure que plusieurs blocs sont enchaînés après un bloc donné, le travail pour changer un bloc inclurait de refaire tous les blocs après celui-ci.

test de travail

La preuve de travail résout également le problème de déterminer comment représenter la décision majoritaire. Si cette majorité était basée sur un vote par adresse IP, elle pourrait être modifiée par quelqu'un capable d'attribuer de nombreuses adresses IP. La preuve de travail équivaut essentiellement à «un CPU-un-vote». La décision majoritaire est représentée par la chaîne la plus longue, qui a la preuve du travail avec le plus d'efforts investis.

Si la majeure partie de la puissance du processeur est contrôlée par des nœuds honnêtes, la chaîne honnête se développera plus rapidement et laissera derrière elle toutes les autres chaînes concurrentes. Pour modifier un bloc dans le passé, un attaquant devrait refaire la preuve de travail du bloc et de tous les blocs suivants, puis rattraper et transmettre le travail des nœuds honnêtes.

Nous montrerons ensuite que la probabilité qu'un attaquant plus lent puisse atteindre la chaîne la plus longue diminue de façon exponentielle à mesure que d'autres blocs sont ajoutés.

Pour compenser la vitesse accrue du matériel et l'intérêt variable pour l'exécution des nœuds dans le temps, la difficulté de la preuve de travail est déterminée par une moyenne mobile dirigée par un nombre moyen de blocs par heure. Si ceux-ci sont générés très rapidement, la difficulté augmente.

Le Web

Les étapes que le réseau exécute sont les suivantes:

  1. De nouvelles transactions sont émises vers tous les nœuds.
  2. Chaque nœud collecte les nouvelles transactions en un seul bloc.
  3. Chaque nœud travaille pour trouver une preuve de travail difficile pour son bloc.
  4. Lorsqu'un nœud trouve une preuve de travail, il émet le bloc à tous les nœuds.
  5. Le bloc est accepté par les nœuds si toutes les transactions du bloc ont été validées et non dépensées.
  6. Les nœuds expriment leur acceptation du bloc en travaillant à la création du bloc suivant dans la chaîne, en utilisant le hachage du bloc accepté comme hachage précédent.

La chaîne la plus longue est toujours considérée comme la bonne et ils commencent à travailler sur son extension. Si deux nœuds diffusent simultanément des versions différentes du bloc suivant, certains nœuds peuvent recevoir l'un ou l'autre en premier. Dans ce cas, ils travaillent sur la première qu'ils reçoivent mais sauvegardent l'autre branche au cas où elle s'allonge. Le lien est rompu lorsque le prochain essai de travail est trouvé et qu'une branche s'allonge; les nœuds qui travaillaient sur l'autre branche sont ensuite remplacés par celui qui est maintenant plus long.

Les nouvelles émissions de transaction ne doivent pas nécessairement atteindre tous les nœuds. Au moment où ils atteignent de nombreux nœuds, ils finiront par entrer dans un bloc avant longtemps. L'émission des blocs est également tolérante à la perte de messages. Si un nœud ne reçoit pas de bloc, il le demandera lorsqu'il recevra le bloc suivant et se rendra compte qu'il en a perdu un.

Incentive

Par convention, la première transaction du bloc est une transaction spéciale qui génère une nouvelle devise appartenant au créateur du bloc. Cela incite les nœuds à prendre en charge le réseau et fournit un moyen initial de distribuer et de faire circuler les pièces, car il n'y a aucune autorité pour les créer. Cet ajout stable d'une quantité constante de nouvelles pièces est analogue aux mineurs d'or qui dépensent des ressources pour la mettre en circulation. Dans notre cas, les ressources sont le temps processeur et l'électricité dépensés.

L'incitation peut également être établie avec des coûts de transaction. Si la valeur de sortie d'une transaction est inférieure à l'entrée, la différence sera des frais de transaction qui seront ajoutés à la valeur d'incitation du bloc qui la contient. Une fois qu'un nombre prédéterminé de pièces est entré en circulation, l'incitation peut évoluer entièrement aux frais de transaction et être totalement exempte d'inflation.

L'incitation peut également aider à encourager les nœuds à rester honnêtes. Si un attaquant égoïste est capable de mobiliser plus de puissance de processeur que tous les nœuds honnêtes, il devrait choisir entre l'utiliser pour frauder les gens en volant leurs paiements, ou l'utiliser pour générer de nouvelles pièces. Vous devriez trouver plus rentable de jouer selon les règles, car elles vous favoriseront avec plus de pièces que de combiner tous les autres nœuds, que de saper le système et la validité de votre propre richesse.

Réclamation d'espace disque

Une fois que la dernière transaction est enterrée sous suffisamment de blocs, les transactions dépensées avant celle-ci peuvent être supprimées pour économiser de l'espace disque. Pour faciliter cela sans casser le hachage de bloc, les transactions sont vérifiées dans un arbre merkle [7] [2] [5], avec seulement la racine incluse dans le hachage du bloc. Les vieux blocs peuvent être compactés en enlevant les branches de l'arbre. Les hachages intérieurs n'ont pas besoin d'être enregistrés.

arbre merkle

L'en-tête d'un bloc sans transactions sera d'environ 80 octets. Si nous supposons que chaque bloc est généré toutes les 10 minutes, 80 octets * 6 * 24 * 365 = 4.2 Mo par an. Les ordinateurs étant généralement vendus avec 2 Go de RAM en 2008 et la loi de Moore prévoyant une croissance actuelle de 1.2 Go par an, le stockage ne devrait pas être un problème même si les en-têtes de bloc doivent rester en mémoire.

Vérification simplifiée des paiements

Il est possible de vérifier les paiements sans exécuter un nœud de réseau complet. Un utilisateur n'a besoin que de conserver une copie des en-têtes de bloc de la plus longue chaîne de la preuve de travail, qui peut être obtenue en effectuant une recherche dans les nœuds du réseau jusqu'à ce qu'il soit convaincu qu'il a la plus longue chaîne, et obtenir la branche de l'arbre Merkle, qui relie la transaction au bloc dans lequel elle a été datée. Bien que vous ne puissiez pas vérifier vous-même la transaction, en la reliant quelque part dans la chaîne, vous pouvez voir qu'un nœud du réseau l'a acceptée, de sorte que les blocs ajoutés par la suite confirmeraient davantage cette acceptation par le réseau.

vérification du paiement

En tant que telle, la vérification est fiable car les nœuds honnêtes contrôlent le réseau, mais devient plus vulnérable si le réseau est dominé par un attaquant. Alors que les nœuds de réseau peuvent vérifier eux-mêmes les transactions, la méthode simplifiée peut être trompée par des transactions fabriquées par un attaquant tant que l'attaquant peut dominer le réseau. Une stratégie pour vous protéger consiste à accepter les alertes des nœuds du réseau lorsqu'ils détectent un bloc invalide, en demandant à l'utilisateur de télécharger le bloc entier et les transactions alertées pour confirmer l'incohérence. Les entreprises qui reçoivent fréquemment des paiements voudront exécuter leurs propres nœuds pour une sécurité plus indépendante et une vérification plus rapide.

Combiner et diviser la valeur

Bien qu’il soit possible de manipuler les devises individuellement, il serait difficile d’effectuer des transactions distinctes pour chaque centime d’un transfert. Pour permettre à la valeur d'être fractionnée et combinée, les transactions contiennent plusieurs entrées et sorties. En règle générale, il y aura soit une seule entrée, provenant d'une transaction précédente plus importante, soit plusieurs entrées combinant des montants plus petits et au moins deux sorties: une pour le paiement et une pour renvoyer la monnaie, le cas échéant, à l'émetteur. .

Combiner et diviser la valeur

Gardez à l'esprit que ce système est en forme d'éventail, de sorte qu'une transaction peut dépendre de plusieurs transactions, et celles-ci dépendent à leur tour de beaucoup plus, ce qui n'est pas un problème. Il n'est jamais nécessaire d'extraire une seule copie complète de l'historique des transactions.

Confidentialité

Le modèle bancaire traditionnel atteint son niveau de confidentialité en limitant l'accès aux informations aux parties concernées et au tiers de confiance. La nécessité de publier toutes les transactions exclut cette méthode, mais la confidentialité peut toujours être préservée en interrompant le flux d'informations ailleurs: en gardant les clés publiques anonymes. On peut voir publiquement que quelqu'un envoie un certain montant à quelqu'un d'autre, mais sans informations liant la transaction à quelqu'un en particulier. Ceci est similaire au niveau d'information affiché sur les bourses de valeurs, où l'heure et la taille des transactions individuelles, la «bande», sont publiques, mais sans dire qui sont les parties.

modèle de confidentialité traditionnel

En tant que pare-feu supplémentaire, une nouvelle paire de clés doit être utilisée pour chaque transaction afin qu'elles puissent être associées à un propriétaire commun. Certains types d'association avec des transactions à entrées multiples sont inévitables, ce qui peut révéler que vos entrées appartiennent au même propriétaire. Le risque serait que si le propriétaire d'une clé est révélé, la liaison pourrait révéler d'autres transactions appartenant au même propriétaire.

Cálculos

Nous considérons le scénario où un attaquant tente de générer une chaîne alternative plus rapidement que la chaîne honnête. Même si cela était réalisé, cela n'ouvrirait pas le système à des changements arbitraires, tels que la création de valeur dans l'air ou la prise d'argent qui n'a jamais appartenu à l'attaquant. Les nœuds n'accepteraient pas une transaction invalide comme paiement, et les nœuds honnêtes n'accepteraient jamais un bloc les contenant. Un attaquant ne peut essayer de modifier que ses propres transactions pour reprendre l'argent qu'il a récemment dépensé.

La course entre une chaîne honnête et la chaîne d'un attaquant est caractérisée comme un chemin binomial aléatoire. L'événement de succès est la chaîne honnête étendant un bloc supplémentaire et augmentant son avance de +1, et l'événement d'échec étant la chaîne de l'attaquant s'étendant d'un bloc réduisant la distance de -1.

La probabilité qu'un attaquant puisse nous frapper, à partir d'un déficit donné, est analogue au problème Player Ruin. Supposons qu'un joueur avec un crédit illimité commence avec un déficit et joue potentiellement un nombre infini de tentatives pour essayer d'atteindre le seuil de rentabilité. On peut calculer la probabilité qu'il atteigne le point d'équilibre, ou qu'il atteigne la chaîne honnête, comme suit [8]:

p = probabilité qu'un nœud honnête trouve le bloc suivant

q = probabilité que l'attaquant trouve le bloc suivant q

qz = probabilité que l'attaquant atteigne de z blocs derrière.

Compte tenu de notre hypothèse que p> q, la probabilité diminue de façon exponentielle tandis que le nombre de blocs que l'attaquant doit atteindre augmente. Avec les chances contre vous, si vous ne faites pas un jeu chanceux dès le début, vos chances deviennent extrêmement faibles à mesure que vous prenez du retard.

Voyons maintenant combien de temps le bénéficiaire d'une nouvelle transaction doit attendre avant d'être suffisamment certain que l'émetteur ne peut pas la changer. Nous supposons que l'émetteur est un attaquant qui veut faire croire au bénéficiaire qu'il a été payé pendant un certain temps, puis modifier la transaction pour se rembourser après un certain temps, le bénéficiaire sera alerté lorsque cela se produira, mais l'émetteur espère qu'il est trop tard.

Le bénéficiaire génère une nouvelle paire de clés et remet la clé publique à l'émetteur peu après la signature. Cela empêche l'émetteur de préparer une blockchain à l'avance et peut y travailler en continu jusqu'à ce qu'il ait la chance de prendre de l'avance sur lui-même, puis d'exécuter la transaction à ce stade. Une fois la transaction soumise, l'expéditeur non autorisé commence secrètement à travailler sur une chaîne parallèle contenant une version alternative de sa transaction.

Le bénéficiaire attend que la transaction soit ajoutée à un bloc et que z blocs soient liés après la transaction. Vous n'aurez pas besoin de connaître la progression exacte de l'attaquant, mais en supposant que les blocs honnêtes aient pris la moyenne attendue par bloc, la progression potentielle de l'attaquant sera une distribution de Poisson avec une valeur attendue de:

Pour obtenir la probabilité que l'attaquant puisse encore nous atteindre maintenant, nous multiplions la densité de Poisson par la quantité de progrès qu'il aurait pu faire multipliée par la probabilité qu'il puisse atteindre ce point:

On se réorganise pour éviter la somme de la file infinie de la distribution ...

Nous convertissons en code C ...

#include double AttackerSuccessProbability (double q, int z) {double p = 1.0 - q; double lambda = z * (q / p); double somme = 1.0 ; int i, k; pour (k = 0; k <= z; k ++) {double poisson = exp (-lambda); pour (i = 1; i <= k; i ++) poisson * = lambda / i; somme - = poisson * (1 - pow (q / p, z - k)); } renvoie la somme ; }

Nous exécutons quelques résultats, nous pouvons voir que la probabilité diminue de façon exponentielle avec z.

q = 0.1 z = 0 P = 1.0000000 z = 1 P = 0.2045873 z = 2 P = 0.0509779 z = 3 P = 0.0131722 z = 4 P = 0.0034552 z = 5 P = 0.0009137 z = 6 P = 0.0002428 z = 7 P = 0.0000647 z = 8 P = 0.0000173 z = 9 P = 0.0000046 z = 10 P = 0.0000012 q = 0.3 z = 0 P = 1.0000000 z = 5 P = 0.1773523 z = 10 P = 0.0416605 z = 15 P = 0.0101008 z = 20 P = 0.0024804 z = 25 P = 0.0006132 z = 30 P = 0.0001522 z = 35 P = 0.0000379 z = 40 P = 0.0000095 z = 45 P = 0.0000024 z = 50 P = 0.0000006

Nous résolvons pour P inférieur à 0.1% ...

P> 0.001 q = 0.10 z = 5 q = 0.15 z = 8 q = 0.20 z = 11 q = 0.25 z = 15 q = 0.30 z = 24 q = 0.35 z = 41 q = 0.40 z = 89 q = 0.45 z = 340

Conclusions

Nous avons proposé un système de transactions électroniques qui ne dépendent pas de la confiance. Nous partons du cadre habituel des pièces de monnaie basées sur l'utilisation de signatures numériques, qui offre un contrôle fort de la propriété, mais qui est incomplet s'il n'y a aucun moyen d'éviter les doubles dépenses. Pour résoudre ce problème, nous proposons un réseau d'utilisateur à utilisateur qui utilise la preuve de travail pour enregistrer un historique des transactions publiques et qui devient rapidement insoluble par le calcul pour un attaquant qui veut le changer, si des nœuds honnêtes contrôlent la majeure partie de la puissance du processeur.

Un réseau robuste grâce à sa simplicité non structurée. Les nœuds peuvent tous fonctionner en même temps avec peu de coordination. Ils n'ont pas besoin d'être identifiés, car les messages ne sont pas acheminés vers un emplacement particulier et doivent seulement être livrés au mieux. Les nœuds peuvent aller et revenir du réseau à volonté, en acceptant la chaîne de preuve de travail comme preuve de ce qui s'est passé pendant leur absence. Ils votent avec la puissance de leur processeur, exprimant leur acceptation des blocs valides en travaillant en étendant et en rejetant les blocs invalides en refusant de travailler dessus. Toutes les règles ou incitations nécessaires peuvent être appliquées avec ce mécanisme de consensus.

références

  • [1] W. Dai, «b-money», https://www.weidai.com/bmoney.txt 1998.
  • [2] H. Massias, XS Avila et J.-J. Quisquater, «Conception d'un service d'horodatage sécurisé avec des exigences de confiance minimales», dans le 20e Symposium sur la théorie de l'information au Benelux, mai 1999.
  • [3] S. Haber, WS Stornetta, «Comment horodater un document numérique», dans Journal of Cryptology, vol 3, no 2, pages 99-111, 1991.
  • [4] D. Bayer, S. Haber, WS Stornetta, «Améliorer l'efficacité et la fiabilité de l'horodatage numérique», dans Séquences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993.
  • [5] S. Haber, WS Stornetta, «Noms sécurisés pour les chaînes de bits», dans Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, avril 1997.
  • [6] A. Back, "Hashcash - a déni de service contre-mesure," https://www.hashcash.org/papers/hashcash.pdf 2002.
  • [7] RC Merkle, "Protocoles pour les cryptosystèmes à clé publique", In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, avril 1980.
  • [8] W. Feller, "Une introduction à la théorie des probabilités et ses applications", 1957.