Consensus sur la réputation des nœuds. Est-ce nécessaire ?

Je sais, je sais. Il y a une multitude de projets cryptographiques, avec pleins de consensus : basés sur le travail et la possession, l'or, le pétrole, des pâtisseries (oui, ça existe, oui-oui). Que nous apporte encore un de plus ? C'est ce que je propose de discuter après avoir lu la traduction de la documentation technique 'allégée' du projet *Constellation (Constellation). Bien sûr, ce n'est pas une description complète de l'algorithme, mais je suis intéressé par l'opinion de la communauté Habr, un tel consensus a-t-il sa place ou est-il inutile ?

Il n'y a pas beaucoup de lettres restantes, donc si vous avez simplement envie d'écrire 'beurk, combien de fois parler de crypto', je vous prie de vous abstenir. Si vous êtes intéressé par les nouvelles avancées dans le domaine des systèmes distribués et que vous avez des choses à partager dans les commentaires, n'hésitez pas.

P.S. Je ne suis pas l'auteur de la technologie, je ne peux pas garantir la transmission complète de l'idée, donc je serais heureux des commentaires avec des corrections, s'il y en a.

Évolution des consensus synchrones vers des consensus asynchrones

Les nœuds sont choisis à l'aide d'un processus déterministe (le même que celui utilisé dans les DHT, par exemple, bittorrent), qui règle dynamiquement les responsabilités des nœuds pour 'faciliter' la validation ou, pour être plus clair, pour atteindre un consensus. Nous choisissons des groupes de 3 nœuds et effectuons des rondes de consensus en parallèle, de sorte qu'un nœud puisse être facilitateur dans plusieurs blocs. Cela nous permet de traiter les transactions de manière asynchrone, ce qui signifie fondamentalement que plusieurs blockchains se forment simultanément. Le processus est semblable à une toile, formée de nombreux fils, contrairement aux nœuds qui forment une chaîne unique au fil du temps. Le traitement asynchrone ou parallèle est la clé de la programmation évolutive, car il permet d'utiliser toutes les ressources de l'ordinateur, accélérant ainsi les calculs globaux. Ce réseau est appelé graph orienté acyclique ou DAG en informatique.

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
La largeur de bande d'une blockchain linéaire contre l'effet multiplicatif du DAG, où nous avons plusieurs blockchains parallèles.

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
La réalisation géométrique d'une blockchain linéaire contre un DAG. Les points noirs représentent les blocs, les points blancs représentent les nœuds.

Nous utilisons 3 nœuds à chaque tour de consensus, car cela nous fournit des processus mathématiques intéressants pour réfléchir à l'état, formant une « surface plane » à travers les données sous forme de triangles avec des connexions. Ensuite, le protocole utilise ces triangles pour « coudre » la surface optimale, qui ne contient aucune donnée redondante ou contradictoire et possède le nombre minimal de triangles possible. Algorithmique, cela est analogue à un « coupe minimale » dans un graphe, et mathématiquement, à une dérivée ou à une fonction d'optimisation (d'où la fonction trouve le chemin le plus court qu'elle peut traverser à la surface). Ce chemin le plus court équivaut à un stockage de données (transactions) optimal dans un ensemble de disponibilité des bases de données. Des triangles « carrelages » qui s'opposent, pour que la surface de l'événement soit plane et sans conflits.

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
Réalisation géométrique de la détection / gestion des conflits. Un bloc conflictuel crée un carrelage supplémentaire sur la surface. Nous supprimons le carrelage supplémentaire pour maintenir une surface plane (= sans conflits) des événements.

Consensus basé sur la réputation

Dans un système p2p décentralisé de réputation optimal, chaque nœud doit être en mesure de déterminer indépendamment sa confiance envers les autres nœuds. Notre système utilise un modèle spécial qui inclut des relations transitives ou des relations qu'un nœud a avec d'autres nœuds lors de l'attribution d'une évaluation globale. « Vous n'êtes aussi bon que votre entreprise ». Le résultat final est une « distorsion » ou un gradient basé sur la confiance ou la réputation transitive dans tous les nœuds dans le $DAG ou le canal standard. Cela peut être considéré comme une râpe ou un pinceau pour le fromage, qui efface la surface de la « surface plane » et décide quels « carrelages triangulaires » effacer et lesquels conserver. C'est ainsi que la logique des conflits supprime réellement les « carrelages triangulaires ».

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
DAG avec un carrelage conflictuel traversant un espace « déformé », qui est un gradient semblable à une râpe à fromage, et vient supprimer ou « effacer » le carrelage conflictuel.

