Hoje meu tio me perguntou algo que parecia simples. “Se um sistema financeiro diz que uma transação foi bem-sucedida, por que alguém questionaria isso?”
Honestamente, essa pergunta ficou comigo enquanto eu analisava como o Dusk lida com transações.
Eu costumava achar que sucesso era apenas sucesso. Mas o Dusk separa o processo em diferentes etapas. Uma transação pode ser aceita para roteamento, entrar no mempool local, ser executada em um bloco e só mais tarde alcançar a finalização.
Isso me fez parar por um momento.
O problema real não é que o sistema tenha múltiplos estados. É o que acontece quando uma aplicação trata esses estados como se significassem exatamente a mesma coisa.
Fiquei surpreso com a praticidade desse risco. Se uma aplicação vê sucesso e imediatamente libera um ativo, atualiza garantias ou encerra uma obrigação, ela pode estar agindo antes de o protocolo realmente ter alcançado o estado necessário para aquela ação.
As orientações de exchange do Dusk deixam essa distinção ainda mais clara. Uma transação aceita para roteamento não significa que um saque esteja concluído. Execução e finalização ainda importam.
Minha preocupação não é complexidade. Sistemas financeiros já são complexos.
O verdadeiro Trade-off é entre tornar uma API fácil de usar e fornecer aos desenvolvedores informações suficientes para tomarem a decisão econômica correta.
Meu desejo é simples. Uma API deve dizer
para os desenvolvedores não apenas o que aconteceu, mas
o que eles realmente estão seguros de fazer em seguida.
Estou sendo honesto. Eu prefiro ver alguns estados claros em vez de uma mensagem simples de sucesso que pode significar coisas diferentes em momentos diferentes.
Então, APIs financeiras devem manter a complexidade do protocolo escondida ou mostrar aos desenvolvedores o estado que elas realmente precisam antes de realizar a próxima ação financeira? 🤔
#dusk $DUSK $BTC $ETH @Dusk
#Blockchain #DeFi #Web3
Honestamente, essa pergunta ficou comigo enquanto eu analisava como o Dusk lida com transações.
Eu costumava achar que sucesso era apenas sucesso. Mas o Dusk separa o processo em diferentes etapas. Uma transação pode ser aceita para roteamento, entrar no mempool local, ser executada em um bloco e só mais tarde alcançar a finalização.
Isso me fez parar por um momento.
O problema real não é que o sistema tenha múltiplos estados. É o que acontece quando uma aplicação trata esses estados como se significassem exatamente a mesma coisa.
Fiquei surpreso com a praticidade desse risco. Se uma aplicação vê sucesso e imediatamente libera um ativo, atualiza garantias ou encerra uma obrigação, ela pode estar agindo antes de o protocolo realmente ter alcançado o estado necessário para aquela ação.
As orientações de exchange do Dusk deixam essa distinção ainda mais clara. Uma transação aceita para roteamento não significa que um saque esteja concluído. Execução e finalização ainda importam.
Minha preocupação não é complexidade. Sistemas financeiros já são complexos.
O verdadeiro Trade-off é entre tornar uma API fácil de usar e fornecer aos desenvolvedores informações suficientes para tomarem a decisão econômica correta.
Meu desejo é simples. Uma API deve dizer
para os desenvolvedores não apenas o que aconteceu, mas
o que eles realmente estão seguros de fazer em seguida.
Estou sendo honesto. Eu prefiro ver alguns estados claros em vez de uma mensagem simples de sucesso que pode significar coisas diferentes em momentos diferentes.
Então, APIs financeiras devem manter a complexidade do protocolo escondida ou mostrar aos desenvolvedores o estado que elas realmente precisam antes de realizar a próxima ação financeira? 🤔
#dusk $DUSK $BTC $ETH @Dusk
#Blockchain #DeFi #Web3
