Rejoignez-Nous sur

Dégroupage des vecteurs de la centralisation dans Web3

Screen Shot 2019 07 24 at 11.24.19 AM

News

Dégroupage des vecteurs de la centralisation dans Web3

Il y a un an, j'ai illustré le Pile Web3 comme je l'ai compris à l'époque. Plus récemment, j’ai publié Multicoin’s crypto méga thèses, détaillant la thèse d’investissement pour Web3. Comme je l'ai souligné, l'une des principales conséquences de Web3 est que la propriété des données et la logique d'application seront dissociées.

Dans cet article, j’expliquerai les problèmes spécifiques inhérents à ce dégroupage et la manière dont nous envisageons d’investir dans la pile Web3.

Où sont les bases de données et les données?

Pour des raisons pratiques, la grande majorité des applications modernes peuvent être considérées comme une UX au-dessus d'une base de données. À quelques exceptions près (par exemple, la diffusion vidéo en continu et les jeux vidéo), cela est généralement vrai. Pratiquement tous les principaux services consommateurs – Facebook, Reddit, Evernote, Twitter, Google Docs, Gmail, iMessage, etc. – peuvent être simplifiés en un UX au-dessus d’une base de données.

Dans le modèle Web2, les fournisseurs d’application stockent et gèrent les données des utilisateurs de manière à ce que ceux-ci n’aient pas à le faire. De plus, les fournisseurs d’applications Web2 sont toujours en ligne car ils utilisent des serveurs 24h / 24, alors que les utilisateurs se connectent souvent hors ligne (métros, faible connectivité, problèmes de batterie, etc.). Dans le modèle Web3, il n'y a pas de fournisseur d'application centralisé, il est donc nécessaire de changer tout le paradigme de la propriété des données.

Cela soulève quelques questions:

  1. Où un utilisateur – appelons-t-il Alice – stocke-t-il ses données (en supposant qu’il ne gère pas son propre serveur)?
  2. Et comment l'expéditeur du contenu envoie-t-il du contenu à Alice si Alice est hors ligne?

Naturellement, la réponse doit être la suivante: stockez le contenu dans un endroit toujours en ligne et accessible, et assurez-vous que, lorsque Alice reviendra en ligne, Alice sait où trouver le contenu qui lui est destiné. Ce paradigme englobe les applications P2P telles que la messagerie et les applications de base de données traditionnelles telles que les journaux, les médias sociaux et les applications de prise de notes.

