Actualités du développement Safe 🇫🇷 25 novembre 2021

Ceci est une traduction automatique. L’original en anglais est ici: Update 25 November 2021

Nous avons tous convenu que cette semaine serait un bon moment pour examiner ce que Safe apporte à la table en termes de consensus distribué. En fait, quelques-uns d’entre nous ont pensé que c’était une idée stupide, mais une majorité qualifiée a voté pour aller de l’avant, et c’est tout ce qui compte :stuck_out_tongue_winking_eye:. Ainsi, cette semaine, nous expliquons comment Safe comble le fossé entre la blockchain et les protocoles qui sous-tendent les bases de données distribuées comme Cassandra et AWS DynamoDB.

Progrès général

@ChrisO a terminé la tâche de publication continue de sn et sn_api dans le référentiel safe_network. Cela signifie que nous sommes de retour dans un endroit où nous pouvons librement fusionner les commits et être confiants dans la version suivante. Avec cela en place, @chrisO passe à l’examen de la CLI et à sa stabilisation avant de l’inclure dans les versions.

David Rusu a mis en place une démo sur les signatures de bague et Safe. Attendez-vous à une mise à jour bientôt (attention : ce sera « lourd sur le calcul »). :homme qui court:

@qi_ma , @yogesh et @lionel.faber ont refactorisé la caisse DKG et safe_network (notre principale source actuelle de casse-tête car les promotions des anciens s’arrêtent avant sept heures) pour réduire le nombre de messages à diffuser et augmenter stabilité du démarrage et de la division de la section. Le travail se poursuit là-bas, mais nous atteignons définitivement les problèmes sous-jacents.

Il y a également eu du travail sur l’activation de la priorité de gestion des messages pour les nœuds, bien que cela soit toujours en cours d’évaluation. Cela devrait nous aider à garantir que les changements plus importants sont traités plus attentivement que les messages moins importants. Ce blocage des messages de faible priorité était involontairement présent dans la base de code moins concurrente, mais a été perdu lorsque nous avons libéré des nœuds pour profiter davantage du processeur. Cela devrait donc, espérons-le, ramener un peu d’ordre dans les opérations du nœud.

Consensus distribué et comment Safe comble le fossé

Le cœur de Safe Network, et ce qui le rend particulièrement utile pour une grande variété d’objectifs, est la façon dont il parvient à un accord entre des nœuds distribués qui peuvent ne pas être fiables.

Dans les années 1980, un accord décentralisé sans référence à un oracle central était considéré comme impossible, mais ensuite, Leslie Lamport est venu prouver que tout le monde avait tort. En fait, il essayait en fait de prouver qu’il était en fait impossible d’avoir de la cohérence et de la tolérance aux pannes, mais il est ensuite tombé sur une réponse, qui était de promouvoir des leaders temporaires et d’assurer l’ordre des opérations à l’échelle du système.

L’algorithme résultant était Paxos, pour lequel Lamport a finalement remporté un prix Turing. Paxos garantit une cohérence éventuelle dans un réseau distribué où certaines machines peuvent ne pas être fiables. Cela signifie que les réseaux peuvent éviter d’avoir un point de défaillance unique - n’importe quel nœud, même un leader, peut tomber et le système fonctionnera toujours.

Paxos s’est avéré un énorme succès et a engendré des centaines d’imitateurs et de variantes. Il est principalement utilisé pour répliquer de manière fiable les données entre les machines distribuées et constitue la base des bases de données cloud comme AWS DynamoDB et Google Chubby.

Il le fait en essayant de décider d’un ordre total d’opérations. Il y a deux étapes dans une opération Paxos - promettre et s’engager. Une promesse est un accord pour faire quelque chose et un engagement est l’action de le faire. Une majorité de nœuds doivent être d’accord avant de faire une promesse de muter l’état ou de modifier les autorisations. Une majorité est également nécessaire pour passer d’une promesse à un commit, par exemple une écriture ou un changement de propriétaire.

Les réseaux distribués étant asynchrones, l’ordre est maintenu en attribuant à chaque opération un identifiant numérique et en augmentant les identifiants au fil du temps. En cas de conflit sur une promesse, le plus récent (ID le plus élevé) l’emportera généralement.

À Paxos, il y a toujours un nœud leader. Dans le cas d’un commit, le leader ajoute chaque op à son log et demande aux autres serveurs de faire de même. Une fois qu’il a reçu une réponse de la majorité des serveurs de son cluster, il valide le changement.

Un nouveau chef est élu lorsque l’actuel ne répond pas dans un certain délai. Lorsque cela se produit, n’importe quel nœud peut se mettre en avant. Pour devenir leader, un nouveau candidat doit obtenir la majorité des voix. Il doit ensuite mettre à jour ses logs en se synchronisant avec d’autres nœuds. Les nœuds votants envoient leurs logs avec leurs votes pour faciliter cela, mais la mise à jour peut encore prendre beaucoup de temps, pendant laquelle le cluster est inactif, ce qui peut être problématique.

