Liens faibles / intermédiaires / forts

[elois]

Il y a en en effet deux objectifs distincts.

Je pense que le critère discriminant concernant les solutions a retenir c’est la complexité ajoutée autant coté code que coté utilisateur final.

Plus un programme est complexe plus il est source de bug et difficile a maintenir. De la même façon plus l’utilisation finale est complexe pet moins la monnaie libre est accessible (le systèeme actuel de certifications est déjà bien compliqué a comprendre pour beaucoup d’utilisateurs).

Donc tout ajout de complexité qui n’est pas absolument nécessaire devrait être proscrit.
Si, toute chose égale par ailleurs, on a une autre solution répondant au même besoin avec un ajout de complexité plus faible alors il conviens de la choisir

Objectif 1 : a difficulté des nouveaux membres à rentrer (pour co-créer le DU et certifier à leur tour dans ce même but), problématique de création monétaire uniquement : J’avais indiqué dans ce présent fil que l’on peut faciliter l’entrée en modifiant les paramètres de la wot :

@elois

si l’on décidait de rendre l’entrée plus facile, je préconiserai plutôt :

1. Augmenter fortement Y[n], le doubler tout de suite, pour que seul des membres de forte confiance puissent être référents.
2. Réduire la durée de vie des certifications à 1an, et réduire sigPeriod a 3 jours et réduire sigStock à 80. Cela permettrait une entrée plus facile tout en simplifiant le système en faisant coïncider la durée de l’adhésion et des certifications. Réduire sigPeriod devenant alors nécessaire pour que l’ensemble du stock reste utilisable.
3. Ne donner le droit au calcul qu’aux membres référents ET ayant une qualité > 0.8
4. Réduire sigQty a 3 afin de permettre l’entrée large plus facilement
5. Pour nous prémunir des attaques sybil rapides : spécifier dans le protocole qu’un nouveau membre ne peut pas émettre de certifications avant 1 mois.

Objectif 2 : la sécurité de la blockchain par rapport au droit d’écriture : J’ai proposé sur un autre fil une solution qui ajote zéro complexité pour l’utilisateur final et une complexité faible pour le protocole : Proposition d’identités forgerons − solution user-friendly au problème de sécurité des instances cesium web

@cgeek

Pour le 1er point, je suis toujours favorable à la création de liens faibles, qui ouvre à leurs bénéficiaires le droit de co-créer la monnaie (avec plus de 5 liens toutefois) et de certifier à leur tour en liens faibles.

La création d’un 2ème type de certification dite “faible” me semble complexifier considérablement l’utilisation pour l’utilisateur final et rendre encore moins lisible la compréhension de la licence et de la toile de confiance
Y a t’il d’autres idées induisant un ajout de complexité plus faible ? Que pensez-vous de ma proposition d’adaptation des paramètres de la wot ?

@cgeek

Pour le 2ème point, je me demande s’il ne serait pas judicieux de reposer tout simplement sur la topologie de la toile de confiance. Une propriété, par exemple la qualité ou la centralité, permettrait de déterminer qui peut ou non calculer des blocs. L’avantage, c’est qu’avec une centralité élevée par exemple, on sait qu’il s’agit d’une personne investie socialement dans la monnaie et donc théoriquement facile à contacter et qui connaît bien le sujet.

Oui c’est une bonne idée, et c’est moins complexe que ma proposition Après ça exclu du droit au calcul les personnes peu investies socialement, somme nous ok avec ça ? (c’est une question ouverte)