Houve uma noite em que abri a documentação do DuskEVM e do DuskVM lado a lado, com um arquivo de notas cheio de setas ao lado delas, e então executei eu mesmo um teste de simulação: com o mesmo fluxo de Smart Contract, como a minha mente pensa sobre isso sob EVM Compatibility e, ao passar para a Native Execution, quantas vezes o raciocínio precisa mudar...
Eu dividi o fluxo em 10 etapas: 6 passos familiares de Solidity, Gas e Account Model; as outras 4 etapas tocam Rust/WASM, Transaction Model, Ledger Logic, State Transition, Privacy e Zero-Knowledge Proof.
6/10 = 60% parece pouco, mas os restantes 40% é onde o tempo realmente foi.
porque a sintaxe é apenas a camada externa.
a parte mais difícil é o modelo mental.
no EVM, eu penso em termos de chamada de contrato, estado da conta e consumo de gas; ao ir para o DuskVM, as perguntas mudam completamente: como o estado é representado, onde a Privacy se encaixa e em que momento o Zero-Knowledge Proof entra na State Transition?
para ser sincero, essa parte me fez gostar mais do Dusk... mas também me deixou mais cauteloso.
tentei mais 8 tarefas para um app com Protocol Assets: 5 tarefas em EVM vieram quase por reflexo, enquanto 3 tarefas nativas me forçaram a parar e desenhar a dependência e o fluxo de execução.
3/8 = 37,5% das tarefas, mas a troca de Context Switching ainda consumiu bastante esforço.
isso não é um benchmark oficial, apenas o jeito que eu uso para medir a carga cognitiva quando uma equipe vive em dois Execution Environments.
EVM Compatibility torna o onboarding mais rápido.
mas se Privacy, Zero-Knowledge e Protocol Assets ficam profundamente dentro da Native Execution, o desenvolvedor ainda precisa passar por duas pilhas, duas Ledger Logic, dois Transaction Model.
não tenho medo de arquitetura em camadas.
para mim, uma boa arquitetura deve fazer com que o desenvolvedor compreenda corretamente State, Execution Semantics e Security Assumption antes que o código rode.
o que vocês acham: a maior vantagem do Dusk está no ponto de entrada do EVM... ou na capacidade de fazer o desenvolvedor dominar de verdade a camada nativa por trás dele?
#dusk $DUSK @Dusk
Eu dividi o fluxo em 10 etapas: 6 passos familiares de Solidity, Gas e Account Model; as outras 4 etapas tocam Rust/WASM, Transaction Model, Ledger Logic, State Transition, Privacy e Zero-Knowledge Proof.
6/10 = 60% parece pouco, mas os restantes 40% é onde o tempo realmente foi.
porque a sintaxe é apenas a camada externa.
a parte mais difícil é o modelo mental.
no EVM, eu penso em termos de chamada de contrato, estado da conta e consumo de gas; ao ir para o DuskVM, as perguntas mudam completamente: como o estado é representado, onde a Privacy se encaixa e em que momento o Zero-Knowledge Proof entra na State Transition?
para ser sincero, essa parte me fez gostar mais do Dusk... mas também me deixou mais cauteloso.
tentei mais 8 tarefas para um app com Protocol Assets: 5 tarefas em EVM vieram quase por reflexo, enquanto 3 tarefas nativas me forçaram a parar e desenhar a dependência e o fluxo de execução.
3/8 = 37,5% das tarefas, mas a troca de Context Switching ainda consumiu bastante esforço.
isso não é um benchmark oficial, apenas o jeito que eu uso para medir a carga cognitiva quando uma equipe vive em dois Execution Environments.
EVM Compatibility torna o onboarding mais rápido.
mas se Privacy, Zero-Knowledge e Protocol Assets ficam profundamente dentro da Native Execution, o desenvolvedor ainda precisa passar por duas pilhas, duas Ledger Logic, dois Transaction Model.
não tenho medo de arquitetura em camadas.
para mim, uma boa arquitetura deve fazer com que o desenvolvedor compreenda corretamente State, Execution Semantics e Security Assumption antes que o código rode.
o que vocês acham: a maior vantagem do Dusk está no ponto de entrada do EVM... ou na capacidade de fazer o desenvolvedor dominar de verdade a camada nativa por trás dele?
#dusk $DUSK @Dusk