Ceramic Network : les flux de données décentralisés du Web3

Ceramic Network est un protocole décentralisé et open-source qui permet de créer, d’héberger et de partager des flux de données. Le réseau est résistant à la censure et sans permission. Découvrons ensemble cette plateforme essentielle pour un Web3 vraiment décentralisé.

L’équipe de développement de Ceramic Network

3Box Labs est l’équipe centrale développant Ceramic Network, un protocole de données décentralisé. Leur communauté est forte de plus de 10 000 abonnés. 3Box Labs travaille principalement à distance (remote-first), et ses membres sont présents sur toute la planète. Tous les projets issus de 3Box Labs sont open source.

Les possibilités qu’offre Ceramic au Web3 sont nombreuses et variées. Nous ne serons donc pas surpris de voir que des géants de l’écosystème collaborent au projet : Avalanche, Ethereum, The Graph, Gnosis, Near, Moonbeam, Consensys ou MetaMask, pour ne citer qu’eux…

Présentation générale des fonctionnalités de Ceramic Network

Ceramic Network permet à chacun de stocker des informations sur le Web décentralisé, et d’y diffuser ces flux de données modifiables. Le protocole assure plusieurs fonctionnalités essentielles :

Flux modifiables

Ceramic Network est basé sur IPFS, et plus précisément IPLD – Interplanetary Linked Data, la couche d’IPFS dédiée aux structures de données. Il est possible d’y stocker, d’éditer et de mettre à jour des flux de données (streams) en continu. Ceramic Network permet également de personnaliser entièrement les structures de données de ces flux, en fonction des besoins de l’utilisateur.

IPFS – Interplanetary File System – est l’une des clés de voûte du Web décentralisé. Ce protocole pair-à-pair permet de stocker et de fournir des fichiers de façon décentralisée et efficiente. IPFS est ainsi résistant à la censure et à la falsification. Les fichiers sont identifiés et fragmentés sur tous les nœuds du réseau.

Identifiants persistants

Sur l’IPFS, les flux sont identifiés via les CID (content identifiers). Ces identifiants changent lorsque le contenu d’un flux est mis à jour. Sur Ceramic Network, les flux sont référencés par un identifiant persistant, le StreamID. 

Historique infalsifiable

L’historique complet des flux peut être audité. De la sorte, on peut savoir comment leur contenu a changé au cours du temps.

Disponibilité globale

Le réseau Ceramic est pair-à-pair, global, décentralisé et résistant à la censure : les flux qu’il héberge sont donc disponibles partout, tout le temps et pour tout le monde.

Synchronisation et partage

Grâce à des API standardisées, l’utilisateur peut envoyer des requêtes et souscrire à tous les flux du réseau. De même, l’état de chaque flux peut être synchronisé en permanence.

Composabilité

Les flux du réseau sont regroupés dans un même espace de noms. L’utilisateur peut ainsi référencer et agréger plusieurs flux à la fois. En utilisant un protocole comme The Graph, les flux de Ceramic peuvent être indexés pour requêter facilement des données sur le réseau. Ceramic étant une infrastructure ouverte, les utilisateurs comme les développeurs peuvent facilement réutiliser et partager les données à travers les applications.

Un espace de noms (namespace) est une structure conçue pour répertorier des ensembles de termes et éviter les homonymes. C’est notamment un atout pour la modularité d’un programme.

Fonctionnalités personnalisées

Grâce aux nœuds du réseau Ceramic, l’utilisateur peut entièrement personnaliser la façon dont il traite la mise à jour de ses flux. Ces fonctions s’appellent les “StreamTypes”. Elles permettent d’effectuer la mise à jour des streams de façon autonome. La gestion de leurs états est ainsi indépendante. Cependant, Ceramic propose des StreamTypes par défaut. Ils permettent à tout un chacun de créer son application sans avoir à coder son propre StreamType.

Authentification DID

Ceramic Network utilise le standard du W3C des identités décentralisées (DID) pour l’authentification et les échanges avec les flux. Mais il est tout à fait possible de personnaliser le mécanisme d’authentification. Les DID offrent l’avantage d’être contrôlables via un – ou plusieurs – portefeuilles Web3. L’utilisateur peut donc créer des identifiants cross-chain.

