#dusk $DUSK @Dusk Leia o White Paper do Dusk e notei um detalhe fácil de passar despercebido: as descrições de contratos usam tempos verbais diferentes.
Na seção 6.2, ao descrever os Genesis, Transfer e Stake Contracts, a maior parte do texto está formulada principalmente para afirmar as funções que eles já executam atualmente: transferências, dedução de Gas, staking etc. Esses são componentes de infraestrutura necessários para a operação da rede Dusk.
Já a seção 6.3, ao apresentar o Zedger e o Citadel, traz expressões claramente mais orientadas para o futuro, como “designed to be deployed” e “will allow”.
Apenas pelos tempos verbais, claro, não dá para provar que determinada funcionalidade “ainda não foi implementada”. Mas, como um sinal em um documento técnico, isso pelo menos nos lembra que: o desenho da arquitetura no white paper, os protocolos que já foram implantados e as capacidades dos produtos que hoje já podem ser usados na prática não são conceitos equivalentes.
Agora, ao observar o site do Dusk, o status dos diferentes produtos já foi marcado como Live, Building e Testnet. Isso, na verdade, nos fornece um referencial ainda mais concreto: ao discutir uma capacidade, também deveríamos distinguir se ela foi apenas desenhada, se já foi implantada, ou se já pode ser verificada e usada de maneira real?
Hoje, as discussões do Dusk sobre finanças em cadeias reguladas também vêm se concentrando cada vez mais em processos completos, como admissão de investidores, transferências controladas, divulgação de privacidade e liquidação.
Então a pergunta fica mais específica:
Em qual etapa — entre “designado”, “implantado” e “uso verificável” — se encontra atualmente cada uma dessas capacidades: Zedger, XSC e Citadel?
Se o objetivo do Dusk é atender a um mercado financeiro real e regulado, quais são os pontos-chave que, neste caminho do desenho no white paper até o uso no mercado real, mais precisam de validação externa?#dusk $DUSK @Dusk
Na seção 6.2, ao descrever os Genesis, Transfer e Stake Contracts, a maior parte do texto está formulada principalmente para afirmar as funções que eles já executam atualmente: transferências, dedução de Gas, staking etc. Esses são componentes de infraestrutura necessários para a operação da rede Dusk.
Já a seção 6.3, ao apresentar o Zedger e o Citadel, traz expressões claramente mais orientadas para o futuro, como “designed to be deployed” e “will allow”.
Apenas pelos tempos verbais, claro, não dá para provar que determinada funcionalidade “ainda não foi implementada”. Mas, como um sinal em um documento técnico, isso pelo menos nos lembra que: o desenho da arquitetura no white paper, os protocolos que já foram implantados e as capacidades dos produtos que hoje já podem ser usados na prática não são conceitos equivalentes.
Agora, ao observar o site do Dusk, o status dos diferentes produtos já foi marcado como Live, Building e Testnet. Isso, na verdade, nos fornece um referencial ainda mais concreto: ao discutir uma capacidade, também deveríamos distinguir se ela foi apenas desenhada, se já foi implantada, ou se já pode ser verificada e usada de maneira real?
Hoje, as discussões do Dusk sobre finanças em cadeias reguladas também vêm se concentrando cada vez mais em processos completos, como admissão de investidores, transferências controladas, divulgação de privacidade e liquidação.
Então a pergunta fica mais específica:
Em qual etapa — entre “designado”, “implantado” e “uso verificável” — se encontra atualmente cada uma dessas capacidades: Zedger, XSC e Citadel?
Se o objetivo do Dusk é atender a um mercado financeiro real e regulado, quais são os pontos-chave que, neste caminho do desenho no white paper até o uso no mercado real, mais precisam de validação externa?#dusk $DUSK @Dusk
