Oui, vous pourriez avoir besoin d'une blockchain

Balaji S. Srinivasan est l'ancien directeur technique de Coinbase, associé du conseil d'administration d'Andreessen Horowitz et membre du conseil consultatif de CoinDesk.

L'article suivant a été initialement publié dans Consensus Magazine, distribué exclusivement aux participants de l'événement Consensus 2019 de CoinDesk.

Il existe un certain type de développeur qui affirme que les blockchains ne sont queterrible Bases de données. Comme le dit le récit, pourquoi ne pas simplement utiliser PostgreSQL pour votre application ? C'est une solution mature, robuste et performante. Comparées aux bases de données relationnelles, les sceptiques affirment que les blockchains ne sont que des bases de données lentes, lourdes et coûteuses, T évolutivité.

Bien que certaines critiques de cette critique soient déjà présentes (1,2), je proposerais une simple réfutation en une phrase : les blockchains publiques sont utiles pour stocker un état partagé, en particulier lorsque cet état partagé représente des données précieuses que les utilisateurs souhaitent exporter/importer sans erreur, comme leur argent.

Le problème d'exportation/importation de données

Jetez un œil aux diagrammes de nuages pourAmazon Web Services,Microsoft Azure, ou Google CloudIl existe des icônes pour les équilibreurs de charge, les transcodeurs, les files d'attente et les fonctions lambda.

Il existe des icônes pour les VPC et tous les types de bases de données sous le THU, y compris les plus récentes blockchain géréeservices (qui sont distincts des blockchains publiques, bien que potentiellement utiles dans certaines circonstances).

Ce pour quoi il n'y a T d' ICON , c'est l'état partagé entre les comptes. Autrement dit, ces diagrammes en nuage supposent implicitement qu'une seule entité et ses employés (à savoir, l'entité ayant accès à compte racine cloud) est le ONE à établir le schéma d'architecture et à lire et écrire dans l'application qu'il sous-tend. Plus précisément, ces schémas supposent généralement la présence d'un seul acteur économique, à savoir l'entité qui paie les factures cloud.*

Mais si l'on visualise les diagrammes de cloud non pas pour un , mais ONE cent acteurs économiques d'entreprise à la fois, des questions immédiates se posent. Ces acteurs peuvent-ils interagir ? Leurs utilisateurs peuvent-ils extraire leurs données et les intégrer à d'autres applications ? Et puisque les utilisateurs sont eux-mêmes des acteurs économiques, si ces données représentent une valeur monétaire, peuvent-ils être sûrs que leurs données n'ont T été modifiées lors de ces exportations et importations ?

Voilà le type de questions qui se posent lorsque l'on considère l'exportation et l'importation de données depuis l'application de chaque entité comme une exigence primordiale. Et (sauf exceptions que nous aborderons plus loin), en général, la réponse à ces questions est aujourd'hui négative.

Non, les différentes applications ne disposent généralement T de logiciels interopérables, ne permettent pas à leurs utilisateurs d'exporter/importer facilement leurs données sous une forme standard, ou ne donnent pas aux utilisateurs la certitude que leurs données n'ont T été intentionnellement altérées ou corrompues par inadvertance pendant toute l'exportation et l'importation.

La raison en est une question d'incitations. La plupart des grands services Internet n'offrent aucun avantage financier à permettre aux utilisateurs d'exporter leurs données, et encore moins à leurs concurrents de les importer rapidement. Certains appellent cela laportabilité des donnéesproblème, appelons-le le problème d’exportation/importation de données pour concentrer l’attention sur les mécanismes spécifiques d’exportation et d’importation.

Approches actuelles du problème d'exportation/importation de données

Même si les incitations financières pour une solution globale au problème d'exportation/importation de données ne sont T encore disponibles, des mécanismes ont été créés pour de nombreux cas particuliers importants. Ces mécanismes incluent les API, les exportations JSON/PDF/CSV, les fichiers MBOX et (dans le contexte bancaire) le protocole SFTP.

