A coisa que me prendeu enquanto eu investigava o DuskEVM não foi a parte do EVM em si. Foi onde a execução realmente acontece.

Eu estava analisando a @DuskNetwork; a documentação atual mostra que o DuskEVM usa o chain ID 744, com DUSK como o token nativo de gás, enquanto o DuskDS cuida do settlement e da disponibilidade de dados. Essa separação parece bem limpa no papel, mas mudou a forma como eu encarei a rede: o ambiente EVM não está substituindo a camada base do Dusk; ele está em cima dela.

O que me fez pausar foi a recente atividade de governança do OpenDusk.

O voto de agosto é sobre se as recompensas de blocos queimadas devem ir para um tesouro comunitário, enquanto o DuskEVM está sendo posicionado como a camada de aplicação. Então existe um contraste interessante aqui: governança e settlement continuam ligados ao DuskDS, enquanto os desenvolvedores recebem o ambiente familiar de Solidity/EVM acima dele.

Eu originalmente achava que EVM no Dusk significava, principalmente, implantação mais fácil. Depois de traçar a arquitetura, estou menos certo de que essa seja a parte mais importante.

A pergunta real, para mim, é se desenvolvedores realmente usam essa separação na prática, ou se o DuskEVM continua sendo, em grande parte, uma camada de compatibilidade enquanto a atividade mais profunda permanece no DuskDS…

@Dusk $DUSK #dusk