Choix des paramètres de la monnaie ĞDev

ĞDev est le nom de la 1ʳᵉ monnaie de test de duniter-v2s, l’objectif de ce sujet est de choisir les valeurs des paramètres que l’on inscrira dans le genesis de cette monnaie (le bytecode du runtime étant inscrit dans le genesis).

Pour comprendre a quoi sert chaque paramètre, merci de vous référer au sujet dédié:

Le plus important est de nous mettre d’accord sur les paramètres difficiles à modifier (catégories 1 à 3).
Le tableau liste tout les paramètre (y compris ceux de la catégorie 4).

Valeur des paramètres au genesis

Paramètre Valeur Explication
System.SS58Prefix 42 préfixe à utiliser pour tout les testnet
System.BlockHashCount 2 400 4 heures
System.MaxConsumers 16
Babe.ExpectedBlockTime 6 000 6 secondes
Babe.EpochDuration 600 1 heure (comme Kusama)
AtomicSwap.ProofLimit 1024 1024 octets, permet d’être large sur les futurs ğusages
UniversalDividend.UdCreationPeriod 14 400 1 jour
UniversalDividend.UdReevalPeriod 100 800 Une semaine, comme pour la ğ1-test (ce qui permet d’avoir un taux c réel plus élevé).
UniversalDividend.SquareMoneyGrowthRate 2 381 440 En partie par milliard. Ce qui correspond nombre décimal 0.002_381_440 soit exactement le résultat de 4,88%^2.
*.MaxAuthorities 32 32 pour commencer, on augmentera ce nombre progressivement
Balances.ExistentialDeposit 200 2 ĞD
AuthorityMembers.MaxKeysLife 1 500 En nombre de sessions, donc environ 62 jours. En gros, chaque autorité devra rotate ses clés au moins tout les 2 mois.
AuthorityMembers.MaxOfflineSessions 2 400 En nombre de sessions, donc environ 100 jours. En gros, un membre forgeron inactif perdra son statut de forgeron au bout de 3 mois.
Wot.MinCertForMembership 5
Wot.MinReceivedCertToBeAbleToIssueCert 5
Treasury.MaxApprovals 100
Treasury.SpendPeriod 86 400 6 jours
Treasury.ProposalBond 10 000 En partie par million, donc 1 %.
Treasury.ProposalBondMinimum 10 000 100 ĞD
TransactionPayment.TransactionByteFee 0
Scheduler.MaximumWeight 1 600 000 000 000 80% du temps d’exécution maximal d’un bloc (Polkadot utilise cette valeur).
Scheduler.MaxScheduledPerBlock 50 50 calls planifiés (Polkadot utilise cette valeur).
Account.MaxNewAccountsPerBlock 1 Même à 1, un attaquant peut forcer l’affectation de 600 random id dans un même bloc (lors du changement de session). Et ça permet quand même de créer 14400 nouveaux simples portefeuilles par jour, c’est largement suffisant
Account.NewAccountPrice 300 3 ĞD
ImOnline.UnsignedPriority u64::MAX Priorité maximale pour cet inhérent.
ImOnline.MaxPeerDataEncodingSize 1 000 Valeur utilisée par Polkadot
ImOnline.MaxPeerInHeartbeats 10 000 Valeur utilisée par Polkadot
ProvideRandomness.MaxRequests 100
ProvideRandomness.RequestPrice 2 000 20 ĞD
Multisig.MaxSignatories 10
Proxy.MaxProxies 32 Valeur utilisée par Polkadot
Proxy.MaxPending 32 Valeur utilisée par Polkadot
Wot.FirstIssuableOn 14 400 1 jour. délai court pour tester, mais dans la Ğ1 ce délai sera plus élevé par sécurité (de l’ordre du mois).
Wot.MinCertForCreateIdtyRight 5 L’idée c’est de sécuriser la sous-toile forgeron au maximum, donc le droit d’émettre des certifications forgerons doit être davantage restreint que le droit d’être forgeron.
Identity.ConfirmPeriod 14 400 24h. Le 1er certificateur est censé se synchroniser avec la personne qui veut créer son identité.
Identity.IdtyCreationPeriod 14 400 24h. Volontairement très court pour cette monnaie de test, dans la Ğ1 ce sera plus de l’ordre du mois.
Membership.MembershipPeriod 1 051 200 73 jours. Même délai que dans la ğ1-test.
Membership.PendingMembershipPeriod 172 800 12 jours. Même délai que dans la ğ1-test.
Membership.RenewablePeriod 172 800 12 jours. Même délai que dans la ğ1-test.
Cert.MaxByIssuer 100
Cert.CertPeriod 14 400 1 jour. Même délai que dans la ğ1-test.
Cert.CertRenewablePeriod 172 800 12 jours. Même délai que dans la ğ1-test.
Cert.ValidityPeriod 2 102 400 146 jours. Même délai que dans la ğ1-test.
SmithsSubWot.MinCertForMembership 3
SmithsSubWot.MinReceivedCertToBeAbleToIssueCert 5
SmithsSubWot.FirstIssuableOn 14 400 24h. Volontairement très court pour cette monnaie de test, dans la Ğ1 ce sera plus de l’ordre du mois.
SmithsMembership.MembershipPeriod 1 051 200 73 jours.
SmithsMembership.PendingMembershipPeriod 172 800 12 jours.
SmithsMembership.RenewablePeriod 172 800 12 jours.
SmithsCert.MaxByIssuer 12
SmithsCert.CertRenewablePeriod 172 800 12 jours.
SmithsCert.ValidityPeriod 2 102 400 146 jours.
SmithsCollective.MotionDuration 100 800 7 jours
SmithsCollective.MaxProposals 20
SmithsCollective.MaxMembers 1 000
3 « J'aime »