Mise à l'échelle partielle / complète du nœud

Dans la théorie des réseaux, la distribution optimale est généralement connue sous le nom de « sans mise à l'échelle », qui peut être décrite comme une disposition hiérarchique avec de grands nœuds centraux contrôlant de nombreux nœuds périphériques plus petits. Cette distribution est observable dans la nature et, en premier lieu, sur Internet. Constellation utilise cette architecture pour la « mise à l'échelle », c'est-à-dire l'augmentation de la bande passante ou de la largeur de notre Graphe.

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
L'effet de la décomposition hiérarchique. Nous pouvons ajouter plus de nœuds pour augmenter la bande passante.

Hylochain — Support pour des applications basées sur des canaux.

Notre approche du support d'applications peut être considérée comme une « plateforme décentralisée de contrats intelligents ». Au lieu d'un réseau central exécutant toute la logique et traitant toutes les données de l'application, Constellation coordonne les données de l'application avec des « canaux dédiés », que l'on peut voir comme une station de télévision diffusant toutes les données du système dédié. Chaque canal dédié peut mettre en œuvre sa propre logique de vérification, permettant de résoudre le problème des oracles par une vérification croisée de l'authenticité des producteurs de données et une vérification transitive des systèmes dédiés composites. Les réseaux de canaux dédiés fournissent un soutien parallèle aux applications, accélérant le temps d'adoption, qui dans un réseau de contrats intelligents est limité par un consensus synchrone traditionnel.

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
Deux canaux dédiés qui sont « compatibles » via le réseau $DAG. Ils peuvent interagir ou être interprétés, car ils sont tous deux « intégrés » avec le $DAG par le déploiement de nœuds hybrides $DAG + Canal.

La raison pour laquelle il s'appelle Hylochain réside dans l'utilisation d'un modèle fonctionnel de programmation, les Schémas de Récursion, pour développer une interface MapReduce dans notre approche de support des applications. En particulier, les schémas de récursion Hylomorphism et Metamorphism peuvent être intégrés pour créer des requêtes vérifiables et des connexions en flux via des canaux standards, en vérifiant les types algébriques de données de la même manière que les opcodes pour les contrats intelligents. Le résultat final est une interface fonctionnelle MapReduce, qui est familière aux ingénieurs des données et compatible avec la technologie des grandes données existante.

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
Hylomorphic et Metamorphic canaux standards pour le contraste. Dans l'état métamorphique, les données de deux canaux standards sont envoyées dans un bloc au métacanal. Dans Hilo, nous prenons l'état précédent du canal et l'utilisons pour interroger (poser une question spécifique) deux autres canaux, puis nous stockons le résultat de la requête dans le bloc.

Tokenomics et son lien avec Hylochain

Lorsqu'un canal standard est créé, il peut être intégré dans le canal $DAG, mais en utilisant l'interface ACI ou Application Chain Interface. Cette interface est simplement un objet JSON contenant des informations de configuration et une clé publique associée au canal lui-même. La raison pour laquelle nous associons une clé publique au canal standard est de créer un mécanisme de courtage pour les données du canal standard. Une fois le canal standard déployé, les développeurs configurent eux-mêmes comment les paiements du réseau $DAG sont répartis entre les nœuds et les opérateurs.

Consensus sur la réputation des nœuds. Est-ce nécessaire ?
Flux pour acheter l'accès à des informations ou modifier des informations. La demande est envoyée au $DAG, les fonds sont transférés sur le compte du canal, le résultat est envoyé à l'acheteur et la somme de contrôle de la transaction est renvoyée au réseau $DAG, qui débloque ensuite les fonds pour le canal standard.

Source : habr.com

Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS 🔥 Acheter un hébergement fiable pour les sites avec protection DDoS, serveurs VPS VDS | ProHoster