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
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.
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.
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.
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).
