Hier, je comptais abandonner, mais j’ai quand même essayé d’exécuter en local la configuration des nœuds du @Dusk pour compiler le cœur du dépôt rusk` sur le réseau de test : je me suis retrouvé bloqué sur un log de comparaison dans un état de synchronisation de consensus.
Je suis allé fouiller la logique de mise en gage des nœuds dans le module consensus/staking, et j’ai remarqué un nom de variable vraiment intéressant : AttestationCapacity. J’ai tout de suite été intrigué.
Je pensais au départ que c’était juste un champ standard pour enregistrer le montant verrouillé du nœud, mais en suivant l’appel jusqu’à rewards_emission.rs, j’ai découvert que Dusk joue en dessous une stratégie très hardcore de liaison à la puissance de calcul.
Sur la plupart des chaînes PoS précédentes, les récompenses d’un nœud sont entièrement un « jeu de capital ». Concrètement : plus tu as de pièces, plus longtemps tu les immobilises, plus tu reçois de récompenses d’inflation. Même si ton serveur tourne sur un Raspberry Pi, personne ne s’en occupe. Mais dans le code de Dusk, les gains de mise en gage du nœud sont fortement liés à la latence de calcul de la réponse ZK de la machine virtuelle Piecrust.
Si un nœud a seulement un solde élevé, mais qu’au cours du consensus SA de la manche précédente il traite un hash Poseidon ou qu’il valide une preuve Plonk avec un léger retard, alors l’algorithme d’atténuation du système va directement réduire le poids dynamique de son AttestationCapacity. En termes simples : les « gros qui挂机 sans puissance suffisante » verront leurs revenus rognés de force par le système.
Un autre design très intéressant : sa logique de destruction (burn) des Gas. Dans le module de traitement des frais fee_collector, le Base Fee de chaque transaction conforme est fixé et brûlé au niveau protocolaire. Seule la Priority Fee est répartie selon des poids aux nœuds de puissance de calcul qui participent réellement à la validation ZK.
J’ai estimé à partir des logs de puissance de calcul obtenus sur le réseau de test : lorsque le règlement des actifs RWA de niveau supérieur atteint une fréquence de transactions donnée, le taux de destruction du Base Gas compense rapidement l’inflation des récompenses de bloc du système.
Il ne s’agit pas de vendre un concept de « super déflation », mais plutôt d’inscrire dans le code de bas niveau un modèle triangulaire où « contribution en puissance », « allocation de mise en gage » et « destruction du Gas » se contraignent mutuellement. Participer au consensus, ce n’est pas rester passif et encaisser : il faut réellement faire remonter la puissance matérielle sur la chaîne. Et toutes ces récompenses sont ancrées sur $DUSK .
#dusk
Je suis allé fouiller la logique de mise en gage des nœuds dans le module consensus/staking, et j’ai remarqué un nom de variable vraiment intéressant : AttestationCapacity. J’ai tout de suite été intrigué.
Je pensais au départ que c’était juste un champ standard pour enregistrer le montant verrouillé du nœud, mais en suivant l’appel jusqu’à rewards_emission.rs, j’ai découvert que Dusk joue en dessous une stratégie très hardcore de liaison à la puissance de calcul.
Sur la plupart des chaînes PoS précédentes, les récompenses d’un nœud sont entièrement un « jeu de capital ». Concrètement : plus tu as de pièces, plus longtemps tu les immobilises, plus tu reçois de récompenses d’inflation. Même si ton serveur tourne sur un Raspberry Pi, personne ne s’en occupe. Mais dans le code de Dusk, les gains de mise en gage du nœud sont fortement liés à la latence de calcul de la réponse ZK de la machine virtuelle Piecrust.
Si un nœud a seulement un solde élevé, mais qu’au cours du consensus SA de la manche précédente il traite un hash Poseidon ou qu’il valide une preuve Plonk avec un léger retard, alors l’algorithme d’atténuation du système va directement réduire le poids dynamique de son AttestationCapacity. En termes simples : les « gros qui挂机 sans puissance suffisante » verront leurs revenus rognés de force par le système.
Un autre design très intéressant : sa logique de destruction (burn) des Gas. Dans le module de traitement des frais fee_collector, le Base Fee de chaque transaction conforme est fixé et brûlé au niveau protocolaire. Seule la Priority Fee est répartie selon des poids aux nœuds de puissance de calcul qui participent réellement à la validation ZK.
J’ai estimé à partir des logs de puissance de calcul obtenus sur le réseau de test : lorsque le règlement des actifs RWA de niveau supérieur atteint une fréquence de transactions donnée, le taux de destruction du Base Gas compense rapidement l’inflation des récompenses de bloc du système.
Il ne s’agit pas de vendre un concept de « super déflation », mais plutôt d’inscrire dans le code de bas niveau un modèle triangulaire où « contribution en puissance », « allocation de mise en gage » et « destruction du Gas » se contraignent mutuellement. Participer au consensus, ce n’est pas rester passif et encaisser : il faut réellement faire remonter la puissance matérielle sur la chaîne. Et toutes ces récompenses sont ancrées sur $DUSK .
#dusk
