J’ai commencé à examiner l’état privé de DUSK à partir de la mauvaise métrique, à savoir le premier total de notes créées. Cela ressemble à l’histoire de stockage évidente, mais cela ne montre qu’une seule courbe. @Dusk
L’arbre des notes grandit lorsque des sorties sont créées. L’ensemble des nullificateurs grandit lorsque des notes sont dépensées. Ils sont liés, mais ce n’est pas le même comportement.
Prenons 100 M de notes Phoenix, dont 60 M ont déjà été dépensées. DUSK conserve encore l’historique des notes créées, tandis que le côté des nullificateurs a déjà atteint 60 M d’entrées. Si 70 % sont finalement dépensées, cela fait 70 M de nullificateurs. Avec 1 Md de notes et 750 M de nullificateurs, la question devient moins confortable : quelle structure finit par devenir la charge d’état à long terme la plus lourde ?
Une transaction à 4 entrées / 1 sortie rend cela plus clair. Les notes en vie baissent de trois nettes, mais quatre nouveaux nullificateurs sont ajoutés. Un nombre inférieur de notes en vie ne signifie pas un historique d’état moins lourd.
Une partie de la croissance est normale. Les systèmes privés ont besoin d’engagements et de protection contre les notes dépensées.
Le vrai test est de savoir si DUSK peut garder les deux courbes efficaces à mesure que l’usage s’accumule. Le fait de tronquer, d’indexer, de prouver et de synchroniser peut-il rester raisonnable ? Ou la confidentialité finit-elle par devenir une taxe d’infrastructure ?
Pour l’activité de DUSK, ce n’est pas la métrique difficile. C’est la discipline d’état.
#dusk $DUSK
L’arbre des notes grandit lorsque des sorties sont créées. L’ensemble des nullificateurs grandit lorsque des notes sont dépensées. Ils sont liés, mais ce n’est pas le même comportement.
Prenons 100 M de notes Phoenix, dont 60 M ont déjà été dépensées. DUSK conserve encore l’historique des notes créées, tandis que le côté des nullificateurs a déjà atteint 60 M d’entrées. Si 70 % sont finalement dépensées, cela fait 70 M de nullificateurs. Avec 1 Md de notes et 750 M de nullificateurs, la question devient moins confortable : quelle structure finit par devenir la charge d’état à long terme la plus lourde ?
Une transaction à 4 entrées / 1 sortie rend cela plus clair. Les notes en vie baissent de trois nettes, mais quatre nouveaux nullificateurs sont ajoutés. Un nombre inférieur de notes en vie ne signifie pas un historique d’état moins lourd.
Une partie de la croissance est normale. Les systèmes privés ont besoin d’engagements et de protection contre les notes dépensées.
Le vrai test est de savoir si DUSK peut garder les deux courbes efficaces à mesure que l’usage s’accumule. Le fait de tronquer, d’indexer, de prouver et de synchroniser peut-il rester raisonnable ? Ou la confidentialité finit-elle par devenir une taxe d’infrastructure ?
Pour l’activité de DUSK, ce n’est pas la métrique difficile. C’est la discipline d’état.
#dusk $DUSK
