#dusk $DUSK Hoje eu tentei explicar a arquitetura técnica do Dusk usando “linguagem de gente”, evitando ao máximo aquele monte de termos profissionais. Vamos ver se dá para fazer amigos que não mexem com tecnologia entenderem pelo menos uma parte.
Primeiro, a conclusão: @Dusk o sistema inteiro, em essência, é uma estrutura de “dois andares”. Um andar cuida da privacidade; o outro cuida da conformidade (compliance). Cada um faz sua parte. $AKE
Primeiro andar: Phoenix, cuida da privacidade.
Ele se baseia na arquitetura UTXO (você pode entender de forma simples como “uma cédula de cada vez, cada quantia é independente”, em vez de “uma conta única geral”) e coloca provas de conhecimento zero diretamente na camada de transações. Na hora de transferir, informações como seu endereço e o valor ficam criptografadas na cadeia: quem varre o blockchain não consegue ver o texto em claro, mas a rede ainda consegue verificar que a transação é válida (sem gasto duplo, sem estourar saldo). Isso resolve o problema antigo de “ter privacidade, mas sem perder verificabilidade”.
Segundo andar: Zedger, cuida da conformidade.
Se o Phoenix é “esconder os detalhes”, então o Zedger é “seguir as regras”. Ele é uma camada feita especificamente para tokens do tipo “ativos/valores mobiliários” (securities). Nele, as regras de compliance são escritas na lógica da própria blockchain. Por exemplo: se um token de securities define que nenhum detentor pode ter mais de 5% do total, qualquer transferência acima do limite é rejeitada diretamente na cadeia, sem precisar depender de verificação humana fora da cadeia para “tapar o buraco”. Limite de holdings, listas de permissões (whitelist) e período de bloqueio — essas restrições comuns do sistema financeiro tradicional — tudo pode ser automatizado pelo Zedger.
Abaixo disso, a base: DuskDS + DuskEVM + DuskVM.$SPCXB
DuskDS é a camada de consenso, responsável por garantir liquidação determinística: quando uma transação é colocada na blockchain, ela vira estado final. Então não fica acontecendo aquele tipo de reorg ocasional como em redes PoW.
DuskEVM é compatível com Solidity, permitindo que desenvolvedores do ecossistema Ethereum migrem com baixo custo.
Já o DuskVM mantém a capacidade nativa de computação com privacidade, para cenários que precisam de uma personalização maior.
O pulo do gato desse desenho é que ele não trata “privacidade” e “conformidade” como coisas em conflito. Em vez disso, ele separa as duas necessidades por camadas: cada uma é resolvida do jeito mais adequado e depois combinadas. É também por isso que o Dusk consegue mirar em RWA e em finanças reguladas: porque a pilha técnica foi pensada desde o início para esse cenário, não é algo “encaixado à força”.
Com a lógica da base esclarecida, ao olhar o posicionamento de mercado e os parceiros (AFM, a galera de exchanges NPE etc.), você entende que a linha toda faz sentido — não é uma história montada de pedaços.
#dusk @Dusk
Primeiro, a conclusão: @Dusk o sistema inteiro, em essência, é uma estrutura de “dois andares”. Um andar cuida da privacidade; o outro cuida da conformidade (compliance). Cada um faz sua parte. $AKE
Primeiro andar: Phoenix, cuida da privacidade.
Ele se baseia na arquitetura UTXO (você pode entender de forma simples como “uma cédula de cada vez, cada quantia é independente”, em vez de “uma conta única geral”) e coloca provas de conhecimento zero diretamente na camada de transações. Na hora de transferir, informações como seu endereço e o valor ficam criptografadas na cadeia: quem varre o blockchain não consegue ver o texto em claro, mas a rede ainda consegue verificar que a transação é válida (sem gasto duplo, sem estourar saldo). Isso resolve o problema antigo de “ter privacidade, mas sem perder verificabilidade”.
Segundo andar: Zedger, cuida da conformidade.
Se o Phoenix é “esconder os detalhes”, então o Zedger é “seguir as regras”. Ele é uma camada feita especificamente para tokens do tipo “ativos/valores mobiliários” (securities). Nele, as regras de compliance são escritas na lógica da própria blockchain. Por exemplo: se um token de securities define que nenhum detentor pode ter mais de 5% do total, qualquer transferência acima do limite é rejeitada diretamente na cadeia, sem precisar depender de verificação humana fora da cadeia para “tapar o buraco”. Limite de holdings, listas de permissões (whitelist) e período de bloqueio — essas restrições comuns do sistema financeiro tradicional — tudo pode ser automatizado pelo Zedger.
Abaixo disso, a base: DuskDS + DuskEVM + DuskVM.$SPCXB
DuskDS é a camada de consenso, responsável por garantir liquidação determinística: quando uma transação é colocada na blockchain, ela vira estado final. Então não fica acontecendo aquele tipo de reorg ocasional como em redes PoW.
DuskEVM é compatível com Solidity, permitindo que desenvolvedores do ecossistema Ethereum migrem com baixo custo.
Já o DuskVM mantém a capacidade nativa de computação com privacidade, para cenários que precisam de uma personalização maior.
O pulo do gato desse desenho é que ele não trata “privacidade” e “conformidade” como coisas em conflito. Em vez disso, ele separa as duas necessidades por camadas: cada uma é resolvida do jeito mais adequado e depois combinadas. É também por isso que o Dusk consegue mirar em RWA e em finanças reguladas: porque a pilha técnica foi pensada desde o início para esse cenário, não é algo “encaixado à força”.
Com a lógica da base esclarecida, ao olhar o posicionamento de mercado e os parceiros (AFM, a galera de exchanges NPE etc.), você entende que a linha toda faz sentido — não é uma história montada de pedaços.
#dusk @Dusk
ZK证明到底是什么原理
0%
UTXO和账户模型哪个好
100%
兼容EVM有多重要
0%
1 Votos • Votação encerrada