Auditoria AlexGo – Blog CoinFabrik

Introdução

A CoinFabrik foi solicitada a auditar os contratos do projeto AlexGo. Primeiro, forneceremos um resumo de nossas descobertas e, em seguida, mostraremos os detalhes de nossas descobertas.

Resumo

Os contratos auditados são do repositório alex-v1 em
https://github.com/alexgo-io/alex-v1. A auditoria é baseada no commit
0913c9eb0c8f79b3cd0b843641075ce27d437c96. Correções foram feitas e verificadas novamente com base no commit feb43898de520ca1c55a6d8bc5bcf2d6f7df8ffa.

Contratos

Os contratos auditados são:

● clareza/contratos/equações/equação ponderada.clar: Biblioteca para
funções matemáticas ponderadas.
● clareza/contratos/equações/yield-token-equation.clar: Biblioteca para
produzir funções matemáticas de token.
● clareza/contratos/pool/alex-reserve-pool.clar: contrato de participação.
● clareza/contratos/pool/collateral-rebalancing-pool.clar: Empréstimos
e contrato de pool de empréstimos com pools de pesos variáveis.
● clareza/contratos/pool/fixo-peso-pool.clar: Contrato com
pools de liquidez de peso fixo.
● clareza/contratos/pool/liquidity-bootstrapping-pool.clar:
Contrato com pools de liquidez que aumentam o peso do token bootstrap
A Hora.
● clareza/contratos/pool/yield-token-pool.clar: pools de liquidez para
token e pares de token de rendimento correspondente.

Análises

As seguintes análises foram feitas:

● Uso indevido dos diferentes métodos de chamada
● Erros de estouro de número inteiro
● Divisão por zero erros
● Ataques de corrida frontal
● Ataques de reentrada
● Uso indevido de carimbos de data/hora de bloqueio
● Ataques de negação de serviço Softlock
● Funções com custo excessivo de gás
● Qualificadores de função ausentes ou mal utilizados
● Código desnecessariamente complexo e interações de contrato
● Tratamento de erros deficiente ou inexistente
● Falha ao usar um padrão de retirada
● Validação insuficiente dos parâmetros de entrada
● Tratamento incorreto de assinaturas criptográficas

Descobertas e correções

Classificação de gravidade

Os riscos de segurança são classificados da seguinte forma:

● Crítico: São questões que conseguimos explorar. Eles comprometem seriamente o sistema. Eles devem ser corrigidos imediatamente.
● Médio: Esses são problemas potencialmente exploráveis. Mesmo que não tivéssemos
conseguem explorá-los ou seu impacto não é claro, eles podem representar um
risco de segurança em um futuro próximo. Sugerimos corrigi-los O mais breve possível.
● Menor: Esses problemas representam problemas relativamente pequenos ou difíceis de tirar proveito, mas podem ser explorados em combinação com outros problemas. Esses tipos de problemas não bloqueiam implantações em ambientes de produção. Eles devem ser levados em consideração e corrigidos sempre que possível.
● Aprimoramento: Esses tipos de descobertas não representam um risco de segurança. São as melhores práticas que sugerimos implementar.

Essa classificação está resumida na tabela a seguir:

Problemas encontrados por gravidade

Problemas críticos de gravidade

Pools CR-01 transferem mais tokens do que o esperado

A função add-to-position() nos contratos
liquidity-bootstrapping-pool.clar e fixed-weight-pool.clar recebe como parâmetro quantos tokens o usuário gostaria de fornecer ao pool. Para adequar o saldo do pool, a função calcula a quantidade de tokens y a serem fornecidos com base na quantidade de token x. Como consequência, o valor real fornecido ao pool pode ser maior que o especificado pelo usuário. O resultado seria o contrato movendo mais tokens do que os consentidos pelo usuário.

Recomendação

A quantidade real de token y a ser fornecida ao pool nunca deve ser maior que o valor definido pelo usuário (dy). Isso pode ser feito adicionando um asserts! que compara esses valores.

Solução

Corrigido de acordo com a recomendação

CR-02 Perdeu Fundos ao Queimar Tokens de Rendimento

