Tout a commencé avec le livre blanc Bitcoin, un document explicatif sur le concept d'une technologie qui, aujourd'hui, ne fait aucun doute. Bitcoin et sa technologie sous-jacente, blockchain, est devenu l'une des plus grandes révolutions technologiques de ces derniers temps. Ce concept permet de créer des applications au potentiel incroyable, car 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 définit théoriquement une Moyen 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 le "Bitcoin Paper", et vous pouvez le vérifier ici.
Ensuite, nous vous laissons 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 directement des paiements en ligne, d'une entité à une autre. Tout cela, sans avoir à passer par une institution financière. Les signatures numériques apportent une partie de la solution au problème, mais les principaux avantages sont perdus si un tiers de confiance doit exister pour empêcher la 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 des calculs de hachage. De cette façon, un enregistrement est en cours de formation et ne peut pas être modifié sans recréer la preuve de travail complète. La chaîne la plus longue sert non seulement de jeton et de preuve de la séquence d'événements, mais garantit également qu'elle 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 auront un avantage sur les attaquants. Le réseau lui-même nécessite une structure minimale. Les messages sont envoyés sur la base du moindre effort, et les nœuds peuvent quitter et rejoindre le réseau quand bon leur semble. Toujours accepter 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 en est venu à s'appuyer exclusivement sur les institutions financières, qui agissent en tant que tiers de confiance, pour le traitement des paiements électroniques. Bien que le système fonctionne assez bien pour la plupart des transactions, il souffre toujours des faiblesses inhérentes au modèle basé sur la confiance. Les transactions totalement irréversibles ne sont pas vraiment possibles, car les institutions financières ne peuvent éviter la médiation en cas de litige.
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, le coût de cette perte étant plus élevé et l'impossibilité d'effectuer des paiements non réversibles pour des services non réversibles. Avec la possibilité d'inversion, le besoin de confiance augmente. Les commerçants doivent prendre soin de leurs clients, les harceler pour obtenir 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 permettant d'effectuer des paiements via un canal de communication sans 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. Ceci est destiné à permettre aux deux parties intéressées d'effectuer directement des transactions sans avoir besoin d'un tiers de confiance. Les transactions impossibles à annuler sur le plan informatique protégeraient les vendeurs contre la fraude. De même, des mécanismes de séquestre de routine pourraient facilement être mis en place pour protéger les acheteurs.
Dans ce travail, 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é.
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 nous soucierons donc pas d'autres tentatives de double dépense. La seule façon de confirmer l'absence d'une transaction est d'être au courant de toutes les transactions existantes. Dans le modèle de la Monnaie, c'était la Monnaie qui était au courant de toutes les transactions et qui décidait lesquelles venaient en premier. Pour y parvenir sans tiers de confiance, les transactions doivent être annoncées publiquement [1], et nous aurons besoin d'un système de participants s'accordant sur une seule histoire, de 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 celui qui a été reçu en premier.
Serveur d'horodatage
La solution que nous proposons commence par un serveur d'horodatage. Un serveur d'horodatage fonctionne en hacher un bloc de données à dater et le publier 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é à ce moment-là pour être incluses dans les données. hachage. Chaque horodatage inclut l'horodatage précédent dans son hachage, formant une chaîne, de sorte que chaque horodatage supplémentaire renforce les précédents.
Test de travail
Pour implémenter un serveur d'horodatage utilisateur à utilisateur, nous devrons utiliser un système de preuve de travail similaire à Hashcash par Adam Back [6], plutôt que d'utiliser un journal ou une publication Usenet. La preuve de travail implique la recherche d'une valeur, telle que, lors du calcul d'un hachage, tel que SHA-256, il commence par un certain nombre de bits de valeur zéro. Le travail moyen requis sera exponentiel au nombre de bits requis avec une valeur nulle mais qui 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.
La test de travail cela 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 trafiquée par quelqu'un capable d'attribuer plusieurs IP. La preuve de travail est essentiellement « un processeur, 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 grand effort investi.
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:
- De nouvelles transactions sont émises vers tous les nœuds.
- Chaque nœud collecte les nouvelles transactions en un seul bloc.
- Chaque nœud travaille pour trouver une preuve de travail difficile pour son bloc.
- Lorsqu'un nœud trouve une preuve de travail, il émet le bloc à tous les nœuds.
- Le bloc est accepté par les nœuds si toutes les transactions du bloc ont été validées et non dépensées.
- 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 branche qu'ils reçoivent mais conservent l'autre branche au cas où elle s'allongerait. L'égalité est rompue lorsque la prochaine preuve de travail est trouvée et qu'une branche s'allonge ; les nœuds qui travaillaient sur l'autre branche sont ensuite basculés vers celui qui est maintenant plus long.
Les émissions de nouvelles transactions n'ont pas besoin d'atteindre tous les nœuds. Au moment où ils atteindront 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 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 un frais de transaction qui sera ajouté à la valeur incitative du bloc qui le contient. Une fois qu'un nombre prédéterminé de pièces est entré en circulation, l'incitation peut évoluer entièrement en 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.
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. Avec des ordinateurs généralement livrés avec 2 Go de RAM en 2008 et la loi de Moore prédisant 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 de conserver qu'une copie des en-têtes de bloc de la chaîne la plus longue de la preuve de travail, qui peut être obtenue en recherchant les nœuds du réseau jusqu'à ce qu'il soit convaincu qu'ils ont la chaîne la plus longue, et en obtenant la branche de l'arbre de Merkle. qui relie la transaction au bloc dans lequel elle a été datée. Bien que vous ne puissiez pas vérifier la transaction vous-même, en la liant quelque part dans la chaîne, vous pouvez voir qu'elle a été acceptée par un nœud du réseau, donc les blocs ajoutés par la suite confirmeraient davantage cette acceptation par le réseau.
Ainsi, la vérification est fiable tant que des nœuds honnêtes contrôlent le réseau, mais elle devient plus vulnérable si le réseau est pris en charge par un attaquant. Alors que les nœuds du 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 l'intégralité du bloc 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. .
Il faut tenir compte du fait que ce système est déployé, de sorte que une transaction peut dépendre de plusieurs transactions, et ceux-ci peuvent à leur tour dépendre de bien d'autres, 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é d'annoncer publiquement toutes les transactions exclut cette méthode, mais la confidentialité peut toujours être maintenue en interrompant le flux d'informations ailleurs : garder les clés publiques anonymes. Publiquement, on peut voir que quelqu'un envoie un certain montant à une autre personne, mais sans information qui relie la transaction à une personne en particulier. Ceci est similaire au niveau d'information affiché sur les bourses, où l'heure et la taille des transactions individuelles, la "bande", sont publiques, mais sans dire qui sont les parties.
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'associations avec des transactions multi-billets sont inévitables, ce qui peut révéler que leurs billets appartiennent au même propriétaire. Le risque serait que si le propriétaire d'une clé est révélé, alors l'éditeur de liens pourrait révéler d'autres transactions qui lui appartenaient.
Cálculos
Nous considérons le scénario où un attaquant essaie de générer une chaîne alternative plus rapidement que la chaîne honnête. Même si cela était accompli, cela n'ouvrirait pas le système à des changements arbitraires, tels que créer de la valeur à partir de rien ou prendre de l'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'accepteront jamais un bloc les contenant. Un attaquant peut essayer de modifier uniquement ses propres transactions pour récupérer 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.
Étant donné notre hypothèse que p > q, la probabilité chute 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.
Considérons maintenant combien de temps le destinataire d'une nouvelle transaction doit attendre avant d'être suffisamment certain que l'émetteur ne peut pas la modifier. 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 basculer la transaction pour se rembourser, après un certain temps. Le bénéficiaire sera alerté lorsque cela se produira, mais l'expéditeur 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 destinataire attend que la transaction soit ajoutée à un bloc et que z blocs aient été liés après la transaction. Vous n'aurez pas besoin de connaître le montant exact des progrès réalisés par l'attaquant, mais en supposant que les blocs honnêtes ont pris la moyenne attendue par bloc, les progrès potentiels de l'attaquant seront un Loi 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épend pas de la confiance. Nous commençons par le cadre habituel des pièces fabriquées sur la base de 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 public des transactions et qui devient rapidement insoluble par calcul pour un attaquant qui veut le changer, si des nœuds honnêtes contrôlent la majeure partie du CPU. pouvoir.
Un réseau robuste pour sa simplicité dé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 endroit particulier et ne doivent être livrés qu'au mieux. Les nœuds peuvent aller et venir du réseau à volonté, acceptant la chaîne de preuve de travail comme preuve de ce qui s'est passé pendant leur absence. Ils votent avec leur puissance CPU, 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.