Mettre fin au débat Bitcoin vs Blockchain

Y a-t-il une valeur dans une blockchain sans crypto-monnaie ?

Le débat dure depuis un certain temps, mais le mois dernier a connu une sérieuse reprise. La question posée est la suivante :

Y a-t-il une valeur dans une blockchain sans crypto-monnaie ? Et ces « registres partagés sans jeton » peuvent-ils être appelés blockchains ?

Alors j'ai lu L'article de Bailey, regardé La vidéo de Tim, Lire ce message du Nasdaq, a suivi celui de Richard chaque mot, et j'avais même le mien débat animé (voir commentaires) avec Chris DeRose de la fondation Counterparty. Tant d’air chaud.

Une chose que Chris sait bien résumer à la question : la blockchain est-elle une innovation économique ou informatique ? L’implication est que si les blockchains sont une innovation purement économique, les blockchains sans crypto-monnaies ne servent à rien. Alors permettez-moi d'exposer ma position au début :

La blockchain Bitcoin était à la fois un outil économique et les une innovation informatique.

J'autorise ici « l'innovation » à inclure une nouvelle combinaison de techniques existantes, plutôt que quelque chose qui n’a aucun précédent. Cette définition permet de considérer le World Wide Web comme une innovation, même s’il n’a fait que combiner l’hypertexte avec une variante de certains protocoles Internet existants. Si vous souhaitez adopter une définition plus stricte de l'innovation, soyez mon invité, mais vous serez surpris de voir à quel point il reste peu de véritables « innovations ». Paraphraser Le professeur, il y a peu de nouveauté sous le soleil.

Pour être précis, j'affirme que les blockchains sans jeton servent à quelque chose, mais c'est un but différent par rapport à la blockchain Bitcoin originale. Les crypto-dirigeants se moquent des blockchains sans jetons parce qu'elles ne peuvent pas fournir de résistance à la censure et une sécurité décentralisée grâce à une preuve de travail. Les responsables de la Fintech se moquent des blockchains publiques parce qu’elles sont lentes, coûteuses et inadaptées à la finance traditionnelle. Eh bien, continuez à rire tout le monde, car je pense que vous avez tous les deux raison.

Je vais affirmer que les blockchains sans jetons sont utiles pour maintenir les bases de données décentralisées synchronisées, même dans une seule organisation dans laquelle règne une confiance parfaite. Et puis nous verrons quelles autres fonctionnalités offrent les blockchains, qui les rendent adaptées à la création d'un consensus pour types spécifiques de transactions entre organisations, où la confiance est limitée et imparfaite.

Malheureusement, pour suivre l'argument, vous devrez vous intéresser au modèle transactionnel Bitcoin, au contrôle de concurrence multiversion de base de données (MVCC) et au problème de la résolution des conflits dans la réplication de bases de données multi-maîtres. Je ferai de mon mieux pour m'en tenir à l'anglais, mais c'est quand même un sujet technique, et il n'y a pas moyen de l'éviter.

Le modèle transactionnel de Bitcoin

Le modèle transactionnel Bitcoin est simple mais puissant. Chaque transaction Bitcoin comporte un ensemble d’entrées et un ensemble de sorties. Chaque entrée « dépense » une sortie d’une transaction précédente. Tous les bitcoins contenus dans les entrées d'une transaction entrent dans cette transaction et sont répartis entre ses sorties en fonction des quantités qui y sont écrites. De cette manière, les transactions forment une chaîne connectée multidirectionnelle qui se termine au niveau des transactions « coinbase » dans lesquelles de nouveaux bitcoins sont créés.

Bitcoin a un certain nombre de règles supplémentaires qui sont appliquées par chaque nœud du réseau :

• Chaque entrée dans une transaction doit prouver qu’elle a le droit de dépenser la sortie précédente à laquelle elle est connectée. Ce droit est limité par des conditions codées dans la sortie précédente.
• Une transaction doit avoir suffisamment de bitcoins totaux dans ses entrées pour couvrir le total écrit dans ses sorties. Les seules exceptions sont les transactions coinbase qui créent de nouvelles unités de monnaie.
• Chaque sortie ne peut être dépensée qu’une seule fois, en d’autres termes, elle ne peut être connectée qu’à une seule entrée lors d’une transaction ultérieure.