Scalabilité

Sur le réseau Ceramic, tous les flux maintiennent leur état de façon indépendante, et les nœuds du réseau exécutent les transactions de flux en parallèle. Cette approche, qui diffère de la plupart des blockchains, permet à Ceramic d’opérer avec la scalabilité nécessaire pour la diffusion de contenu décentralisé.

Archivage

Le contenu des flux est sauvegardé sur l’IPFS, Filecoin, ou sur des serveurs Amazon S3.

Les cas d’usage de Ceramic Network

Comme vous l’aurez compris, Ceramic est un protocole générique, pouvant être utilisé à des fins multiples. Chacun peut donc l’intégrer et l’adapter à son projet ou business.

Identité décentralisée

Ce concept a fait couler beaucoup d’encre ces dernières années. Ceramic utilise le DID Datastore, une implémentation de l’IDX (Identity Index). Ce protocole l’identité décentralisé fournit des API, permettant aux développeurs de l’intégrer facilement au sein de leurs applications. Le kit de développement en JavaScript d’IDX permet donc de créer des apps où l’utilisateur peut contrôler son identité et ses données, indépendamment desdites applications. Les développeurs n’ont pas à centraliser les données utilisateur. C’est ce qui permet également d’utiliser les portefeuilles de différentes blockchains et plateformes Web3.

L’intégration d’IDX offre de nombreuses possibilités, et elles vont au-delà de l’utilisation d’identifiants décentralisés (DID) : agrégation d’identités cross-chain, liaison des comptes sociaux à son identifiant, profils utilisateur, graphes sociaux, stockage de données, systèmes de réputation…

Bases de données décentralisées

Ceramic offre la possibilité d’utiliser des flux de données modifiables plutôt qu’une base de données locale. Cela concerne les données utilisateur, le contenu généré par l’utilisateur, son activité, son historique, les données d’application, l’état de l’application ou des cookies…

Fichiers évolutifs

Grâce au protocole Ceramic et à IPFS, il n’y a plus besoin d’utiliser un service externe pour auditer ou calculer les changements d’état d’un fichier. Il en va de même pour les droits d’accès. L’historique (log) des mises à jour des fichiers stockés via Ceramic est infalsifiable et immuable. De même, ces changements peuvent être rendus publics. Exemples : NFT éditables, documents JSON, métadonnées, identifiants vérifiables…

Réseaux sociaux décentralisés

Qu’il s’agisse de réseaux sociaux, de plateformes communautaires ou de forums de gouvernance, Ceramic permet de développer des applications décentralisées : l’utilisateur y sera donc propriétaire de son contenu.

Publications décentralisées

Imaginons une plateforme de blogging où le contenu des utilisateurs est publié et hébergé de façon décentralisée et résistante à la censure… Ceramic permet de créer ce type de média, où les données sont toujours accessibles, les droits d’auteur vérifiables, et le contenu mis à jour par son créateur en toute transparence.

Partage de données inter-applications

Différentes organisations et applications peuvent échanger des informations vérifiables en temps réel, sans passer par des serveurs centralisés et l’utilisation d’API multiples.

Architecture de Ceramic Network

Le protocole pair-à-pair de Ceramic s’appelle Libp2p. Il fait aussi partie de la pile technologique d’IPFS – ou encore de Polkadot. C’est avec Libp2p que Ceramic établit la découverte des données du réseau et que les nœuds communiquent.

Les différents réseaux de Ceramic sont donc constitués de nœuds, qui forment des ensembles indépendants, aux configurations spécifiques.

Il existe deux types de réseaux.

Les réseaux publics

Trois réseaux publics sont accessibles : le Mainnet, le Clay Testnet, et le Dev Unstable.

Le Mainnet

