Mise à l'échelle des chaînes de blocs avec des données hors chaîne

Republié par Platon

Suiveurs: 0

Quand un hachage vaut un million de mots

À présent, il est clair que de nombreux cas d'utilisation de la blockchain n'ont rien à voir avec les transactions financières. Au lieu de cela, le but de la chaîne est de permettre l'agrégation, la commande, l'horodatage et l'archivage décentralisés des tous type d'informations, y compris les données structurées, la correspondance ou la documentation. La valeur fondamentale de la blockchain est de permettre à ses participants de se mettre d'accord de manière prouvée et permanente sur exactement quelles données ont été saisies, quand et par qui, sans compter sur un intermédiaire de confiance. Par exemple, SAP a récemment lancé plateforme blockchain, qui prend en charge MultiChain et Hyperledger Fabric, cible un large éventail de chaînes d'approvisionnement et d'autres applications non financières.

Le moyen le plus simple d'utiliser une blockchain pour enregistrer des données est d'intégrer chaque élément de données directement dans une transaction. Chaque transaction blockchain est signée numériquement par une ou plusieurs parties, répliquée sur chaque nœud, ordonnée et horodatée par l'algorithme de consensus de la chaîne, et stockée en permanence de manière infalsifiable. Toutes les données de la transaction seront donc stockées de manière identique mais indépendante par chaque nœud, avec une preuve de qui l'a écrite et quand. Les utilisateurs de la chaîne peuvent récupérer ces informations à tout moment futur.

Par exemple, MultiChain 1.0 permettait de créer un ou plusieurs «flux» nommés sur une blockchain, puis d'être utilisés pour stocker et récupérer des données brutes. Chaque flux a son propre ensemble d'autorisations d'écriture et chaque nœud peut choisir librement les flux auxquels s'abonner. Si un nœud est abonné à un flux, il indexe le contenu de ce flux en temps réel, ce qui permet de récupérer rapidement les éléments en fonction de leur ordre, de l'horodatage, du numéro de bloc ou de l'adresse de l'éditeur, ainsi que via une «clé» (ou étiquette) par lesquels les éléments peuvent être étiquetés. MultiChain 2.0 (depuis alpha 1) étend les flux pour prendre en charge le texte Unicode ou les données JSON, ainsi que plusieurs clés par élément et plusieurs éléments par transaction. Il a également ajouté des fonctions de synthèse telles que «JSON merge» qui combinent des éléments avec la même clé ou éditeur de manière utile.

Confidentialité et évolutivité

Bien que le stockage des données directement sur une blockchain fonctionne bien, il souffre de deux lacunes principales: la confidentialité et l'évolutivité. Pour commencer par la confidentialité, le contenu de chaque élément de flux est visible par chaque nœud de la chaîne, et ce n'est pas nécessairement un résultat souhaitable. Dans de nombreux cas, un élément de données ne doit être visible que par un certain sous-ensemble de nœuds, même si d'autres nœuds sont nécessaires pour faciliter son classement, son horodatage et sa notarisation.

La confidentialité est un problème relativement facile à résoudre, en chiffrant les informations avant qu'elles ne soient intégrées dans une transaction. La clé de déchiffrement de chaque élément de données n'est partagée qu'avec les participants qui sont censés la voir. La livraison des clés peut être effectuée en chaîne à l'aide de la cryptographie asymétrique (comme décrit ici) ou via un mécanisme hors chaîne, comme cela est préféré. Tout nœud n'ayant pas la clé pour déchiffrer un élément ne verra rien de plus que du charabia binaire.

L'évolutivité, en revanche, est un défi plus important. Disons que toute plate-forme de blockchain décente devrait prendre en charge un débit réseau de 500 transactions par seconde. Si l'objectif de la chaîne est le stockage d'informations, la taille de chaque transaction dépendra principalement de la quantité de données qu'elle contient. Chaque transaction nécessitera également (au moins) 100 octets de frais généraux pour stocker l'adresse de l'expéditeur, la signature numérique et quelques autres bits et éléments.