En raison de cette dernière règle, le réseau nécessite un mécanisme permettant de parvenir à un consensus sur les transactions valides, et c’est ce que fait la blockchain. Spécifiquement:

Si deux transactions tentent de dépenser le même résultat, une seule de ces transactions sera finalement acceptée. Une blockchain agit comme un mécanisme unifié pour détecter et prévenir ces conflits sur le réseau.

La blockchain est structurée comme une série de blocs liés, dans lesquels chaque bloc contient un ensemble de transactions qui n'entrent pas en conflit entre elles ni avec les blocs précédents, à partir du premier bloc créé en 2009. En théorie, la chaîne pourrait contenir un série de transactions individuelles, mais en regroupant les transactions en blocs, nous obtenons un certain nombre d'efficacités qui rendent le système plus pratique.

Alors quel est le but d’une cryptomonnaie dans tout ça ? Cela revient à la question de savoir qui décide des blocs qui forment la chaîne. Bitcoin est décentralisé et n’a aucune autorité pour prendre cette décision, il doit donc trouver un autre moyen de parvenir à un consensus.

Nous aimerions peut-être utiliser une approche démocratique, dans laquelle les nœuds du réseau votent sur des blocs et la majorité gagne. Malheureusement, comme tout sondage sur Internet peut le démontrer, la démocratie représentative n'est pas possible en ligne, en raison du problème de l'usurpation d'identité (également connue sous le nom de Attaque Sybil). Une personne peut s’emparer d’un million d’ordinateurs et décider comment elle vote, prenant ainsi le contrôle du consensus du réseau. Personne d’autre ne saura que cela s’est produit.

Pour résoudre ce problème, Bitcoin rend délibérément difficile l’ajout d’un bloc à la chaîne, via un processus appelé « minage ». Pour créer un bloc, vous devez résoudre un problème mathématique difficile mais inutile qui demande beaucoup de calculs (et donc d'électricité et d'argent). Il vous faut également un peu de chance, puisque vous êtes en concurrence avec de nombreux autres mineurs de blocs à travers le monde. Vous ne pouvez pas avancer longtemps en achetant un ordinateur de minage plus puissant, car le réseau ajuste régulièrement la difficulté du problème pour maintenir un taux global stable d'un bloc toutes les 10 minutes.

S'il est si difficile et si coûteux de créer un bloc, pourquoi s'en soucierait-on ? La réponse est dans la récompense de bloc. Le mineur d’un bloc qui réussit contrôle la transaction coinbase qui lui attribue 25 bitcoins (cette somme est divisée par deux tous les quatre ans). Ils peuvent vendre ces bitcoins sur le marché libre pour 7,000 XNUMX dollars (au taux actuel), payer leur facture d'électricité et, espérons-le, empocher quelques bénéfices. Les mineurs perçoivent également un petit supplément sur les frais liés aux transactions, même si pour l’instant ces frais jouent un rôle mineur.

Ainsi, Bitcoin génère un consensus via une preuve de travail et le nœud de l'argument des têtes de Bitcoin est le suivant : Sans crypto-monnaie, il n’y a aucun moyen d’encourager l’extraction décentralisée de blocs. Il n’existe donc aucun moyen de sécuriser une blockchain ouverte contre les attaques par usurpation d’identité. N’importe qui peut donc monopoliser le consensus du réseau et rendre le tout inutile. Je ne contesterai rien de tout cela.

Contrôle de concurrence multiversion

En attendant, je veux parler de quelque chose qui peut sembler complètement sans rapport.

Une base de données est un référentiel d'informations structurées, regroupées en entités de type feuille de calcul appelées tables. Un exemple simple d'un tel tableau est une liste de comptes bancaires, dans laquelle chaque ligne contient un numéro de compte ainsi que le solde de ce compte. Disons que votre compte démarre la journée avec un solde de 900 $. Aujourd’hui, un versement hypothécaire automatique de 750 $ est prévu et vous devez également retirer 400 $ à un guichet automatique. Malheureusement, vous ne disposez pas d'une facilité de découvert, donc l'une de ces opérations est vouée à l'échec.