Raft (2014), qui est basé sur Paxos (ou plus précisément Multi-Paxos, la version mise à jour) simplifie le processus de vote et d’autres opérations, mais est essentiellement une modification de Paxos. Raft a maintenant dépassé Paxos en termes d’activité de projet.

Jusqu’ici tout va bien, mais bien que Paxos/Raft soient des solutions élégantes pour un consensus distribué, leur mise en œuvre nécessite beaucoup d’extras s’ils doivent fonctionner comme prévu.

Cloudflare est basé sur Raft et en 2020, il a subi une panne majeure en raison du processus d’élection du leader qui entre ensans boucle. Pour garantir la vivacité, des optimisations PreVote et CheckQuorum sont également nécessaires, ainsi que bien d’autres encore. Pas si simple maintenant.

L’extension des fonctionnalités de Paxos et Raft et d’autres variantes les rend complexes, ce qui, dans l’industrie technologique, signifie qu’ils deviennent propriétaires. Si seulement Amazon sait comment configurer DynamoDB de manière fiable, Amazon ne révélera pas ce secret à la hâte.

Mais le principal inconvénient de ces algorithmes est leur hypothèse selon laquelle les nœuds ne s’entendent pas, ne mentent pas ou ne tentent pas de subvertir le protocole, c’est-à-dire que les échecs byzantins ne se produisent pas. Si vous êtes Amazon, vous pourrez peut-être garantir que puisque vous contrôlez votre propre matériel et vos propres logiciels, mais pour les réseaux publics mixtes, vous ne pouvez en aucun cas le faire. C’est pourquoi vous n’entendez pas beaucoup parler de Paxos et al dans le monde de la cryptographie, même si cela sous-tend les Goliaths technologiques.

Entrez Satoshi

Tolérants aux pannes byzantins (BFT), les algorithmes décentralisés sont dominés par la blockchain, qui a résolu ce problème difficile grâce au génie de Satoshi. Les blockchains sont hautement ordonnées et BFT. Mais l’ordre total est essentiel et cela bloque ou ralentit le multi-accès et la simultanéité. Les blockchains ne sont pas des systèmes à usage général, mais des systèmes conçus spécifiquement pour l’échange de valeur. Les blockchains ne peuvent pas remplacer Paxos et ses dérivés car ils sont optimisés pour sécuriser et partager les transactions, pas les opérations de données.

Écartez-vous de Satoshi, Safe Network est là

Le coffre-fort est différent. Il comble le fossé entre les transactions de stockage permanent des blockchains et la gestion des données distribuées de Paxos et Raft.

Les données sont stockées pour toujours sans PoW lourd.

Il n’y a pas de leader global à attaquer, pas même temporaire (comme le vainqueur du PoW dans une blockchain). Au lieu de cela, la responsabilité est répartie entre les supermajorités de section et celles-ci consistent en des groupes en constante évolution (mais convenus).

Ensuite, nous avons le problème de la tolérance aux pannes. Paxos et Raft utilisent le concept de tolérance aux pannes (CFT). Mais les réseaux publics nécessitent une tolérance aux pannes byzantine. La différence semble subtile mais ce n’est pas le cas. La tolérance aux pannes en cas de crash couvre le nombre de nœuds pouvant tomber en panne entre les exécutions de maintenance, tandis que la tolérance aux pannes byzantine correspond au nombre de nœuds pouvant devenir malveillants à tout moment. CFT est calculable, BFT ne l’est pas.

Safe est BFT et conçu pour être prêt pour les conditions du monde réel où les choses échouent et les méchants errent. L’âge des nœuds garantit que les nœuds byzantins sont rapidement déresponsabilisés. En revanche, Paxos/Raft sont facilement attaqués en promouvant un leader qui ne répond pas ou qui répond trop vite. Ils s’appuient également dans une certaine mesure sur les horloges des serveurs pour gérer le consensus. Ils semblent être simples (comme le font les réseaux Kademlia) mais ils ont besoin de beaucoup de conditions préalables pour les faire fonctionner, y compris du matériel et des logiciels de confiance, pas de traversée NAT, etc.

Le coffre-fort est entièrement décentralisé. AE, BRB et CRDT éliminent l’exigence d’un accord à l’échelle du réseau pour assurer la cohérence, et il n’y a pas besoin d’une commande totale. Même Amazon admet que pour les grands systèmes distribués, le jeu est une cohérence éventuelle et non un ordre total (la vitesse de la lumière est une limite stricte). Essayer d’obtenir une commande totale à grande échelle conduit inévitablement à de faibles performances.

Ainsi, Safe franchit de nombreuses frontières : éventuelle forte concurrence sur un réseau public, BFT à usage général et données permanentes.


Liens utiles

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é!