DFINITY, qui se spécialise dans les technologies sous-jacentes, peut-il vraiment envisager la réalisation du Web3 ?

Recommandé : Le marché est haussier et baissier et rencontre la situation en Ukraine, cliquez ici pour rejoindre le groupe PANews pour vous réchauffer

Titre original : Interprétation du nouveau livre blanc de DFINITY, la chaîne publique des actions potentielles Quelle est la technologie sous-jacente à l’ère de la connexion du Web 3.0 ?

Auteur : TinTinLand

1

Plomb

Début février 2022, Dmail, la première DApp de messagerie privée développée sur la base de l’écosystème DFINITY, a reçu un investissement stratégique d’Amino Capital. Il est rapporté que Dmail peut envoyer des e-mails vers et depuis des boîtes aux lettres traditionnelles, et par rapport aux boîtes aux lettres traditionnelles, Dmail avec des attributs blockchain peut également réaliser une transmission cryptée d’informations et NFT de noms de boîtes aux lettres. Il s’agit d’une préparation aux logiciels de communication à l’ère du Web 3.0, qui servent d’entrée aux sites web décentralisés et aux DApps sous forme d’« identité numérique ». La question que je veux poser est la suivante : pourquoi Dmail a-t-il choisi Dfinity ?

Comparé aux chaînes publiques de la blockchain, Dfinity n’a pas émergé beaucoup de fois. Il n’y a pas eu de feu DeFi quand il y a eu une petite étincelle, et il n’y a pas eu de gain de siège dans la première année de « NFT ». Cependant, depuis son lancement, il n’est pas rare que des personnes comme Dmail aient un aperçu de ce à quoi ressemblera l’implémentation spécifique du Web 3.0.

DFINITY a publié en juillet 2020 la version open-source du logiciel social de vidéos courtes « CanCan », que nous pouvons simplement comparer à Douyin du Web 2.0. CanCan est basé sur le langage de programmation de DFINITY, Motoko, et compte moins de 1 000 lignes de code. Cela peut être qualifié d’incroyable par rapport aux dizaines de millions de lignes de code sur Douyin et Facebook. En même temps, le code de CanCan est open source et la propriété du produit n’appartient à aucune autorité centralisée. Le 1er octobre de la même année, DFINITY a dévoilé son système de gouvernance et son modèle économique de jetons, et la valorisation du projet a atteint 9,5 milliards de dollars, se classant parmi les cinq premiers. À la fin du mois de décembre de la même année, l’évolution marquante des cinq réseaux du cuivre au mercure a été achevée. Dominic Williams, fondateur et scientifique en chef de la Fondation DFINITY, a déclaré lors du « Forum et de la cérémonie de remise des prix du sommet de l’ère de la valeur FAT 2020 » que l’ordinateur Internet est la troisième grande innovation de la blockchain.

Cet article interprétera le texte original du livre blanc de DFINITY, en partant de la logique la plus basse de l’explication officielle, pour voir comment DFINITY peut partir de la technologie, casser les géants de l’Internet et laisser divers logiciels Web2.0 utiliser des logiciels autonomes et une gouvernance décentralisée pour réaliser la synergie des entreprises open source, afin de vraiment réaliser le Web3.0 ; Les lecteurs n’ayant aucune expérience dans l’industrie de la blockchain peuvent avoir un seuil de lecture lorsqu’ils lisent cet article, mais ils sont également invités à commenter les questions qui se posent ci-dessous, et ils peuvent obtenir des réponses inattendues.

2

Contour

Tout au long de l’histoire et du processus actuel de la blockchain, BTC a apporté l’ère de la monnaie décentralisée, ETH représente le domaine des systèmes d’exploitation, Filecoin représente le stockage et DFINITY représente l’innovation dans le domaine de l’informatique et la mise en œuvre du Web 3.0. Internet Computer (ci-après dénommé IC) est le réseau principal, est un protocole de couche 1, visant à développer un réseau public décentralisé, DFINITY est un ordinateur et une technologie blockchain virtuels ouverts, étendant l’écosystème Ethereum à un large éventail de scénarios d’applications commerciales. Dans cet article, nous utiliserons le terme officiel « Internet Computer » dans le livre blanc pour faire référence à la chaîne « DFINITY » qui est couramment utilisée dans le scénario de communication actuel. Cette section explique principalement les termes techniques impliqués dans certains circuits intégrés, ainsi que les différences de technologie et de mise en œuvre par rapport à d’autres chaînes publiques, ou les points brillants de la technologie et de la fonction. On peut dire que l’IC est une nouvelle tentative de combinaison d’évolutivité, de décentralisation et de sécurité.

2.1 Protocole de consensus

Si l’on considère IC et plusieurs autres grandes chaînes publiques du point de vue des protocoles de consensus, IC adopte un modèle hybride de réseau contrôlé par la DAO, qui offre de nombreux avantages d’un protocole PoS décentralisé tout en ayant l’efficacité d’un protocole autorisé. Les protocoles de consensus Bitcoin, Ethereum et Algorand sont basés sur la blockchain, utilisant soit la preuve de travail (PoW), soit la preuve d’enjeu (POS). Bien que ces protocoles soient entièrement décentralisés, ils sont moins efficaces que les protocoles autorisés.

