Liste des paramètres (protocolaires) de Duniter-v2s

:warning: Ce post reflète l’état du code au commit 23eca1ba15c85a7614f5af614940935356cee528, il est possible que les paramètres dans le code est changés depuis la dernière mise à jour de ce post !

Protocole et runtime ?

Le protocole d’une blockchain substrate est défini dans ce que l’on nomme un « runtime ».
Ce runtime est composé de « pallets » ayant chacune plusieurs paramètres, que le runtime doit configurer. Ce sont donc des paramètres protocolaires.

Ce post liste les paramètres* du* runtime duniter-v2s.

*Note 1: On liste uniquement les paramètres dont la valeur est un nombre entier où une proportion (nombre rationnel entre 0 et 1).

*Note 2: Certains paramètres ne sont volontairement pas listés, car ce n’est par pertinent, par exemple ceux dont la valeur doit être liée à d’autres par un calcul précis (qui n’existent que pour des raisons d’optimisation ou de découplage).

*Note 3: En réalité il y a plusieurs runtimes (1 pour chaque monnaie), car c’est une nécessité technique, mais ils ont les mêmes paramètre, seule la valeur de ces paramètres peut être différente.

Catégories de paramètres

Les paramètres sont catégorisés selon la difficulté à les modifier après le bloc genesis, voici la liste des catégories:

1. Never

Les paramètres dans cette catégorie ne peuvent pas être modifiés après le bloc genesis, il faut donc particulièrement bien les choisir, heureusement ils sont peu nombreux.

2. Unexpected

Les paramètres dans cette catégorie sont implémentés selon l’hypothèse que la valeur du paramètre ne sera pas modifiée après le bloc genesis. Dit autrement, l’implémentation de ces paramètres n’a pas prévu l’éventualité ou l’on voudrait les modifier.
En fait la seule différence avec la catégorie 1 c’est que implémentation de ces paramètres est suffisamment circonscrite et non-critique pour qu’il soit éventuellement envisageable de modifier l’implémentation de manière à permettre une future modification du paramètre concerné.
Bref, on passe d’impossible à extrêmement difficile, donc il faut également bien choisir la valeur de ces paramètres, heureusement ils sont peu nombreux.

3. Migration

Les paramètres dans cette catégorie sont implémentés d’une manière qui permet leur modification, mais à condition de réaliser une migration du « onchain storage » en même temps.
Substrate offre un cadre de travail et des outils permettant de faciliter au maximum les migrations, donc c’est infiniment plus facile à gérer que dans la plupart des systèmes de données.
Mais ça reste une migration, et une migration ça reste toujours un peu délicat, il faut écrire et tester le code de migration.
Changer un paramètre dans cette catégorie requiert donc des développeurs et testeurs et à minima quelques semaines, voir quelques mois selon la nature de la migration et la disponibilité des contributeurs.

4. Easy

Les paramètres dans cette catégorie peuvent être modifiés directement sans autre forme de procès. Il faut bien sur compiler et proposer un nouveau runtime onchain, ce qui peut être fait par un utilisateur avancé qui n’a pas peur de la ligne de commande et qui sait suivre une documentation technique, pas besoin de développeurs.
Le temps pour modifier un tel paramètre en production dépend uniquement du temps de validation du nouveau runtime par le processus de gouvernance. Par prudence, on fera quand même des tests en amont, pour s’assurer que la modification de ce paramètre n’a pas des effets de bords que nous n’aurions pas anticipé.

Notez bien que la présence d’un paramètre dans cette catégorie signifie uniquement qu’il peut techniquement être modifié sans migration, mais peut-être que pour des raisons métier on voudra quand même réaliser une migration en même temps.
Un exemple simple c’est la rétroactivité: sans migration la modification du paramètre ne sera pas rétroactive, la nouvelle valeur s’appliquera uniquement aux nouveaux cas. Si l’on souhaite que le changement soit rétroactif, il faudra coder une migration.

Liste des paramètres par catégorie

Un même paramètre peut se situer dans une catégorie différente selon qu’on souhaite augmenter ou diminuer sa valeur, quand c’est le cas la mention (+) ou (-) est ajoutée après le nom du paramètre.

