Abri a pipeline de execução da Dusk esta manhã—e percebi que a maioria das cadeias é apenas uma camada de privacidade sobre uma base EVM construída para transparência. A Dusk reconstruiu a stack de baixo para cima, partindo do circuito.
A DuskVM executa bytecode WASM, não EVM. Contratos são compilados para WASM e passam por um buffer de argumentos de 64KB. Os resultados da execução precisam ser idênticos em todos os nós; caso contrário, a validação de consenso falha. Essa execução determinística é imposta pela camada de protocolo, não assumida.
A pipeline de liquidação executa dois modelos nativos de transações em paralelo—Moonlight para transferências públicas, baseadas em conta, e Phoenix para transferências shielded, no estilo UTXO, com provas ZK. Ambas são liquidadas na mesma cadeia por meio do Contract de Transferência, que aceita ambos os tipos de payload, os direciona para a lógica de verificação e impede double spends. Coordenação de estado em nível de protocolo, não um toggle de interface.
Stack de criptografia: BLS12-381 para assinaturas agregadas e BLS threshold, JubJub para circuitos ZK eficientes, Poseidon para hashing otimizado para circuitos, PLONK para provas reutilizáveis e verificáveis on-chain. Tudo em Rust puro. A Attestation Succinct é finalizada em três rodadas determinísticas—proposta, validação e ratificação—com provedores selecionados aleatoriamente. Sem reorgs. Sem finalidade probabilística. Tempo médio de bloco: ~2 segundos.
O que não é abordado: se a pipeline de execução WASM com privacidade integrada a ZK mantém o throughput sob volumes institucionais de negociação, ou se a sobrecarga dos circuitos vira o próximo gargalo.
Com o que eu fico: a Dusk não fez fork de uma cadeia. Ela criou um ambiente de execução em que privacidade, conformidade e liquidação são o mesmo problema de engenharia—resolvido em nível de circuito antes que a primeira transação fosse liquidada.
@Dusk #DUSK
#dusk $DUSK $WAL $ACE
A DuskVM executa bytecode WASM, não EVM. Contratos são compilados para WASM e passam por um buffer de argumentos de 64KB. Os resultados da execução precisam ser idênticos em todos os nós; caso contrário, a validação de consenso falha. Essa execução determinística é imposta pela camada de protocolo, não assumida.
A pipeline de liquidação executa dois modelos nativos de transações em paralelo—Moonlight para transferências públicas, baseadas em conta, e Phoenix para transferências shielded, no estilo UTXO, com provas ZK. Ambas são liquidadas na mesma cadeia por meio do Contract de Transferência, que aceita ambos os tipos de payload, os direciona para a lógica de verificação e impede double spends. Coordenação de estado em nível de protocolo, não um toggle de interface.
Stack de criptografia: BLS12-381 para assinaturas agregadas e BLS threshold, JubJub para circuitos ZK eficientes, Poseidon para hashing otimizado para circuitos, PLONK para provas reutilizáveis e verificáveis on-chain. Tudo em Rust puro. A Attestation Succinct é finalizada em três rodadas determinísticas—proposta, validação e ratificação—com provedores selecionados aleatoriamente. Sem reorgs. Sem finalidade probabilística. Tempo médio de bloco: ~2 segundos.
O que não é abordado: se a pipeline de execução WASM com privacidade integrada a ZK mantém o throughput sob volumes institucionais de negociação, ou se a sobrecarga dos circuitos vira o próximo gargalo.
Com o que eu fico: a Dusk não fez fork de uma cadeia. Ela criou um ambiente de execução em que privacidade, conformidade e liquidação são o mesmo problema de engenharia—resolvido em nível de circuito antes que a primeira transação fosse liquidada.
@Dusk #DUSK
#dusk $DUSK $WAL $ACE