Les DAO fonctionnent selon un protocole de consensus autorisé pour chaque sous-réseau, et une DAO décide quelles entités peuvent fournir des copies des nœuds, configure le réseau, fournit une infrastructure à clé publique et contrôle la version du protocole dans laquelle les copies des nœuds sont déployées. La DAO d’IC s’appelle le système nerveux du réseau (NNS) et est basée sur le protocole Pos, c’est-à-dire que les décisions pertinentes sont toutes décidées par les membres de la communauté, et le pouvoir de vote des membres de la communauté est déterminé par le nombre de jetons de gouvernance natifs (ICP) IC qu’ils mettent en jeu dans NNS. Ce mécanisme de gouvernance basé sur PoS vous permet de créer de nouveaux sous-réseaux et d’ajouter ou de supprimer des répliques de nœuds existants, ainsi que de déployer des mises à jour logicielles et d’apporter d’autres ajustements à l’IC.

De ce point de vue, nous pouvons également comprendre pourquoi DFINITY appelle IC un réseau de machines à états répliquées, car NNS lui-même est une machine à états répliqués. Comme les autres machines d’état, elles s’exécutent sur un sous-réseau spécifique et leur appartenance est déterminée par le même système de gouvernance basé sur PoS mentionné ci-dessus. Dans le même temps, une base de données appelée registre est gérée, qui enregistre les réplicas de nœuds appartenant à quel sous-réseau, les clés publiques des réplicas de nœuds, etc. Par conséquent, le réseau de contrôle de la DAO sert de protocole de consensus décentralisé, permettant à l’IC d’obtenir un consensus efficace, mais en même temps, en raison du mécanisme de fonctionnement de la DAO, l’IC conserve également les avantages existants de la décentralisation.

Le protocole de consensus de l’IC utilise également la cryptographie à clé publique, comme le registre maintenu par NNS pour lier la clé publique au réplica de nœud et au sous-réseau pour former un tout, ce qui est appelé cryptographie à clé en chaîne, et l’IC envisage également le modèle de communication pour le protocole de consensus et le protocole qui exécute la machine d’état de réplication : il espère adopter un modèle asynchrone plus réalisable et plus robuste (pour tout message envoyé, l’adversaire peut retarder la livraison de tout message pendant un temps arbitraire, il n’y a donc pas de limite de temps pour la livraison du message) pour faire face aux échecs byzantins. Cependant, à l’heure actuelle, il n’existe pas de modèle de consensus connu qui soit vraiment réalisable dans le cadre du modèle asynchrone, et dans l’interprétation suivante de l’architecture IC, cet article expliquera plus en détail l’approche technique de l’IC pour cette situation réelle.

2.2 Cryptographie à clé en chaîne

Comme mentionné ci-dessus, le protocole de consensus d’IC utilise également la cryptographie à clé publique - la cryptographie à clé en chaîne, et il existe plusieurs parties principales qui composent la cryptographie à clé en chaîne. Le premier composant de la cryptographie à clé en chaîne est la signature de seuil : la signature de seuil est une technique cryptographique mature qui permet à un sous-réseau d’avoir une clé de signature de vérification commune, et la clé privée de signature correspondante est divisée en plusieurs copies et distribuée aux nœuds du sous-réseau, tandis que l’allocation garantit que le nœud défectueux ne peut pas falsifier de signatures, et le fragment de clé privée appartenant au nœud honnête permet au sous-réseau de générer des signatures conformes aux principes et protocoles IC.

L’une des principales applications de ces signatures de seuil est que la sortie individuelle d’un sous-réseau peut être vérifiée par un autre sous-réseau ou par un utilisateur externe, et que la vérification peut être effectuée simplement en vérifiant l’implémentation de la signature électronique à l’aide de la clé de signature de vérification publique du sous-réseau modifié (le premier sous-réseau).

Comme nous pouvons le voir, il existe de nombreuses autres applications de ces signatures de seuil dans le CI. L’un d’eux doit être utilisé pour rendre chaque copie d’un nœud d’un sous-réseau accessible à des chiffres pseudo-aléatoires imprévisibles (dérivés de ces signatures de seuil). C’est la base des balises aléatoires utilisées par la couche consensus et des bandes aléatoires utilisées par la couche d’exécution.

Pour déployer en toute sécurité les signatures de seuil, l’IC utilise un protocole innovant de génération de clés distribuées (DKG) pour construire une clé de vérification de signature publique et fournir à chaque réplica de nœud un fragment de la clé privée de signature correspondante pour les modèles de défaillance byzantine et asynchrones mentionnés précédemment.

2.3 ICP

L’ICP présente les caractéristiques suivantes :

Le staking NNS, c’est-à-dire la facilitation de la gouvernance du réseau.

ICP peut être utilisé pour miser dans NNS afin d’obtenir des droits de vote et ainsi participer à la DAO qui contrôle le réseau IC. Les utilisateurs qui misent des tokens dans NNS et participent à la gouvernance de NNS reçoivent également des tokens ICP nouvellement frappés en tant que récompenses de vote. Le nombre de récompenses est déterminé par les politiques établies et appliquées par NNS.

Cycles de rachat, c’est-à-dire en tant que puissance de production.