Les noms des paramètres sont préfixés par le nom de l’instance de la pallet concernée.

1. Never

System.SS58Prefix

Voir Choix du préfixe SS58 pour nos blockchains substrate

Babe.ExpectedBlockTime

Durée attendue entre 2 blocs, en nombre de millisecondes.

Babe.EpochDuration

Durée d’une epoch, exprimée en nombre de ExpectedBlockTime.
Une epoch est une phase pendant laquelle le set des autorités ne peut pas changer. Ça sert aussi à d’autres choses, plus d’informations dans le sujet dédié: Ğ1v2: proposition de passer au consensus hybride BABE/GRANDPA

2. Unexpected

AtomicSwap.ProofLimit

Taille maximale d’une preuve fournie en paramètre du call AtomicSwap.claim_swap().

Vous pouvez voir ça comme l’équivalent du « code » pour débloquer une condition XHX dans duniter v1.

UniversalDividend.UdCreationPeriod

Fréquence de création du DU, en nombre de blocs. Équivalent duniter v1: dt.

3. Migration

*.MaxAuthorities (-)

Regroupe en réalité plusieurs paramètres qui doivent tous avoir la même valeur: Babe.MaxAuthorities, AuthorityMembers.MaxAuthorities, Grandpa.MaxAuthorities, ImOnline.MaxKeys, AuthorityDiscovery.MaxAuthorities.

Chacune de ces pallet substrate à besoin de connaître le nombre maximum d’autorités pouvant être présentes dans une même session.
Vu la quantité énorme de pallets impactés par ce paramètre (il s’agit en plus de pallet particulièrement critiques car liées au mécanisme de consensus), diminuer la valeur de ce paramètre nécessiterait une migration beaucoup trop complexe et risquée.
Même si la diminution de ce paramètre rentre « techniquement » dans cette catégorie, eon ne le baissera jamais, sauf si la survie de la monnaie est en jeux.

System.BlockHashCount (-)

Nombre de hash de blocks à conserver dans le storage onchain du dernier bloc.
Cela va notamment déterminer la durée maximale de validité d’un extrinsic mortel, et de toute éventuelle future payload signée dont on aurait besoin de vérifier la date d’émission.

Balances.ExistentialDeposit (+)

Solde minimal d’un compte Ğ1 sur la blockchain. Si le solde d’un compte passe en dessous de ce seuil, la monnaie restante est transférée à la trésorerie commune et le compte est supprimé.

La suppression du compte implique la suppression de toute donnée liée à ce compte dans l’état courant de la blockchain, y compris le nonce.

Si le compte ne peut pas être supprimé (parce qu’une identité y est rattachée par exemple), alors il est impossible de faire passer le solde en dessous de ce dépôt d’existence, la tentative de transfert échouera.

AuthorityMembers.MaxKeysLife

Durée de vie maximale des sessions keys d’un membre forgeron (en nombre de sessions).

Tout membre forgeron doit modifier régulièrement ses sessions keys pour des raisons évidentes de sécurité, si un membre forgeron oubli de modifier ses sessions keys pendant ure durée supérieure à MaxKeysLife sessions, il perdra son statut de forgeron. Il peut le redemander immédiatement, ce n’est pas une sanction, juste une sécurité pour s’assurer que seul les forgerons effectivement actifs peuvent rester forgerons.

AuthorityMembers.MaxOfflineSessions

Nombre maximum de sessions consécutives auxquelles un membre forgeron a le droit de ne pas participer, au-delà le membre perd automatiquement son statut de forgeron. Il peut le redemander immédiatement, ce n’est pas une sanction, juste une sécurité pour s’assurer que seul les forgerons effectivement actifs peuvent rester forgerons.

UniversalDividend.UdReevalPeriod

Fréquence de réévaluation du DU, en nombre de blocs. Équivalent duniter v1: dtReeval.

Wot.MinCertForMembership (-)

Nombre minimal de certifications reçus à atteindre pour acquérir le statut de membre de la toile de confiance. Équivalent duniter v1: sigQty

Wot.MinReceivedCertToBeAbleToIssueCert

Nombre minimal de certifications reçus à atteindre pour pouvoir émettre des certifications.

