Quando eu olhei pela primeira vez para o DuskEVM, a história óbvia era a compatibilidade com a EVM. Desenvolvedores Solidity conseguem trabalhar com ferramentas familiares, o que reduz o atrito para construir em uma nova rede.
Mas a parte mais interessante, para mim, começa depois que a transação sai da EVM.
O DuskEVM não opera de forma isolada. O seu ambiente de execução fica acima do DuskDS, a camada subjacente responsável pela liquidação e pela infraestrutura de rede. Essa separação muda a pergunta que eu acho que deveríamos estar fazendo.
Em vez de perguntar apenas: “Quão facilmente desenvolvedores podem implantar aplicações estilo Ethereum no Dusk?”, estou mais interessado no que essas aplicações herdam da arquitetura por baixo delas.
Execução familiar é útil. Mas execução familiar conectada a um modelo de liquidação diferente pode criar um espaço de design diferente.
Isso se torna ainda mais interessante quando a privacidade entra em cena. A Dusk está avançando para fluxos de EVM confidenciais por meio do Hedger, combinando tecnologias como criptografia homomórfica e provas de conhecimento zero. Assim, a experiência do desenvolvedor pode permanecer reconhecível, enquanto as premissas sobre visibilidade das transações e liquidação não necessariamente são as mesmas de um ambiente típico de EVM pública.
É aí que eu acho que a história do DuskEVM fica mais profunda.
O valor não é simplesmente levar o Solidity para outra cadeia. É, potencialmente, dar a aplicações familiares acesso a uma infraestrutura projetada especificamente para atividade financeira regulada, na qual confidencialidade, verificabilidade e liquidação determinística importam.
A premissa que eu questionaria é que a compatibilidade com a EVM seja principalmente um atalho de adoção.
Talvez seja mais útil como uma ponte: execução familiar na interface, infraestrutura financeira diferente por baixo.
E o teste real para @Dusk won não será se desenvolvedores conseguem implantar contratos.
Será o que eles escolhem construir quando percebem o que está sob aqueles contratos.
@Dusk_Foundation $DUSK #dusk
Mas a parte mais interessante, para mim, começa depois que a transação sai da EVM.
O DuskEVM não opera de forma isolada. O seu ambiente de execução fica acima do DuskDS, a camada subjacente responsável pela liquidação e pela infraestrutura de rede. Essa separação muda a pergunta que eu acho que deveríamos estar fazendo.
Em vez de perguntar apenas: “Quão facilmente desenvolvedores podem implantar aplicações estilo Ethereum no Dusk?”, estou mais interessado no que essas aplicações herdam da arquitetura por baixo delas.
Execução familiar é útil. Mas execução familiar conectada a um modelo de liquidação diferente pode criar um espaço de design diferente.
Isso se torna ainda mais interessante quando a privacidade entra em cena. A Dusk está avançando para fluxos de EVM confidenciais por meio do Hedger, combinando tecnologias como criptografia homomórfica e provas de conhecimento zero. Assim, a experiência do desenvolvedor pode permanecer reconhecível, enquanto as premissas sobre visibilidade das transações e liquidação não necessariamente são as mesmas de um ambiente típico de EVM pública.
É aí que eu acho que a história do DuskEVM fica mais profunda.
O valor não é simplesmente levar o Solidity para outra cadeia. É, potencialmente, dar a aplicações familiares acesso a uma infraestrutura projetada especificamente para atividade financeira regulada, na qual confidencialidade, verificabilidade e liquidação determinística importam.
A premissa que eu questionaria é que a compatibilidade com a EVM seja principalmente um atalho de adoção.
Talvez seja mais útil como uma ponte: execução familiar na interface, infraestrutura financeira diferente por baixo.
E o teste real para @Dusk won não será se desenvolvedores conseguem implantar contratos.
Será o que eles escolhem construir quando percebem o que está sob aqueles contratos.
@Dusk_Foundation $DUSK #dusk