Le PCI est utilisé pour payer l’utilisation du CI. Plus précisément, l’ICP peut être échangé contre des cycles (c’est-à-dire brûlés), qui peuvent être utilisés pour payer les ressources (stockage, processeur et bande passante) utilisées pour créer des réservoirs et des réservoirs. Le rapport entre la PIC et le cycle est déterminé par NNS.

Les fournisseurs de nœuds sont rémunérés, c’est-à-dire qu’ils sont donnés en récompense aux participants.

L’ICP est utilisé pour payer les fournisseurs de nœuds, c’est-à-dire les entités qui possèdent et exploitent des nœuds de calcul pour héberger les copies des nœuds qui composent l’IC. NNS détermine régulièrement (actuellement mensuellement) le nouveau PCI que chaque fournisseur de nœud doit recevoir et le dépose sur son compte. Selon les politiques établies et appliquées par NNS, le paiement de l’ICP est basé sur le fait que le fournisseur de nœuds fournit des services fiables à l’IC.

2.4 Exécution du NNS

Comme mentionné précédemment, la machine d’état de réplication du circuit intégré peut exécuter des programmes arbitraires. L’unité de calcul de base d’un circuit intégré s’appelle un réservoir, et c’est à peu près le même concept qu’un processus, contenant le programme et son état (qui change avec le temps). Le programme du réservoir est codé en WebAssembly (ci-après dénommé Wasm), qui est un format d’instruction à deux mécanismes basé sur une machine virtuelle empilée. Wasm est une norme open-source, et bien qu’elle ait été conçue à l’origine pour permettre des applications hautes performances sur le Web, elle est également bien adaptée à l’informatique à usage général.

Le circuit intégré fournit un environnement d’exécution pour l’exécution des programmes Wasm à l’intérieur du réservoir et la communication (via la messagerie) avec d’autres réservoirs et des utilisateurs externes. Alors qu’en principe, il est possible d’écrire un programme de char dans n’importe quel langage qui compile en Wasm, le langage susmentionné appelé Motoko est très cohérent avec la sémantique des opérations de circuits intégrés et peut être utilisé dans les circuits intégrés.

Motoko est un programme de programmation basé sur l’acteur 2 avec prise en charge intégrée de la persistance orthogonale 3 et de la messagerie asynchrone. La persistance en quadrature signifie que la mémoire maintenue par le réservoir est automatiquement conservée (c’est-à-dire qu’elle n’a pas besoin d’être écrite dans un fichier). Motoko dispose d’un certain nombre de fonctionnalités de productivité et de sécurité, notamment la gestion automatique de la mémoire, les génériques, l’inférence de type, la correspondance de motifs et l’arithmétique arbitraire et à précision fixe.

En plus de Motoko, l’IC fournit un langage de définition d’interface de message et un format de données appelé Candid, qui est utilisé pour l’interopérabilité de type fixe, de langage de haut niveau et inter-langues. Cela permet à deux chars, même s’ils sont écrits dans des langues de haut niveau différentes, de communiquer facilement entre eux. Afin de fournir une prise en charge complète du développement de réservoirs pour un langage de programmation donné, un support d’exécution spécifique doit être fourni en plus du compilateur Wasm pour ce langage. Actuellement, en plus de Motoko, le circuit intégré prend également en charge le développement de chars dans le langage de programmation Rust.

Par conséquent, les circuits intégrés prennent en charge des langages de programmation plus sécurisés et interlangages, ce qui est l’un des facteurs importants qui rendent les développeurs plus efficaces et plus sûrs dans la création de circuits intégrés.

2.5 Décisions de la SNN

Dans le réseau blockchain DFINITY, BNS (Blockchain Nervous System) est le système de gouvernance sur lequel le réseau fonctionne, et c’est l’un des éléments constitutifs les plus importants du réseau blockchain, qui peut entrer automatiquement dans le système et avoir une grande autorité. Il joue le rôle d’un supernœud. Tout le monde participe à la gouvernance du NNS en jalonnant l’ICP dans ce que l’on appelle les neurones. Les détenteurs de neurones peuvent proposer et voter sur la façon dont le CI doit être modifié, comme la topologie du sous-réseau ou le protocole. Les droits de vote des neurones sont basés sur le PoS. Intuitivement, plus l’ICP est misé, plus les droits de vote neuronaux sont importants. Cependant, le pouvoir de vote dépend également d’autres caractéristiques des neurones, telles que les détenteurs de neurones qui sont prêts à miser leurs jetons pendant une période plus longue, se voient accorder un plus grand pouvoir de vote.

Chaque proposition fait l’objet d’une période de vote définie. Si, à la fin de la période de vote, une majorité simple des votants en faveur de la proposition et que le nombre de voix favorables dépasse le quorum requis pour le total des droits de vote (actuellement 3 %), la proposition est adoptée. Dans le cas contraire, la proposition a été rejetée. En outre, à tout moment où une majorité qualifiée (plus de la moitié du vote total) est pour ou contre la proposition, la proposition est acceptée ou rejetée en conséquence.

En termes plus simples, le processus de gouvernance de la SNE est divisé en quatre phases : la création de neurones, la proposition, le vote et l’exécution.