Cert.MaxByIssuer (-)

Nombre maximal de certifications émises pouvant être actives en même temps.
Équivalent duniter v1: sigStock.

SmithsSubWot.MinCertForMembership (-)

Nombre minimal de certifications de type forgeron à recevoir pour acquérir le statut de forgeron.

SmithsSubWot.MinReceivedCertToBeAbleToIssueCert

Nombre minimal de certifications de type forgeron à recevoir pour pouvoir émettre soi-même des certifications de type forgeron.

SmithsCert.MaxByIssuer (-)

Nombre maximal de certifications émises (de type forgeron) pouvant être actives en même temps.

Treasury.MaxApprovals (-)

Nombre maximal de propositions (d’utilisation de la trésorerie) pouvant être approuvées mais pas encore exécutées. Si cette limite est atteinte, il est impossible d’approuver une autre proposition, il faut alors attendre qu’au moins une proposition approuvée soit exécutée ou annulée.

Treasury.SpendPeriod

Fréquence à laquelle la blockchain exécute les paiements que la trésorerie doit effectuer. Cela inclus les propositions approuvées, mais également tout autre usage implémenté par le handler SpendFunds.
La pallet treasury n’a pas besoin de migration pour changer ce paramètre, mais l’implémentation du handler SpendFunds peut en avoir besoin.

4. Easy

*.MaxAuthorities (+)

Déjà défini.
Augmenter la valeur de ce paramètre est très simple, il vaut donc mieux commencer limité et augmenter petit à petit à mesure que nos tests réseaux sont concluants.

System.BlockHashCount (+)

Déjà défini plus haut.

System.MaxConsumers

Valeur maximale du compteur consumers pour tout compte.
Chaque compte possède 3 compteurs entiers (consumers, providers et sufficients), qui permettent de savoir quand est-ce qu’un compte peut être supprimé. Plus d’informations dans le sujet dédié: [sujet à créer]

TransactionPayment.TransactionByteFee

Frais à payer en fonction de la taille de la transaction en octets, dans son format SCALE encodé (sérialisé).

Scheduler.MaximumWeight

Poids maximal que la pallet scheduler peut utiliser dans un bloc pour l’exécution des call programmés. Si cette limite est atteinte, les call restant sont reportés au bloc suivant.

Scheduler.MaxScheduledPerBlock

Nombre maximum de call programmés que la pallet scheduler est censée pouvoir exécuter dans un bloc. Cette limite n’est pas forcée, si elle set dépassée seul un warning est loggé.
La valeur de ce paramètre est utilisée pour estimer le poid de certains call de cette pallet, elle doit donc être d’un ordre de grandeur réaliste.

Account.MaxNewAccountsPerBlock

Nombre maximum de nouveaux comptes pouvant être créés dans un même bloc.
Si cette limite est atteinte, les comptes restant dans la queue seront créés au prochain bloc.

La création d’un compte revient à prélever les frais de création, et à programmer l’affectation d’un random id.

La création d’un compte est automatiquement demandée lorsque ce compte reçoit de la monnaie.

Account.NewAccountPrice

Frais de création d’un compte simple portefeuille.
Pour ne pas payer ces frais, il faut créer l’identité en même temps qu’on alimente le compte (dans le même bloc), ce qui peut être garanti via le call batch.

Balances.ExistentialDeposit (-)

Déjà défini plus haut.

Balances.MaxLocks

Concept de substrate que nous n’utilisons pas, je ne vais donc pas le décrire, on mettra zéro dans tous nos runtimes.

Balances.MaxReserves

Concept de substrate que nous n’utilisons pas, je ne vais donc pas le décrire, on mettra zéro dans tous nos runtimes.

ImOnline.UnsignedPriority

Priorité des transactions publiant un signal heartbeat. Il est recommandé de donner la priorité maximale.

ImOnline.MaxPeerDataEncodingSize

Taille maximale d’un endpoint libp2p (au format multiaddr SCALE encodé).

ImOnline.MaxPeerInHeartbeats

Nombre maximum d’endpoints libp2p pouvant être listés dans un signal heartbeat.