Examinons-les tour à tour pour comprendre l’état actuel des choses.

• Apis. ONEune des méthodes les plus courantes pour exporter/importer des données est l'utilisation d'interfaces de programmation d'applications (API). Certaines entreprises vous permettent d'extraire certaines de vos données ou d'en écrire sur votre compte. Mais cela a un coût. Premièrement, leur format de données interne est généralement propriétaire et non standard. Deuxièmement, les API ne sont parfois pas essentielles à leur activité CORE et peuvent être éteintTroisièmement, parfois les API sont au cœur de leur activité CORE et le prix peut être augmenté de façon spectaculaireEn général, si vous lisez ou écrivez sur une API hébergée, vous êtes à la merci du fournisseur d'API. C'est ce que l'on appelle le risque de plateforme, et être dé-plateformisé sans ménagement ablessé beaucoup un démarrer.
• JSON.Une autre solution connexe consiste à permettre aux utilisateurs ou aux scripts de télécharger des fichiers JSON, ou de les lire/écrire dans les API mentionnées ci-dessus. Cela convient, mais JSON est très libre et peut décrire pratiquement n'importe quoi. Par exemple, FacebookAPI graphiqueet LinkedInAPI RESTtraitent de choses similaires mais renvoient des résultats JSON très différents.
• PDF.Une autre solution, très partielle, consiste à permettre aux utilisateurs d'exporter un PDF. Cela fonctionne pour les documents, car le PDF est unnorme ouverte Il peut être lu par d'autres applications comme Aperçu, Adobe Acrobat, Google Drive, Dropbox, etc. Cependant, un PDF est conçu comme un produit fini, destiné à être lu par un Human. Il n'est pas destiné à être utilisé comme entrée pour une application autre qu'un lecteur PDF.
• CSV.Le modeste fichier de valeurs séparées par des virgules se rapproche de ce que nous recherchons comme solution générale au problème d'import/export de données. Contrairement au backend d'une API propriétaire, le CSV est unformat standarddécrit parRFC 4180Contrairement à JSON, qui peut représenter presque tout, un CSV représente généralement un simple tableau. Et contrairement à un PDF, un CSV peut généralement être modifié localement par un utilisateur via une feuille de calcul ou utilisé comme entrée lisible par machine dans une application locale ou cloud. La plupart des types de données peuvent être représentés dans une base de données relationnelle, et les bases de données relationnelles peuvent généralement êtreexporté En tant qu'ensemble de fichiers CSV potentiellement gigantesques, il est également assez général. Cependant, les CSV présentent plusieurs inconvénients. Premièrement, contrairement à une API propriétaire, ils ne sont T hébergés. Autrement dit, il n'existe pas d'emplacement canonique unique pour lire ou écrire un CSV représentant, par exemple, un enregistrement de transactions ou une table de métadonnées cartographiques. Deuxièmement, les CSV ne sont T inviolables. Si un utilisateur exporte un enregistrement de transactions du service A, le modifie, puis le réimporte vers le service B, le second service n'en sera pas informé. Troisièmement, les CSV ne disposent T de contrôles d'intégrité intégrés pour se protéger des erreurs involontaires. Par exemple, les colonnes d'un CSV ne contiennent T d'informations de type explicites, ce qui signifie qu'une colonne contenant les mois de l'année de 1 à 12 pourrait voir son type automatiquement converti en un entier simple lors de l'importation, entraînant ainsi une erreur. confusion.
• MBOX.Bien que moins connu que le CSV, leFormat MBOXLa représentation de collections de messages électroniques est ce qui se rapproche le plus d'une structure de données standardisée, conçue pour l'importation et l'exportation entre les principales plateformes et les applications indépendantes. En effet, il existepapiers Proposer l'utilisation de MBOX dans des contextes autres que le courrier électronique. Alors que le format CSV représente des données tabulaires, MBOX représente un type de données structurées en logarithme. Il s'agit essentiellement d'un seul et même fichier texte volumineux contenant des messages électroniques classés par ordre chronologique, mais il peut également représenter des données. images/pièces jointes via MIME. Comme CSV, les fichiers MBOX sont un norme ouverteet peut être exporté, modifié localement et réimporté. De plus, comme le CSV, le MBOX présente l'inconvénient de ne pas disposer d'un hôte canonique ni d'un contrôle d'intégrité des données intrinsèque.
• SFTP. Avant de poursuivre, il existe un autre mécanisme d'exportation/importation de données qui mérite d'être mentionné : le protocole de transfert de fichiers sécurisé (SFTP). Bien que vénérable, il s'agit en réalité du moyen par lequel les individus FORTH des paiements ACH. En résumé, les institutions financières utilisent les serveurs SFTP pour collecter les données des transactions électroniques. fichiers spécialement formatéset le transmettre à la Réserve fédérale chaque jour pour synchroniser les débits et crédits ACH entre eux (voirici,ici,ici, et ici).