Le Mainnet est le réseau public principal. Les nœuds utilisent la librairie libp2p dédiée pour communiquer, ainsi qu’Ethereum pour l’horodatage. Plus précisément, les flux utilisent des ancres (anchor commit). Il s’agit d’un horodatage blockchain (via Ethereum – EIP 155), aussi appelé preuve de publication. Ces ancres sont immuables et sont nécessaires au bon fonctionnement du système, car le protocole Ceramic utilise des arbres orientés acycliques de Merkle (Merkle DAG), qui n’ont pas la notion du temps absolu, nécessaire pour le consensus au sein du réseau.

Le Mainnet est actuellement fonctionnel et tout un chacun peut envoyer des requêtes en utilisant le portail communautaire. Cependant, l’accès en écriture est pour l’instant réservé aux projets faisant partie de la liste d’attente – via l’early launch program (ELP). L’inscription à l’ELP est accessible ici. Bien entendu, le Mainnet sera à terme ouvert à tous.

Le Clay Testnet

Le Clay Testnet est utilisé pour le prototypage d’applications, leur développement et les tests. C’est également sur ce réseau que les core developers de Ceramic testent les mises à jour officielles du protocole. Bien entendu, la stabilité, la fiabilité et les performances du Testnet sont inférieures à celles du Mainnet. Il s’appuie sur les testnets d’Ethereum (Rinkeby et Ropsten) pour générer les horodatages utilisés par les ancres. Il est accessible à tous.

Le Dev unstable

Ce réseau de test est utilisé par les core developers de Ceramic pour tester les nouvelles fonctionnalités du protocole. Il est considéré hautement instable et expérimental. Il utilise également les réseaux de test Rinkeby et Ropsten.

Réseaux privés

Il est tout à fait possible d’exécuter le protocole Ceramic au sein d’un environnement local, complètement déconnecté des autres nœuds publics. Il faudra déployer sa blockchain Ethereum locale via Ganache pour l’horodatage.

Pile technologique de Ceramic Network

Ceramic fournit à n’importe quel type de structures de données stockées sur le Web3 un protocole public, open source et sans permission pour effectuer des calculs, des changements d’état, et établir un consensus. 

L’information open-source

Des millions d’applications nécessitent l’accès à des sources de données pour donner vie à Internet tel que nous le connaissons. Les systèmes d’identification, ou le stockage des données générées par les utilisateurs (ou les machines), est traditionnellement assuré par des serveurs, spécifiques à chaque application. Ces serveurs centralisés agissent comme un tiers de confiance pour garantir la propriété des données. Cette architecture a des défauts.

Il est difficile pour l’utilisateur d’accéder à ses données; quant aux développeurs, ces environnements en silo rendent leur tâche difficile. Et cela a une influence sur l’expérience utilisateur, qui en sera dégradée.

Avec l’open source puis le Web3, le modèle est devenu plus collaboratif. On recherche désormais une meilleure composabilité. L’objectif de Ceramic Network est d’appliquer ces principes du web ouvert aux informations elles-mêmes. Le contenu du Web3 devra être inter-applicatif et circuler librement à travers les frontières organisationnelles. Pour résumer, Ceramic est un réseau de calcul décentralisé, focalisé sur le contenu, flexible, scalable et modulaire. 

Opérer sur un contenu décentralisé

Grâce au Web3, il est désormais possible de stocker du contenu de manière décentralisée. Avec l’apparition d’IPFS, nous avons un système de fichiers universel pour classer et router ce contenu. Avec des réseaux comme Filecoin, Arweave ou Sia, nous avons un système de stockage persistant et résistant à la censure.

Pour l’instant, ces systèmes sont très fonctionnels quand il s’agit de contenu statique. Mais ils manquent de souplesse quant il s’agit de contrôle de version, de contrôle d’accès, ou de logique programmable. Ce sont des choses que les bases de données centralisées font déjà… Cependant, il nous faut leur équivalent sur le Web3, afin de créer des applications pleinement décentralisées.

Ceramic est dédié au contenu dynamique, aux flux de données (streams). Il permet de transformer des fichiers statiques en structures de données mutables, pouvant être programmées afin de se comporter de la manière désirée. Les états correspondants sont stockés au sein d’un réseau de nœuds.