À chaque session, chaque autorité active doit publier au moins 1 signal heartbeat, ce heartbeat doit contenir plusieurs informations, dont notamment la liste des endpoint libp2p connus (au format multiaddr).

ProvideRandomness.MaxRequests

Nombre maximum de demandes de tirage aléatoire en cours de traitement. Lorsque cette limite est atteinte, toute nouvelle demandes de tirage aléatoire (call ProvideRandomness.request) échoue.
Il faut alors réésayer plus tard (le temps que certaines demandes soient traitées).

ProvideRandomness.RequestPrice

Prix d’une demande de tirage aléatoire.

Multisig.MaxSignatories

Nombre maximum de co-propriétaires d’un compte partagé.

Proxy.MaxProxies

Nombre maximum de « délégations » par compte.

Proxy.MaxPending

Nombre maximum d’actions de délégataires pouvant être « annoncées » par compte.

Un délégataire à en effet la possibilité (voir l’obligation selon les modalités de délégation), d’annoncer à l’avance une action qu’il va réaliser au nom du compte pour lequel des droits ont été délégués.
Cela donne la possibilité au propriétaire d’origine (ou à un autre délégataire) de contrôler l’action et éventuellement de la rejetée avant qu’elle ne soit exécutée.

Si pour un compte donné, il ya déjà trop d’action annoncée, aucun délégataire ne peut en annoncer une nouvelle, il faut alors attendre que certaines actions annoncées soient exécutées où rejeter ou annulées.

UniversalDividend.SquareMoneyGrowthRate

Corresponds à la valeur de c^2 dans la formule de réévaluatiorn du DU.
Équivalent duniter v1: c (mais exprimé directement au carré)

Wot.FirstIssuableOn

Délai (en nombre de bloc) entre l’entrée dnas la toile de confiance et la capacité à émettre une 1ènre certification. Peut valloir zéro si l’un ne soufaite aucun délai (comme c’est le cas dans la Ğ1v1).

Wot.MinCertForCreateIdtyRight

Nombre minimal de certifications qu’il faut recevoir pour avoir le droit de créer une identité. Doit être supérieur ou égal à MinCertForMembership.

Wot.MinCertForMembership (+)

Déjà défini plus haut.

Identity.ConfirmPeriod

Durée (en nombre de blocs) pendant laquelle le propriétaire d’une identité peut confirmer la demande de création d’identité publiée par le 1er certificateur.
Passé ce délai, l’identité concernée est supprimée, la demande de création d’identité doit donc être republiée par un 1er certificateur.

Identity.IdtyCreationPeriod

Durée minimale (en nombre de blocs) entre la création de 2 identités par un même « 1er certificateur ».

À noter que comme la création d’une identité implique la certification de celle-ci, le paramètre Cert.CertPeriod rentre également en compte. Pour qu’une identité puisse être créée les 2 délais doivent être respectés.

Membership.MembershipPeriod

Délai (en nombre de blocs) au bout duquel l’identité est révoquée si elle n’a pas renouvellée son adhésion.
Équivalent duniter v1: msValidity.

Membership.PendingMembershipPeriod

Délai (en nombre de blocs) au bout duquel une identité non-validée est supprimée. Le délai commence à courir à partir de la demande d’adhésion, demande d’adhésion qui est réalisée automatiquement lorsque le propriétaire de l’identité confirme la création de l’identité via le call Identity.confirm_identity.

Par « validée » on entend, devenir membre de la toile de confiance.

Ce paramètre « remplace » les paramètres suivant de duniter v1: idtyWindow, msWindow, sigWindow.

Membership.RenewablePeriod

Délai (en nombre de blocs) au bout duquel une identité peut (re)renouveller son adhésion.
Équivalent duniter v1: msPeriod

Cert.CertPeriod

Délai (en nombre de blocs) entre 2 certifications par un même certificateur.

Équivalent duniter v1: sigPeriod

Cert.CertRenewablePeriod

Délai (en nombre de blocs) au bout duquel une identité peut renouveller une certification émise.
Équivalent duniter v1: sigReplay

Cert.MaxByIssuer (+)

Déja défini.

Cert.ValidityPeriod

Durée de vie (en nombre de blocs) d’une certification. Passé ce délai, la certifiaction expire.

Équivalent duniter v1: sigValidity

