@Dusk Tenho observado o design de liquidação do Dusk menos como um problema de velocidade e mais como um problema de coordenação.
Uma camada de finalidade (finality) rápida é útil, mas a liquidação regulada envolve múltiplas partes cujos sistemas nem necessariamente se movem no mesmo ritmo. A camada DuskDS do Dusk pode fornecer finalidade determinística e coordenar o estado da liquidação, ainda assim a perna do ativo, o sistema de pagamentos, o custodiante e as verificações de conformidade podem introduzir diferenças de temporização.
Isso muda a métrica que eu me importaria.
“A qualidade de liquidação é medida quando os sistemas discordam.”
Se uma transação de entrega versus pagamento encontrar um atraso ou uma divergência, a questão importante é o que o protocolo e a infraestrutura ao redor fazem em seguida. O ativo pode permanecer seguramente bloqueado? O lado do pagamento pode ser reconciliado sem criar uma nova exposição a contraparte? Os participantes autorizados conseguem verificar o estado relevante sem expor informações que eles não deveriam ver?
É aqui que a execução confidencial do Dusk se torna mais interessante para mim do que a capacidade bruta. O sistema precisa preservar tanto a correção das transações quanto o fluxo de informações controlado quando algo dá errado.
A fraqueza é que o Dusk não consegue eliminar dependências fora da cadeia. Mesmo uma camada de liquidação perfeitamente determinística ainda herda risco operacional de custodiante, provedores de pagamento e fontes externas de dados.
Então eu observaria o tratamento de liquidações malsucedidas, o tempo de reconciliação e o uso institucional repetido. Transações bem-sucedidas mostram que o sistema funciona; transações difíceis mostram se ele realmente pode ser confiável.
#dusk @Dusk $DUSK $BTR $BMT
Uma camada de finalidade (finality) rápida é útil, mas a liquidação regulada envolve múltiplas partes cujos sistemas nem necessariamente se movem no mesmo ritmo. A camada DuskDS do Dusk pode fornecer finalidade determinística e coordenar o estado da liquidação, ainda assim a perna do ativo, o sistema de pagamentos, o custodiante e as verificações de conformidade podem introduzir diferenças de temporização.
Isso muda a métrica que eu me importaria.
“A qualidade de liquidação é medida quando os sistemas discordam.”
Se uma transação de entrega versus pagamento encontrar um atraso ou uma divergência, a questão importante é o que o protocolo e a infraestrutura ao redor fazem em seguida. O ativo pode permanecer seguramente bloqueado? O lado do pagamento pode ser reconciliado sem criar uma nova exposição a contraparte? Os participantes autorizados conseguem verificar o estado relevante sem expor informações que eles não deveriam ver?
É aqui que a execução confidencial do Dusk se torna mais interessante para mim do que a capacidade bruta. O sistema precisa preservar tanto a correção das transações quanto o fluxo de informações controlado quando algo dá errado.
A fraqueza é que o Dusk não consegue eliminar dependências fora da cadeia. Mesmo uma camada de liquidação perfeitamente determinística ainda herda risco operacional de custodiante, provedores de pagamento e fontes externas de dados.
Então eu observaria o tratamento de liquidações malsucedidas, o tempo de reconciliação e o uso institucional repetido. Transações bem-sucedidas mostram que o sistema funciona; transações difíceis mostram se ele realmente pode ser confiável.
#dusk @Dusk $DUSK $BTR $BMT