Ainsi, Ceramic se base sur l’IPFS (et autres réseaux persistants) mais étend cet univers grâce à son réseau de calcul pour le contenu décentralisé.

Les flux de données (streams) de Ceramic Network

Ceramic s’inspire de divers systèmes de stream du Web2. Le modèle est le suivant : les événements sont traités au fur et à mesure de leur survenue, et les résultats sont enregistrés dans un historique, un log. Ce dernier représente l’état courant de l’information. La façon dont les événements sont traités pour un flux particulier dépend de son cas d’usage, et on peut donc coder sa logique propre. C’est ce qui permet d’avoir la flexibilité nécessaire – des informations diverses et variées circulent sur le Web.

Sur Ceramic, les informations sont représentées sous forme d’un historique de changements d’état, le Stream. On peut seulement ajouter des données au stream (append-only log of commits). Chaque flux est stocké sur l’IPLD sous forme de graphe orienté acyclique (DAG) – pour plus d’informations sur les DAG, voir l’article présentant Avalanche.

Les flux ont un nom immuable, le StreamID, et un état vérifiable, le StreamState. Il y a des similitudes avec les arbres de GitHub, par exemple. Ou encore, chaque stream peut être vu comme une blockchain, un registre unique.

Types de flux

Chaque flux doit spécifier son type (StreamType). Il s’agit de la logique de traitement utilisée. Cette fonction est exécutée par un nœud Ceramic lors de la réception d’un événement – engagement ou commit. C’est elle qui gouverne les transitions d’état du flux et donc le résultat sortant. Les StreamTypes définissent les règles du flux (structure des données, format du contenu, authentification et contrôle d’accès, algorithme de consensus). Toute mise à jour non-conforme au StreamType est rejetée. Tout commit valide est diffusé au reste du réseau (les nœuds de Ceramic Network). Chaque nœud maintenant aussi l’état du stream met alors à jour le StreamType.

Le système de StreamTypes de Ceramic est flexible et le développeur peut coder ses types personnalisés. Les logiciels clients Ceramic proposent des StreamTypes pré-écrits, correspondant à des cas d’usage courants :

• Tile Document : stockage d’un JSON. Utilisé notamment pour les métadonnées d’identité (profils, graphes sociaux, scores de réputation, etc.), le contenu généré par l’utilisateur.
• CAIP-10 Link : stockage de preuves cryptographiques vérifiables liant une adresse blockchain à un DID.
• Custom : StreamType personnalisé.

Méthodes d’authentification

On peut définir les paramètres d’authentification pour chaque StreamType. Par défaut, Ceramic utilise les DID (rappel : le standard W3C pour les identifiants décentralisés). Les DID fournissent un identifiant unique et plateforme-agnostique pour les documents DID. Ces derniers contiennent les clés (publique et privée) nécessaires au chiffrement et à la vérification des signatures. Toutes les implémentations sont disponibles sur Ceramic : 3ID DID, Key DID, NFT DID, Safe DID.

Les nœuds de Ceramic Network

Comme nous l’avons vu précédemment, Ceramic Network est un réseau décentralisé et mondial dont les nœuds communiquent de pair-à-pair via Libp2p. Par conception, sa scalabilité, son débit et donc ses performances sont maximales.

Environnements d’exécution

Chaque nœud Ceramic possède son propre environnement d’exécution. Cela diffère des blockchains classiques, où la machine virtuelle est unique : l’état du registre est partagé entre les nœuds. Sur Ceramic, il n’y a pas de registre global : chaque nœud peut effectuer des calculs et valider des transactions sur les streams. On parle d’environnement d’exécution fragmenté (sharded execution environment). C’est qui permet de paralléliser l’exécution d’un nombre croissant de transactions simultanées, au fur et à mesure que le nombre de nœuds du réseau augmente.

Pour traiter des flux de données à l’échelle mondiale, une telle scalabilité est requise. L’ordre de grandeur est bien supérieur à celui des blockchains financières. Les nœuds Ceramic peuvent également traiter les transactions hors-ligne, puis se synchroniser avec le reste du réseau une fois en ligne.