Pour exécuter cela, il existe quelques défis mécaniques:

  1. Quelqu'un qui n'est pas Alice a besoin de savoir pour stocker le contenu et un index de ce contenu afin qu'Alice puisse le rechercher et le télécharger plus tard.
  2. Alice doit savoir où trouver cet index.
  3. Avec cet index, Alice doit trouver et télécharger les données sous-jacentes.
  4. Celui qui stocke les données ne doit pas pouvoir lire le contenu (s'il est privé) ou le censurer.

En résolvant ces problèmes, la propriété des données et la logique d'application peuvent être dissociées, permettant ainsi à Web3 de prospérer.

Avant d’explorer comment les entrepreneurs Web3 modernes résolvent ces problèmes, il est utile d’examiner comment d’autres entreprises ont tenté de les résoudre par le passé.

Tentatives antérieures de décentralisation d'Internet

Il y a eu une poignée d’équipes, y compris, mais sans s'y limiter, Zeronet, Freenet, et Ragots– qui ont essayé, comme ils le diraient, de "décentraliser Internet". Ils ont essayé de le faire avant l'ère de la cryptographie moderne telle que nous la connaissons aujourd'hui. La plupart de ces efforts ont été concentrés sur la prise en charge de cas d’utilisation restreints; par exemple, la messagerie résistante à la censure et les babillards électroniques destinés aux utilisateurs de pays dotés de régimes autoritaires.

Si vous êtes curieux, je vous recommande d’essayer chacun de ces systèmes. Vous constaterez que les UX laissent beaucoup à désirer. Bien qu'il existe de nombreux problèmes UX avec ces systèmes, le plus gros problème est de loin la vitesse. Tout est douloureusement lent.

Ce qui donne? Pourquoi sont-ils si lents?

Parce qu’ils sont tous logiquement décentralisés.

Ces systèmes ont adopté certaines variantes de l'architecture suivante. Je vais décrire leurs architectures dans le contexte d’une application de messagerie P2P chiffrée:

  1. Ces systèmes reposent sur l’idée que si quelqu'un envoie un message à Alice alors qu’elle est hors ligne, il le transmettra à Bob à la place et ce dernier stockera le message pour le compte d’Alice.

  2. Quand Alice reviendra en ligne, elle demandera à Bob si quelque chose lui a manqué pendant son absence (index des messages).

  3. Malheureusement, Alice n'a aucune garantie que 1) Bob est en ligne maintenant, 2) qu'il était en ligne aussi longtemps qu'il était hors ligne, et 3) que Bob disposera de l'index complet des messages qu'elle aurait manqués pendant son absence. Pour remédier à cela, Bob peut demander à ses pairs s'ils sont au courant de messages adressés à Alice. Cependant, ces pairs peuvent être ou ont également été hors ligne et ils peuvent également disposer d'informations incomplètes.

    Dans ce paradigme, il est tout simplement impossible de garantir la livraison des messages car il est difficile de savoir où les messages doivent être remis et qui doit stocker l’index des messages. Cela crée des problèmes complexes lorsque le destinataire revient en ligne car il ne sait pas où trouver la liste des messages qui lui sont adressés ni la référence des messages de données.

    Scuttlebutt, qui se concentre sur la construction d'un réseau social P2P, tente de résoudre ce problème en adoptant un système d'amis à double opt-in de type Facebook. C'est-à-dire qu'une fois qu'Alice et Bob sont devenus amis, ils partagent leurs listes d'amis afin que Bob puisse indexer et stocker le contenu publié par les amis d'Alice pour le compte d'Alice. Cela nécessite qu'Alice informe tous ses amis que Bob est son mandataire et inversement. Ensuite, lorsque les amis d’Alice publient une mise à jour alors qu’Alice est hors ligne, ils peuvent envoyer cette mise à jour à Bob, qui peut l’héberger pour Alice.

    Zeronet et Freenet, qui sont plus généralisés que les réseaux sociaux P2P, utilisent un modèle similaire, sauf qu’il n’existe pas de modèle d’options à double option. Cela ajoute quelques complexités au système et rend les choses encore plus lentes. Contrairement au modèle Scuttlebutt, dans lequel les amis acceptent de s’entraider pour des chemins d’information définis, les utilisateurs de Freenet et de Zeronet doivent envoyer une requête aléatoire à d’autres utilisateurs et leur demander quelles informations ils connaissent. C'est la raison pour laquelle ces systèmes sont si lents.

  4. Disons qu’Alice rassemble enfin l’index de tout ce qui lui a manqué pendant son absence. En d’autres termes, elle sait que Carol lui a envoyé une photo et que Dave la stocke sur «dave.com/alicepic1.png». Si Dave est hors ligne, comment Alice peut-elle accéder à la photo?

Ces problèmes ne sont pas triviaux. Décentraliser Internet est difficile.

Centralisation logique et architecturale

La cause fondamentale de tous les problèmes décrits ci-dessus est l’absence de stockage et d’indexation centralisés de manière logique. Qu'est-ce qu'un stockage centralisé de manière logique? Pour répondre à cette question, il est utile de comprendre les trois vecteurs de la décentralisation dans les systèmes distribués:

  1. Architectural
    • le nombre d'ordinateurs dans le système
  2. Politique
    • le nombre de personnes pouvant exercer une influence sur le système
  3. Logique
    • le nombre d'interfaces par lesquelles des agents externes interagissent avec le système

Pour une explication plus robuste de ces concepts, je recommande cette rédaction par Vitalik Buterin.

Les monopoles Web2 ont résolu tous les problèmes décrits dans la section précédente, car ils reposent sur un stockage centralisé logique. C'est-à-dire que, lorsqu'Alice revient en ligne, elle demande simplement au service Web centralisé, qui gère le stockage centralisé, quels messages elle a manqués depuis sa dernière connexion en ligne. Le service Web interroge une base de données qu'il contrôle contenant tous les messages utilisateur et renvoie les messages corrects.

Le problème avec ce modèle est que ces systèmes Web2 regroupent toutes les formes de centralisation: ils sont centralisés de manière logique, centralisés sur le plan politique et (sauf à des fins de dimensionnement) centralisés sur le plan architectural.

Existe-t-il des systèmes de stockage logiquement centralisés, mais décentralisés sur les plans architectural et politique?

Heureusement, la réponse est un oui retentissant: système de fichiers interplanétaires (IPFS) pour le stockage basé sur contrat, et Arweave pour le stockage permanent (stockage contractuel: stockez X octets de données pour une période de temps avec des garanties de récupérabilité de Z. AWS, GCP, Azure, Filecoin, et Sia sont tous des systèmes de stockage contractuels).

Qu'est-ce que cela signifie exactement pour le système d'être centralisé logiquement, mais décentralisé sur le plan architectural et politique? La meilleure façon de comprendre cela est d'examiner comment un ordinateur récupère les fichiers de base d'un autre serveur sur le Web aujourd'hui (adressage basé sur l'emplacement), puis de le comparer à l'approche IPFS / Arweave (adressage basé sur le contenu).

