O que é um governance attack em cripto e como podem os protocolos proteger-se?

O que é um governance attack em cripto?

Um governance attack é um ataque em que alguém usa ou toma conta da tomada de decisão de uma DAO ou de um protocolo para executar uma ação (normalmente) prejudicial. Uma DAO é uma organização que toma decisões através de regras em smart contracts e dos votos dos participantes.

Em muitos protocolos, os tokens determinam quanto direito de voto tem cada utilizador. Quem acumula poder de voto suficiente pode, por exemplo, propor alterações às definições, adicionar novas funcionalidades, atualizar a lógica de um contrato ou transferir fundos de uma treasury. Uma treasury é, de forma simples, o fundo comum com recursos de um protocolo.

Nem todo governance attack resulta de um erro de programação. Por vezes, um atacante segue formalmente as regras, mas acumula influência suficiente para fazer aprovar uma proposta prejudicial para outros utilizadores. A isto chama-se governance capture: a tomada de decisão fica, na prática, nas mãos de uma única parte ou de um pequeno grupo.

Uma possível manobra aqui é um flash loan. Trata-se de um empréstimo que tem de ser reembolsado na mesma transação da blockchain. Se um protocolo basear o peso de voto na quantidade atual de tokens numa wallet, sem período de espera ou instantâneo histórico, um atacante pode obter temporariamente muito poder de voto.

Exemplo: Suponha que um protocolo equipara um token a um voto. Alguém pede temporariamente muitos tokens emprestados, vota numa proposta para transferir fundos da treasury e reembolsa o empréstimo de imediato. Se o sistema contar estes tokens temporários, isso pode ser suficiente para influenciar a votação.

Pontos principais

• Um governance attack explora a tomada de decisão de uma DAO ou de um protocolo para executar uma ação prejudicial.
• Em governance ponderado por tokens, o número de tokens determina muitas vezes quanto direito de voto alguém tem.
• Um ataque pode usar uma falha técnica, mas também pode ocorrer dentro das regras existentes.
• Os flash loans podem conceder temporariamente muito poder de voto se um protocolo usar saldos atuais.
• As propostas podem, entre outras coisas, ajustar definições, atualizar contratos ou transferir ativos da treasury.

Como funciona um governance attack?

Um governance attack funciona, normalmente, porque um atacante primeiro acumula poder de voto efetivo suficiente, depois faz aprovar uma proposta prejudicial e, por fim, executa-a. O modo exato depende das regras do protocolo.

O peso de voto pode, por exemplo, resultar dos tokens que possui, dos votos que outros lhe delegam, dos tokens em staking ou de posições de LP. Uma posição de LP é a sua participação num liquidity pool. O ponto crucial é: em que momento o protocolo fixa quanto direito de voto tem?

Muitas vezes, um ataque tem um aspeto aproximado como este:

1. Reunir direito de voto O atacante compra tokens, reúne delegações, usa poder de voto já existente em grande escala ou pede tokens emprestados temporariamente através de um flash loan.

2. Apresentar uma proposta A proposta contém uma ou mais ações que os smart contracts devem executar. Podem ser, por exemplo, alterações às definições, mas também uma atualização ou uma transferência a partir da treasury.

3. Vencer a votação A proposta tem de obter votos suficientes e atingir o quorum exigido. Um quorum é a quantidade mínima de participação necessária para que uma votação seja válida.

4. Executar a ação Após uma votação bem-sucedida, a governance executa as transações planeadas. Sem atraso, isso pode acontecer de imediato. Com um timelock, a ação tem primeiro de esperar.

Um instantâneo histórico ajuda a proteger contra certos ataques com flash loans. Um snapshot é, na prática, uma fotografia dos direitos de voto num momento anterior e fixo. Um voting delay, ou seja, um período de espera antes de os votos contarem, só funciona bem se os tokens emprestados temporariamente não constarem já nesse snapshot.

Beanstalk mostra quão grande pode ser o impacto. Em 17 de abril de 2022, o protocolo foi atacado através de governance on-chain. O atacante usou um flash loan para comprometer o mecanismo de governance da altura e retirar ativos da DAO.

Um snapshot, aliás, não é uma solução completa. Se um atacante já tiver comprado ou controlado os tokens antes do momento escolhido, esse poder de voto conta na mesma.

Que consequências pode ter um governance attack?

Um governance attack pode fazer com que um atacante obtenha dinheiro, direitos ou definições importantes de um protocolo. A gravidade depende inteiramente do que a governance pode efetivamente fazer.

