Irmãos, hoje vamos conversar sobre um assunto que pode salvar vidas — não se sintam com vergonha de soar meio estranho.
A “torta” subiu para mais de 80 mil. O BTC está muito forte!
Na comunidade, existe um problema comum: assim que alguém vê que saiu um hash de transação, todo mundo quer, na hora, abrir champanhe e comemorar. Mas falando a verdade: na rede como a Dusk, que busca conformidade com finanças reguladas, entre o Confirmed (confirmado) e o Finalized (finalidade), na verdade há uma “fenda de tempo” que precisa ser examinada com uma lupa.
Eu relembrei/reorganizei a base do Succinct Attestation e percebi que essa ideia é bem contraintuitiva. Ela não segue aquela lógica bruta do tipo “um bloco apareceu, pronto, pode carimbar”. Em vez disso, são três degraus bem estáveis: primeiro, o Provisioner apresenta os blocos candidatos; depois, o comitê sorteado coloca a mão na massa para validar — ainda não acabou — e é preciso esperar que outro grupo de juízes dê o martelo com Ratification. Só quando o martelo do terceiro passo cai é que o livro-razão é considerado “registrado como prova”. As duas etapas anteriores, no fim das contas, ainda são “rascunhos”.
Essa diferença quase não dá para sentir no dia a dia quando a gente faz transferências. Mas pense bem: e se isso for uma liquidação de valores mobiliários na Dusk Trade, ou algum crédito grande de uma instituição? Só escutar o “Contract Executed” e já lançar na contabilidade, se depois acontecer um Block Reverted (lembre-se: isso não é erro de contrato; é um “retrocesso do tempo” no nível de consenso), como você vai acertar as contas com o time financeiro? O arquivo não volta. Os documentos até deixam claro de propósito a distinção entre revert do contrato e revert do bloco: o primeiro é um conflito de lógica de código; o segundo é o bloco inteiro ter sido “eliminado” pelo consenso. São dois tipos de falha, duas soluções diferentes — misturar tudo é como cavar uma bomba-relógio para si.
Então veja: por mais que a norma esteja escrita em papel e tinta, não adianta se o integrador resolve economizar na prática. O que eu me importo nunca foi saber quantos segundos, em média, sai um bloco — $DUSK . O que eu observo são aqueles caras que fazem aplicações: eles tratam o finalized como “ferro com ferro”, como um ponto sem retorno, e não operam fora da linha. Se algo der errado, existe um conjunto de ferramentas de replay auditáveis que permita que a contabilidade do negócio acompanhe a cadeia e “tome um remédio para o arrependimento” junto com ela?
A verdadeira finalidade final de liquidação nunca é aquele momento em que os nós fecham a porta e votam. Ela precisa partir do evento de finalized, atravessar os desafios de indexação/arquivamento dos nós, atravessar também as barreiras de varredura de reconexão, e só então cair com segurança no banco de dados do negócio. No meio, se qualquer etapa sair correndo — antes da hora — essa história acaba dando errado.
@Dusk $DUSK #dusk
A “torta” subiu para mais de 80 mil. O BTC está muito forte!
Na comunidade, existe um problema comum: assim que alguém vê que saiu um hash de transação, todo mundo quer, na hora, abrir champanhe e comemorar. Mas falando a verdade: na rede como a Dusk, que busca conformidade com finanças reguladas, entre o Confirmed (confirmado) e o Finalized (finalidade), na verdade há uma “fenda de tempo” que precisa ser examinada com uma lupa.
Eu relembrei/reorganizei a base do Succinct Attestation e percebi que essa ideia é bem contraintuitiva. Ela não segue aquela lógica bruta do tipo “um bloco apareceu, pronto, pode carimbar”. Em vez disso, são três degraus bem estáveis: primeiro, o Provisioner apresenta os blocos candidatos; depois, o comitê sorteado coloca a mão na massa para validar — ainda não acabou — e é preciso esperar que outro grupo de juízes dê o martelo com Ratification. Só quando o martelo do terceiro passo cai é que o livro-razão é considerado “registrado como prova”. As duas etapas anteriores, no fim das contas, ainda são “rascunhos”.
Essa diferença quase não dá para sentir no dia a dia quando a gente faz transferências. Mas pense bem: e se isso for uma liquidação de valores mobiliários na Dusk Trade, ou algum crédito grande de uma instituição? Só escutar o “Contract Executed” e já lançar na contabilidade, se depois acontecer um Block Reverted (lembre-se: isso não é erro de contrato; é um “retrocesso do tempo” no nível de consenso), como você vai acertar as contas com o time financeiro? O arquivo não volta. Os documentos até deixam claro de propósito a distinção entre revert do contrato e revert do bloco: o primeiro é um conflito de lógica de código; o segundo é o bloco inteiro ter sido “eliminado” pelo consenso. São dois tipos de falha, duas soluções diferentes — misturar tudo é como cavar uma bomba-relógio para si.
Então veja: por mais que a norma esteja escrita em papel e tinta, não adianta se o integrador resolve economizar na prática. O que eu me importo nunca foi saber quantos segundos, em média, sai um bloco — $DUSK . O que eu observo são aqueles caras que fazem aplicações: eles tratam o finalized como “ferro com ferro”, como um ponto sem retorno, e não operam fora da linha. Se algo der errado, existe um conjunto de ferramentas de replay auditáveis que permita que a contabilidade do negócio acompanhe a cadeia e “tome um remédio para o arrependimento” junto com ela?
A verdadeira finalidade final de liquidação nunca é aquele momento em que os nós fecham a porta e votam. Ela precisa partir do evento de finalized, atravessar os desafios de indexação/arquivamento dos nós, atravessar também as barreiras de varredura de reconexão, e só então cair com segurança no banco de dados do negócio. No meio, se qualquer etapa sair correndo — antes da hora — essa história acaba dando errado.
@Dusk $DUSK #dusk