License forgeron

Je ne suis pas pour freiner les réflexions et débats, mais je suis d’accord qu’il n’y a aucune urgence à implémenter des mécanismes on-chain pour des votes autres que runtime-update, et que prioriser leur développement serait préjudiciable à la date de migration v2.

Après discussion téléphonique avec toi, j’ai changé la formulation dans le pad que @italpaola est entrain de relire pour corriger mes coquilles orthographiques.
Dès que c’est fait je publie la nouvelle formulation ici pour voir si elle conviens mieux :wink:

Correction ortho faite

Très chouette document, qui à mon humble avis, a le mérite de faire avancer la gouvernance au sein de la G1. merci @1000i100

1 Like

Voici la version relue et corrigée :

Et si vous voulez juste voir ce qui à été modifié :

3 Likes

Je m’engage à contacter sous 24h max ce forgeron si j’apprends qu’un défaut concerne son nœud validateur (désynchronisé, pas à jour, inaccessible…​).

Ça me semble excessif. Pour un défaut de sécurité oui (màj urgente, faille dans la config, fuite des clés de session ou de la clé privée, intrusion), mais s’il est désynchro ou inaccessible il sera mis offline automatiquement avant même qu’on ait le temps de le contacter.

Ensuite s’il faut contacter à chaque fois qu’on voit que le nœud n’est pas online, comment faire la différence entre un plantage occasionnel dû à une coupure de courant, une coupure volontaire de quelques heures pour réparer le serveur, de quelques jours pour un déménagement, etc.

On pourrait dire que “offline manuel = tout va bien” et “offline automatique = problème”, mais si je redémarre mon serveur en sachant que je vais rater quelques blocs et que ce n’est pas grave, puis que le serveur plante, je serai automatiquement offline mais pas besoin qu’on m’envoie un message, j’ai vu que ça a planté.

On pourrait plutôt demander que la personne soit contactée en cas de problème, que ce soit par les certificateurs, ou par un quelconque service de monitoring.

1 Like

un p’tit service “pager” ? où chaque forgerons définit le canal par lequel il reçoit l’alerte en fonction de son indice critique ?
(1. mobilisation générale, attaque massive :cold_face: ; 2. urgence dysfonctionnement - vulnérabilité :cold_sweat: ; 3. :woozy_face: ; etc …) ?
où il pourrait aussi y avoir un mode “feu vert” pour les mémos, les manips et check de maintenance, un fil d’actu pointu maison forgerons, … ?
où il y aurait potentiellement un mode “orange” pour des exercices, des investigations, des bounty crackers, crash test, … ?

quelconque un peu dans ce genre là ?


Côté “licences”
De mon point de vue il y a mélange des genres :

  • l’acte d’engagement du créateur de DU = seulement un processus humain de certification décentralisée, qui garantit l’intégrité d’une identité numérique, d’une clé.
  • la licence forgeron = valide l’aptitude technique et l’engagement opérationnel du forgeron. Pour le coup on est vraiment dans un registre de licence, (comme un permis).
    Pas grand chose à voir, il ne devrait pas y avoir de superposition entre les deux, (d’autant moins que la licence forgeron requiert la certification fiduciaire de créateurs de DU ;-).

Quelconque dans le sens où la licence le définit par sa fonction et non par sa nature.

Ça peut être un service centralisé qui envoie mail+sms, un service installé sur le serveur lui-même, une fenêtre PolkadotJS ouverte en permanence sur le bi-écran, une LED qui s’allume sur le bureau, une sirène civile…

Avoir des outils de monitoring me semble une bonne idée, mais qui sort du périmètre de la license forgeron.

En revanche, définir ce qui est attendu en terme de joignabilité et disponibilité, et dans quel cas contacter un forgeron pour quel type de souci lié à son noeud, ça oui, c’est du ressort de la licence forgeron.