Si nous prenons un cas simple, où chaque élément est une petite structure JSON de 100 octets, le débit global de données serait de 100 kilo-octets par seconde, calculé à partir de 500 × (100 + 100). Cela se traduit par moins de 1 mégabit / seconde de bande passante, ce qui est confortablement dans la capacité de toute connexion Internet moderne. Les données s'accumuleraient à un rythme d'environ 3 téraoctets par an, ce qui n'est pas une mince affaire. Mais avec des disques durs de 12 téraoctets maintenant largement disponibleet RAID contrôleurs qui combinent plusieurs disques physiques en un seul disque logique, nous pourrions facilement stocker 10 à 20 ans de données sur chaque nœud sans trop de tracas ou de dépenses.

Cependant, les choses semblent très différentes si nous stockons des informations plus volumineuses, telles que la documentation numérisée. Une numérisation JPEG de qualité raisonnable d'une feuille de papier A4 peut avoir une taille de 500 kilo-octets. Multipliez cela par 500 transactions par seconde, et nous recherchons un débit de 250 mégaoctets par seconde. Cela se traduit par 2 gigabits / seconde de bande passante, ce qui est plus rapide que la plupart des réseaux locaux, sans parler des connexions à Internet. Chez Amazon Web Services le moins cher prix publié de 0.05 USD par gigaoctet, cela signifie une facture annuelle de bande passante de 400,000 8000 USD par nœud. Et où chaque nœud stockera-t-il les XNUMX XNUMX téraoctets de nouvelles données générées chaque année?

Il est clair que, pour les applications blockchain stockant de nombreux gros morceaux de données, le stockage en chaîne simple n'est pas un choix pratique. Pour ajouter l'insulte à la blessure, si les données sont cryptées pour résoudre le problème de confidentialité, les nœuds sont invités à stocker une énorme quantité d'informations qu'ils ne peuvent même pas lire. Ce n'est pas une proposition intéressante pour les participants du réseau.

La solution de hachage

Alors, comment résoudre le problème de l'évolutivité des données? Comment pouvons-nous tirer parti de la notarisation décentralisée des données de la blockchain, sans répliquer ces données sur chaque nœud de la chaîne?

La réponse est avec une technologie intelligente appelée «hachage». Un hachage est un nombre long (pensez à 256 bits, soit environ 80 chiffres décimaux) qui identifie de manière unique un élément de données. Le hachage est calculé à partir des données à l'aide d'un fonction unidirectionnelle qui a une propriété cryptographique importante: étant donné n'importe quelle donnée, il est facile et rapide de calculer son hachage. Mais étant donné un hachage particulier, il est impossible de trouver un élément de données qui générerait ce hachage. Et quand nous disons «infaisable par le calcul», nous voulons dire plus de calculs qu'il n'y a d'atomes dans l'univers connu.