Em um pool de reequilíbrio de garantias (collateral-rebalancing-pool.clar)os provedores de liquidez obtêm uma quantidade de rendimento e tokens de chave igual à liquidez fornecida multiplicada por ltv (Loan-to-Value). Quando os tokens de rendimento são queimados chamando reduce-position-yield(), o pool é totalmente rebalanceado, trocando todas as garantias. Então, por exemplo, se um usuário possuir 100% do valor do pool e queimar todos os seus tokens de rendimento, o saldo armazenado no blockchain será reduzido a zero.
No entanto, o usuário é transferido apenas a quantidade exata de token de rendimento queimado (balance * ltv). Como isso não representa o valor real fornecido, os usuários perceberão que perderam fundos quando tentarem gravar seus tokens de chave e receberem zero tokens porque o pool está vazio.

Recomendação

Subtraia do saldo do pool o mesmo valor transferido para o usuário.

Solução

Corrigido de acordo com a recomendação.

CR-03 Negação de serviço ao queimar fichas de rendimento

Em um pool de reequilíbrio de garantias (collateral-rebalancing-pool.clar)quando os tokens de rendimento são queimados chamando reduce-position-yield(), a carteira é completamente rebalanceada, trocando todas as garantias (ou seja, torna-se uma carteira de 0-100). Como consequência, torna-se inutilizável para trocas de token, pois o valor de entrada ou saída será maior que o saldo zero, fazendo com que a transação seja revertida devido às afirmações feitas em weighted-equation.clar. Essas afirmações verificam se o valor depositado em um pool em um token A é menor que o saldo desse token multiplicado por uma proporção, e também a quantidade de tokens B dados em troca é menor que o saldo desse token multiplicado por uma proporção.
Além disso, essa negação de serviço seria na maioria das vezes executada involuntariamente pelos usuários e persistiria até que alguém fornecesse liquidez ao pool novamente, incrementando o saldo zero.

Solução

As funções de troca só podem ser chamadas antes do bloco de expiração.

Problemas de gravidade média

ME-01 Negação de Serviço ao Gravar Tokens de Chave

Em um pool de reequilíbrio de garantias (collateral-rebalancing-pool.clar)se todos os tokens de chave foram queimados e o pool de reserva (alex-reserve-pool.clar) não tiver tokens em seu saldo, os usuários podem não queimar nenhuma quantidade de seus tokens de rendimento.
Desde a reduce-position-yield() troca todas as garantias, um novo saldo do token é calculado com base no saldo anterior e na quantidade de tokens recebidos após a troca. Em seguida, a função calcula uma variável
share-to-yield que é igual à quantidade de tokens de rendimento que o usuário deseja queimar (compartilhamentos) dividido por sua oferta total (yield-supply). Depois, calcula dyo produto de new-bal-y e shares-to-yielde compara dy com ações.
Uma vez que o pool tem apenas um valor igual à oferta de rendimento, ele é trocado e as taxas são retiradas, dy será menor que as ações. Portanto, na linha 496, chama alex-reserve-pool.remove-from-balance() transferir o défice, mas se alex-reserve-pool não tiver tokens, ele será revertido.

Solução

As alterações feitas para corrigir o CR-02 resolveram esse problema.

Problemas de gravidade menores

Precisão decimal baixa MI-01

Os tipos inteiros do Clarity são armazenados em slots de armazenamento de 128 bits. Para representar a parte fracionária, utiliza-se uma precisão de ponto fixo com 8 decimais para a parte fracionária e 30 para a parte inteira. No entanto, essa precisão é baixa e pode resultar em erros decimais significativos a longo prazo.

Recomendação

Como a parte inteira é mais do que longa o suficiente, a precisão pode ser aumentada para, por exemplo, 18 casas decimais.

Solução

A equipe de desenvolvimento está estudando a implementação de um decimal mais alto
precisão.

Fundos MI-02 Captados por causa da repetição do token do pool de liquidez

Sempre que os usuários fornecem liquidez a um pool, eles recebem tokens de pool de liquidez (tokens LP). Se dois pools fossem criados com o mesmo token LP, os usuários poderiam fornecer liquidez em um desses pools e retirar fundos do outro. Atualmente, apenas os proprietários do contrato podem criar pools e isso fica a seu critério.

