Consensus sur la réputation du nœud. Est-ce nécessaire?

Je sais je sais. Il y a beaucoup de projets cryptographiques, il y a beaucoup de consensus : basés sur le travail et la propriété, l'or, le pétrole, les tartes cuites au four (il y en a une, oui, oui). De quoi avons-nous besoin de plus ? C'est ce que je propose d'aborder après lecture de la traduction de la documentation technique « légère » 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, y a-t-il une place pour qu'un tel consensus « soit » ou est-ce inutile ?

Il n’y a pas beaucoup plus de lettres, donc si vous voulez simplement écrire « wow, autant que vous le pouvez sur la cryptographie », alors abstenez-vous. Si vous êtes intéressé par les nouveaux développements dans le domaine des systèmes distribués et que vous avez quelque chose à partager dans les commentaires, veuillez vous référer au cat.

PS Je ne suis pas l'auteur de la technologie, je ne peux pas garantir le transfert complet de l'essence, je serai donc heureux de recevoir des commentaires avec des modifications, le cas échéant.

Evolution des consensus synchrones vers les consensus asynchrones

Les nœuds sont sélectionnés à l'aide d'un processus déterministe (le même que celui utilisé dans les DHT tels que bittorrent) qui ajuste dynamiquement les responsabilités des nœuds pour « faciliter » la validation ou, plus compréhensible, pour parvenir à un consensus. Nous sélectionnons des groupes de 3 nœuds et organisons des cycles de consensus en parallèle afin qu'un nœud puisse être un facilitateur dans plusieurs blocs. Cela nous permet de traiter les transactions de manière asynchrone, ce qui signifie essentiellement que plusieurs blockchains sont formées en même temps. Le processus est comme une toile d'araignée, formée de nombreux fils, par opposition aux nœuds formant une seule chaîne au fil du temps. Le traitement asynchrone ou parallèle constitue la base d'une programmation évolutive car il permet d'utiliser toutes les ressources informatiques, accélérant ainsi le calcul global. Ce réseau est appelé graphe acyclique dirigé ou DAG en informatique.

Consensus sur la réputation du nœud. Est-ce nécessaire?
Largeur de canal d'une blockchain linéaire par rapport à l'effet multiplicatif d'un DAG où nous avons plusieurs blockchains parallèles.

Consensus sur la réputation du nœud. Est-ce nécessaire?
Implémentation géométrique d'une blockchain linéaire contre DAG. Les points noirs sont des blocs, les points blancs sont des nœuds

Nous utilisons 3 nœuds dans chaque cycle de consensus car cela nous donne des processus mathématiques intéressants pour raisonner sur l'état, formant un « plan de surface » à travers les données sous la forme de triangles connectés. Le protocole utilise ensuite les triangles pour assembler une surface optimale qui ne contient aucune donnée redondante ou incohérente et comporte les triangles les plus petits possibles. Algorithmiquement, cela est analogue à une « coupe minimale » d'un graphique, et mathématiquement, cela est analogue à une fonction de dérivée ou d'optimisation (à partir de laquelle la fonction trouve le chemin le plus court qu'elle peut parcourir le long de la surface). Ce chemin le plus court équivaut à stocker de manière optimale des données (transactions) dans un DAG. Des « tuiles » triangulaires conflictuelles pour que la surface de l’événement soit lisse et exempte de conflits.

Consensus sur la réputation du nœud. Est-ce nécessaire?
Implémentation géométrique de la détection/gestion des conflits. Un bloc en conflit crée une tuile de surface supplémentaire. Nous supprimons les tuiles de surface supplémentaires pour maintenir une surface événementielle plate (= sans conflit).

Consensus basé sur la réputation

Dans un système de réputation p2p décentralisé optimal, chaque nœud devrait être capable de déterminer indépendamment sa confiance dans 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 entretient avec d'autres nœuds, lors de l'attribution d'un score global. "Vous êtes aussi bon que votre entreprise." Le résultat final est un « biais » ou un gradient basé sur la confiance ou la réputation transitive sur tous les nœuds du $DAG ou du canal standard. Cela peut être considéré comme un pinceau ou une râpe à fromage qui efface sur un « plan de surface » et sélectionne les « carreaux triangulaires » à effacer et ceux à laisser. C’est ainsi que la logique de conflit supprime les « tuiles triangulaires ».

Consensus sur la réputation du nœud. Est-ce nécessaire?
Un DAG avec une tuile en conflit traversant un espace « courbé » qui est un dégradé, semblable à une râpe à fromage, et va supprimer ou « effacer » la tuile en conflit.

Mise à l'échelle partielle/complète des nœuds

Dans la théorie des réseaux, l’allocation optimale est généralement connue sous le nom de « sans échelle », ce qui peut être décrit comme un arrangement hiérarchique avec de grands nœuds centraux gérant de nombreux nœuds périphériques plus petits. Cette diffusion est visible dans la nature et surtout sur Internet. Constellation utilise cette architecture pour « évoluer » ou augmenter le débit ou la largeur de notre graphique.

Consensus sur la réputation du nœud. Est-ce nécessaire?
L'effet du partitionnement hiérarchique. Nous pouvons ajouter plus de nœuds en augmentant la bande passante

Hylochain - Prise en charge des applications basées sur les canaux

Notre approche du support applicatif peut être considérée comme une « plateforme de contrats intelligents décentralisée ». Au lieu d'un réseau central gérant toute la logique et traitant toutes les données de l'application, Constellation coordonne les données de l'application avec des « chaînes maison », qui peuvent être considérées comme une chaîne de télévision diffusant toutes les données du système maison. Chaque canal du personnel peut mettre en œuvre sa propre logique de vérification pour résoudre le problème d'Oracle grâce à l'authentification de bout en bout des producteurs de données et à la vérification transitive des systèmes composites du personnel. Les réseaux de canaux d'État fournissent une prise en charge parallèle des applications, accélérant les délais d'adoption limités par le consensus synchrone traditionnel dans un réseau de contrats intelligents.

Consensus sur la réputation du nœud. Est-ce nécessaire?
Deux chaînes standards « compatibles » via le réseau $DAG. Ils peuvent interagir ou être interprétés car ils sont tous deux « intégrés » à $DAG en déployant des nœuds hybrides $DAG + Channel.

La raison pour laquelle on l'appelle Hylochain est que notre approche de la prise en charge des applications a utilisé le modèle de programmation fonctionnel Recursion Schemes pour créer l'interface MapReduce. 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 diffuser des connexions sur des canaux natifs en validant les types de données algébriques de la même manière que les codes opérationnels des contrats intelligents sont vérifiés. Le résultat final est une interface MapReduce fonctionnelle, familière aux ingénieurs de données et compatible avec la technologie Big Data existante.

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

Tokenomics et sa connexion avec Hylochain

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

Consensus sur la réputation du nœud. Est-ce nécessaire?
Flux d'achat d'accès à l'information ou de modification d'information. La demande est envoyée à $DAG, les fonds sont envoyés au compte du canal, le résultat est envoyé à l'acheteur et la somme de contrôle de la transaction est envoyée au réseau $DAG, qui libère ensuite les fonds vers le canal habituel.

Source: habr.com

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