Houve uma noite em que fiquei ali, mapeando o fluxo de depósito/levantamento para um app financeiro, sem nem perceber quando o café ficou frio... o que me prendeu não foi a Prova de Zero Conhecimento, mas sim quais dados precisam ser vistos e quais dados nunca devem ser expostos?
Eu dividi em 20 casos de transação: 12 precisavam de Auditabilidade, 8 precisavam de Confidencialidade; foi aí que Moonlight com Account Model e Phoenix com UTXO Model pararam de soar como nomes criados para marketing
Moonlight expõe saldo, remetente, destinatário, valor, nonce; Phoenix coloca os fundos em uma nota criptografada, usando commitment, Nullifier e Prova de Zero Conhecimento para provar uma transição de estado sem revelar o Valor
ao rascunhar o Indexer, finalmente entendi que o Account Model é mais fácil de ler, mas o nonce precisa ser gerenciado com rigor; o Phoenix é mais privado, porém traz junto a seleção de notas, Nullifier gasto, gerenciamento de chaves... A privacidade transfere o custo para a arquitetura
para ser franco, foram os detalhes mínimos que fizeram eu confiar mais: memo limitado a 512 bytes, precisão nativa de 9 decimais, o endereço do Moonlight usa chave comprimida de 96 B enquanto o Phoenix usa 2 × 32 B de pontos comprimidos; errar a codificação por um único byte é o bastante para passar a noite inteira encarando logs!
fee = gas_used × gas_price; ficar sem gas pode causar um revert, mas o gas já utilizado ainda é cobrado, então Gas Limit e Gas Price não são apenas campos para preencher por aparência
Quando chega a Rusk, DuskVM, Rust/WebAssembly, Smart Contract, GraphQL, mempool, finality... o problema real está nas operações
Moonlight conflita por conta + nonce, Phoenix por Nullifier gasto; uma vez que um crédito duplicado passa, a diversão acaba
para mim, o que vale a pena escrutinar no Dusk é se o Developer Toolchain, Documentação, SDK, API, Custódia, Viewing Key, Selective Disclosure e trilha de auditoria foram projetados com qualidade suficiente para tornar erros genuinamente difíceis de acontecer
se a arquitetura obriga os devs a pensar sobre visibilidade, idempotência e finalidade... não é esse o teste realmente sério para uma blockchain financeira?
#dusk $DUSK @Dusk
Eu dividi em 20 casos de transação: 12 precisavam de Auditabilidade, 8 precisavam de Confidencialidade; foi aí que Moonlight com Account Model e Phoenix com UTXO Model pararam de soar como nomes criados para marketing
Moonlight expõe saldo, remetente, destinatário, valor, nonce; Phoenix coloca os fundos em uma nota criptografada, usando commitment, Nullifier e Prova de Zero Conhecimento para provar uma transição de estado sem revelar o Valor
ao rascunhar o Indexer, finalmente entendi que o Account Model é mais fácil de ler, mas o nonce precisa ser gerenciado com rigor; o Phoenix é mais privado, porém traz junto a seleção de notas, Nullifier gasto, gerenciamento de chaves... A privacidade transfere o custo para a arquitetura
para ser franco, foram os detalhes mínimos que fizeram eu confiar mais: memo limitado a 512 bytes, precisão nativa de 9 decimais, o endereço do Moonlight usa chave comprimida de 96 B enquanto o Phoenix usa 2 × 32 B de pontos comprimidos; errar a codificação por um único byte é o bastante para passar a noite inteira encarando logs!
fee = gas_used × gas_price; ficar sem gas pode causar um revert, mas o gas já utilizado ainda é cobrado, então Gas Limit e Gas Price não são apenas campos para preencher por aparência
Quando chega a Rusk, DuskVM, Rust/WebAssembly, Smart Contract, GraphQL, mempool, finality... o problema real está nas operações
Moonlight conflita por conta + nonce, Phoenix por Nullifier gasto; uma vez que um crédito duplicado passa, a diversão acaba
para mim, o que vale a pena escrutinar no Dusk é se o Developer Toolchain, Documentação, SDK, API, Custódia, Viewing Key, Selective Disclosure e trilha de auditoria foram projetados com qualidade suficiente para tornar erros genuinamente difíceis de acontecer
se a arquitetura obriga os devs a pensar sobre visibilidade, idempotência e finalidade... não é esse o teste realmente sério para uma blockchain financeira?
#dusk $DUSK @Dusk
