Rythme de certifications -- promesse/intention de certification

Nodes Duniter-v2s
1

Plop,

C’est bien pénible cette histoire de délai minimal entre deux certifications. Est-ce que ça ne pourrait pas être un peu assoupli ?

Par exemple hier je voulais émettre des certifs pour faire avancer ce sujet, et bien entendu à la deuxième certification :

$ bin/gcli identity certify 14154
Mnemonic: 
transaction submitted to the network, waiting 6 seconds...
Anyhow(Runtime error: Pallet error: Cert::NotRespectCertPeriod

Caused by:
    Pallet error: Cert::NotRespectCertPeriod)

Error: Anyhow(Runtime error: Pallet error: Cert::NotRespectCertPeriod

Caused by:
    Pallet error: Cert::NotRespectCertPeriod)

J’imagine que les gens qui vont aux événements monnaie libre reviennent avec une pile de certif à émettre. Pas seulement pour les nouveaux entrants, mais aussi pour tisser de nouveaux liens dans la toile de confiance. Et j’imagine que comme moi, ils aimeraient pouvoir émettre leur série de certifs et passer à autre chose.

Pourquoi imposer un tel délai de plusieurs jours ? Quel est le risque à le descendre à 30 secondes par exemple ? De toute façon le nombre de certifications est limité dans le temps, donc on de devrait pas être exposé au risque de spam ou DoS, non ?

2 Likes
2

Dans Duniter v1, c’était le rôle de la piscine de mémoriser les documents en attente, et ils n’était ajoutés en blockchain que quand ils pouvaient l’être. C’était la source de bugs et comportements non déterministes.
Dans Duniter v2, soit une certification peut être écrite immédiatement et dans ce cas elle l’est, soit le délai n’est pas respecté et dans ce cas là elle échoue.

Je suis d’accord que c’est pénible de ne pas pouvoir ajouter une liste de certifications et qu’elles se fassent automatiquement quand l’identité source est disponible pour certifier. Il y aurait plusieurs manières d’obtenir à nouveau une fonctionnalité similaire.

1. une fonctionnalité côté client

Le client pourrait demander de signer à l’avance plusieurs transactions et les soumettre au réseau de manière différée.

  • ça nécessite que le client soit à nouveau en ligne au moment désiré
  • il ne faut pas que d’autres transactions aient été émises entre temps, sinon le nonce ne sera plus valide

2. une fonctionnalité côté blockchain générique

Pour l’instant, schedule n’est disponible que pour root, mais on pourrait autoriser l’utilisateur à planifier un call sous certaines conditions. Mais il revient donc à la blockchain de se souvenir des actions à effectuer et de les effectuer de manière automatique, ce n’est pas trivial, ça peut poser des problèmes de scalabilité, il faut réfléchir. De plus, il y a toujours la possibilité d’échec de l’action programmée.

3. une fonctionnalité côté blockchain dédiée

On pourrait écrire un scheduler dédié aux certifications qui intègre des concepts métier, mais il y a toujours la question du coût des traitements automatiques, et c’est sûrement overwkill.

4. une fonctionnalité côté serveur tiers

On pourrait aussi ajouter une nouvelle API de certification : la soumission d’un document de certification (daté, signé, et ciblant un bloc futur…). Un logiciel serveur tiers serait responsable de soumettre au réseau ces documents au moment demandé.

Note : ça peut aussi être la responsabilité du destinataire de la certification

Que fait-on d’une certification programmée, mais dont l’émetteur n’est plus membre au moment où la certification devrait être émise ? Quelle limite pose-t-on à la programmation de certifications pour éviter de saturer la blockchain ? … bref, ça pose plein de question.

3

Ce délai sert à ralentir les attaques sur la WoT.

5. plafond glissant (changement des règles WoT)

Pour le rendre plus adapté au mode de certification assez répandu de “plein de certs d’un coup”, il pourrait être remplacé par un plafond glissant, par exemple 6 certifications par 30 jours glissants (pour garder la même fréquence maximale). C’est simple à implémenter, rapide à calculer et peu gourmand en mémoire.

Un tel changement devrait être décidé avec la communauté.

8 Likes
4

Bonjour,
ok je ne code pas mais je me permets d’intervenir en tant qu’utilisatrice juniste.
Je trouve que ce que soulève @Pini

est très très intéressant et très utile. Donc malgré l’intervention de @HugoTrentesaux

dont je n’ai aucune réponse factuelle, si on pouvait raccourcir le délais des certifications ce serait vraiment chouette.

Tout en tenant compte de ce que @tuxmain soulève

Comment pouvoir raccourcir le délais entre les certifications tout en se sécurisant et éviter des attaques ?