Chacun de ces mécanismes est largement utilisé. Mais ils ne suffisent pas à garantir l'importation et l'exportation inviolables de données précieuses entre acteurs économiques arbitraires, qu'il s'agisse d'entreprises, d'utilisateurs individuels ou de scripts sans interface utilisateur. Pour cela, nous avons besoin de blockchains publiques.

Les blockchains publiques permettent un état partagé en favorisant l'interopérabilité. Elles convertissent de nombreux types de problèmes d'import/export de données en une classe générale de problèmes d'état partagé. Elles y parviennent en partie en intégrant bon nombre des meilleures fonctionnalités des mécanismes décrits ci-dessus.

• Les blockchains publiques offrent des méthodes canoniques d'accès en lecture/écriture, à l'instar d'une API d'entreprise hébergée, mais sans les mêmes risques liés à la plateforme. Aucun acteur économique ne peut, à lui seul, interrompre ou refuser le service aux clients d'une blockchain publique décentralisée comme Bitcoin ou Ethereum.
• Ils permettent également aux utilisateurs individuels d'exporter des données critiques vers leur ordinateur local ou vers une nouvelle application comme JSON/CSV/ MBOX (soit en envoyant des fonds, soit en exportant des clés privées) tout en offrant des garanties cryptographiques d'intégrité des données.
• Elles permettent à des acteurs économiques arbitraires (qu'il s'agisse d'entreprises, d'utilisateurs individuels ou de programmes) d'interagir de manière transparente. Chaque acteur économique qui lit une blockchain publique obtient le même résultat, et tout acteur économique disposant de fonds suffisants peut écrire sur une blockchain publique de la même manière. Aucune création de compte n'est nécessaire et aucun acteur ne peut être bloqué en lecture/écriture.
• Et peut-être plus important encore, les blockchains publiques offrent des incitations financières pour l’interopérabilité et l’intégrité des données.

Ce dernier point mérite d'être développé. Une blockchain publique comme Bitcoin ou Ethereum enregistre généralement les transferts d'éléments de valeur monétaire. Il peut s'agir de la Cryptomonnaie intrinsèque de la chaîne, d'un jeton émis au sommet de la chaîne ou d'un autre type d'actif numérique.

Parce que les données associées à une blockchain publique représentent une valeur monétaire, elles offrent enfin l'incitation financière à l'interopérabilité. Après tout, toute application web ou mobile souhaitant recevoir (par exemple) des BTC doit respecter les conventions de la blockchain Bitcoin . En effet, les développeurs d'applications n'auraient pas d'autre choix, car Bitcoin, par conception, possède une chaîne de preuve de travail unique et canonique, la plus longue, avec validation cryptographique de chaque bloc de cette chaîne.

Voilà donc l’incitation financière à importer.

Quant à l'incitation à l'exportation, notamment en matière d'argent, les utilisateurs exigent une exportation en toute fidélité et très rapide. Il ne s'agit pas de leurs vieilles photos de chat, qu'ils pourraient facilement perdre à cause d'un désagrément ou de problèmes techniques. Il s'agit de leur argent, de leurs Bitcoin, de leurs Cryptomonnaie. Toute application qui les détient doit les rendre disponibles à l'exportation lorsqu'ils souhaitent les retirer, que ce soit en prenant en charge la fonctionnalité d'envoi, en proposant des sauvegardes de clés privées, ou les deux. Dans le cas contraire, l'application a peu de chances de recevoir des dépôts.

