Acabei de descer para pegar um lanche noturno, e o visor do elevador já acendeu cedo com “chegou”, mas a porta demorou teimosamente dois segundos para abrir. Isso me lembrou um velho problema de quando eu estava por trás, na sala de servidores, ajustando nós ontem à noite — depois de tanto tempo nesse meio, eu sempre fico com uma desconfiança instintiva em relação àquela mensagem verde de “transação bem-sucedida” no front-end.
Nesses dias, enquanto corria alguns scripts, eu reli de novo a whitepaper do Dusk e descobri que, além do motor de privacidade que eles destacam, o que realmente esconde detalhes bem “pesados” está no consenso de Succinct Attestation, naquela lógica de “finalidade rolante” (Rolling Finality).
Essa lógica é bem interessante. Em cada rodada de produção de blocos, primeiro escolhem um proponente por sorteio determinístico; depois, ainda precisa passar por duas etapas do comitê — verificação e aprovação. Em ambos os casos, é preciso reunir dois terços dos votos válidos e agregar assinaturas BLS para formar o certificado final. Parece que alguém carimba com dois carimbos em um escritório… mas e se você cair numa situação extrema como latência de rede? Na mesma rodada, é totalmente possível surgir candidatos com iterações diferentes; nesse momento, o nó precisa acionar um fallback local com base nesses certificados.
Então, nunca trate o aviso do front-end como se fosse sentença. No estado subjacente do Dusk, Accepted apenas significa que a rede recebeu a mensagem; Attested quer dizer que você obteve um certificado inicial; e só depois que blocos subsequentes empurrarem o estado até Confirmed — e, ainda por cima, até o bloco pai ficar realmente Final — é que essa conta é “cravada” de vez na cadeia, imutável, sem ninguém conseguir alterar.
É também por isso que eu sempre fui preguiçoso para ficar ouvindo essas redes públicas gritando TPS todos os dias. Se a ideia fosse colocar valores mobiliários reais de centenas de milhões de euros na cadeia, o que as instituições mais temem não é simplesmente ter que esperar esses três ou cinco segundos. O medo real é a briga entre as duas pontas sobre “foi ou não foi liquidado”. O Dusk fatiou essa incerteza em estados de código claros e explícitos. O capital tradicional pode olhar para esses marcadores concretos da camada de base para decidir quando liberar o pagamento, quando transferir a titularidade, em vez de ficar comemorando cegamente por causa de um valor hash.
Mas minha regra de “prioridade é salvar a vida” não pode quebrar. Por mais rigoroso que seja o protocolo de base, no fim ainda depende de as instituições licenciadas estarem dispostas a realmente integrar seus sistemas centrais de negócios a essas interfaces RPC. Ser aprovado tecnicamente é só a entrada; não significa que eu vá aceitar “o tranco” sem pensar, nem pegar de volta $DUSK .
#dusk #BTC @Dusk $DUSK
Nesses dias, enquanto corria alguns scripts, eu reli de novo a whitepaper do Dusk e descobri que, além do motor de privacidade que eles destacam, o que realmente esconde detalhes bem “pesados” está no consenso de Succinct Attestation, naquela lógica de “finalidade rolante” (Rolling Finality).
Essa lógica é bem interessante. Em cada rodada de produção de blocos, primeiro escolhem um proponente por sorteio determinístico; depois, ainda precisa passar por duas etapas do comitê — verificação e aprovação. Em ambos os casos, é preciso reunir dois terços dos votos válidos e agregar assinaturas BLS para formar o certificado final. Parece que alguém carimba com dois carimbos em um escritório… mas e se você cair numa situação extrema como latência de rede? Na mesma rodada, é totalmente possível surgir candidatos com iterações diferentes; nesse momento, o nó precisa acionar um fallback local com base nesses certificados.
Então, nunca trate o aviso do front-end como se fosse sentença. No estado subjacente do Dusk, Accepted apenas significa que a rede recebeu a mensagem; Attested quer dizer que você obteve um certificado inicial; e só depois que blocos subsequentes empurrarem o estado até Confirmed — e, ainda por cima, até o bloco pai ficar realmente Final — é que essa conta é “cravada” de vez na cadeia, imutável, sem ninguém conseguir alterar.
É também por isso que eu sempre fui preguiçoso para ficar ouvindo essas redes públicas gritando TPS todos os dias. Se a ideia fosse colocar valores mobiliários reais de centenas de milhões de euros na cadeia, o que as instituições mais temem não é simplesmente ter que esperar esses três ou cinco segundos. O medo real é a briga entre as duas pontas sobre “foi ou não foi liquidado”. O Dusk fatiou essa incerteza em estados de código claros e explícitos. O capital tradicional pode olhar para esses marcadores concretos da camada de base para decidir quando liberar o pagamento, quando transferir a titularidade, em vez de ficar comemorando cegamente por causa de um valor hash.
Mas minha regra de “prioridade é salvar a vida” não pode quebrar. Por mais rigoroso que seja o protocolo de base, no fim ainda depende de as instituições licenciadas estarem dispostas a realmente integrar seus sistemas centrais de negócios a essas interfaces RPC. Ser aprovado tecnicamente é só a entrada; não significa que eu vá aceitar “o tranco” sem pensar, nem pegar de volta $DUSK .
#dusk #BTC @Dusk $DUSK