#dusk $DUSK @Dusk Deixe-me verificar as alegações técnicas antes de finalizar isso.
Li a whitepaper da Dusk num fim de tarde tranquilo, curioso para saber o que o XSC realmente significava além de um nome. Acabei preso na seção de transações. A Dusk executa dois modelos em uma única cadeia: Moonlight, um sistema de contas transparente, e Phoenix, um modelo UTXO protegido que usa provas de conhecimento zero.
O que eu não esperava: o Moonlight não fazia parte do design original. A Dusk o adicionou depois de perceber que a integração com exchanges precisava de um modelo de transação pública, já que a anonimidade total criava risco de delisting sob as regras da UE. É uma razão prática, não de marketing, e isso muda como eu leio todo o sistema.
Os dois modelos não são isolados. Um Transfer Contract permite que os usuários convertam entre notas do Phoenix e saldos do Moonlight de forma atômica, e o Phoenix suporta chaves de visualização para transações específicas poderem ser divulgadas seletivamente para auditoria.
Cenário concreto: uma pequena mesa de trading paga salários e reporta movimentos do tesouro via Moonlight, totalmente visível, e depois executa as operações reais de posições via Phoenix, ocultas dos concorrentes, com uma chave de visualização em posse de um regulador, se necessário. Sem ponte, sem segunda cadeia, mesma camada de liquidação.
Esse é o argumento. O que eu não consigo avaliar a partir de um documento é a fricção, como a conversão se comporta sob carga real e se "sem costura" se mantém quando ambos os modelos competem pelo mesmo espaço de blocos.
Alguém já rodou conversões do Moonlight para o Phoenix na testnet da Dusk? Pareceu atômico e rápido, ou houve atraso que a documentação não menciona? $SOL $LAB
Li a whitepaper da Dusk num fim de tarde tranquilo, curioso para saber o que o XSC realmente significava além de um nome. Acabei preso na seção de transações. A Dusk executa dois modelos em uma única cadeia: Moonlight, um sistema de contas transparente, e Phoenix, um modelo UTXO protegido que usa provas de conhecimento zero.
O que eu não esperava: o Moonlight não fazia parte do design original. A Dusk o adicionou depois de perceber que a integração com exchanges precisava de um modelo de transação pública, já que a anonimidade total criava risco de delisting sob as regras da UE. É uma razão prática, não de marketing, e isso muda como eu leio todo o sistema.
Os dois modelos não são isolados. Um Transfer Contract permite que os usuários convertam entre notas do Phoenix e saldos do Moonlight de forma atômica, e o Phoenix suporta chaves de visualização para transações específicas poderem ser divulgadas seletivamente para auditoria.
Cenário concreto: uma pequena mesa de trading paga salários e reporta movimentos do tesouro via Moonlight, totalmente visível, e depois executa as operações reais de posições via Phoenix, ocultas dos concorrentes, com uma chave de visualização em posse de um regulador, se necessário. Sem ponte, sem segunda cadeia, mesma camada de liquidação.
Esse é o argumento. O que eu não consigo avaliar a partir de um documento é a fricção, como a conversão se comporta sob carga real e se "sem costura" se mantém quando ambos os modelos competem pelo mesmo espaço de blocos.
Alguém já rodou conversões do Moonlight para o Phoenix na testnet da Dusk? Pareceu atômico e rápido, ou houve atraso que a documentação não menciona? $SOL $LAB
🔒 Stays seamless at real scale
100%
⚖️ Regulatory trust
0%
🏦 TradFi adoption
0%
🤷 Too early to say
0%
3 Votos • Votação encerrada