Em alguns protocolos, a governance pode, entre outras coisas, alterar definições do sistema, adicionar novos mercados ou funcionalidades e atualizar partes do protocolo. Se a governance também controlar proxies importantes, componentes de configuração ou contratos da treasury, uma proposta maliciosa pode causar danos significativos.

As possíveis consequências incluem:

• perda de ativos da treasury ou de utilizadores;
• minting indesejado de novos tokens;
• definições alteradas que prejudicam os utilizadores;
• direitos de administração modificados;
• uma atualização para lógica de contrato maliciosa;
• a suspensão temporária ou total de funcionalidades.

No ataque à Beanstalk, em 17 de abril de 2022, todos os ativos de utilizadores que não eram BEAN foram roubados, no valor de cerca de 77 milhões de dólares. Depois disso, o protocolo foi pausado, a governance on-chain foi removida e a estrutura de governance foi alterada.

O dano é muitas vezes maior do que a perda direta. Um protocolo pode ter de migrar para novos contratos, pagar auditorias e trabalho de recuperação e colocar temporariamente mais controlo de emergência nas mãos de um pequeno grupo. Isso pode afetar fortemente a confiança dos utilizadores.

Como pode um protocolo perder o controlo?

Um protocolo perde, na prática, o controlo assim que um atacante tem direitos suficientes sobre os contratos que executam ações críticas. Pense no proprietário de um proxy, numa conta que pode executar atualizações, numa função que pode agendar propostas num timelock ou no controlador da treasury.

Um proxy é, aqui, de forma simples, um endereço de contrato fixo que aponta para uma determinada versão da lógica do contrato. Num protocolo atualizável, a governance pode fazer com que esse endereço aponte para nova lógica. Assim, uma única proposta aprovada pode alterar de forma profunda o funcionamento do protocolo.

Para isso, um atacante nem sempre precisa da maioria de todos os detentores de tokens. Com baixa participação, um quorum baixo ou delegações muito concentradas, um grupo relativamente pequeno pode já ter poder de voto efetivo suficiente.

Após uma execução maliciosa, a recuperação pode tornar-se ainda mais difícil. O atacante pode alterar permissões, desviar ativos ou até modificar as futuras regras de governance. Nessa altura, é possível que a comunidade já não consiga intervir pela mesma via, ou apenas muito mais tarde.

A perda de controlo também pode acontecer sem ataque. Se as contas autorizadas de um timelock autogerido deixarem de estar disponíveis, um contrato gerido por esse timelock pode ficar bloqueado por tempo indeterminado.

Como podem os protocolos de criptomoedas e DeFi proteger-se?

Os protocolos de criptomoedas e DeFi podem reduzir o risco ao não permitir que poder de voto, permissões e execução se concentrem demasiado num único momento. Não existe uma definição mágica que pare todos os ataques, mas várias camadas em conjunto tornam o abuso mais difícil.

As medidas importantes são:

1. Usar snapshots e um voting delay Fixe o peso de voto num momento anterior e introduza um período de espera. Assim, torna-se mais difícil arranjar tokens temporariamente pouco antes de uma votação e usá-los de imediato.

2. Escolher limiares de voto adequados Um mínimo para propostas torna mais difíceis as propostas de spam baratas. Um quorum impede que uma participação muito pequena decida sozinha. A ponderação continua a ser difícil: limiares demasiado baixos facilitam a captura, enquanto limiares demasiado altos podem tornar a governance impraticável.

3. Colocar ações sensíveis atrás de um timelock Atualizações, grandes alterações de parâmetros e ações da treasury não têm de acontecer imediatamente após uma votação. Um timelock dá aos utilizadores tempo para rever uma ação planeada e, se necessário, fechar a sua posição.

4. Limitar direitos por função Não dê à governance poder ilimitado por defeito. Em especial, os direitos de atualização, minting e chamadas externas ilimitadas merecem restrições adicionais. Os direitos de emergência devem estar claramente delimitados.

5. Testar as ações reais das propostas Não basta verificar apenas o módulo de votação. As equipas também devem testar e simular as transações exatas por trás de uma proposta. Uma proposta pode parecer inofensiva em termos gerais, enquanto as chamadas concretas fazem algo muito diferente.

6. Acompanhar propostas e poder de voto A monitorização não impede um ataque por si só, mas pode fazer com que uma proposta suspeita ou uma grande mudança nas delegações seja detetada a tempo. Um plano de incidente previamente acordado ajuda depois a reagir mais depressa.

