4 月多起 DeFi 攻擊事件後，discussão de segurança na indústria das finanças descentralizadas está a virar de forma clara. No passado, os protocolos DeFi eram mais frequentemente escrutinados quanto a saber se os contratos inteligentes tinham sido auditados e se existiam vulnerabilidades no código; mas Andre Cronje, fundador da Flying Tulip, afirmou recentemente em entrevista à Cointelegraph que o risco de muitos protocolos DeFi atuais já não está apenas no código em cadeia, mas sim nas permissões de upgrade, na governação multisig, na infraestrutura off-chain e nos processos operacionais da equipa.
DeFi já não é apenas código imutável
Cronje foi direto ao ponto: se se olhar para o DeFi inicial com definições rigorosas de “descentralizado, imutável, sem necessidade de confiança”, então muitos protocolos hoje já não podem, na prática, ser chamados DeFi puro. Ele chega mesmo a incluir a Flying Tulip nesta avaliação, dizendo que a indústria atual se parece mais com serviços financeiros lucrativos geridos por equipas do que com infraestruturas públicas totalmente imutáveis.
Disse: “Acho que aquilo que temos hoje, incluindo a Flying Tulip, já não é DeFi. Não é finanças descentralizadas nem código imutável e inviolável; é um negócio lucrativo em que a equipa está a operar.”
Esta afirmação aponta para a realidade mais embaraçosa do setor DeFi: muitos protocolos ainda usam narrativas, modelos de avaliação e linguagem de marca do DeFi, mas na operação real já dependem há muito de controlo humano e de processos off-chain.
O maior risco do DeFi já não é apenas falhas no contrato
Cronje considera que o modelo de segurança do DeFi inicial era relativamente simples: após a implementação do protocolo, os contratos inteligentes eram imutáveis e o utilizador assumia sobretudo o risco lógico do código. Agora, porém, os sistemas DeFi são tipicamente muito mais complexos: um protocolo pode usar proxy upgrade para atualizar contratos, gerir permissões críticas via multisig, depender de fornecedores de infraestrutura externos e, em caso de problemas, contar com a resposta de emergência da equipa central.
Isto significa que os problemas de segurança deixaram de ser apenas “há ou não bugs no código” e passaram a abranger “quem tem permissão para atualizar contratos”, “quem controla o multisig”, “o time lock é suficiente”, “servidores off-chain ou interfaces de gestão podem ser atacados”, “a equipa consegue reagir corretamente em situações anómalas”.
Cronje aponta ainda que a indústria, no passado, continuou a colocar demasiado foco nas auditorias a contratos inteligentes, mas muitos ataques recentes têm mais semelhança com problemas de segurança tradicionais do Web2 ou de TradFi, por exemplo: invasão de acessos a infraestrutura, ataques de engenharia social, processos de gestão abusados ou comprometimento de um único nó de permissão.
Por outras palavras, o DeFi não é algo que dispense auditorias — o problema é que só com auditorias já não chega. Quando um protocolo pode ser atualizado, gerido e receber intervenção humana, tem de admitir que também enfrenta riscos operacionais semelhantes aos das instituições financeiras tradicionais.
Flying Tulip adiciona mecanismo de circuit breaker para levantamentos
Neste contexto, a Flying Tulip incorporou recentemente um mecanismo de circuit breaker para levantamentos (withdrawal circuit breaker), permitindo que o protocolo, ao detetar saídas anómalas de fundos, atrase ou coloque em fila o processamento de levantamentos. Cronje salienta que este mecanismo não serve para bloquear permanentemente os levantamentos dos utilizadores, nem para a equipa congelar fundos arbitrariamente; serve antes para ganhar uma janela curta de resposta do protocolo em situações anómalas.
No caso da Flying Tulip, este mecanismo poderá dar à equipa cerca de 6 horas. Cronje considera que, se a dimensão da equipa for menor e os membros não estiverem suficientemente globalizados, podem ser necessárias 12 a 24 horas, ou mesmo mais tempo, para concluir as confirmações internas, assinaturas e respostas quando um ataque ocorrer.
A lógica deste tipo de desenho assemelha-se muito à pausa de transações ou às portas de controlo de risco nos mercados financeiros tradicionais: quando há mobilidade de liquidez ou saídas de ativos anómalas, não se conclui imediatamente que todas as transações são inválidas; primeiro, abranda-se o sistema para evitar que um atacante consiga retirar todo o capital em poucos minutos.
Ainda assim, Cronje reforça que o mecanismo de circuit breaker apenas pode ser uma parte de uma arquitetura de segurança em camadas, não podendo ser encarado como uma solução milagrosa. A proteção real tem de incluir auditorias, multisig distribuído, time locks, processos de governação, mecanismos de monitorização e controlo de permissões.
O custo do mecanismo de circuit breaker: proteger utilizadores ou criar uma nova porta traseira centralizada?
No entanto, o mecanismo de circuit breaker também desencadeou imediatamente uma disputa de linhas no seio da comunidade de desenvolvedores DeFi. O fundador da Curve Finance e da Yield Basis, Michael Egorov, concorda que ataques recentes expuseram efetivamente o risco de centralização off-chain, mas demonstra forte cautela face à solução de “aumentar controlo de emergência humano”.
Egorov assinala que muitos eventos DeFi recentes de grande escala não resultaram de contratos inteligentes terem sido comprometidos em si mesmos, mas sim de falhas críticas de um único ponto off-chain. Ele cita o caso relacionado com rsETH para exemplificar e diz que os contratos inteligentes de Aave, Kelp e LayerZero não foram hackeados; o problema real esteve na infraestrutura off-chain.
Assim, para Egorov, se o maior risco já vem de pessoas e permissões off-chain, então ao adicionar um mecanismo de circuit breaker controlado por humanos, pode ser apenas mais uma forma de concentrar ainda mais poder nas mãos de poucos signatários ou gestores.
Egorov receia que, se as permissões de controlo de emergência permitirem que signatários modifiquem contratos, suspendam levantamentos ou interfiram no fluxo de fundos, então, caso os signatários sejam alvo de um ataque, o mecanismo que supostamente deveria proteger os utilizadores possa, em vez disso, transformar-se numa ferramenta para drenar fundos para fora por parte de hackers, ou numa porta traseira para congelar ativos de forma centralizada. A sua conclusão é que o design do DeFi deve reduzir ao máximo falhas críticas de um único ponto humano, e não resolver problemas causados por poder humano a mais com mais permissões humanas.
DeFi tem de admitir em que se tornou
As divergências entre Cronje e Egorov, à superfície, são uma disputa sobre o mecanismo de circuit breaker; na prática, é uma disputa de identidade do DeFi. A perspetiva de Cronje é mais pragmática: já que muitos protocolos não são contratos imutáveis e possuem permissões de upgrade, processos de gestão e produtos financeiros operados por equipas, então deve reconhecer-se esta realidade e implementar níveis adequados de controlo de risco.
Egorov está mais próximo dos tradicionalistas do DeFi: se a segurança do DeFi advém da descentralização, então a solução não deve consistir em entregar ainda mais controlo às pessoas, mas sim desenhar sistemas que dependam menos de intervenção humana.
Ambos reconhecem, no fundo, a mesma coisa: o maior problema do DeFi já não é apenas se o código do contrato foi escrito bem ou não; é em quem é que os utilizadores realmente confiam. Se um protocolo pode ser atualizado, pode ser pausado, pode enfileirar levantamentos e pode, através de multisig, alterar a lógica central, então o risco que o utilizador assume já não é apenas o risco de contrato inteligente — é também o risco de governação da equipa, o risco dos signatários, o risco da infraestrutura e o risco operacional.
Esta notícia DeFi ainda é descentralizada? Andre Cronje: admita-se que sim, a maioria dos protocolos são códigos modificáveis É a primeira vez que aparece em 鏈新聞 ABMedia.