Voilà donc l'incitation financière à l'exportation. Ainsi, une blockchain publique incite économiquement chaque acteur économique interagissant avec elle à utiliser le même format d'import/export que tous les autres acteurs, qu'il s'agisse d'une entreprise, d'un utilisateur ou d'un programme. Autrement dit, les blockchains publiques constituent l'étape suivante après l'open source, car elles fournissent des données ouvertes. N'importe qui peut coder son propre explorateur de blocs en lisant une blockchain publique, et chacun peut créer son propre portefeuille capable d'écrire sur une blockchain publique.

C'est une véritable avancée. Nous disposons désormais d'un moyen fiable d'encourager l'utilisation de l'état partagé, permettant simultanément à des millions de personnes et d'entreprises d'accéder en lecture (et à des milliers d'accéder en écriture) au même stockage de données, tout en appliquant une norme commune et en maintenant une confiance élevée dans l'intégrité des données.

C'est très différent du statu quo. En général, on ne partage T le mot de passe root de sa base de données sur Internet, car une base de données qui autorise n'importe qui à y accéder en lecture/écriture est généralement corrompue. Les blockchains publiques résolvent ce problème grâce à la cryptographie plutôt qu'aux autorisations, augmentant ainsi considérablement le nombre d'utilisateurs simultanés.

Il est vrai qu'aujourd'hui, les blockchains publiques sont généralement axées sur les applications monétaires et financières, où l'ensemble de données sous-jacent représente un historique de transactions en ajout uniquement, avec des enregistrements immuables. Cela limite leur généralité, car elles permettent de résoudre les différentes versions du problème d'importation/exportation de données. Cependant, des versions blockchain publiques d'outils comme OpenStreetMaps, Wikipédia et Twitter, ainsi que de systèmes comme Filecoin/IPFS, sont en cours de développement. Ces versions ne représenteraient T uniquement des enregistrements de transactions financières, pour lesquels l'immuabilité est requise, mais pourraient également représenter d'autres types de données (comme des entrées de cartes ou d'encyclopédies) régulièrement mises à jour.

Bien conçus, ces nouveaux types de systèmes basés sur la blockchain publique pourraient permettre à tout acteur économique disposant de fonds suffisants et/ou d'identifiants cryptographiques non seulement de lire et d'écrire, mais aussi de modifier ses propres enregistrements tout en préservant l'intégrité des données. Grâce à cette capacité, ONE est possible T' ajouter une couche SQL à une blockchain publique pour exploiter l'état partagé qu'elle offre, à l'instar d'une base de données relationnelle traditionnelle. Il en résulte un nouveau type de base de données sans propriétaire privilégié, où les sept milliards d'humains de la planète (et leurs scripts !) sont des utilisateurs autorisés, et dans laquelle toute entité disposant de fonds suffisants peut écrire.

Ce jour n'est T encore arrivé. Il reste à voir jusqu'où nous pouvons pousser les cas d'usage des chaînes publiques. Et les défis de mise à l'échelle sont nombreux. Mais il est clair que, si les blockchains publiques constituent bel et bien un nouveau type de base de données, elles offrent quelque chose de bien différent de ce qu'offre une base de données traditionnelle.

* La ONE exception est la fonctionnalité « Payer le demandeur » proposée par Amazon et d'autres services cloud. Cette fonctionnalité intéressante permet à quelqu'un de payer pour écrire dans votre bucket S3. Cependant, elle est soumise à autorisation : chaque auteur potentiel doit ouvrir un compte AWS et le propriétaire du bucket doit accepter de les laisser écrire dans son bucket, ce qui permet de conserver un propriétaire unique.

Image de base de données via Shutterstock