Créer des neurones : Comme mentionné ci-dessus, le neurosystème blockchain permet aux utilisateurs d’utiliser l’ICP pour créer des neurones de vote. N’importe qui peut créer un neurone, et à l’avenir, des dizaines de milliers de neurones pourraient être créés, qui exprimeront collectivement la volonté de la communauté, par l’intermédiaire d’algorithmes.

Propositions : Tout utilisateur exécutant des neurones peut faire une proposition sur BNS, et BNS examinera la proposition en fonction du caractère raisonnable de la proposition et si elle fournit une solution. L’utilisateur qui fait la proposition doit payer deux frais : l’un est de payer les évaluateurs professionnels et les neurones qui ont participé au vote, et l’autre est le dépôt de la proposition, qui sera retourné au neurone après l’adoption de la proposition, et ce montant peut être fixé pour encourager les propositions de haute qualité.

Vote : En plus du proposant, d’autres utilisateurs doivent également miser des jetons sur les neurones pendant la phase de vote et pouvoir choisir de voter activement ou de suivre le vote. Les utilisateurs ayant une capacité de jugement indépendante peuvent choisir de voter activement, et le scénario du vote suivant convient à certains utilisateurs qui ne peuvent pas juger avec précision des propositions. Une fois le vote terminé, le BNS recueille les résultats du réseau neuronal et détermine automatiquement si la proposition est approuvée ou non.

Mise en œuvre : Il y a maintenant une interprétation du consensus IC de la couche d’exécution, quelle est la mise en œuvre spécifique de la mise en œuvre du système de gouvernance BNS ? LA PROPOSITION D’EXÉCUTION PASSIVE IMPLIQUE PRINCIPALEMENT DES CHANGEMENTS DE PARAMÈTRES DANS LES CONTRATS INTELLIGENTS SUR DFINITY, TELS QUE LES PARAMÈTRES DE JALONNEMENT DES NEURONES. Les paramètres de proposition mis à jour seront écrits passivement dans la base de données des contrats intelligents BNS et prendront effet directement lorsqu’ils seront exécutés ultérieurement. Il existe un cas particulier où la proposition échappe au contrôle du contrat intelligent BNS, par exemple au niveau réglementaire du BNS, qui nécessitera une application active humaine pour outrepasser la partie « code is law » de DFINITY. Par exemple, modifier les vulnérabilités du code système ou geler les contrats intelligents ou les neurones qui enfreignent les réglementations BNS. Le processus d’exécution active est implémenté en invoquant des opcodes spéciaux ajoutés à l’EVM. Le fonctionnement de cette étape est plus humain et raisonnable, plutôt que le « code est la loi » et « le code est tout » dans le monde actuel de la blockchain. Du point de vue de la nature humaine, couvrir des scénarios où le code ne peut pas prendre de décisions peut apporter une gouvernance plus efficace et plus intelligente, et dans une certaine mesure, cela touche également vraiment à l’intention sous-jacente du « consensus ».

3

Interprétation de l’architecture

Le protocole IC se compose de quatre couches (comme le montre la figure ci-dessous), à savoir la couche P2P, la couche de consensus, la couche de routage et la couche d’exécution. Dans cette partie, cet article interprète uniquement les rôles et les fonctions de l’architecture à quatre couches, et analyse la construction de l’architecture globale. POUR UNE COMPRÉHENSION PLUS DÉTAILLÉE DE L’IMPLÉMENTATION TECHNIQUE SPÉCIFIQUE D’UNE COUCHE PARTICULIÈRE, VEUILLEZ VOUS RÉFÉRER AU LIVRE BLANC ORIGINAL DE DFINITY.

3.1 Couche P2P

La couche P2P sert de couche dans la couche de protocole informatique Internet pour la récupération et l’ordre des messages, et sa tâche consiste à remettre les messages de protocole dans une copie des nœuds du sous-réseau.

Il existe deux types de messages de protocole : les messages utilisés pour obtenir un consensus et les messages d’entrée initiés par des utilisateurs externes.

Nous pouvons comprendre que la couche P2P fournit essentiellement un canal de diffusion « au mieux », c’est-à-dire que si une copie honnête du nœud diffuse un message, le message finira par être reçu par tous les nœuds de la ville dans le sous-réseau.

La couche P2P est conçue avec les objectifs suivants :

Des ressources limitées. Tous les algorithmes fonctionnent avec des ressources limitées (mémoire, bande passante, processeur).

Priorité. En fonction d’attributs spécifiques, tels que le type, la taille et le tour, différents messages seront triés avec des priorités différentes. Et les règles de ces priorités peuvent changer au fil du temps.

Très efficace. Un débit élevé est plus important qu’une faible latence. LE DÉBIT ÉLEVÉ EST ÉGALEMENT LA RAISON POUR LAQUELLE DFINITY EST PLUS EFFICACE À PARTIR DU BAS QUE LES AUTRES CHAÎNES PUBLIQUES.

Anti-DOS/SPAM. Les nœuds défaillants n’affecteront pas la communication entre les réplicas de nœuds honnêtes.

3.2 Couche de consensus

3.2.1 Vue d’ensemble de la couche de consensus

