@Dusk brûler un tableau de bord face à un après-midi plat de volume de transactions. Je pensais que le total brûlé était un signal net de réduction de l’offre, le genre de chiffre sur lequel on peut pointer et passer à autre chose. Mais quand je l’ai décomposé par bloc, la combustion n’était pas du tout répartie uniformément.
En creusant, j’ai constaté qu’une poignée d’appels de contrats expliquait la majeure partie de la combustion de cette journée, et non une utilisation large du réseau. Cela m’a poussé à examiner comment <c-1/> #dusk structure ses transactions, où les entrées, les sorties et les métadonnées voyagent ensemble comme un seul objet validé. La combustion n’était pas du bruit aléatoire : c’était un résultat direct de chemins d’exécution précis, concentré plutôt que distribué.
C’est à ce moment-là que j’ai séparé deux choses que je traitais comme une seule : réduction de l’offre et distribution de la demande. Un chiffre d’offre en baisse me dit combien de jetons restent en circulation. Il ne dit rien sur le nombre de participants distincts ou d’applications qui ont généré cette activité. Les confondre a fait paraître l’histoire de la déflation plus forte que ce que l’utilisation sous-jacente soutient réellement.
$DUSK
Ce que je n’arrive pas encore à résoudre, c’est comment cela se met à l’échelle. Si les comptes actifs ou les appels de contrats se multiplient plusieurs fois, je ne sais pas quelle variable bouge en premier : le gaz par transaction, la profondeur du mempool, ou le temps d’inclusion sur <t-2/> DuskEVM. Le format de transaction qui rend la validation explicite signifie aussi davantage d’état à transporter, et je n’ai pas encore vu comment cela se comporte sous une pression réelle.
Par la suite, je surveille la combustion par unité mise en jeu par rapport aux récompenses des pourvoyeurs actifs, la densité de frais par époque, et si les sources de combustion se diversifient entre portefeuilles plutôt que de se regrouper. Une activité récurrente provenant d’adresses répétées m’en dira plus que n’importe quel total sur une seule journée ne pourrait jamais le faire.
Je ne sais toujours pas si une structure de transaction aussi explicite devient un avantage sous charge ou un coût croissant que le réseau absorbe silencieusement.$VELVET
$TUT
En creusant, j’ai constaté qu’une poignée d’appels de contrats expliquait la majeure partie de la combustion de cette journée, et non une utilisation large du réseau. Cela m’a poussé à examiner comment <c-1/> #dusk structure ses transactions, où les entrées, les sorties et les métadonnées voyagent ensemble comme un seul objet validé. La combustion n’était pas du bruit aléatoire : c’était un résultat direct de chemins d’exécution précis, concentré plutôt que distribué.
C’est à ce moment-là que j’ai séparé deux choses que je traitais comme une seule : réduction de l’offre et distribution de la demande. Un chiffre d’offre en baisse me dit combien de jetons restent en circulation. Il ne dit rien sur le nombre de participants distincts ou d’applications qui ont généré cette activité. Les confondre a fait paraître l’histoire de la déflation plus forte que ce que l’utilisation sous-jacente soutient réellement.
$DUSK
Ce que je n’arrive pas encore à résoudre, c’est comment cela se met à l’échelle. Si les comptes actifs ou les appels de contrats se multiplient plusieurs fois, je ne sais pas quelle variable bouge en premier : le gaz par transaction, la profondeur du mempool, ou le temps d’inclusion sur <t-2/> DuskEVM. Le format de transaction qui rend la validation explicite signifie aussi davantage d’état à transporter, et je n’ai pas encore vu comment cela se comporte sous une pression réelle.
Par la suite, je surveille la combustion par unité mise en jeu par rapport aux récompenses des pourvoyeurs actifs, la densité de frais par époque, et si les sources de combustion se diversifient entre portefeuilles plutôt que de se regrouper. Une activité récurrente provenant d’adresses répétées m’en dira plus que n’importe quel total sur une seule journée ne pourrait jamais le faire.
Je ne sais toujours pas si une structure de transaction aussi explicite devient un avantage sous charge ou un coût croissant que le réseau absorbe silencieusement.$VELVET
$TUT
