Présentation des flux MultiChain

Horodatage: 15 septembre 2016 8:56 AM
Nœud source: 1213525

Pour les bases de données de valeurs-clés et de séries chronologiques immuables partagées

Aujourd'hui, nous sommes fiers de publier la dernière version de MultiChain, qui implémente un nouvel ensemble crucial de fonctionnalités appelées «flux». Les flux fournissent une abstraction naturelle pour les cas d'utilisation de la blockchain qui se concentrent sur la récupération générale des données, l'horodatage et l'archivage, plutôt que sur le transfert d'actifs entre les participants. Les flux peuvent être utilisés pour implémenter trois types de bases de données différents sur une chaîne:

  1. Une base de données de valeurs-clés ou un magasin de documents, dans le style de NoSQL.
  2. Une base de données de séries chronologiques, qui se concentre sur l'ordre des entrées.
  3. Une base de données basée sur l'identité où les entrées sont classées selon leur auteur.

Ceux-ci peuvent être considérés comme le «quoi», le «quand» et le «qui» d'une base de données partagée.

Notions de base sur les flux

Un nombre illimité de flux peut être créé dans une chaîne de blocs MultiChain, et chaque flux agit comme une collection indépendante d'éléments ajoutés uniquement. Chaque élément d'un flux présente les caractéristiques suivantes:

  • Un ou plus éditeurs qui ont signé numériquement cet article.
  • En option, key pour une récupération ultérieure pratique.
  • Certain données, qui peut aller d'un petit morceau de texte à plusieurs mégaoctets de binaire brut.
  • A horodatage, qui est extrait de l'en-tête du bloc dans lequel l'élément est confirmé.

Dans les coulisses, chaque élément d'un flux est représenté par une transaction blockchain, mais les développeurs peuvent lire et écrire des flux sans avoir connaissance de ce mécanisme sous-jacent. (Les utilisateurs plus avancés peuvent utiliser transactions brutes pour écrire dans plusieurs flux, émettre ou transférer des actifs et / ou attribuer des autorisations en une seule transaction atomique.)

Les flux s'intègrent au système d'autorisations de MultiChain de plusieurs façons. Premièrement, les flux ne peuvent être créés que par ceux qui sont autorisés à le faire, de la même manière que les actifs ne peuvent être émis que par certaines adresses. Lorsqu'un flux est créé, il est ouvert ou fermé. Les flux ouverts sont accessibles en écriture par toute personne autorisée à envoyer une transaction blockchain, tandis que les flux fermés sont limités à une liste modifiable d'adresses autorisées. Dans ce dernier cas, chaque flux a un ou plusieurs administrateurs qui peuvent modifier ces autorisations d'écriture au fil du temps.

Chaque chaîne de blocs possède un flux «racine» facultatif, qui est défini dans son paramètres et existe dès la création de la chaîne. Cela permet à une blockchain d'être utilisée immédiatement pour le stockage et la récupération de données, sans attendre la création explicite d'un flux.

Comme j'ai discuté précédemment, la confidentialité est le plus grand défi dans un grand nombre de cas d'utilisation de la blockchain. En effet, chaque nœud d'une blockchain voit une copie complète du contenu de la chaîne entière. Les flux fournissent un moyen naturel de prendre en charge les données chiffrées sur une blockchain, comme suit:

  1. Un flux est utilisé par les participants pour distribuer leurs clés publiques pour tout schéma de cryptographie à clé publique.
  2. Un deuxième flux est utilisé pour publier des données, où chaque élément de données est crypté à l'aide d'une cryptographie symétrique avec une clé unique.
  3. Un troisième flux permet d'accéder aux données. Pour chaque participant devant voir un élément de données, une entrée de flux est créée qui contient la clé secrète de ces données, chiffrée à l'aide de la clé publique de ce participant.

Cela fournit un moyen efficace d'archiver des données sur une blockchain, tout en ne les rendant visibles qu'à certains participants.

Récupération à partir de flux

