Conecte-se conosco em afterdarklabs.xyz ou @afterdark_labs
Contexto
A EIP-2612 foi criada especificamente para permitir a aprovação de um token ERC20 na mesma transação em que é consumido. Isso se baseia em dois padrões anteriores: EIP-20 e EIP-712. Vamos cobrir brevemente alguns dos aspectos importantes destes dois padrões, mas se você não está familiarizado com nenhum deles, recomendamos que os revise antes de continuar com este artigo.
Resumo da EIP
A EIP-2612 pode ser vista como uma extensão da EIP-20. Para aqueles que não estão familiarizados com a EIP-20, é o padrão que descreve os requisitos da API para tokens ERC-20 não fungíveis. A EIP-2612 adiciona 3 novas funções ao padrão de token ERC-20: permit(), nonces() e DOMAIN_SEPARATOR().
A maior parte da funcionalidade adicionada pode ser encontrada na função permit() desta EIP. Ela leva o proprietário dos tokens ERC-20 (owner), a conta que receberá permissão para gastar em nome do proprietário (spender), o valor para definir a aprovação (value), um prazo (deadline) e uma assinatura para atualizar o mapeamento de aprovação do token ERC-20 (v, r e s).
Vamos dar uma olhada prática em como funciona a função permit(), analisando uma implementação dela pela popular biblioteca OpenZeppelin:
Função permit() como vista no contrato ERC20Permit.sol do OpenZeppelin
Vamos dividir isso em três seções:
Aplicação do Prazo
Nesta primeira linha, vemos que o prazo está sendo aplicado comparando-o à marca temporal (timestamp). Se a marca temporal do bloco atual for maior que o prazo, sabemos que o limite de tempo passou e revertemos a transação. Esta verificação permite que os usuários forneçam uma data de expiração para sua aprovação assinada.
Codificação do Hash de Assinatura
Nestas duas linhas, o hash dos parâmetros está sendo configurado para que uma assinatura possa ser recuperada dele. Observe que ele contém todas as informações relevantes mencionadas na EIP: o proprietário, gastador, valor e prazo. O empacotador _useNonce() é uma forma elegante de incrementar o nonce imediatamente após ter sido consumido. Construir o hash dessa forma significa que o signatário original precisa ter assinado todas essas mesmas informações para que a recuperação da assinatura funcione corretamente. O hash corretamente codificado da EIP-712 para este domínio é construído usando a struct hasheada e o separador de domínio.
Agora é um bom momento para sair da função permit() e discutir o separador de domínio. O separador de domínio é usado para limitar uma assinatura a um domínio. Isso é útil para garantir que os usuários não estejam assinando um cheque em branco. Ao incorporar informações como o nome do token ERC-20 e o chainID no domínio, a assinatura não deve se aplicar amplamente a outros aplicativos e cadeias.
Recuperação de Assinatura
Por último, recuperamos o endereço do signatário usando o hash assinado e os valores que representam a assinatura e o identificador de recuperação. A chamada ECDSA.recover é um empacotador em torno da pré-compilação ecrecover. Esta pré-compilação retorna a chave pública de uma assinatura, o identificador de recuperação e uma mensagem assinada. Se a chave pública corresponder ao proprietário, então sabemos que o proprietário originalmente assinou esta mensagem e a aprovação será feita.
E essa é a maior parte da funcionalidade adicionada! Agora vamos abordar alguns casos de uso e considerações de segurança para aqueles que consideram usar a funcionalidade EIP-2612 em seu protocolo.
Casos de Uso
Transações sem Gás
Um uso muito popular da EIP-2612 é para realizar transações sem gás. Como as assinaturas do estilo EIP-712 podem ser coletadas fora da cadeia, não se espera que o usuário seja a parte que publica a transação contendo a chamada para permit(). Protocolos podem, portanto, oferecer transações sem gás para seus usuários que, de outra forma, exigiriam que um usuário interagisse diretamente com um aplicativo.
Redução da Pegada de Aprovação
Como abordado em "Top 5 Smart Contract Vulnerabilities of 2023", aprovações não revogadas são uma grande fonte de fundos perdidos para usuários no DeFi. Utilizando a EIP-2612 para coletar assinaturas no local para aprovações, é viável para protocolos oferecerem a seus usuários uma experiência contínua sem exigir uma aprovação máxima permanente. Isso pode ajudar os usuários a reduzir sua pegada de aprovação e potencialmente mantê-los seguros durante ataques a protocolos.
Transações Agrupadas
Interações em aplicativos que lidam com tokens que fazem uso da EIP-2612 podem ser agrupadas. Agrupar pode melhorar a composabilidade intratransacional, permitindo que os usuários interajam com vários protocolos e potencialmente sejam menos suscetíveis a ataques de ordenação de transações. Transações agrupadas também podem se beneficiar da capacidade de serem feitas sem gás para os usuários.
Considerações de Segurança
Proteção contra Reprodução
É importante que o domínio de assinatura seja único, caso contrário, as assinaturas podem ser reproduzidas em domínios. Na prática, bibliotecas EIP-712 populares cuidam de grande parte disso para você. Recomendamos usar nomes e/ou versões únicas ao construir cada um dos seus tokens para melhorar a robustez da proteção contra reprodução.
Maleabilidade de Assinatura
A maleabilidade da assinatura ocorre quando assinaturas não únicas podem ser consideradas válidas para a mesma saída assinada. O código de operação da EVM ecrecover em si pode retornar o mesmo endereço para assinaturas não únicas. Semelhante a problemas de reprodução, muito disso pode ser mitigado usando bibliotecas populares que rejeitam um segundo conjunto de assinaturas que ecrecover aceitaria.
Falha Silenciosa do ecrecover
Como mencionado na própria EIP-2612, a pré-compilação ecrecover falha silenciosamente e retorna o endereço 0 para o signatário em caso de falha. Isso significa que é importante verificar se o signatário não é o endereço 0 ao realizar um permit(). A maioria das bibliotecas bem conhecidas leva isso em consideração ao lançar um erro quando ecrecover retorna 0.
Complexidade do Protocolo
Adicionar a funcionalidade EIP-2612 a um protocolo pode aumentar a complexidade. Além de adicionar capacidades de frontend para coleta de assinaturas, os próprios contratos geralmente requerem tanto a funcionalidade de permissão quanto a funcionalidade tradicional não baseada em assinatura. Portanto, os protocolos devem ter em mente o potencial aumento nos custos de implantação, bem como a complexidade ao escolher adicionar a funcionalidade EIP-2612.
Potencial de Censura
É típico para protocolos que implementam a funcionalidade EIP-2612 também enviar as transações em nome do usuário. Isso significa que o usuário depende do protocolo para enviar sua transação para interagir com seus aplicativos.
Pensamentos Finais
A EIP-2612 oferece funcionalidade adicional útil para protocolos que desejam oferecer transações sem gás ou agrupadas. Se implementada corretamente, também pode ajudar os usuários a reduzir sua pegada de aprovação e permitir que eles interajam com dApps de forma mais segura. Usar bibliotecas existentes pode ajudar as equipes de desenvolvimento a evitar armadilhas criptográficas comuns e implementar uma forma tradicional de interagir com seus dApps, além dos métodos EIP-2612, pode limitar o risco de problemas de censura.
Se você estiver interessado em uma auditoria de contrato inteligente ou outros serviços de segurança, inicie o processo visitando afterdarklabs.xyz ou entrando em contato diretamente com [email protected].
Artigo original publicado por AfterDark Labs. Traduzido por Paulinho Giovannini.
Top comments (0)