# GTest Paramètres
**URL:** https://forum.duniter.org/t/gtest-parametres/13134
**Category:** ĞTest
**Created:** [16 June 2025 09:41 UTC](https://forum.duniter.org/t/gtest-parametres/13134 "2025-06-16T09:41:26Z")
**Posts on this page:** 10
**Page:** 1
### Author:  [@bgallois](https://forum.duniter.org/u/bgallois)
#### Post date: [16 June 2025 09:41 UTC](https://forum.duniter.org/t/gtest-parametres/13134/1 "2025-06-16T09:41:26Z")
Comme évoqué lors de la dernière réunion développeurs, le lancement d’un test GTest prévu pour début juillet nécessite une révision des paramètres de la chaîne, qui n’ont pas encore été examinés. Je poste ici la liste (plus ou moins complète) des paramètres numériques de la chaîne. Restera aussi la question du treasury spend origin à régler [Set correct treasury spend origin (!314) · Merge requests · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/314)
| Pallet | Parameter Name | Description | Value |
| --- | --- | --- | --- |
| **System** | BlockHashCount | Maximum number of block number to block hash mappings to keep | 2400 blocks (4 hours) |
| | BlockWeights | Block weights and limits | 2 seconds of compute (6s avg block time) |
| | BlockLength | Maximum block length | 5 MB |
| | SS58Prefix | Chain identifier prefix | 42 |
| | MaxConsumers | Maximum number of consumers for an account | 16 |
| **Authority Discovery** | MaxAuthorities | Maximum number of authorities | 32 |
| **Timestamp** | MinimumPeriod | Minimum time between blocks | 3000 ms (SLOT\_DURATION/2) |
| **Distance** | MinAccessibleReferees | Minimum percentage of accessible referees | 80% |
| | MaxRefereeDistance | Maximum referee distance | 5 |
| | EvaluationPeriod | Period for distance evaluation | 7 blocks (42 seconds) |
| | EvaluationPrice | Price for requesting distance evaluation | 1000 |
| **Babe** | EpochDuration | Duration of an epoch in slots | 600 blocks (1 hour) |
| | ExpectedBlockTime | Expected block time | 6000 ms |
| | ReportLongevity | Longevity of equivocation reports | 100,800 blocks (7 days) |
| | PrimaryProbability | Probability of primary block production | 1/4 (25%) |
| **ImOnline** | ImOnlineUnsignedPriority | Priority of unsigned im-online transactions | MAX |
| | MaxPeerInHeartbeats | Maximum peers in heartbeats | 10,000 |
| | MaxPeerDataEncodingSize | Maximum peer data encoding size | 1,000 |
| **Balances** | ExistentialDeposit | Minimum balance to keep an account alive | 100 |
| | MaxLocks | Maximum number of locks per account | 50 |
| | MaxReserves | Maximum number of reserves per account | 5 |
| **Universal Dividend** | SquareMoneyGrowthRate | Money growth rate squared | 0.002381440 (0.0488²) |
| | UdCreationPeriod | Period between UD creations | 14,400 blocks (1 day) |
| | UdReevalPeriod | Period between UD reevaluations | 100,800 blocks (7 days) |
| | MaxPastReeval | Maximum past reevaluations stored | 160 |
| **WOT** | WotFirstCertIssuableOn | First block when certifications can be issued | 14,400 blocks (1 day) |
| | WotMinCertForMembership | Minimum certifications needed for membership | 5 |
| | MinReceivedCertToBeAbleToIssueCert | Minimum received certs to be able to issue certs | 5 |
| | WotMinCertForCreateIdtyRight | Minimum certifications needed to create identity right | 5 |
| **Identity** | ChangeOwnerKeyPeriod | Period to change owner key | 438,300 blocks (~1 month) |
| | ConfirmPeriod | Confirmation period for identity operations | 14,400 blocks (1 day) |
| | IdtyCreationPeriod | Period between identity creations | 14,400 blocks (1 day) |
| | AutorevocationPeriod | Period before auto-revocation | 5,259,600 blocks (~1 year) |
| | DeletionPeriod | Period before identity deletion | 52,596,000 blocks (~10 years) |
| | ValidationPeriod | Period for identity validation | 87,600 blocks (~2 months) |
| **Membership** | MembershipPeriod | Duration of membership | 1,051,200 blocks (~73 days) |
| | MembershipRenewalPeriod | Period for membership renewal | 806,400 blocks (~56 days) |
| **Certification** | CertPeriod | Period between certifications | 14,400 blocks (1 day) |
| | MaxByIssuer | Maximum certifications per issuer | 100 |
| | ValidityPeriod | Validity period of certifications | 210,240 blocks (~146 days) |
| **Smith-Members** | SmithWotMinCertForMembership | Minimum certs for Smith membership | 3 |
| | SmithMaxByIssuer | Maximum Smith members per issuer | 100 |
| | SmithInactivityMaxDuration | Maximum inactivity duration for Smith members | 48 blocks (4.8 minutes) |
| **Multisig** | MaxSignatories | Maximum number of signatories | 10 |
| **Treasury** | TreasuryPalletId | Treasury account pallet ID | “py/trsry” |
| | SpendPeriod | Period between treasury spends | 14,400 blocks (1 day) |
| | Burn | Percentage of funds to burn | 0% |
| | ProposalBond | Percentage of proposal value to bond | 1% |
| | ProposalBondMaximum | Maximum proposal bond amount | None |
| | MaxApprovals | Maximum treasury approvals | 100 |
| | PayoutPeriod | Payout period | 100 |
| **Scheduler** | MaximumSchedulerWeight | Maximum weight for scheduler operations | 80% of max block weight |
| | MaxScheduledPerBlock | Maximum scheduled calls per block | 50 |
| | NoPreimagePostponement | Postponement when no preimage | 10 |
| **Quota** | ReloadRate | Rate at which quota reloads | 600 blocks (1 hour) |
| | MaxQuota | Maximum quota amount | 1000 (10 ĞD) |
| | MaxNominators | Maximum number of nominators | 64 |
| **Transaction Payment** | Target | Target block saturation for fee adjustment | 25% |
| | MaxMultiplier | Maximum fee multiplier | 10 |
| | OperationalFeeMultiplier | Multiplier for operational transactions | 5 |
| **Proxy** | ProxyDepositBase | Base deposit for proxy | 108 (100 + 8) |
| | ProxyDepositFactor | Additional deposit per proxy | 33 (0 + 33) |
| | AnnouncementDepositBase | Base deposit for announcement | 108 (100 + 8) |
| | AnnouncementDepositFactor | Additional deposit per announcement | 66 (0 + 66) |
| | MaxPending | Maximum pending proxy announcements | 32 |
| | MaxProxies | Maximum proxies per account | 32 |
| **Preimage** | PreimageMaxSize | Maximum preimage size | 4096 KB |
| | PreimageBaseDeposit | Base deposit for preimage | 264 (200 + 64) |
| | PreimageByteDeposit | Deposit per byte for preimage | 1 (0 + 1) |
| **Grandpa** | MaxSetIdSessionEntries | Maximum session entries for set ID | 1000 |
| | MaxNominators | Maximum nominators per validator | 64 |
| **Atomic Swap** | ProofLimit | Maximum proof size | 1024 bytes |
| **Provide Randomness** | MaxRequests | Maximum randomness requests | 100 |
| | RequestPrice | Price per randomness request | 2000 |
| **Technical Committee** | TechnicalCommitteeMotionDuration | Duration for technical committee motions | 100,800 blocks (7 days) |
| | MaxWeight | Maximum weight for technical committee proposals | 50% of max block weight |
| | MaxMembers | Maximum committee members | 100 |
| | MaxProposals | Maximum active proposals | 20 |
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [28 June 2025 09:33 UTC](https://forum.duniter.org/t/gtest-parametres/13134/2 "2025-06-28T09:33:08Z")
Je lis toute la liste et fais un commentaire sur tous les paramètres qui me posent question :
### MaxAuthorities
32 semble petit mais
> [@Liste des paramètres (protocolaires) de Duniter-v2s](https://forum.duniter.org/t/liste-des-parametres-protocolaires-de-duniter-v2s/9297/1):
>
> 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.
> [@Liste des paramètres (protocolaires) de Duniter-v2s](https://forum.duniter.org/t/liste-des-parametres-protocolaires-de-duniter-v2s/9297/1):
>
> 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.
Il faudrait toutefois regarder s’il y a une raison de limiter autant, si l’augmenter créerait un risque de sécurité ou de stabilité.
### MaxPeerInHeartbeats
10 000 ça fait beaucoup, je ne sais pas si ça correspond à un nombre d’auteurs de blocs à garder en mémoire. Puisqu’on a moins d’auteurs et une EpochDuration plus petite que PolkaDot, peut-être qu’on peut le réduire.
### SquareMoneyGrowthRate
0.0488 est tronqué, il faut repartir de c=10% pour avoir une meilleure approximation :
```python
>>> (1.1**0.5-1)**2
0.0023823036596969144
```
Donc la valeur serait `Perbill::from_parts(2_382_304)`.
### ConfirmPeriod
1 jour semble peu : imaginez une rencontre Ğ1 où les gens n’ont pas leur machine ou n’ont pas Internet, on promet des certifications. La création du portefeuille, la création de l’identité et la confirmation nécessitent plusieurs allers-retours de communication entre les gens, ce qui peut prendre plusieurs jours si la Ğ1 n’est pas leur seul soucis dans la vie ou que l’accès Internet est intermittent. Donc soit il faut obliger à avoir Internet simultanément pour le premier certificateur et le nouveau membre durant les rencontres physiques, soit je propose d’étendre à 10 jours (une semaine + un week-end).
Il ne faut pas oublier que chaque délai devra être compris par les utilisateurs et causera des mauvaises interprétations voire des superstitions. Peut-être même que 2 mois serait mieux, pour ne pas ajouter de délai supplémentaire à retenir par rapport à la v1.
### SmithInactivityMaxDuration
Ce sont des sessions et non des blocs, donc ça fait 2 jours. Ça fait peu, étant donné qu’il faut à nouveau 3 certifications pour rentrer. Si je go offline pour une semaine de vacances ou un déménagement du serveur pendant 3 jours ? Je propose au moins 1 mois. (l’exclusion automatique est là pour gérer les pannes)
### ProposalBond
Whaaat? C’est le pourcentage de la proposition qui doit être réservée _par le compte qui propose, sur ses fonds propres_. Bon pour le moment ça n’importe pas puisqu’il n’y a pas de mécanisme de prise de décision, mais il faudra mettre ça à zéro un jour. (limiter les propositions aux membres, et en limiter le nombre par membre, devrait suffire comme antispam)
### MaxNominators
C’est un paramètre de `staking` qu’on n’utilise pas, je suppose qu’il s’est glissé dans le code par un copier-coller malheureux ?
### RequestPrice
Je ne sais plus si on utilise encore Provide Randomness, mais 20Ğ1 ça fait beaucoup. 1Ğ1 suffirait, et rentrerait dans le quota.
* * *
Sur tout le reste soit je suis OK, soit je fais aveuglément confiance à la valeur précédente.
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [28 June 2025 12:26 UTC](https://forum.duniter.org/t/gtest-parametres/13134/3 "2025-06-28T12:26:48Z")
## SS58Prefix
Il a été proposé de le fixer à la même valeur que la Ǧ1 pour habituer les utilisateurs à leurs véritables futures adresses qui commenceront par “g1”.
## EpochDuration
1 h, c’était pour la gdev ; pour la Ǧ1, je recommandais 4 h. Ce serait bien d’augmenter à 4 h dès la Ǧtest pour habituer les forgerons aux vrais délais.
## MaxPeerInHeartbeats
Ce paramètre n’est plus utilisé depuis [https://github.com/paritytech/substrate/pull/14251](https://github.com/paritytech/substrate/pull/14251) ; il aurait dû être supprimé (oui, il y a de la dette technique dans le polkadot-sdk). Donc sa valeur n’a pas d’impact.
## ConfirmPeriod
L’objectif de ce délai court était d’empêcher le spam ; si on allonge ConfirmPeriod, je recommande d’allonger également IdtyCreationPeriod de la même durée afin que chaque membre ne puisse créer qu’une seule nouvelle identité à la fois.
## SmithInactivityMaxDuration
C’est effectivement un nombre de sessions ; l’objectif est de s’assurer qu’on ne laisse pas traîner des droits pour des forgerons qui ne sont plus actifs. Deux à trois mois sont suffisants pour cela (le forgeron inactif aura déjà été mis hors ligne par la blockchain au bout de quelques heures).
## MaxNominators
> [@tuxmain](#):
>
> C’est un paramètre de staking qu’on n’utilise pas, je suppose qu’il s’est glissé dans le code par un copier-coller malheureux ?
Ce paramètre est imposé par la pallet grandpa car cela impacte les benchmarks de Polkadot pour évaluer le coût de soumission d’une offense (car, quand un validateur est slashé, chacun de ses nominateurs doit l’être également). On doit fournir une valeur pour que le code compile, mais elle n’est pas utilisée dans nos benchmarks : [runtime/gdev/src/weights/pallet\_grandpa.rs · master · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/blob/master/runtime/gdev/src/weights/pallet_grandpa.rs#L32)
## RequestPrice
> [@tuxmain](#):
>
> Je ne sais plus si on utilise encore Provide Randomness, mais 20Ğ1 ça fait beaucoup. 1Ğ1 suffirait, et rentrerait dans le quota.
La pallet randomness est toujours dans le runtime, et il me paraît utile qu’elle y soit pour permettre des cas d’usage offchain souhaitant obtenir une source d’aléatoire non manipulable, comme un tirage au sort par exemple. Ce montant peut être diminué sans migration ; je suggère de le laisser à 20 Ğ1 pour le moment.
* * *
Je n’ai vérifié que les paramètres des catégories `Never`, `Unexpected` et `Migration`, ainsi que ceux commentés par tuxmain. Je n’ai pas vérifié les paramètres de la catégorie `Easy` car on peut les corriger sans migration après le lancement, si besoin.
EDIT: j’ai ouvert une MR brouillon pour modifier/finaliser les paramètres de la ĞTest: [Resolve "Paramétrage de la ĞTest" (!327) · Merge requests · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/327)
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [28 June 2025 17:32 UTC](https://forum.duniter.org/t/gtest-parametres/13134/4 "2025-06-28T17:32:28Z")
> [@elois](#):
>
> ## ConfirmPeriod
>
> L’objectif de ce délai court était d’empêcher le spam ; si on allonge ConfirmPeriod, je recommande d’allonger également IdtyCreationPeriod de la même durée afin que chaque membre ne puisse créer qu’une seule nouvelle identité à la fois.
C’est ce que je me disais, mais si on allonge à 10 jours, pouvoir créer 10 identités non validées simultanément, ce n’est pas un pouvoir de nuisance considérable. Et si ça fait du spam social (plein de fausses identités qui apparaissent dans l’annuaire), les certificateurs peuvent le voir.
Et de toute façon si on veut spammer de cette manière, on peut créer des identités dont on contrôle la clé, et confirmer immédiatement. La durée de confirmation n’a pas d’effet dans ce cas.
L’enjeu est donc sur la création d’identité pour des comptes appartenant à autrui, ce qui ne profite pas au spammeur et viole la licence.
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 July 2025 10:33 UTC](https://forum.duniter.org/t/gtest-parametres/13134/5 "2025-07-04T10:33:56Z")
3 posts were split to a new topic: [Quand pourra-t-on démarrer une ĞTest?](https://forum.duniter.org/t/quand-pourra-t-on-demarrer-une-gtest/13167)
---
### Author:  [@HugoTrentesaux](https://forum.duniter.org/u/HugoTrentesaux)
#### Post date: [4 July 2025 10:33 UTC](https://forum.duniter.org/t/gtest-parametres/13134/8 "2025-07-04T10:33:00Z")
> [@bgallois](#):
>
> UdReevalPeriod Period between UD reevaluations 100,800 blocks (7 days)
Il faut passer à 6 mois si on veut s’aligner sur la v1.
> [@bgallois](#):
>
> MembershipPeriod Duration of membership 1,051,200 blocks (~73 days)
Il faut passer à un an.
> [@bgallois](#):
>
> CertPeriod Period between certifications 14,400 blocks (1 day)
Il faut passer à 5 jours.
> [@bgallois](#):
>
> ValidityPeriod Validity period of certifications 210,240 blocks (~146 days)
Il faut passer à deux ans.
> [@bgallois](#):
>
> MaxNominators Maximum number of nominators 64
Pas dans Quota, ça doit être une ligne en doublon de grandpa 😃
> [@tuxmain](#):
>
> ### ConfirmPeriod
>
> 1 jour semble peu
> [@V2- certification - 72h au lieu de 48h](https://forum.duniter.org/t/v2-certification-72h-au-lieu-de-48h/12498):
>
> Lorsqu’une…
Également favorable à deux mois
> [@tuxmain](#):
>
> pouvoir créer 10 identités non validées simultanément
De toute façons la création d’identité venant avec une certification, on est limité par le délai de 5 jours.
* * *
En dehors des paramètres, il y a :
- le prefix SS58 comme le dit elois (#ss58)
- le nom de monnaie
- la valeur du DU initiale
- la toile forgeron initiale
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [4 July 2025 13:12 UTC](https://forum.duniter.org/t/gtest-parametres/13134/9 "2025-07-04T13:12:29Z")
Merci @HugoTrentesaux pour ton retour sur les paramètres ! Je viens de les mettre à jour conformément à tes suggestions dans cette MR : [Draft: Resolve "Paramétrage de la ĞTest" (!327) · Merge requests · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/327)
quote=“HugoTrentesaux, post:8, topic:13134”]
le nom de monnaie
[/quote]
Le code de duniter-v2s ne contient que le nom du runtime (« gtest ») et le symbole du token (« ĞT »). À mon avis, il n’y a rien à modifier dans le code pour ce point.
> [@HugoTrentesaux](#):
>
> la valeur du DU initiale
Je crois que cette valeur est extraite de l’image v1. Il reste à tester pour vérifier si la configuration mise en place par cgeek fonctionne pour Gtest.
---
### Author:  [@tuxmain](https://forum.duniter.org/u/tuxmain)
#### Post date: [21 February 2026 10:43 UTC](https://forum.duniter.org/t/gtest-parametres/13134/10 "2026-02-21T10:43:34Z")
Les paramètres de la G1 n’avaient pas été corrigés. J’en ai changé quelques uns en essayant de coller à la v1 et à la gtest, et à ce qui a été proposé ici et [là (attente avant droit à certifier, j’ai passé à 0)](https://forum.duniter.org/t/wait-24h-before-ability-to-certifiy/13447) et [là (durée de l’époque à 1h)](https://forum.duniter.org/t/epoc-duration-in-substrate-ecosystem/13590/1).
Si plusieurs personnes pouvaient relire (les changements et les autres paramètres que je n’ai pas modifiés) ce serait bien. @HugoTrentesaux @cgeek
> **[gtest: fix SquareMoneyGrowthRate (!346) · Merge requests · nodes / rust /...](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/346/diffs)**
>
> https://forum.duniter.org/t/gtest-parametres/13134/2?u=tuxmain#p-112874-squaremoneygrowthrate-3 The current value is computed from 0.0488, which is a truncation from the actual value computed from 10%.
---
### Author:  [@Maaltir](https://forum.duniter.org/u/Maaltir)
#### Post date: [21 February 2026 11:02 UTC](https://forum.duniter.org/t/gtest-parametres/13134/11 "2026-02-21T11:02:29Z")
J’avais posé un ticket sur les renouvellements avant échéance : [Renouvellement de certification et d'adhésion avant échéance (#338) · Issues · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/issues/338)
---
### Author:  [@elois](https://forum.duniter.org/u/elois)
#### Post date: [24 February 2026 19:53 UTC](https://forum.duniter.org/t/gtest-parametres/13134/12 "2026-02-24T19:53:28Z")
> [@tuxmain](#):
>
> [fix g1 and gtest parameters (!346) · Merge requests · nodes / rust / Duniter v2S · GitLab](https://git.duniter.org/nodes/rust/duniter-v2s/-/merge_requests/346/diffs)
Certains changements de paramètres me semblent présenter des risques. Il est encore temps de les ajuster avant la migration :
### Majeur : Le paramètre ChangeOwnerKeyPeriod est passé de 6 mois à 1 mois.
Cette durée me paraît excessivement courte et potentiellement dangereuse, car elle pourrait faciliter la prise de contrôle définitive d’un compte membre.
En cas de piratage d’un compte peu actif, un attaquant pourrait modifier la clé propriétaire afin de s’approprier définitivement le compte. L’objectif principal du paramètre ChangeOwnerKeyPeriod est précisément de laisser un délai suffisant au membre victime pour constater le piratage et révoquer son compte à l’aide de l’ancienne clé. Cela permet ensuite à ses certificateurs de le recertifier sur un nouveau compte.
Pour cette raison, ce paramètre devrait rester relativement long ; une durée de 6 mois me semble constituer un minimum prudent.
### Moyen : Le paramètre IdtyCreationPeriod est passé de 14 jours à 1 jour.
Le paramètre IdtyCreationPeriod devrait être suffisamment long afin de limiter le spam de fausses demandes de création de comptes.
Dans la G1 v1, il n’est possible de certifier une nouvelle personne que tous les 5 jours. Il semblerait donc cohérent de limiter également la création d’une nouvelle identité à une fréquence maximale d’une tous les 5 jours.