IPFS, Système De Fichiers Interplanétaires – Introduction

ABSTRAIT

Le système de fichiers interplanétaires (IPFS) est un système de fichiers distribué pair-à-pair qui cherche à connecter tous les périphériques informatiques avec le même système de fichiers. À certains égards, IPFS est similaire au Web, mais IPFS peut être vu comme un seul essaim BitTorrent, échangeant des objets dans un même référentiel Git. En d’autres termes, IPFS fournit un modèle de stockage par blocs à haut débit, avec des liens hypertextes adressés au contenu. Cela forme un DAG Merkle généralisé, une structure de données sur laquelle on peut construire des systèmes de fichiers versionnés, des blockchains et même un Web permanent. IPFS combine une table de hachage distribuée, un échange de blocs motivés et un espace de noms auto-certifiant. IPFS n’a pas de point de défaillance unique et les nœuds n’ont pas besoin de se faire confiance.

Introduction

Il y a eu de nombreuses tentatives de construction d’un système de fichiers à distribution globale. Certains systèmes ont connu un succès considérable en la matière tandis que  d’autres ont complètement échoué. Parmi les tentatives académiques, AFS a largement réussi et est encore utilisé aujourd’hui. D’autres N’ont pas connu le même succès.

En dehors du monde académique, les systèmes les plus performants sont les applications de partage de fichiers peer-to-peer, principalement orientées vers les grands médias (audio et vidéo). Notamment, Napster, KaZaA et BitTorrent ont déployé de grands systèmes de distribution de fichiers supportant plus de 100 millions d’utilisateurs simultanés. Même aujourd’hui, BitTorrent maintient un déploiement massif où des dizaines de millions de nœuds changent tous les jours. Ces applications ont vu un plus grand nombre d’utilisateurs et de fichiers distribués que leurs homologues du système de fichiers académique. Cependant, les applications n’ont pas été conçues comme une infrastructure sur laquelle s’appuyer. Bien qu’il y ait eu des réaffectations réussies, aucun système de fichiers général n’a émergé offrant une distribution mondiale, à faible latence et décentralisée.

Peut-être est-ce parce qu’un système «assez bon» existe déjà pour la plupart des cas d’utilisation: HTTP. De loin, HTTP est le «système de fichiers distribué» le plus réussi jamais déployé. Couplé avec le navigateur, HTTP a eu un impact technique et social énorme. C’est devenu le moyen de facto de transmettre des fichiers sur Internet. Pourtant, il ne parvient pas à tirer parti des dizaines de techniques de distribution de fichiers brillantes inventées au cours des quinze dernières années. D’une perspective, l’évolution de l’infrastructure Web est quasiment impossible, compte tenu du nombre de contraintes de rétrocompatibilité et du nombre de parties fortes investies dans le modèle actuel. Mais d’un autre point de vue, de nouveaux protocoles ont vu le jour et ont été largement utilisés depuis l’émergence du protocole HTTP. Ce qui manque, c’est la mise à niveau de la conception: améliorer le Web HTTP actuel et introduire de nouvelles fonctionnalités sans dégrader l’expérience utilisateur.

L’industrie n’a plus besoin d’utiliser HTTP depuis longtemps parce que déplacer de petits fichiers est relativement bon marché, même pour les petites organisations avec beaucoup de trafic. Mais nous entrons dans une nouvelle ère de distribution de données avec de nouveaux défis: héberger et distribuer des ensembles de données petabytes (1 PB = 1000000000000000B = 1015bytes = 1000terabytes.); calcul et traitement d’énormes quantités de données à travers les organisations; gestion des flux multimédias haute définition à haut volume ou à la demande; le versionnement et la liaison de quantités de données hyper-massives; empêcher la disparition accidentelle de fichiers importants, et plus encore.

Beaucoup d’entre elles peuvent être réduites à “beaucoup de données, accessibles partout”. Pressées par des caractéristiques critiques et des problèmes de bande passante, nous avons déjà abandonné le HTTP pour différents protocoles de distribution de données. La prochaine étape consiste à les faire partie du Web lui-même.