Dans l'architecture Web2, si Alice souhaite télécharger une image depuis un serveur, Alice utilisera une URL ressemblant à l'adresse suivante: website.com/image.png. Que se passe-t-il exactement quand Alice essaie d'accéder à cette URL?

En utilisant DNS, Alice sait où trouver le serveur sur website.com et elle demandera au serveur l'image qu'il héberge sur son système de fichiers local à l'adresse “/image.png”. En supposant que le serveur souhaite coopérer, il vérifiera sa répertoire pour /image.png et renvoyez ce fichier s’il existe.

Notez la fragilité de ce système: si le fichier est déplacé, si le serveur est occupé ou si le serveur ne coopère pas pour une raison quelconque, la requête échouera.

C'est la base sur laquelle le Web est construit aujourd'hui.

Dans un système d'adressage basé sur le contenu tel que celui utilisé dans IPFS et Arweave, l'URL visitée par Alice ressemble à peu près à ceci: QmTkzDwWqPbnAh5YiV5VwcTLnGdwSNsNTn2aDxdXBFca7D.

Bien qu’il ne soit pas lisible par l’homme, il est généré de manière déterministe à partir du contenu dont il est dérivé. En d'autres termes, il n'y a qu'un seul élément de contenu dans l'univers qui, une fois haché, produira cette chaîne exacte. La magie d'IPFS et d'Arweave réside dans le fait qu'ils gèrent toute la complexité qui permet à un ordinateur de résoudre QmTkzDwW … dans cette page Web.

Capture d'écran 2019-07-24 à 11h24.19

(Si vous souhaitez en savoir plus sur le fonctionnement d’IPFS, cette Série en 6 parties est un excellent point de départ).

Le contenu des réseaux IPFS et Arweave est stocké sur de nombreuses machines. Indépendamment du nombre de machines sur lesquelles le contenu est stocké ou de l'emplacement de ces machines dans le monde, ces protocoles résolvent des adresses telles que QmTkzDwW …, quel que soit le lieu où le contenu est stocké.

C’est la magie de l’adressage basé sur le contenu. Il présente une interface logique unique – l'adresse basée sur le contenu – qui sera toujours résolue correctement quel que soit le lieu où les données sous-jacentes sont stockées sur un vaste réseau d'ordinateurs décentralisés sur les plans architectural et politique.

Parmi les quatre principaux défis techniques décrits au début de cet essai, l'adressage basé sur le contenu résout les problèmes n ° 1, n ° 3 et n ° 4 (stockage du contenu, mise à disposition du contenu pour le téléchargement et prévention de la non-divulgation d'informations confidentielles par l'hôte) . Mais qu'en est-il de la question n ° 2: savoir où chercher les données?

Indexage

