Ceci est une traduction automatique. L’original en anglais est ici: Update 10 November, 2022
Un petit avant-goût des choses à venir cette semaine. Comme vous le savez, les mécanismes de consensus sont au cœur de presque tous les réseaux décentralisés, y compris le bitcoin. En fait, la principale innovation du bitcoin est sans doute le mécanisme de consensus de la blockchain. Mais il y a toujours un compromis. Dans le bitcoin et d’autres chaînes de blocs, c’est le mécanisme de traitement des fourches, ce qui signifie que deux versions peuvent exister pendant longtemps (en théorie pour toujours) et doivent être résolues via PoW, qui est le talon d’Achille de bitcoin.
En tant que tels, nous avons tenu à éviter les algorithmes de consensus (tels qu’ils sont généralement compris) dans la mesure du possible - les fourmis les utilisent-elles ? Mais il y a des occasions où, avec les réseaux informatiques, ils sont probablement nécessaires. C’est ce sur quoi Mostafa s’est penché, et nous approfondirons cela dans les semaines à venir.
Progrès général
En ce moment, nous réorganisons le processus de la machine CI pour qu’il soit un peu plus léger et plus sûr. C’est vraiment le bébé de @chriso et il a travaillé pour mettre tous les éléments en place, y compris les API, les instances EC2, les fonctions sans serveur et la protection DDoS. Presque là maintenant.
Nous nous efforçons de supprimer autant de verrous en lecture/écriture que possible lors de la réplication des données. C’est principalement le domaine de @joshuef. Josh et @bochaco ont également à peu près terminé le refactor sn_node pour réintroduire les communications bidirectionnelles dans le code. C’est quelque chose que nous avions avant mais c’est devenu très complexe. Simplifier la base de code signifie que nous pouvons la ramener. Toujours en test, mais nous constatons déjà des améliorations de stabilité.
@roland supprime la fonction traceroute. Ça provoque du ballonnement, ça ne s’avère pas utile (et encore moins avec les flux bi-directionnels), donc on s’en débarrasse.
Mécanismes de consensus
Il existe de nombreux mécanismes de consensus en informatique. Certaines sont de simples affaires binaires, d’autres sont des mécanismes complexes à plusieurs variantes. La chose importante à comprendre, cependant, est qu’ils ne sont que des outils pour un travail, et rien de plus. Ce travail consiste à garantir l’accord entre les entités pendant un certain temps. Mais tout comme les gens doivent s’entendre sur certaines règles pour s’entendre, comme par exemple sur quel côté de la route conduire, ils n’ont pas besoin de s’entendre sur tout pour vivre côte à côte. Contrairement aux blockchains, les gens n’ont pas besoin d’une commande à l’échelle du système, et Safe non plus. Nous devons donc choisir le bon outil pour le travail, le faire uniquement lorsque cela est nécessaire et, surtout, nous assurer que nous ne sommes pas bloqués par ce choix.
Safe est un réseau décentralisé asynchrone. Les choses changent tout le temps; « État », c’est-à-dire un instantané de la compréhension actuelle que nous avons du monde, est presque toujours différent du point de vue de chaque nœud individuel. Et pourtant, pendant une courte période au moins, ces nœuds doivent s’entendre.
Le consensus est essentiellement un mot pour dire qu’à un moment donné, tous ceux qui comptent ont besoin de voir le même état pour qu’une action se produise.
Alors, comment les nœuds parviennent-ils à un accord sur l’état ? Eh bien, cela dépend des circonstances, de l’action et de la portée.
Souvent sur Safe, on arrive à s’entendre grâce à l’anti-entropie (AE). Il s’agit d’un simple échange d’informations pour nous assurer que nous parlons aux anciens actuels d’une section. En tant que tel, AE pourrait être considéré comme un mécanisme de consensus local simple, binaire, bien que nous le considérions simplement comme une vérification que les parties qui doivent être synchronisées sont toutes sur la même longueur d’onde. Certes, c’est loin de l’ordre total de bitcoin à l’échelle du système.
Lorsque les anciens s’entendent sur un plan d’action, nous utilisons la génération de clé distribuée (DKG) pour nous assurer qu’une super majorité d’anciens sont d’accord. C’est aussi un type de consensus local, binaire (oui/non), bien que nous n’ayons pas tendance à utiliser ce mot.
Ensuite, nous avons des types de données répliquées sans conflit (CRDT), que nous utilisons pour les données modifiables. Ceux-ci ont une horloge logique, permettent un accès simultané et finissent par résoudre les fourches en un seul état. Tout cela se passe sans aucun consensus. Les fourches sont fines et se résolvent d’elles-mêmes.
Mais il y a d’autres situations où nous ne pouvons pas tolérer un fork, même pour une nanoseconde, et c’est là que, en tant que réseau décentralisé asynchrone, nous avons définitivement besoin d’un consensus.
Et il y a des zones grises où nous pouvons tolérer les fourches pendant un certain temps, mais devons éventuellement les résoudre. Ceux-ci peuvent nécessiter un mécanisme de consensus formel.
Alors, où les fourmis pourraient-elles avoir besoin d’aide technique ? L’un recrute de nouveaux nœuds à partir d’une liste de peut-être des centaines de candidats, tous avec un âge de nœud de zéro - lequel choisissons-nous ? Ici, nous devrons peut-être compter sur une intelligence supérieure que le groupe peut fournir.
Un autre est l’adhésion - gérer les nœuds qui se trouvent dans une section. DKG est un instrument émoussé et ne gère pas très bien les cas extrêmes comme plusieurs jointures et sorties simultanées.
Et nous aurons peut-être besoin d’un niveau de consensus plus élevé pour gérer les DBC entre les sections afin d’éviter les doubles dépenses.
C’est sur quoi l’équipe - en particulier Mostafa et @davidrusu - se concentre en ce moment : mettre en place le bon protocole au bon endroit au bon moment. A bientôt les amis !
Liens utiles
- Site Web du réseau sécurisé
- Safe Network Primer
- Principes de base du réseau
- Feuille de route
- Glossaire
N’hésitez pas à répondre ci-dessous avec des liens vers les traductions de cette mise à jour de développement et les modérateurs les ajouteront ici.
En tant que projet open source, nous sommes toujours à la recherche de commentaires, de commentaires et de contributions de la communauté. Ne soyez donc pas timide, rejoignez-nous et créons ensemble le réseau sécurisé!