Actualités du développement Safe 🇫🇷 15 septembre 2022

Ceci est une traduction automatique. L’original en anglais est ici: Update 15 September, 2022

Cette semaine, nous examinons la question de l’autorité. Qui peut faire quoi et de quelles qualifications a-t-il besoin pour le faire ? Le sujet survient alors que nous cherchons à simplifier le code, en supprimant les modèles de filtrage des messages que nous n’utilisons plus et en veillant à ce que les principes fondamentaux soient logiques et faciles à comprendre.

Progrès général

@anselme a implémenté une couche de potins pour gérer les instances manquées lorsque le nouveau système DKG ne parvient pas à se terminer et examine maintenant les cas où nous avons des DKG fractionnés simultanés qui se terminent ensemble. DKG semble assez stable sinon.

Et @roland a pratiquement terminé le passage de SectionChain (une liste liée sécurisée) à la nouvelle conception de Section DAG. Encore un peu de test et nous y sommes.

@qi.ma a recherché des bogues potentiels dans FilesContainers, car les comnets ont récemment mis en évidence certains conflits de version suspects.

Nous avons également creusé certains problèmes de connexion client à partir de nœuds, qui semblent laisser tomber certaines réponses. Et supprimant les étapes de sérialisation inutiles autour de OperationId, allégeant davantage la charge sur les nœuds.

Autorité

Si vous pensez à l’autorité en termes de pouvoir, vous pourriez penser que les aînés, les vieux barbus rusés, auraient le plus d’autorité. Après tout, ce sont eux qui contrôlent tout ce qui se passe dans leur section, y compris le pouvoir de vie et de mort des autres nœuds. Vous auriez tort. Lorsqu’il s’agit d’apporter des modifications au réseau, les nœuds individuels n’ont aucune autorité individuelle. Les adultes n’ont pas leur mot à dire, tandis que les anciens n’ont d’autorité qu’en tant que collectif, par le biais d’un vote de seuil.

En fait, l’acteur le plus puissant est le client - le client est roi si vous voulez. C’est parce que le client peut faire des choses comme éditer des données modifiables (conteneurs) qu’il possède et signer la réédition d’un DBC. Les nœuds ne sont en réalité que des messagers, transmettant des informations sur les opérations et les jugements, et faisant principalement ce qu’on leur dit.

Pourquoi est-ce important ? Eh bien, c’est important parce que nous voulons des lignes de démarcation claires sur qui peut faire quoi. Dans la mesure du possible, nous voulons que l’autorité soit implicite dans les types de données et les opérations et que cela soit contrôlé par la cryptographie, et non par des hiérarchies complexes, et nous voulons les structures d’autorisation les plus simples possibles.

Types de données

Les autorisations sont intégrées aux types de données.
Données immuables
En matière de mutation, les morceaux sont insensibles à l’autorité. Il n’y a aucune autorité sur la planète qui vous laissera modifier les données. Par conséquent, nous n’avons pas à nous soucier de concevoir une logique d’autorisation pour eux.
Cependant, pour stocker un morceau, nous avons besoin d’une autorité, dans ce cas, elle est fournie par la section dans laquelle elle doit être stockée et une fois accordée, cette autorité s’applique pour toujours. SectionAuth est une clé de section valide plus une signature.

Données modifiables
Le stockage des conteneurs nécessite SectionAuth, tandis que leur mutation nécessite ClientAuth - seul le propriétaire doit pouvoir modifier ses données. Ainsi, ce type de données implique implicitement qu’il nécessite une signature client avant de pouvoir être modifié. ClientAuth est une signature client valide.

L’autre type de données mutables est le SectionTree, qui est un arbre dérivé de Genesis. Ici, la situation est un peu différente car il y a effectivement plusieurs propriétaires (toutes les sections), mais chaque section ne peut ajouter qu’une feuille à sa branche particulière avec son SectionAuth.

Les DBC sont un peu plus complexes en ce sens qu’ils nécessitent qu’un client autorise une réémission (ClientAuth) et une section pour la signer (SectionAuth), mais encore une fois jusqu’à ce qu’il ait ces deux bits d’autorité attachés, un DBC est effectivement inutile.

L’important ici est que pour les opérations de données, les nœuds sont de simples porteurs de message et que le message est indépendant du porteur. Peu importe d’où vient le message, et peu importe qui l’a signé. Nous nous soucions seulement que l’élément de données porte le bon type de signature (client ou section) plus une clé.

Dans l’exemple le plus simple, un bloc de données avec une clé de signature de section valide attachée peut voler autour de l’univers, et lorsqu’il revient, le réseau doit l’accepter, car une signature de section sur les données signifie qu’elle existe pour toujours.

Opérations sur les données

En termes d’API REST, les opérations de données ressemblent à ceci :
Les opérations GET ne nécessitent aucune autorisation.
Les opérations PUT nécessitent SectionAuth pour le stockage et une combinaison de ClientAuth et SectionAuth pour le paiement.
Les opérations POST nécessitent ClientAuth pour muter les conteneurs SectionAuth pour muter les feuilles individuelles du SectionDAG

Les transferts de jetons nécessitent une combinaison de ClientAuth et SectionAuth.

Opérations réseau

Les modifications apportées à la composition d’une section en termes d’aînés et d’adultes, de scissions, etc., nécessitent toutes « SectionAuth ». Mais alors que les nœuds individuels n’ont aucune autorité dans ces processus, les anciens au moins ne sont pas simplement des porteurs de messages passifs comme ils le sont avec les données. Par exemple, si un aîné remarque qu’un nœud se comporte de manière dysfonctionnelle, il peut forcer un vote pour savoir s’il devraitd être pénalisé.

Pour que cela fonctionne, les nœuds doivent être identifiables dans certains cas, ce qui signifie qu’ils doivent signer les messages avec leurs clés publiques. Donc, si un client envoie une demande pour un morceau et que ce morceau arrive en retard ou s’il y a une corruption, la signature est une preuve cryptographique irréfutable contre ce nœud et le client peut informer les anciens que c’est un mauvais.

Et pour DKG il est vital que les messages envoyés entre anciens avec leurs partages de vote soient autorisés. L’autorité du message est celle de l’expéditeur et vérifiée par rapport à sa signature sur le message. Cela s’appelle NodeAuth.

OK, mais à quoi ça sert ?

En nous concentrant sur l’autorité et en supprimant les vérifications inutiles, en particulier dans les messages, nous simplifions les opérations autant que possible et nous nous appuyons sur la cryptographie et les types de données pour faire le travail acharné à notre place. Nous avons encore des signatures de messages inutiles suspendues aux itérations précédentes du réseau, et toutes ont un coût en termes de performances et créent de la confusion. Un design épuré et simple est un design efficace.


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