Les processus de paiement hypothécaire et de retrait aux distributeurs automatiques s'exécutent sur des systèmes distincts, qui accèdent tous deux à cette base de données de comptes unique. Disons que chaque processus fonctionne en lisant le solde de votre compte, en vérifiant qu'il est suffisant pour l'opération, en lançant cette opération, en vérifiant que l'opération est terminée, en calculant le nouveau solde et enfin en l'écrivant dans la base de données.

Tant que votre versement hypothécaire et votre retrait au guichet automatique ne se chevauchent pas, cette logique fonctionnera bien. La première opération s'exécutera avec succès et la seconde sera abandonnée car votre compte ne dispose pas de fonds suffisants. Selon la commande, vous recevrez un appel téléphonique en colère de la banque ou un message grossier sur l'écran du guichet automatique.

Mais que se passe-t-il si les deux processus démarrent en même temps ? Dans ce cas, chacun lira le solde de votre compte et le jugera suffisant pour continuer. Une fois le paiement hypothécaire terminé, votre nouveau solde sera calculé à 150 $ et inscrit dans la base de données. Une fois le retrait au guichet automatique terminé, votre nouveau solde de 500 $ sera également écrit. L'une de ces opérations d'écriture va remplacer l'autre et, selon votre chance, vous recevrez un bonus de 750 $ ou 400 $ de votre banque. Nul doute que vous apprendrez bientôt à programmer vos visites au guichet automatique pour le jour de votre prêt hypothécaire.

Bien sûr, cela ne se produit pas dans la réalité, en raison d'une technologie de base de données appelée Contrôle de la concurrence. Le contrôle de la concurrence maintient nos données (en particulier financières) saines et sécurisées, et il se présente sous de nombreuses formes. Mais tous partagent le principe selon lequel les opérations de base de données sont regroupées en « transactions », qui sont traitées de manière atomique, ce qui signifie qu'elles réussissent ou échouent dans leur ensemble. La concurrence préserve la cohérence en verrouillant ou en gelant des parties d'une base de données lorsqu'elles sont utilisées par une transaction, afin d'empêcher d'autres transactions d'opérer sur les mêmes informations de manière conflictuelle.

Si nous n'avions pas besoin d'exécuter des transactions en parallèle, nous pourrions verrouiller l'intégralité de la base de données pendant toute la durée de chaque transaction. Toutefois, cela n’est pas pratique dans la plupart des applications du monde réel. Un bon système de contrôle de concurrence permet des opérations parallèles en verrouillant le moins de données possible pendant la durée la plus courte possible. Dans l'exemple ci-dessus, seule la ligne de la base de données correspondant à votre compte serait verrouillée, et seulement pendant la fraction de seconde au cours de laquelle un contrôle final et une déduction ont eu lieu. Une transaction conflictuelle opérant en parallèle devrait simplement attendre que ce verrou soit libéré.

Une technique de contrôle de concurrence populaire est appelée contrôle d'accès concurrentiel multiversion, ou MVCC pour faire court. Dans MVCC, chaque transaction voit un instantané cohérent des données à un moment donné, même si une partie de ces données est en train d'être mise à jour par une deuxième transaction simultanée. Ce isolement de cliché La propriété garantit, par exemple, qu'un relevé indiquant notre solde total sur plusieurs comptes sera toujours correct, même si certains fonds sont en train de passer d'un compte à un autre. Une transaction n'affectera les données vues par une deuxième transaction que si la seconde commence après que toutes les modifications de la première ont été appliquées avec succès.

En coulisses, MVCC fonctionne en permettant de conserver simultanément plusieurs versions d'une ligne, ainsi qu'un horodatage qui représente la date de dernière modification de chaque version. La modification d'une ligne de base de données dans MVCC marque la version actuelle de cette ligne pour suppression, tout en appliquant la modification à un copie de cette ligne avec un horodatage mis à jour. Du point de vue de la couche de stockage de la base de données, il n'existe pas de modification d'une ligne en place. Chaque transaction sait exactement quand elle a commencé et ne voit que les versions des lignes dont l'horodatage est antérieur à cette heure. Les anciennes versions des lignes peuvent être supprimées du stockage une fois qu'il n'y a plus de transactions en cours qui pourraient avoir besoin d'y accéder.

Pour nos besoins ici, MVCC évite les conflits entre les opérations d'écriture. Spécifiquement:

