En comparant les runtimes gtest et g1, j’ai identifié plusieurs différences de comportement qui peuvent avoir un impact fonctionnel:
1. ProxyType TechnicalCommitteePropose
Présent dans gtest
Absent dans g1
Impact : une capacité de proxy disponible sur gtest ne l’est pas sur g1.
J’avais créé ce ProxyType pour permettre aux membres du comité technique de voter avec un trousseau de clés secondaire afin de ne pas avoir à utiliser leur trousseau membre à chaque fois. Est-ce que quelqu’un s’en sert ? Est-ce qu’on veut garder cette possibilité en production ?
2. SmithMaxByIssuer
gtest : 100
g1 : 12
Impact : limitation beaucoup plus stricte côté g1 pour l’émission Smith.
Est-on toujours d’accord pour limiter à 12 les certifications forgeron en production ?
3. MembershipRenewalPeriod
gtest : 56 jours
g1 : 2 mois
Impact : fenêtre de renouvellement plus longue sur g1 (en pratique ~4,875 jours de plus avec les constantes actuelles).
Puisqu’on veut désormais aligner gtest et g1 pour qu’ils évoluent de la même façon, doit-on modifier MembershipRenewalPeriod en gtest à 2 mois ?
Je viens de créer une MR pour aligner les comportements des runtimes gtest et g1 :
Cette MR aligne la valeur de MembershipRenewalPeriod et la définition des ProxyType en ajoutant TechnicalCommitteePropose à g1, au cas où un dev s’en serait servi sur gtest. On pourra toujours supprimer ce ProxyType à l’avenir si personne ne l’utilise.
Concernant SmithMaxByIssuer, je n’ai pas trouvé de discussion sur le forum à propos de cette valeur. C’est moi qui l’avais fixée à 12 il y a 4 ans, lorsque j’ai écrit le code de la sous-toile forgerons, mais je ne me souviens plus pourquoi j’avais choisi 12. S’il y avait eu une raison forte, je m’en souviendrais, car j’ai une très bonne mémoire pour ce genre de choses. Ce qui est certain, c’est qu’il faut une limite, et que cette limite doit être plus faible que pour les certifications normales, puisqu’il suffit d’en recevoir 3 au lieu de 5.
Je ne pense pas que 12 soit trop élevé. Avec les événements physiques récurrents, les devs forment une presque-clique assez grande (en termes de certifications potentielles). On peut laisser comme ça et augmenter si besoin. Ce sera plus compliqué de réduire que d’augmenter.
@HugoTrentesaux Avec tes outils de stats sur la TdC est-ce que tu as un truc déjà fait qui permet de voir la sous-toile des forgerons v1 ? (peut-être en cumulé, tous les gens qui ont écrit au moins 1 bloc, et sans compter les expirations, pour avoir une borne haute sur le degré sortant dans cette sous-toile)
Dans les faits, il se peut que la plupart de futures smiths soient invités par le même petit groupe de personne central, qui consomme alors plus de certification que le autres.
Mais bon je sais pas en fait, peut être pas.
Merci @tuxmain et @cgeek pour vos retours. Du coup, je propose qu’on reste à 12 pour le moment. On pourra toujours augmenter lors d’un futur runtime upgrade si on constate que 12 est trop limitant en pratique.
@poka, de mon côté, j’ai terminé d’auditer tout ce que je voulais. Il ne reste plus qu’à merger la MR !368 et on pourra livrer un nouveau runtime gtest
J’ai vue que le benchmark sur la machine de aya ont été mergé, mais concernant !358, ont est d’accord qu’on fera l’upgrade substrate après la migration, ou qu’en penses-tu ?
J’ai l’approche inverse en tête. Je propose qu’on ne l’implémente pas. Si un besoin se crée on l’ajoute. Plus un code a de fonctionnalités, plus il y a de bugs potentiels. Cette fonctionnalité est potentiellement pas utilisée et a surement été oubliée (je la découvre). Si une fonctionnalité est oubliée, il vaut mieux qu’elle n’existe pas. On a suffisamment de choses à maintenir.
La pallet proxy est maintenue par Parity ; tout ce qu’on a à faire, c’est déclarer les catégories de délégation et les droits associés. Ce n’est que de la configuration.