Les hachages jouent un rôle crucial dans toutes les blockchains, en identifiant de manière unique les transactions et les blocages. Ils sous-tendent également le défi de calcul dans les systèmes de preuve de travail comme le bitcoin. De nombreuses fonctions de hachage différentes ont été développées, avec des noms de gobbledygook tels que BLAKE2, MD5 et RIPEMD160. Mais pour qu'une fonction de hachage soit digne de confiance, elle doit subir des examens et des tests universitaires approfondis. Ces tests se présentent sous la forme de tentatives d'attaques, telles que «preimage» (trouver une entrée avec le hachage donné), «deuxième préimage» (trouver une deuxième entrée avec le même hachage que l'entrée donnée) et «collision» (trouver une deux entrées différentes avec le même hachage). Survivre à ce défi est loin d'être facile, avec une longue et tragique histoire de fonctions de hachage cassées prouvant la célèbre maxime: «Ne roulez pas votre propre crypto».

Pour revenir à notre problème d'origine, nous pouvons résoudre l'évolutivité des données dans les blockchains en intégrant les hachages de gros morceaux de données dans les transactions, au lieu des données elles-mêmes. Chaque hachage agit comme un «engagement» envers ses données d'entrée, les données elles-mêmes étant stockées en dehors de la blockchain ou «hors chaîne». Par exemple, en utilisant la fonction de hachage SHA256 populaire, une image JPEG de 500 kilo-octets peut être représentée par un nombre de 32 octets, soit une réduction de plus de 15,000 500 ×. Même à une cadence de XNUMX images par seconde, cela nous ramène confortablement sur le territoire des besoins de bande passante et de stockage réalisables, en termes de données stockées sur la chaîne elle-même.

Bien sûr, tout participant à la blockchain qui a besoin d'une image hors chaîne ne peut pas la reproduire à partir de son hachage. Mais si l'image peut être récupérée d'une autre manière, le hachage en chaîne sert à confirmer qui l'a créée et quand. Tout comme les données en chaîne régulières, le hachage est intégré dans une transaction signée numériquement, qui a été incluse dans la chaîne par consensus. Si un fichier image tombe du ciel et que le hachage de cette image correspond à un hachage dans la blockchain, l'origine et l'horodatage de cette image sont confirmés. Ainsi, la blockchain fournit exactement la même valeur en termes de notarisation que si l'image était directement intégrée dans la chaîne.

Une question de livraison

Jusqu'ici tout va bien. En incorporant des hachages dans une blockchain au lieu des données d'origine, nous avons une solution simple au problème de l'évolutivité. Néanmoins, une question cruciale demeure:

Comment livrer le contenu original hors chaîne aux nœuds qui en ont besoin, sinon via la chaîne elle-même?

Cette question a plusieurs réponses possibles, et nous savons que les utilisateurs de MultiChain les appliquent toutes. Une approche de base consiste à mettre en place un référentiel centralisé chez une partie de confiance, où toutes les données hors chaîne sont téléchargées puis récupérées par la suite. Ce système pourrait naturellement utiliser «l'adressage de contenu», c'est-à-dire que le hachage de chaque donnée sert directement d'identifiant pour la récupération. Cependant, bien que cette configuration puisse fonctionner pour une preuve de concept, cela n'a pas de sens pour la production, car le but d'une blockchain est de supprimer les intermédiaires de confiance. Même si les hachages en chaîne empêchent l'intermédiaire de falsifier les données, il peut toujours supprimer les données ou ne pas les fournir à certains participants, en raison d'une défaillance technique ou des actions d'un employé non autorisé.

Une possibilité plus prometteuse est la communication point à point, dans laquelle le nœud qui a besoin de certaines données hors chaîne les demande directement au nœud qui les a publiées. Cela évite de s'appuyer sur un intermédiaire de confiance, mais souffre de trois défauts alternatifs:

Il nécessite une cartographie des adresses blockchain en adresses IP, pour permettre au consommateur de certaines données de communiquer directement avec son éditeur. Les blockchains peuvent généralement éviter ce type de configuration de réseau statique, ce qui peut être un problème en termes de basculement et de confidentialité.
Si le nœud de l'éditeur d'origine a quitté le réseau ou est temporairement hors service, les données ne peuvent être récupérées par personne d'autre.
Si un grand nombre de nœuds sont intéressés par certaines données, l'éditeur sera submergé par les demandes. Cela peut créer une grave congestion du réseau, ralentir le système de l'éditeur et entraîner de longs délais pour ceux qui tentent de récupérer ces données.

Afin d'éviter ces problèmes, nous utiliserions idéalement une sorte de mécanisme de livraison décentralisé. Les nœuds doivent être en mesure de récupérer les données dont ils ont besoin sans s'appuyer sur un système individuel - qu'il s'agisse d'un référentiel centralisé ou de l'éditeur d'origine des données. Si plusieurs parties ont un élément de données, ils devraient partager le fardeau de le fournir à toute autre personne qui le souhaite. Personne n'a besoin de faire confiance à une source de données individuelle, car les hachages en chaîne peuvent prouver que les données n'ont pas été falsifiées. Si un nœud malveillant me fournit les mauvaises données pour un hachage, je peux simplement supprimer ces données et essayer de demander à quelqu'un d'autre.

Pour ceux qui ont de l'expérience avec partage de fichiers poste à poste protocoles tels que Napster, Gnutella ou BitTorrent, tout cela vous semblera très familier. En effet, bon nombre des principes de base sont les mêmes, mais il existe deux différences essentielles. Premièrement, en supposant que nous utilisons notre blockchain dans un contexte d'entreprise, le système fonctionne dans un groupe fermé de participants, plutôt que sur Internet dans son ensemble. Deuxièmement, la blockchain ajoute une colonne vertébrale décentralisée de commande, d'horodatage et de notarisation, permettant à tous les utilisateurs de conserver une vision prouvée cohérente et inviolable de ce qui s'est passé, quand et par qui.

Comment un développeur d'applications blockchain pourrait-il réaliser cette livraison décentralisée de contenu hors chaîne? Un choix courant consiste à prendre une plate-forme de partage de fichiers peer-to-peer existante, telle que le nom amusant Système de fichiers interplanétaire (IPFS), et utilisez-le avec la blockchain. Chaque participant exécute à la fois un nœud blockchain et un nœud IPFS, avec un middleware coordonné entre les deux. Lors de la publication de données hors chaîne, ce middleware stocke les données d'origine dans IPFS, puis crée une transaction blockchain contenant le hachage de ces données. Pour récupérer des données hors chaîne, le middleware extrait le hachage de la blockchain, puis utilise ce hachage pour récupérer le contenu d'IPFS. Le nœud IPFS local vérifie automatiquement le contenu récupéré par rapport au hachage pour s'assurer qu'il n'a pas été modifié.

Bien que cette solution soit possible, elle est plutôt maladroite et peu pratique. Tout d'abord, chaque participant doit installer, maintenir et mettre à jour trois logiciels distincts (nœud blockchain, nœud IPFS et middleware), chacun stockant ses données dans un endroit séparé. Deuxièmement, il y aura deux réseaux peer-to-peer séparés, chacun avec sa propre configuration, ses ports réseau, son système d'identité et ses autorisations (bien qu'il soit à noter qu'IPFS ne prend pas encore en charge les réseaux fermés). Enfin, coupler étroitement IPFS et la blockchain rendrait le middleware de plus en plus complexe. Par exemple, si nous voulons que les données hors chaîne référencées par certaines transactions blockchain soient instantanément récupérées (avec des tentatives automatiques), le middleware devrait être constamment opérationnel, en conservant son propre état complexe. Ne serait-il pas bien que le nœud blockchain fasse tout cela pour nous?

Données hors chaîne dans MultiChain 2.0

Aujourd'hui, nous sommes ravis de publier le troisième version d'aperçu (alpha 3) de MultiChain 2.0, avec une solution entièrement intégrée et transparente pour les données hors chaîne. Chaque information publiée dans un flux peut être en chaîne ou hors chaîne selon vos besoins, et MultiChain s'occupe de tout le reste.

Non vraiment, nous voulons dire peut. En tant que développeur s'appuyant sur MultiChain, vous n'aurez pas à vous soucier des hachages, du stockage local, de la découverte de contenu, de la livraison décentralisée ou de la vérification des données. Voici ce qui se passe dans les coulisses:

Le nœud MultiChain de publication écrit les nouvelles données dans son stockage local, découpant les éléments volumineux en morceaux pour faciliter la digestion et la livraison.
La transaction de publication d'éléments de flux hors chaîne est automatiquement construite, contenant le ou les hachage (s) de bloc et la (les) taille (s) en octets.
Cette transaction est signée et diffusée sur le réseau, se propageant entre les nœuds et entrant dans la blockchain de la manière habituelle.
Lorsqu'un nœud abonné à un flux voit une référence à certaines données hors chaîne, il ajoute les hachages de bloc pour ces données à sa file d'attente de récupération. (Lors de l'abonnement à un ancien flux, un nœud met également en file d'attente tous les éléments hors chaîne précédemment publiés pour la récupération.)
En tant que processus d'arrière-plan, s'il y a des morceaux dans la file d'attente de récupération d'un nœud, des requêtes sont envoyées au réseau pour localiser ces morceaux, tels qu'identifiés par leurs hachages.
Ces requêtes de bloc sont propagées à d'autres nœuds du réseau de manière peer-to-peer (limité à deux sauts pour le moment - voir les détails techniques ci-dessous).
Tout nœud qui a les données pour un bloc peut répondre, et cette réponse est relayée à l'abonné le long du même chemin que la requête.
Si aucun nœud ne répond à la requête de bloc, le bloc est renvoyé dans la file d'attente pour une nouvelle tentative ultérieure.
Sinon, l'abonné choisit la source la plus prometteuse pour un bloc (en fonction des sauts et du temps de réponse) et lui envoie une demande pour les données de ce bloc, à nouveau le long du même chemin d'égal à égal que la réponse précédente.
Le nœud source fournit les données demandées, en utilisant à nouveau le même chemin.
L'abonné vérifie la taille et le hachage des données par rapport à la demande d'origine.
Si tout se vérifie, l'abonné écrit les données sur son stockage local, les rendant immédiatement disponibles pour une récupération via les API de flux.
Si le contenu demandé n'est pas arrivé ou ne correspond pas au hachage ou à la taille souhaités, le bloc est renvoyé dans la file d'attente pour une récupération ultérieure à partir d'une autre source.

Plus important encore, tout cela se produit extrêmement rapidement. Dans les réseaux à faible latence, de petits morceaux de données hors chaîne arriveront aux abonnés en une fraction de seconde après la transaction qui les référence. Et pour les applications à forte charge, nos tests montrent que MultiChain 2.0 alpha 3 peut supporter un taux de plus de 1000 éléments hors chaîne ou 25 Mo de données hors chaîne récupérées par seconde, sur un serveur de milieu de gamme (Core i7) avec un bon Connexion Internet. Tout fonctionne correctement avec des éléments hors chaîne d'une taille allant jusqu'à 1 Go, bien au-delà de la limite de 64 Mo pour les données en chaîne. Bien sûr, nous espérons améliorer encore ces chiffres en passant du temps à optimiser MultiChain 2.0 pendant sa phase bêta.

Lors de l'utilisation de données hors chaîne plutôt que sur chaîne dans des flux, les développeurs d'applications MultiChain doivent faire exactement deux choses:

Lors de la publication de données, transmettez un indicateur «hors chaîne» aux API appropriées.
Lorsque vous utilisez les API d'interrogation de flux, envisagez la possibilité que certaines données hors chaîne ne soient pas encore disponibles, comme indiqué par l'indicateur «disponible». Bien que cette situation soit rare dans des circonstances normales, il est important que les développeurs d'applications la gèrent de manière appropriée.

Bien entendu, pour empêcher chaque nœud de récupérer chaque élément hors chaîne, les éléments doivent être regroupés en flux de manière appropriée, chaque nœud s'abonnant à ces flux d'intérêt.

Les éléments en chaîne et hors chaîne peuvent être utilisés dans le même flux, et les diverses fonctions d'interrogation et de synthèse de flux se rapportent aux deux types de données de manière identique. Cela permet aux éditeurs de faire le choix approprié pour chaque élément d'un flux, sans affecter le reste d'une application. Par exemple, un flux d'éléments JSON sur les activités des personnes peut utiliser des données hors chaîne pour des informations d'identification personnelle et des données en chaîne pour le reste. Les abonnés peuvent utiliser la fusion JSON de MultiChain pour combiner les deux types d'informations en un seul JSON pour la lecture.

Si vous souhaitez essayer des éléments de flux hors chaîne, suivez simplement le programme régulier de MultiChain Pour commencer tutoriel, et assurez-vous de ne pas sauter la section 5.

Alors, quelle est la prochaine?

Avec une prise en charge transparente des données hors chaîne, MultiChain 2.0 offrira un grand pas en avant pour les applications blockchain axées sur l'horodatage et la notarisation des données à grande échelle. À plus long terme, nous réfléchissons déjà à une tonne d'améliorations futures possibles de cette fonctionnalité pour les éditions Community et / ou Enterprise de MultiChain:

Mise en œuvre du flux lire autorisations utilisant une combinaison d'éléments hors chaîne, de hachages salés, de requêtes de blocs signés et de livraison chiffrée.
Permettre aux données hors chaîne d'être explicitement «oubliées», à la fois volontairement par des nœuds individuels ou par tous les nœuds en réponse à un message en chaîne.
Abonnements à des flux sélectifs, dans lesquels les nœuds récupèrent uniquement les données des éléments hors chaîne avec des éditeurs ou des clés particuliers.
En utilisant arbres merkle pour permettre à un seul hachage sur chaîne de représenter un nombre illimité d'éléments hors chaîne, ce qui donne un autre énorme saut en termes d'évolutivité.
Moteurs de stockage enfichables, permettant de conserver les données hors chaîne dans des bases de données ou des systèmes de fichiers externes plutôt que sur un disque local.
Les nœuds apprennent au fil du temps où chaque type de données hors chaîne est généralement disponible dans un réseau et concentrent leurs requêtes de manière appropriée.

Avec plaisir entendre vos commentaires sur la liste ci-dessus ainsi que les articles hors chaîne en général. Avec MultiChain 2.0 toujours officiellement en alpha, il reste encore beaucoup de temps pour améliorer cette fonctionnalité avant sa sortie finale.

En attendant, nous avons déjà commencé à travailler sur les «filtres intelligents», la dernière fonctionnalité majeure prévue pour la communauté MultiChain 2.0. Un filtre intelligent est un morceau de code intégré dans la blockchain qui implémente des règles personnalisées pour valider des données ou des transactions. Les filtres intelligents présentent certaines similitudes avec les «contrats intelligents» et peuvent faire beaucoup des mêmes choses, mais présentent des différences clés en termes de sécurité et de performances. Nous sommes impatients de vous en dire plus en temps voulu.

Veuillez poster vos commentaires sur LinkedIn.

Détails techniques

Bien que les éléments de flux hors chaîne dans MultiChain 2.0 soient simples à utiliser, ils contiennent de nombreuses décisions de conception et des fonctionnalités supplémentaires qui peuvent être intéressantes. La liste ci-dessous sera principalement pertinente pour les développeurs qui créent des applications blockchain et peut être ignorée par des types moins techniques:

Politiques par flux. Lorsqu'un flux MultiChain est créé, il peut éventuellement être restreint pour n'autoriser que les données en chaîne ou hors chaîne. Il y a plusieurs raisons possibles à cela, plutôt que de laisser chaque éditeur décider par lui-même. Par exemple, les articles en chaîne offrent une garantie de disponibilité à toute épreuve, tandis que les anciens articles hors chaîne peuvent devenir irrécupérables si leur éditeur et d'autres abonnés abandonnent le réseau. D'un autre côté, les articles en chaîne ne peuvent pas être «oubliés» sans modifier la blockchain, tandis que les articles hors chaîne sont plus flexibles. Cela peut être important en termes de règles de confidentialité des données, telles que la nouvelle réglementation européenne GDPR.
Métadonnées en chaîne. Pour les éléments hors chaîne, la transaction en chaîne contient toujours le ou les éditeurs, les clés, le format (JSON, texte ou binaire) et la taille totale de l'élément. Tout cela prend très peu de place et aide les développeurs d'applications à déterminer si l'indisponibilité d'un élément hors chaîne est préoccupante pour une requête de flux particulière.
Limite de deux sauts. Lors du relais de requêtes de bloc sur le réseau peer-to-peer, il y a un compromis entre l'accessibilité et les performances. Alors qu'il serait bien que chaque requête soit propagée le long de chaque chemin, cela peut obstruer le réseau avec des «bavardages» inutiles. Donc, pour l'instant, les requêtes de segment sont limitées à deux sauts, ce qui signifie qu'un nœud peut récupérer des données hors chaîne à partir de n'importe quel pair de ses pairs. Dans les petits réseaux de moins de 1000 nœuds qui ont tendance à caractériser les blockchains d'entreprise, nous pensons que cela fonctionnera très bien, mais il est facile pour nous d'ajuster cette contrainte (ou de la proposer comme paramètre) si nous nous trompons.
Stockage local. Chaque nœud MultiChain stocke les données hors chaîne dans le répertoire «chunks» de son répertoire blockchain normal, en utilisant un format binaire efficace et un index LevelDB. Un sous-répertoire distinct est utilisé pour les éléments dans chacun des flux souscrits, ainsi que pour ceux publiés par le nœud lui-même. Dans chacun de ces sous-répertoires, les blocs dupliqués (avec le même hachage) ne sont stockés qu'une seule fois. Lorsqu'un nœud se désabonne d'un flux, il peut choisir de purger ou non les données hors chaîne récupérées pour ce flux.
Cache binaire. Lors de la publication de gros morceaux de données binaires, que ce soit en chaîne ou hors chaîne, il peut ne pas être pratique pour les développeurs d'applications d'envoyer ces données à l'API de MultiChain en une seule requête JSON-RPC. Ainsi, MultiChain 2.0 implémente un cache binaire, qui permet de créer de gros morceaux de données sur plusieurs appels d'API, puis de les publier dans une brève étape finale. Chaque élément du cache binaire est stocké sous la forme d'un simple fichier dans le sous-répertoire «cache» du répertoire blockchain, ce qui permet également de pousser des gigaoctets de données directement via le système de fichiers.
Surveillance des API. MultiChain 2.0 alpha 3 ajoute deux nouvelles API pour surveiller la récupération asynchrone des données hors chaîne. La première API décrit l'état actuel de la file d'attente, indiquant le nombre de blocs (et la quantité de données) en attente ou en cours d'interrogation ou de récupération. La deuxième API fournit des statistiques agrégées pour toutes les requêtes de bloc et les demandes envoyées depuis le démarrage du nœud, y compris le décompte des différents types d'échec.
Flush lors de la publication. Lors de la publication d'un élément hors chaîne, MultiChain s'assure que sa copie locale des données est entièrement écrite (ou «vidée») sur le lecteur de disque physique avant que la transaction référençant ces données ne soit diffusée sur le réseau. Sinon, si le nœud a eu la malchance de perdre de l'alimentation immédiatement après la diffusion de la transaction, les données hors chaîne pourraient être définitivement perdues. Ce n'est pas un problème pour MultiChain lui-même, car les délais entre les tentatives de récupération d'un morceau augmentent automatiquement avec le temps. Mais cela pourrait poser des problèmes au niveau de l'application, où tout le monde connaît l'existence de certaines données mais personne ne peut les trouver.
Publication des performances. En vidant les données hors chaîne sur le disque de cette manière, MultiChain peut entraîner une baisse des performances, car les disques physiques sont lents. Par exemple, un disque dur de milieu de gamme à 7200 tr / min ne peut effectuer qu'environ 100 écritures de données aléatoires par seconde, limitant à son tour la vitesse à laquelle un nœud individuel peut publier des éléments hors chaîne. Il existe trois solutions de contournement possibles pour ce problème. Tout d'abord, et plus simplement, les nœuds peuvent utiliser un disque SSD (Solid State Device) au lieu d'un disque dur ordinaire, qui prend en charge 10,000 opérations d'écriture aléatoire par seconde. Deuxièmement, plusieurs articles hors chaîne peuvent être publiés en une seule transaction à l'aide de l'API «createrawsendfrom». Dans ce cas, MultiChain écrit toutes les données hors chaîne référencées par une transaction en une seule opération de disque. Enfin, MultiChain peut être configuré pour ne pas vider les données hors chaîne sur le disque avant de diffuser la transaction qui y fait référence. Utilisez cette option avec précaution.
Intégration de la devise native. Pour les cas d'utilisation qui l'exigent, MultiChain a toujours offert la possibilité d'utiliser une devise native sur une blockchain pour éviter le spam de transaction et / ou inciter les validateurs de blocs («mineurs»). Dans ces cas, les transactions doivent offrir aux mineurs une redevance minimale proportionnelle à leur taille en octets, afin d'être relayées et confirmées sur la chaîne. Ce mécanisme a été étendu pour permettre d'éviter le spam hors chaîne, en exigeant un supplément minimum par kilo-octet de données hors chaîne référencées dans une transaction.
Archiver les nœuds. Si un nœud souhaite s'abonner à chaque flux, et donc récupérer et stocker chaque élément hors chaîne publié, il peut être configuré pour le faire à l'aide du paramètre d'exécution «autosubscribe». Un tel nœud agira comme une sauvegarde pour l'ensemble du réseau, garantissant que les éléments hors chaîne ne seront pas perdus ou indisponibles, quels que soient les autres nœuds qui disparaissent. On peut imaginer des sociétés tierces offrant cela comme un service commercial.