Testes de propriedade generalizada para cofres ERC4626

À medida que o DeFi cresce e amadurece, a infraestrutura escalável e a capacidade de composição são as principais preocupações dos desenvolvedores. Ethereum Requests for Comments (ou ERCs) — kits de ferramentas padronizados para criar aplicativos baseados em Ethereum, como o padrão de token amplamente usado ERC20 — cumprem o papel essencial de fornecer diretrizes consistentes para que os desenvolvedores contribuam com o ecossistema sem começar do zero. No início deste ano, padrão de cofre tokenizado ERC4626 foi criado para incentivar a compatibilidade cruzada entre tokens de rendimento. Padronizar detalhes de implementações também pode resolver problemas urgentes de composição, tornando a integração de protocolos mais fácil e, em última análise, menos propensa a erros.

Vários projetos DeFi já adotado o padrão, procurando aumentar a capacidade de composição de seus cofres, e prevemos uma adoção mais ampla em todo o ecossistema. Adaptar os cofres existentes causa algumas dores de crescimento, no entanto; criticamente, certos erros de implementação podem expor novos alvos para ataques. Mesmo pequenos erros (tão pequenos quanto a interpretação errada da interface padrão) podem ter consequências significativas para a segurança e a experiência do usuário, ressaltando a necessidade de mais ferramentas e medidas de segurança, principalmente em um ecossistema DeFi mais combinável. 

Felizmente, erros simples podem ter soluções relativamente simples se detectados bem antes de serem explorados (e idealmente antes mesmo de serem implantados). Para isso, lançamos Testes de propriedade ERC4626 para fuzzing e execução simbólica para ajudar os construtores de cofres a detectar violações padrão que podem interromper integrações ou levar a vulnerabilidades no futuro. Neste post, explicamos o problema motivador, explicamos nossa abordagem e concluímos com alguns conselhos acionáveis.

Primeiro, um pouco de fundo sobre o padrão ERC4626

Finalizado em março, ERC4626 é o padrão para cofres tokenizados. Foi introduzido a fim de estender o amplamente utilizado ERC20 standard (atualmente a base para centenas de tokens), incentivar a padronização em cofres com rendimento e garantir a capacidade de composição para os aplicativos e protocolos (por exemplo, agregadores de rendimento) que precisam interagir com eles. Isso significa que qualquer aplicativo criado em um cofre ERC4626 pode ser facilmente estendido para funcionar com qualquer outro cofre ERC4626. 

Os cofres com token permitem que os usuários depositem livremente ativos para cunhar compartilhamentos do cofre e, posteriormente, resgatem esses compartilhamentos para retirar o principal e os juros do cofre. Esses compartilhamentos de cofre são tokens ERC20 e, portanto, podem ser facilmente negociados ou usados ​​como garantia para emprestar outros ativos. Por exemplo, os usuários podem depositar seus ativos em cofres Yearn para cunhar tokens yVault, que podem ser negociados no Uniswap, apostados para obter rendimento adicional ou usados ​​como garantia para protocolos de empréstimo.

A lógica de negócios para gerar e distribuir o rendimento (e determinar o preço da ação) pode variar entre as implementações. Para cobrir o maior número possível de cofres (com o objetivo de torná-los interoperáveis ​​versus idênticos), o padrão ERC4626 se concentra na descrição da interface do usuário, deixando a maioria dos detalhes de implementação não especificados. Isso permite variações na lógica de negócios, desde que o cofre atenda aos requisitos específicos da interface e incentiva interoperabilidade em muitos tipos diferentes de aplicativos e tipos de cofres ERC4626.

À medida que mais cofres são criados, esperamos vê-los implementados de acordo com o padrão ERC4626 desde o início; mas atualmente estamos em uma fase de transição, em que os desenvolvedores que desejam aproveitar uma maior capacidade de composição precisarão atualizar cofres, aplicativos e protocolos existentes para se adequar ao padrão. E à medida que são atualizados, eles enfrentam uma série de complexidades e desafios. 

