Tenho estado a observar @Dusk ; quanto mais olho, mais acho que tem algo de interessante.
Vou começar pelo ciclo de vida das transações que mais me “fisgou”. No começo eu também fui levado pela ideia de finalidade determinística, passei dias lendo documentação até perceber que “confirmed” e “finalized” são coisas totalmente diferentes. O bloco ainda não chegou ao último passo; ainda pode dar revert. O fluxo é: o provisioner propõe primeiro um bloco candidato, depois vem a validação de um comitê aleatório, em seguida um lote de ratificações (Ratification); só depois que a ratificação acontece é que ocorre a entrega/assentamento real (landing). Não é que, ao propor, acabou tudo — é que, após a finalização, você não precisa mais empilhar contagens de confirmação.
Se for só uma transferência comum, tudo bem; mas quando é depósito em exchange ou liquidação de títulos, não dá para brincar assim. Detectar “executed” só indica que a execução ocorreu; você ainda precisa confirmar que o campo “error” está vazio. Só o evento “finalized” é que é realmente seguro. Se vier um “reverted”, tem que ouvir de novo (reescutar). Um revert de contrato é erro de código; um revert de bloco é mudança de consenso — a lógica de recuperação é totalmente em direções opostas. Se o integrador tratar “confirmed” como “final”, a determinística vai cair por terra na camada de aplicação. O que eu mais quero saber agora é: exchange e Dusk Trade usam mesmo “finalized” como fronteira unificada? Existe um fluxo de replay auditável?
Falando em negociação justa, isso me enojou de verdade. O Mempool parece uma sala de vidro sem cortina: tudo que você quer comprar fica visível para a rede; robôs de pinça atacam a qualquer momento. $DUSK faz uma licitação/bate-papo privada e em lote diretamente no nível de protocolo: lances e quantidades são submetidos e, num instante, são “encapsulados”/protegidos por ZK. Os nós calculam um preço justo equivalente ao valor cujo desvio entre a demanda total de compras escondidas e a oferta total de vendas fica próximo de zero; então, todas as ordens pendentes no mesmo bloco são liquidadas nesse preço. A assimetria de informação é arrancada — a piscina escura é justa até na essência.
Também não enrolam em conformidade. A Phoenix usa ZK para privacidade; a Moonlight usa um livro-razão transparente; a Citadel suporta divulgação seletiva; a XSC escreve elegibilidade, restrições e relatórios inteiros na lógica do contrato. Não dá para depender apenas de regras fora da cadeia.
Quanto mais o produto fica complexo, mais regras aparecem. A questão que eu continuo acompanhando é: dá para rodar tudo de forma consistente e estável em vários fluxos de trabalho? A verdadeira “finalidade” não é um termo — é o caminho do evento do nó até o ledger, sem ninguém antecipar. #dusk $DUSK
Vou começar pelo ciclo de vida das transações que mais me “fisgou”. No começo eu também fui levado pela ideia de finalidade determinística, passei dias lendo documentação até perceber que “confirmed” e “finalized” são coisas totalmente diferentes. O bloco ainda não chegou ao último passo; ainda pode dar revert. O fluxo é: o provisioner propõe primeiro um bloco candidato, depois vem a validação de um comitê aleatório, em seguida um lote de ratificações (Ratification); só depois que a ratificação acontece é que ocorre a entrega/assentamento real (landing). Não é que, ao propor, acabou tudo — é que, após a finalização, você não precisa mais empilhar contagens de confirmação.
Se for só uma transferência comum, tudo bem; mas quando é depósito em exchange ou liquidação de títulos, não dá para brincar assim. Detectar “executed” só indica que a execução ocorreu; você ainda precisa confirmar que o campo “error” está vazio. Só o evento “finalized” é que é realmente seguro. Se vier um “reverted”, tem que ouvir de novo (reescutar). Um revert de contrato é erro de código; um revert de bloco é mudança de consenso — a lógica de recuperação é totalmente em direções opostas. Se o integrador tratar “confirmed” como “final”, a determinística vai cair por terra na camada de aplicação. O que eu mais quero saber agora é: exchange e Dusk Trade usam mesmo “finalized” como fronteira unificada? Existe um fluxo de replay auditável?
Falando em negociação justa, isso me enojou de verdade. O Mempool parece uma sala de vidro sem cortina: tudo que você quer comprar fica visível para a rede; robôs de pinça atacam a qualquer momento. $DUSK faz uma licitação/bate-papo privada e em lote diretamente no nível de protocolo: lances e quantidades são submetidos e, num instante, são “encapsulados”/protegidos por ZK. Os nós calculam um preço justo equivalente ao valor cujo desvio entre a demanda total de compras escondidas e a oferta total de vendas fica próximo de zero; então, todas as ordens pendentes no mesmo bloco são liquidadas nesse preço. A assimetria de informação é arrancada — a piscina escura é justa até na essência.
Também não enrolam em conformidade. A Phoenix usa ZK para privacidade; a Moonlight usa um livro-razão transparente; a Citadel suporta divulgação seletiva; a XSC escreve elegibilidade, restrições e relatórios inteiros na lógica do contrato. Não dá para depender apenas de regras fora da cadeia.
Quanto mais o produto fica complexo, mais regras aparecem. A questão que eu continuo acompanhando é: dá para rodar tudo de forma consistente e estável em vários fluxos de trabalho? A verdadeira “finalidade” não é um termo — é o caminho do evento do nó até o ledger, sem ninguém antecipar. #dusk $DUSK