#dusk $DUSK @Dusk
Voltei à documentação do DuskEVM depois de ver o resultado mais recente do teste de carga e percebi que havia feito uma suposição simples: um bloco rápido da EVM significava que o DuskDS precisava executar as mesmas transações novamente.
O fluxo documentado é diferente. Uma transação vai para o sequenciador do DuskEVM, entra em um bloco L2 e o operador do batcher publica seus dados no DuskDS. Depois disso, os compromissos de estado e as provas de falha conectam o estado resultante ao settlement do DuskDS. No teste reportado, cerca de 10.000 transações em um único bloco do DuskEVM de dois segundos produziram oito blobs, divididos em duas transações do DuskDS, enquanto o DuskDS continuou processando sua carga de trabalho nativa.
Isso me fez olhar para isso de outra forma.
Minha interpretação: o resultado importante não é apenas a contagem de transações. É que a execução da EVM e o settlement do DuskDS lidaram com trabalho misto por meio de modelos de estado separados, sem o exemplo mostrar um trabalho bloqueando o outro.
Minha incerteza é o que acontece fora do caso “limpo”. Com demanda mista sustentada, quais são os limites de pior caso entre a inclusão na EVM, a publicação de dados e o settlement do DuskDS? Se o sequenciador ou o batcher travarem, quem pode iniciar a recuperação e o que impede que essa autoridade reordene ou atrase transações financeiras pendentes?
Quero observar isso na prática.
Voltei à documentação do DuskEVM depois de ver o resultado mais recente do teste de carga e percebi que havia feito uma suposição simples: um bloco rápido da EVM significava que o DuskDS precisava executar as mesmas transações novamente.
O fluxo documentado é diferente. Uma transação vai para o sequenciador do DuskEVM, entra em um bloco L2 e o operador do batcher publica seus dados no DuskDS. Depois disso, os compromissos de estado e as provas de falha conectam o estado resultante ao settlement do DuskDS. No teste reportado, cerca de 10.000 transações em um único bloco do DuskEVM de dois segundos produziram oito blobs, divididos em duas transações do DuskDS, enquanto o DuskDS continuou processando sua carga de trabalho nativa.
Isso me fez olhar para isso de outra forma.
Minha interpretação: o resultado importante não é apenas a contagem de transações. É que a execução da EVM e o settlement do DuskDS lidaram com trabalho misto por meio de modelos de estado separados, sem o exemplo mostrar um trabalho bloqueando o outro.
Minha incerteza é o que acontece fora do caso “limpo”. Com demanda mista sustentada, quais são os limites de pior caso entre a inclusão na EVM, a publicação de dados e o settlement do DuskDS? Se o sequenciador ou o batcher travarem, quem pode iniciar a recuperação e o que impede que essa autoridade reordene ou atrase transações financeiras pendentes?
Quero observar isso na prática.