Os desafios da conformidade padrão (e as armadilhas de não se conformar)

Seguir um novo padrão nem sempre é simples. Cada cofre ERC4626 deve implementar fielmente (e exatamente) os requisitos do padrão conforme descrito. Caso contrário, a integração dos cofres ERC4626 torna-se cada vez mais complexa para dar conta de diferentes variações. Essa complexidade torna as integrações inerentemente propensas a erros; e como não são suficientemente à prova de futuro, podem levar a vulnerabilidades de segurança ao longo do tempo.

Os tokens ERC20 não padrão (por exemplo, Tether USD) exigem que muitos sistemas DeFi usem uma biblioteca adicional (como SafeERC20) ao realizar transferências de token para lidar com segurança com comportamentos divergentes (por exemplo, não retornar nada quando uma transferência for bem-sucedida em vez de retornar true). Isso significa que qualquer sistema que interaja com esses tokens pode se tornar vulnerável se o sistema não for projetado para lidar adequadamente com casos de “devoluções ausentes”. Esses cenários podem potencialmente introduzir uma armadilha de segurança comum e aumentar os custos gerais de desenvolvimento e manutenção (ao considerar a lógica adicional e as dependências necessárias para mitigar problemas). A conformidade com o padrão é, portanto, fundamental não apenas para implementações individuais, mas também para a segurança de todo o ecossistema. Uma vulnerabilidade em um único sistema ou dependência pode causar problemas generalizados.

Idealmente, os padrões seriam formalmente especificados sem ambiguidade (por exemplo, especificação formal do ERC20), e cada implementação pode ser formalmente verificada em relação à especificação padrão. Na prática, porém, isso não é fácil de ser alcançado em um curto período de tempo, devido ao custo e esforço exigidos da comunidade.

Apresentando propriedades executáveis ​​ERC4626 para identificar problemas de conformidade 

À medida que trabalhamos em direção a um estado ideal (todo cofre verificado formalmente em relação a especificações formais rigorosas), escrevemos o padrão ERC4626 Propriedades para detectar discrepâncias em detalhes sutis e fáceis de perder dos requisitos padrão.  

Os desenvolvedores do Vault podem executar os testes para detectar possíveis violações padrão em suas implementações antes da implantação. E os integradores de cofres podem verificar se os cofres fornecidos seguem o padrão antes de integrá-los ao sistema. As propriedades também podem ser testadas contra os cofres ativos já implantados na rede principal, por meio de testes de bifurcação da rede principal. O teste de cofres ativos pode ser útil — especialmente quando os cofres foram implantados ou atualizados recentemente — para garantir que todos os parâmetros do sistema tenham sido definidos corretamente. 

Escolhemos testes baseados em propriedades — escritos em Foundry e prontos para serem executados por seu fuzzer — para tornar as propriedades executáveis ​​(e, portanto, testáveis). No futuro, eles também podem ser executados por execução simbólica ou ferramentas de verificação de modelo para verificar formalmente se o cofre fornecido satisfaz as propriedades para todas as entradas e condições possíveis.

Escrevemos as propriedades para serem gerais o suficiente para serem aplicadas a uma ampla variedade de cofres que implementam diferentes lógicas de negócios. Usamos apenas funções de interface pública para torná-las independentes dos detalhes de implementação. (Devido a essa restrição, no entanto, certos requisitos padrão que se referem a dados internos específicos da implementação foram omitidos das propriedades.)

Por exemplo, a propriedade a seguir corresponde a um dos requisitos do convertToShares() função, “NÃO DEVE mostrar variações dependendo do chamador.” Dados os dois endereços de conta e o valor, faz com que cada uma das contas chame convertToShares() com o mesmo valor e garante que os dois valores de retorno sejam iguais. Esta propriedade é independente dos detalhes de implementação de convertToShares(), que varia entre os cofres e deve ser atendido por todos os cofres que implementam o ERC4626. Essa propriedade pode ser executada fornecendo valores de entrada específicos (para teste de unidade), muitas entradas aleatórias (para teste de fuzz) ou valores simbólicos (para execução simbólica e verificação formal). Ele também pode ser executado localmente ou em um fork da rede principal (para teste de integração).