Orthogonal à la distribution efficace des données, les systèmes de contrôle de version ont réussi à développer des flux importants de collaboration de données. Git, le système de contrôle de version de code source distribué, a développé de nombreux moyens utiles pour modéliser et mettre en œuvre des opérations de données distribuées.La chaîne d’outils Git offre une fonctionnalité de versionnage polyvalente qui manque cruellement aux systèmes de distribution de fichiers volumineux. De nouvelles solutions inspirées par Git émergent, telles que “Camlistore”, un système de stockage de fichiers personnel, et “Dat” une chaîne d’outils de collaboration de données et gestionnaire de paquets de données. Git a déjà influencé la conception de systèmes de fichiers distribués, car son modèle de données Merkle DAG orienté vers le contenu permet de puissantes stratégies de distribution de fichiers. Ce qui reste à explorer est de savoir comment cette structure de données peut influencer la conception de systèmes de fichiers orientés à haut débit, et comment il pourrait mettre à niveau le Web lui-même. Cet article présente l’IPFS, le nouveau système de fichiers contrôlés par la version P2P qui cherche à résoudre ces problèmes. L’IPFS synthétise les enseignements tirés de nombreux systèmes réussis. Une intégration ciblée sur l’interface produit un système plus performant que la somme de ses parties. Le principe central de l’IPFS est la modélisation de toutes les données dans le même Merkle DAG.

Contexte

Cette section passe en revue les propriétés importantes des systèmes P2P réussis, combinées par l’IPFS.

Tables de hachage distribuées

Les tables de hachage distribuées (DHT) sont largement utilisées pour coordonner et maintenir les métadonnées sur les systèmes P2P. Par exemple, “BitTorrent Mainline DHT” suit les ensembles de pairs faisant partie d’un essaim de torrent.

Kademlia DHT

Kademlia est une DHT populaire qui fournit:

1. Recherche efficace à travers des réseaux massifs: requêtes sur le contact moyen dlog2 (n) e noeuds. (par exemple, 20 bonds pour un réseau de 10 000 000 nœuds).
2. Faible surcharge de coordination: elle optimise le nombre de messages de contrôle qu’elle envoie aux autres nœuds.
3. Résistance à diverses attaques en préférant les noeuds ayant une vie longue.
4. Large utilisation dans les applications P2P, y compris Gnutella et BitTorrent, formant des réseaux de plus de 20 millions de nœuds.

Coral DSHT

Alors que certains systèmes de fichiers P2P stockent des blocs de données directement dans les DHT, cela «gaspille le stockage et la bande passante, car les données doivent être stockées sur des nœuds où ils ne sont pas nécessaires». Le DSHT Coral étend Kademlia de trois manières particulièrement importantes:

1. Kademlia stocke les valeurs dans les nœuds dont les identifiants sont “plus proches” (en utilisant la distance XOR) de la clé. Cela ne prend pas en compte la localité des données d’application, ignore les nœuds «éloignés» qui peuvent déjà avoir les données et force les nœuds «les plus proches» à les stocker, qu’ils en aient besoin ou non. Cela gaspille un stockage et une bande passante importants. Au lieu de cela, Coral stocke les adresses aux pairs qui peuvent fournir les blocs de données.
2. Coral détend l’API DHT de “get_value” (clé) à “get_any_values” (clé) (le “sloppy” dans DSHT). Cela fonctionne toujours puisque les utilisateurs de Coral n’ont besoin que d’un seul pair (de travail), pas de la liste complète. En retour, Coral peut distribuer uniquement des sous-ensembles de valeurs aux nœuds “les plus proches”, en évitant les points chauds (en surchargeant tous les nœuds les plus proches lorsqu’une clé devient populaire).
3. En outre, Coral organise une hiérarchie de DSHT distincts appelés clusters en fonction de la région et de la taille. Cela permet aux nœuds d’interroger d’abord les homologues dans leur région, “en recherchant des données proches sans interroger des nœuds éloignés” et en réduisant considérablement la latence des recherches.

S / Kademlia DHT

S / Kademlia étend Kademlia pour une protection optimale contre les attaques malveillantes,cela se fait de deux manières particulièrement importantes:

1. S / Kademlia fournit des méthodes pour sécuriser la génération NodeId et empêcher les attaques Sybill. elle nécessite des nœuds pour créer une paire de clés PKI, en dériver les identité et signer leurs messages les uns aux autres. Un schéma comprend une preuve de travail crypto puzzle (énigme) pour rendre la génération Sybills coûteux.
2. Les nœuds S / Kademlia recherchent des valeurs sur des chemins disjoints, afin de s’assurer que les nœuds honnêtes peuvent se connecter les uns aux autres en présence d’une grande partie des adversaires du réseau. S / Kademlia atteint un taux de réussite de 0,85 même avec une fraction contradictoire aussi grande que la moitié des nœuds.

Échanges de blocs – BitTorrent

BitTorrent est un système de partage de fichiers pair-à-pair largement réussi, qui réussit à coordonner des réseaux de pairs (essaims) non fiables pour coopérer dans la distribution de fichiers les uns aux autres. Les principales caractéristiques de BitTorrent et de son écosystème qui éclairent la conception de l’IPFS incluent:

