Cette introduction à un sujet complexe m'a été suggérée par Frédéric Tabbal, étudiant au Diplôme de 2e cycle en génie logiciel (DGL) de l'Université de Sherbrooke à la session Automne 2022...
Pour présenter l'idée de Blockchain, quoi de mieux que de commencer par l'abstract du texte original sur le sujet par Satoshi Nakamoto, quand il a proposé le Bitcoin, une monnaie électronique décentralisée qui reposait sur le concept de Blockchain :
« A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. » (source, la mise en évidence est de moi)
Le problème que Nakamoto cherchait à résoudre était celui de produire une monnaie permettant de réaliser des transactions fiables sans devoir passer par la médiation d'un tiers de confiance spécialisé, comme une banque à titre d'exemple.
Pour y arriver, il définit une pièce de monnaie (coin) électronique comme un enchaînement de signatures numériques. Ces signatures reposent sur un chiffrement à partir de paires de clés (publique pour chiffrer, privée pour déchiffrer, à la manière de RSA par exemple).
Une illustration claire de cet enchaînement est visible à la section 2 de https://nakamotoinstitute.org/bitcoin/
Un transfert de monnaie se fait en signant numériquement un hash de la transaction précédente et la clé publique du propriétaire suivant puis en ajoutant ce hash à la fin de la pièce de monnaie. Le récepteur de la transaction peut vérifier les signatures pour s'assurer que l'émetteur détenait bien la monnaie (et vérifier, en pratique, la totalité de la chaîne de propriété sur la monnaie, donc le chemin ayant mené cette pièce jusqu'à sa destination actuelle).
Si on se limite à cela, nous avons un problème : un émetteur de monnaie pourrait dépenser une même pièce plus d'une fois, à l'insu du destinataire. C'est pour cette raison que les solutions traditionnelles reposaient sur une autorité de confiance (une banque), d'ailleurs : seules les pièces de monnaie émises par ce tiers sont considérées dignes de confiance. Pour Nakamoto, cette confiance presque aveugle envers un tiers est un problème, et c'est pourquoi il propose une alternative :
« To accomplish this without a trusted party, transactions must be publicly announced, and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received » (source, la mise en évidence est de moi)
La solution de Nakamoto passe par un serveur d'estampilles (Timestamp Server); ces serveurs offrent un service qui accepte le hash d'un bloc, lui appose une estampille (un Timestamp) puis publie massivement le hash estampillé pour que le moment de publication soit largement connu. Cette publication est une preuve d'existence à un moment précis dans le temps. Puisque chaque estampille inclut les hash et les estampilles de chaque transaction précédente, les blocs se renforcent et se complexifient à chaque transaction en formant un enchaînement, ce que Nakamoto nomme une preuve d'effort (Proof-of-Work) :
« The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added. » (source, la mise en évidence est de moi)
La technique requiert donc un réseau de noeuds opérant sur des blocs. Les étapes sont :
Manifestement, plus la chaîne croît et plus le processus de validation est dispendieux.
Quand un noeud reçoit plusieurs chaînes de blocs, il considère par défaut la plus longue comme étant la meilleure et travaille à la faire croître. Ce choix tient au fait que la même chaîne peut parvenir de plusieurs sources qui ont travaillé sur les mêmes blocs, et que la plus longue est (si elle n'a pas été trafiquée) la plus récente. Le fait que chaque transaction soit diffusée et soit intégrée à des blocs par plusieurs noeuds fait qu'une transaction n'a pas à atteindre tous les noeuds (ce qui rend le protocole tolérant aux erreurs) : dans la mesure où elle atteint plusieurs noeuds du réseau, elle finira statistiquement par être intégrée à un bloc.
L'enjeu suivant est celui de la motivation. Une première transaction dans un nouveau bloc a un statut particulier et appartient à son émetteur. Ceci sert à titre de motivation pour générer de la monnaie (ça paie!), mais au lieu de payer en or, les émetteurs de nouvelle monnaie paient en électricité et en temps de calcul. Nakamoto explique comment le système peut éviter l'inflation en générant des « frais » de transaction en fonction du nombre de pièces de monnaie en circulation, et montre comment un tiers hostile amassant une masse trop importante de noeuds de calcul (pour essayer de débalancer le système et de s'enrichir) se trouverait à devoir choisir entre rembourser les tiers qu'il essaie de flouer... et générer de nouvelles pièces de monnaie.
Le texte séminal de Nakamoto couvre ensuite divers enjeux techniques :
Si vous souhaitez vous mettre au développement de transactions basées sur des Blockchains, une API pour y arriver est offerte sur https://www.blockchain.com/explorer/api (la page d'accueil de ce site, https://www.blockchain.com/explorer est aussi intéressante)
Un petit outil pour visualiser les Blockchains au quotidien : http://dailyblockchain.github.io/
Quelques liens pour enrichir le propos.
