No fim de semana, fui ao café embaixo de casa para “dar uma chance” ao ar-condicionado durante os testes da rede do Dusk, sentei e esperei — depois errei a senha três vezes seguidas. Foi preciso quase meia hora só para concluir a 21ª transação. Fiquei encarando por um bom tempo os logs de execução da máquina virtual Rusk; antes eu já tinha brincado com algumas antigas cadeias privadas: ou travavam por horas sem produzir blocos, ou faziam anonimato até o último nível de conformidade, de modo que não dava para abrir permissões de auditoria. No fim, eu já não tinha nenhuma expectativa com esses “blockchains de privacidade” — até cair na armadilha com as minhas próprias mãos e perceber que isto não é só uma carcaça para炒 conceito.
No começo, eu considerei o consenso SBA como uma espécie de PoS com outra pele. Depois de revisar as regras dos nós e rodar dez mil simulações de double-spend, só então entendi: o SBA (Segregated Byzantine Agreement, Acordo Bizantino Segregado) divide os nós em duas camadas. Uma camada é o comitê de produção de blocos, responsável por empacotar transações; a outra é o conjunto de validadores de amostragem, que realiza auditorias aleatórias. A semente dessas amostragens é gerada por um VDF (função de atraso verificável), então ninguém consegue prever antecipadamente quem será verificado. O navegador da testnet mostrou que havia 3 nós que perderam seus depósitos por enviarem blocos inválidos: dois foram punidos “suavemente” — faltaram alguns blocos, então foram removidos temporariamente da fila de consenso, e o valor de staking efetivo foi reduzido; o outro foi punido “duro” — foi pego em dupla assinatura (double-sign), e os tokens de staking foram diretamente reduzidos em 20% e destruídos. Mecanismos de punição como esses elevam bastante o custo de agir mal, e o preço de tentativa e erro é enorme.
Durante os testes de transações, por engano eu coloquei um 0 a mais. O valor imediatamente saiu do intervalo permitido pelo Range Proof, e a transação foi rejeitada instantaneamente, sem deixar nem sequer rastro de “transação inútil” na cadeia. O Range Proof do protocolo Phoenix “trava” rigidamente o intervalo de valores de transação; em combinação com o compromisso Pedersen, ele fixa a quantidade total de ativos de cada operação, impedindo criação “do nada”. Além disso, usando Stealth Address descartável (endereços furtivos renovados automaticamente a cada transação), eu consegui fazer 5 transferências de teste consecutivas: na cadeia, nem dá para associar essas 5 transações à mesma conta. As provas PLONK de agregação recursiva ficam comprimidas em 287 bytes; a verificação de cada transação leva apenas 1,8 ms. Rodar foi bem tranquilo, e também não encontrei congestionamento durante o pico da testnet.
A máquina virtual Rusk foi escrita do zero totalmente em Rust; ela suporta nativamente o padrão de ativos confidenciais. Ao implantar meu Token de teste, nem precisei escrever código de privacidade — nem chegava a 200 linhas. O Gas para rodar contratos ficou 63% menor do que quando se usa um ZK “por cima” no EVM, e ainda deixou uma porta de entrada de permissões de auditoria para o lado da conformidade. Privacidade e conformidade não precisam ser “ou uma coisa ou outra”; dá para ter as duas. Naquela noite em que a testnet terminou de rodar, eu fiquei bem mais tranquilo do que em qualquer projeto que eu tenha investido junto anteriormente.
#dusk $DUSK @Dusk
No começo, eu considerei o consenso SBA como uma espécie de PoS com outra pele. Depois de revisar as regras dos nós e rodar dez mil simulações de double-spend, só então entendi: o SBA (Segregated Byzantine Agreement, Acordo Bizantino Segregado) divide os nós em duas camadas. Uma camada é o comitê de produção de blocos, responsável por empacotar transações; a outra é o conjunto de validadores de amostragem, que realiza auditorias aleatórias. A semente dessas amostragens é gerada por um VDF (função de atraso verificável), então ninguém consegue prever antecipadamente quem será verificado. O navegador da testnet mostrou que havia 3 nós que perderam seus depósitos por enviarem blocos inválidos: dois foram punidos “suavemente” — faltaram alguns blocos, então foram removidos temporariamente da fila de consenso, e o valor de staking efetivo foi reduzido; o outro foi punido “duro” — foi pego em dupla assinatura (double-sign), e os tokens de staking foram diretamente reduzidos em 20% e destruídos. Mecanismos de punição como esses elevam bastante o custo de agir mal, e o preço de tentativa e erro é enorme.
Durante os testes de transações, por engano eu coloquei um 0 a mais. O valor imediatamente saiu do intervalo permitido pelo Range Proof, e a transação foi rejeitada instantaneamente, sem deixar nem sequer rastro de “transação inútil” na cadeia. O Range Proof do protocolo Phoenix “trava” rigidamente o intervalo de valores de transação; em combinação com o compromisso Pedersen, ele fixa a quantidade total de ativos de cada operação, impedindo criação “do nada”. Além disso, usando Stealth Address descartável (endereços furtivos renovados automaticamente a cada transação), eu consegui fazer 5 transferências de teste consecutivas: na cadeia, nem dá para associar essas 5 transações à mesma conta. As provas PLONK de agregação recursiva ficam comprimidas em 287 bytes; a verificação de cada transação leva apenas 1,8 ms. Rodar foi bem tranquilo, e também não encontrei congestionamento durante o pico da testnet.
A máquina virtual Rusk foi escrita do zero totalmente em Rust; ela suporta nativamente o padrão de ativos confidenciais. Ao implantar meu Token de teste, nem precisei escrever código de privacidade — nem chegava a 200 linhas. O Gas para rodar contratos ficou 63% menor do que quando se usa um ZK “por cima” no EVM, e ainda deixou uma porta de entrada de permissões de auditoria para o lado da conformidade. Privacidade e conformidade não precisam ser “ou uma coisa ou outra”; dá para ter as duas. Naquela noite em que a testnet terminou de rodar, eu fiquei bem mais tranquilo do que em qualquer projeto que eu tenha investido junto anteriormente.
#dusk $DUSK @Dusk
