#dusk $DUSK
Nestes dois dias estive a ler a documentação do DuskEVM da @Dusk , e há um detalhe que eu realmente tinha ignorado antes:
Uma transação ser empacotada no DuskEVM não significa que ela já tenha sido concluída.
Na arquitetura atual do Dusk, o DuskEVM e o DuskDS não fazem a mesma coisa.
Os contratos Solidity executam primeiro no DuskEVM; a transação entra no sequencer e é incluída num bloco L2. Depois, o batcher ainda precisa submeter os dados da transação ao DuskDS, e o estado continua a ser confirmado por mecanismos como commitment e fault proof.
No fim, quem fica responsável por settlement e data availability é o DuskDS.
Por isso, a minha compreensão atual do DuskEVM já não é simplesmente a de “Dusk com um EVM”.
Mais precisamente, deveria ser assim:
O DuskEVM cuida da execução, e o DuskDS cuida de saber se isso realmente conta no final.
Isso também explica por que a documentação oficial faz questão de distinguir transaction inclusion de settlement.
Até o fluxo de withdrawal da testnet atual mostra essa lógica de design: primeiro inicia no DuskEVM, depois prova no Dusk L1, e só no fim finaliza; não é porque aparece como sucesso no lado L2 que tudo está realmente encerrado.
Essa diferença talvez não pareça tão atraente para transferências comuns, mas em cenários financeiros, na minha opinião, ela é ainda mais importante.
Se valores mobiliários, fundos e coisas desse tipo realmente forem para a cadeia, no fim o que todos se preocupam não é apenas “se a transação roda rápido”, mas também com uma pergunta mais prática:
Em que camada, afinal, esse estado atinge a finalidade final?
Então, quando eu olhar para o mainnet do DuskEVM a seguir, além de desempenho e compatibilidade com Solidity, quero ainda mais ver como essa cadeia real de execution até o settlement no DuskDS se comporta na prática.
Pelo menos agora, a divisão de responsabilidades na arquitetura eu já entendi.
Nestes dois dias estive a ler a documentação do DuskEVM da @Dusk , e há um detalhe que eu realmente tinha ignorado antes:
Uma transação ser empacotada no DuskEVM não significa que ela já tenha sido concluída.
Na arquitetura atual do Dusk, o DuskEVM e o DuskDS não fazem a mesma coisa.
Os contratos Solidity executam primeiro no DuskEVM; a transação entra no sequencer e é incluída num bloco L2. Depois, o batcher ainda precisa submeter os dados da transação ao DuskDS, e o estado continua a ser confirmado por mecanismos como commitment e fault proof.
No fim, quem fica responsável por settlement e data availability é o DuskDS.
Por isso, a minha compreensão atual do DuskEVM já não é simplesmente a de “Dusk com um EVM”.
Mais precisamente, deveria ser assim:
O DuskEVM cuida da execução, e o DuskDS cuida de saber se isso realmente conta no final.
Isso também explica por que a documentação oficial faz questão de distinguir transaction inclusion de settlement.
Até o fluxo de withdrawal da testnet atual mostra essa lógica de design: primeiro inicia no DuskEVM, depois prova no Dusk L1, e só no fim finaliza; não é porque aparece como sucesso no lado L2 que tudo está realmente encerrado.
Essa diferença talvez não pareça tão atraente para transferências comuns, mas em cenários financeiros, na minha opinião, ela é ainda mais importante.
Se valores mobiliários, fundos e coisas desse tipo realmente forem para a cadeia, no fim o que todos se preocupam não é apenas “se a transação roda rápido”, mas também com uma pergunta mais prática:
Em que camada, afinal, esse estado atinge a finalidade final?
Então, quando eu olhar para o mainnet do DuskEVM a seguir, além de desempenho e compatibilidade com Solidity, quero ainda mais ver como essa cadeia real de execution até o settlement no DuskDS se comporta na prática.
Pelo menos agora, a divisão de responsabilidades na arquitetura eu já entendi.