#dusk $DUSK @Dusk Antes, eu achava que uma transferência em blockchain tinha apenas dois resultados possíveis: ela é bem-sucedida ou falha. Sucesso significava que o valor foi movido. Falha significava que algo deu errado. Mas, quanto mais eu investigava como a Dusk descreve transferências de ativos regulados, mais eu percebi que esse modelo é simplista demais para os mercados financeiros.
Em uma cadeia comum, uma transação rejeitada não lhe diz praticamente nada. O gas acabou, uma instrução require foi acionada, o estado mudou por baixo de você. Você fica tentando adivinhar o quê exatamente aconteceu.
Para um ativo regulado, essa ambiguidade não é aceitável. A documentação da Dusk descreve verificações de transferência que falham com razões claras e — a parte que achei mais interessante — verificações que podem ser simuladas antes de qualquer transação ser enviada.
O que achei particularmente notável é a implicação desse segundo ponto. Isso significa que a elegibilidade não é algo que você descobre tentando fazer uma transferência e vendo ela falhar. Você pode fazer a pergunta primeiro e receber uma resposta, sem sequer tocar no ledger.
Isso reflete como o lado tradicional já funciona. Um corretor não envia uma ordem e espera que o sistema de conformidade permita. A verificação acontece antes; e, quando uma negociação é recusada, alguém consegue explicar com precisão por quê — a contraparte não estava credenciada, o período de carência ainda não havia transcorrido, a jurisdição estava restrita. "Rejeitada" sem um motivo não é uma resposta utilizável em um processo regulado.
A falha vira informação, e não um acidente. E uma rejeição que traz um motivo é, de forma argumentável, mais útil do que um sucesso que não traz nenhum.
Ainda não consigo avaliar o quão detalhadas essas razões são na prática, nem quanto disso está disponível para uma aplicação hoje, em vez de estar descrito apenas como uma meta de design.
A partir daí, comecei a enxergar o design de outra forma. A conformidade on-chain talvez não seja sobre bloquear transações ruins. Talvez seja sobre tornar o resultado previsível antes de qualquer pessoa se comprometer com ele.
Em uma cadeia comum, uma transação rejeitada não lhe diz praticamente nada. O gas acabou, uma instrução require foi acionada, o estado mudou por baixo de você. Você fica tentando adivinhar o quê exatamente aconteceu.
Para um ativo regulado, essa ambiguidade não é aceitável. A documentação da Dusk descreve verificações de transferência que falham com razões claras e — a parte que achei mais interessante — verificações que podem ser simuladas antes de qualquer transação ser enviada.
O que achei particularmente notável é a implicação desse segundo ponto. Isso significa que a elegibilidade não é algo que você descobre tentando fazer uma transferência e vendo ela falhar. Você pode fazer a pergunta primeiro e receber uma resposta, sem sequer tocar no ledger.
Isso reflete como o lado tradicional já funciona. Um corretor não envia uma ordem e espera que o sistema de conformidade permita. A verificação acontece antes; e, quando uma negociação é recusada, alguém consegue explicar com precisão por quê — a contraparte não estava credenciada, o período de carência ainda não havia transcorrido, a jurisdição estava restrita. "Rejeitada" sem um motivo não é uma resposta utilizável em um processo regulado.
A falha vira informação, e não um acidente. E uma rejeição que traz um motivo é, de forma argumentável, mais útil do que um sucesso que não traz nenhum.
Ainda não consigo avaliar o quão detalhadas essas razões são na prática, nem quanto disso está disponível para uma aplicação hoje, em vez de estar descrito apenas como uma meta de design.
A partir daí, comecei a enxergar o design de outra forma. A conformidade on-chain talvez não seja sobre bloquear transações ruins. Talvez seja sobre tornar o resultado previsível antes de qualquer pessoa se comprometer com ele.