No mundo em constante evolução do DeFi, garantir a estabilidade e segurança do protocolo é essencial. Durante uma revisão de segurança recente de um projeto CDP, observei como vulnerabilidades específicas podem surgir em determinadas configurações. Embora as configurações de parâmetros atuais deste projeto sejam robustas, entender esses riscos potenciais é crucial para manter a integridade do protocolo.
Este artigo tem como objetivo explorar o papel crítico que as taxas de empréstimo único e as taxas de resgate desempenham nesse contexto. Ao examinar cenários específicos de exploração que poderiam surgir sem essas taxas, demonstrarei como uma estrutura de taxas adequada é essencial para prevenir ataques de desestabilização, garantindo assim a segurança e viabilidade de longo prazo do protocolo.
Tirando inspiração de um dos protocolos originais, Liquity, e suas derivadas, muitos modelos de CDP (Posição de Dívida Colateralizada) geram stablecoins descentralizadas por meio de supercolateralização. Esses modelos frequentemente incorporam um conjunto complexo, porém sofisticado, de mecanismos projetados para manter a paridade com o dólar americano, garantindo a segurança do protocolo em diversas condições, minimizando efetivamente o risco de dívidas ruins. Esses protocolos se distinguem por meio de customizações-chave, incluindo incentivos econômicos personalizados que se alinham mais de perto com os objetivos específicos do protocolo.
A taxa de resgate é uma taxa aplicada quando um usuário resgata a stablecoin do protocolo pelo seu colateral subjacente. Essa taxa é projetada para estabilizar o valor da stablecoin tornando o processo de resgate mais caro quando os resgates são frequentes, evitando assim resgates excessivos que possam desestabilizar o protocolo.
A taxa de resgate é calculada com base na baseRate do protocolo, um parâmetro de ajuste dinâmico que reflete a atividade recente dentro do sistema. Especificamente, a baseRate aumenta a cada resgate, tornando os resgates subsequentes mais caros.
Esse aumento é proporcional à fração do fornecimento total de stablecoin que é resgatada. Com o tempo, se nenhum resgate ocorrer, a taxa base gradualmente decai de volta a zero, com uma meia-vida de aproximadamente 12 horas.
A taxa de resgate é calculada usando a fórmula:
Por exemplo, se a taxa base for de 1% e um usuário resgatar 100 stablecoins quando o preço do colateral for $50,000, a taxa de resgate seria:
Assim, o usuário receberia um pouco menos de garantia após contabilizar a taxa de resgate. Esse mecanismo garante que os resgates permaneçam economicamente sensatos enquanto protegem o protocolo de atividades de arbitragem desestabilizadoras.
A taxa de empréstimo é outra taxa única que é cobrada quando um usuário toma empréstimo de stablecoins contra sua garantia. Essa taxa é baseada de forma semelhante na taxa base, mas se aplica no momento em que as stablecoins são retiradas do Tesouro do usuário (um contrato de cofre que mantém a garantia e a dívida do usuário).
A taxa de empréstimo é calculada da seguinte forma:
Por exemplo, se um usuário deseja pegar emprestado 4.000 stablecoins e a taxa base for definida em 0,5%, a taxa seria:
Esta taxa é adicionada à dívida do usuário, o que significa que sua dívida total seria o valor emprestado mais a taxa (por exemplo, 4.000 stablecoins + 20 stablecoins = 4.020 stablecoins).
Essas taxas também funcionam como uma espécie de âncora, influenciando indiretamente o preço de mercado da stablecoin, tornando-a menos atrativa para empréstimos ou resgates em certas condições, ajudando assim a manter a stablecoin próximo de $1.
Agora, vamos explorar o que poderia acontecer se essas taxas cruciais fossem removidas ou definidas como zero.
Sem uma taxa de resgate única, o protocolo poderia se transformar inadvertidamente em uma troca de DEX sem deslizamento. Nesse cenário, grandes detentores de stablecoins poderiam explorar o mecanismo de resgate para trocar stablecoins por garantias sem incorrer em custos significativos, efetivamente realizando negociações de arbitragem em grande escala. Isso poderia levar a vários resultados negativos, pois nesse ambiente sem deslizamento, resgates em grande escala não apenas drenariam a liquidez do protocolo, mas também forçariam os mutuários a vender suas garantias pelo preço de mercado atual. Embora sua dívida seja reduzida de acordo, essa liquidação forçada poderia aumentar os custos operacionais para os usuários, especialmente se a stablecoin estiver sendo negociada abaixo de $1.
Além disso, existe o risco de pré-execução do oracle: se um usuário perceber que uma transação está prestes a atualizar o oracle de preço do colateral para refletir um preço mais alto, ele poderia rapidamente resgatar uma grande quantidade de stablecoin antes da atualização do preço. Uma vez que o preço do colateral é atualizado e aumenta, o usuário poderia então vender o colateral resgatado com lucro, completando um ciclo de arbitragem. Essa prática não só explora o protocolo, mas também deixa os mutuários em desvantagem, pois eles podem ser forçados a vender seu colateral a preços menos favoráveis.
Um dos cenários de exploração mais diretos envolve a manipulação da taxa de resgate para reduzir os custos. Em protocolos onde não há taxa de empréstimo única, os usuários podem pegar grandes quantidades de stablecoin, inflando artificialmente a dívida total do protocolo. Uma vez que a dívida é inflada, eles podem resgatar suas stablecoins com uma taxa menor, já que a taxa de resgate é calculada com base na proporção do tamanho do resgate em relação à dívida total.
Esta manipulação mina a estrutura de taxas pretendida do protocolo, levando a uma redução na receita do protocolo e potencialmente desestabilizando o sistema. Por exemplo, os atacantes podem usar empréstimos flash para pedir emprestado grandes quantidades de garantias, que então usam para criar uma quantidade substancial de stablecoins, aumentando assim a dívida total do sistema. Eles então realizam uma operação de resgate, beneficiando-se da taxa reduzida devido à dívida inflacionada, e finalmente pagam o empréstimo flash, deixando o protocolo com menos receita do que o esperado e podendo levar a mais instabilidade para aqueles usuários que não anteciparam serem alvos de resgate.
Outra vulnerabilidade crítica surge da capacidade de forçar o protocolo a entrar no Modo de Recuperação em um único bloco, possibilitando a liquidação de posições com índices de garantia anteriormente saudáveis. Esse exploit depende do uso de empréstimos instantâneos e do timing do ataque em torno de uma atualização de preço do oráculo.
O ataque se desenrola da seguinte forma:
O atacante primeiro usa um empréstimo relâmpago para pegar emprestado uma grande quantidade de garantia, que é então depositada como garantia no protocolo. Usando essa garantia, o atacante toma emprestado stablecoins na Razão de Garantia Mínima (MCR). O atacante pode tomar essa ação para diminuir a Razão de Garantia Total (TCR) para 150%, o limite para acionar o Modo de Recuperação.
O atacante aguarda uma atualização do oráculo que reflita uma queda no preço do colateral. À medida que o novo preço mais baixo é atualizado no sistema, o valor do colateral cai, fazendo com que o TCR caia abaixo de 150%.
Com o TCR agora abaixo de 150%, o protocolo entra automaticamente no Modo de Recuperação. Nesse estado, o protocolo permite a liquidação de Troves com Índices de Colateral (CR) abaixo do novo TCR. O atacante pode então proceder à liquidação de Troves de outros usuários que agora têm um CR abaixo do TCR, causando prejuízos a eles e lucrando com as recompensas de liquidação.
Construindo sobre o cenário de ataque anterior, este exploit avançado permite que um invasor force o protocolo a entrar no Modo de Recuperação através de um processo de resgate cuidadosamente elaborado. Ao contrário do ataque anterior, que pode temporariamente retornar o sistema ao modo normal após a liquidação, este método garante que o sistema permaneça no Modo de Recuperação, permitindo que o invasor explore repetidamente a vulnerabilidade.
A questão central, que surge quando o sistema suporta múltiplos tipos de garantia, cada um gerenciado por diferentes Gerentes de Reserva, reside na potencial diminuição da Razão Total de Garantia (RTG) em todo o sistema após um resgate, mesmo que a saúde individual dos Gerentes de Reserva melhore. Este resultado contra-intuitivo é resultado da complexa interação entre as razões de garantia global e local.
Por exemplo, considere um cenário em que o TCR do sistema é de 150%.
Se um usuário resgatar contra uma Trove com uma taxa de garantia de 160%, causando o fechamento dessa Trove, o cálculo resultante empurraria o TCR abaixo de 150%, acionando o Modo de Recuperação.
O ataque se desenrola da seguinte forma:
O atacante abre uma posição mínima com uma razão de garantia ligeiramente acima de 150% em uma Trove cuidadosamente selecionada. Essa configuração é crucial para garantir que o resgate na próxima etapa leve efetivamente o TCR abaixo do limite crítico.
O atacante usa um empréstimo flash para abrir outra posição com uma relação de garantia na Taxa Mínima de Garantia (MCR) de 110% em qualquer Gerenciador de Tesouros, reduzindo a Taxa Total de Garantia (TCR) do sistema para exatamente 150%. Este passo prepara o sistema para o Modo de Recuperação.
O atacante então resgata a posição aberta no primeiro passo. Como essa posição tem um CR ligeiramente acima de 150%, resgatá-la faz com que o TCR caia abaixo de 150%, desencadeando assim o Modo de Recuperação. O resgate não apenas impacta o Túmulo específico sendo resgatado, mas também causa um efeito sistêmico que empurra o TCR para o Modo de Recuperação.
Com o sistema agora no Modo de Recuperação, o atacante pode liquidar qualquer posição com uma taxa de garantia abaixo de 150%. Essas liquidações podem restaurar o TCR para acima de 150%.
O atacante pode repetir as etapas conforme necessário, mantendo o sistema em um estado de Modo de Recuperação para explorar continuamente os Tesouros com índices de garantia abaixo de 150%.
As taxas de resgate e de empréstimo únicas desempenham um papel crucial na mitigação dos riscos associados aos vetores de ataque descritos acima. Ao introduzir um custo para o empréstimo e resgate, essas taxas tornam economicamente inviável para os atacantes executarem manipulações lucrativas em grande escala na maioria dos casos.
Por exemplo, no cenário de manipulação da taxa de resgate, uma taxa de empréstimo única aumentaria o custo de inflar a dívida do sistema, tornando não lucrativo para o atacante explorar a taxa de resgate. Da mesma forma, em cenários onde o atacante busca disparar o Modo de Recuperação, a taxa de empréstimo atuaria como um impedimento, aumentando o custo de assumir grandes quantidades de dívida para manipular o TCR.
À medida que o DeFi evolui, os protocolos enfrentarão ataques cada vez mais sofisticados. Para se manter à frente, é crucial entender como diferentes recursos interagem e potencialmente criam vulnerabilidades. A segurança eficaz requer um profundo entendimento de como os diferentes componentes do sistema interagem, bem como atenção cuidadosa às configurações e parâmetros que regem essas interações. Ao antecipar proativamente as maneiras pelas quais os recursos podem se combinar para criar vulnerabilidades, os designers podem construir protocolos que não apenas sejam seguros, mas também resilientes e adaptáveis aos desafios futuros.
Partilhar
İçerik
No mundo em constante evolução do DeFi, garantir a estabilidade e segurança do protocolo é essencial. Durante uma revisão de segurança recente de um projeto CDP, observei como vulnerabilidades específicas podem surgir em determinadas configurações. Embora as configurações de parâmetros atuais deste projeto sejam robustas, entender esses riscos potenciais é crucial para manter a integridade do protocolo.
Este artigo tem como objetivo explorar o papel crítico que as taxas de empréstimo único e as taxas de resgate desempenham nesse contexto. Ao examinar cenários específicos de exploração que poderiam surgir sem essas taxas, demonstrarei como uma estrutura de taxas adequada é essencial para prevenir ataques de desestabilização, garantindo assim a segurança e viabilidade de longo prazo do protocolo.
Tirando inspiração de um dos protocolos originais, Liquity, e suas derivadas, muitos modelos de CDP (Posição de Dívida Colateralizada) geram stablecoins descentralizadas por meio de supercolateralização. Esses modelos frequentemente incorporam um conjunto complexo, porém sofisticado, de mecanismos projetados para manter a paridade com o dólar americano, garantindo a segurança do protocolo em diversas condições, minimizando efetivamente o risco de dívidas ruins. Esses protocolos se distinguem por meio de customizações-chave, incluindo incentivos econômicos personalizados que se alinham mais de perto com os objetivos específicos do protocolo.
A taxa de resgate é uma taxa aplicada quando um usuário resgata a stablecoin do protocolo pelo seu colateral subjacente. Essa taxa é projetada para estabilizar o valor da stablecoin tornando o processo de resgate mais caro quando os resgates são frequentes, evitando assim resgates excessivos que possam desestabilizar o protocolo.
A taxa de resgate é calculada com base na baseRate do protocolo, um parâmetro de ajuste dinâmico que reflete a atividade recente dentro do sistema. Especificamente, a baseRate aumenta a cada resgate, tornando os resgates subsequentes mais caros.
Esse aumento é proporcional à fração do fornecimento total de stablecoin que é resgatada. Com o tempo, se nenhum resgate ocorrer, a taxa base gradualmente decai de volta a zero, com uma meia-vida de aproximadamente 12 horas.
A taxa de resgate é calculada usando a fórmula:
Por exemplo, se a taxa base for de 1% e um usuário resgatar 100 stablecoins quando o preço do colateral for $50,000, a taxa de resgate seria:
Assim, o usuário receberia um pouco menos de garantia após contabilizar a taxa de resgate. Esse mecanismo garante que os resgates permaneçam economicamente sensatos enquanto protegem o protocolo de atividades de arbitragem desestabilizadoras.
A taxa de empréstimo é outra taxa única que é cobrada quando um usuário toma empréstimo de stablecoins contra sua garantia. Essa taxa é baseada de forma semelhante na taxa base, mas se aplica no momento em que as stablecoins são retiradas do Tesouro do usuário (um contrato de cofre que mantém a garantia e a dívida do usuário).
A taxa de empréstimo é calculada da seguinte forma:
Por exemplo, se um usuário deseja pegar emprestado 4.000 stablecoins e a taxa base for definida em 0,5%, a taxa seria:
Esta taxa é adicionada à dívida do usuário, o que significa que sua dívida total seria o valor emprestado mais a taxa (por exemplo, 4.000 stablecoins + 20 stablecoins = 4.020 stablecoins).
Essas taxas também funcionam como uma espécie de âncora, influenciando indiretamente o preço de mercado da stablecoin, tornando-a menos atrativa para empréstimos ou resgates em certas condições, ajudando assim a manter a stablecoin próximo de $1.
Agora, vamos explorar o que poderia acontecer se essas taxas cruciais fossem removidas ou definidas como zero.
Sem uma taxa de resgate única, o protocolo poderia se transformar inadvertidamente em uma troca de DEX sem deslizamento. Nesse cenário, grandes detentores de stablecoins poderiam explorar o mecanismo de resgate para trocar stablecoins por garantias sem incorrer em custos significativos, efetivamente realizando negociações de arbitragem em grande escala. Isso poderia levar a vários resultados negativos, pois nesse ambiente sem deslizamento, resgates em grande escala não apenas drenariam a liquidez do protocolo, mas também forçariam os mutuários a vender suas garantias pelo preço de mercado atual. Embora sua dívida seja reduzida de acordo, essa liquidação forçada poderia aumentar os custos operacionais para os usuários, especialmente se a stablecoin estiver sendo negociada abaixo de $1.
Além disso, existe o risco de pré-execução do oracle: se um usuário perceber que uma transação está prestes a atualizar o oracle de preço do colateral para refletir um preço mais alto, ele poderia rapidamente resgatar uma grande quantidade de stablecoin antes da atualização do preço. Uma vez que o preço do colateral é atualizado e aumenta, o usuário poderia então vender o colateral resgatado com lucro, completando um ciclo de arbitragem. Essa prática não só explora o protocolo, mas também deixa os mutuários em desvantagem, pois eles podem ser forçados a vender seu colateral a preços menos favoráveis.
Um dos cenários de exploração mais diretos envolve a manipulação da taxa de resgate para reduzir os custos. Em protocolos onde não há taxa de empréstimo única, os usuários podem pegar grandes quantidades de stablecoin, inflando artificialmente a dívida total do protocolo. Uma vez que a dívida é inflada, eles podem resgatar suas stablecoins com uma taxa menor, já que a taxa de resgate é calculada com base na proporção do tamanho do resgate em relação à dívida total.
Esta manipulação mina a estrutura de taxas pretendida do protocolo, levando a uma redução na receita do protocolo e potencialmente desestabilizando o sistema. Por exemplo, os atacantes podem usar empréstimos flash para pedir emprestado grandes quantidades de garantias, que então usam para criar uma quantidade substancial de stablecoins, aumentando assim a dívida total do sistema. Eles então realizam uma operação de resgate, beneficiando-se da taxa reduzida devido à dívida inflacionada, e finalmente pagam o empréstimo flash, deixando o protocolo com menos receita do que o esperado e podendo levar a mais instabilidade para aqueles usuários que não anteciparam serem alvos de resgate.
Outra vulnerabilidade crítica surge da capacidade de forçar o protocolo a entrar no Modo de Recuperação em um único bloco, possibilitando a liquidação de posições com índices de garantia anteriormente saudáveis. Esse exploit depende do uso de empréstimos instantâneos e do timing do ataque em torno de uma atualização de preço do oráculo.
O ataque se desenrola da seguinte forma:
O atacante primeiro usa um empréstimo relâmpago para pegar emprestado uma grande quantidade de garantia, que é então depositada como garantia no protocolo. Usando essa garantia, o atacante toma emprestado stablecoins na Razão de Garantia Mínima (MCR). O atacante pode tomar essa ação para diminuir a Razão de Garantia Total (TCR) para 150%, o limite para acionar o Modo de Recuperação.
O atacante aguarda uma atualização do oráculo que reflita uma queda no preço do colateral. À medida que o novo preço mais baixo é atualizado no sistema, o valor do colateral cai, fazendo com que o TCR caia abaixo de 150%.
Com o TCR agora abaixo de 150%, o protocolo entra automaticamente no Modo de Recuperação. Nesse estado, o protocolo permite a liquidação de Troves com Índices de Colateral (CR) abaixo do novo TCR. O atacante pode então proceder à liquidação de Troves de outros usuários que agora têm um CR abaixo do TCR, causando prejuízos a eles e lucrando com as recompensas de liquidação.
Construindo sobre o cenário de ataque anterior, este exploit avançado permite que um invasor force o protocolo a entrar no Modo de Recuperação através de um processo de resgate cuidadosamente elaborado. Ao contrário do ataque anterior, que pode temporariamente retornar o sistema ao modo normal após a liquidação, este método garante que o sistema permaneça no Modo de Recuperação, permitindo que o invasor explore repetidamente a vulnerabilidade.
A questão central, que surge quando o sistema suporta múltiplos tipos de garantia, cada um gerenciado por diferentes Gerentes de Reserva, reside na potencial diminuição da Razão Total de Garantia (RTG) em todo o sistema após um resgate, mesmo que a saúde individual dos Gerentes de Reserva melhore. Este resultado contra-intuitivo é resultado da complexa interação entre as razões de garantia global e local.
Por exemplo, considere um cenário em que o TCR do sistema é de 150%.
Se um usuário resgatar contra uma Trove com uma taxa de garantia de 160%, causando o fechamento dessa Trove, o cálculo resultante empurraria o TCR abaixo de 150%, acionando o Modo de Recuperação.
O ataque se desenrola da seguinte forma:
O atacante abre uma posição mínima com uma razão de garantia ligeiramente acima de 150% em uma Trove cuidadosamente selecionada. Essa configuração é crucial para garantir que o resgate na próxima etapa leve efetivamente o TCR abaixo do limite crítico.
O atacante usa um empréstimo flash para abrir outra posição com uma relação de garantia na Taxa Mínima de Garantia (MCR) de 110% em qualquer Gerenciador de Tesouros, reduzindo a Taxa Total de Garantia (TCR) do sistema para exatamente 150%. Este passo prepara o sistema para o Modo de Recuperação.
O atacante então resgata a posição aberta no primeiro passo. Como essa posição tem um CR ligeiramente acima de 150%, resgatá-la faz com que o TCR caia abaixo de 150%, desencadeando assim o Modo de Recuperação. O resgate não apenas impacta o Túmulo específico sendo resgatado, mas também causa um efeito sistêmico que empurra o TCR para o Modo de Recuperação.
Com o sistema agora no Modo de Recuperação, o atacante pode liquidar qualquer posição com uma taxa de garantia abaixo de 150%. Essas liquidações podem restaurar o TCR para acima de 150%.
O atacante pode repetir as etapas conforme necessário, mantendo o sistema em um estado de Modo de Recuperação para explorar continuamente os Tesouros com índices de garantia abaixo de 150%.
As taxas de resgate e de empréstimo únicas desempenham um papel crucial na mitigação dos riscos associados aos vetores de ataque descritos acima. Ao introduzir um custo para o empréstimo e resgate, essas taxas tornam economicamente inviável para os atacantes executarem manipulações lucrativas em grande escala na maioria dos casos.
Por exemplo, no cenário de manipulação da taxa de resgate, uma taxa de empréstimo única aumentaria o custo de inflar a dívida do sistema, tornando não lucrativo para o atacante explorar a taxa de resgate. Da mesma forma, em cenários onde o atacante busca disparar o Modo de Recuperação, a taxa de empréstimo atuaria como um impedimento, aumentando o custo de assumir grandes quantidades de dívida para manipular o TCR.
À medida que o DeFi evolui, os protocolos enfrentarão ataques cada vez mais sofisticados. Para se manter à frente, é crucial entender como diferentes recursos interagem e potencialmente criam vulnerabilidades. A segurança eficaz requer um profundo entendimento de como os diferentes componentes do sistema interagem, bem como atenção cuidadosa às configurações e parâmetros que regem essas interações. Ao antecipar proativamente as maneiras pelas quais os recursos podem se combinar para criar vulnerabilidades, os designers podem construir protocolos que não apenas sejam seguros, mas também resilientes e adaptáveis aos desafios futuros.