Após vários incidentes de ataques DeFi em abril, o debate sobre segurança na indústria de finanças descentralizadas está ficando cada vez mais evidente. No passado, a maioria dos protocolos DeFi era mais frequentemente analisada quanto a auditorias de contratos inteligentes e à existência de vulnerabilidades no código; mas Andre Cronje, fundador da Flying Tulip, disse recentemente em entrevista ao Cointelegraph que, hoje, os riscos de muitos protocolos DeFi já não estão apenas no código executado na blockchain, e sim nas permissões de upgrade, na governança via multisig, na infraestrutura off-chain e nos processos operacionais da equipe.
DeFi já não é código imutável
Cronje disse sem rodeios que, ao observar a definição estrita do DeFi inicial — “descentralizado, imutável, sem necessidade de confiança” —, muitos protocolos atuais na verdade já não podem mais ser chamados de DeFi puro. Ele até inclui a Flying Tulip nessa avaliação, afirmando que a indústria atual se parece mais com serviços financeiros lucrativos operados por equipes do que com uma infraestrutura pública totalmente imutável.
Ele afirmou: “Acho que o que temos hoje, incluindo a Flying Tulip, já não é DeFi. Não é finanças descentralizadas e não é código imutável; é um negócio lucrativo operado por uma equipe.”
Essa declaração evidencia a realidade mais desconfortável do setor: muitos protocolos ainda usam a narrativa, a precificação e a linguagem de marca do DeFi, mas, na prática, há muito tempo dependem de bastante controle humano e de processos off-chain.
O maior risco do DeFi já não é apenas bug em contrato
Cronje acredita que o modelo de segurança do DeFi no início era relativamente simples: após o deploy do protocolo, os contratos inteligentes eram imutáveis, e os usuários assumiam principalmente o risco da lógica do código. Mas agora, os sistemas DeFi normalmente são bem mais complexos: o protocolo pode usar proxy upgrade para atualizar contratos, gerenciar permissões críticas por meio de multisig, depender de fornecedores externos de infraestrutura e, em caso de problema, contar com a equipe central para agir na resposta a crises.
Isso significa que as questões de segurança deixaram de ser apenas “o código tem algum bug” e passaram a abranger “quem tem permissão para atualizar o contrato”, “quem controla o multisig”, “o timelock é suficiente”, “servidores ou interfaces de gerenciamento off-chain podem ser atacados”, “a equipe consegue reagir corretamente em situações anormais”.
Cronje também apontou que a indústria no passado ainda dava atenção demais às auditorias de contratos inteligentes, mas ataques recentes têm mais semelhança com problemas de segurança tradicionais do Web2 ou TradFi, como invasão de permissões de acesso a infraestrutura, ataques de engenharia social, processos de gerenciamento sendo abusados, ou um comprometimento de um único nó de permissão.
Em outras palavras, o DeFi não é algo que não precise de auditorias; é apenas que confiar somente em auditorias já não é suficiente. Quando um protocolo pode ser atualizado, pode ser gerenciado e pode ser alvo de intervenção humana, ele precisa admitir que também enfrenta riscos operacionais que instituições financeiras tradicionais enfrentariam.
Flying Tulip adiciona mecanismo de circuit breaker para saques
Nesse contexto, a Flying Tulip adicionou recentemente um mecanismo de circuit breaker de saques (withdrawal circuit breaker), permitindo que, ao detectar fluxos anormais de saída de fundos, o protocolo atrase ou coloque em fila o processamento dos saques. Cronje ressaltou que esse mecanismo não existe para impedir permanentemente os usuários de sacar, nem para a equipe congelar fundos arbitrariamente; é para abrir uma janela curta de resposta do protocolo em situações anormais.
No caso da Flying Tulip, essa medida pode dar à equipe cerca de 6 horas de tempo. Cronje acredita que, se o tamanho da equipe for menor e a distribuição dos membros não for suficientemente globalizada, pode ser necessário de 12 a 24 horas, ou até mais, para concluir confirmações internas, assinaturas e ações de contingência durante um ataque.
A lógica desse tipo de desenho é parecida com a paralisação de negociações ou as “portas” de controle de risco nos mercados financeiros tradicionais: quando o sistema apresenta liquidez anormal ou fuga de ativos, não se conclui imediatamente que todas as transações são inválidas; primeiro, o sistema desacelera para evitar que o atacante leve todos os fundos em poucos minutos.
No entanto, Cronje também enfatizou que o circuit breaker só pode ser parte de uma arquitetura de segurança em camadas, não devendo ser visto como uma solução mágica. A proteção real ainda precisa incluir auditorias, multisig distribuído, time locks, processos de governança, mecanismos de monitoramento e controle de permissões.
O custo do circuit breaker: proteger usuários ou criar novas “portas” de centralização?
Ainda assim, o mecanismo de circuit breaker gerou imediatamente uma disputa de linha entre desenvolvedores da comunidade DeFi. O fundador da Curve Finance e da Yield Basis, Michael Egorov, concordou que ataques recentes realmente expuseram riscos de centralização off-chain, mas ele está altamente cauteloso em relação à solução de “aumentar controles de emergência humanos”.
Egorov apontou que muitos eventos DeFi relevantes recentes não ocorreram porque contratos inteligentes em si foram invadidos, e sim por falhas pontuais off-chain. Ele citou, por exemplo, um incidente relacionado a rsETH, dizendo que os contratos inteligentes da Aave, da Kelp e da LayerZero não foram hackeados; o problema real estava na infraestrutura off-chain.
Portanto, na visão de Egorov, se o maior risco sempre vem de pessoas e de permissões off-chain, adicionar um mecanismo de circuit breaker controlado por pessoas pode ser apenas concentrar mais poder nas mãos de poucos signatários ou administradores.
Egorov teme que, se a autoridade de controle de emergência permitir que os signatários modifiquem contratos, suspendam saques ou intervenham nos fluxos de fundos, então um mecanismo que deveria proteger os usuários pode, na prática, virar uma ferramenta para o hacker drenar os fundos, ou se tornar uma “porta” para o congelamento centralizado de ativos. Sua conclusão é que o design do DeFi deve reduzir o máximo possível falhas humanas de ponto único, em vez de usar mais permissões humanas para resolver problemas causados por permissões humanas.
DeFi precisa admitir no que está se tornando
A divergência entre Cronje e Egorov, à primeira vista, parece uma disputa sobre circuit breaker; na prática, é uma disputa sobre identidade do DeFi. A posição de Cronje é mais pragmática: se muitos protocolos já não são contratos imutáveis, mas produtos financeiros com permissões de upgrade, processos de governança e operações de equipe, então deve-se admitir essa realidade e implementar controles de risco adequados.
Egorov, por outro lado, se aproxima mais do DeFi original: se a segurança do DeFi vem da descentralização, então a solução não deveria ser entregar mais controle às pessoas; deveria ser projetar sistemas que dependam de menos intervenções manuais.
Os dois, no fundo, reconhecem a mesma coisa: o maior problema do DeFi agora não é apenas se o código do contrato está bem escrito, e sim em quem os usuários realmente confiam. Se um protocolo pode ser atualizado, pode ser pausado, pode ter saques enfileirados e pode alterar a lógica central via multisig, então o risco assumido pelo usuário deixa de ser apenas o risco do contrato inteligente, passando a incluir riscos de governança da equipe, de signatários, de infraestrutura e de operação.
Este artigo: o DeFi ainda é descentralizado? Andre Cronje: admita, a maioria dos protocolos é código mutável
Apareceu pela primeira vez em: Cadeia de Notícias ABMedia.