As auditorias continuam a ser úteis, mas não são garantia. Nem todo governance attack está numa falha no código. Propostas enganosas, baixa participação e transações mal avaliadas também podem causar problemas.

Como podem os timelocks e a governance por multisig ajudar?

Os timelocks e as multisigs podem formar uma camada adicional de segurança, porque impedem que uma única conta aprovada ou comprometida execute tudo de imediato.

Um timelockcontroller impõe um período mínimo de espera entre o agendamento e a execução de uma ação importante. Se o timelock for o administrador de um contrato, esse atraso também se aplica a ações que, de outra forma, poderiam acontecer de imediato com direitos de administração.

Essa janela de reação é importante. Os utilizadores e os investigadores de segurança podem rever os dados exatos da transação antes de a alteração entrar em vigor. Perante uma proposta perigosa, os utilizadores podem, por exemplo, fechar a sua posição antes de a ação ser executada. O timelock não invalida automaticamente uma ação prejudicial, mas retira velocidade a um ataque visível.

Compound v2 usa, por exemplo, várias fases: dois dias de revisão, três dias de votação e depois dois dias de timelock. Assim, uma alteração ao protocolo demora, no mínimo, uma semana.

Uma multisig funciona de forma diferente. Nesse caso, vários proprietários têm de confirmar uma transação. Numa multisig 3 de 5, são necessárias três assinaturas válidas. Uma chave roubada ou comprometida não chega, por si só, para transferir dinheiro ou alterar definições.

Uma multisig pode, por exemplo, ser a única entidade autorizada a agendar ações num timelock. Assim, primeiro um grupo de signatários tem de concordar e só depois começa o período de espera definido.

É importante saber, no entanto, que uma multisig desloca a confiança para os signatários. Se signatários suficientes conspirarem, se demasiadas chaves forem roubadas ou se os signatários não estiverem acessíveis, continuam a surgir problemas. Também os módulos ou extensões adicionais merecem atenção, porque, em certas circunstâncias, podem executar transações fora da verificação normal de assinatura.

Quais são as limitações da governance em cripto?

A governance em criptomoedas pode executar decisões de forma transparente e automática, mas o sistema não sabe, por si só, se uma proposta é também sensata ou justa. Uma votação on-chain válida apenas prova que as regras foram seguidas.

Em governance ponderado por tokens, a influência está ligada ao peso económico. Grandes detentores, fundos e delegates conhecidos podem, por isso, ter muito mais influência do que pequenos participantes, mesmo sem ataque ou erro no código. A delegação facilita o voto, mas pode concentrar o poder num pequeno grupo.

Também a velocidade e a segurança entram por vezes em conflito. Períodos de votação mais longos e timelocks dão mais tempo para avaliar bem as propostas e reagir. Ao mesmo tempo, atrasam atualizações úteis, ajustes e, por vezes, também a resposta a um incidente.

Os quorums e os mínimos para propostas têm a mesma troca. Se forem demasiado baixos, um grupo pequeno mas bem organizado pode tomar decisões. Se forem demasiado altos, as propostas normais podem ficar bloqueadas porque poucas pessoas votam.

Outro problema é a complexidade. Os dados calldata exatos de uma proposta, uma atualização da lógica do contrato ou a interação entre vários smart contracts são difíceis de avaliar para muitos votantes. Assim, uma proposta pode estar correta do ponto de vista processual, enquanto poucas pessoas compreendem realmente o que está a acontecer.

Uma multisig ou um guardian pode reduzir o risco de um ataque rápido, mas também introduz riscos de centralização e disponibilidade. Um guardian é uma conta ou grupo com direitos especiais de emergência. Se essa parte agir de má-fé, não estiver acessível ou bloquear transações, essa camada de segurança pode tornar-se, ela própria, um ponto fraco.

A governance, portanto, não é uma definição que se faz uma vez e depois se esquece. A distribuição de tokens, delegações, direitos, incentivos, controlo de propostas e procedimentos de emergência devem ser revistos regularmente.

Conclusão

Um governance attack não diz respeito apenas a hackers que encontram uma falha técnica. Também uma parte que, segundo as regras, acumula poder de voto suficiente pode colocar um protocolo em dificuldades se a governance tiver direitos excessivos ou executar propostas demasiado depressa.

Uma boa proteção assenta em várias camadas: snapshots, voting delay, limiares adequados, permissões limitadas, controlo das ações das propostas e monitorização. Os timelocks e as multisigs podem acrescentar tempo e controlo extra. No fim, a questão principal continua a ser simples: quem pode alterar o quê e quanto tempo tem o resto para o ver e reagir?