GTest Paramètres

[bgallois]

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

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

[tuxmain]

Je lis toute la liste et fais un commentaire sur tous les paramètres qui me posent question :

MaxAuthorities

32 semble petit mais

@elois

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.

@elois

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 :

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

[elois]

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 [frame/im-online] remove network state from heartbeats by melekes · Pull Request #14251 · paritytech/substrate · GitHub ; 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

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: Draft: Resolve "Paramétrage de la ĞTest" (!327) · Merge requests · nodes / rust / Duniter v2S · GitLab

[tuxmain]

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

[HugoTrentesaux]

@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

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

[elois]

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

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.