Neste texto, não vou discutir o mercado, nem a popularidade da narrativa, e muito menos se 'o futuro vai explodir'. Vou adotar uma perspectiva que se alinha mais com a essência da Dusk Foundation e que é mais difícil de enganar: me colocar como alguém que vai trabalhar no Dusk. Não sou um espectador, sou alguém que vai lançar um produto.

Porque a rota do Dusk, repetir 'conformidade com a privacidade' cem vezes não é tão eficaz quanto uma pergunta direta:

Se eu realmente quisesse criar um aplicativo relacionado a um ativo regulamentado hoje, será que o Dusk pode me fornecer um conjunto de capacidades básicas suficientemente claras e controláveis, para que eu me sinta seguro em colocar usuários reais e ativos reais?

Não estou escrevendo um tutorial, estou escrevendo "como eu aceitaria". As duas palavras podem parecer um pouco frias, mas ativos regulamentados devem ser frios. O barulho é para os negociantes, a responsabilidade é para os construtores. Projetos como o Dusk precisam transformar essas coisas frias em interfaces utilizáveis para chegar ao final.

Dividi o que preciso em cinco classes de interface. Cada classe está fortemente relacionada à linha principal do Dusk, e cada classe tem uma razão real do tipo "se faltar, haverá problemas". A vantagem de escrever assim é: não repetirá as formas que você já escreveu antes e pode pressionar a relevância a um nível muito alto.

Primeira classe de interface: interface de qualificação

O que eu preciso não é "quem você é", mas sim "se você atende às condições".

Primeiro, admito uma coisa, eu costumava entender conformidade como KYC. Depois percebi que KYC é apenas a camada mais externa da conformidade; o verdadeiro problema é o estado de qualificação em si. Ativos regulamentados não são para qualquer um participar, eles exigirão condições como região, tipo de sujeito, nível de risco e adequação do investidor. Essas condições no mundo real não são para complicar as pessoas, mas para reduzir disputas e responsabilidades.

Portanto, se eu quiser criar um aplicativo no Dusk, a primeira coisa que perguntarei é:

O Dusk pode me permitir verificar o estado de qualificação de uma pessoa na blockchain, em vez de jogar a qualificação para aprovação fora da blockchain e, em seguida, inserir um endereço de lista branca?

O conjunto de lista branca pode funcionar a curto prazo, mas eu não me atrevo a usá-lo a longo prazo. A razão é muito real:

Uma vez que surja uma disputa, você deve provar qual foi a base para a avaliação da qualificação na época, em que ponto a avaliação ocorreu, se a base foi alterada, e se a lógica de avaliação teve alteração de versão. A lista branca fora da blockchain acabará se tornando "confiar em um banco de dados", o que é muito frágil em ativos regulamentados.

Se o Dusk realmente seguir a rota que declara, ele deve transformar a qualificação em um "estado comprovável". Eu não preciso saber os detalhes da sua identidade real, mas posso verificar se você atende às condições. Mais importante, esse processo de verificação deve ser reproduzível, não dependendo de capturas de tela do atendimento ao cliente ou explicações manuais.

Aqui estou até disposto a ser um pouco exigente: se a interface de qualificação for apenas "podemos fazer isso", para mim é como não ter feito nada. Deve ser possível ser reproduzida por terceiros de acordo com o processo.

Segunda classe de interface: interface de regras de ativos

Ativo não é token, ativo é um conjunto de regras

Muitos produtos em blockchain tratam ativos como um token transferível, é simples assim. Mas ativos regulamentados não são assim. O verdadeiro problema não está na emissão, mas nas regras: período de bloqueio, restrições de transferência, restrições a sujeitos específicos, condições de acionamento para divulgação de informações, janelas de resgate, mecanismo de suspensão de negociação. Se você remover essas regras, o que está na blockchain pode ainda circular, mas não será mais uma representação legal daquele ativo no mundo real.