1. Le protocole d’échange de données de BitTorrent utilise une stratégie “ tit-for-tat” qui récompense les nœuds qui contribuent les uns aux autres, et punit les nœuds qui ne font que drainer les ressources des autres.
2. Les pairs BitTorrent suivent la disponibilité des fichiers, en donnant la priorité à l’envoi des pièces les plus rares en premier. Cela enlève la charge des graines (seeds), ce qui rend les pairs non-graines capables de traiter les uns avec les autres.
3. Le tit-for-tat standard de BitTorrent est vulnérable à certaines stratégies de partage de bande passante exploitantes. PropShare est une stratégie différente d’attribution de bande passante homologue qui résiste mieux aux stratégies d’exploitation et améliore les performances des essaims.

Systèmes de contrôle de version – Git

Les systèmes de contrôle de version (Version Control Systems) fournissent des fonctionnalités permettant de modéliser des fichiers évoluant dans le temps et de distribuer efficacement différentes versions. Le système de contrôle de version populaire Git fournit un puissant modèle d’objet Merkle DAG qui capture les modifications apportées à un arbre de système de fichiers de manière distribuée.

1. Les objets immuables représentent les fichiers “blob”, les répertoires “tree” (arborescence) et les modifications “commit”.
2. Les objets sont adressés au contenu, par le hachage cryptographique de leur contenu.
3. Les liens vers d’autres objets sont intégrés, formant un Merkle DAG. Cela fournit de nombreuses propriétés d’intégrité et de flux de travail utiles.
4. La plupart des métadonnées de gestion de versions (branches, tags, etc.) sont simplement des références de pointeurs, et donc peu coûteuses à créer et à mettre à jour.
5. Les modifications de version mettent à jour uniquement les références ou ajoutent les objets.
6. La distribution des modifications de version à d’autres utilisateurs consiste simplement à transférer les objets et à mettre à jour les références distantes.

Systèmes de fichiers auto-certifiés – SFS

SFS (Self-Certified Filesystems) en français systèmes de fichiers auto-certifiés, a proposé des implémentations convaincantes à la fois des chaînes de confiance distribuées et des espaces de noms globaux partagés égalitaires. SFS a introduit une technique de construction de systèmes de fichiers auto-certifiés: adresser les systèmes de fichiers distants en utilisant le schéma suivant

/ sfs / <Emplacement>: <ID hôte>

où Location est l’adresse réseau du serveur, et:

HostID = hash (clé publique || Location

Ainsi, le nom d’un système de fichiers SFS certifie son serveur.)

L’utilisateur peut vérifier la clé publique proposée par le serveur, négocier un secret partagé et sécuriser tout le trafic. Toutes les instances SFS partagent un espace de noms global où l’allocation de noms est cryptographique et non gérée par un organisme centralisé.

Graphique acyclique dirigé par Merkle – construction similaire mais plus générale qu’un arbre de Merkle. Dédupliqué, n’a pas besoin d’être équilibré et les nœuds non-feuille contiennent des données.

Conception de L’IPFS

IPFS est un système de fichiers distribué qui synthétise les idées réussies à partir de systèmes P2P précédents, y compris DHT, BitTorrent, Git et SFS. La contribution de l’IPFS est de simplifier, d’évoluer et de connecter les techniques éprouvées dans un seul système cohésif, plus grand que la somme de ses parties. IPFS présente une nouvelle plate-forme pour l’écriture et le déploiement d’applications, et un nouveau système de distribution et de version de données trop volumineuses. L’IPFS pourrait même faire évoluer le web lui-même. IPFS est peer-to-peer; aucun noeud n’est privilégié. Les nœuds IPFS stockent les objets IPFS dans le stockage local. Les nœuds se connectent les uns aux autres et transfèrent des objets. Ces objets représentent des fichiers et d’autres structures de données. Le protocole IPFS est divisé en un tat de sous-protocoles responsables de différentes fonctionnalités:

1. Identités: gère la génération et la vérification de l’identité de noeud.
2. Réseau: Configurable, il gère les connexions aux autres pairs et utilise différents protocoles réseau sous-jacents.
3. Routage:  conserve les informations pour localiser les pairs et les objets spécifiques. Répond aux requêtes locales et distantes, par défaut à un DHT, mais est permutable.
4. Échange: un nouveau protocole d’échange de blocs (BitSwap) qui régit la distribution de blocs efficace. Modélisé comme un marché, incite faiblement la réplication de données. Stratégies d’échange Permutables
5. Les objets:  un DAG Merkle de contenu – adressaient des objets immuables avec des liens. Utilisé pour représenter des structures de données arbitraires, par ex. hiérarchies de fichiers et systèmes de communication.
6. Fichiers: Hiérarchie de système de fichiers versionnée inspirée par Git.
7. Nomination: Un système de nom mutable auto-certifiant.

Note: Dans le prochain article nous allons examiner avec détail chaque sous protocole.