Espace de noms global

Tous les streams de Ceramic Network font partie d’un espace de noms unique. N’importe quel autre nœud peut y accéder, et n’importe quel autre stream peut le référencer. L’information est donc open source et publique.

Rôles des nœuds

Outre l’exécution des stream transactions, les nœuds Ceramic ont d’autres fonctions :

• Stockage du StreamState : on appelle cela le pinning – épingler un flux. Un nœud Ceramic ne stocke que le StreamState de ses streams dédiés. 
• Stockage de l’historique (commit log) : maintien d’une copie locale du log des commits.
• Connecteurs de persistance (optionnel) : les nœuds Ceramic peuvent stocker des sauvegardes des commits, par exemple via Filecoin, Arweave, Sia, etc.
• Réponses aux requêtes : les nœuds répondent aux requêtes des logiciels clients. S’il possède le stream recherché, il envoie la réponse. Dans le cas inverse, il recherche le stream (via libp2p) sur le reste du réseau, effectue la requête puis renvoie la réponse.
• Diffusion des transactions : une fois qu’une transaction est traitée avec succès, le nœud Ceramic la diffuse au reste du réseau. Les nœuds qui “pin” le stream correspondant peuvent alors mettre à jour leur StreamState.

Les logiciels clients pour Ceramic Network

Ils fournissent les interfaces pour exécuter les transactions et les requêtes. Ils permettent aussi d’authentifier les utilisateurs et de signer les transactions. Il y a trois clients disponibles :

• JS HTTP (client léger permettant de se connecter à un nœud Ceramic via HTTP, pour les développeurs d’applications) ;
• JS Core – inclut un nœud Ceramic complet, pour une décentralisation maximale.
• CLI : interface en ligne de commande pour interagir avec un nœud Ceramic.

Disponibilité des données

Il y a deux catégories de données pour les flux, les commits, et le state (engagements et état). Que l’on envoie des requêtes ou des ordres d’écriture, ces données doivent être disponibles. Dans le cas contraire (données hors-ligne), le logiciel client renverra une erreur. Bien évidemment, si les données sont perdues, le flux sera corrompu.

Opérations sur les flux de données : les commits

Chaque stream est donc un historique d’événements (log) constitué d’un ou plusieurs commits (engagements). L’ensemble des commits représente les données constituant le contenu du flux.

Mise en cache

Lors d’une requête (query) ou d’une opération d’écriture (write) sur un stream, les commits sont préalablement mis en cache sur les nœuds Ceramic. L’espace mémoire dédié est limité (500 streams par défaut). Les plus vieux streams sont donc évincés au fur et à mesure. Cela permet d’avoir une certaine persistance pour les flux les plus populaires. Le cache est vidé lors d’un arrêt ou d’un redémarrage du nœud. Ce n’est donc pas le cache qui assure la disponibilité des données pour de longues périodes.

Hébergement

Pour plus de persistance des données, les nœuds utilisent le pinning. C’est-à-dire qu’ils vont héberger les commits pour un flux spécifique. Étant donné que le stockage s’effectue via IPLD, les nœuds Ceramic ont également un nœud IPFS intégré. Cependant, il est possible d’utiliser un nœud IPFS externe.

Le nombre de pins pour chaque nœud est illimité. Cependant, il y aura un problème de disponibilité des données si un seul nœud héberge un stream donné, et qu’aucun autre nœud ne le possède en cache. Il est donc recommandé d’avoir de multiples nœuds IPFS dans différents environnements pour les mêmes flux.

Archivage 

Il s’agit bien évidemment de la façon la plus durable de stocker les commits. Les nœuds Ceramic ont la possibilité de se connecter à un service de stockage externe pour archiver tous les commits composant un stream. Ils ont le choix entre des systèmes décentralisés comme Filecoin, ou centralisés, comme Amazon S3.

État du flux (stream state)

Tous les nœuds hébergeant un stream possèdent, en plus des commits, l’état du flux. Ce dernier n’est pas stocké sur IPFS, mais sur les nœuds eux-mêmes – si le stream est épinglé ou mis en cache. Il faut à la fois que les données des commits et de l’état du stream soient disponibles.

