Ao analisar desta vez as regras de transferência de ativos do Dusk, acabei prestando atenção em um detalhe bem pouco chamativo: por que ele faria uma verificação e uma simulação antes de a transação ser realmente enviada?
Antes, quando eu via transferências on-chain, o padrão era: assinar, enviar e esperar o resultado.
Mas ativos sujeitos a regulamentação não funcionam assim.
Um investidor pode ter saldo, mas não ter permissão para deter certo tipo de ativo; um endereço também pode conseguir receber pagamentos, mas, pelas regras atuais, ele não pode receber este ativo.
No design oficial do Dusk, essa verificação de elegibilidade e de transferência é colocada com antecedência no processo, permitindo que a transação seja checada ou simulada antes da submissão oficial.
> Acho que o que essa etapa realmente resolve não é apenas os quatro dizeres “a transação falhou”, mas evitar que uma operação incorreta vire fato on-chain.
Do ponto de vista de quem emite ou de um marketplace, essa diferença é enorme.
A lógica tradicional on-chain é mais parecida com:
Primeiro, submeter.
Se falhar, então tratar depois.
O que o Dusk quer fazer é:
Primeiro, avaliar.
Se não cumprir as regras, barrar o máximo possível antes de enviar.
Claro que isso adiciona uma camada extra de lógica de verificação; a transferência de ativos não fica tão simples quanto tokens comuns que só olham saldo e assinatura.
Mas, em troca, é possível embutir antecipadamente no fluxo on-chain muitas decisões de conformidade que antes dependiam de correção manual do backoffice.
Acho que é justamente aqui que o Dusk fica realmente interessante.
Ele não está apenas “transportando” títulos para a blockchain; ele tenta fazer com que “quem pode transferir, quem pode receber e em que situações se deve recusar” se torne parte das próprias regras operacionais do ativo.
Se você fosse o emissor, você preferiria aceitar uma etapa extra de checagem prévia, ou preferiria manter a simplicidade do fluxo de tokens comuns — transferir primeiro e tratar as exceções depois?@Dusk
#dusk $DUSK
Antes, quando eu via transferências on-chain, o padrão era: assinar, enviar e esperar o resultado.
Mas ativos sujeitos a regulamentação não funcionam assim.
Um investidor pode ter saldo, mas não ter permissão para deter certo tipo de ativo; um endereço também pode conseguir receber pagamentos, mas, pelas regras atuais, ele não pode receber este ativo.
No design oficial do Dusk, essa verificação de elegibilidade e de transferência é colocada com antecedência no processo, permitindo que a transação seja checada ou simulada antes da submissão oficial.
> Acho que o que essa etapa realmente resolve não é apenas os quatro dizeres “a transação falhou”, mas evitar que uma operação incorreta vire fato on-chain.
Do ponto de vista de quem emite ou de um marketplace, essa diferença é enorme.
A lógica tradicional on-chain é mais parecida com:
Primeiro, submeter.
Se falhar, então tratar depois.
O que o Dusk quer fazer é:
Primeiro, avaliar.
Se não cumprir as regras, barrar o máximo possível antes de enviar.
Claro que isso adiciona uma camada extra de lógica de verificação; a transferência de ativos não fica tão simples quanto tokens comuns que só olham saldo e assinatura.
Mas, em troca, é possível embutir antecipadamente no fluxo on-chain muitas decisões de conformidade que antes dependiam de correção manual do backoffice.
Acho que é justamente aqui que o Dusk fica realmente interessante.
Ele não está apenas “transportando” títulos para a blockchain; ele tenta fazer com que “quem pode transferir, quem pode receber e em que situações se deve recusar” se torne parte das próprias regras operacionais do ativo.
Se você fosse o emissor, você preferiria aceitar uma etapa extra de checagem prévia, ou preferiria manter a simplicidade do fluxo de tokens comuns — transferir primeiro e tratar as exceções depois?@Dusk
#dusk $DUSK