Portanto, preciso que o Dusk me forneça uma segunda classe de interface, onde as regras dos ativos possam ser expressas e executadas. Não é "prometemos cumprir", mas sim que o nível do contrato pode impedir transferências irregulares, liberar quando as condições forem atendidas e entrar na próxima etapa quando as condições de acionamento aparecerem.

Para ser mais direto: eu preciso que o sistema me ajude a criar vilões. Porque no mundo real, se você deixar os usuários cumprirem as regras sozinhos, você acabará levando a culpa.

Essa é também a razão pela qual dou tanta importância à tendência de "conformidade em nível de protocolo" do Dusk. Quem trabalha com aplicativos de ativos regulamentados não tem medo apenas de que os usuários o critiquem por ser complicado, mas tem medo de que, se algo der errado, você não consiga explicar por que permitiu aquela transação. O que você precisa é de um sistema que possa codificar "permitir e não permitir" nas regras. Se o Dusk não conseguir fazer isso uma capacidade padrão, então não é adequado para assumir o ciclo de vida de ativos regulamentados.

Terceira classe de interface: interface de divulgação

Privacidade não é cobrir tudo, mas sim tornar a divulgação uma ação controlável.

O que eu mais temo ao lidar com ativos sérios na blockchain não é que outros vejam o saldo, mas que outros montem as relações entre os participantes. Quem transaciona com quem, quem entra e sai em que ponto no tempo, quem se comporta como um market maker, essas revelações de relação impedirão diretamente que as instituições entrem em cena.

Mas, por outro lado, ativos regulamentados não permitem um black box total. Auditoria e regulamentação devem intervir sob condições legais, isso é fundamental.

Então eu preciso que o Dusk me forneça um conjunto de "interfaces de divulgação", transformando a divulgação em um comportamento acionado por condições:

Quem pode ver sob quais condições

Quanto pode ser visto

Após a leitura, é possível reproduzir

Se haverá transbordamento para partes não relacionadas

Quem é responsável pelo risco de transbordamento

Eu sei que essas perguntas podem parecer provocativas, mas essa é a realidade dos ativos regulamentados. Se você não tem uma interface de divulgação, você só pode escolher entre "transparência pública" e "privacidade extrema". E o valor do Dusk reside precisamente em sua afirmação de seguir um terceiro caminho: divulgação seletiva.

O que realmente torna a divulgação seletiva difícil não são os termos técnicos, mas a definição de limites. Se os limites não forem claros, você pode ter problemas em momentos críticos.

Portanto, se eu fosse desenvolvedor, consideraria a interface de divulgação como um dos principais critérios de aceitação do Dusk: se ela pode suportar "provar sem expor", especialmente se pode concluir a prova necessária sem revelar o retrato de relacionamento.

Eu não preciso que ele esconda tudo como um buraco negro, eu preciso que ele torne a divulgação controlável e auditável.

Quarta classe de interface: interface de auditoria e disputa

Não tenho medo de ser auditado, tenho medo de depender de "encontrar alguém para explicar" durante a auditoria.

Uma preferência muito realista que tenho em relação ao Dusk é: prefiro que ele seja um pouco mais lento, mas que torne o caminho de auditoria um mecanismo. Pois o verdadeiro desastre dos ativos regulamentados não é ser auditado, mas quando a auditoria chega e você só pode "procurar a equipe para explicar o que aconteceu". Isso significa que o sistema não codificou a parte mais difícil nas regras, o que significa que você sobrevive à custa do governo das pessoas. O governo das pessoas pode não ser aparente em pequena escala, mas uma vez que a escala aumenta ou surge uma disputa, o governo das pessoas pode entrar em colapso diretamente.

Portanto, preciso que o Dusk forneça uma interface de "disputa reproduzível":

Quando houver uma disputa, a entidade de auditoria autorizada pode reproduzir o processo-chave de acordo com as regras e chegar à mesma conclusão.

Além disso, a reprodução não deve depender da explicação verbal de um funcionário interno.

