#dusk $DUSK @Dusk A transação exibida como “sucesso” significa que já terminou de verdade?
Ontem à noite, ao consultar a documentação de desenvolvimento do Dusk, encontrei um detalhe que eu não tinha notado antes.
Depois que uma transação é enviada, o nó retorna 202 Accepted — o que quer dizer apenas que o pedido foi recebido e está sendo processado, não que a transação já foi concluída.
Ao continuar a ler, percebi que, em seguida, ainda é preciso passar por admission, mempool, seleção do bloco e execução.
Mesmo que já tenha sido executada, ainda não acabou.
Porque um bloco que já foi aceito ainda pode ser revertido.
Só quando o bloco entra no estado finalized é que a transação ganha, de fato, finalização.
Achei esse detalhe bem interessante.
Quando a gente costuma dizer “transação bem-sucedida”, na verdade estamos misturando vários estados totalmente diferentes:
o nó recebeu, e a rede aceitou — não é a mesma coisa;
entrou no bloco, e executou com sucesso — também não é a mesma coisa;
executar com sucesso, não é garantia de liquidação final.
Para transferências comuns, essa diferença de estados talvez seja só um detalhe.
Mas e se no futuro a cadeia estiver executando valores mobiliários, pagamentos ou outros ativos financeiros?
Aí, “quase deu certo” certamente não basta.
O que realmente precisa ser respondido é:
em qual estado, afinal, os direitos e obrigações do ativo passam a ser verdadeiramente alterados?
Esse também é um ângulo pelo qual eu tenho voltado a entender recentemente o “deterministic settlement” do Dusk.
O problema que ele realmente precisa resolver talvez nunca tenha sido apenas tornar as transações mais rápidas, e sim garantir que os participantes saibam claramente:
quando já não é mais preciso esperar, e quando é possível, de fato, tratar essa transação como já concluída.
Talvez seja isso que, na infraestrutura financeira, as quatro palavras “transação concluída” realmente querem dizer.
@Dusk $DUSK #DUSK
Ontem à noite, ao consultar a documentação de desenvolvimento do Dusk, encontrei um detalhe que eu não tinha notado antes.
Depois que uma transação é enviada, o nó retorna 202 Accepted — o que quer dizer apenas que o pedido foi recebido e está sendo processado, não que a transação já foi concluída.
Ao continuar a ler, percebi que, em seguida, ainda é preciso passar por admission, mempool, seleção do bloco e execução.
Mesmo que já tenha sido executada, ainda não acabou.
Porque um bloco que já foi aceito ainda pode ser revertido.
Só quando o bloco entra no estado finalized é que a transação ganha, de fato, finalização.
Achei esse detalhe bem interessante.
Quando a gente costuma dizer “transação bem-sucedida”, na verdade estamos misturando vários estados totalmente diferentes:
o nó recebeu, e a rede aceitou — não é a mesma coisa;
entrou no bloco, e executou com sucesso — também não é a mesma coisa;
executar com sucesso, não é garantia de liquidação final.
Para transferências comuns, essa diferença de estados talvez seja só um detalhe.
Mas e se no futuro a cadeia estiver executando valores mobiliários, pagamentos ou outros ativos financeiros?
Aí, “quase deu certo” certamente não basta.
O que realmente precisa ser respondido é:
em qual estado, afinal, os direitos e obrigações do ativo passam a ser verdadeiramente alterados?
Esse também é um ângulo pelo qual eu tenho voltado a entender recentemente o “deterministic settlement” do Dusk.
O problema que ele realmente precisa resolver talvez nunca tenha sido apenas tornar as transações mais rápidas, e sim garantir que os participantes saibam claramente:
quando já não é mais preciso esperar, e quando é possível, de fato, tratar essa transação como já concluída.
Talvez seja isso que, na infraestrutura financeira, as quatro palavras “transação concluída” realmente querem dizer.
@Dusk $DUSK #DUSK