Le système de mise en cache est le même que pour les commits. Cependant, le pinning est effectué dans une base de données interne au nœud.

Pour l’instant, l’archivage décentralisé des états n’est pas disponible sur Ceramic, mais ce sera implémenté. Néanmoins, il est possible d’utiliser Amazon S3 pour l’archivage.

Mécanismes de consensus de Ceramic Network

Les blockchains classiques maintiennent un consensus sur l’état d’un registre global, tandis que Ceramic Network maintient un consensus pour des flux de données individuels. Cela confère plus de scalabilité au réseau, puisque les nœuds n’ont besoin que des informations concernant leurs flux épinglés.

De même, les mécanismes de consensus peuvent être différents selon les streams. Les règles du consensus sont inscrites dans les StreamTypes.

La règle la plus répandue se nomme Earliest Anchor Wins – l’ancre la plus récente gagne.

Pour un StreamType “Tile Document”, les mises à jour sont encodées via un json-patch (le format permettant de décrire les changements à appliquer à un document JSON). Le commit correspondant permet alors d’effectuer les changements d’état. Lors de la synchronisation d’un StreamType “Tile Document”, il faut récupérer le commit de genèse, puis appliquer tous les json-patch subséquents, un par un, jusqu’à la fin du log.

Conflits

Règle générale : earliest anchor wins

Il peut arriver qu’il y ait conflit en écriture sur le même flux. Par exemple, lorsque celui qui contrôle le flux va utiliser des appareils ou applications différents pour le mettre à jour. Ou encore, dans le cas où plusieurs utilisateurs ont accès en écriture au même stream.

De manière générale, les StreamTypes vont utiliser la règle du Earliest Anchor Wins. Elle se base sur l’horodatage des mises à jour. Rappelez-vous, ces dernières sont régulièrement ancrées sur la blockchain d’Ethereum. C’est donc ce qui permet de déterminer quelle est la mise à jour qui a été soumise en premier : la branche ancrée en premier gagnera toujours.

Longest update chain

Cependant, cette règle n’est pas suffisante dans le cas où de multiples mises à jour sont soumises très rapidement. Dans ce cas, la règle qui s’applique est la longest update chain (chaîne de mise à jour la plus longue). Lorsqu’il y a des logs conflictuels qui n’ont pas été ancrés, les nœuds vont privilégier le plus long. Cela garantit que l’historique présentant le plus d’activité et le plus de mises à jour sera conservé.

Dans le cas où des branches conflictuelles non-ancrées ont la même longueur, le mécanisme en choisit une de façon arbitraire mais déterministe – afin que les autres nœuds fassent consensus sur le même log. Il y a donc un rare cas où des mises à jour conflictuelles peuvent être perdues – lorsqu’elles sont publiées à quelques secondes près.

Mises à jour simultanées

Dans ce scénario, une application tente d’ajouter une nouvelle entrée dans un tableau, sur un stream de type “Tile Document”. L’application charge le stream pour obtenir son contenu. Elle ajoute (localement) le nouvel élément et soumet la mise à jour au réseau.

Lorsque le code sera exécuté, si une autre mise à jour est faite au même flux, via un code similaire mais une entrée différente, alors le code pourrait ne pas inclure la seconde mise à jour lors de sa publication sur le réseau. 

Le réseau choisira l’une des deux mises à jour arbitrairement, mais celle qui sera rejetée sera définitivement perdue. Dans la plupart des cas, ce n’est pas un problème : la majorité des flux sont contrôlés par un seul utilisateur. Néanmoins, ce mécanisme pêche lorsqu’une application autorise de multiples utilisateurs à mettre à jour le même flux simultanément.

D’autres mécanismes de consensus seront donc implémentés dans le futur. 

Sécurité et confidentialité sur Ceramic Network

La sécurité de Ceramic repose sur les signatures cryptographiques, les preuves de publication (ancrage via Ethereum), et des structures de données liées par les fonctions de hachage. En parallèle, Ceramic Network utilise un protocole de bavardage (gossip) pour diffuser les mises à jour des flux.