La tâche de la couche de consensus IC est de trier les messages d’entrée pour s’assurer que toutes les répliques des nœuds traitent les messages d’entrée dans le même ordre. Il existe de nombreux protocoles dans la littérature qui traitent de cette question. IC adopte un nouveau protocole de consensus, qui sera décrit en langage général dans cet article. Tout protocole de consensus sécurisé doit garantir deux attributs, qui sont à peu près les suivants :

Sécurité : toutes les répliques de nœuds acceptent de facto le même ordre d’entrées.

Actif : tous les réplicas de nœud doivent mettre à jour leur état un par un.

L’objectif de conception de la couche de consensus IC est en fait facile à comprendre : lorsqu’il y a des nœuds malveillants individuels, les performances seront dégradées de manière flexible. Comme de nombreux protocoles de consensus, le protocole de consensus IC est basé sur la blockchain. Au fur et à mesure que le protocole progresse, l’arbre de blocs avec le bloc de genèse comme nœud racine continuera de croître. Chaque bloc non-genesis contient une charge utile, qui se compose d’une série d’entrées et du hachage du bloc parent.

Les réplicas honnêtes ont une vue cohérente de l’arborescence de blocs : bien que chaque réplica puisse avoir une vue locale différente de l’arborescence de segments, tous les réplicas du nœud voient la même arborescence de segments. De plus, au fur et à mesure que le protocole progresse, il y aura toujours un chemin dans l’arborescence des blocs pour finaliser le bloc. Encore une fois, les réplicas de noeud honnêtes ont une vue cohérente de ce chemin : bien que chaque réplica de noeud puisse avoir une vue locale différente du chemin, tous les réplicas de noeud voient le même chemin. Les entrées dans le chargement des blocs le long de ce chemin sont les entrées triées qui seront traitées par la couche d’exécution du CI.

Le protocole de consensus s’appuie sur des signatures électroniques pour vérifier les messages dans une copie d’un nœud. Pour ce faire, chaque copie du nœud est associée à une clé d’authentification publique pour le protocole de signature. La corrélation entre le réplica de nœud et la clé publique peut être obtenue à partir du registre géré par NNS. Ceci est également conforme au rôle et au rôle de la cryptographie à clé de chaîne dans les circuits intégrés mentionnés ci-dessus.

3.2.2 Hypothèses

Comme nous l’avons vu dans la partie II, IC propose l’hypothèse suivante :

Un sous-réseau contient n répliques de noeuds, et un maximum de f

Les réplicas de nœud défaillants peuvent présenter un comportement arbitraire et malveillant (c’est-à-dire une défaillance byzantine). Nous supposons que la communication est asynchrone et qu’il n’y a pas de limitation préalable de la latence des messages entre les réplicas de nœuds, c’est-à-dire le modèle asynchrone mentionné ci-dessus. À ce stade, la planification de la messagerie peut être complètement hostile. Dans cette hypothèse de communication faible, le protocole de consensus IC peut assurer la sécurité. Mais pour assurer l’activité, nous devons supposer une certaine forme de synchronisation partielle, c’est-à-dire que le réseau reste synchronisé périodiquement à de courts intervalles. Dans le cadre de cet intervalle de synchronisation, toutes les informations non soumises seront soumises dans le délai imparti, c’est-à-dire dans un délai fixe δ. La limite de temps δ n’est pas connue à l’avance (le protocole initialise une valeur limite raisonnable mais ajuste dynamiquement la valeur et augmente la valeur limite lorsque la limite de temps est trop petite). Que le réseau soit asynchrone ou partiellement synchrone, nous supposons que les messages envoyés par un réplica de nœud honnête à un autre réplica de nœud finiront par être remis.

3.2.3 Présentation du protocole

Comme de nombreux protocoles de consensus, le protocole de consensus IC est basé sur la blockchain. Au fur et à mesure que le protocole progresse, les arbres de blocs (voir 3.2.4 par exemple) avec le bloc de genèse comme nœud racine continueront à croître. Chaque bloc non-genesis contient une charge utile, qui se compose d’une série d’entrées et du hachage du bloc parent. Les réplicas honnêtes ont une vue cohérente de l’arborescence de blocs : bien que chaque réplica puisse avoir une vue locale différente de l’arborescence de segments, tous les réplicas du nœud voient la même arborescence de segments. De plus, au fur et à mesure que le protocole progresse, il y aura toujours un chemin dans l’arborescence des blocs pour finaliser le bloc. De même, les réplicas de noeud honnêtes ont une vue cohérente de ce chemin et, bien que chaque réplica de noeud puisse avoir une vue locale différente du chemin, tous les réplicas de noeud voient le même chemin. Les entrées dans les charges des blocs le long de ce chemin ont été triées et traitées par la couche d’exécution, qui est interprétée dans la section précédente.

3.2.4 Exemple pratique

