#dusk $DUSK Hoje estou pesquisando a VM virtual Piecrust do @Dusk e surgiu uma pergunta que não sai da minha cabeça: se o DuskEVM for compatível com Ethereum, qual é a diferença entre ele e aquelas dezenas de cadeias compatíveis com EVM do mercado? No fim das contas, não é para permitir que desenvolvedores de Solidity migrem? Quando analisei a lógica de design do Piecrust, entendi que essa “compatibilidade” vai muito mais fundo do que eu imaginava.
A maioria das cadeias compatíveis com EVM faz algo como “se der para rodar contratos do Ethereum, então está compatível”, tratam a compatibilidade como uma opção de funcionalidade. Mas o Piecrust tem um posicionamento totalmente diferente — ele roda em uma cadeia de privacidade baseada em UTXO, na qual um ambiente de execução EVM é embutido nativamente. Isso significa que contratos escritos em Solidity podem chamar diretamente as funções nativas de privacidade do Dusk: no nível do contrato, você consegue manipular notes criptografadas, acionar a geração e a verificação de provas de conhecimento zero e ler/escrever o estado privado do Phoenix. Isso não é “rodar EVM em uma cadeia transparente”; são espécies completamente diferentes.
Isso me lembrou uma conversa que tive há um mês com um amigo que trabalha com DeFi. Ele disse que o time quer fazer negociações de dark pool de nível institucional na cadeia. O maior obstáculo não é o algoritmo de matching, e sim o fato de que o próprio smart contract não consegue lidar, ao mesmo tempo, com “privacidade de posição” e “divulgação seletiva”. Em uma cadeia pública, qualquer coisa que você escreve é transparente; numa cadeia de privacidade, por outro lado, não dá para executar uma lógica de contrato complexa. Se o design do Piecrust conseguir ser implementado de verdade, ele vira uma ponte entre “privacidade” e “programabilidade”: não é “uma ou outra”, é “as duas”.
Mas o custo também está claro: a complexidade dessa arquitetura é uma ordem de grandeza maior do que a de uma cadeia EVM comum. Depois que o desenvolvedor entra, só para entender o ciclo de vida dos UTXOs das notes e a lógica de consumo dos nullifiers já exige bastante tempo; além disso, o atrito do cold start do ecossistema é considerável.
Deixamos um pouco de “reserva” no fundo (fundos parados), e a força principal fica para ver, quando saírem os primeiros protótipos de DeFi rodando no Piecrust, os dados reais de consumo de gas e desempenho.
O que vocês acham: essa combinação de “privacidade + programabilidade” é uma necessidade real para desenvolvedores de DeFi ou é um falso problema? Digam nos comentários. @Dusk $BTC