POR QUE UM EVENTO EM BLOCKCHAIN NÃO É A MESMA COISA QUE FINALIDADE
Eu costumava pensar que uma exchange precisava, principalmente, saber quando uma transação de blockchain acontecia. Mas ao ver o Dusk, isso me fez questionar. Se uma transação ainda pode mudar, não tenho certeza se uma exchange deveria tratar esse evento como dinheiro definitivo.
Foi por isso que RUES (Rusk Universal Event System) chamou minha atenção. O Dusk lista especificamente o RUES para infraestrutura, indexadores e exchanges. Para mim, a parte interessante é o que a exchange faz depois de receber o evento.
O ciclo de vida de transações do Dusk separa incluída, executada, confirmada e finalizada. A documentação diz para monitorar a transação executada, verificar erros, confirmar que o bloco foi finalizado e re-escutar caso um bloco reverta. Eu entendo por que isso importa: creditar uma exchange cedo demais pode transformar um estado temporário em um saldo real.
Fico pensando nisso como rastreamento de encomendas. Se meu pacote diz “a caminho para entrega”, eu sei que ele está se movendo, mas eu não marcaria como entregue ainda. Talvez eu esteja sendo cauteloso demais, mas eu entendo por que uma exchange iria querer essa mesma lacuna entre “em movimento” e “entregue”.
O detalhe de idempotência me fez parar novamente. O Dusk orienta os scanners de depósitos a usarem o ID da transação do Dusk como chave de idempotência, e não o memo, e a escrever o crédito e o checkpoint do bloco de forma atômica. Assim, se o scanner travar e escanear o mesmo intervalo novamente, essa transação não deveria virar um segundo depósito.
E agora estou me perguntando se eu estava olhando para o RUES de forma simples demais. Se uma exchange precisa pensar separadamente sobre evento, finalidade, reversões e processamento duplicado, quanto do trabalho real está acontecendo depois que o blockchain diz que algo aconteceu? @Dusk #dusk $DUSK
Eu costumava pensar que uma exchange precisava, principalmente, saber quando uma transação de blockchain acontecia. Mas ao ver o Dusk, isso me fez questionar. Se uma transação ainda pode mudar, não tenho certeza se uma exchange deveria tratar esse evento como dinheiro definitivo.
Foi por isso que RUES (Rusk Universal Event System) chamou minha atenção. O Dusk lista especificamente o RUES para infraestrutura, indexadores e exchanges. Para mim, a parte interessante é o que a exchange faz depois de receber o evento.
O ciclo de vida de transações do Dusk separa incluída, executada, confirmada e finalizada. A documentação diz para monitorar a transação executada, verificar erros, confirmar que o bloco foi finalizado e re-escutar caso um bloco reverta. Eu entendo por que isso importa: creditar uma exchange cedo demais pode transformar um estado temporário em um saldo real.
Fico pensando nisso como rastreamento de encomendas. Se meu pacote diz “a caminho para entrega”, eu sei que ele está se movendo, mas eu não marcaria como entregue ainda. Talvez eu esteja sendo cauteloso demais, mas eu entendo por que uma exchange iria querer essa mesma lacuna entre “em movimento” e “entregue”.
O detalhe de idempotência me fez parar novamente. O Dusk orienta os scanners de depósitos a usarem o ID da transação do Dusk como chave de idempotência, e não o memo, e a escrever o crédito e o checkpoint do bloco de forma atômica. Assim, se o scanner travar e escanear o mesmo intervalo novamente, essa transação não deveria virar um segundo depósito.
E agora estou me perguntando se eu estava olhando para o RUES de forma simples demais. Se uma exchange precisa pensar separadamente sobre evento, finalidade, reversões e processamento duplicado, quanto do trabalho real está acontecendo depois que o blockchain diz que algo aconteceu? @Dusk #dusk $DUSK