@Dusk queima o dashboard contra uma tarde plana de volume de negociação. Eu assumi que o total da queima era um sinal limpo de oferta diminuindo, o tipo de número que você aponta e segue em frente. Mas quando eu quebrei por bloco, a queima não ficou distribuída de forma alguma.

Investigando mais a fundo, descobri que algumas poucas chamadas de contratos responderam pela maior parte da queima daquele dia, não um uso amplo da rede. Isso me levou a observar como #dusk estrutura suas transações, onde entradas, saídas e metadados viajam juntos como um único objeto validado. A queima não era ruído aleatório: era um resultado direto de caminhos de execução específicos, concentrado em vez de distribuído.

Foi quando eu separei duas coisas que eu vinha tratando como uma só: redução de oferta e distribuição de demanda. Um número de oferta decrescente me diz quantos tokens ainda estão em circulação. Isso não diz nada sobre quantos participantes ou aplicações distintos geraram essa atividade. Ao misturar as duas, a história da deflação pareceu mais forte do que o uso subjacente realmente sustenta.
$DUSK
O que eu ainda não consigo resolver é como isso escala. Se contas ativas ou chamadas de contratos multiplicam várias vezes, eu não sei qual variável se move primeiro: gás por transação, profundidade do mempool ou tempo de inclusão no DuskEVM. O formato da transação que torna a validação explícita também significa mais estado para carregar, e eu ainda não vi como isso se comporta sob pressão real.

Doravante, estou observando a queima por unidade apostada em relação às recompensas dos provedores ativos, a densidade de taxas por epoch e se as fontes de queima se diversificam entre carteiras em vez de se agruparem. Atividade recorrente de endereços repetidos me diria mais do que qualquer total de um único dia alguma vez poderia.

Ainda não sei se uma estrutura de transação tão explícita se torna uma vantagem sob carga ou um custo crescente que a rede absorve silenciosamente.$VELVET
$TUT