Si deux transactions tentent de supprimer la même version de ligne, une seule de ces transactions sera finalement acceptée. Le contrôle de concurrence multiversion agit comme un mécanisme unifié pour détecter et prévenir ces conflits au sein d'une base de données.

Ça vous dit quelque chose ? Il y a encore un élément de contexte dont nous devons discuter.

Réplication de base de données multi-maître

Parlons maintenant de la réplication de base de données, dans laquelle une base de données existe en plusieurs copies. Il existe un certain nombre de bonnes raisons de répliquer une base de données, telles que :

• Pour augmenter la fiabilité, de sorte que si une copie de la base de données est perdue (par exemple en raison d'une panne de disque), nous puissions passer instantanément à une deuxième copie.
• Pour augmenter le débit, si le volume des opérations dépasse la capacité d'un seul serveur de base de données.
• Réduire la latence, afin que les processus exécutés dans le bureau de Singapour n'aient pas besoin d'attendre les réponses d'une base de données située à Toronto.

Si vous préférez lire données provenant de bases de données, la réplication est une technique idéale, car toutes les répliques contiennent les mêmes informations. Cependant, les choses deviennent plus délicates lorsqu'il s'agit d'opérations d'écriture, car nous devons décider où ces opérations d'écriture sont effectuées et comment elles sont transférées vers d'autres copies de la base de données.

La réponse la plus courante consiste à utiliser la réplication maître-esclave, dans laquelle une seule base de données (le « maître ») fait autorité. Toute modification des données est effectuée exclusivement sur le maître et se répercute ensuite sur toutes les autres bases de données « esclaves » via un journal des transactions. Cela permet de synchroniser instantanément toutes les copies de la base de données (plus ou moins).

Malheureusement, si les opérations d'écriture sont fréquentes, la réplication maître-esclave nous ramène directement au problème que la réplication a été conçue pour résoudre. La base de données maître devient un goulot d'étranglement en termes de fiabilité, de débit et de latence, puisque chaque opération d'écriture est effectuée sur elle seule.

Une stratégie plus complexe est appelée réplication multi-maître, dans laquelle les écritures peuvent être effectuées sur n'importe laquelle des copies de base de données, plutôt que sur un seul maître. Dans ce cas, les copies partagent les mises à jour entre elles de manière peer-to-peer afin de rester synchronisées.

Cela semble simple en théorie, mais la réplication multi-maître introduit un nouveau problème car des conflits peuvent survenir. Que se passe-t-il si deux copies d'une base de données mettent à jour la même ligne en même temps, puis tentent d'échanger ces mises à jour entre elles ? Les deux bases de données remarqueront qu'une mise à jour conflictuelle a eu lieu et devront appliquer une stratégie convenue pour résoudre ces conflits. Et voilà, les choses arrivent assez complexe – voir la documentation pour MySQL, SQL Server or Oracle pour quelques exemples de stratégies de résolution de conflits. (J'ignore la réplication multi-maître synchrone ou dite « impatiente », dans laquelle toutes les répliques doivent s'engager dans une opération d'écriture avant qu'elle puisse avoir lieu, car cela devient chaque copie de la base de données dans un goulot d'étranglement.)

Voici donc où mène tout ce contexte :

Ne serait-il pas bien si nous pouvions distribuer un contrôle de concurrence multiversion, pour éviter les conflits lors de la réplication multi-maître ?

Eh bien, oui, j'imagine que ce serait vraiment très bien. Et je crois que c’est précisément ce que font les blockchains.

Blockchains en tant que MVCC distribué

Recopieons quelques phrases que j'ai écrites en gras ci-dessus :

Si deux transactions tentent de passer le même sortie, alors une seule de ces transactions sera finalement acceptée. Une blockchain agit comme un mécanisme unifié pour détecter et prévenir ces conflits à travers le réseau.

Si deux transactions tentent de effacer le même version en ligne, alors une seule de ces transactions sera finalement acceptée. Contrôle de concurrence multiversion agit comme un mécanisme unifié pour détecter et prévenir ces conflits dans une base de données.

Ces phrases sont identiques à l'exception des termes en gras. Voici donc ce que je vais affirmer :

Une blockchain fournit un MVCC distribué (avec quelques cloches et sifflets supplémentaires).

