#dusk $DUSK @Dusk Ainda não entendi muito bem como posicionar esse negócio de “DuskEVM” no Dusk. Esta semana, dediquei um tempo específico para separá-lo e analisá-lo com atenção.
Em poucas palavras, o DuskEVM é uma camada no ecossistema do Dusk feita para compatibilizar o modelo de desenvolvimento de contratos inteligentes do Ethereum. Para quem está acostumado com a linguagem e as ferramentas do Ethereum, não precisa aprender tudo do zero: é possível implantar a aplicação no Dusk usando o mesmo fluxo. Ele não mantém, por conta própria, um conjunto totalmente independente de livro-razão nem uma lógica final de liquidação. Os dados reais de registro da transação e a confirmação final ficam a cargo da camada de liquidação do nível mais baixo do Dusk. Nesse sentido, o DuskEVM é mais como uma camada acima, especificamente voltada para executar contratos inteligentes.
No começo, eu achei, por suposição, que era uma cadeia independente “no mesmo nível”, com a camada de liquidação embaixo sendo um livro-razão separado, sem dependência uma da outra, e que cada uma rodava por conta própria. Depois, reli algumas vezes as explicações oficiais de arquitetura e percebi que eu havia entendido errado — nesta parte de execução, depois de processar as transações, ainda é preciso empacotar os resultados e enviá-los para a camada de liquidação embaixo, para que aí sim sejam feitos o registro e a confirmação de verdade. Ou seja, há uma relação de “sistema a montante e a jusante”: não é algo paralelo. Eu fiquei preso a esse mal-entendido por bastante tempo, principalmente porque os materiais de divulgação frequentemente apresentam as duas camadas separadamente, o que facilita a impressão de que seriam duas cadeias independentes rodando em paralelo.
Para desenvolvedores, essa relação hierárquica é bem importante — significa que o custo real da aplicação que você implanta no DuskEVM não é apenas o gasto de recursos com a execução de contratos nesta camada. Você também precisa considerar a parte do custo de enviar os dados para a camada de liquidação embaixo. Somar as duas contas é o custo completo. Se você estimar o custo de implantação apenas com base na experiência do Ethereum, é fácil esquecer de contabilizar o que ocorre nessa camada inferior.
Se minha compreensão estiver com algum desvio, sinta-se à vontade para apontar. Eu mesmo só consegui organizar essa lógica nos últimos dias, e não tenho certeza se deixei passar algum detalhe.
Em poucas palavras, o DuskEVM é uma camada no ecossistema do Dusk feita para compatibilizar o modelo de desenvolvimento de contratos inteligentes do Ethereum. Para quem está acostumado com a linguagem e as ferramentas do Ethereum, não precisa aprender tudo do zero: é possível implantar a aplicação no Dusk usando o mesmo fluxo. Ele não mantém, por conta própria, um conjunto totalmente independente de livro-razão nem uma lógica final de liquidação. Os dados reais de registro da transação e a confirmação final ficam a cargo da camada de liquidação do nível mais baixo do Dusk. Nesse sentido, o DuskEVM é mais como uma camada acima, especificamente voltada para executar contratos inteligentes.
No começo, eu achei, por suposição, que era uma cadeia independente “no mesmo nível”, com a camada de liquidação embaixo sendo um livro-razão separado, sem dependência uma da outra, e que cada uma rodava por conta própria. Depois, reli algumas vezes as explicações oficiais de arquitetura e percebi que eu havia entendido errado — nesta parte de execução, depois de processar as transações, ainda é preciso empacotar os resultados e enviá-los para a camada de liquidação embaixo, para que aí sim sejam feitos o registro e a confirmação de verdade. Ou seja, há uma relação de “sistema a montante e a jusante”: não é algo paralelo. Eu fiquei preso a esse mal-entendido por bastante tempo, principalmente porque os materiais de divulgação frequentemente apresentam as duas camadas separadamente, o que facilita a impressão de que seriam duas cadeias independentes rodando em paralelo.
Para desenvolvedores, essa relação hierárquica é bem importante — significa que o custo real da aplicação que você implanta no DuskEVM não é apenas o gasto de recursos com a execução de contratos nesta camada. Você também precisa considerar a parte do custo de enviar os dados para a camada de liquidação embaixo. Somar as duas contas é o custo completo. Se você estimar o custo de implantação apenas com base na experiência do Ethereum, é fácil esquecer de contabilizar o que ocorre nessa camada inferior.
Se minha compreensão estiver com algum desvio, sinta-se à vontade para apontar. Eu mesmo só consegui organizar essa lógica nos últimos dias, e não tenho certeza se deixei passar algum detalhe.