#dusk $DUSK @Dusk #dusk $DUSK @Dusk_Foundation
A maioria das L2s aluga sua disponibilidade de dados. Blobs do Ethereum, Celestia, alguém.
O DuskEVM não. Leia o ciclo de vida da transação na documentação e ele é: o sequenciador inclui sua transação em um bloco de uma L2, então um empacotador (batcher) publica esses dados da transação no DuskDS, então compromissos de estado e provas de falha ancoram isso de volta no settlement do DuskDS. A mesma cadeia fazendo consenso, settlement e DA para sua própria camada de execução.
Depois, confira a página de atualizações da rede e há uma entrada correspondente: transações de blobs ativadas na mainnet no bloco 2.873.420 em 10 de dezembro de 2025, exigindo Rusk 1.4.1.
Duas coisas seguem disso, e elas puxam em direções opostas.
A boa: nenhum fator de dependência externa no caminho do settlement. Para uma cadeia que argumenta que ativos regulamentados precisam de um único ambiente coerente com uma única garantia de finalidade, terceirizar a DA para uma rede terceira abriria um buraco direto na proposta. Isso é arquiteturalmente consistente com o que eles dizem que estão construindo.
A mais difícil: a demanda por DA e o espaço de bloco da L1 agora são o mesmo recurso. Cada transação do DuskEVM eventualmente custa espaço de bloco no DuskDS. Se o uso do EVM ficar pesado, a pressão nas taxas da L1 e o custo da L2 deixam de ser conversas separadas. Esse é um acoplamento real, e ele corta nos dois sentidos — é também o mecanismo pelo qual a atividade do EVM realmente geraria taxas para validadores da L1, em vez de ficar em uma economia paralela.
A ressalva honesta: o DuskEVM ainda está rotulado como Testnet na própria página inicial da Dusk. Então esse acoplamento foi desenhado, não ainda estressado. A maquinaria de blobs está ativa na mainnet antes da carga para a qual foi construída.
Você preferiria que uma L2 fosse dona da sua DA e compartilhasse o espaço de bloco do seu “pai”, ou alugasse a DA em outro lugar e ficasse barata?
A maioria das L2s aluga sua disponibilidade de dados. Blobs do Ethereum, Celestia, alguém.
O DuskEVM não. Leia o ciclo de vida da transação na documentação e ele é: o sequenciador inclui sua transação em um bloco de uma L2, então um empacotador (batcher) publica esses dados da transação no DuskDS, então compromissos de estado e provas de falha ancoram isso de volta no settlement do DuskDS. A mesma cadeia fazendo consenso, settlement e DA para sua própria camada de execução.
Depois, confira a página de atualizações da rede e há uma entrada correspondente: transações de blobs ativadas na mainnet no bloco 2.873.420 em 10 de dezembro de 2025, exigindo Rusk 1.4.1.
Duas coisas seguem disso, e elas puxam em direções opostas.
A boa: nenhum fator de dependência externa no caminho do settlement. Para uma cadeia que argumenta que ativos regulamentados precisam de um único ambiente coerente com uma única garantia de finalidade, terceirizar a DA para uma rede terceira abriria um buraco direto na proposta. Isso é arquiteturalmente consistente com o que eles dizem que estão construindo.
A mais difícil: a demanda por DA e o espaço de bloco da L1 agora são o mesmo recurso. Cada transação do DuskEVM eventualmente custa espaço de bloco no DuskDS. Se o uso do EVM ficar pesado, a pressão nas taxas da L1 e o custo da L2 deixam de ser conversas separadas. Esse é um acoplamento real, e ele corta nos dois sentidos — é também o mecanismo pelo qual a atividade do EVM realmente geraria taxas para validadores da L1, em vez de ficar em uma economia paralela.
A ressalva honesta: o DuskEVM ainda está rotulado como Testnet na própria página inicial da Dusk. Então esse acoplamento foi desenhado, não ainda estressado. A maquinaria de blobs está ativa na mainnet antes da carga para a qual foi construída.
Você preferiria que uma L2 fosse dona da sua DA e compartilhasse o espaço de bloco do seu “pai”, ou alugasse a DA em outro lugar e ficasse barata?