Como foi relatado esta semana, um endereço associado à exploração da FTX tem movimentado fundos através de uma série de projetos cross-chain.
Embora a maioria dos fundos tenha passado pelo Thorchain, alguns deles foram encaminhados pelo tBTC. No processo, dois bugs foram expostos.
Nenhum dos bugs coloca os fundos dos usuários em risco. O primeiro foi corrigido e lançado ontem, enquanto o segundo requer discussão e consenso da comunidade.
O primeiro bug – um vetor de negação de serviço
No sábado, 30 de setembro, um endereço associado à FTX solicitou o resgate de 76.81431578 BTC.
No tBTC hoje, os resgates podem ser solicitados por qualquer usuário com um saldo L1 tBTC. Depois de algum tempo, um mantenedor off-chain delegado pelo Threshold DAO no
Coordenador de Carteira
contrato verifica uma solicitação de resgate, levando os signatários a considerarem uma solicitação de resgate válida. Se 51 de 100 signatários de uma carteira específica concordarem, eles assinam e liberam esses fundos em conjunto no blockchain do Bitcoin.
Depois de algum tempo, essa solicitação de resgate foi aprovada pelo mantenedor dos resgates. Pelo menos 51 dos signatários na carteira associada concordaram, e o resgate foi concluído.
9 horas depois, um endereço diferente associado à exploração da FTX solicitou outro resgate — desta vez por 76.62186419 BTC.
Pouco depois, algo incrível aconteceu.
Um terceiro desconhecido enviou transações de BTC para duas das carteiras por trás do tBTC.
Agora, isso acontece o tempo todo — afinal, o tBTC é cunhado depositando BTC. Mas, em vez de uma transação de depósito normal, essas transações foram criadas manualmente de tal forma que os clientes assinantes do tBTC pensaram que as carteiras estavam "ocupadas" movimentando fundos e incapazes de atender às solicitações de resgate. O mantenedor da aprovação esperou que as carteiras não estivessem mais "ocupadas" — o que nunca aconteceu.
Efetivamente, essas transações de BTC bloquearam todos os resgates de tBTC pendentes.
Não sabemos quem enviou essas transações. Mas quem quer que tenham sido, sabiam o suficiente para pausar à força a ponte tBTC, queimando um simples exploit de 0-day no processo e impedindo que o segundo resgate associado à FTX fosse aprovado.
Essa é uma novidade para mim. Nenhum white hats entrou em contato, ninguém ofereceu nenhuma explicação — mas o timing é incrível.
Nesse ponto, os sistemas de alerta e monitoramento usados pelos contribuidores em todo o DAO estavam a todo vapor. A equipe de desenvolvimento do Keep começou a preparar um patch para consertar a negação de serviço no fim de semana.
Naquela época, também percebemos que um dos resgates bloqueados estava associado à FTX.
O segundo bug — falha no projeto do mecanismo de resgate
O segundo bug ficou aparente enquanto preparávamos o primeiro patch.
O Threshold DAO pode delegar para vários endereços de aprovadores no
Coordenador de Carteira
contrato.
Infelizmente, até hoje, houve apenas uma delegação para um único endereço de mantenedor — um único ponto de falha. Hoje, esse endereço é controlado por uma empresa de propriedade dos EUA, impedida de aprovar o resgate associado à FTX.
Corrigindo o design do mecanismo
Ter apenas um único aprovador delegado com $25M em TVL foi um descuido. Ainda assim, o problema maior é o design do mecanismo em si.
Qualquer sistema que dependa da aprovação explícita de um resgate está fadado a ter outro problema como esse. Quando o protocolo foi lançado pela primeira vez, a justificativa para um mecanismo de aprovação era velocidade e facilidade de uso — alternativas significavam uma experiência de usuário pior.
Não acredito que o sistema atual tenha feito as escolhas certas.
Existem duas abordagens claras para corrigir esta falha
Passe de um fluxo baseado em aprovação para um fluxo baseado em veto
Remover todas as revisões de resgate no nível do protocolo
Acredito que o design de mecanismo mais seguro, daqui para frente, é algo que chamo de "resgates otimistas". Em vez de uma lista de endereços que finalizam os resgates, temos uma lista de endereços que podem vetar um resgate — semelhante ao papel do Guardian na cunhagem otimista.
Com esse mecanismo em vigor, todos os resgates são válidos por padrão. Se um resgate for vetado devido a uma suspeita de hack de ponte, ele pode ser adiado. Se for vetado por guardiões suficientes, ele pode voltar para uma votação do detentor do token. Se o veto for mantido por uma votação do detentor do token, o resgate de tBTC rejeitado pode ser automaticamente devolvido ao usuário que o resgatou.
A desvantagem é que esse mecanismo hipotético requer um atraso adicional para cada resgate. Com o tempo, porém, esse atraso pode ser reduzido para apenas 15 minutos e totalmente dispensado para transações pequenas.
Finalmente, se e quando a comunidade julgar o sistema seguro sem um período de revisão de resgate, ela poderia eliminar o atraso completamente, migrando suavemente da primeira abordagem para a segunda. Na verdade, acho que um cronograma claro para remover a revisão de resgate ajudaria a construir confiança em toda a comunidade.
Seja qual for a maneira como essa falha de design do mecanismo for resolvida, aprendemos muito com essa experiência — e estou feliz por termos aprendido isso esta semana, em vez de 10 vezes mais aqui.
O que vem depois?
O DAO e a comunidade têm decisões a tomar.
Quer a comunidade decida adicionar outro endereço de aprovador, atualizar os contratos para um mecanismo de "resgate otimista" ou pesquisar e considerar outras opções, como uma equipe de desenvolvimento, estamos aqui para aconselhar e ajudar a construir um futuro financeiro mais robusto, seguro e neutro, juntos.