L’image ci-dessous montre une arborescence de blocs. Chaque bloc est marqué d’une hauteur de bloc (30, 31, 32, ··· ) et le classement des générateurs de blocs, qui montre que chaque bloc de l’arborescence des blocs est notarié et marqué du symbole N. Cela signifie que les blocs notariés dans chaque arborescence de blocs sont pris en charge par la notarisation d’au moins n à f copies de différents nœuds. On peut constater qu’il peut y avoir plus d’un bloc notarié à la hauteur de bloc spécifiée. Par exemple, à la hauteur du bloc 32, on peut voir 2 blocs notariés, l’un proposé par le générateur de blocs au rang 1 et l’autre proposé au rang 2, et la même chose se produit à la hauteur du bloc 34. Nous pouvons également voir que les blocs d’une hauteur de 36 sont également explicitement confirmés, comme identifiés par le symbole F. Cela signifie que n-f copies de différents noeuds ont pris en charge la confirmation finale du bloc, ce qui signifie que ces copies de noeud (ou du moins les copies honnêtes de noeud de celles-ci) ne prennent en charge la notarisation d’aucun autre bloc. Tous les ancêtres dont le bloc est rempli de gris sont considérés comme ayant reçu une confirmation finale implicite.

**3.2.5 Impartialité **

L’équité est le fondement du consensus, de sorte qu’un autre attribut important dans les protocoles de consensus est l’équité. Plutôt que d’établir une définition universelle, nous observons simplement que l’invariance de la vie implique une propriété d’équité utile. Pour récapituler, l’invariance signifie essentiellement que dans n’importe quel tour, lorsque le masternode est honnête et que le réseau est synchronisé, le bloc proposé par le masternode sera également finalisé. Dans le tour où cela se produit, le nœud maître honnête s’assure en fait qu’il contient toutes les entrées qu’il connaît dans la charge du bloc (en fonction des limites de module de la taille de charge). Donc, grosso modo, toute entrée qui est propagée à un nombre suffisant de copies de nœud sera très probablement incluse dans le bloc final confirmé dans un délai raisonnable.

3.3 Couche de routage

Comme mentionné précédemment, l’unité de calcul de base dans le circuit intégré s’appelle un réservoir. Le circuit intégré fournit l’environnement d’exploitation dans lequel les programmes peuvent être exécutés dans le réservoir et peuvent communiquer (par message) avec d’autres réservoirs et des utilisateurs externes. La couche de consensus emballe l’entrée dans la charge du bloc, et lorsque le bloc est confirmé par le plus rouge, la charge correspondante est transmise à la couche de routage des messages et traitée par l’environnement d’exécution. La couche d’exécution met ensuite à jour l’état dans le réservoir correspondant de la machine d’état de réplication et transfère la sortie à la couche de routage des messages pour traitement.

Il est nécessaire de distinguer deux types d’entrées :

Message d’entrée : message d’un utilisateur externe.

Messages inter-sous-réseaux : messages provenant de chars d’autres sous-réseaux.

On peut également distinguer deux types de sortie :

Réponse au message d’entrée : réponse au message d’entrée (qui peut être récupérée par des utilisateurs externes).

Messages inter-sous-réseaux : messages transmis à d’autres réservoirs de sous-réseau.

Lorsque des charges issues d’un consensus sont reçues, les entrées de ces charges sont placées dans différentes files d’attente d’entrées. Pour chaque réservoir C d’un sous-réseau, il existe plusieurs files d’attente d’entrée : un message d’entrée vers C, un réservoir C’séparé pour communiquer avec C, et un message inter-sous-réseau de C vers C’.

À chaque tour, la couche d’exécution consomme une partie des entrées de ces files d’attente, met à jour l’état de réplication dans le réservoir correspondant et place les sorties dans une file d’attente différente. Pour chaque réservoir d’un sous-réseau, il existe plusieurs files d’attente de sortie : pour chaque réservoir qui communique avec, il existe une file d’attente pour les messages inter-sous-réseaux de C à C’. La couche de routage du message prend les messages dans la file d’attente de messages et les place dans le trafic de sous-réseau à sous-réseau pour être traités par le protocole de transport entre sous-réseaux, qui transmet en fait les messages à d’autres sous-réseaux.

En plus de ces files d’attente de sortie, il existe également une structure de données historique pour les messages d’entrée. Une fois qu’un message d’entrée a été traité par le réservoir, la réponse à ce message d’entrée est enregistrée dans cette structure de données. À ce stade, l’utilisateur externe qui a fourni le message d’entrée sera en mesure d’obtenir la réponse appropriée. (Remarque : l’historique des entrées ne conserve pas un historique complet de tous les messages d’entrée).

Il y a deux points qui doivent être clarifiés, tout d’abord, l’état de la réplique de nœud comprend l’état du réservoir ainsi que l’état du système. « État du système » inclut les files d’attente, les flux de données et les structures de données de l’historique d’entrée mentionné ci-dessus. Par conséquent, la couche de routage des messages et la couche d’exécution sont impliquées dans la mise à jour et la maintenance de l’état de réplica du sous-réseau. Cet état doit être mis à jour avec un déterminisme complet, de sorte que tous les nœuds conservent exactement le même état.

Le deuxième point à noter est que la couche de consensus précède la couche de routage des messages et la couche d’exécution, ce qui signifie que tous les forks de la blockchain de consensus ont déjà été résolus avant que la charge ne soit transmise. En fait, la couche de consensus permet un fonctionnement précoce et n’a pas besoin d’être sur le même calendrier que la couche de routage des messages.

L’explication et l’explication de la couche de routage nous permettent de mieux comprendre comment le protocole de consensus est transmis vers et depuis le protocole de consensus via le routage des messages, et comment il est connecté à la couche d’exécution, afin de favoriser la coordination et la cohérence du protocole de consensus.