Recomendação

Restringir a repetição do token LP, não apenas em cada contrato, mas também em todo o pool
contratos: fixed-weight-pool.clar, liquidity-bootstrapping-pool.clar, yield-token-pool.clar. Esses são os pools que compartilham a mesma característica para os tokens LP.

Solução

A equipe de desenvolvimento está considerando a manutenção de um contrato de registro que
atualizado sempre que um pool é criado e verifica se o endereço principal do token do pool passado já está em uso.

MI-03 Swap Limit Setter não restrito

Os valores trocados são limitados para não serem maiores que uma certa porcentagem do saldo total (MAX-IN-RATIO e MAX-OUT-RATIO). Esses valores são definidos inicialmente para 30% em weighted-equation.clar e yield-token-equation.clar, mas podem ser modificados sem restrições. Pode resultar em uma negação de serviço se o valor for muito pequeno.

Recomendação

Os setters devem verificar se o novo valor é, no mínimo, maior que zero com um asserts!.

Solução

Corrigido de acordo com a recomendação.

MI-04 Front-running após a criação do pool

Pools de bootstrapping de liquidez (liquidity-bootstrapping-pool.clar) são criados com um valor padrão para preços máximos e mínimos para token bootstrap (o máximo é definido como 10^8 e o mínimo como zero). Eles podem ser alterados, mas apenas chamando o setter em outra transação. Como o criador do pool deve fornecer liquidez na mesma transação em que criou o pool, sob certas condições de mercado, um invasor pode achar lucrativo executar um swap imediatamente após a criação do pool e antes que o máximo e o mínimo sejam modificados.

Recomendação

Adicione dois parâmetros para create-pool() atribuir valores iniciais para price-x-min e price-x-max.

Solução

Corrigido de acordo com a recomendação.

MI-05 Nova Expiração Máxima no Passado

Dentro yield-token-pool.clar, max-expiry é uma variável essencial para calcular o tempo até o vencimento. Se essa variável for menor ou igual ao bloco atual, a maioria das transações será revertida, causando uma negação de serviço nesse contrato. Atualmente, seu montador, set-max-expiry()não verifica se o novo valor é válido.

Recomendação

Adicionar um asserts! checar new-max-expiry é melhor que block-height antes de atribuí-lo a max-expiry.

Solução

Corrigido de acordo com a recomendação.

Melhorias

EN-01 Constantes e Funções Matemáticas Não Usadas

Funções matemáticas úteis e constantes são copiadas nos contratos. No entanto, eles nem sempre são usados ​​pelo restante das funções do contrato e tornam a implantação mais cara. Por exemplo, em collateral-rebalancing-pool.clar, pow-up()ONE_10, log-fixed() e ln-fixed() não são usados.

Recomendação

Remova as funções que não são necessárias para os contratos.

outras considerações

1. collateral-rebalancing-pool.clar usa uma aproximação para a função de erro (Abramowitz e Stegun) que tem um erro máximo alto. A recomendação é testá-lo extensivamente para garantir que não tenha implicações inesperadas.
2. Dentro yield-token-pool contrato, max-expiry valor é baseado em um tempo de bloco de 15 segundos. A equipe do AlexGo explicou que está definido para o ambiente mocknet. Ele deve ser alterado para 10 minutos quando for implantado na rede principal do Stacks.

Conclusão

Achamos os contratos simples e diretos e possuem uma quantidade adequada de documentação, mas nem sempre atualizada. Foram encontrados três problemas de gravidade crítica, um médio e cinco de gravidade menor. Além disso, um aprimoramento foi proposto. A equipe de desenvolvimento corrigiu sete problemas e reconheceu dois problemas menores.

Isenção de responsabilidade: Este relatório de auditoria não é uma garantia de segurança, conselho de investimento ou uma aprovação do projeto AlexGo, pois a CoinFabrik não revisou sua plataforma. Além disso, ele não fornece uma garantia de ausência de falhas de código de contrato inteligente.