Dans le refactoring que j’effectue pour Industrialiser le démarrage d’une nouvelle Ğx, se pose la question de ce que l’on souhaite comme données pour la ĞDev, ĞTest et Ğ1. J’ai deux questions :
A priori, pour ĞTest et Ğ1 nous serions dans une configuration très proche avec reprise des données de la Ğ1 mais avec des paramètres de délais plus courts pour la ĞTest (production du DU, délais de renouvellement, etc.) et un DU élevé (pour éviter que la monnaie ne prenne en valeur). Est-ton bien d’accord là-dessus ?
Pour la ĞDev, jusqu’à maintenant nous faisions un peu comme la ĞTest : donnée de la Ğ1 + paramètres plus fréquents. Continue-t-on sur la même voie ? Nous pourrions avoir une WoT restreinte aux contributeurs techniques par exemple. Ou bien continuer à utiliser la WoT Ğ1 tant que la ĞTest n’est pas lancée.
La GT peut servir à tester à la fois Duniter et l’écosystème avec des données ressemblant à la G1, donc on pourrait la lancer avec un instantané de la G1 et laisser les gens volontairement la tester. Je ne vois pas l’intérêt de restreindre, au contraire elle devrait pouvoir accueillir autant de bordeledge cases que possible. Quitte à utiliser des bots pour entretenir sa TdC et qu’elle reste au moins au niveau de la G1 en terme de bande passante, occupation des blocs, nombre de membres et de certifs.
J’en profite avec une troisième question : dans le Genesis, selon moi, tous les Smiths devraient être automatiquement co-certifiés, possiblement au hasard, à hauteur de [SmithWotMinCertForMembership ; SmithMaxByIssuer] certifications. Je ne vois pas l’intérêt qu’il en soit autrement. Êtes-vous d’accord avec ça ?
Si oui, je modifierai la structure du fichier de genesis config pour que l’on n’ai plus besoin de préciser les certifications statiquement, mais juste le pseudo des smiths + leur session_keys.
Je suis d’accord pour que les forgerons soient une clique en gdev et gtest pour des raisons pratiques (besoin de recueillir les listes de certifs et de mettre à jour le json), mais pas pour la G1.
Ces certifications ont quand même un sens et des implications sur la sécurité de la chaîne. Un forgeron avec le minimum de certifications forgeron est probablement moins reconnu comme fiable qu’un forgeron en ayant 15, donc on n’a pas intérêt à effacer cette information en leur donnant le même nombre de certifs (et donc en pérennisant davantage la position du premier, qui était peut-être un attaquant ou qui gérait mal son serveur).
Effectivement pour gdev et gtest on peut partir sur une clique. Et pas forcément besoin de mettre les session keys d’autres personnes que celle qui démarre le réseau. D’ailleurs, je me sers justement de la présence de session keys pour savoir quelle autorité sera online au début.
// Initial authorities and session keys
let session_keys_bytes = if let Some(declared_session_keys) = &smith_data.session_keys {
counter_online_authorities += 1;
// insert authority as online
initial_authorities.insert(identity.index, (identity.owner_key.clone(), true));
// decode session keys or force to given value
match maybe_force_authority {
Some(ref bytes) => bytes.clone(),
None => hex::decode(&declared_session_keys[2..])
.map_err(|_| format!("invalid session keys for idty {}", &name))?,
}
} else {
// still authority but offline
initial_authorities.insert(identity.index, (identity.owner_key.clone(), false));
// fake session keys
let mut fake_bytes = Vec::with_capacity(128);
for _ in 0..4 {
fake_bytes.extend_from_slice(identity.owner_key.as_ref())
}
fake_bytes
};
Je ne sais pas si vous avez vu mais il y a un bouton “Bulk Edit” dans la page listant les issues d’une milestone sur GitLab.
Je dis ça parce qu’en voyant mes notifications mail j’ai l’impression que certaines éditions automatisables (migration des issues d’une milestone vers une autre) sont faites à la main.
