Refonte de la Smith WoT

Pour faire suite à : À quoi servent les pending membership? - #26 by cgeek

J’ai émis l’idée qu’il faudrait supprimer la Smith WoT, c’est-à-dire l’implémentation actuelle du code qui gère nos autorités en empruntant le code de la WoT.

Le problème du fonctionnement actuel, c’est qu’il nous contraint à avoir un comportement commun pour deux choses différentes (voir Pallets instanciables et vérifications d'adhésion). Or, la Smith WoT n’est pas satisfaisante aux yeux de @HugoTrentesaux ni moi-même, au moins.

J’ai commencé à me dire que je pourrais recoder un système minimaliste de WoT pour gérer les autorités dans authority-members, et puis je me suis demandé si l’on ne voudrait pas plus simple justement : pourquoi ne pas simplement déléguer la décision au comité technique ?

Concrètement, je crois :

  • (root) disposer d’un extrinsic pour promouvoir un membre de la WoT au statut de Smith
  • (root) disposer d’un extrinsic pour révoquer un membre du statut de Smith
  • (smith) disposer des calls habituels goOnline(), goOffline(), etc
2 Likes

La TdC forgeron vient de discussions ayant notamment eu lieu avec les membres lors des dernières RML, l’objectif étant de ne pas trop centraliser de pouvoir.

Le comité technique tel qu’il est aujourd’hui étant lui-même une solution temporaire en attendant de trouver un modèle plus scalable, démocratique et résistant aux putschs. Si je me souviens bien, le consensus aux RML était que le comité est temporairement tout-puissant, mais qu’à l’avenir il perdra son rôle politique pour se cantonner aux propositions de mise à jour et corrections de bugs, ce qui est un rôle éloigné de celui de décider des forgerons.

Si le comité technique décide des forgerons, comment le fait-il ? On pourrait faire des votes avec un seuil de 5, mais exigerait-on le respect de la licence forgeron à ceux qui ont voté pour l’entrée d’un membre ? Combien de votes contre pour refuser, et comment fait-on si une minorité fait blocage ?

3 Likes

J’essaye de retrouver les discussions sur le forum, je vois :

Les discussions distinguent bien le comité technique et les nœuds forgerons, je crois qu’il n’y a pas trop de débat là-dessus.

Par contre, la définition des nœuds forgerons revient régulièrement. Au stade actuel, la solution à base de toile basée sur le même code que la WoT nous pose trop de problèmes. Nous pourrions soit la recoder dans authority-members (plus simplement, plus adaptée au besoin), soit – c’est mon intuition – nous pourrions pour l’instant nous en remettre au comité technique.

Je ne sais pas, on peut rester pour le début aux mêmes conditions que pour les Runtime Upgrade.

La justification à un tel système est simple : de toutes façons, à l’heure actuelle, le projet technique est porté par une poignée d’êtres humains présents sur ce forum. Sans eux, tout s’écroule à plus ou moins brève échéance. Selon moi, le comité technique initial de la Ğ1v2 sera composé de ces personnes qui devront savoir facilement et rapidement se contacter en cas de besoin. Car dans le pire des cas, ce seront encore elles qui proposeront le hard-fork en cas de nécessité.

Bref, je trouve que l’on s’embarrasse beaucoup avec cette toile forgeron aussi tôt dans le projet.

2 Likes

Comme mon objectif principal est découpler les forgerons de la WoT en termes de code source, et que je sens que la toile Smith semble être une solution plus acceptée, je vais partir dans cette direction.

En fait non, authority-members est très bien comme elle est. Je vais plutôt proposer une palette smith-members qui s’intercale entre la WoT (palette duniter-wot pour l’instant, j’espère identity plus tard) et authority-members.

Paramètres conservés

Je reprends les paramètres / handlers / providers suivants de la SmithWoT existante, et je commente le sens du paramètre dans la nouvelle palette smith-members :

Paramètre Commentaire
Provider “IsMember” Pour n’autoriser que les membres de la WoT à devenir Smith
Handler “MembershipRemoved” Pour propager la perte du statut de membre de la WoT à la toile Smith
MinCertForMembership Nombre de certifications pour être considéré Smith
MinCertForCreateIdtyRight Nombre de certifications pour pouvoir inviter un nouveau Smith
CertPeriod Délai à observer entre deux émissions de certifications pour un Smith
MaxByIssuer Stock maximal de certifications actuellement émises pour un Smith
MinReceivedCertToBeAbleToIssueCert Nombre minimum de certifications à recevoir en tant que Smith pour pouvoir en émettre soi-même

Paramètres supprimés

Paramètre Commentaire
FirstIssuableOn Pas d’intérêt de décaler le délai de la 1ère certification pour un Smith
MembershipPeriod Rester Smith se fait en étant online, ou offline mais pendant un délai maximal donné (OfflineMaxDuration, voir ci-après)
ValidityPeriod Pas d’expiration des certifications. Un Smith qui se fait éjecter (par le comité technique, par perte du statut de membre de la WoT ou par les offences) perd toutes ses certifications Smith

Nouveaux paramètres

Paramètre Commentaire
OfflineMaxDuration Durée maximale, en nombre de sessions, pendant laquelle un Smith peut rester offline. Au-delà, le Smith est éjecté et perd ses certifications smith.

Extrinsics

Paramètre Commentaire
certify_smith Permet de certifier un Smith, et de le créer s’il n’existe pas encore (pourrait être découpé en invite_smith et certify_smith, j’hésite sur ce point).

Je ne vois pas d’autre extrinsic nécessaire pour l’instant.


Je n’ai pas l’impression que ce soit compliqué à coder, je vais commencer pour voir.

2 Likes

Je pense qu’il faut prévoir que quand un Smith perd son statut de smith ses certifs Smith émises devrait disparaitre (dans le cas où il n’y a pas d’expiration des certifs Smith) peut-être avec un certain délai…

1 Like

MR!217 disponible pour relecture.

2 Likes

Je suis pertubé par le choix de nommage :
soit MinCertFor*
soit MinCertTo*
soit MinReceivedCertTo*
Mais un mix des deux me semble confusant.

Sinon sur le fond je suis d’accord avec @tuxmain tout ce qui va dans le sens de concentrer le pouvoir m’inquiète (sans forcément m’y opposer catégoriquement si ça permet à court terme d’avancer sans créer une concentration qui n’était pas de facto déjà là) et tout ce qui va dans le sens de diviser les pouvoir me branche (même si tant que c’est sur le principe, mais qu’en principe, on cumule les mandats, ça ne change pas grand chose à court terme).

Ces choix de nommage ne sont pas les miens, mais de toute façon je n’ai conservé que MinCertForMembership.

Pour ce qui est de la concentration des pouvoirs, je suis resté sur le principe d’une “Smith WoT” même si ça m’a coûté du temps de le faire afin qu’elle soit plus rapidement acceptée.

La principale différence, technique, c’est que cette palette n’est plus fondée sur une combinaison d’instances des palettes certification + membership + duniter-wot mais sur une unique palette non-instanciable et dédiée smith-members. Ce qui devrait largement faciliter sa délimitation et sa vérification (ticket #141). Donc améliorer la sécurité générale de la blockchain et la confiance dans le fait que la migration vers une Ğ1v2 va techniquement tenir.

5 Likes