3.4 Couche d’exécution

L’environnement d’exécution traite une entrée à la fois, qui est prise dans l’une des files d’attente d’entrée et dirigée vers un réservoir, en fonction de l’état de l’entrée et du réservoir, l’environnement d’exécution met à jour l’état du réservoir et peut en outre ajouter des messages à la file d’attente de sortie. et mettre à jour l’historique des entrées (éventuellement avec la réponse au message d’entrée précédent). Au cours d’un tour donné, l’environnement d’exécution traitera plusieurs entrées. Le planificateur détermine quelles entrées seront exécutées dans quel ordre pour un tour donné. Au lieu d’entrer dans trop de détails sur le planificateur, nous allons mettre en évidence certains des objectifs :

Elle doit être déterministe, c’est-à-dire dépendre uniquement des données données ;

Il doit répartir équitablement la charge de travail entre les réservoirs (mais optimiser le débit plutôt que la latence).

Le nombre de travaux effectués à chaque tour est mesuré en cycles et doit être proche d’une quantité prédéterminée.

Une autre tâche que l’environnement d’exécution doit gérer est la situation où l’un des réservoirs d’un sous-réseau produit des messages sur les sous-réseaux plus rapidement que les autres sous-réseaux ne peuvent en consommer. En réponse à cette situation, nous avons mis en place un mécanisme d’autorégulation pour ralentir la cuve de production. Il existe de nombreuses autres tâches de gestion des ressources et de comptabilité qui doivent être gérées par l’environnement d’exécution, mais toutes ces tâches doivent être traitées de manière déterministe.

4

Cryptographie à clé en chaîne

Dans le synopsis, nous expliquons que le protocole de consensus de l’IC utilise également la technique de cryptographie à clé publique - la cryptographie à clé en chaîne, et qu’une partie importante de la cryptographie à clé en chaîne est la signature de seuil. En fait, la cryptographie à clé de chaîne englobe un ensemble complexe de techniques utilisées pour maintenir de manière robuste et sécurisée les machines d’état de réplication basées sur la blockchain au fil du temps, collectivement connues sous le nom de techniques d’évolution de chaîne. Chaque sous-réseau fonctionne à l’intérieur d’époques qui contiennent plusieurs cycles (généralement quelques centaines). La technologie d’évolution de la chaîne permet de nombreuses tâches de maintenance de base qui sont effectuées par époque : nettoyage de la mémoire, avance rapide, modifications des membres du sous-réseau, transfert de secret actif et mises à niveau de protocole.

La compréhension de la technologie d’évolution de la chaîne, c’est-à-dire la compréhension de la mise en œuvre technique de la sécurité du protocole de consensus IC. La technologie d’évolution de la chaîne se compose de deux composants de base : les blocs récapitulatifs et les packages de rattrapage (CUP).

4.1 Bloc récapitulatif

Le premier bloc de chaque époque est le bloc de synthèse. Le bloc récapitulatif contient des données spéciales qui sont utilisées pour gérer les fragments de clé pour différents schémas de signature de seuil. Il existe deux schémas de signature de seuil :

Dans un scénario avec une structure de seuil de f + 1/n, une nouvelle clé de signature est générée pour chaque époque ;

Dans un scénario avec une structure de seuil de n-f/n, la clé de signature est repartagée une fois par époque.

Les scénarios avec des seuils bas sont utilisés pour les balises aléatoires et les bandes aléatoires, tandis que les scénarios avec des seuils élevés sont utilisés pour vérifier l’état de réplication du sous-réseau. Rappelez-vous que le protocole DKG exige que pour chaque clé de signature, il existe un ensemble de transactions, et chaque réplica de nœud peut obtenir son fragment de clé de signature de manière non interactive en fonction de cet ensemble de transactions. Rappelons encore une fois, entre autres, que NNS maintient un registre qui détermine les membres du sous-réseau. Le registre (et les membres du sous-réseau) changent au fil du temps. Par conséquent, les sous-réseaux doivent se mettre d’accord sur la version du registre à utiliser à différents moments et à différentes fins. Ces informations sont également stockées dans le bloc récapitulatif.

4,2 CUPs

Maintenant que le résumé est terminé, jetons un coup d’œil aux packages de rattrapage, ou CUP. Avant d’entrer dans le détail du CUP, nous devons d’abord souligner un détail des balises aléatoires : les balises aléatoires de chaque tour dépendent des balises aléatoires du tour précédent. Ce n’est pas une caractéristique fondamentale du CUP, mais cela influence la conception du CUP. Un CUP est un message spécial (qui n’est pas sur la blockchain) qui contient tout ce dont un nœud a besoin pour fonctionner au point de départ d’une époque sans connaître aucune information sur l’époque précédente. Il contient les champs de données suivants :

La racine de l’arbre de hachage de Merkel pour l’ensemble de l’état répliqué (par opposition à l’état partiel de chaque cycle de validation dans le chapitre 1.6).

époque.

Balise aléatoire pour le premier tour d’époque.

Signature de seuil du sous-réseau pour (n - f)/n pour les champs ci-dessus.