Les streams sont faits de commits, liés entre eux via des hash, formant un DAG (graphe orienté acyclique). Cette structure repose sur l’IPLD. Chaque commit contient une preuve – il peut s’agir d’une signature ou d’une preuve de publication. Les nœuds Ceramic vérifient le DAG des commits lors de la synchronisation. Il est possible d’effectuer cette vérification localement.

Les signatures proviennent généralement du contrôleur du stream, bien que d’autres règles peuvent être définies. Les preuves de publications se basent sur l’horodatage du hash du contenu, via la blockchain d’Ethereum, et il est possible d’optimiser leur coût. La technique consiste à former un arbre de Merkle avec plusieurs hash de contenu, puis à publier la racine de l’arbre sur la blockchain.

Le protocole de bavardage utilisé est le Libp2p pubsub. Les nœuds doivent toujours vérifier la validité des mises à jour et des requêtes.

Spamming et attaques de déni de service

Des nœuds malicieux pourraient vouloir envoyer un très grand nombre de messages (spam). La contre-attaque consiste alors à limiter le nombre de messages qu’un nœud peut envoyer, en fonction de son score de réputation.

Il existe d’autres types d’attaques, comme l’attaque false log. Elle consiste à envoyer des logs défectueux. Lors de la synchronisation, le nœud victime rejettera le log, puisqu’il est invalide. Mais si l’attaquant spamme des logs très longs, cela va considérablement encombrer le nœud victime. L’approche la plus simple pour parer cette attaque est tout simplement de rejeter le nœud malicieux. Il y a des approches plus élaborées, reposant sur les preuves à non-divulgation de connaissance (ZKP), non implémentées.

La confidentialité sur Ceramic Network

La flexibilité des StreamTypes permet aux développeurs d’implémenter toutes sortes de fonctionnalités dédiées à la confidentialité des utilisateurs.

Le système DID permet de chiffrer le contenu embarqué dans un flux . On peut également rendre un flux confidentiel en le chiffrant simplement grâce à la cryptographie symétrique. Pour un chiffrement complet des métadonnées et des donnés, il y a plusieurs approches à implémenter. Une fois de plus, les preuves à non-divulgation de connaissance sont à étudier de près.

Participer au développement de Ceramic Network

Il est d’ores et déjà possible d’explorer le Mainnet via Tiles, un explorateur des flux de Ceramic Network. De même, une application pour navigateur – Playground – permet d’expérimenter le fonctionnement de Ceramic Network.

Pour utiliser Ceramic Network, c’est très simple. Tout d’abord, il faut choisir l’un des clients JavaScript (nœud complet ou léger). Ensuite, il faudra l’installer, en ayant bien pris soin de vérifier que l’on possède Node.js 14 et npm 6. Puis, pour se familiariser avec les streams, on peut créer, requêter, et mettre à jour ces derniers; sans oublier de passer en revue les schémas json.

Afin d’autoriser des utilisateurs à accéder aux flux en écriture, il faut choisir une méthode d’authentification DID et installer le fournisseur correspondant. Pour ce qui est des requêtes, il faut consulter la documentation de référence de l’API Ceramic. Il en va de même pour épingler (pin) un flux au sein de votre nœud. Afin d’installer l’interface en ligne de commande de Ceramic, il faut aussi suivre le tutoriel dédié. Tous les projets pourront alors être partagés avec la communauté de Ceramic via GitHub.

Les nœuds Ceramic/IPFS peuvent être hébergés et déployés avec Terraform sur des conteneurs AWS ECS, grâce au module dédié. Enfin, plusieurs outils sont déjà disponibles, comme des librairies, des interfaces en lignes de commande et autre services.

Si vous êtes ingénieur ou chef de produit et que souhaitez travailler avec les équipes de 3Box Labs sur Ceramic Network, 3Box Labs recrute !

Ressources

• Site officiel de Ceramic Network
• Documentation
• Chat officiel (Discord)
• Twitter
• GitHub
• YouTube