Mes arguments :slight_smile:

  • lors des gmarchés nous pourrions certifier plusieurs personnes : disons une par minutes ou une par jour
  • plus de junistes pourraient rentrer dans la toile de confiance sur l’instant présent
  • ces mêmes junistes auraient plus de confiance (ou d’aisance avec l’outil informatique) dans la toile de confiance et seraient à leur tour certificateurs/trices
  • nous augmenterions bien plus rapidement qu’actuellement
  • un million de junistes bien plus rapidement pour faire faire basculer notre société ?
    Bien à vous :pray:
5

Il y a aussi le problème que les certifications actuelles sont de niveau « fort » là où des certifications de gmarché sont plutôt de niveau faible, ce qui donne envie de les enchaîner rapidement.

Il manque les liens faibles, c’est clair, et sont ces liens qui permettront vraiment à la G1 de grossir significativement. Mais on n’y est pas :slight_smile:

Cf Liens faibles / intermédiaires / forts

6 Likes
6

Oui, mais plus très loins, on voit le bout là je crois non ?

D’abords la migration au plus proche des règles existantes, stabilisation de l’écosystème, puis on pourra enfin reparler de l’évolution du protocole.

Mais la proposition de tuxmain est intéressante, sans trop bousculer le protocole.

5 Likes
7

Ne t’y trompe pas : on souhaite tous simplifier les règles de la Ğ1 sans (trop) compromettre sa sécurité, et c’est justement une des raisons de Duniter v2 qui simplifiera les évolutions ! @ManUtopiK n’est pas là, mais c’est également un fervent défenseur des liens forts (comme les liens familiaux où une ou deux certifications pourraient suffire).

Simplement, le parcours pour élaborer une nouvelle version est long et fastidieux :

  • il faut spécifier précisément une proposition
  • examiner ses vulnérabilités et se convaincre de sa robustesse (pas uniquement se persuader)
  • proposer une première implémentation, ce qui force à revenir sur les spécifications
  • tester sur un réseau de test, ce qui pousse souvent à revenir sur les spécifications et l’implémentation
  • adapter tout l’écosystème (indexeurs, applis, documentation…)

Seule l’implémentation est une tâche vraiment technique qui nécessite des compétences de programmation, pour tout ce qui est spécification, examen des failles, test utilisateur, on a besoin d’aide et elle peut venir de toute personne suffisamment renseignée sur la Ğ1 et prête à réfléchir pendant des semaines sur un problème. @Maaltir est l’exemple par excellence de ce genre d’aide, il a souvent participé à élaborer des solutions en pointant des points faibles des propositions. Et aux RML17 les discussions à l’oral avec @Yvv, @gerard94 ont aussi bien fait avancer les idées.
Je pense que les RML18 seront surtout techniques puisqu’on n’aura pas encore migré la Ǧ1 et que les efforts seront dirigés de ce côté, mais il faudra prévoir d’avoir ce genre de discussions aux RML19.

6 Likes
8

À cryptoxr j’ai parlé avec pas mal de junistes de la Nièvre et de l’Yonne, et il semble que les gens sont assez attachés à cette fonctionnalité d’émission simultanée de plusieurs certifications. Je pense que si on veut sortir une v2 il faut qu’on se calme un peu au niveau des fonctionnalités, et il faudra plutôt implémenter quelque chose côté client dans un premier temps (comme une liste de personnes à certifier) avant de trouver une évolution lien faible/fort ou plafond glissant.
Mais j’ai noté un point qui pourra être retenu lors de la conception du futur système : lors de l’émission simultanée de plusieurs certifications, il est confortable pour l’utilisateur de ne pas avoir à choisir l’ordre dans lequel elles passent, mais que soit dans les mains d’un algorithme externe, ce qui évite d’avoir à établir une “préférence”.

1 Like
9

Note des RML18 : on part plutôt sur une solution sans changement en blockchain, mais avec une fonctionnalité côté client pour faciliter la mémorisation des certifications (sorte d’annuaire de contact, d’intention de certifications).

1 Like
10

En creusant un peu la solution (4) (soumission des transactions postdatées à serveur tiers) je vois que c’est impossible sans changement du runtime :

Le problème du nonce peut être résolu avec un compte délégué réservé aux transactions planifiées (nécessite d’implémenter les comptes délégués pour les certifications).

Le problème du hash de bloc peut être résolu en changeant des paramètres blockchain (pas forcément souhaitable) ou en ajoutant des règles d’exception.

La solution (1) (client), faute de mieux, me semble un retour en arrière par rapport à Duniter v1. Grâce aux piscines, l’antispam des 5 jours est la plupart du temps sans conséquences pour les gens. Au pire il faut attendre, mais pas besoin de se connecter tous les 5 jours passée telle heure pour signer et envoyer une certification.

La meilleure solution me semble la (5) (plafond glissant), car elle implémente le même antispam mais sans contrainte visible dans la plupart des cas légitimes(tout comme pour le quota de frais), et est plus flexible que la planification.

J’aimerais discuter de la priorisation de cette fonctionnalité lundi.

2 Likes