00:00 Introduction
02:01 Résoudre le consensus byzantin
09:35 Les exigences strictes d’une blockchain libre
20:31 L’histoire jusqu’à présent
22:44 S’enrichir rapidement aujourd’hui
24:03 Mini Bitcoin 1/3 - Hachage et signature
29:23 Mini Bitcoin 2/3 - Transactions
34:44 Mini Bitcoin 3/3 - Blocs et preuve de travail
44:47 Mise à l’échelle de la blockchain 1/2 - Paysage applicatif
49:07 Mise à l’échelle de la blockchain 2/2 - Blocs plus grands
57:11 Accélérer la blockchain 1/2
59:30 Accélérer la blockchain 2/2
01:06:54 Donner du pouvoir à la blockchain
01:14:51 Cas d’utilisation : paiements
01:19:25 Cas d’utilisation : traçabilité passive
01:25:33 Cas d’utilisation : traçabilité active
01:32:47 Cas d’utilisation : recyclage incitatif
01:35:40 Cas d’utilisation : sécurité incitative
01:41:30 Cas d’utilisation : assouplissement des exigences
01:44:53 Conclusion
01:49:35 4.21 Blockchains for supply chain - Questions?
Description
Les cryptomonnaies ont attiré beaucoup d’attention. Des fortunes ont été réalisées. Des fortunes ont été perdues. Les systèmes pyramidaux étaient omniprésents. D’un point de vue d’entreprise, la “blockchain” est le euphémisme poli utilisé pour introduire des idées et des technologies similaires tout en établissant une distanciation par rapport à ces cryptomonnaies. Des cas d’utilisation supply chain existent pour la blockchain, mais les défis abondent également.
Transcription complète
Bienvenue dans cette série de conférences supply chain. Je suis Joannes Vermorel, et aujourd’hui je vais présenter “Blockchains for Supply Chain.” Les cryptomonnaies ont capturé l’imagination du public, des fortunes ont été réalisées et perdues, certains méchants ont été arrêtés et emprisonnés, et d’autres suivront. Au milieu de toute cette agitation, le terme cryptomonnaie est devenu un peu trop chargé pour les grandes entreprises moyennes qui tendent à être assez conservatrices. Ainsi, le terme blockchain a été adopté comme moyen de distancier l’innovation de toute la folie qui sévit dans le monde de la crypto. Cependant, fondamentalement, blockchains et cryptomonnaies sont une seule et même chose.
L’objectif de cette conférence est d’acquérir une compréhension technique, une compréhension technique approfondie, de ce qui se passe avec les blockchains. Si vous possédez quelques compétences en programmation, à la fin de cette conférence, vous devriez être capable de réimplémenter votre propre blockchain ludique si vous le souhaitez. En nous appuyant sur cette nouvelle compréhension technique de la blockchain, nous commencerons à passer en revue les cas d’utilisation supply chain et à évaluer leur viabilité en tant que technologies pour résoudre des problèmes ainsi que leur valeur ajoutée pour les supply chains. Allons-y.
L’origine de Bitcoin est tout simplement étrange. En 2008, sous un pseudonyme, Satoshi Nakamoto, qui est probablement le fruit d’un travail d’équipe, un livre blanc intitulé “Bitcoin: A Peer-to-Peer Electronic Cash System” fut publié. Ce document présente un système et une approche pour un nouveau type de monnaie électronique. C’est un document relativement court avec quelques parties mathématiques, et même ces parties mathématiques sont en partie incorrectes.
Le document original stipule que le système est censé être sécurisé si au moins la moitié de la puissance de hachage est du bon côté. Cependant, il a été démontré plus tard dans un article publié en 2013, “Majority is Not Enough: Bitcoin Mining is Vulnerable”, que pour maintenir la sécurité du réseau, il ne suffit pas que la moitié de la puissance de hachage soit honnête ; il faut en réalité que plus des deux-tiers de la puissance de hachage soit honnête.
Néanmoins, il existe un livre blanc et un logiciel. Le logiciel est open source, et c’est une implémentation de très faible qualité. Le client Satoshi est de très mauvaise qualité, et durant la première année qui a suivi la publication du logiciel, des contributeurs open source ont rapidement corrigé une multitude de bugs et de problèmes. Certains de ces problèmes étaient difficiles à résoudre en raison du design original et ont eu un effet durable sur toute la communauté. De nombreuses cryptomonnaies existant aujourd’hui sont des forks du client Satoshi original et, dans une certaine mesure, portent encore de nombreux problèmes qui n’ont pas pu être corrigés au fil des années.
Ainsi, il s’agit d’une situation très déconcertante où l’on dispose d’un document de qualité médiocre et d’un logiciel dont la qualité est sans doute très faible, et pourtant l’équipe de Satoshi Nakamoto a réalisé une découverte stupéfiante. Fondamentalement, le problème était connu sous le nom de problème du consensus byzantin. C’est un problème d’informatique distribuée. Imaginez que vous ayez des participants, et que tous ces participants puissent voir ce qui est censé être l’état du système, qui dans le monde numérique peut être considéré comme une longue série de zéros et de uns, une charge utile de données. Les participants peuvent mettre à jour l’état du système, modifier quelques bits, ajouter un bit, supprimer un bit, et ils peuvent faire tout cela en même temps. Les participants peuvent communiquer entre eux, et le problème du consensus byzantin consiste à faire en sorte que tous les participants honnêtes se mettent d’accord, à un moment précis, sur ce qu’est l’état du système, jusqu’au dernier bit.
Le problème est très difficile si vous avez des participants byzantins qui agissent en tant qu’adversaires, essayant de semer la confusion parmi tous les autres participants. La découverte stupéfiante de Bitcoin est que, si nous remontons à 2008 et consultons des experts, ils auraient probablement dit qu’il ne semble pas possible de résoudre le problème du consensus byzantin de manière entièrement décentralisée sans autorité centrale. Cependant, la découverte de Satoshi Nakamoto, le consensus Nakamoto, est qu’ils ont trouvé un moyen de résoudre ce problème.
La solution est très surprenante. Cela ressemble à un problème algorithmique, mais l’essence de la solution derrière Bitcoin est que Satoshi Nakamoto a résolu ce problème en ajoutant des incitations monétaires, une incitation financière. Ce n’est pas seulement une solution algorithmique ; c’est littéralement un algorithme qui ne fonctionne que parce que, à l’intérieur du système, des incitations monétaires sont imbriquées, incitant ainsi les participants à agir d’une certaine manière.
Si nous voulons mettre en place ces incitations, nous avons besoin d’une sorte de monnaie électronique, afin de pouvoir concevoir ces incitations en premier lieu. C’est exactement ce qui est fait avec Bitcoin. Si vous souhaitez disposer d’une monnaie électronique, vous devez résoudre au moins deux problèmes très difficiles. Le premier problème est la double dépense. Si vous avez une certaine quantité d’argent numérique représentée par quelques bits d’information, qu’est-ce qui vous empêche de faire une copie de cet argent numérique et de dépenser l’argent une première fois pour payer quelque chose, puis de dépenser à nouveau le même argent avec votre copie pour payer autre chose ? Ce problème est connu sous le nom de double dépense, et c’est un problème très difficile auquel Bitcoin s’attaque.
Le deuxième problème est l’émission de pièces. D’où provient cet argent ? L’élément intéressant est que, généralement, lorsqu’on est confronté à un problème très difficile, on adopte une approche “diviser pour mieux régner”, en subdivisant votre grand problème en sous-problèmes plus simples qui peuvent être résolus séparément. Ensuite, le problème total peut être résolu. Ce qui est intéressant avec Bitcoin, c’est qu’il y a deux problèmes distincts et très difficiles : la double dépense et l’émission de pièces. Au lieu d’utiliser une approche de division, Bitcoin emploie une approche d’unification et d’enchevêtrement, qui était novatrice à l’époque, pour résoudre les deux problèmes simultanément. La solution, comme nous le verrons plus loin dans cette conférence, est étonnamment simple.
Cette conférence ne traite pas principalement de ce qui fait qu’une monnaie numérique est une bonne monnaie, car cela mériterait une conférence à part entière. Néanmoins, les blockchains ne fonctionnent pas sans les incitations financières conçues via les monnaies numériques qui soutiennent elles-mêmes la blockchain. Lorsque nous affirmons que la cryptomonnaie et les blockchains sont très similaires, l’idée est que si vous souhaitez avoir une blockchain, vous diffuserez des messages, et ces messages seront des transactions impliquant un flux d’argent. La perspective cryptomonnaie se concentre principalement sur l’aspect monétaire, tandis que la perspective blockchain s’intéresse davantage aux métadonnées qui se superposent aux transactions.
Rappelez-vous que l’ensemble du modèle de sécurité de ces systèmes blockchain/cryptomonnaie repose sur les incitations économiques conçues au sein du système. Vous ne pouvez pas complètement séparer les objectifs économiques et ceux de la cryptomonnaie de la blockchain. C’est simplement une question de perspective.
Maintenant, jetons un coup d’œil rapide aux exigences associées à un système blockchain/cryptomonnaie, et à la manière dont nous pouvons éventuellement assouplir ces exigences. La première est la non-négation. La non-négation signifie qu’en tant que participant, personne ne peut vous empêcher de diffuser une transaction. Personne ne peut empêcher la réalisation d’une transaction valide. Ceci est très important, car s’il existe un participant capable de le faire, alors, en essence, vous avez une autorité centrale. Inversement, aucun participant ne peut empêcher la réalisation d’une transaction valide, et il n’existe également aucun participant pouvant vous refuser la possibilité de réaliser une transaction parce qu’il pourrait consommer votre propre coin ou faire aboutir une transaction invalide. C’est la première exigence.
La deuxième exigence est l’anonymat. Techniquement, Bitcoin est un réseau pseudo-anonyme, mais fondamentalement, lorsque je parle de l’exigence d’anonymat, cela signifie qu’il n’existe pas de liste des participants. Dans une véritable blockchain, les participants peuvent apparaître ou quitter le système à tout moment, sans intermédiaire. Comme les participants peuvent rejoindre ou quitter librement, personne ne suit leur identité. Cela ne veut pas dire que le système doit être anonyme ; cela signifie simplement que si vous possédez une blockchain canonique véritable, l’exigence d’anonymat, où les participants peuvent rejoindre et partir à leur guise, doit être respectée.
Ensuite, je mentionne la scalabilité massive comme exigence, qui est particulièrement difficile pour les blockchains car, comme nous le verrons, ce type de systèmes distribués n’est pas intrinsèquement facile à mettre à l’échelle. Au contraire, faire évoluer une blockchain est remarquablement difficile. Fondamentalement, il existe un conflit : si vous laissez n’importe quel participant diffuser un nombre arbitrairement grand de messages, de transactions ou de mises à jour du système, un participant peut inonder l’ensemble du réseau et, en essence, le saturer de spams. Ainsi, toutes les blockchains doivent faire face à ce problème de scalabilité, qui est résolu par la mise en place d’incitations financières.
L’idée est de maintenir le coût d’une transaction, qui est le message élémentaire diffusé sur la blockchain, à environ un dixième de centime. C’est très bon marché – imaginez que vous deviez payer un dixième de centime pour envoyer un e-mail. Ce n’est pas gratuit, mais c’est toujours très peu coûteux. Ainsi, si vous avez une utilisation régulière et que vous souhaitez avoir une transaction associée, par exemple, au mouvement d’un produit dans un entrepôt, c’est acceptable ; le coût reste très faible. Cependant, en fixant le coût à 0,1 centime, vous rendez ces transactions trop chères pour un attaquant qui souhaiterait inonder le réseau de milliards de transactions, ce qui est très facile à faire en l’absence de frais. Chaque transaction doit payer un frais pour son existence et pour soutenir sa diffusion ; sinon, un attaquant pourrait saturer le système distribué sans obstacles.
Ainsi, les frais de transaction constituent un autre aspect de l’ingénierie économique pour rendre la blockchain viable. Vous voulez pouvoir maintenir ces frais de 0,1 centime à toute échelle, car un autre problème lié au refus de la scalabilité massive est que si nous avons des millions de transactions, le coût des transactions va s’envoler. C’est un gros problème que nous ne voulons pas. Nous ne voulons pas nous retrouver dans une situation où un bus de 100 personnes souhaitant voyager à un moment donné ne dispose que de 50 places. Dans ce cas, un mécanisme d’enchères se mettrait en place, et le prix des billets augmenterait vertigineusement. En termes de blockchain, cela signifie que le coût des transactions explosera. Soit dit en passant, ce type de problème se produit actuellement avec plusieurs blockchains. Par exemple, sur le réseau Bitcoin Core, il est très fréquent que le coût d’une transaction dépasse dix dollars, et c’est un très gros problème.
Maintenant, nous souhaitons également disposer d’une latence assez faible. Ce que Satoshi Nakamoto a découvert en 2008, le consensus Nakamoto, fonctionne très bien, mais fondamentalement, c’est un processus très lent. Quand je dis très lent, cela signifie que pour que les participants convergent vers l’état du système, il faut environ une heure. Ce n’est pas dramatiquement lent, mais ce n’est pas très rapide non plus. Si nous voulons réaliser quelque chose en rapport avec supply chain, où nous souhaitons effectuer des paiements ou tracer le mouvement des marchandises, il serait bien plus agréable de pouvoir maintenir la latence du système à environ trois secondes ou moins – le même type de latence que l’on pourrait attendre d’un paiement par carte de crédit rapide.
Enfin, l’un des derniers prérequis est l’infrastructure. Quand je dis l’infrastructure logicielle qui soutient la blockchain ou la cryptomonnaie, cela doit être un bien public financé par une sorte de contrat social convenu. C’est quelque chose que je crois que Satoshi Nakamoto n’avait pas prévu en 2008. Si vous voulez exploiter un système mondial distribué très complexe, il y a une tonne d’infrastructure logicielle à mettre en place et à maintenir. Le problème, c’est que si vous n’avez pas une manière socialement acceptée de financer tous ces efforts, des adversaires apparaissent, non seulement en tant qu’adversaires byzantins dans le réseau qui essaient de déstabiliser les autres participants quant à l’état du réseau, mais ils émergent aussi comme des adversaires qui prendront le contrôle du code lui-même et feront avec l’infrastructure logicielle des choses qui vont à l’encontre des intérêts de la communauté au sens large. Cela est arrivé dans l’histoire des cryptomonnaies, avec des prises de contrôle hostiles d’une équipe à l’autre, les nouvelles équipes ayant des intérêts complètement désalignés par rapport à ceux de la communauté au sens large. Il s’agit d’une catégorie d’attaques, davantage de nature social engineering, qui n’avaient pas été clairement envisagées par Satoshi Nakamoto en 2008. Cependant, après une décennie de fonctionnement, ces types d’attaques sont désormais bien plus évidents pour les observateurs du monde crypto.
À ce jour, l’histoire est la suivante : il s’agit d’une série de conférences sur la supply chain. Nous faisons partie du quatrième chapitre. Dans le premier chapitre, j’ai présenté mes vues sur la supply chain en tant que domaine d’étude et en tant que pratique, et nous avons vu que cela requiert des méthodologies très spécifiques. Le deuxième chapitre entier est dédié aux méthodologies de supply chain adaptées pour fonctionner dans cet espace. La plupart des méthodologies naïves ne survivent pas au contact avec la réalité, surtout lorsqu’il existe des conflits d’intérêts. D’ailleurs, de nombreux aspects du deuxième chapitre, où j’aborde les conflits d’intérêts, sont très pertinents pour la conférence d’aujourd’hui, donc j’invite le public, s’il n’a pas encore vu les conférences du deuxième chapitre, à y jeter un œil. Le troisième chapitre est consacré aux problèmes de supply chain, c’est-à-dire à des conférences où je me concentre exclusivement sur les problèmes de supply chain, et non sur les solutions. L’idée est de bien comprendre le problème avant de commencer à imaginer des solutions.
Le quatrième chapitre est essentiellement une collection de sciences auxiliaires. La blockchain est un sujet marginal que j’ajoute à la fin de ce chapitre, mais fondamentalement, les sciences auxiliaires sont des disciplines qui soutiennent véritablement les pratiques modernes de supply chain. De la même manière que l’on s’attend à ce qu’un médecin moderne ait quelques connaissances en chimie, il n’est pas nécessaire d’être un brillant chimiste pour être un brillant médecin. Le consensus général serait que, d’un point de vue moderne en science médicale, si l’on ne connaît rien en chimie, on ne peut pas être un bon médecin selon les standards actuels. Il en va de même pour la supply chain, selon moi. Il existe une série de sciences auxiliaires dans lesquelles il faut avoir quelques bases si l’on veut pratiquer une supply chain moderne de manière raisonnable.
Pour la conférence actuelle, je vais d’abord présenter Mini Bitcoin, qui est une implémentation de blockchain jouet. Cela devrait permettre de mieux comprendre comment fonctionnent les cryptomonnaies et quelle est la découverte clé réalisée par Satoshi Nakamoto en 2008. Cela devrait également clarifier les trois très grands défis auxquels nous sommes confrontés lors de la conception de blockchains, à savoir la scalabilité, la latence et l’expressivité. Ces trois défis ont un impact significatif sur le type de cas d’usage supply chain que nous pouvons envisager en nous basant sur la blockchain. Il est essentiel de comprendre les limitations inhérentes aux blockchains, car elles limitent essentiellement ce que nous pouvons faire en matière de supply chain et le type de valeur que nous pouvons créer. Enfin, dans une deuxième partie de la conférence, j’examinerai une série de cas d’usage supply chain où, dans une certaine mesure, la supply chain apporte véritablement sa pierre à l’édifice.
Le but de Mini Bitcoin est de construire une blockchain jouet, une version simplifiée de Bitcoin à partir de rien. Nous ne nous attarderons pas trop sur toutes les subtilités techniques impliquées car, en réalité, l’ingénierie d’une blockchain demande de prêter attention à une multitude de détails. Ici, je veux simplement exposer la structure globale de manière à la garder dramatiquement simplifiée par rapport à la réalité, afin que nous puissions comprendre en quelques diapositives ce qui se passe, comment cela est conçu et comment cela fonctionne.
Dans cet exemple très simple, nous allons concevoir une monnaie où chaque pièce vaut exactement un bitcoin. Vous disposez d’un ensemble de pièces, chaque pièce ayant exactement la valeur d’un bitcoin, et la seule opération possible est essentiellement de transférer une pièce d’un participant à un autre. Si un participant possède plusieurs pièces, il peut en transférer la totalité, mais nous nous limitons ici à une monnaie très simple où il n’existe pas de quantités fractionnaires ni d’autres éléments.
Pour construire ce Mini Bitcoin, nous n’avons besoin que de trois fonctions spéciales : une fonction de hachage, une fonction de signature et une fonction de vérification. Ces fonctions étaient déjà standard en 2008, ainsi, lorsque Bitcoin a été inventé, tous les outils cryptographiques de base étaient déjà en place. Satoshi Nakamoto n’a inventé aucun de ces outils. Ces fonctions cryptographiques particulières, également appelées fonctions à trappe, étaient bien connues, standards et largement utilisées en 2008. L’innovation clé de Satoshi Nakamoto a été d’utiliser ces fonctions de manière tout à fait particulière, comme nous le verrons.
Nous avons ces trois fonctions : la fonction de hachage, dont je ne vais pas entrer dans les détails ici, mais que j’ai abordée dans une conférence précédente. Il s’agit d’une version cryptographique de la fonction de hachage, capable de prendre n’importe quel message, une série de bits de longueur arbitraire, et de créer un condensé de 256 bits. La fonction ne peut, en pratique, être inversée. Si vous possédez un condensé, la seule manière d’identifier un message qui produit ce condensé est de connaître le message au préalable.
La fonction de signature peut prendre un message, une clé privée et produire une signature, qui est elle aussi de 256 bits. La fonction de signature fonctionne de pair avec une fonction de vérification. Pour ceux qui ne seraient pas familiers avec la cryptographie asymétrique, l’idée est de disposer d’un mécanisme vous permettant d’avoir des paires de clés publiques et privées. Avec la clé privée, vous pouvez produire une signature et publier un message sans divulguer votre clé privée. Tout participant peut utiliser la fonction de vérification pour prendre le message, votre signature et votre clé publique afin de vérifier que le message a bien été signé par la clé privée associée à cette clé publique.
Ces fonctions à trappe ne peuvent pas être inversées, donc si vous ne connaissez pas le message original, vous ne pouvez pas revenir en arrière, du condensé au message d’origine. La même logique s’applique si vous ne possédez pas la clé privée ; vous ne pouvez pas produire une signature par vous-même pour un nouveau message.
Ces trois fonctions spéciales sont disponibles dans pratiquement tous les environnements de programmation modernes, que ce soit en C++, Python, Java, C# ou autres. Elles font partie intégrante de l’environnement standard pour accéder à ces classes de fonctions cryptographiques.
Maintenant, examinons une situation où je suis censé être le propriétaire de la pièce numéro un. Qu’est-ce que cela signifie ? Cela signifie que, dans le cadre de ce consensus byzantin, un accord partagé existe entre tous les participants de ce réseau Mini Bitcoin, selon lequel, dans le cadre des UTXO (Unspent Transaction Outputs), cette pièce est effectivement présente. Quand je dis « cette pièce », je fais référence à un message qui inclut la clé publique numéro un et la signature zéro. Je pars du principe que cela fait partie d’un ensemble de pièces et que tous les participants conviennent que cette pièce existe réellement et est prête à être dépensée. Maintenant, en tant que propriétaire de cette pièce numéro un, comment puis-je réellement la dépenser pour transférer sa propriété à quelqu’un d’autre ?
La méthode consiste à produire une signature. La signature est construite de la manière suivante : j’utilise la fonction spéciale « sign » et je vais signer un message. Ce message sera simplement composé de la clé publique numéro un, de la signature zéro, puis de la clé publique numéro deux. La clé publique numéro deux correspond littéralement à l’adresse vers laquelle j’envoie l’argent. Celui qui détient la clé privée associée à cette clé publique numéro deux sera le destinataire de ma transaction. Ainsi, je signe cette transaction, et pour le faire, j’utilise la clé privée numéro un. Le seul participant capable de produire cette signature numéro un est la personne qui possède le secret, c’est-à-dire la clé privée numéro un associée à la clé publique numéro un.
Si je veux informer l’ensemble du réseau que cette transaction a été réalisée, je dois diffuser une transaction. La transaction sera simplement un message qui énumère la clé publique numéro un, la signature zéro, la clé publique numéro deux et la signature un que je viens de produire. C’est juste une liste des éléments constituant la transaction. Lorsque je publie cette transaction de un à deux, la pièce numéro un sort essentiellement du pool de pièces, et la pièce numéro deux entre dans le pool du système. C’est pourquoi il est crucial d’avoir ce consensus byzantin en place. Nous en avons besoin parce que, potentiellement, vous pourriez vouloir dépenser de l’argent que vous ne possédez pas et semer la confusion dans le réseau concernant la propriété de certaines pièces. Cependant, si vous réussissez à résoudre le problème du consensus byzantin, il y aura un accord ferme sur les pièces qui appartiennent réellement au système. Une fois qu’une pièce est dépensée, le propriétaire numéro deux détient désormais une pièce. Une pièce peut quitter le réseau, et une nouvelle pièce est créée et intégrée à l’état du système.
Le mécanisme peut être répété ; la pièce numéro deux peut être transférée vers la pièce numéro trois en utilisant le même procédé : produire une signature, diffuser une transaction, et ainsi de suite.
D’ailleurs, chaque fois que j’ai dit que la fonction « sign » était utilisée, cela implique implicitement que tous les observateurs peuvent utiliser la fonction « verify » pour vérifier que la signature est correcte. Fondamentalement, lorsque les participants vont examiner les transactions, la première chose qu’ils feront sera d’utiliser la fonction « verify » que j’ai présentée précédemment afin de vérifier que la transaction est réellement correcte. Deux vérifications sont effectuées : chaque participant doit s’assurer que la pièce transférée faisait déjà partie de l’état du système, garantissant ainsi qu’il s’agit d’une pièce valide, et que la transaction est conforme à la signature. Ce que je n’ai pas abordé ici, c’est le problème de la double dépense. Comment empêcher que deux transactions conflictuelles ne soient effectuées simultanément, et comment éviter que le réseau ne soit dérouté si un adversaire tente de diffuser deux transactions conflictuelles en même temps, envoyant le même argent à deux participants distincts ?
Je n’ai pas non plus clarifié l’origine de ces pièces. Comment sont-elles intégrées dans le système dès le départ ? L’essence de la découverte de Satoshi Nakamoto et de son Consensus Nakamoto réside dans la résolution simultanée de ces deux problèmes.
La proposition de Satoshi Nakamoto est d’introduire une classe spéciale de participants dans le réseau, de nos jours surnommés « miners ».
Les miners écoutent essentiellement le réseau et collectent toutes les transactions qui ont été diffusées. Ils rassemblent ces transactions diffusées et les regroupent dans un conteneur appelé « block ». Un block est simplement une collection de transactions diffusées par n’importe qui dans le réseau peer-to-peer.
La toute première transaction d’un block sera une transaction spéciale appelée « coinbase ». Une coinbase est une transaction unique qui crée une nouvelle pièce dans ce Mini Bitcoin ex nihilo. La première transaction est donc la coinbase, qui crée une nouvelle pièce de nulle part, puis le block inclut la liste des transactions qui ont été diffusées, telles que perçues par le miner. Le miner ne pourra peut-être pas capturer toutes les transactions du réseau Bitcoin, mais il essaiera de le faire.
La coinbase est spéciale, et je vais expliquer comment la construire, car il s’agit d’une transaction unique. Tout d’abord, nous allons produire un hash du block, un hash partiel (H1a). Ce hash est essentiellement le résultat du hachage d’un message, et ce message commence par le hash du block précédent (H0b), concaténé avec toutes les transactions présentes dans le block.
La coinbase est ensuite un tuple qui comprend le hash H1a, suivi d’un nonce. Un nonce est un nombre choisi aléatoirement par le miner et revêt une importance particulière. La coinbase contient également la clé publique du miner. Elle inclut un hash de l’ensemble du contenu du block, un nombre aléatoire et la clé publique du miner. Cette clé publique sera utilisée ultérieurement par le miner pour réclamer la coinbase en tant que pièce ordinaire. Dans ce Mini Bitcoin, les pièces sont émises à raison d’un Bitcoin par block. En réalité, sur le réseau Bitcoin Core ou Bitcoin Cash, le processus est plus complexe, mais la plupart de cette complexité peut être simplifiée pour des raisons de clarté.
L’idée est que, pour qu’un block soit considéré comme valide, nous devons produire une coinbase. Cependant, si nous nous arrêtons ici, tous les miners pourraient revendiquer avoir un block à leur guise, et chaque miner aurait intérêt à dire : “Je peux produire un package, un condensé de toutes ces transactions. Je peux produire une coinbase. S’il vous plaît, donnez-moi ce Bitcoin supplémentaire.” Comment trier alors tous les miners en compétition pour que leur version du block soit sélectionnée par le réseau et considérée comme le véritable block ?
Satoshi Nakamoto a introduit le concept de proof of work. Le hash de la coinbase, qui est un grand nombre de 256 bits, doit être supérieur à un seuil de difficulté. Ce processus est comparable à la résolution d’une énigme, et la seule façon de résoudre cette énigme est de trouver une coinbase dont le hash satisfait cette cible de difficulté. Le miner peut essayer de nombreux nombres aléatoires pour le nonce en espérant être le premier à atteindre la difficulté et ainsi revendiquer le block pour lui-même.
Dans Bitcoin, la difficulté est adaptative, et le réseau utilise un algorithme de moyenne mobile améliore pour maintenir la difficulté autour de 10 minutes par block. Si les blocks sont découverts en moyenne plus rapidement que 10 minutes, la difficulté augmentera jusqu’à ce que les blocks soient trouvés en moyenne toutes les 10 minutes. Si les blocks commencent à être trouvés toutes les 11 minutes, la difficulté diminuera afin de maintenir le temps moyen de découverte d’un block à 10 minutes.
La proposition de Satoshi Nakamoto est que les mineurs suivent toujours la chaîne valide la plus longue. Une chaîne de blocs doit atteindre l’objectif de difficulté pour être valide. Lors de la construction d’un bloc, vous le construisez toujours au-dessus d’un bloc préexistant, à l’exception du bloc genèse, qui est le point de départ par défaut. La règle ne consiste pas seulement à avoir la chaîne la plus longue, mais la chaîne valide la plus longue. D’autres mineurs vérifieront que toutes les transactions inscrites dans un bloc sont effectivement valides, s’assurant que les signatures correspondent et que les pièces dépensées sont éligibles à être dépensées. Ils maintiennent cet état, et c’est exactement ainsi que Bitcoin peut résoudre à la fois le problème de la double dépense et celui de l’émission de pièces. Nous avons tout ce qu’il faut pour construire une blockchain.
En réalité, si vous souhaitez construire une blockchain de qualité production, il y a une multitude de choses supplémentaires à considérer. Tout d’abord, vous aimeriez disposer de quantités fractionnaires. Vous ne voulez probablement pas pouvoir détenir un seul Bitcoin à la fois ; vous souhaitez quelque chose qui vous permette de transférer plusieurs quantités, voire des quantités fractionnaires, de Bitcoins.
En ce qui concerne les pièces, vous souhaiteriez avoir des transactions pouvant consommer de nombreuses pièces en entrée simultanément pour ensuite en produire plusieurs à la fois. Il ne s’agira pas de transactions un-à-un reliant une pièce à une pièce ; ce sera des transactions plusieurs-à-plusieurs, avec de nombreuses pièces d’entrée reliées à de nombreuses pièces de sortie. D’ailleurs, c’est ainsi que fonctionnent actuellement divers réseaux Bitcoin.
Vous avez également les frais de transaction que j’ai mentionnés. Si vous permettez aux gens de diffuser des transactions sans fin, ils pourraient envoyer de l’argent d’une adresse à l’autre de façon répétée et inonder le marché. L’idée est qu’un frais représente fondamentalement la notion selon laquelle une certaine portion de la transaction est redirigée vers le mineur. La manière dont c’est généralement fait dans la plupart des variantes de Bitcoin consiste à dire que le total des entrées doit être, en termes de valeur monétaire, légèrement supérieur au total des sorties. La fraction de valeur manquante, l’écart, constitue la récompense versée au mineur.
Nous avons maintenant complété notre mini Bitcoin. Si vous savez programmer, vous disposez de tous les éléments nécessaires pour implémenter votre propre blockchain. D’ailleurs, vous pouvez également répéter des blocs, et c’est ce que je fais ici. Ce que vous venez de faire pour un bloc, vous pouvez répéter exactement les mêmes formules pour un autre bloc, avec une deuxième base de code. C’est exactement comme pour les transactions ; le même mécanisme se répète encore et encore.
La mise à l’échelle de la blockchain est très complexe. Dans un court livre blanc de 2018, j’ai publié un panorama applicatif de Bitcoin. L’idée est que, selon la quantité de données impliquées dans vos blockchains, le volume de données que vous devez traiter et transférer varie grandement en fonction de ce que vous faites avec la blockchain. Essentiellement, cela va d’environ 100 octets à transférer (l’ordre de grandeur d’une clé privée) jusqu’à 10 ordres de grandeur si vous devez gérer l’intégralité de la blockchain.
Il est difficile d’appréhender le fait que, selon ce que vous faites, la quantité de ressources informatiques que vous devrez injecter pour accomplir la tâche varie de 10 ordres de grandeur. Un ordre de grandeur signifie que vous multipliez la quantité de ressources par un facteur de 10, et lorsque vous en avez 10, vous pouvez passer de 1 à 10 milliards. Cela est stupéfiant et colossal. Dans ce panorama applicatif, vous verrez qu’il existe deux distinctions principales : les applications on-chain et off-chain. Les applications off-chain sont celles qui ne traitent que les données générées par vous ou vos partenaires proches. Si vous êtes une grande entreprise, vous pouvez avoir à gérer des millions de transactions, mais il ne s’agit que de vos propres transactions. En termes de données, cela peut être volumineux, mais c’est gérable puisque cela se rapporte directement à votre activité.
En revanche, les applications on-chain traitent de toutes les transactions diffusées sur le réseau. Cela peut être énormément plus important, surtout si vous êtes un petit acteur et que vous devez gérer toutes les transactions sur un grand réseau, ce qui peut représenter des millions de fois plus que les transactions qui vous concernent.
De plus, nous devons distinguer entre les composants dits “cash cogs” et “cash lands”. Les cash cogs sont des composants fondamentaux qui contribuent à la résolution du problème du consensus. Si vous les supprimez, la blockchain cesse de fonctionner car vous n’avez plus de consensus. Les cash lands, en revanche, sont des composants optionnels qui peuvent être construits au-dessus de l’infrastructure de la blockchain. Ils ne sont pas strictement nécessaires pour que la blockchain fonctionne.
Typiquement, lorsque nous pensons aux cas d’usage supply chain, nous nous positionnons du côté des métadonnées dans le domaine des cash lands. Ce que nous faisons n’est pas strictement requis pour que la blockchain continue à fonctionner ; elle peut continuer à opérer sans notre cas d’usage spécifique.
En ce qui concerne la mise à l’échelle de la blockchain pour de vrais cas d’usage supply chain, il faut considérer que la blockchain doit être capable de gérer des millions de transactions. Les grandes entreprises traitent des millions de transactions hebdomadaires, ce qui n’est pas exceptionnel dans le monde de la supply chain. Cependant, les blockchains sont peu scalables, comme en témoigne le fait que les mineurs doivent traiter toutes les transactions de chacun.
Pour remédier à ce problème, certaines innovations ont été introduites, telles que les solutions évoquées plus tôt dans la conférence. L’objectif principal est de rendre la technologie blockchain plus scalable et adaptée pour gérer le volume massif de transactions typiquement observé dans les applications supply chain. Si vous souhaitez qu’une blockchain soit utilisée pour des besoins supply chain, elle doit être capable de gérer non seulement les transactions d’une seule entreprise, mais aussi celles de toutes les entreprises participant à l’initiative blockchain. Cela peut devenir extrêmement grand, voire réellement très grand, peut-être excessivement grand. C’est ce que nous devons examiner, et ici, à la rescousse, il y a essentiellement eu deux articles notables. Lorsque Satoshi Nakamoto a publié son article, il disait qu’avec l’évolution du matériel, ce problème serait résolu, et nous scalerions autant que nécessaire. Cela devait arriver. Cependant, il s’est avéré que c’était difficile, et depuis plus d’une décennie maintenant, pratiquement tous les acteurs de l’univers de la blockchain et des cryptomonnaies peinent avec la scalabilité.
Le premier article notable est ECMH, Elliptic Curve Multiset Hash. C’est un article assez technique, mais l’idée principale est que vous n’avez pas besoin de conserver toutes les transactions ; il suffit de conserver les pièces prêtes à être dépensées. Cet ensemble de pièces pouvant être dépensées est techniquement connu dans l’écosystème Bitcoin sous le nom d’UTXO. À titre d’ordre de grandeur, l’UTXO du réseau Bitcoin Core est actuellement légèrement inférieur à cinq gigaoctets. C’est la taille du jeu de données UTXO, mais si vous regardez la blockchain de Bitcoin Core, la taille de celle-ci est légèrement inférieure à 350 gigaoctets, et la blockchain croît bien plus rapidement que l’UTXO.
Ce que l’article ECMH vous apporte, c’est une fonction de hachage qui a une affinité pour les multisets. Essentiellement, c’est une fonction de hachage qui vous permet de mettre à jour votre hachage si vous ajoutez ou retirez des éléments de votre collection. Vous ne préservez pas l’ensemble ou le multiset lui-même, mais vous conservez simplement le hachage, et vous pouvez ajouter ou supprimer des éléments. Cette propriété de type ensemble signifie que vous pouvez effectuer ces ajouts ou suppressions dans n’importe quel ordre et obtenir tout de même le même hachage. Ce que vous obtenez grâce à ECMH, c’est une sorte d’engagement UTXO, permettant à la communauté de s’affranchir de la blockchain complète. La majeure partie de la communauté n’a donc pas à traiter l’intégralité de la blockchain, mais seulement l’UTXO. Je le répète, la taille de l’UTXO du réseau Bitcoin Core est de cinq gigaoctets, et la taille de la blockchain est de 350 gigaoctets, ce qui représente essentiellement un gain de deux ordres de grandeur. C’est très significatif. Essentiellement, avec ECMH, vous gagnez deux ordres de grandeur en stockage de données persistantes, ce qui est un gain énorme.
Le second article est Graphene, un nouveau protocole de propagation de blocs utilisant la réconciliation d’ensembles. Graphene vous permet de gagner essentiellement deux ordres de grandeur sur les exigences de bande passante de pointe. Dans ce mini Bitcoin que je viens de décrire, vous avez des mineurs et des transactions diffusées en mode peer-to-peer en permanence sur le réseau. La bande passante est probablement le problème le mieux résolu de Bitcoin, mais néanmoins, il y a un problème de bande passante au moment où un bloc est trouvé. Le mineur, afin de revendiquer le bloc, doit propager le coinbase, où il indique : “Regardez, j’ai un coinbase qui atteint mon objectif de difficulté.” Ensuite, tous les autres mineurs doivent télécharger l’intégralité du bloc et, s’il est effectué de manière naïve, ils doivent valider que le bloc est effectivement valide, et pas seulement que le coinbase atteint l’objectif de difficulté.
Chaque fois qu’un bloc est trouvé, il y a une exigence de pic parce que vous souhaitez que le temps nécessaire à transférer un bloc entier, s’il est effectué naïvement, reste bien inférieur à l’intervalle de 10 minutes. Dans Bitcoin, l’énigme est réglée en termes de difficulté de sorte que le temps moyen entre deux blocs consécutifs est en moyenne de 10 minutes. Ainsi, vous voulez que le transfert du bloc ne prenne qu’une fraction de ce temps, disons moins de 30 secondes, si vous souhaitez que le réseau reste très stable. Cependant, cela signifie que le bloc doit être transféré en 30 secondes, ce qui limite votre bande passante de pointe. La vitesse à laquelle vous allez transférer votre bloc sera limitée par votre bande passante.
L’idée est qu’avec Graphene, une technique basée sur la compression, vous n’aurez pas besoin de transférer l’intégralité du bloc, car la majeure partie de son contenu correspond aux transactions qui ont déjà été diffusées sur le réseau. La seule chose que vous souhaitez diffuser est un ensemble de réconciliation, afin d’informer vos pairs (les autres mineurs) des transactions qui ont été incluses ou non dans votre bloc, de manière parfaitement fiable. Si vous procédez ainsi, vous pouvez à nouveau économiser deux ordres de grandeur sur la bande passante de pointe, ce qui est très significatif.
Ceci présente un grand intérêt, par exemple, Graphene fonctionnerait sur les réseaux Bitcoin Cash ou les réseaux plus récents eCash, en raison de particularités techniques complètes. Il ne fonctionnerait pas sur le réseau Bitcoin Core. Cela faisait partie des aspects qui n’avaient pas vraiment été anticipés par Satoshi Nakamoto.
La dernière exigence que j’ai mentionnée dans ma liste de critères est que la maintenance du logiciel signifie que vous devez disposer d’un contrat social en place, afin d’avoir des équipes capables d’assurer la maintenance et d’intégrer par la suite de nouvelles découvertes dans votre blockchain. Sinon, vous restez bloqué avec le genre de performance et de stabilité que vous aviez il y a une décennie ou à l’époque de la création de la blockchain.
Nous avons maintenant un autre problème : accélérer la blockchain. Le réseau Bitcoin classique affiche un temps moyen entre les blocs de 10 minutes, et si vous souhaitez avoir une véritable confiance dans l’état du consensus, vous devez attendre plusieurs blocs. En règle générale, on estime habituellement que, pour obtenir une confiance absolue, il faut attendre six confirmations, ce qui équivaut à un délai d’une heure. L’idée est que nous pourrions réduire ce temps entre les blocs. Cependant, le problème est que plus ce temps est court, plus les blocs doivent être réduits en taille, ce qui compromet la scalabilité. Des blocs peu fréquents permettent d’avoir des blocs très volumineux, ce qui est une bonne chose, car cela aide votre réseau à gérer la masse de transactions.
Compte tenu des délais observés sur le réseau mondial, cet objectif de 10 minutes n’est pas optimal, mais il se situe dans la fourchette de ce qui est efficace pour faire fonctionner ce type de consensus distribué avec des blocs très volumineux, pouvant atteindre jusqu’à un téraoctet. Cela semble très important, mais en réalité, si l’on considère l’usage à l’échelle de l’humanité, c’est ce qu’il faut. Vous devez espacer largement les blocs en termes de timing si vous souhaitez préserver votre scalabilité. Cependant, vous vous heurtez alors au problème d’un réseau lent. Une heure pour confirmer une transaction peut être acceptable dans le cadre d’un cas d’usage de le e-commerce, où il est tolérable de ne rien faire pendant 60 minutes après le paiement puisque la livraison n’aura de toute façon pas lieu avant le lendemain. Mais si vous attendez quelque chose qui se passe à l’intérieur d’un entrepôt ou au point de vente, ce délai est beaucoup trop long. C’est comme une carte de crédit pour laquelle il faudrait une heure pour que le paiement soit validé, ce qui est très lent.
Ce que nous souhaitons, c’est généralement un objectif d’environ trois secondes ou moins. Cela s’explique par le fait que, d’un point de vue de l’expérience utilisateur, quelque chose qui prend trois secondes à être validé sera perçu comme raisonnablement rapide. Pensez-y comme à un paiement par carte de crédit ; si vous comptez un-deux-trois lors d’un paiement, c’est acceptable, c’est suffisamment rapide. Si vous pouvez garantir une sécurité totale dans ce laps de temps, vous offrirez une expérience utilisateur très décente pour la plupart des cas d’usage. C’est encore trop lent pour une communication machine-à-machine à faible latence, mais cela suffit pour la plupart des situations impliquant la perception humaine.
Pendant près d’une décennie, de nombreuses solutions ont été proposées pour remédier à ce problème de latence. La grande majorité de ces solutions n’étaient pas très efficaces. Elles présentaient toutes diverses limitations qui compromettaient Bitcoin ou sa scalabilité, ou bien il s’agissait de solutions naïves apparues rapidement après la publication de Bitcoin. La plupart de ces solutions reposaient sur l’élection d’un leader, ce qui permettait à ce dernier d’agir comme une autorité centrale temporaire pendant une période donnée, offrant des services à faible latence. Cependant, le problème avec l’élection d’un leader est que, lorsque vous passez d’un leader à un autre, le processus peut devenir très chaotique, et vous vous retrouvez dans une situation où, en termes de qualité de service, la majorité du temps c’est quelques secondes, puis parfois en réalité ce sont une heure d’attente. Cela serait perçu par tous comme une interruption du réseau.
Il a fallu une décennie pour qu’une solution, qui était à mon avis suffisamment robuste, soit publiée. Cette solution est une brillante réalisation d’une équipe anonyme appelée Team Rocket, publiée en mai 2018 : Snowflake to Avalanche, une autre famille de protocoles de consensus métastables pour les cryptomonnaies. Cet article présente une série de trois algorithmes : Snowflake, Snowball et Avalanche. Chaque algorithme est construit sur le précédent et, d’ailleurs, la véritable magie réside dans l’algorithme Snowball, qui est précisément celui qui n’apparaît pas dans le titre de l’article.
Fondamentalement, ce qu’ils ont conçu, c’est la métastabilité, et c’est très intéressant. Rappelez-vous, lorsque vous avez des transactions conflictuelles, il n’importe vraiment pas laquelle est choisie car améliorer la latence consiste à prévenir la double dépense ou à réduire en réalité le délai pendant lequel il peut y avoir une ambiguïté concernant la double dépense. L’idée d’avoir quelque chose de méta-stable est que vous aimeriez disposer d’un protocole où les participants discutent constamment entre eux. Le but est que s’il y a deux transactions conflictuelles, le réseau atteindra un équilibre métastable. Le réseau convergera rapidement vers une interprétation de la vérité ; peu importe laquelle, il suffit qu’il y en ait une. Ainsi, s’il y a des objets conflictuels, le réseau discutera et résoudra le conflit.
Snowflake offre un processus de convergence lente, tandis que Snowball, dans cet article, propose une astuce permettant une accélération exponentielle, résultant en une convergence bien plus rapide. Avalanche apporte certaines propriétés de graphe liées au graphe des transactions. Cependant, ma compréhension personnelle est que la contribution d’Avalanche est bien plus faible ; c’est vraiment Snowball qui opère la magie. Vous pourriez vouloir implémenter Avalanche, mais seul Snowball vous donnera environ 99 % de la métastabilité recherchée.
Il y a un inconvénient à cette approche. Avec la preuve de travail et les blocs de Satoshi Nakamoto, tout observateur peut intervenir et constater ce qui s’est passé, reproduisant l’ensemble du processus et vérifiant tout. La sécurité ne dépend pas du fait que l’observateur soit en ligne. L’observateur peut être en ligne ou hors ligne, et cela n’a pas d’importance. C’est un excellent modèle de sécurité qui ne repose pas sur une connexion en direct au réseau.
Avalanche, en revanche, exige que l’observateur surveille constamment les discussions du réseau pour générer de la sécurité. Il n’est pas possible pour un observateur tardif de rejoindre et de réévaluer la sécurité des transactions passées. Cependant, ce problème ne nous importe pas vraiment, car si vous êtes en direct sur le réseau, vous évaluez la sécurité des transactions en cours à ce moment-là. Pour ce qui s’est passé dans le passé lorsque vous n’étiez pas présent, la preuve de travail et les blocs fournissent toujours un moyen de valider les transactions.
Avalanche n’est pas en opposition à Bitcoin ; il est complémentaire. L’un des aspects faibles de la solution passant de Snowflake à Avalanche est qu’elle ne fournit pas une solution nette au problème de l’émission de pièces. Pour obtenir le meilleur des deux mondes, il serait idéal de maintenir un design de type Bitcoin avec une preuve de travail et de grands blocs, tout en superposant cela à une sécurité à faible latence.
Pour éviter certaines classes d’attaques Sybil susceptibles de perturber Avalanche, la preuve d’enjeu pourrait être employée. Cela introduit des couches d’enchevêtrement économique, ce qui est une manière de penser très à la Bitcoin. Pour atteindre la sécurité désirée, un réseau d’enchevêtrements économiques devrait être créé afin de s’assurer que chacun reste honnête. Il existe des moyens de concevoir des solutions pour obtenir une meilleure latence.
Maintenant, toujours sur le sujet de l’expressivité, nous recherchons plus que de simples transactions financières, car il s’agit de supply chain et d’utiliser une blockchain à des fins de supply chain. Les transactions financières sont nécessaires en arrière-plan, mais nous voulons pouvoir faire plus. La question est : comment incorporer cette logique supplémentaire ?
Dans les cercles des cryptomonnaies, de nombreuses cryptomonnaies ont introduit la notion de smart contracts. Un smart contract est fondamentalement un programme exploité par les mineurs eux-mêmes sur la blockchain. Les mineurs vérifient la validité des transactions, mais si vous pouvez inclure un langage de programmation ou du code en assembleur dans le cadre de votre transaction, les mineurs pourraient exécuter les programmes et vérifier que ces programmes respectent certaines propriétés. C’est ce qui se fait typiquement sur Ethereum, et cela est appelé un smart contract. Il y a ce leitmotiv selon lequel “code is law”, signifiant que nous faisons confiance à l’exécution du programme parce qu’il est certifié comme correct par les mineurs eux-mêmes.
Cependant, je pense que cette approche est profondément erronée sur deux aspects très différents. Le premier problème est que vous aggravez considérablement le problème d’évolutivité. Mettre une blockchain à l’échelle est déjà très difficile, car il faut canaliser toutes ces transactions vers les mineurs. Les mineurs n’ont pas grand-chose à faire avec ces transactions ; ils doivent simplement vérifier la signature. Un mineur peut potentiellement traiter une quantité massive de transactions parce que le nombre de vérifications à effectuer pour chaque transaction est minimal. Maintenant, imaginez si un mineur devait non seulement valider les transactions, mais aussi exécuter des programmes arbitraires provenant de toutes les entreprises. Cela devient très difficile, et c’est exactement ce qui se passe depuis longtemps sur le réseau Ethereum et d’autres cryptomonnaies destinées aux contrats complexes.
Bien que des cryptomonnaies ultérieures comme Ethereum aient bénéficié d’une meilleure ingénierie, elles sont toujours confrontées à un problème d’évolutivité énormément plus difficile. Une fois qu’elles atteignent un certain niveau de notoriété et d’activité sur le réseau, elles font toutes face à d’énormes problèmes d’évolutivité. Tout se résume au fait qu’il faut exécuter tous ces programmes.
Le deuxième problème majeur avec les smart contracts est qu’ils sont fondamentalement des programmes immuables. Lorsque vous placez des programmes sur la blockchain, l’idée est que vous faites confiance à ces programmes parce qu’ils fonctionnent de manière autonome. Par “autonomes”, on entend qu’il y a des mineurs ayant des incitations financières à exécuter ces programmes pour la communauté, et que l’ensemble du processus est transparent et vérifiable. Cependant, le gros problème des programmes immuables est que s’il y a un bug, vous ne pouvez pas le corriger.
L’histoire des smart contracts a été une série interminable de failles entraînant des pertes massives pour ceux qui exploitaient les contrats. Même Ethereum lui-même a dû subir un fork massif, donnant naissance à Ethereum et Ethereum Classic, parce qu’un contrat défaillant était si important que les opérateurs ont décidé qu’il valait mieux revenir en arrière sur les problèmes et compromettre la propriété immuable que la blockchain est censée offrir. Il n’y a pas de solution de contournement, et si vous faites quelque chose de non trivial dans un smart contract, vous vous exposez à des failles.
En 2018, j’ai publié une autre approche appelée Tokida qui montre comment vous pouvez avoir des programmes arbitraires fonctionnant parallèlement à la blockchain. Avec Tokida, le programme est open-source et fonctionne sur un modèle “trust but verify”. Toutes les personnes intéressées par le résultat du contrat peuvent vérifier si elles le souhaitent, et en termes de performance, c’est plus flexible car le reste de la communauté n’a pas à exécuter votre programme. Si vous souhaitez patcher votre logiciel, vous pouvez toujours le faire à tout moment sans que le reste de la communauté ignore ce que vous avez fait.
S’il y a une faille, ce n’est pas un problème significatif car vous pouvez la corriger, et la communauté peut constater que le patch a été appliqué de bonne foi. L’idée est que la majeure partie de ce dont vous avez besoin en termes de modèle de sécurité pour la supply chain se résume à “trust but verify”. Il suffit de s’assurer que si quelqu’un triche, toutes les autres personnes le remarqueront, et cela suffira. Pour la monnaie elle-même, vous voulez empêcher les gens de tricher dès le départ. Mais pour les smart contracts, vous n’avez pas besoin du même degré de sécurité que pour la monnaie. Le fait de pouvoir détecter une fraude après coup est suffisant. Si quelqu’un commence à frauder votre entreprise, vous n’allez tout simplement plus faire affaire avec ce partenaire, et cela mettrait fin à l’histoire. Vous n’avez pas besoin de quelque chose qui empêche la fraude dès le départ. La confiance est essentielle en affaires, et si vous travaillez avec un partenaire, vous avez un certain degré de confiance en lui.
Maintenant, nous entrons dans la deuxième partie de la conférence, qui traite des cas d’utilisation. Je crois que le cas d’utilisation principal des blockchains reste celui des paiements. Payer les fournisseurs, en particulier ceux à l’étranger, peut toujours représenter un défi. Le traitement d’un virement peut être lent, prenant jusqu’à deux semaines dans certains cas. Les flux de paiement du système bancaire sont loin d’être à jour avec le 21e siècle, ce qui peut entraîner des erreurs telles que des paiements en double pour de grandes factures.
Je crois qu’il existe de nombreux cas d’utilisation pour les paiements, en particulier lorsqu’il s’agit de mettre en place des mécanismes complexes tels que les paiements différés, les paiements conditionnels ou des pénalités pour des produits qui ne respectent pas les exigences de qualité ou les délais. Avec de l’argent programmatique, vous pouvez implémenter tous ces schémas de manières qui auraient semblé de la science-fiction.
Cependant, ce cas d’utilisation présente deux réserves. Premièrement, les cryptomonnaies sont encore incroyablement volatiles en valeur, ce qui signifie que leur valeur peut fluctuer de manière spectaculaire au fil du temps. Cette volatilité est un problème constant, mais au cours de la dernière décennie, elle a diminué. La volatilité était même plus élevée il y a dix ans, et elle a diminué progressivement depuis, mais elle demeure en dehors de la zone de confort de la plupart des grandes entreprises. Observer des fluctuations quotidiennes de 10 % dans la valeur de ces cryptomonnaies est toujours la norme. Il y a dix ans, c’était autour de 50 %. Le deuxième problème concernant les paiements est l’existence de milliers de cryptomonnaies, ce qui pose le problème de choisir l’une d’entre elles et de s’entendre avec votre partenaire. Cependant, il existe des systèmes de change robotisés capables de convertir n’importe quelle cryptomonnaie en une autre, avec des frais très faibles, de l’ordre de 0,1 %, ce qui aide à atténuer ce problème.
Un autre cas d’utilisation est la traçabilité passive. La traçabilité est essentielle dans de nombreuses industries telles que l’aérospatiale, le pharmaceutique et l’automobile, car elle peut être une question de vie ou de mort. Des pièces automobiles contrefaites, par exemple, peuvent entraîner des accidents mortels si elles échouent sous contrainte. Les tokens non fongibles (NFTs) peuvent être utilisés pour élever la traçabilité à un niveau supérieur. Un NFT est comme un numéro de série transférable. Grâce à des transactions sécurisées, seul le propriétaire de ce numéro, avec ses clés privées, a le pouvoir de transférer ce numéro à un autre participant. L’utilisation des NFTs peut empêcher les contrefaçons, même de la part des émetteurs originaux.
Pour mettre en œuvre une traçabilité basée sur les NFT, il suffit d’utiliser des codes QR et un smartphone, ce qui en fait principalement une solution logicielle. La technologie blockchain offre un moyen de maintenir une traçabilité transparente de la production jusqu’au consommateur. Cependant, il existe des défis. Premièrement, tout le monde doit s’accorder sur un format et une blockchain. La blockchain transporte des charges binaires, donc si vous souhaitez l’utiliser à des fins de traçabilité, le format doit être convenu. Cela devient un problème complexe puisque de nombreuses industries et entreprises possèdent leurs propres formats et normes uniques.
Ce que les gens ne réalisent pas nécessairement, c’est à quel point les supply chains tendent à être flexibles dans le monde réel. Par exemple, même dans l’aérospatiale où la traçabilité est absolument excellente, vous remarquerez qu’au point A, le document accompagnant une pièce est un PDF. Pour l’étape suivante, c’est le même PDF mais scanné, et peut-être pour l’étape suivante, c’est le même scan mais annoté et rescanné. Fondamentalement, on suppose qu’un humain peut intervenir et déchiffrer les documents. Cependant, si vous voulez opérer sur une blockchain, vous ne pouvez pas avoir un processus aussi lâche. Vous devez spécifier complètement le format binaire pour toutes les données que vous souhaitez exposer sur la blockchain ; sinon, vous perdez l’angle programmatique qui permet de travailler avec des outils programmatiques.
Unifier toutes les normes est difficile, et vous devez choisir une blockchain car, pour que la traçabilité fonctionne, vous devez opter pour une blockchain partagée par tous les participants, au moins pour un secteur et une région. Le problème est que lorsqu’il s’agit de choisir une blockchain, vous êtes confronté à d’énormes conflits d’intérêts. Puisqu’une blockchain ne peut jamais être complètement dissociée de sa cryptomonnaie sous-jacente, si vous investissez dans une cryptomonnaie, vous devenez enclin à vouloir que l’entreprise choisisse la blockchain associée à la cryptomonnaie que vous détenez.
Ces conflits d’intérêts sont omniprésents et difficiles à évaluer puisque les blockchains sont généralement anonymes. Si vous souhaitez tâter le terrain et obtenir des retours sur la blockchain à choisir, vous devez tenir compte des conflits d’intérêts potentiels qui peuvent surgir parmi votre personnel. Les entreprises qui opèrent de grandes supply chains impliquent généralement de nombreuses personnes, et ces problèmes sont amplifiés.
Maintenant, considérons un exemple plus conflictuel. Imaginez des entreprises pharmaceutiques opérant dans des pays très pauvres, comme certains pays africains, où elles font face à des problèmes importants avec des médicaments contrefaits. Le problème est que dans ces pays pauvres, tous les intermédiaires sont corrompus dans une certaine mesure. Des intermédiaires corrompus peuvent prendre une vraie boîte contenant de vrais produits, échanger les vrais médicaments de la boîte contre des médicaments contrefaits, puis vendre la boîte sur le marché. Les personnes qui achètent des médicaments contrefaits peuvent présenter une condition mettant leur vie en danger et avoir réellement besoin du médicament. C’est un problème très sérieux dans les pays pauvres, et reproduire l’emballage de médicaments contrefaits est trivial. Une solution potentielle consiste à utiliser des blockchains et des tokens pour une traçabilité active, qui rappelle le fonctionnement de la taxe sur la valeur ajoutée (TVA) en Europe. La TVA est une taxe difficile à frauder car elle crée un schéma d’ingénierie sociale où les entreprises sont étroitement liées à leurs fournisseurs honnêtes.
L’idée est de reprendre le même concept et de l’appliquer à la blockchain. Par exemple, supposons que vous soyez une entreprise pharmaceutique produisant un médicament. Vous vendez un paquet du médicament à un intermédiaire ou grossiste à un prix plus élevé, par exemple 15 $ au lieu du prix réel de 10 $. Le transfert de propriété du token s’effectue, et le grossiste peut récupérer 1 $ sur la valeur, ramenant ainsi son coût à 14 $. Le grossiste vend ensuite le paquet de médicaments au distributeur, et là encore, il y a un transfert de propriété du token. Une fois que le distributeur réclame le token, il peut récupérer 1 $ de la valeur qu’il vient d’acquérir, et ainsi de suite, jusqu’au consommateur final.
Lorsque le consommateur final reçoit la boîte de médicaments, il paie 11 $, et en scannant le code QR avec un smartphone, il peut récupérer 1 $, lequel lui est reversé. L’application fait deux choses : premièrement, elle permet au consommateur final de récupérer son dollar supplémentaire, et surtout, elle vérifie l’intégralité de la traçabilité et l’affiche au client. Le consommateur final est informé qu’il vient de récupérer le dollar supplémentaire, et le numéro de série est désormais déclaré comme consommé.
En fin de compte, le consommateur final ne peut pas transférer le jeton à qui que ce soit, et la personne qui vient de recevoir la boîte peut voir sur son application mobile que toute la chaîne de traçabilité a été vérifiée, et qu’il s’agit d’une véritable boîte. L’idée est qu’avec ces incitations financières, il devient très difficile de tricher, car distribuer les médicaments sans le numéro de série associé devient impossible. Au bout de la chaîne, les gens peuvent être pauvres, mais ils veulent tout de même s’assurer qu’ils peuvent vérifier si le médicament est légitime, surtout s’il s’agit d’une condition mettant la vie en danger. C’est ce que j’appellerais la traçabilité active, où l’on dispose d’un jeton non fongible (NFT) avec un mécanisme financier superposé qui donne des incitations à tous les acteurs pour réaliser certaines actions.
Dans le cas de l’exemple du médicament, chaque consommateur final a une incitation financière pour réclamer le numéro de série. Sans cette incitation, les gens pourraient ne pas déclarer la boîte comme consommée, et des médicaments contrefaits pourraient être réintroduits dans le réseau. En marquant le numéro de série comme consommé, il ne peut plus être réutilisé par quiconque. Cependant, cette approche nécessite l’alignement et la participation de tous les intervenants, et tous les intermédiaires devront jouer ce jeu financier. Bien qu’il s’agisse d’un cas d’usage valide, cela requiert une coordination importante entre de nombreuses parties.
Une autre application potentielle est d’inciter au recyclage via des systèmes de remboursement de consigne. Ces systèmes existent depuis longtemps et sont plus ou moins répandus selon les pays. Le fabricant d’origine est généralement l’acteur le mieux placé dans le réseau pour réutiliser, recycler ou réparer l’équipement poussé dans la Supply chain. Cependant, il existe des frictions pour mettre en place ces systèmes, et le défi est de réduire encore ces frictions. La blockchain et les cryptomonnaies offrent une manière de diminuer le volume de friction pour les micropaiements et potentiellement de réduire l’infrastructure nécessaire pour garantir que les opérations ne soient pas manipulées.
Par exemple, si vous donniez 20 centimes chaque fois que des personnes rapportent une bouteille en verre, des adversaires pourraient potentiellement gamifier le système en produisant des bouteilles contrefaites et en encaissant la marge réalisée en vendant les pièces récupérées. Les blockchains peuvent offrir une manière simple de réduire certaines de ces combines, mais cela reste fondamentalement quelque chose de progressif. Je ne prétends pas que les systèmes de remboursement de consigne soient nouveaux ; ils existent depuis longtemps. Il s’agit simplement de réduire un peu ces frictions afin qu’il puisse y avoir davantage de cas d’usage.
Un autre cas d’usage intéressant est la sécurité, car les Supply chains sont vulnérables aux cyberattaques. Les Supply chains sont réparties géographiquement par conception, ce qui signifie que les systèmes informatiques et les dispositifs sont dispersés partout. Par conception, la surface d’attaque est grande, et il est difficile d’agir autrement. Une Supply chain doit être connectée à des clients, des fournisseurs, des partenaires et des prestataires logistiques tiers, créant ainsi une vaste surface d’attaque. Bien que l’intégration des systèmes, telle que l’EDI, puisse être précieuse pour passer des commandes auprès des fournisseurs et améliorer les délais de réponse, une intégration plus poussée engendre également davantage de problèmes de sécurité.
Un exemple de cette vulnérabilité est l’incident du Colonial Pipeline, où un service apparemment mineur lié à la facturation a été piraté, empêchant l’ensemble du pipeline de fonctionner pendant une semaine et mettant en danger des infrastructures critiques aux États-Unis. Comment la blockchain peut-elle aider dans ce contexte ? Une approche consisterait à disposer d’une petite quantité de Bitcoin, d’une valeur d’environ 100 dollars, dans chaque système et dispositif, y compris les dispositifs IoT. En rendant public que tous les systèmes et dispositifs possèdent cette réserve, vous créez une incitation pour que les hackers tentent de pénétrer dans vos systèmes et de voler l’argent.
Cependant, il ne s’agit pas de vol ; c’est considéré comme une prime pour que les hackers pénètrent dans votre système. Si un hacker parvient à pénétrer, disons, dans un dispositif IoT, il peut réclamer la somme d’argent qu’il contient. De plus, s’il revient vers vous et vous explique comment il a procédé et comment résoudre le problème, vous pourriez lui verser une seconde partie de la prime, d’une valeur d’environ 300 dollars en Bitcoin. En créant une incitation, vous financez le travail des hackers éthiques qui testent votre sécurité. Si seuls les mauvais acteurs ont une incitation à attaquer vos systèmes, vous découvrirez une faille avec un mauvais acteur, ce qui peut être très désagréable, comme cela s’est produit avec le Colonial Pipeline. Cependant, si vous offrez une incitation aux hackers honnêtes et éthiques pour pénétrer dans votre système, il y a de fortes chances que les personnes qui y parviennent soient des individus honnêtes qui vous expliqueront ensuite comment réparer votre système afin d’empêcher que des problèmes ne surviennent. L’intéressant, c’est que ces réserves sont publiques, donc si vous les intégrez dans votre réseau, vous pouvez surveiller de manière transparente si vous avez été piraté ou non. Vous pouvez également surveiller de l’extérieur tous les dispositifs, même si le dispositif IoT n’est pas connecté à Internet. Si vous voyez les pièces qui se trouvaient dans ce dispositif se déplacer, cela signifie qu’une manière ou une autre, ce dispositif a été piraté, et il est crucial de le savoir.
Rappelez-vous que dans ces failles très médiatisées, il se trouve généralement que les acteurs étaient présents dans les systèmes pendant des mois avant de décider enfin de réclamer leur rançon. En utilisant ce système de sécurité basé sur la blockchain, vous créez un mécanisme d’alerte précoce. Même si des hackers non éthiques parviennent à pénétrer dans le système, ils pourraient simplement s’emparer de l’argent et prendre la fuite, sans passer par le processus chaotique de la rançon.
C’est une manière différente de concevoir la sécurité et probablement pas le cas d’usage auquel vous pensiez pour la blockchain dans votre Supply chain. Mais comme vous pouvez le constater, les cas d’usage intéressants pour la Supply chain incluent toujours une forme d’incitation monétaire, ce qui est très à la manière de Bitcoin en termes d’approche de la blockchain concernant les cas d’usage en Supply chain.
Comme je l’ai mentionné, les blockchains sont très difficiles à concevoir par rapport à pratiquement toute solution alternative. Vous pouvez vous attendre à ce qu’il soit au moins deux ordres de grandeur plus difficile de concevoir une solution blockchain. Ainsi, chaque fois que vous pensez pouvoir résoudre un problème en allouant une semaine de travail d’un ingénieur logiciel, multipliez ce chiffre par 100, et cela vous donnera une idée de l’effort nécessaire pour faire la même chose avec la blockchain. Il existe des situations où cela a du sens ; ce n’est pas parce que c’est coûteux que cela ne peut pas être rentable, mais c’est fondamentalement difficile, et il faut en tenir compte. Les coûts sont également bien plus élevés en termes de ressources informatiques. En général, la blockchain est très difficile à faire évoluer, et par rapport à une configuration non blockchain, vous finissez par dépenser 100 fois plus de ressources informatiques pour tout ce que vous voulez faire avec la blockchain. Dans certaines situations, cela peut ne pas vous importuner, mais dans bien d’autres situations, une augmentation de 100 fois de votre coût de matériel informatique est significative.
La question est la suivante : comment essayer des alternatives ? Dans presque toutes les situations impliquant une blockchain, il existe une alternative non blockchain. En général, cela s’obtient en assouplissant les exigences. En termes de valeur ajoutée, si vous êtes prêt à renoncer à la propriété de non-répudiation que j’ai décrite au début de cette conférence, vous pouvez mettre en place un consortium d’une certaine sorte. Ce consortium utilisera une base de données de points de contrôle, publiera des journaux pouvant être vérifiés par n’importe quel tiers au sein du consortium ou potentiellement par des entreprises ou entités extérieures au consortium. L’un des points critiques sera de disposer de formats binaires spécifiés de manière très claire afin qu’il soit possible pour les parties d’opérer de manière programmée. Avec cela en place, vous obtiendrez la majeure partie de la valeur que vous obtiendriez autrement d’une blockchain.
Un excellent exemple en Supply chain serait GS1 pour les codes-barres. GS1 est une entité qui attribue des codes-barres, et elle le fait depuis des décennies. Cette organisation a été créée en tant qu’entité distincte, donc à l’époque, ce n’était pas IBM directement qui gérait les codes-barres. GS1 offre la valeur ajoutée d’une blockchain sans utiliser réellement une blockchain. Cependant, cette approche nécessite une autorité centrale ou un consortium en qui vous pouvez avoir confiance. Dans de nombreux secteurs très concentrés, comme la pharmacie, établir un consortium disposant déjà d’une part de marché significative peut ne pas être trop difficile.
Pour conclure, le consensus Satoshi Nakamoto est une découverte stupéfiante. En 2008, si vous aviez demandé à des experts en systèmes distribués s’il était possible de résoudre le problème du consensus byzantin sans recourir à une autorité centrale, la plupart d’entre eux auraient répondu non, car cela ne semblait pas possible. L’idée était tellement en dehors du domaine de ce que l’on pensait possible qu’ils ne regardaient même pas dans cette direction. À cet égard, c’était une découverte stupéfiante. Comme je l’ai présenté avec le mini Bitcoin, c’est une idée très simple qui a des utilisations au-delà de l’argent, l’argent constituant le cas d’usage principal.
Ce que nous devons garder à l’esprit, c’est que pour chaque cas d’usage de la blockchain, il existe généralement une alternative non blockchain qui est nettement plus simple à exploiter. Nous devons vraiment évaluer si la surcharge supplémentaire associée à une blockchain vaut tout le tracas que cela engendre. En guise de conclusion, n’oubliez jamais qu’une blockchain est fondamentalement liée à sa devise sous-jacente, et cela génère le berceau de tous les conflits d’intérêts.
Dans une de mes conférences précédentes sur la recherche de marché face à des adversaires, j’ai présenté mes points de vue sur la manière de choisir des fournisseurs d’entreprise et abordé les problèmes liés aux avis. De nombreuses approches intuitives pour aborder ces problèmes sont sapées par des conflits d’intérêts. Avec les blockchains et les cryptomonnaies, le problème est mille fois pire. Tout le monde dispose d’incitations massives s’ils possèdent du Bitcoin, du Bitcoin Cash, de l’eCash ou toute autre cryptomonnaie. Ils auront un biais significatif en raison de leurs investissements, et si votre entreprise prend une direction favorable à une blockchain spécifique, cela pourrait également être favorable pour leurs investissements.
Je n’ai pas de bonne solution à ce problème, mais je conseille d’être vigilant et préparé. La plupart des informations trouvées en ligne sur les cryptomonnaies ne sont pas fiables, car de nombreuses personnes ont un conflit d’intérêts en promouvant leur devise préférée. Ne faites confiance à personne, sauf aux collègues en qui vous auriez la confiance de donner votre vie. Fiez-vous à votre propre jugement ou à celui de collègues qui comprennent ce qui se passe. Les conflits d’intérêts liés aux blockchains conduisent à des comportements inattendus, en particulier dans la Supply chain, où des relations de longue durée et un haut degré de confiance sont généralement présents.
Les organisations qui gèrent de grandes Supply chains peuvent ne pas être préparées au niveau de méfiance que l’on retrouve dans l’univers des cryptomonnaies. Cela conclut la conférence. Passons aux questions.
Question: La blockchain et le Bitcoin ne sont pas identiques ; l’une est unique tandis que l’autre est une technologie de base.
Oui, la sémantique et la terminologie sont importantes. Je savais, en préparant cette conférence, qu’il y aurait des personnes signalant qu’ils ne sont pas exactement la même chose. Cependant, si vous souhaitez examiner une blockchain pure au sens technique, alors un dépôt Git, comme GitHub, est une blockchain. Les dépôts Git existent depuis environ 15 ans, et ils n’ont pas mis le monde sens dessus dessous. Il n’y a pas des milliards d’euros et de dollars qui circulent dans ces dépôts Git.
L’essentiel est que la blockchain ne fonctionne qu’en termes de valeur ajoutée qu’elle génère. Ce qui différencie le Bitcoin de Git, malgré le fait que les deux soient des blockchains, c’est que le Bitcoin possède des incitations financières intégrées qui débloquent certains aspects de la technologie. Voilà le truc. Si vous enlevez tous les aspects monétaires et incitations qui sont conçus, alors vous obtenez quelque chose qui n’est qu’une structure de données technique, mais qui n’a aucun intérêt. Certes, c’est une belle structure de données – Git est une belle structure de données – mais cela n’a pas rendu le marché fou, et certainement, les gens ne diraient pas : “Oh, ce dépôt Git vaut des milliards.” Il y a quelque chose de différent. En laissant de côté le chicane sur la terminologie, je crois que la principale raison pour laquelle de nombreuses entreprises ont opté pour le terme blockchain était d’introduire une distinction dans le discours par rapport aux cryptomonnaies qui étaient perçues comme le véritable Far West.
Question: La blockchain est la technologie qui permet un consensus décentralisé mais avec un coût – délai, scalabilité, etc., et pollution.
Absolument. D’ailleurs, je peux également aborder le cas d’usage lié à la pollution. Le fait est que chaque fois que vous avez un processus d’émission monétaire, peu importe la manière dont l’argent est émis – que ce soit la banque centrale pour l’euro, la Fed pour le dollar, ou autre – si les acteurs économiques peuvent investir pour bénéficier de cette émission monétaire, ils investiront jusqu’au coût marginal. Donc, si la banque centrale imprime 100 et que je peux investir 90 pour récupérer ces 100, je le ferai.
Peu importe le processus d’émission monétaire, les gens dépenseront jusqu’au coût marginal pour correspondre à l’utilité. Il s’est avéré que, puisque Bitcoin Core a pris de la valeur, les gens sont prêts à payer beaucoup en électricité pour acquérir ces Bitcoins nouvellement créés. Cependant, le processus diminue de manière exponentielle, ce qui signifie qu’au bout de quelques décennies, la quantité de Bitcoins nouvellement créés diminuera jusqu’à presque rien, et donc le montant que les gens seront prêts à payer pour la preuve de travail sera presque nul. Il s’agit d’un problème transitoire, et pour l’instant, c’est surtout la capacité électrique inutilisée qui est utilisée.
Je suis d’accord avec votre conclusion ; cela vous offre un consensus décentralisé du point de vue du consensus byzantin, et oui, il y a d’énormes surcoûts associés. Absolument, c’est bien la conclusion à retenir.
Question: Pourquoi l’utiliser dans l’industrie de la Supply chain ? Quel problème le paradigme décentralisé résout-il ? Quel problème apporte-t-il ?
J’ai présenté divers cas d’usage dans ma conférence. La décentralisation vous évite d’avoir à concevoir un consortium. Le problème est que si vous avez une autorité centrale en laquelle vous avez confiance et que cette autorité est honnête, tant mieux – vous n’avez pas besoin d’une blockchain. Le fait est, que faites-vous quand vous ne disposez pas de cela?
Même les domaines qui disposaient d’autorités centrales, comme par exemple les virements bancaires pour les paiements, sont sous le contrôle d’autorités centrales – il y a des gardiens qui sont les banques puis les banques centrales. Nous ne sommes pas, dirais-je, en période de rupture de stock d’autorités centrales, mais, en 2021, le règlement d’un paiement avec mes clients d’outre-mer prend encore deux semaines. C’est le 21e siècle ; je peux envoyer un courriel, et il est reçu en quelques secondes par ces clients, mais l’envoi d’un virement bancaire prend des semaines. Il est donc évident qu’il existe certains problèmes qui sont parfois très difficiles à résoudre, car peut-être que le problème n’est pas l’absence d’autorités centrales, mais la surabondance d’autorités centrales, ou vous avez des problèmes complexes où il est impossible de rassembler les gens pour trouver une solution.
J’ai décrit quelques cas d’usage, par exemple, la traçabilité active, où vous opérez dans un pays pauvre où tous les intermédiaires sont corrompus. C’est un autre problème où vous ne pouvez faire confiance à personne. Lorsqu’on est confronté à une corruption épidémique, ces problèmes sont très difficiles à résoudre. C’est une situation où la blockchain décentralisée peut vous offrir un moyen d’ingénier l’honnêteté des participants. Voilà le truc : on ne s’attend pas à ce que les participants soient honnêtes ; ils sont conçus pour rester honnêtes tout en opérant la supply chain. Si tout le monde est déjà très honnête et que les autorités centrales sont appliquées, alors il y a très peu de valeur ajoutée.
Question: Comment gérez-vous l’existence des ASIC (circuits intégrés spécifiques à une application) matériel spécialisé dans le minage et les fermes afin de s’assurer que personne ne puisse facilement détenir 51% de la puissance des réseaux ?
Historiquement, les ASIC ont été une force positive pour la sécurité du réseau Bitcoin Core. Pourquoi cela ? Parce qu’il y a un autre problème dans le paysage moderne : les botnets. Les botnets sont d’immenses flottes d’ordinateurs compromis, contrôlés par des organisations criminelles qui prennent littéralement le contrôle de millions d’appareils du quotidien tels que les ordinateurs, les imprimantes et les caméras de sécurité. Ces organisations ne veulent pas vous empêcher d’utiliser votre appareil, car cela entraînerait des réparations et l’élimination du malware.
En termes de sécurité, le contexte actuel est que les organisations criminelles disposent littéralement de dizaines de millions d’ordinateurs gratuitement. Ces organisations qui opèrent des botnets, si vous regardez les mises à jour de sécurité de Microsoft, vous verrez qu’à quelques reprises par an, Microsoft a éliminé d’immenses botnets dans le passé. Ils communiquaient, par exemple, “Nous avons déployé cette mise à jour Windows, et au fait, nous venons d’éliminer, de dégager ce botnet de 50 millions de machines.” C’est impressionnant. Ainsi, les ASIC signifient qu’il n’y a aucun intérêt à jouer à ce jeu avec le matériel classique comme celui de vos ordinateurs ordinaires. Ainsi, les criminels qui opèrent des botnets ne peuvent pas utiliser ces botnets pour miner de la cryptomonnaie, ce qui élimine un angle de monétisation de ces botnets. Cela oblige les mineurs à s’engager envers la monnaie.
Vous voyez, les ASIC ne sont pas un problème ; ils sont, au contraire, le type de solution qui permet de s’assurer que cette puissance de traitement supplémentaire ne cause pas de désastres ni ne tire avantage de la puissance de traitement disponible à travers les botnets. Les botnets sont déjà un problème immense pour tout le monde, et nous ne voulons pas renforcer davantage ces botnets.
Question: Que pensez-vous du Telegram Open Network qui n’a pu voir le jour en raison des tribunaux américains ? Que pensez-vous en général des cryptomonnaies émises par des messageries ? Apportent-elles quelque chose de nouveau ?
Eh bien, je pense que la situation est très prévisible pour Telegram et la même chose pour Facebook, ainsi que toute entreprise qui souhaite opérer en tant que société publique. Il existe des réglementations générales qui stipulent que si vous êtes une entreprise, il y a des exigences KYC (Know Your Customer), et je ne vais pas trop entrer dans les détails. Fondamentalement, si vous êtes une grande entreprise, vous pouvez vous attendre à ce que dans de nombreuses juridictions, il y ait des exigences KYC. Je ne suis pas ici pour discuter de savoir si les réglementations sont adéquates ou non ; je dis simplement que les réglementations KYC sont prédominantes dans de nombreux pays.
Si vous revenez à ce qui fait d’une blockchain une blockchain, comme je l’ai décrit dans la liste des exigences, le deuxième point est que les participants sont anonymes. Ainsi, voici les exigences KYC. Si vous voulez opérer une blockchain, vous devez accepter de préserver une certaine pseudo-anonymat de tous ceux qui participent à ce réseau, ce qui signifie qu’en termes d’exigences KYC, vous êtes complètement désarmé.
Je n’étais pas très sûr de ce que ces entreprises envisageaient, mais je ne peux imaginer une entreprise qui souhaite être à la fois publique et répondre aux autorités comme la SEC aux États-Unis ou l’AMF en France, tout en pouvant se livrer à un schéma qui va évidemment totalement à l’encontre des réglementations KYC, très prédominantes pour les grandes entreprises. À mon avis, fondamentalement, elles essayaient probablement de sonder le terrain pour voir si, peut-être, les régulateurs assoupliraient les réglementations uniquement pour elles, juste parce qu’elles étaient grandes. Cela n’a peut-être pas fonctionné pour elles, et ainsi elles en sont revenues sur cette idée. Fondamentalement, outre cela, je crois que, par exemple, Telegram ou Facebook, s’ils acceptent de simplement promouvoir une cryptomonnaie sans l’opérer, pourraient en fait donner un énorme coup de pouce à cette cryptomonnaie. Cependant, le problème est que puisqu’ils se contenteraient de promouvoir, sans opérer, ils auraient peu à y gagner, sauf s’ils ont conçu un conflit d’intérêts où ils bénéficient de la croissance de la monnaie. D’ailleurs, Elon Musk, je vous regarde quand vous commencez à tweeter au sujet du Bitcoin et du fait que votre entreprise détient une position à ce sujet. C’est littéralement le jeu qui peut être joué : vous commencez par acquérir une participation dans une cryptomonnaie et ensuite vous gonflez littéralement cette cryptomonnaie en faisant des déclarations très visibles à son sujet. Laissez la valorisation monter, et ensuite, une fois qu’elle a augmenté, vendez-la. D’ailleurs, ce processus s’appelle pump and dump. Probablement que Telegram et Facebook se sont rendu compte que la seule façon pour eux de profiter uniquement de la promotion d’une monnaie sans l’opérer était le pump and dump, et ils ne voulaient pas que leur réputation soit entachée par ce genre de magouilles.
Question: Il y a sept ans, j’ai vu de nombreuses startups introduire la technologie blockchain dans des domaines liés à la supply chain. Aucune d’elles n’a réussi, du moins à grande échelle. Connaissez-vous une qui a réussi et prouvé qu’elle fonctionnait à grande échelle ?
Bonne question. Je veux dire, d’abord, je ne pense pas que quiconque ait, sur la planète, une blockchain qui soit prouvablement scalable et réellement fonctionnelle à grande échelle. Si l’on observe l’expérience Bitcoin Core, cela ne se passe pas bien. Le réseau est complètement saturé ; il est maintenant saturé depuis quatre ans. C’est vraiment le contraire de la scalabilité. Si l’on regarde Bitcoin Cash, c’est une autre blockchain. Ils ont fait quelques progrès, mais ils n’ont jamais vraiment eu le temps ; ils ont eu quelques dissensions internes, et ainsi ils n’ont jamais effectué toutes les dernières étapes en termes d’ingénierie pour la faire fonctionner. Il existe une autre fourchette nouvelle, comme je le mentionnais, appelée eCash qui est en fait une fourche de Bitcoin Cash, où ils essaient encore de réaliser toutes les choses qui n’ont pas été effectuées dans le client Satoshi original parce que la plupart des problèmes de scalabilité remontent au client Satoshi original. Il y a un espoir qu’ils puissent atteindre une scalabilité massive, mais encore une fois, cela relève plus d’une perspective théorique. Cela n’est pas prouvé dans le sens où il existe quelque chose qui, à l’heure actuelle, fonctionne à l’hyperscale, bien que nous ayons des raisons de croire que c’est, dans une certaine mesure, possible. J’ai publié à ce sujet, d’ailleurs, si vous voulez consulter ma publication sur les blocs de taille téraoctet pour Bitcoin.
Maintenant, personne n’a réussi à amener ce genre de choses à grande échelle. C’est très difficile. L’augmentation d’échelle de la couche de base est le premier défi, et ensuite évidemment, les startups souhaitant le faire pour la supply chain veulent faire quelque chose d’encore plus avancé. Elles doivent avoir la couche de base capable de monter en charge, et ensuite elles souhaitent faire quelque chose qui l’est également pour la supply chain à grande échelle. Je crois qu’aucune d’elles n’a réussi parce que, comme je le décrivais, oui, il y a des cas d’usage pour la supply chain, et oui, il y a une marge de valeur ajoutée, mais d’abord, vous devez résoudre ces problèmes très difficiles de scalabilité et de latence. Cela n’a peut-être pas fonctionné pour elles, et vous pouvez voir que les articles que j’ai cités ne sont pas si anciens. Je veux dire, les articles sur Avalanche datent littéralement de seulement quelques années. Il y a eu des percées qui sont encore assez récentes, et il faudra encore beaucoup de temps. Pour monter en charge, vous devez réaliser des percées au niveau de l’algorithmique théorique, ce qui est très difficile à faire avancer.
Les algorithmes que j’ai décrits, comme Avalanche, sont d’une complexité redoutable à implémenter correctement. Il y a une multitude de détails que vous pouvez mal gérer, et en termes de blockchain, si vous vous trompez, cela signifiera que vous serez vulnérable, attaqué et que de l’argent sera perdu. La gravité des bugs et des problèmes lorsque vous opérez dans l’univers de la blockchain est très sévère. Ce n’est pas comme votre logiciel d’entreprise classique dans lequel, en cas de plantage, vous pouvez redémarrer, corriger manuellement les bouts de données affectées, et repartir de là. Avec les blockchains, une fois que vous avez une corruption massive, le dommage peut être permanent, et c’est un environnement très difficile où opérer.
Je crois que bon nombre des startups qui se sont lancées dans cet espace étaient absolument mal préparées en termes de mentalité d’ingénierie nécessaire pour relever les défis liés à l’opération dans le domaine de la blockchain. Une bonne ingénierie ne suffit pas ; il faut une ingénierie vraiment excellente pour réussir.
Cela conclut la section Questions & Réponses pour cette conférence. La prochaine conférence portera sur l’optimisation mathématique pour la supply chain et se tiendra le mercredi 25 août. Je prendrai quelques jours de vacances. D’ailleurs, l’optimisation mathématique, contrairement à la blockchain, est utilisée quotidiennement dans de nombreuses supply chains. Les applications sont énormes, et les cas d’usage sont très concrets. Nous ne parlons pas de cas d’usage de niche ; les applications sont massives.
L’optimisation mathématique est étroitement liée à l’apprentissage statistique et à la prise des meilleures décisions supply chain. À la prochaine.
