Estou analisando a documentação de bridging da DuskEVM e percebi um aviso que é repetido inúmeras vezes.
Atualmente, o bridging só suporta a testnet DUSK.
Isso não é uma limitação técnica.
É porque a publicação de estado, a maturidade das provas e a janela de controvérsia ainda precisam de tempo para validação.$BTC
Isso me fez pensar num problema mais realista: o fato de a testnet funcionar não significa que a mainnet possa ser usada.
Na arquitetura em camadas de @Dusk , o DuskDS é responsável por consenso e settlement; o DuskEVM usa o OP Stack para fornecer compatibilidade com EVM. Entre os dois, a ponte transmite mensagens e ativos. Em teoria, desenvolvedores podem implantar contratos Solidity diretamente no DuskEVM e começar rapidamente com uma toolchain familiar.
Mas o bridging não acontece instantaneamente.
Depósitos precisam esperar a confirmação do DuskDS; saques precisam esperar a publicação do estado na L1, o envio das provas e o término do período de disputa. Se algum aplicativo DeFi precisar de arbitragem de alta frequência ou liquidação rápida, essas latências podem ser toleradas? Se uma mensagem entre camadas travar em algum estágio, quem assume a responsabilidade, como se restaura, e as perdas do usuário serão de quem?
O mais importante, porém, é a liquidez.
Na testnet, dá para cunhar moedas à vontade; na mainnet, cada transação $DUSK tem um custo real. Se, quando o DuskEVM entrar no ar, a liquidez dentro da ponte for insuficiente, os usuários até conseguem depositar facilmente, mas podem ter dificuldade para retirar, ou enfrentar tempos de fila longos para saques. Mesmo a melhor compatibilidade pode não ser suficiente para manter aplicações.
Quando verifiquei o roadmap de #dusk , o cronograma de auditoria do contrato do bridging e de implantação na mainnet ainda não está claro. Não é que a tecnologia não seja capaz; do teste até a produção, ainda existem várias etapas: operação, monitoramento, tratamento de exceções e orientação de liquidez.
Então, ao acompanhar o progresso da DuskEVM agora, eu não vou perguntar apenas “dá para implantar contrato?”.
Eu me preocupo com três pontos de conversão: a proporção de migração de aplicações da testnet para a mainnet, o tamanho inicial da liquidez do bridging e o mecanismo de reposição, e a velocidade real de resposta quando ocorrerem exceções entre camadas.
Compatibilidade com EVM reduz o custo de entrada; mas para manter desenvolvedores e usuários, é preciso que a ponte seja estável, o dinheiro circule rápido e que exista alguém cuidando dos problemas.
No fim, essa distância é realmente apenas uma questão de tempo?
#dusk @Dusk $DUSK