@smiths-v2 Suite à un changement de paramètre de dernière minute, si vous passez online smith sur le réseau g1 au démarrage, une fois go offline, vous devrez attendre 28 jours avant de pouvoir migrer votre identité sur un compte mnemonic.
Pensez donc à migrer votre identité AVANT de go online si vous souhaitez la migrer.
Ce qui veux dire ne plus forger de blocs également pendant ces 28 jours ? une petite session de vacances en fait ? faire disparaitre les premiers forgerons pendant les premières semaines du réseau, c’est dommage… Donc, le mieux c’est de faire la migration avant de rejoindre le réseau ?
Le noeud initial bootstrap arrivera à enregistrer toutes les demandes de migrations alors qu’il sera tout seul ?
Oui exactement, mieux vaut faire la migration tout de suite avant de go online, ou bien accepter de migrer plus tard.
La durée de 28 jours sera finalement réduite à 1 h au lancement afin d’éviter qu’un forgeron initial ne se retrouve bloqué. Cette valeur sera rétablie à 28 jours lors d’un runtime upgrade après la migration.
Non, après la migration du compte on peut go online et forger immédiatement.
C’est dans l’autre sens que ça bloque : après le go offline, il y a un délai pendant lequel on ne peut pas migrer (et on ne peut pas migrer en étant online).
@poka Tu dois pouvoir migrer ta clé dans le bloc zéro non ? Mais bon ça fait un vecteur de bug supplémentaire.
J’avais intialement ajouté cette possibilité dans les premières versions de py-g1-migrator, mais ça a été retiré par @cgeek , je pense pour rester KISS, à raison.
C’est très bien, maintenant que ReportLongevity est à 1h pour la g1 (durée d’une Epoch), ça ne pose plus aucun soucis, j’ai juste à attendre qu’il y ait suffisament de forgerons, pour go offline, changeOwnerKey, attendre 1h, puis re go online 
Ça fera un bon prétexte pour s’accoutumer aux Runtime upgrades.
Quel est l’intérêt de rétablir à 28 jours ensuite ?
J’imagine que c’est un enjeu de sécurité mais je ne vois pas le modèle d’attaque correspondant.
Oui, l’intérêt de revenir à 28 jours est bien principalement un enjeu de sécurité, c’est plus précisément un enjeu de fenêtre de preuve.
Avec reportLongevity, on définit combien de temps une preuve d’offence reste recevable.
L’attaque visée est une attaque par délai / censure temporaire :
Donc le retour à 28 jours sert à éviter qu’un acteur fautif “gagne” juste en faisant traîner la remontée de preuve.
Deux offences principales :
Ces preuves peuvent remonter tard (surtout si l’observateur qui a vu la divergence n’est pas immédiatement connecté au reste du réseau), d’où l’intérêt d’une fenêtre longue.
En pratique :
Point important :
En résumé : rétablir 28 jours, c’est surtout garantir que les fautes graves restent effectivement sanctionnables, même si le réseau traverse une période perturbée.
Merci @1000i100 d’avoir posé ta question. En vérifiant le code pour pouvoir te répondre de manière précise, je me suis rendu compte que les équivocations GRANDPA ne remontent pas. Cela signifie qu’un forgeron malveillant qui voudrait perturber la finalisation des blocs en émettant des votes de finalité contradictoires ne peut pas être blacklisté.
Je viens de créer une MR pour corriger ce bug critique :
Du coup, tant qu’internet ressemble à ce qu’il est, je peine à voir le scénario où une preuve de ce type mettrait plus de 24 à 48h à remonter. Le gain de sécurité de 28 jours me semble donc assez dérisoire au regard de la contrainte. Il n’y a pas besoin de trancher maintenant si on commence à 1h pour la migration, mais je serais davantage favorable à remonter ensuite à 24h ou à 48h plutôt qu’à 28 jours.
Qu’en pensez-vous ?
Je comprends l’argument et je suis d’accord qu’en régime normal, 48 h couvriront probablement l’écrasante majorité des cas.
Dans certains cas, cela pourrait ne pas être suffisant. Il ne s’agit pas d’un « Internet lent », mais d’incidents rares et prolongés côté logiciel ou infrastructure : bug de synchronisation, divergence prolongée, détection tardive après correctif ou indisponibilité temporaire des nœuds. Dans ces situations, on pourrait perdre une preuve en raison d’une fenêtre trop courte.
Et si ce genre de situation est très exceptionnel et implique de toute façon l’attention forte de toute l’équipe, j’imagine que si on constatatait une raison valable de blacklister un compte, même périmé, on pourrait le faire manuellement de la même manière que c’est une opération manuelle pour sortir un compte de blacklist. Confirmes-tu ?
En tout cas, on n’a aucun intérêt à garder 1h seulement post-démarrage. Donc autant mettre 28j.
Pas forcément, et même probablement pas. Tant que l’equivocation proof n’est pas on-chain, on ne peut pas la voir simplement en analysant les données on-chain ; les seules traces se trouvent dans les mempools des nœuds qui auront observé la fraude.
Si une équipe malveillante trouve un bug qui peut empêcher temporairement l’inclusion de transactions on-chain, par exemple, elle peut se coordonner avec un ou quelques forgerons complices pour qu’ils se comportent mal en même temps que l’exploitation du bug. Nous serions alors concentrés sur la correction du bug via une mise à jour afin que la chaîne accepte de nouveau des transactions. Mais, entre-temps, les transactions destinées à publier les preuves d’equivocation ne pourraient plus être acceptées on-chain, car le délai ReportLongevity serait passé.
Pour le moment, il n’y a pas de call root pour blacklister un forgeron. En l’état, le comité technique ne peut donc pas blacklister un forgeron : il faudrait d’abord déployer un runtime upgrade qui ajoute un tel call.