Aqui também há uma questão mais complicada: a reprodução deve ocorrer sob autorização legal, e não deve permitir que pessoas não relacionadas obtenham materiais para montar uma imagem. Em outras palavras, a interface de auditoria deve ter limites, os limites devem ser executáveis, e após a execução, deve haver uma cadeia de evidências que prove que os limites foram realmente respeitados.

Na verdade, escrever isso me parece complicado, mas esse é o ponto complicado das finanças reais. Se o Dusk estiver disposto a enfrentar esse problema, ele terá a chance de entrar em cenários mais sérios. Se não enfrentar, ficará apenas no conceito.

Quinta classe de interface: interface de liquidação e interoperabilidade

Os ativos precisam se tornar um mercado, não podem ser uma ilha, mas quanto mais forte a interoperabilidade, mais difícil é traçar responsabilidades.

Uma vez que ativos regulamentados estão na blockchain, as instituições geralmente se preocupam não com "se podem comprar", mas com "se podem sair em segurança". A sensação de segurança ao sair vem de duas coisas: liquidação clara e limites de responsabilidade claros. Se você não tiver um caminho claro de liquidação e saída, as instituições sentirão que estão presas em uma ilha.

E se você quiser evitar ilhas, precisa falar sobre interoperabilidade, padrões de dados e liquidação transfronteiriça.

Eu sei que o Dusk tem planos em termos de interoperabilidade e padrões de dados, mas aqui não vou considerar "ter planos" como "resolver". Estou mais preocupado se ele vê a interoperabilidade como um conjunto de "conexões com limites de responsabilidade", e não como "conexões para expandir a narrativa". Porque a interoperabilidade mais facilmente traz risco do que crescimento: como lidar com conflitos de regras após a travessia entre sistemas, quem arca com o custo do fracasso na liquidação, quem é responsável por erros de dados, e sob quais regras as disputas são decididas.

Portanto, como desenvolvedor, o que eu preciso é: o Dusk me dê uma capacidade de camada de liquidação que seja combinável, interoperável, mas com limites de responsabilidade claros.

Dito de uma forma mais humana: espero que ele me permita conectar ao mundo externo, enquanto não transforma minha responsabilidade em uma confusão.

Escrevendo isso, eu realmente já esclareci se o "Dusk é adequado para aplicativos de ativos regulamentados". Não se baseia em uma frase como "cadeia de privacidade em conformidade"; baseia-se na viabilidade, na reprodutibilidade e na resistência à deformação sob pressão dessas cinco classes de interface.

Eu também preciso falar sobre meus próprios pontos de hesitação, para evitar que isso pareça uma posição.

O que me faz hesitar não é a direção do Dusk, mas se seu ritmo de implementação pode acompanhar a janela de demanda real. O ritmo de colocar ativos regulamentados na blockchain é muito estranho: geralmente é lento, mas assim que uma determinada região, um determinado emissor, ou uma forma de produto funciona, a adoção em pequena escala pode acelerar rapidamente. O vencedor muitas vezes não é quem fala melhor, mas quem faz a interface certa primeiro.

Portanto, agora vejo o Dusk como um projeto onde "as interfaces estão se tornando cada vez mais claras", e não um projeto onde "a popularidade está aumentando".

A cada ação, se puder tornar as cinco classes de interfaces de qualificação, regras de ativos, divulgação, auditoria e liquidação um pouco mais claras, eu lhe darei mais peso. Por outro lado, se sua expressão se tornar cada vez mais como uma pilha de grandes palavras, mas a interface permanecer obscura, eu rapidamente ajustarei minhas expectativas para baixo.

Por fim, deixo uma conclusão muito simples, como uma nota para mim mesmo:

Eu não preciso que o Dusk me faça sentir empolgado, eu preciso que ele me faça sentir seguro para lançar. O que os aplicativos de ativos regulamentados realmente precisam não é de aplausos, mas de transformar problemas em interfaces utilizáveis. Se o Dusk puder continuamente preencher essas cinco classes de interface, ele não será apenas um conceito; se não conseguir, por mais que seja escrito em uma narrativa, ainda será apenas uma narrativa.

@Dusk $DUSK #Dusk