Actualités du développement Safe 🇫🇷 26 mai 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 26 May 2022

Notre objectif principal avec Safe Network est la permanence des données. Nous stockons des copies de données sur des appareils qui, statistiquement, ne sont pas susceptibles de se trouver dans la même région en cas, par exemple, d’une coupure de courant massive ou d’une panne d’Internet imposée par le gouvernement. À cette fin, plus il y a de copies, mieux c’est, mais cela impose des exigences en matière de stockage et, en particulier, de bande passante réseau. Cette semaine, nous examinons une approche pour résoudre ce problème, qui devrait permettre plus de redondance avec moins de flux de données.

Progrès général

@Anselme a corrigé un bogue consensuel, implémentant l’anti-entropie pour le transfert ainsi que les générations. Des tentatives de jointure plus complètes (où nous nous assurons que nous sommes dans l’état actuel de la section) ont également été fusionnées :muscle: .

@Chriso creuse dans la mise en œuvre de DBC et a déjà effectué toutes les modifications CLI pour transmettre un DBC à un nouveau propriétaire. Il tourne maintenant son attention vers le côté sn_api pour attribuer le changement de propriétaire DBC.

Nous pouvons également signaler des progrès sur le front de l’observabilité avec @yogesh faisant de bons progrès avec les messages traceroute, en s’assurant que tous les flux de messages (fichier et registre) ont une réponse traceroute vers le client des adultes et sont enregistrés dans les tests.

Et @davidrusu a passé le mot en participant à une autre rencontre CompSci de Toronto pour parler à travers les CRDT Tree. « Une excellente discussion tout autour », rapporte-t-il, et un excellent endroit pour recruter des parties intéressées pour Safe Labs.

Dans le monde sûr au sens large, le projet communautaire en cours pour soutenir MaidSafeCoin sur le protocole ERC20 se poursuit sans relâche, et nous sommes heureux d’annoncer que ces efforts continuent de porter leurs fruits ! Ainsi, en plus d’Uniswap, eMAID est désormais également ouvert à la négociation sur P2PB2B !

Vous pouvez remercier les membres dévoués de la communauté tels que @Sotros25 et @Mightyfool qui ont pris sur eux de faire avancer ce sujet en permanence :clap:

Optimisation du transfert de données

Quand quelqu’un fait une requête GET, ce kick démarre un certain nombre de processus. Tout d’abord, la demande est transmise aux anciens dans quelle section le morceau est stocké. Les anciens calculent ensuite quels sont les quatre adultes qui stockent le morceau - les quatre XOR les plus proches de l’adresse du morceau - et chacun de ces adultes transmet leur copie du morceau aux anciens, qui les renvoient ensuite au client demandeur.

Cela fournit une redondance, il y a toujours quatre adultes avec une copie du morceau, et nous donne également un moyen de surveiller les performances. Si un adulte est nettement plus lent ou moins fiable, il peut être rétrogradé. Mais cela a un prix.

Si le client contacte les sept anciens de la section pour demander un bloc « A » de 1 Mo, et que chaque ancien demande à son tour le bloc A aux quatre adultes qui le détiennent et le renvoie au client, alors potentiellement c’est 28 Mo (4x7) passant sur le réseau pour une seule requête GET de 1 Mo.

Actuellement, nous utilisons un système de transition où le client contacte trois aînés au hasard et ces aînés contactent les quatre adultes détenant le bloc A - nous avons donc potentiellement 12 Mo (3x4) de données circulant sur le réseau pour une demande de 1 Mo - mieux, mais toujours pas génial. Et réduire les contacts à trois aînés a un coût : si nous n’avons que trois aînés qui interagissent avec les adultes, nous n’avons plus de majorité qualifiée pour décider si l’un des adultes est dysfonctionnel, ce qui rend le suivi des dysfonctionnements plus complexe.

Une solution que nous examinons maintenant est les algorithmes de dispersion d’informations (IDA, également connus sous le nom de codage d’effacement). Cela pourrait nous aider à réduire considérablement le volume de transfert de données par GET, en demandant aux adultes de transmettre une partage des données aux aînés plutôt que la totalité. Les anciens transmettent ensuite ces partages de données au client, qui les réassemble et, voila, le bloc A est recréé. Potentiellement, cela pourrait réduire les flux sur un GET à seulement 1,4 Mo pour un morceau de 1 Mo.

Alors, comment ça marche? Tout d’abord, nous ne proposons pas de remplacer la réplication par un IDA. Certains projets le font (par exemple Solana) mais pour nous, il y a trop de compromis. Ainsi, tout comme maintenant, si un adulte se déconnecte, ses données sont entièrement répliquées sur un autre adulte. Le changement est que les adultes pourront diviser le morceau A en sept morceaux à l’aide d’un IDA et ne transmettre qu’un seul morceau aux aînés sur demande, plutôt que le morceau entier, ce qui signifie que beaucoup moins de données sont échangées.

Une fois qu’il a collecté cinq des sept pièces, le client peut réassembler le morceau A.

Ce chiffre de cinq sur sept a sans aucun doute allumé quelques ampoules mentales :ampoule:, car c’est le même seuil que nous utilisons pour le consensus BLS, mais IDA est une bête différente de la cryptographie à seuil, conçue pour optimiser le stockage et le transfert de données plutôt que le partage secret. Au cas où vous vous demanderiez d’où vient le 0,4 supplémentaire (le transfert d’un morceau de 1 Mo à l’aide d’IDA nécessite 1,4 Mo de flux de données), il s’agit d’une surcharge inévitable due au fonctionnement de l’algorithme.

Donc, moins de stress sur le réseau et le client aussi, et bien sûr les sept aînés sont maintenant en contact avec les adultes, ce qui rend le consensus sur le dysfonctionnement beaucoup plus simple.

D’autres optimisations devraient également être possibles avec cette architecture. En raison des récents changements d’adhésion, nous savons maintenant quel adulte des trois tenant le morceau A est en fait le plus proche. Ainsi, plutôt que de demander le morceau A, le client peut le demander directement pour le premier morceau A[0] et les aînés iront directement à l’adulte le plus proche ; la deuxième pièce A[1], les aînés demanderont à l’adulte suivant le plus proche, et ainsi de suite. Tout échec est simplement réessayé sur un autre adulte. Ceci est plus efficace et signifie que nous pouvons potentiellement augmenter le nombre de répliques - des adultes détenant le bloc A - sans aucune contrainte supplémentaire significative sur le réseau, avec des gains évidents pour la redondance des données.


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