Antes, trabalhei por alguns anos no departamento de liquidação de negociações. O que mais me dava dor de cabeça não era a volatilidade do mercado, e sim o intervalo de compensação de algumas horas depois do fechamento diário. O dinheiro já tinha sido fechado, mas o sistema ainda mostrava “aguardando confirmação”. Nesse período, não dava para fazer nada: só esperar. Depois de esperar, ainda era preciso fazer a conciliação; se não batesse, havia necessidade de retroceder (rastrear) transações. Era comum uma negociação ficar pendente até o meio da manhã do dia seguinte para finalmente se estabilizar.
Sobre o Dusk: no primeiro problema sempre há o conceito de finalização. O livro-razão não volta atrás. O Succinct Attestation segue um caminho determinístico; em outras palavras, é um fluxo de confirmação que faz com que, uma vez “fechado” um bloco, ele permaneça fechado. Os blocos passam por três etapas: Proposal, Validation e Ratification. Ao passar pela Ratification, já é confirmação final. Não existe rollback probabilístico, nem “esperar mais algumas confirmações”. A diferença entre “faltam três minutos” e “faltou um dia” é, na contabilidade, um mundo à parte.
A confirmação rápida tem um custo. O consenso determinístico exige um nível altíssimo de qualidade por parte dos validadores. Quedas de nós e partições de rede, em outras redes podem apenas significar lentidão; aqui, podem simplesmente impedir a produção de blocos. Eu mesmo rodei nós e entendi na prática: numa rede doméstica, se você troca o IP uma vez, já é suficiente para perder uma rodada de votos. Para obter garantias de liquidação em nível institucional, a qualidade dos nós precisa acompanhar.
O time da OtterSec revisou a implementação do PLONK do Dusk e encontrou uma vulnerabilidade: no último passo, o verificador usou dados não verificados fornecidos pelo provedor da prova; em teoria, isso pode permitir problemas de “cunhagem”. A resposta do time foi rápida: corrigiram tudo em um dia. Isso me lembra que, do lado de engenharia, ainda é preciso continuar lapidando: a camada central de criptografia continua surgindo com problemas; não é algo que você resolve e pronto, acabou.
O ecossistema também é raso: há poucas aplicações que realmente podem ser usadas, e o refinamento do produto não acompanha a ambição técnica. O NPEX tem cenários reais de colaboração, mas ainda é preciso ver se as demandas on-chain conseguem se traduzir em consumo real no DUSK. Gas é, na prática, a taxa de transação on-chain; ainda precisa observar.
A direção está certa, mas o resto — se as etapas vão passar ou não — é outra história. Nem todo projeto com a direção certa consegue sobreviver até aquele dia. Quais indicadores vocês vão usar para julgar se uma cadeia “está utilizável”? #dusk $DUSK @Dusk
Sobre o Dusk: no primeiro problema sempre há o conceito de finalização. O livro-razão não volta atrás. O Succinct Attestation segue um caminho determinístico; em outras palavras, é um fluxo de confirmação que faz com que, uma vez “fechado” um bloco, ele permaneça fechado. Os blocos passam por três etapas: Proposal, Validation e Ratification. Ao passar pela Ratification, já é confirmação final. Não existe rollback probabilístico, nem “esperar mais algumas confirmações”. A diferença entre “faltam três minutos” e “faltou um dia” é, na contabilidade, um mundo à parte.
A confirmação rápida tem um custo. O consenso determinístico exige um nível altíssimo de qualidade por parte dos validadores. Quedas de nós e partições de rede, em outras redes podem apenas significar lentidão; aqui, podem simplesmente impedir a produção de blocos. Eu mesmo rodei nós e entendi na prática: numa rede doméstica, se você troca o IP uma vez, já é suficiente para perder uma rodada de votos. Para obter garantias de liquidação em nível institucional, a qualidade dos nós precisa acompanhar.
O time da OtterSec revisou a implementação do PLONK do Dusk e encontrou uma vulnerabilidade: no último passo, o verificador usou dados não verificados fornecidos pelo provedor da prova; em teoria, isso pode permitir problemas de “cunhagem”. A resposta do time foi rápida: corrigiram tudo em um dia. Isso me lembra que, do lado de engenharia, ainda é preciso continuar lapidando: a camada central de criptografia continua surgindo com problemas; não é algo que você resolve e pronto, acabou.
O ecossistema também é raso: há poucas aplicações que realmente podem ser usadas, e o refinamento do produto não acompanha a ambição técnica. O NPEX tem cenários reais de colaboração, mas ainda é preciso ver se as demandas on-chain conseguem se traduzir em consumo real no DUSK. Gas é, na prática, a taxa de transação on-chain; ainda precisa observar.
A direção está certa, mas o resto — se as etapas vão passar ou não — é outra história. Nem todo projeto com a direção certa consegue sobreviver até aquele dia. Quais indicadores vocês vão usar para julgar se uma cadeia “está utilizável”? #dusk $DUSK @Dusk