Date de création du DU

Nodes Duniter-v2s
1

Dans Duniter v2, le temps d’attribution du DU est compté en nombre de blocs.

fn on_initialize(n: T::BlockNumber) -> Weight {
    if (n % T::UdCreationPeriod::get()).is_zero() {
        // création du DU...

Il n’est actuellement pas possible de régler la date de création du premier DU. Cela veut dire qu’au moment de la migration, le délai entre deux DU successifs sera prolongé au maximum d’une journée. Est-ce problématique à votre avis ? (pour moi c’est du détail, ce n’est pas grave que la migration entraîne un retard du premier DU).

1 Like
2

Je pense que ce n’est pas grave, en tout cas pas plus que l’approximation du DU faite par un versement quotidien avec réévaluation semestrielle.

L’implémentation du DU calculé sur le temps et non sur les blocs corrigerait ce problème.

5 Likes
3

Pas grave et d’accord avec l’idée de @tuxmain

1 Like
4

La !178 corrige la #64 en comptant le DU et sa réévaluation sur le temps et non sur le nombre de blocs.

Mon implémentation permet au genesis de définir (ou non) les dates du premier DU et de la première réévaluation. Une fois la date atteinte, la période théorique est additionnée à la date théorique plutôt qu’à la date réelle, il n’y a donc aucun décalage. En cas de coupure (pas de blocs pendant plus de 24h), on rattrape le retard en émettant un DU et/ou une réévaluation par bloc tant que nécessaire. Si la date n’est pas indiquée dans le genesis, elle est définie lors du premier bloc à une période dans le futur.

On peut donc conserver l’heure du DU pour la migration.

Il n’y a aucun changement pour les clients (les événements et extrinsics restent les mêmes).

Appliquer ceci à la gdev nécessiterait une migration. Est-ce qu’on s’embête à le faire, ou on reset pour le runtime 600 ? (sachant que ça corrigera aussi l’incohérence du storage smiths->smith et qu’il y aura peut-être d’autres MR cassantes à faire)

7 Likes
5

Ah mais c’est énorme ! Merci tuxmain je vais regarder ça avec beaucoup d’intérêt. Fonctionnellement parlant ce que tu proposes est parfait, je suis content qu’on puisse continuer à tenir cette promesse du DU quotidien et à heure fixe.

À mon avis mieux vaut attendre le reset. Pareil pour le calcul de distance, dans la mesure où l’on est a priori assez près du but.

edit : ah bah d’ailleurs, j’ai l’impression que la ĞDev vient tout juste de bloquer.

1 Like
6

2 posts were split to a new topic: Gdev runtime 600

7

Attention, il me semble que tu as remplacé la variable first_ud qui était un montant (BalanceOf<T>) par un moment (Option<T::Moment>). D’où mon commentaire.

[edit] ah non, en fait tu l’as renommé en ud, c’est le changement de nom qui m’a perturbé.