SmithsSubWot.FirstIssuableOn

Identique à Wot.FirstIssuableOn mais pour les certifications de type forgeron.

SmithsSubWot.MinCertForMembership (+)

déjà défini.

SmithsMembership.MembershipPeriod

Délai (en nombre de blocs), au bout duquel un membre forgeron perd son statut de forgeron (il redevient un membre « normal ») s’il n’a pas renouvelé son adhésion forgeron.

SmithsMembership.PendingMembershipPeriod

Délai (en nombre de blocs) au bout duquel une demande d’adhésion forgeron expire. Le délai commence à courir à partir de la demande d’adhésion via le call SmithsMembership.request_membership.

SmithsMembership.RenewablePeriod

Identique à Membership.RenewablePeriod, mais pour l’adhésion forgeron.

SmithsCert.CertRenewablePeriod

Identique à Cert.RenewablePeriod, mais pour les certifications de type forgeron.

SmithsCert.MaxByIssuer (+)

Identique à Cert.MaxByIssuer, mais pour les certifications de type forgeron.

SmithsCert.ValidityPeriod

Identique à Cert.ValidityPeriod, mais pour les certifications de type forgeron.

SmithsCollective.MotionDuration

Durée maximale (en nombre de blocs) pendant laquelle il est possible de voter pour une proposition d’action à exécuter au nom d’une proportion des membres forgerons.

Passé ce délai, si le seuil de votes favorables (défini dans la proposition) n’est pas atteint, la proposition est cloturée.

SmithsCollective.MaxProposals

Nombre maximum de propositions d’actions «au nom d’une proportion des membres forgerons» pouvant être ouvertes au vote en même temps.
Si cette limite est atteinte, toute tentative de soumettre une nouvelle proposition échouera, il faut alors attendre qu’une proposition en cours soit clôturée.

SmithsCollective.MaxMembers

Nombre maximum de membres forgerons.
C’est une borne supérieure qui est utilisée dans le calcul du « poids maximal » des extrinsics de l’instance de la pallet SmithsCollective.
Pour rappel le poids réel d’un extrinsic (retourné à la fin de son exécution) peut être inférieur au poids maximal, le max est utilisé pour savoir s’il reste de la place dans le bloc avant d’exécuter éventuellement l’extrinsic.

Treasury.MaxApprovals (+)

déja défini.

Treasury.ProposalBond

Proportion du montant de la proposition (d’utilisation de la trésorerie) qui doit être déposée pour pouvoir soumettre la proposition. Ce dépot est très important car il est le seul rempart centre le spam de propositions.
Ce dépot est obligatoirement perdu en cas de rejet de la proposition.

L’idée est de s’assurer que la proposition est sérieuse, afin que la communauté ne perde pas de temps pour voter sur des propositions fantaisistes. En effet, on ne soumettra une proposition en blockchain que si l’on sait qu’elle à de bonnes chances d’être acceptée, donc qu’on en a déjà discuté avec la communauté avant.

Le montant de ce dépot est borné par les paramètres ProposalBondMinimum et ProposalBondMaximum

Treasury.ProposalBondMinimum

Montant minimal du dépot associé à une proposition (voir paramètre ProposalBond).

4 « J'aime »

Voilà maintenant que j’ai enfin pris le temps de lister tous les paramètres, on va pouvoir discuter des valeurs de ces paramètres pour la 1ère monnaie de test, une étape de plus vers son lancement :slight_smile:

Je rappelle que ces paramètres sont juste le reflet de l’état actuel du code, et pas une prescription de ce qu’on doit faire. Il est évident que certains paramètres seront ajoutés/supprimés/modifiés, en fonction des besoins et des retours d’expérience de la 1ère monnaie de test.

Cela sous-entend: svp ne râlez pas. Si quelque chose ne vous convient pas à la lecture de ce post, posez vous 5 min avant de répondre et prenez le temps d’identifier quel est le besoin qui vous semble compromis par ce que vous avez lu. Puis formulez clairement votre besoin et demandez s’il est actuellement bien adressé et comment (même si vous êtes certain qu’il n’est pas adressé correctement en vue de ce que vous avez compris).

3 « J'aime »