Estava lendo a documentação de infraestrutura de mercado da Dusk e ficava travando na parte do pagamento. Uma transferência de ativos, por si só, é fácil de imaginar. A parte complicada começa quando o pagamento precisa se alinhar a isso.
A Dusk trata Delivery-versus-Payment como um problema de fluxo de trabalho, e não apenas mais uma transferência de tokens. A perna de ativos e a perna de pagamento podem ser coordenadas pelos caminhos de execução da Dusk, enquanto a DuskDS fornece a liquidação e a finalidade determinística por baixo. Isso significa que a parte interessante não é, na prática, colocar os dois ativos na mesma cadeia. É fazer com que ambas as mudanças de estado se estabeleçam de forma previsível.
Gosto da ideia, mas também acho fácil exagerar o que o protocolo está fazendo aqui.
A Dusk fornece os blocos de construção para essa coordenação. A aplicação em si ainda precisa definir como as condições de ativo, pagamento, elegibilidade e liquidação se encaixam. A própria documentação da Dusk é bem explícita ao dizer que diferentes produtos podem implementar o fluxo de trabalho de formas diferentes.
Isso importa porque DvP pode parecer enganadoramente simples por fora. Você move a segurança, move o pagamento, e chama de liquidado. Em um fluxo de trabalho regulado de verdade, há mais condições ao redor dessas duas pernas.
Então eu não diria que a Dusk eliminou, de alguma forma, o problema de coordenação. Ela moveu a coordenação para uma base comum de liquidação com finalidade determinística.
A única coisa que eu ainda gostaria de inspecionar em uma implantação real é bem específica: quando uma perna falha por causa das condições no nível da aplicação, em que estado exato a outra perna permanece, e quão rapidamente o fluxo de trabalho pode ser desfeito com segurança?
#dusk $DUSK @Dusk $ACE
A Dusk trata Delivery-versus-Payment como um problema de fluxo de trabalho, e não apenas mais uma transferência de tokens. A perna de ativos e a perna de pagamento podem ser coordenadas pelos caminhos de execução da Dusk, enquanto a DuskDS fornece a liquidação e a finalidade determinística por baixo. Isso significa que a parte interessante não é, na prática, colocar os dois ativos na mesma cadeia. É fazer com que ambas as mudanças de estado se estabeleçam de forma previsível.
Gosto da ideia, mas também acho fácil exagerar o que o protocolo está fazendo aqui.
A Dusk fornece os blocos de construção para essa coordenação. A aplicação em si ainda precisa definir como as condições de ativo, pagamento, elegibilidade e liquidação se encaixam. A própria documentação da Dusk é bem explícita ao dizer que diferentes produtos podem implementar o fluxo de trabalho de formas diferentes.
Isso importa porque DvP pode parecer enganadoramente simples por fora. Você move a segurança, move o pagamento, e chama de liquidado. Em um fluxo de trabalho regulado de verdade, há mais condições ao redor dessas duas pernas.
Então eu não diria que a Dusk eliminou, de alguma forma, o problema de coordenação. Ela moveu a coordenação para uma base comum de liquidação com finalidade determinística.
A única coisa que eu ainda gostaria de inspecionar em uma implantação real é bem específica: quando uma perna falha por causa das condições no nível da aplicação, em que estado exato a outra perna permanece, e quão rapidamente o fluxo de trabalho pode ser desfeito com segurança?
#dusk $DUSK @Dusk $ACE