Dans mon Grafana je vois clairement l’impact du downtime du nœud autorité de cgeek :
J’en déduis que la coupure de courant est arrivée aux alentours de 18h30, au plus bas on est descendu vers 7,5 blocs / min, ça variait, car il y a une part d’aléatoire dans le consensus BABE, donc ça dépendait du nombre de slot où cgeek était le seul sélectionné.
Par contre, malgré cet « incident », la finalisation n’a pas subi de lag, au contraire, un bloc est toujours finalisé en 2 à 3 blocs :
Ce sera sans doute plus quand on aura plus de validateurs, ce sera l’un des trucs à tester quand la ĞDev sera plus stable
À l’avenir, ce genre d’offences déclenchera des sanctions, actuellement ça ne déclenche rien car le handler des offences n’a pas été implémenté (c’est une fonction vide qui ne fait rien).
À nous de définir les modalités des sanctions selon la nature de l’offence, la proportion de « rapporteurs », et tout autre critère que l’on peut déduire du storage on-chain, quitte à le stocker exprès pour, comme par exemple mémoriser des offences passées pour savoir si c’est une « récidive ».
Pour le cas de l’offense « hors-ligne » par exemple, substrate recommande de ne sanctionner que si plus de 10% des authorités sont hors-ligne, donc dans la pratique un incident isolé comme la coupure de courant de @cgeek ne devrait pas causer de sanction (car en prod on aura bien plus de 10 authorités), à condition qu’il ne soit pas trop fréquent bien sur
Et il n’ y à pas que les sanctions, on peut par exemple trigger automatiquement on goOffline si une offence « hors-ligne » à suffisamment de rapporteurs, ça permettrait de ne pas impacter le réseau dans la durée si le membre forgeron concerné ne peut pas rétablir la situation rapidement.
Sanctionner les forgeront, dans le cas de substrate/BABE ça me semble indispensable.
Par contre qui dit sanction pour “mauvaise conduite” dit récompenses pour “bonne conduite” ou pour “conduite” tout court ^^
J’imagine que tu as déjà pensé à tous ça avec la trésorerie commune.
J’ai lu quelque par que Polkadot avait commencé avec une pool de 20 authorités, qu’ils sont maintenant autour de 980 et qu’ils visent les 2000 à terme.
Vue le niveau d’engagement et les ressources nécessaires pour forger v2s comparé à v1, il ne faut pas s’attendre à avoir autant de forgeront qu’en v1.
Quand tu dis bien plus de 10, as-tu déjà des ordres de grandeurs en têtes pour la prod ?
Suite au déploiement du runtime 104, toute transaction coûte désormais 0,01 ĞD (1 centime).
Pour le moment, les frais de transactions sont transmis intégralement à l’auteur de bloc, parce que c’est comme ça que c’était codé avant, et dans le cadre d’un hotfix je change uniquement ce qui est nécessaire à corriger le bug.
On va évidemment changer ça dans un futur runtime, mais il faut d’abord qu’on décide qu’est-ce qu’on veut faire des frais
Les créateurs de blocs doivent évidemment être rémunérés pour le travail de maintenance de leur serveur, et pour le coût du matériel des dits serveurs.
Ça peut être directement tout ou partie des frais de transaction, ou/et tout ou partie du don optionnel associé à chaque transaction ou/et financé par une trésorerie, il y a une infinité de modalités possibles
Je dirais plutôt, il faut créer une formation spécifique que devront suivre ceux qui souhaitent être forgerons, puis préciser dans la licence forgeron qu’il est nécessaire de devenir d’abord forgeron sur la ĞTest avant de l’être sur la Ğ1.
Je ne suis pas certain qu’on est moins de forgerons qu’en Ğ1, le nœud sera plus simple à synchroniser, n’a pas de fuites mémoires et ne nécessite pas de restart régulier.
Il faut juste apprendre aux gens comment mettre en place un système de monitoring qui les notifie via un canal d’urgence adapté à leur cas (SMS ou boite mail dédié qui est sur leur smartphone), ce serait l’un des points principal de la formation. Pour le moment je m’auto-forme là-dessus pour pouvoir ensuite écrire de la doc sur comment faire puis vous former à mon tour en visio où lors de prochaines rencontres IRL (certains y arriveront juste avec la doc) .
Oui @Maaltir, et pas que cette décision, mais aussi bien d’autres relatives à la gouvernance on-chain.
Je pense même que le forum n’est pas suffisant, et que le moment venu il faudra discuter des grands choix à faire lors d’évènement IRL avec les utilisateurs, et je sais déjà que ça se fera
Mais il faut d’abord réaliser un gros travail de vulgarisation en amont sur quels vont être les choix à faire, et quelles seront les différentes possibilités et leurs conséquences, et je pense que ça va être l’un des principaux chantiers sur lequel va travailler @HugoTrentesaux, ainsi que toutes les bonnes volontés qui veulent bien aider là-dessus
C’était un peer connecté au mien, car l’activité réseau de mon peer à chutée à ce moment-là:
Par contre, je n’arrive pas à déterminer qui c’est. Quand je regarde les blocs produits à ce moment-là, les 4 forgerons en produisaient bien.
L’un deux devait juste être un peu plus lent à cause de problèmes réseau je présume, si ça se trouve c’était même mon nœud, pour avoir le fin mot de l’histoire il faudrait analyser finement le temps entre chaque bloc en fonction de l’auteur du bloc, je n’ai pas de stat là-dessus pour le moment.
La blockchain n’a pas émis d’offences, une offence n’est émise qu’en cas d’absence sur une epoch entière (1h pour la ĞDev).
À noter que ces stats sont faussées par le fait que le dépôt git de dunitel-v2s est un fork du dépôt template de substrate, et que je n’avais pas pensé à supprimer l’historique git du template, en réalité on est 5 auteurs, les 6 autres sont des dev du template
