Na verdade, essa pilha de @Dusk tem dois livros contábeis relacionados, mas diferentes: um é o livro de execução do DuskEVM, que apresenta o equivalente ao Ethereum via Ethereum JSON-RPC; o outro é o livro de liquidação do Dusk L1, que apresenta GraphQL / RUES. A DUSK precisa ser lida como o mesmo número em ambos os livros, mas seus relógios, unidades e casas decimais não são iguais.
O DuskEVM é a camada de execução EVM no estilo OP Stack; ele retorna blocos, logs e recibos no formato padrão de EVM. A liquidação final e a disponibilidade de dados são então ancoradas ao DuskDS via batcher, compromissos de estado e ponte. Ou seja, não é um adaptador de “traduzir GraphQL em tempo real para JSON-RPC”; entre as duas camadas, a consistência final é mantida por ponte e compromissos de estado. O ponto realmente importante são os cenários intercamadas: no DuskEVM o inclusion é rápido, mas a liquidação completa e a confirmação da ponte ainda levam alguns passos; nesse intervalo, os estados vistos de cada lado podem temporariamente ser diferentes.
O papel de $DUSK deixa esse risco ainda mais concreto. No lado nativo do L1, usa-se o LUX para representar; 1 DUSK é igual a 10 elevado a 9 LUX. Para compatibilidade com a toolchain do Ethereum, o DuskEVM expõe a DUSK com 18 casas decimais. Ao fazer a ponte, se houver erro na conversão ou no tratamento de precisão, o mesmo valor de uma única transação pode ficar temporariamente desalinhado entre os dois livros. Para uma simples transferência talvez seja apenas um erro de exibição; para liquidação sujeita a regulamentação, pode virar uma janela de operação indevida do tipo “um lado mostra que chegou, enquanto o outro ainda não confirmou de forma final”.
Minha conclusão após ler é: avalie #dusk ; não basta olhar apenas que “é compatível com EVM”. É preciso também verificar as garantias de consistência entre o livro de liquidação do L1 e o livro de execução do EVM. A documentação, no momento, não esclarece suficientemente a prioridade de fontes de dados autoritativas, nem mecanismos de detecção e correção de conflitos — e a DUSK é justamente o número que não pode ser lido errado em nenhum desses dois livros. DYOR.
O DuskEVM é a camada de execução EVM no estilo OP Stack; ele retorna blocos, logs e recibos no formato padrão de EVM. A liquidação final e a disponibilidade de dados são então ancoradas ao DuskDS via batcher, compromissos de estado e ponte. Ou seja, não é um adaptador de “traduzir GraphQL em tempo real para JSON-RPC”; entre as duas camadas, a consistência final é mantida por ponte e compromissos de estado. O ponto realmente importante são os cenários intercamadas: no DuskEVM o inclusion é rápido, mas a liquidação completa e a confirmação da ponte ainda levam alguns passos; nesse intervalo, os estados vistos de cada lado podem temporariamente ser diferentes.
O papel de $DUSK deixa esse risco ainda mais concreto. No lado nativo do L1, usa-se o LUX para representar; 1 DUSK é igual a 10 elevado a 9 LUX. Para compatibilidade com a toolchain do Ethereum, o DuskEVM expõe a DUSK com 18 casas decimais. Ao fazer a ponte, se houver erro na conversão ou no tratamento de precisão, o mesmo valor de uma única transação pode ficar temporariamente desalinhado entre os dois livros. Para uma simples transferência talvez seja apenas um erro de exibição; para liquidação sujeita a regulamentação, pode virar uma janela de operação indevida do tipo “um lado mostra que chegou, enquanto o outro ainda não confirmou de forma final”.
Minha conclusão após ler é: avalie #dusk ; não basta olhar apenas que “é compatível com EVM”. É preciso também verificar as garantias de consistência entre o livro de liquidação do L1 e o livro de execução do EVM. A documentação, no momento, não esclarece suficientemente a prioridade de fontes de dados autoritativas, nem mecanismos de detecção e correção de conflitos — e a DUSK é justamente o número que não pode ser lido errado em nenhum desses dois livros. DYOR.