Poussons un peu plus loin la comparaison. Du point de vue d’un nœud blockchain, l’ensemble actuel des résultats de transactions Bitcoin non dépensés forme une base de données dans laquelle chaque ligne est une seule sortie non dépensée. Ceci est similaire à la base de données des comptes bancaires que nous avons décrite précédemment, à la différence mineure que le solde de chaque compte peut être réparti sur plusieurs lignes, chacune portant le même numéro de compte.

Une transaction Bitcoin dépense un ou plusieurs de ces résultats et crée ainsi un ou plusieurs nouveaux résultats. C'est exactement comme une transaction de base de données qui supprime une ou plusieurs versions de ligne et crée ainsi une ou plusieurs nouvelles lignes (rappelez-vous que dans MVCC, il n'existe pas de modification d'une ligne en place). La blockchain Bitcoin garantit qu’un seul résultat ne peut pas être dépensé pour plus d’une transaction. Cela équivaut à garantir qu'une version à une seule ligne ne peut pas être supprimée par plus d'une transaction de base de données.

Avant de nous laisser emporter, je ne prétends pas que les blockchains constituent une excellente technologie à usage général pour la synchronisation de bases de données distribuées dans un environnement totalement fiable. Il existe de nombreuses autres technologies telles que Paxos, Raft et les Engagement en deux phases qui font très bien le travail. Mais je crois que les blockchains ont un point idéal, qui peut être caractérisé comme des applications où :