Caso de uso: propriedades que testam erros de arredondamento

Erros de arredondamento, por exemplo, são uma classe importante de bugs (aparentemente menores) que podem ter algumas implicações em série. A lógica contábil subjacente do ERC4626, por exemplo, o cálculo do número de ações a serem cunhadas ou a quantidade de ativos a serem retirados, é implementada usando aritmética de ponto fixo – erros de arredondamento são inevitáveis. Por segurança, no entanto, o padrão especifica explicitamente a direção de arredondamento preferencial para cada função de interface, deixando os limites de erro não especificados e dependentes da implementação. Especificamente, o deposit() e redeem() funções devem retornar um para-aproximação do valor exato, enquanto o mint() e withdraw() funções devem retornar um Acima de-aproximação. Por exemplo, se o preço atual da ação (ou seja, a quantidade de ativos por ação) for 2, então deposit() com 3 wei de ativos só deve cunhar até 1 wei de ações (ou seja, floor(3/2)), enquanto withdraw() com 3 wei de ativos deve queimar pelo menos 2 wei de ações (ou seja, ceil(3/2)).

Escrevemos as propriedades relacionadas ao arredondamento para serem independentes da lógica contábil subjacente, tratando-a como uma caixa preta. Especificamente, nós as formulamos como propriedades chamadas de “ida e volta”, que descrevem a relação entre duas funções opostas. Por exemplo, a propriedade a seguir especifica que a retirada de ativos que acabaram de ser caucionados pela cunhagem de N ações deve queimar não menos que N ações. Em outras palavras, ninguém pode lucrar gratuitamente convertendo ativos e ações de cofre de um lado para o outro, cunhando e sacando repetidamente.

De fato, descobrimos que vários cofres ERC4626 na rede principal não satisfazem a propriedade acima devido a erros de arredondamento. Isso significa que qualquer um poderia ganhar, por exemplo, alguns satoshi BTC (1 satoshi ~= 0.02 centavos no momento da redação) simplesmente (e repetidamente) cunhando e retirando, esvaziando lentamente o cofre. Isso pode realmente gerar lucro em redes que desfrutam de taxas de gás muito baixas (por exemplo, Fantom), ou se o preço do ativo se tornar alto o suficiente no futuro.

Testando o padrão ERC4626 na natureza

Testamos nossas propriedades em cerca de 100 cofres ERC4626 na rede principal e encontramos muitos cofres que não seguiram os requisitos padrão - principalmente devido aos erros de arredondamento (por exemplo, usando arredondamento de piso onde o teto é desejado, conforme descrevemos). Especificamente, certos cofres não conseguiram cunhar o número exato de ações solicitadas pelo mint() função, embora a norma exija explicitamente isto. Alguns deles também emitiram um Deposit evento onde os dados registrados são diferentes do que foi realmente cunhado. Para nossa surpresa, alguns cofres nunca foram cunhados no local; em vez disso, eles apenas colocam as solicitações do Mint em uma fila e as processam posteriormente em um lote como uma transação separada.

Embora esses comportamentos divergentes não sejam exploráveis ​​em si, eles podem se tornar vulneráveis ​​quando integrados a outros sistemas que esperam apenas os comportamentos padrão. Esses problemas tornarão a integração do vault muito mais difícil, potencialmente neutralizando os esforços contínuos e impulsionando a motivação por trás da padronização.

Usando nossos testes de propriedade e outras etapas acionáveis ​​em direção à conformidade padrão

Seguir o padrão com precisão pode evitar comportamentos divergentes (idealmente antes de serem implantados). Esperamos que nossas propriedades ajudem, juntamente com alguns itens de ação adicionais. Para aqueles que estão desenvolvendo e/ou integrando cofres ERC4626:

