#dusk $DUSK No update de desenvolvimento oficial do Dusk em “August 4–11, 2026”, vi um meter ed BlobCall e minha mão já foi direto para a calculadora: o DUSK adicionou mais uma fonte de receita de dados? Quando vi a próxima linha com “disabled”, minha mão voltou para trás.
Blob pode ser entendido como um grande pacote de dados de transações que a camada superior entrega à camada inferior do Dusk. Para o DuskEVM fazer com que o DuskDS salve e comprove esses dados, esse tipo de canal é indispensável.
No código aberto, o corpo de dados de cada Blob tem cerca de 128KB. Os nós precisam receber, propagar e verificar provas KZG, e ainda garantir que os dados estejam disponíveis a qualquer momento durante o período de verificação de segurança; depois, os dados completos podem ser removidos, e na cadeia fica apenas um “recibo” único, imutável e impossível de falsificar.
Por isso, acho que o Dusk no futuro não vai vender um disco rígido permanente, e sim um serviço de armazenamento de dados verificável.
A engenharia mais recente do Dusk já consegue bloquear dados ruins antes de alterar o livro-razão, e também consegue cobrar pelo BlobCall de acordo com a quantidade de trabalho. Mas a chave seletora não foi ligada; como resultado, a aplicação ainda não chega a essa via de cobrança. Em resumo: o código calcula o preço—isso só mostra que o sistema de cobrança está pronto, não que a receita já ocorreu.
Eu pretendia registrar como um fator positivo; mas depois de desmontar tudo com calma, fiquei ainda mais cauteloso. Se o preço for definido baixo, os nós vão cobrir a largura de banda, CPU e armazenamento para as aplicações de nível superior; se o preço for definido alto demais, as aplicações vão comprimir e reduzir lançamentos freneticamente—o custo por cobrança fica maior, mas o número de cobranças pode até diminuir.
Agora, apenas nesse aspecto, vejo a receita de dados do DUSK como algo bem próximo de: bytes pagos por dia × custo por byte.
Isso não tem relação direta com quantos ativos o DuskEVM colocou. Mesmo que os ativos sejam maiores, se não houver publicação contínua de dados, essa receita ainda é bem fraca.
Em termos de operação, eu vou esperar aparecerem de verdade: a altura de ativação, os primeiros Blob bem-sucedidos, os repetidores (quem publica de novo) e a parcela das taxas de dados no total da taxa do bloco.
É como tabela de preços de um restaurante: pendurar na parede não é negócio. Só conta se alguém estiver disposto a pedir e pagar. Depois que eu desmontei, eu também entendi: isso pode ser considerado um valor de transbordamento da tecnologia, certo? Já adicionei silenciosamente essa análise à lista de indicadores de observação de longo prazo para a valoração do token.
@Dusk
$BTC
Blob pode ser entendido como um grande pacote de dados de transações que a camada superior entrega à camada inferior do Dusk. Para o DuskEVM fazer com que o DuskDS salve e comprove esses dados, esse tipo de canal é indispensável.
No código aberto, o corpo de dados de cada Blob tem cerca de 128KB. Os nós precisam receber, propagar e verificar provas KZG, e ainda garantir que os dados estejam disponíveis a qualquer momento durante o período de verificação de segurança; depois, os dados completos podem ser removidos, e na cadeia fica apenas um “recibo” único, imutável e impossível de falsificar.
Por isso, acho que o Dusk no futuro não vai vender um disco rígido permanente, e sim um serviço de armazenamento de dados verificável.
A engenharia mais recente do Dusk já consegue bloquear dados ruins antes de alterar o livro-razão, e também consegue cobrar pelo BlobCall de acordo com a quantidade de trabalho. Mas a chave seletora não foi ligada; como resultado, a aplicação ainda não chega a essa via de cobrança. Em resumo: o código calcula o preço—isso só mostra que o sistema de cobrança está pronto, não que a receita já ocorreu.
Eu pretendia registrar como um fator positivo; mas depois de desmontar tudo com calma, fiquei ainda mais cauteloso. Se o preço for definido baixo, os nós vão cobrir a largura de banda, CPU e armazenamento para as aplicações de nível superior; se o preço for definido alto demais, as aplicações vão comprimir e reduzir lançamentos freneticamente—o custo por cobrança fica maior, mas o número de cobranças pode até diminuir.
Agora, apenas nesse aspecto, vejo a receita de dados do DUSK como algo bem próximo de: bytes pagos por dia × custo por byte.
Isso não tem relação direta com quantos ativos o DuskEVM colocou. Mesmo que os ativos sejam maiores, se não houver publicação contínua de dados, essa receita ainda é bem fraca.
Em termos de operação, eu vou esperar aparecerem de verdade: a altura de ativação, os primeiros Blob bem-sucedidos, os repetidores (quem publica de novo) e a parcela das taxas de dados no total da taxa do bloco.
É como tabela de preços de um restaurante: pendurar na parede não é negócio. Só conta se alguém estiver disposto a pedir e pagar. Depois que eu desmontei, eu também entendi: isso pode ser considerado um valor de transbordamento da tecnologia, certo? Já adicionei silenciosamente essa análise à lista de indicadores de observação de longo prazo para a valoração do token.
@Dusk
$BTC