Afin de générer une CUP pour une époque donnée, le réplica de nœud doit attendre que le bloc de synthèse de l’époque ait été finalisé et que l’état d’arrondi correspondant ait été vérifié. Comme mentionné précédemment, l’ensemble de l’état de réplication doit être traité dans une arborescence de Merkle par une fonction de hachage. Bien qu’il existe de nombreuses techniques utilisées pour accélérer ce processus, le coût reste important, c’est pourquoi chaque époque n’est traitée qu’une seule fois. Étant donné que la CUP ne contient que la racine de cet arbre de Merkle, nous utilisons un sous-protocole de synchronisation d’état qui permet au réplica de nœud d’extraire l’état dont il a besoin de l’homologue. Encore une fois, nous avons utilisé beaucoup de technologie pour accélérer ce processus, et c’est toujours coûteux. Étant donné que nous utilisons des signatures à seuil élevé pour les CUP, nous pouvons garantir qu’il n’y a qu’un seul CUP valide à chaque époque et que cet état peut être extrait de nombreux homologues.

4.3 Mise en œuvre de la technologie d’évolution de la chaîne

Nettoyage de la mémoire : étant donné que le CUP contient des informations sur une époque particulière, chaque copie du nœud peut purger en toute sécurité toutes les entrées traitées avant cette époque, ainsi que les messages de la couche de consensus qui ont ordonné ces entrées.

Avance rapide : si un réplica d’un nœud d’un sous-réseau accuse un retard significatif par rapport à son nœud synchrone (parce qu’il est en panne ou déconnecté pendant une longue période), ou si un nouveau réplica du nœud est ajouté au sous-réseau, il peut rapidement revenir au point de départ de la dernière époque sans avoir à exécuter le protocole de consensus et à traiter toutes les entrées avant ce point. Cette copie du nœud peut être effectuée en obtenant la dernière version de CUP. Avec les blocs de synthèse et les balises aléatoires contenus dans les CUP, ainsi que les messages de consensus (pas encore effacés) provenant d’autres copies de nœud, le réplica de nœud peut exécuter le protocole de consensus à partir du point de départ de l’époque correspondante. Le nœud peut également utiliser le sous-protocole de synchronisation d’état pour obtenir l’état de réplication au début de l’époque correspondante, afin qu’il puisse également commencer à traiter les entrées générées par la couche de consensus.

Le diagramme suivant illustre l’avance rapide. Ici, supposons que nous ayons besoin d’un réplica de nœud qui doit rattraper le point de départ de l’époque, (disons) avec une hauteur de bloc de 101 et un CUP. Cette CUP contient la racine de l’arbre de Merkle répliqué avec une hauteur de bloc de 101, un bloc résumé avec une hauteur de bloc de 101 et une balise aléatoire avec une hauteur de bloc de 101. Le nœud utilise le sous-protocole de synchronisation d’état pour obtenir tous les états de réplication de hauteur de bloc 101 de ses homologues et vérifie cet état avec l’arborescence de Merkle dans le CUP. Après avoir obtenu cet état, la copie de nœud peut participer au protocole, obtenir des blocs avec une hauteur de bloc de 102, 103, etc. (et d’autres messages liés au consensus) à partir de l’homologue et mettre à jour la copie de son état de réplication. Si ses homologues ont des blocs confirmés à un niveau supérieur, la copie du nœud traitera (ainsi que notariera et finalisera) ces blocs finalisés obtenus auprès des pairs dès que possible (aussi vite que la couche d’exécution le permettra).

5

Épilogue

À l’instar d’Ethereum, la vision de DFINITY est de construire le « supercalculateur du monde », grâce à l’interprétation partielle et à l’explication technique susmentionnées de son livre blanc. Les CI dans le cadre de cette vision ont une grande opportunité d’être réalisés.

Nous pouvons voir l’innovation technologique et la faisabilité technique de l’IC pour réaliser sa vision à partir du modèle hybride DAO du protocole de consensus, de l’innovation technologique de la génération rapide de blocs et du haut débit, et du système de neurones BNS et de son schéma de gouvernance écologique. Contrairement au code Ethereum actuel, qui est une loi, la gouvernance du code IC ajoute des éléments de sagesse de la foule à la fondation, non pas dans le but d’établir une architecture de code parfaite, mais dans le but que le système soit capable d’ajuster rapidement les règles. Il ne s’agit pas seulement d’une création technologique, mais aussi d’une nature humaine brillante. Dans le monde de la blockchain, l’établissement, le maintien et la modification du consensus ne peuvent pas être simplement codifiés, mais l’essence du noyau doit être les personnes. Un consensus valide et équitable entre les groupes centrés sur l’humain est au cœur de l’industrie de la blockchain et de l’attrait de nombreuses Dapps décentralisées.

Cet article cite et interprète une partie du contenu du livre blanc IC, qui décrit plus en détail NNS, l’état d’authentification de chaque série de sous-réseaux sur la couche de consensus, les appels de requête et de mise à jour des messages d’entrée, la distribution de clé distribuée dans la cryptographie à clé en chaîne, les schémas PVSS, les protocoles de base et les protocoles de repartage, etc. Pour les développeurs qui souhaitent une compréhension plus complète et détaillée de la technologie sous-jacente du circuit intégré, la lecture du livre blanc original peut fournir des explications et des explications plus détaillées.