• É altamente recomendável administrar nossa propriedade testes contra seus cofres. Eles encontrarão rapidamente problemas se houver alguma violação clara do padrão.
• Sugerimos também rever nossos Propriedades para verificar sua compreensão dos requisitos padrão e ajustar sua implementação se houver alguma discrepância não intencional.
• Se o seu cofre tiver que divergir do padrão, recomendamos documentar claramente os comportamentos fora do padrão, para que outras pessoas possam lidar adequadamente com esses desvios ao integrar seu cofre. Observe que isso deve ser considerado como último recurso.

***
Os cofres ERC4626 têm o potencial de se tornar um importante bloco de construção para DeFi em um futuro próximo - e, por causa da composição, é importante que os cofres novos e existentes sigam o padrão. Novas implementações surgirão seguindo o padrão, então não há melhor momento do que o presente para padronizar os cofres existentes. 

À medida que trabalhamos em direção a um estado ideal (onde diferentes cofres podem ser compostos uniformemente), os testes de propriedade ERC4626 podem ser executados para detectar mais facilmente violações padrão em implementações de cofres. Os testes de propriedade (com documentação e exemplos) estão todos disponíveis publicamente em nosso Github repositório. Congratulamo-nos com seus comentários e contribuições!

***
As opiniões expressas aqui são as do pessoal individual da AH Capital Management, LLC (“a16z”) citadas e não são as opiniões da a16z ou de suas afiliadas. Certas informações aqui contidas foram obtidas de fontes de terceiros, inclusive de empresas do portfólio de fundos administrados pela a16z. Embora retiradas de fontes consideradas confiáveis, a16z não verificou essas informações de forma independente e não faz representações sobre a precisão atual ou duradoura das informações ou sua adequação a uma determinada situação. Além disso, esse conteúdo pode incluir anúncios de terceiros; a16z não revisou tais anúncios e não endossa nenhum conteúdo de publicidade neles contido.

Este conteúdo é fornecido apenas para fins informativos e não deve ser considerado como aconselhamento jurídico, comercial, de investimento ou fiscal. Você deve consultar seus próprios conselheiros sobre esses assuntos. As referências a quaisquer valores mobiliários ou ativos digitais são apenas para fins ilustrativos e não constituem uma recomendação de investimento ou oferta para fornecer serviços de consultoria de investimento. Além disso, este conteúdo não é direcionado nem destinado ao uso por quaisquer investidores ou potenciais investidores, e não pode, em nenhuma circunstância, ser invocado ao tomar uma decisão de investir em qualquer fundo administrado pela a16z. (Uma oferta para investir em um fundo a16z será feita apenas pelo memorando de colocação privada, contrato de subscrição e outra documentação relevante de tal fundo e deve ser lida na íntegra.) Quaisquer investimentos ou empresas de portfólio mencionados, referidos ou descritos não são representativos de todos os investimentos em veículos administrados pela a16z, e não pode haver garantia de que os investimentos serão rentáveis ​​ou que outros investimentos realizados no futuro terão características ou resultados semelhantes. Uma lista de investimentos feitos por fundos administrados por Andreessen Horowitz (excluindo investimentos para os quais o emissor não deu permissão para a a16z divulgar publicamente, bem como investimentos não anunciados em ativos digitais negociados publicamente) está disponível em https://a16z.com/investments /.

Os gráficos e gráficos fornecidos são apenas para fins informativos e não devem ser considerados ao tomar qualquer decisão de investimento. O desempenho passado não é indicativo de resultados futuros. O conteúdo fala apenas a partir da data indicada. Quaisquer projeções, estimativas, previsões, metas, perspectivas e/ou opiniões expressas nestes materiais estão sujeitas a alterações sem aviso prévio e podem diferir ou ser contrárias às opiniões expressas por outros. Consulte https://a16z.com/disclosures para obter informações adicionais importantes