Alors que IPFS et Arweave agissent en tant que systèmes de fichiers logiquement centralisés, mais architecturalement et politiquement décentralisés, ces systèmes ne sont pas des bases de données. C'est-à-dire qu'il n'y a aucun moyen de les interroger et de leur demander «montre-moi s'il te plaît tous les messages envoyés de Bob à Alice entre les dates X et Y».

Heureusement, il existe plusieurs façons de résoudre ce problème.

Une approche consiste à stocker directement l'index des messages sur des chaînes de blocs. Les blockchains sont eux-mêmes des bases de données logiquement centralisées mais décentralisées sur les plans architectural et politique. Utiliser un service décentralisé comme Le graphique ou un service centralisé comme dFuse, Alice peut interroger des index stockés sur des blockchains. La blockchain ne stocke pas les données sous-jacentes, mais plutôt un hachage des données. Ce hachage est simplement un pointeur sur le contenu stocké dans IPFS ou Arweave. De nos jours, Graph et dFuse sont tous deux en ligne et de nombreuses applications ont adopté ce modèle de stockage sur des chaînes de hachage pointant vers des données stockées dans des systèmes à contenu adressé.

Une deuxième approche consiste à exploiter Textile. Le textile a construit une technologie unique qu'ils appellent Les fils, qui agissent comme une base de données privée, cryptée et personnelle en plus d’IPFS. Cette base de données étant construite sur IPFS, elle est centralisée de manière logique mais décentralisée sur les plans architectural et politique. En tant que base de données logiquement centralisée, les expéditeurs et les destinataires savent où envoyer et lire des informations. De plus, le textile a récemment lancé Les cafés, permettant aux utilisateurs d’établir un serveur pour héberger leurs threads (plutôt que d’héberger localement des threads). La prochaine étape pour Textile consiste à créer une couche économique incitant les valideurs à héberger des cafés pour les autres utilisateurs, ce qui est analogue à la manière dont Filecoin est la couche économique pour IPFS.

Une troisième approche consiste à tirer parti OrbitDB. OrbitDB est similaire aux threads de Textile, à la différence qu’OrbitDB est conçu principalement pour les données publiques (par exemple, pour créer un compte Twitter décentralisé), alors que les fils de Textile intègrent de manière native le chiffrement et la gestion des clés pour les informations privées (par exemple, la messagerie P2P). Comme Textile, OrbitDB est disponible aujourd'hui et l'équipe d'OrbitDB travaille sur une couche économique au-dessus de la technologie sous-jacente.

Enfin, il existe plusieurs équipes telles que La fluence et Bluzelle qui construisent ce qui sont effectivement des bases de données traditionnelles qui fonctionnent dans des environnements sans autorisation avec les garanties BFT.

Nous sommes sceptiques quant à l’idée d’ajouter une couche BFT au-dessus des bases de données traditionnelles étant donné le travail effectué par les équipes de sous-traitance intelligentes pour résoudre le problème de la disponibilité des données à grande échelle, comme celui de Solana. Réplicateurs. Au lieu de cela, nous avons choisi d'investir dans des bases de données «crypto-natives» telles que Textile et dans la couche d'API de développeur sous la forme de The Graph et de dFuse.

Avec les protocoles et les services décrits ci-dessus – IPFS, Filecoin, Arweave, The Graph, dFuse, Textile et OrbitDB – il existe un chemin clair permettant à Web3 de se concrétiser. Tous ces services existent aujourd'hui, même s'ils ne sont pas encore prêts pour la production et à l'échelle Web, avec une cryptoéconomie éprouvée. Néanmoins, il existe des solutions connues au problème le plus important – l'affichage d'une interface unique centralement logique pour les systèmes décentralisés sur le plan politique et architectural.

Est-ce qu'il reste quelque chose?

Logique de niveau supérieur