J’aimerais que l’on se fasse une réunion visio dédiée aux paramètres de la ĞDev en fin de semaine ou week-end prochain, ce serait bien que puissent y être présents @cgeek @tuxmain @HugoTrentesaux , quelles sont vos dispo entre vendredi ? samedi ? dimanche ?

Ce sera public bien sur, tous les intéressés peuvent venir, mais ça va être très technique, je vais passer les paramètres 1 par 1 et expliquer à quoi il sert et pourquoi je propose telle valeur :slight_smile:

4 « J'aime »

Mes dispos :

  • vendredi : toute la journée
  • samedi : matin, sinon soir
  • dimanche : après-midi, soir, sinon matin
1 « J'aime »

vendredi : all day.
samedi et dimanche : matin et soir.

1 « J'aime »

J’aimerais aussi prendre le temps de comprendre et réfléchir sur ces paramètres. Je suis dispo vendredi en soirée et le weekend.

[edit]

je me suis permis d’ajouter quelques liens vers les pallets concernées et de regrouper les paramètres de mêmes pallets qui étaient séparés.

1 « J'aime »

Je pourrais peut-être répondre présent dimanche après-midi ou en soirée, mais je ne peux rien garantir. Ne contraignez pas trop la réunion à ma présence.

1 « J'aime »

Est-ce que tu peux préciser les unités de temps ? Un jour (entre deux DU), c’est 86400s. Mais tu écris 14400, ce qui correspond à une unité de 6s. Bizarre…

1 « J'aime »

Ce doit être un nombre de blocs alors, puisqu’un bloc dure 6s.

1 « J'aime »

Je crois que tu as raison. Il va falloir relire la doc.

@gerard94 toutes les unités de temps sont déjà précisées dans la définition de chaque paramètre dans le sujet dédié:

1 « J'aime »

Pour la visio sur les paramètres je propose samedi soir à 21h :slight_smile:

2 « J'aime »

RAPPEL: ce soir à 21H on parle des paramètres de la ĞDev ici:

cc @cgeek @vit @HugoTrentesaux @tuxmain @gerard94 @poka @1000i100 @matograine @ManUtopiK

2 « J'aime »

J’ai cru comprendre qu’il pourrait y a voir un nombre de certifs pour créer le DU différent de celui pour avoir le droit de certifier. Je trouve l’idée intéressante, mais ne serait-il pas pertinent de se baser plutôt sur la règle de distance ?
Genre être à moins de 5 pas de 85% des référents, ou à moins de 4 pas de 60 %, ou autre. Serait-ce plus protecteur, contre les attaques sybil ?
Mais est-ce que cela ne renforcerai pas l’idée que la Ğ1 se développe uniquement autour du noyau central ?
Avons-nous du temps à perdre pour discuter de ce genre de question ? :crazy_face:

Ce sont des questions de recherche intéressantes qui méritent d’être creusées. Pour l’instant on reste comme c’est actuellement, mais s’il y a des études sur les attaques Sybil dans une toile de confiance, on pourra agir en fonction. C’est le but de Datajune / Jucube mais je n’ai pas eu assez de temps pour continuer les simulations.

Les variables des forgerons ne devraient-elles pas se nommées « blacksmiths » quelque chose, plutôt que juste smiths ?

Ou pourquoi pas forger ? :sunglasses:

Les noms des variables et types sont déjà bien assez longs dans le code, le but est qu’on comprenne en lisant le code, pas nécessairement que le nom soit « complet » d’un point de vue linguistique, sinon que dire des noms des paramètres dans duniter v1…