• Nous pouvons accepter un court délai entre le moment où une transaction est probablement acceptée et le moment où elle est définitivement acceptée. (Ce délai peut être une question de secondes plutôt que de 10 minutes comme dans le cas du Bitcoin.)
• Des transactions conflictuelles ne devraient jamais se produire si tout le monde est honnête et que leurs systèmes fonctionnent correctement.
• Chaque transaction ne modifie que quelques lignes simultanément (sinon nos transactions blockchain auront un nombre énorme d'entrées).
• La taille de chaque ligne de la base de données est assez petite (encore une fois, pour éviter que la taille de nos transactions blockchain n’explose).

Tous ces critères sont remplis par les candidatures financières. Le monde financier est déjà habitué aux délais (jusqu'à 3 jours !) entre la réalisation d'une transaction et son règlement final. En termes de prévention des conflits, elle a mis en place des contrats et des réglementations pour détecter la fraude, et les conséquences peuvent être graves. Et la quantité de données impliquées dans chaque transaction est assez faible – pensez à l’exemple du compte bancaire ci-dessus.

Jusqu’à présent, tout ce que j’ai démontré, c’est que les blockchains constituent un autre mécanisme de synchronisation pour les bases de données distribuées. Grand wow. Les choses ne deviennent vraiment intéressantes que lorsque l’on considère les fonctionnalités supplémentaires fournies par les blockchains.

Blockchains au-delà de MVCC

Une transaction Bitcoin fait bien plus que simplement pointer vers certains résultats de transactions précédents et en créer de nouveaux à leur place. Même la transaction Bitcoin la plus simple répond à deux objectifs supplémentaires.

Premièrement, les règles concernant les transactions valides contiennent une partie de la logique d'application de notre base de données de comptes. Rappelons que la quantité totale de Bitcoin dans les entrées d'une transaction doit couvrir la quantité totale dans les sorties. Traduite dans la logique d'application de base de données, il s'agit d'une règle qui stipule que les transactions de base de données (à l'exception des coinbases) ne sont pas autorisées à augmenter la quantité totale de bitcoins dans la base de données. Ce type de contrainte va au-delà de la base de données classique procédures stockées car il ne peut en aucun cas être contourné.

Deuxièmement, rappelez-vous que chaque sortie de transaction Bitcoin code les conditions dans lesquelles elle peut être dépensée. Pour les sorties Bitcoin régulières, cette condition est basée sur la cryptographie à clé publique. Une adresse publique est intégrée dans le « script » de sortie afin qu'elle ne puisse être utilisée qu'en utilisant la clé privée correspondant à cette adresse publique. Si nous considérons cette sortie comme une ligne de base de données, nous avons une base de données avec des autorisations par ligne basées sur la cryptographie à clé publique. De plus, chaque transaction présente une preuve publiquement vérifiable que son (ses) créateur(s) avait le droit de supprimer/modifier ses lignes précédentes. Ceci (je crois) est une véritable nouveauté dans la technologie des bases de données.

Et encore une fois, il se trouve que ces deux fonctionnalités sont incroyablement utiles pour les applications financières. Nous apprécions le fait que notre base de données garantit, au niveau le plus bas possible, que l'argent ne peut pas être créé à partir de rien. Et nous aimons avoir une piste d'audit incontestable démontrant que chaque transaction a été autorisée par le détenteur des fonds qu'elle a déplacés. Comme discuté en détail ici, nous pouvons également aimer effectuer des transactions d'échange atomiques peer-to-peer sécurisées (livraison contre paiement en langage financier), sans même connaître l'identité de notre contrepartie.

Alors, où est le jeton ?

Bien entendu, rien de tout cela n’est une coïncidence, car le bitcoin lui-même est une magnifique application financière peer-to-peer. Pourtant, aucune des caractéristiques ci-dessus d’une blockchain ne dépend du jeton. Si nous modifions notre schéma de « base de données » afin que chaque ligne puisse représenter plusieurs actifs, plutôt que la devise native de la blockchain, nous pouvons alors nous débarrasser entièrement de cette devise. Cela nous laisse avec une blockchain comme moyen d'atteindre le consensus et la sécurité dans une application financière peer-to-peer pour n'importe quelle classe d'actifs.

Une seule petite question cependant : Qui fait le minage pour générer ce consensus ? Dans Bitcoin, les mineurs anonymes doivent effectuer des calculs inutiles et coûteux, et sont incités à le faire par les récompenses de bloc (et les frais de transaction) libellées dans la devise ou le jeton natif de la blockchain. Avons-nous d’autres options ?

Il s’avère que c’est le cas. Nous pouvons avoir une liste fermée de mineurs autorisés, qui s'identifient en signant les blocs qu'ils créent. Règles sur le consensus distribué (ou « diversité minière » comme nous l'appelons en anglais) MultiChain) offrent une manière différente d’empêcher le contrôle minoritaire de la blockchain, tant que vous pouvez accepter que les mineurs soient pré-approuvés. Bien sûr, pour Bitcoin, cela n’est pas acceptable, car l’objectif est en partie de permettre le minage anonyme, il n’y a donc aucun moyen de censurer les transactions de manière centralisée. Mais si, par exemple, nous avions un système financier hautement réglementé, dans lequel le modèle du bitcoin était inapplicable, peut-être pourrions-nous finalement accepter une liste pré-approuvée de mineurs ? Si nous en avions assez, si nous les répartissions suffisamment entre les institutions et si nous avions des contrats légaux avec chacune d’elles, sont-ils vraiment susceptibles de se regrouper et de saper le réseau dont ils dépendent, alors que cela les mènerait en prison ?

Épilogue

J'espère avoir démontré que les blockchains sans tokens ont des applications utiles, même si celles-ci sont très différentes de la blockchain Bitcoin. Néanmoins une question demeure :

Ces systèmes de registres partagés autorisés et sans jetons méritent-ils vraiment le nom de « blockchain » ?

La réponse courte est : qui s’en soucie ? Cela vaut rarement la peine de discuter du sens des mots, car il y a pas de bonne réponse.

Mais pour aller un peu plus loin, disons que j’accepte le principe selon lequel la blockchain Bitcoin est l’archétype de la blockchain. Dans ce cas, ce que nous devrions vraiment nous demander, c'est :

Ces registres partagés sont-ils suffisamment similaires au bitcoin pour mériter le nom de « blockchain » ?

Mon point de vue personnel ici est Oui. Parce qu’ils partagent un grand nombre de similitudes techniques, même s’ils diffèrent par le modèle d’autorisations et les incitations économiques. Et surtout, parce qu'ils génèrent tous deux un consensus dans une base de données distribuée via un chaîne de blocs.

Merci d'avoir lu.

Vous pouvez Suivez-moi sur twitter ici. Voir également: Livraison contre paiement sur une blockchain.

Voici quelques autres articles qui valent la peine d'être lus sur ce sujet par Piotr Piasecki et les Creuser Campbell.