TLDR: ERC-4626 é o padrão para cofres tokenizados.
Antes da introdução do ERC-4626, cada vault tinha sua própria especificação e detalhes de implementação. Isso torna a integração difícil, propensa a erros e um desperdício de recursos.
O ERC-4626 tenta resolver esse problema com uma especificação padrão para reduzir o esforço de integração e criar um modelo de implementação mais consistente e robusto, assim como o ERC-20.
O que é ERC-4626?
ERC-4626 é um padrão que melhora os parâmetros técnicos dos cofres de rendimento. Ele fornece uma API padrão para cofres de rendimento que representam ações de um único token ERC-20 subjacente.
Cofres tokenizados se tornaram um modelo extremamente comum em DeFi. Agregadores de rendimento, mercados de empréstimo, derivativos de staking e muitos outros dApps utilizam e dependem de cofres tokenizados. Exemplos de cofres tokenizados incluem Yearn e Balancer. Como agregador de rendimento, o Yearn Vault permite que os usuários depositem ativos digitais e obtenham rendimento. O Balancer é um gerenciador de portfólio automatizado e provedor de liquidez que conta com cofres no centro de sua lógica de negócios. Esses cofres gerenciam tokens em vários pools. Ao mesmo tempo, eles separam o gerenciamento de tokens da lógica do próprio pool.
O protocolo aumenta a liquidez e a flexibilidade ao tokenizar seus cofres. Os cofres tokenizados facilitam a transação e o uso de ativos em plataformas DeFi. Além disso, permitem a criação de diversos produtos financeiros interligados. A indústria tem defendido esse paradigma, muitas vezes chamado de "Lego do dinheiro".
No entanto, a capacidade de composição sem adaptabilidade ou padronização adequada apresenta desafios. Além de dificultar a conformidade dos desenvolvedores com os padrões do setor, como o ERC-20, também pode confundir os novos desenvolvedores. Sem a devida adaptação ou padronização, fica difícil revisar novas mudanças e verificar os detalhes de implementação das integrações.
Portanto, o ERC-4626 foi proposto para resolver esse problema e simplificar a integração, permitindo que os participantes do DeFi finalmente adotem uma especificação de cofre unificada mais segura e robusta. Isso, por sua vez, reduzirá a possível superfície de ataque do protocolo enquanto integra tokens em vários protocolos.
Quais problemas de segurança o ERC-4626 pode evitar?
Ao fornecer um padrão unificado, o ERC-4626 acelera a construção da integração entre protocolos. Padrões familiares e consistentes também são mais fáceis para os desenvolvedores entenderem, reduzindo a probabilidade de erros de codificação. Isso ajuda a evitar problemas de composição. A padronização também evita a duplicação de esforços, pois a comunidade só precisa projetar o cofre uma vez, em vez de individualmente para cada protocolo. Uma vez que esse esforço de design geralmente é propenso a erros, ele ajuda a evitar a duplicação de falhas de design estabelecidas, mas generalizadas.
Apresentaremos aqui dois estudos de caso para mostrar quais problemas o ERC-4626 pode prevenir.
Evento Rari Capital
Aproximadamente $ 11 milhões em tokens foram roubados da Rari Capital, o que equivale a 60% de todos os fundos do usuário no pool Rari Capital Ethereum.
No geral, a Rari Capital foi hackeada devido a uma implementação insegura entre protocolos. Seu pool Ethereum leva ETH para o contrato de token ibETH da Alpha Finance como uma estratégia de saída. Essa estratégia específica rastreia o valor de sua taxa de câmbio ibETH/ETH por meio de determinados contratos e fórmulas (especificamente, a função ibETH.totalETH / ibETH.totalSupply), que podem ter saídas errôneas nesse cenário de ataque, por exemplo, ao chamar ibETH.work ( ), os valores da dívida podem ser inflacionados artificialmente.
Um invasor pode esgotar o Rari Fund Manager simplesmente chamando repetidamente as funções de depósito e retirada no contrato RariFundManager. As funções de depósito e retirada precisam obter o saldo do pool para calcular a quantidade de tokens REPT a serem emitidos para o chamador, ou a quantidade de ETH a ser emitida para o chamador. Essa operação chamará a função getBalance do pool Alpha , chame o contrato ibETH e sua função totalETH . Rari não tem conhecimento da possibilidade de manipular esta função.
Há outra função no contrato ibETH: ibETH.work. Esta função pode chamar qualquer contrato especificado pelo usuário. Isso permite que as funções de depósito e retirada do Rari sejam reentrantes e sejam chamadas várias vezes.
A função trabalho é uma função paga, o que significa que o usuário pode controlar a quantidade de ETH no contrato ibETH por meio da função trabalho, alterando assim o valor retornado pela função totalETH. Para piorar a situação, a função de trabalho também suporta chamar qualquer outro contrato, como RariFundManager.
Por meio dessa função, o invasor pode enviar ETH novamente e aumentar o valor total de ETH no contrato ibETH e, ao mesmo tempo, chamar a retirada no contrato RariFundManager para resgatar mais ativos.
Este incidente destaca os riscos significativos representados pela integração insuficiente e projetos incompatíveis em contratos DeFi. Ele destaca como padrões como o ERC-4626 podem impedir tais ataques adicionando uma camada crítica de segurança e previsibilidade e promovendo comportamento uniforme e compreensão mútua.
Caso Financiamento Creme
A Cream Finance sofreu um ataque sofisticado que explorou duas fraquezas fundamentais na plataforma: um oráculo de mistura manipulado e um suprimento ilimitado de tokens. Uma parte fundamental do ataque foi a manipulação do oráculo de mistura, que afetou o valor percebido do token yUSD. Quando o invasor enviou uma grande quantidade de tokens Yearn 4-Curve para o cofre yUSD, ele alterou a taxa de câmbio relatada pelo cofre e, portanto, também afetou o valor percebido dos tokens yUSD para o oráculo.
A principal lição aqui é que um oráculo de preços robusto e não manipulável é fundamental para a estabilidade de um protocolo DeFi. Os oráculos de preço médio ponderado pelo tempo (TWAP) podem ajudar a evitar tais hacks porque são mais resistentes à manipulação repentina de preços.
Esses problemas e outros padrões de design frágeis podem ser mitigados por meio da adoção e implementação cuidadosas do ERC-4626.
Possíveis riscos de segurança no ERC-4626
Sempre há algumas compensações com o uso de um novo protocolo. Para cofres tokenizados, pode haver possíveis problemas para integrá-los a contratos inteligentes que requerem atenção especial.
Gerenciar tokens feeOnTransfer
Se o cofre for projetado para oferecer suporte a tokens feeOnTransfer, verifique se o valor e as ações no cofre estão dentro do intervalo esperado ao transferir ativos.
Uso apropriado da variável decimals
Embora a função convertTo não deva precisar usar a variável decimais do cofre EIP-4626, ainda é altamente recomendável espelhar os decimais do token subjacente sempre que possível. Essa prática ajuda a remover possíveis fontes de confusão e simplifica a integração para vários usuários front-end e fora da cadeia.
arredondamento
De acordo com a especificação, os implementadores do cofre devem estar cientes de que direções de arredondamento específicas e opostas são necessárias em diferentes métodos mutáveis e de exibição, pois é mais seguro priorizar o próprio cofre sobre seus usuários durante os cálculos:
Se estiver calculando o número de ações a serem emitidas para um usuário pelo valor de algum token subjacente que ele oferece, ou se estiver operando para transferir uma parte específica do token subjacente para um usuário, deve-se arredondar para baixo.
Se estiver calculando quantos compartilhamentos um usuário deve fornecer para obter uma certa quantidade de tokens de base, ou se estiver calculando quantos tokens de base um usuário deve fornecer para obter um determinado número de compartilhamentos, deve ser arredondado.
Onde a direção de arredondamento preferencial será ambígua é a função convertTo. Para garantir a consistência em todas as implementações de cofre EIP-4626, especifique que essas funções devem sempre ser arredondadas. Os próprios integradores podem imitar a versão arredondada, por exemplo, adicionando um Wei ao resultado.
A quantidade de ativos subjacentes que um usuário recebe ao resgatar sua participação no cofre (previewRedeem) pode variar significativamente do valor que teria que ser pago para emitir a mesma quantia de participação (previewMint). Essas diferenças podem ser pequenas (por exemplo, devido a erros de arredondamento) ou grandes (por exemplo, um cofre implementa taxas de retirada ou depósito). Portanto, os integradores devem ter o cuidado de usar as funções de visualização que melhor se adequam ao seu caso de uso e nunca presumir que sejam intercambiáveis.
Substituir a funcionalidade principal
Para implementar ou estender a funcionalidade pretendida, é recomendável usar ganchos existentes em vez de alterar a funcionalidade principal. Essa prática garante uma trilha mais gerenciável para testes e auditorias de código eficientes.
Compartilhamento zero
A especificação original para ERC-4626 não delineava como lidar com o caso extremo de nenhum compartilhamento no cofre e se o cofre deveria se comportar normalmente ou reverter. Isso pode ser uma fonte potencial de confusão e erros.
Cofres como oráculos de preço
Com relação ao risco de ataques de manipulação de preço do oráculo, os valores retornados por esses métodos de visualização são os mais próximos da precisão possível. Como tal, eles podem operar alterando as condições da cadeia e nem sempre são seguros para usar como oráculos de preço. A especificação ERC-4626 inclui um método convert e um método totalAssets que permitem imprecisão e, portanto, podem ser implementados como um poderoso oráculo de preço. Por exemplo, ao converter entre ativos e ações, é correto usar o preço médio ponderado no tempo para implementar o método de conversão.
Problemas concretos de implementação
Os integradores devem revisar qualquer implementação de cofre tokenizado antes da integração posterior, pois pode haver implementações maliciosas que parecem estar em conformidade com a especificação da interface, mas cujas funções principais consistem em especificações de design completamente diferentes.
Acesso Direto EOA
Se um cofre for acessado diretamente, sua implementação precisa ter recursos que possam ser usados para acomodar perdas por derrapagem ou limites acidentais de depósito/retirada. Ao contrário dos contratos inteligentes, o EOA não possui um mecanismo à prova de falhas para reversão de transação. Se a saída exata não for alcançada ao chamar a função principal, não há como reverter.
Cofre Estendido
À medida que mais players começarem a adotar o padrão ERC-4626, veremos mais extensões implementadas para o padrão. Por exemplo, a Superform desenvolveu uma extensão experimental do Multi Vault que suporta o uso de diferentes cálculos em um único contrato do Vault. Naturalmente, quanto mais a implementação se desviar do padrão original, maior a possibilidade de introdução de novas vulnerabilidades. Desenvolvedores e auditores podem encontrar sua melhor opção com base no caso de uso para determinar o valor real em risco.
É importante ressaltar que não é a menor adição de cada protocolo que leva a eventos catastróficos, mas a soma deles quando integrados.
Os potenciais vetores de ataque mencionados acima são alguns dos problemas mais discutidos em torno do padrão ERC-4626. À medida que a adoção aumenta, definitivamente exploraremos mais casos de uso de implementação e cenários mais adequados para integração com cofres ERC-4626.
Ver original
O conteúdo é apenas para referência, não uma solicitação ou oferta. Nenhum aconselhamento fiscal, de investimento ou jurídico é fornecido. Consulte a isenção de responsabilidade para obter mais informações sobre riscos.
Entendendo o ERC-4626 em um artigo: o novo padrão para cofres tokenizados DeFi
TLDR: ERC-4626 é o padrão para cofres tokenizados.
Antes da introdução do ERC-4626, cada vault tinha sua própria especificação e detalhes de implementação. Isso torna a integração difícil, propensa a erros e um desperdício de recursos.
O ERC-4626 tenta resolver esse problema com uma especificação padrão para reduzir o esforço de integração e criar um modelo de implementação mais consistente e robusto, assim como o ERC-20.
O que é ERC-4626?
ERC-4626 é um padrão que melhora os parâmetros técnicos dos cofres de rendimento. Ele fornece uma API padrão para cofres de rendimento que representam ações de um único token ERC-20 subjacente.
Cofres tokenizados se tornaram um modelo extremamente comum em DeFi. Agregadores de rendimento, mercados de empréstimo, derivativos de staking e muitos outros dApps utilizam e dependem de cofres tokenizados. Exemplos de cofres tokenizados incluem Yearn e Balancer. Como agregador de rendimento, o Yearn Vault permite que os usuários depositem ativos digitais e obtenham rendimento. O Balancer é um gerenciador de portfólio automatizado e provedor de liquidez que conta com cofres no centro de sua lógica de negócios. Esses cofres gerenciam tokens em vários pools. Ao mesmo tempo, eles separam o gerenciamento de tokens da lógica do próprio pool.
O protocolo aumenta a liquidez e a flexibilidade ao tokenizar seus cofres. Os cofres tokenizados facilitam a transação e o uso de ativos em plataformas DeFi. Além disso, permitem a criação de diversos produtos financeiros interligados. A indústria tem defendido esse paradigma, muitas vezes chamado de "Lego do dinheiro".
No entanto, a capacidade de composição sem adaptabilidade ou padronização adequada apresenta desafios. Além de dificultar a conformidade dos desenvolvedores com os padrões do setor, como o ERC-20, também pode confundir os novos desenvolvedores. Sem a devida adaptação ou padronização, fica difícil revisar novas mudanças e verificar os detalhes de implementação das integrações.
Portanto, o ERC-4626 foi proposto para resolver esse problema e simplificar a integração, permitindo que os participantes do DeFi finalmente adotem uma especificação de cofre unificada mais segura e robusta. Isso, por sua vez, reduzirá a possível superfície de ataque do protocolo enquanto integra tokens em vários protocolos.
Quais problemas de segurança o ERC-4626 pode evitar?
Ao fornecer um padrão unificado, o ERC-4626 acelera a construção da integração entre protocolos. Padrões familiares e consistentes também são mais fáceis para os desenvolvedores entenderem, reduzindo a probabilidade de erros de codificação. Isso ajuda a evitar problemas de composição. A padronização também evita a duplicação de esforços, pois a comunidade só precisa projetar o cofre uma vez, em vez de individualmente para cada protocolo. Uma vez que esse esforço de design geralmente é propenso a erros, ele ajuda a evitar a duplicação de falhas de design estabelecidas, mas generalizadas.
Apresentaremos aqui dois estudos de caso para mostrar quais problemas o ERC-4626 pode prevenir.
Evento Rari Capital
Aproximadamente $ 11 milhões em tokens foram roubados da Rari Capital, o que equivale a 60% de todos os fundos do usuário no pool Rari Capital Ethereum.
No geral, a Rari Capital foi hackeada devido a uma implementação insegura entre protocolos. Seu pool Ethereum leva ETH para o contrato de token ibETH da Alpha Finance como uma estratégia de saída. Essa estratégia específica rastreia o valor de sua taxa de câmbio ibETH/ETH por meio de determinados contratos e fórmulas (especificamente, a função ibETH.totalETH / ibETH.totalSupply), que podem ter saídas errôneas nesse cenário de ataque, por exemplo, ao chamar ibETH.work ( ), os valores da dívida podem ser inflacionados artificialmente.
Um invasor pode esgotar o Rari Fund Manager simplesmente chamando repetidamente as funções de depósito e retirada no contrato RariFundManager. As funções de depósito e retirada precisam obter o saldo do pool para calcular a quantidade de tokens REPT a serem emitidos para o chamador, ou a quantidade de ETH a ser emitida para o chamador. Essa operação chamará a função getBalance do pool Alpha , chame o contrato ibETH e sua função totalETH . Rari não tem conhecimento da possibilidade de manipular esta função.
Há outra função no contrato ibETH: ibETH.work. Esta função pode chamar qualquer contrato especificado pelo usuário. Isso permite que as funções de depósito e retirada do Rari sejam reentrantes e sejam chamadas várias vezes.
A função trabalho é uma função paga, o que significa que o usuário pode controlar a quantidade de ETH no contrato ibETH por meio da função trabalho, alterando assim o valor retornado pela função totalETH. Para piorar a situação, a função de trabalho também suporta chamar qualquer outro contrato, como RariFundManager.
Por meio dessa função, o invasor pode enviar ETH novamente e aumentar o valor total de ETH no contrato ibETH e, ao mesmo tempo, chamar a retirada no contrato RariFundManager para resgatar mais ativos.
Este incidente destaca os riscos significativos representados pela integração insuficiente e projetos incompatíveis em contratos DeFi. Ele destaca como padrões como o ERC-4626 podem impedir tais ataques adicionando uma camada crítica de segurança e previsibilidade e promovendo comportamento uniforme e compreensão mútua.
Caso Financiamento Creme
A Cream Finance sofreu um ataque sofisticado que explorou duas fraquezas fundamentais na plataforma: um oráculo de mistura manipulado e um suprimento ilimitado de tokens. Uma parte fundamental do ataque foi a manipulação do oráculo de mistura, que afetou o valor percebido do token yUSD. Quando o invasor enviou uma grande quantidade de tokens Yearn 4-Curve para o cofre yUSD, ele alterou a taxa de câmbio relatada pelo cofre e, portanto, também afetou o valor percebido dos tokens yUSD para o oráculo.
A principal lição aqui é que um oráculo de preços robusto e não manipulável é fundamental para a estabilidade de um protocolo DeFi. Os oráculos de preço médio ponderado pelo tempo (TWAP) podem ajudar a evitar tais hacks porque são mais resistentes à manipulação repentina de preços.
Esses problemas e outros padrões de design frágeis podem ser mitigados por meio da adoção e implementação cuidadosas do ERC-4626.
Possíveis riscos de segurança no ERC-4626
Sempre há algumas compensações com o uso de um novo protocolo. Para cofres tokenizados, pode haver possíveis problemas para integrá-los a contratos inteligentes que requerem atenção especial.
Gerenciar tokens feeOnTransfer
Se o cofre for projetado para oferecer suporte a tokens feeOnTransfer, verifique se o valor e as ações no cofre estão dentro do intervalo esperado ao transferir ativos.
Uso apropriado da variável decimals
Embora a função convertTo não deva precisar usar a variável decimais do cofre EIP-4626, ainda é altamente recomendável espelhar os decimais do token subjacente sempre que possível. Essa prática ajuda a remover possíveis fontes de confusão e simplifica a integração para vários usuários front-end e fora da cadeia.
arredondamento
De acordo com a especificação, os implementadores do cofre devem estar cientes de que direções de arredondamento específicas e opostas são necessárias em diferentes métodos mutáveis e de exibição, pois é mais seguro priorizar o próprio cofre sobre seus usuários durante os cálculos:
Se estiver calculando o número de ações a serem emitidas para um usuário pelo valor de algum token subjacente que ele oferece, ou se estiver operando para transferir uma parte específica do token subjacente para um usuário, deve-se arredondar para baixo.
Se estiver calculando quantos compartilhamentos um usuário deve fornecer para obter uma certa quantidade de tokens de base, ou se estiver calculando quantos tokens de base um usuário deve fornecer para obter um determinado número de compartilhamentos, deve ser arredondado.
Onde a direção de arredondamento preferencial será ambígua é a função convertTo. Para garantir a consistência em todas as implementações de cofre EIP-4626, especifique que essas funções devem sempre ser arredondadas. Os próprios integradores podem imitar a versão arredondada, por exemplo, adicionando um Wei ao resultado.
A quantidade de ativos subjacentes que um usuário recebe ao resgatar sua participação no cofre (previewRedeem) pode variar significativamente do valor que teria que ser pago para emitir a mesma quantia de participação (previewMint). Essas diferenças podem ser pequenas (por exemplo, devido a erros de arredondamento) ou grandes (por exemplo, um cofre implementa taxas de retirada ou depósito). Portanto, os integradores devem ter o cuidado de usar as funções de visualização que melhor se adequam ao seu caso de uso e nunca presumir que sejam intercambiáveis.
Substituir a funcionalidade principal
Para implementar ou estender a funcionalidade pretendida, é recomendável usar ganchos existentes em vez de alterar a funcionalidade principal. Essa prática garante uma trilha mais gerenciável para testes e auditorias de código eficientes.
Compartilhamento zero
A especificação original para ERC-4626 não delineava como lidar com o caso extremo de nenhum compartilhamento no cofre e se o cofre deveria se comportar normalmente ou reverter. Isso pode ser uma fonte potencial de confusão e erros.
Cofres como oráculos de preço
Com relação ao risco de ataques de manipulação de preço do oráculo, os valores retornados por esses métodos de visualização são os mais próximos da precisão possível. Como tal, eles podem operar alterando as condições da cadeia e nem sempre são seguros para usar como oráculos de preço. A especificação ERC-4626 inclui um método convert e um método totalAssets que permitem imprecisão e, portanto, podem ser implementados como um poderoso oráculo de preço. Por exemplo, ao converter entre ativos e ações, é correto usar o preço médio ponderado no tempo para implementar o método de conversão.
Problemas concretos de implementação
Os integradores devem revisar qualquer implementação de cofre tokenizado antes da integração posterior, pois pode haver implementações maliciosas que parecem estar em conformidade com a especificação da interface, mas cujas funções principais consistem em especificações de design completamente diferentes.
Acesso Direto EOA
Se um cofre for acessado diretamente, sua implementação precisa ter recursos que possam ser usados para acomodar perdas por derrapagem ou limites acidentais de depósito/retirada. Ao contrário dos contratos inteligentes, o EOA não possui um mecanismo à prova de falhas para reversão de transação. Se a saída exata não for alcançada ao chamar a função principal, não há como reverter.
Cofre Estendido
À medida que mais players começarem a adotar o padrão ERC-4626, veremos mais extensões implementadas para o padrão. Por exemplo, a Superform desenvolveu uma extensão experimental do Multi Vault que suporta o uso de diferentes cálculos em um único contrato do Vault. Naturalmente, quanto mais a implementação se desviar do padrão original, maior a possibilidade de introdução de novas vulnerabilidades. Desenvolvedores e auditores podem encontrar sua melhor opção com base no caso de uso para determinar o valor real em risco.
É importante ressaltar que não é a menor adição de cada protocolo que leva a eventos catastróficos, mas a soma deles quando integrados.
Os potenciais vetores de ataque mencionados acima são alguns dos problemas mais discutidos em torno do padrão ERC-4626. À medida que a adoção aumenta, definitivamente exploraremos mais casos de uso de implementação e cenários mais adequados para integração com cofres ERC-4626.