Maintenant que nous avons des solutions pour le stockage, l'indexation et la récupération centralisés sur le plan logique mais sur le plan architectural, nous pouvons nous permettre de penser à une logique de niveau supérieur. Quelques exemples:

  1. Comment Alice gère-t-elle plusieurs identités? Par exemple, Alice peut ne pas vouloir utiliser la même clé publique sur Facebook / Google / Snapchat / Reddit. Et si elle souhaite gérer ces identités dans une seule interface sans les relier publiquement?
  2. Étant donné qu'Alice souhaite envoyer des informations privées à Bob mais les stocker sur IPFS ou Arweave – qui sont par définition des systèmes publics -, ils doivent exploiter secret parfait avant (PFS) poignées de main. Comment configurent-ils PFS de manière asynchrone et gèrent toutes les clés associées?
  3. Étant donné que les schémas de chiffrement traditionnels ne sont conçus que par deux parties, comment le système peut-il prendre en charge les communications privées de grands groupes de personnes, tels que les forums de discussion ou les grands groupes de discussion?
  4. Comment le système active-t-il les modèles UX courants tels que la découverte de groupe, la récupération de données utilisateur, la suppression de contenu, etc.?

Bien que ces défis techniques soient distincts, je les classe globalement comme des problèmes de «logique de niveau supérieur».

Les fils de textile répondent précisément à ce type de problèmes. À bien des égards, on peut considérer Textile comme étant iCloud pour IPFS. Bien que cette analogie ne soit pas parfaite, elle fonctionne généralement: de la même manière qu'iCloud résume la synchronisation inter-appareils et la sauvegarde des données pour les applications (offrant ainsi une meilleure expérience utilisateur et développeur), Textile fournit tous les outils logiques d'ordre supérieur top of IPFS pour rendre le développement d'applications transparent pour les développeurs tout en assurant une synchronisation et une sauvegarde transparentes entre périphériques pour les utilisateurs sur IPFS.

Regarder vers l'avant

L’écosystème Web3 est incroyablement diversifié à de nombreux égards, en fonction du type de problèmes résolus, de l’emplacement des équipes, des modèles économiques qu’elles utilisent, etc. Que le Web3 la pile est en train de se réunir malgré le fait qu’il n’existe pas une seule entité logiquement centralisée coordonnant l’ensemble, c’est remarquable. Cependant, cela signifie également qu’il ya beaucoup d’entropie dans le système et qu’il est donc difficile de comprendre les thèmes de niveau supérieur. Dans cet essai, j'ai distillé cela comme suit:

Le plus grand défi de la transition de Web2 à Web3 est la transition de systèmes dans lesquels les trois vecteurs de la centralisation – logique, architectural et politique – ont été regroupés au profit de systèmes logiquement centralisés mais décentralisés sur les plans politique et architectural.

Si vous construisez une infrastructure ou des applications de base sur la pile Web3, veuillez atteindre ou DM moi sur Gazouillement. Nous cherchons à investir davantage dans Web3. Nous croyons que Web3 va être un changement de paradigme qui déverrouille des milliards dollars au cours de la prochaine décennie, et nous cherchons à aider les meilleurs entrepreneurs à mettre en place l’infrastructure Web3 fondamentale.

Grâce à Andrew Hill et Sam Williams pour fournir des commentaires sur cet essai.

Divulgations: Multicoin Capital a investi dans Solana, The Graph, Textile, Arweave et Dfuse. Multicoin Capital respecte une «politique de non-commerce» pour les actifs énumérés dans le présent rapport pendant 72 heures («période de non-échange») à compter de sa publication. Aucun dirigeant, administrateur ou employé ne doit acheter ou vendre l’un des actifs susmentionnés au cours de la période sans transaction.



Traduction de l’article de Kyle Samani : Article Original

BlockBlog

Le Meilleur de l'Actualité Blockchain Francophone & Internationale | News, Guides, Avis & Tutoriels pour s'informer et démarrer facilement avec Bitcoin, les Crypto-Monnaies et le Blockchain. En Savoir Plus sur L'Équipe BlockBlog

Commenter cet Article

Commenter cet Article

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Plus dans News

Les Plus Populaires

Acheter des Bitcoin

Acheter des Alt-Coins

Sécuriser vos Cryptos

Vêtements et Produits Dérivés

Top
fringilla risus. facilisis pulvinar mattis venenatis, Donec luctus eleifend diam leo tristique