La valeur fondamentale des flux réside dans l'indexation et la récupération. Chaque nœud peut choisir les flux auxquels s'abonner, la chaîne de blocs garantissant que tous les nœuds qui s'abonnent à un flux particulier verront les mêmes éléments à l'intérieur. (Un nœud peut également être configuré pour s'abonner automatiquement à chaque nouveau flux créé.)

Si un nœud est abonné à un flux, les informations peuvent être récupérées à partir de ce flux de plusieurs manières:

  • Récupération des éléments du flux dans l'ordre.
  • Récupérer des éléments avec une clé particulière.
  • Récupération des éléments signés par un éditeur particulier.
  • Liste des clés utilisées dans un flux, avec le nombre d'éléments pour chaque clé.
  • Liste des éditeurs dans un flux, avec le nombre d'éléments.

Comme mentionné au début, ces méthodes de récupération permettent d'utiliser des flux pour bases de données de valeurs-clés, bases de données de séries chronologiques et bases de données basées sur l'identité. Toutes les API de récupération offrent Commencer ainsi que compter paramètres, permettant de récupérer efficacement des sous-sections de longues listes (comme une clause LIMIT en SQL). Valeurs négatives pour Commencer permettre la récupération des éléments les plus récents.

Les flux peuvent contenir plusieurs éléments avec la même clé, ce qui résout naturellement la tension entre l'immuabilité de la blockchain et la nécessité de mettre à jour une base de données. Chaque «entrée» de base de données efficace doit se voir attribuer une clé unique dans votre application, chaque mise à jour de cette entrée étant représentée par un nouvel élément de flux avec sa clé. Les API de récupération de flux de MultiChain peuvent ensuite être utilisées pour: (a) récupérer la première ou la dernière version d'une entrée donnée, (b) récupérer l'historique complet des versions d'une entrée, (c) récupérer des informations sur plusieurs entrées, y compris la première et la dernière versions de chacun.

Notez qu'en raison de l'architecture peer-to-peer d'une blockchain, les éléments d'un flux peuvent arriver à différents nœuds dans des ordres différents, et MultiChain permet aux éléments d'être récupérés avant d'être `` confirmés '' dans un bloc. Par conséquent, toutes les API de récupération offrent le choix entre un classement global (par défaut) ou local. Le classement global garantit qu'une fois la chaîne atteinte, tous les nœuds reçoivent les mêmes réponses des mêmes appels d'API. La commande locale garantit que, pour un nœud particulier, la commande des éléments d'un flux ne changera jamais entre les appels d'API. Chaque application peut faire le choix approprié à ses besoins.

Streams et feuille de route MultiChain

Avec la sortie des streams, nous avons terminé le dernier gros travail pour MultiChain 1.0, et nous sommes maintenant fermement sur la voie de la bêta. Nous prévoyons de passer les prochains mois à étendre notre suite de tests internes (déjà assez grande!), À terminer les ports Windows et Mac, à ajouter des API plus utiles, à mettre à jour le Explorer pour les flux, peaufiner certains aspects du mécanisme de consensus, publier notre démo Web et généralement ranger le code et les messages d'aide. Plus important encore, nous continuerons de corriger les bugs dès qu'ils seront découverts, afin que nos erreurs n'interrompent pas votre travail.

À plus long terme, où les flux s'intègrent-ils dans la feuille de route MultiChain? En prenant du recul, MultiChain propose désormais trois domaines de fonctionnalités de haut niveau:

  • Permissions pour contrôler qui peut se connecter, effectuer des transactions, créer des actifs / flux, extraire / valider et administrer.
  • Outils y compris l'émission, la réémission, le transfert, l'échange atomique, le séquestre et la destruction.
  • Streams avec des API pour créer des flux, écrire, s'abonner, indexer et récupérer.

Après la sortie de MultiChain 1.0 (et d'une version premium), quelle est la prochaine étape dans cette liste? Si vous regardez le Commande API qui est utilisé pour créer des flux, vous remarquerez un paramètre apparemment superflu, avec une valeur fixe de stream. Ce paramètre permettra à MultiChain de prendre en charge d'autres types d'entités de haut niveau à l'avenir.

Les valeurs futures possibles pour le paramètre incluent evm (pour un Ethereum-machine virtuelle compatible), sql (pour une base de données de style SQL) ou même wiki (pour le texte édité en collaboration). Toute entité partagée dont l'état est déterminé par une série ordonnée de changements est un candidat potentiel. Chacune de ces entités aura besoin: (a) d'API qui fournissent la bonne abstraction pour mettre à jour son état, (b) de mécanismes appropriés pour que les nœuds souscrits suivent cet état, et (c) d'API pour récupérer efficacement une partie ou la totalité de l'état. Nous attendons de savoir quelles autres entités de haut niveau seraient les plus utiles, à mettre en œuvre par nous ou par des tiers via une architecture de plug-in.

Et les contrats intelligents?

D'une manière générale, MultiChain adopte l'approche dans laquelle données est immuablement intégré dans une blockchain, mais le code pour interpréter que les données se trouvent dans le nœud ou la couche d'application. Ceci est délibérément différent du paradigme des «contrats intelligents», comme illustré par Ethereum, dans lequel le code est intégré dans la blockchain et s'exécute dans une machine virtuelle. En théorie, parce que les contrats intelligents sont Turing complet, ils peuvent reproduire le comportement de MultiChain ou de toute autre plateforme de blockchain. En pratique, cependant, les contrats intelligents de type Ethereum présentent de nombreuses lacunes douloureuses:

  • Chaque nœud doit effectuer tous les calculs, qu'ils soient intéressants ou non. En revanche, dans MultiChain, chaque nœud décide des flux auxquels s'abonner et peut ignorer les données contenues par d'autres.
  • Les performances de la machine virtuelle utilisée pour les contrats intelligents sont nettement inférieures à celles du code qui a été compilé en mode natif pour une architecture informatique donnée.
  • Le code de contrat intelligent est immuablement intégré dans une chaîne, empêchant l'ajout de fonctionnalités et la correction de bogues. Cela a été démontré avec force disparition du DAO.
  • Transactions envoyées à un contrat intelligent ne peut pas mettre à jour l'état d'une blockchain jusqu'à ce que son classement final soit connu, en raison de la nature du calcul à usage général. Cela entraîne des retards (jusqu'à ce qu'une transaction soit confirmée dans un bloc) ainsi que des inversions possibles (en cas de fork de la chaîne). En revanche, MultiChain peut traiter chaque type de transaction non confirmée de la manière appropriée: (a) les actifs entrants mettent immédiatement à jour le solde non confirmé d'un nœud, (b) les éléments de flux entrants sont instantanément disponibles, avec leur commande globale finalisée, (c) les modifications des autorisations sont appliqués immédiatement puis rejoués dans les blocs entrants.

Néanmoins, comme je l'ai dit avant, nous n'excluons certainement pas les contrats intelligents comme paradigme utile pour les applications de blockchain, si et quand nous voyons des cas d'utilisation forts. Cependant, dans MultiChain, les contrats intelligents seraient mis en œuvre dans une couche semblable à un flux au-dessus de la chaîne de blocs, plutôt qu'au niveau de transaction le plus bas. Cela préservera les performances supérieures de MultiChain pour les entités de chaîne de blocs plus simples telles que les actifs et les flux, tout en offrant un calcul en chaîne plus lent là où il est vraiment nécessaire. Mais il y a moins de tels cas que vous ne le pensez.

 

Veuillez poster vos commentaires sur LinkedIn.

 

Addendum technique

Toutes les commandes liées aux flux sont documentées dans leur intégralité dans le Page API MultiChain, mais voici un bref résumé:

  • Créez un flux en utilisant create stream or createfrom ... stream
  • Ajouter un élément à un flux avec publish or publishfrom
  • Récupérer une liste de flux en utilisant liststreams
  • Démarrer ou arrêter le suivi d'un flux avec subscribe ainsi que unsubscribe
  • Récupérer des éléments de flux à l'aide liststreamitems, liststreamkeyitems ainsi que liststreampublisheritems
  • Liste des clés de flux et des éditeurs avec liststreamkeys ainsi que liststreampublishers
  • Pour les éléments de flux volumineux, récupérez les données complètes à l'aide de gettxoutdata (voir maxshowndata ci-dessous)
  • Contrôlez les autorisations par flux avec des appels comme grant [address] stream1.write
  • Afficher les autorisations d'un flux à l'aide de listpermissions stream1.*

Quelques autres notes de développeur concernant les flux:

  • La create l'autorisation permet à une adresse de créer des flux.
  • Les autorisations par flux pertinentes sont write, admin ainsi que activate
  • Nouveauté paramètres de la chaîne de blocs: root-stream-name (laisser vide pour rien), root-stream-open, anyone-can-create, admin-consensus-create, max-std-op-returns-count
  • Nouveauté paramètres d'exécution: autosubscribe pour vous abonner automatiquement aux nouveaux flux créés et maxshowndata pour limiter la quantité de données dans les réponses API (voir gettxoutdata au dessus de).
  • La taille maximale des données d'un élément de flux est fixée par le max-std-op-return-size paramètre blockchain, ainsi que le plus petit des maximum-block-size ainsi que max-std-tx-size valeurs moins quelques centaines d'octets.
  • Les nœuds utilisant l'ancien format de portefeuille ne peuvent pas s'abonner aux flux, et devrait être mis à niveau.

 

Horodatage:

Plus de Multichain