Ceci est une traduction automatique. L’original en anglais est ici: Update 14 October, 2021
Nous avons presque atteint une mini-étape aujourd’hui (90 % du chemin parcouru !) Qu’est-ce que cela signifie et pourquoi est-ce important? @ChrisO explique tout ci-dessous.
Progrès général
Comme vous le savez probablement, avec des fonctionnalités telles que AE, le réseau est conçu pour ressembler à « CRDT » avec une cohérence éventuelle garantie. Cela signifie que si nous envoyons un message ou un morceau de données et qu’il n’est pas reçu immédiatement, cela n’a pas d’importance car nous attendons ou renvoyons simplement. Aucune synchronisation complexe requise.
Une grande partie du travail que nous faisons en ce moment consiste à faire fonctionner correctement ce comportement de type CRDT. Le comportement en boucle que nous avons vu avec la messagerie de nœud à nœud semble être en grande partie corrigé maintenant.
Les messages AE indiquent au client s’il doit mettre à jour sa compréhension des sections auxquelles il s’adresse. Nous avons ajouté quelques ajustements au client afin qu’il pré-contacte tous les nœuds d’amorçage pour obtenir une vue mise à jour du réseau avant de lui permettre de passer à l’exécution de commandes. Nous avons également ajouté une petite attente pour METTRE toutes les données sur le réseau, car la commande revenait auparavant immédiatement, tandis que la gestion des messages AE se faisait en arrière-plan. Cela n’a pas été un problème avec les tests de la bibliothèque safe_network car ils gardent tous le client à portée de main, mais ce n’est pas le cas de la CLI, donc cela aurait pu conduire à des problèmes où un client ne connaissait pas une partie du réseau, et a manqué la gestion/le renvoi de la commande lorsque ces messages AE sont arrivés.
Nous constatons également quelques anomalies avec les tests CI (intégration continue). Il peut être difficile de dire si le problème vient du réseau ou des tests CI eux-mêmes. C’est le genre de choses que les réseaux de test nous aident à comprendre. Merci encore à tous ceux qui sont restés coincés. Il devrait y avoir un autre candidat à vérifier sous peu, car nous obtenons la fusion API + CLI. Nous envisageons également des options pour un cluster ELK cloud pour stocker les journaux de testnet de la communauté et les rendre consultables.
@Jimcollinson a continué à examiner n des m flux d’authentification utilisant les partages de clés BLS. Pour déverrouiller votre coffre-fort, vous pouvez choisir d’utiliser un combo mot de passe + phrase secrète (ou code QR) avec une clé d’appareil sur votre téléphone en réserve (2 sur 3). Si vous oubliez votre mot de passe, vous pouvez utiliser la phrase secrète et la clé de l’appareil. Avec vos informations d’identification principales (mot de passe et phrase secrète), vous pouvez également créer de nouvelles clés sur des appareils supplémentaires. Ainsi, si vous êtes vraiment oublieux, vous pouvez déverrouiller votre coffre-fort en utilisant plusieurs appareils ou des phrases secrètes de sauvegarde. L’idée ici est d’obtenir la flexibilité nécessaire pour s’adapter à divers modèles de menaces de sécurité, équilibrés par la commodité, tout en tolérant la perte d’informations d’identification.
Sur le front de DBC, @danda a creusé davantage dans les dénominations. Attendez-vous à plus de détails sur toute la ligne.
Un référentiel unique
En juin, nous avions terminé quelques travaux pour fusionner plusieurs référentiels qui constituaient le code du réseau, en un single large référentiel. En raison du fait que le code de ces référentiels était si étroitement lié, cela n’avait aucun sens pour eux d’évoluer indépendamment, et en fait, il était activement problématique pour eux de le faire. Cela rendait le réseau difficile à déboguer et à tester, et maintenir toutes les versions à jour et synchronisées était une corvée importante. Le référentiel unique combine tout ce code dans différents modules de la même caisse, avec un seul numéro de version.
Cependant, dans cette entreprise, quelques référentiels ont été laissés pour compte, à savoir sn_api et sn_cli. L’API et la CLI sont en fait un peu différentes des référentiels mentionnés précédemment, en ce sens qu’elles ne sont pas des composants essentiels du réseau lui-même, mais plutôt leur objectif est de nous permettre d’utiliser le réseau. En raison des ressources limitées axées principalement sur le développement du réseau, le code de l’API et de l’interface de ligne de commande était devenu obsolète, et il s’agissait d’un travail important pour les mettre à jour. Donc, même si nous voulions aussi les fusionner, nous n’étions pas vraiment en mesure de le faire.
Nous avons travaillé pour mettre à jour la CLI et l’API, donc heureusement, nous sommes maintenant en mesure de les fusionner, et nous sommes heureux de dire que c’est presque là. sn_api et sn_cli seront placés à côté du code du réseau, donc le référentiel safe_network se compose de trois caisses qui seront mises à jour et déployées en même temps.
Il est important d’être conscient qu’il s’agit en fait d’un changement assez important et pas simplement d’une commodité administrative. Certains des avantages :
- Tout dans la même caisse élimine la confusion sur les versions de la CLI et de l’API compatibles avec quelle version du réseau. Tous ceux de n’importe quelle version seront compatibles.
- Lorsque le code du réseau est mis à jour avec des changements de rupture, le développeurr sera obligé de faire une mise à jour de l’API et de la CLI. Cela empêche l’API et le code CLI de redevenir obsolètes.
- Les nouvelles versions du réseau sont immédiatement disponibles pour être testées avec une CLI compatible avec le réseau.
Sur le dernier point : maintenant que nous avons vu et accueilli la communauté s’impliquer davantage dans le lancement de testnets, avec une combinaison CLI/API/réseau publiée en même temps, nous pouvons créer un cycle de test et de publication beaucoup plus court, où essentiellement, toute nouvelle version du référentiel safe_network est immédiatement disponible pour les tests de la communauté. En fin de compte, cela a un grand potentiel pour nous aider à itérer plus rapidement vers un candidat au lancement.
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é!