#dusk $DUSK
最近 continuei a reler a documentação do ciclo de vida de uma transação @Dusk , e só então percebi que eu antes tinha simplificado demais uma coisa:
executar uma transação com sucesso não significa que esse estado já possa ser tratado pelo sistema financeiro como “fato”.
No DuskDS, uma transação primeiro é recebida, propagada e executada; depois disso, ainda precisa passar pela confirmação final.
A documentação oficial até lembra explicitamente:
included, accepted e confirmed não podem ser tratados diretamente como payment finality.
O motivo não é complicado.
Uma transação que entra em um bloco accepted ainda pode ser revertida.
Só quando chega a finalized é que o estado entra em deterministic finality.
Na Succinct Attestation do Dusk, o processo continua passando por:
Proposal
→ Validation
→ Ratification
Quando a Ratification é concluída, o bloco só então fica realmente final.
Acho esse detalhe mais valioso do que “quantos TPS”.
Porque o que mais assusta uma exchange ou um sistema financeiro não é ver uma transação alguns segundos depois.
O medo é:
eu já creditei o usuário com base nesse estado, e depois o estado subjacente mudou de novo.
Por isso a documentação de integração do Dusk para exchanges também exige claramente que não se faça lançamento antecipado por causa de mempool, evento included ou bloco accepted-but-unfinalized.
Isso, na prática, deixa o conceito de finality bem concreto.
Não se trata de uma palavra de desempenho.
É uma resposta para:
a partir de que momento o sistema realmente pode parar de se preocupar com a possibilidade de esse estado ser revogado?
O indicador de finality que o site do Dusk mostra atualmente é de cerca de 10 segundos.
O que mais me importa não é se esse número parece bonito.
É se, quando a mainnet estiver realmente sob carga, essa fronteira entre accepted e finalized conseguir permanecer sempre clara e estável.
No fim, é disso que os sistemas financeiros realmente dependem.
最近 continuei a reler a documentação do ciclo de vida de uma transação @Dusk , e só então percebi que eu antes tinha simplificado demais uma coisa:
executar uma transação com sucesso não significa que esse estado já possa ser tratado pelo sistema financeiro como “fato”.
No DuskDS, uma transação primeiro é recebida, propagada e executada; depois disso, ainda precisa passar pela confirmação final.
A documentação oficial até lembra explicitamente:
included, accepted e confirmed não podem ser tratados diretamente como payment finality.
O motivo não é complicado.
Uma transação que entra em um bloco accepted ainda pode ser revertida.
Só quando chega a finalized é que o estado entra em deterministic finality.
Na Succinct Attestation do Dusk, o processo continua passando por:
Proposal
→ Validation
→ Ratification
Quando a Ratification é concluída, o bloco só então fica realmente final.
Acho esse detalhe mais valioso do que “quantos TPS”.
Porque o que mais assusta uma exchange ou um sistema financeiro não é ver uma transação alguns segundos depois.
O medo é:
eu já creditei o usuário com base nesse estado, e depois o estado subjacente mudou de novo.
Por isso a documentação de integração do Dusk para exchanges também exige claramente que não se faça lançamento antecipado por causa de mempool, evento included ou bloco accepted-but-unfinalized.
Isso, na prática, deixa o conceito de finality bem concreto.
Não se trata de uma palavra de desempenho.
É uma resposta para:
a partir de que momento o sistema realmente pode parar de se preocupar com a possibilidade de esse estado ser revogado?
O indicador de finality que o site do Dusk mostra atualmente é de cerca de 10 segundos.
O que mais me importa não é se esse número parece bonito.
É se, quando a mainnet estiver realmente sob carga, essa fronteira entre accepted e finalized conseguir permanecer sempre clara e estável.
No fim, é disso que os sistemas financeiros realmente dependem.