Pontos de Verificação de Segurança para Implementação de Abstração de Conta Baseada na EIP-4337

A Fairyproof realiza um estudo sobre a EIP-4337 e apresenta conclusões com pontos de verificação de segurança

EIP-4337 [1] é uma proposta para implementar a abstração de conta que permite aos usuários usar carteiras de contratos inteligentes em vez de uma (EOA) - Conta de Propriedade Externa - como sua conta principal.

A maior motivação para criar esta EIP é evitar mudanças na camada de consenso da Ethereum e implementar a abstração de contas principalmente em contratos inteligentes.

Uma característica significativa que uma solução de abstração de conta deve ter é simular transações que os usuários iniciam com EOAs. A maior diferença entre uma transação iniciada por uma EOA e uma iniciada por uma conta contratual é que uma EOA requer uma assinatura feita pela chave privada da EOA.

Para implementar tal solução, cinco conceitos são introduzidos nesta proposta: "UserOperation", "Bundler", "EntryPoint", "Paymaster" e "Aggregator".

Uma "UserOperation" é uma estrutura de dados que define uma transação iniciada a partir de uma EOA. Nesta EIP, ela deve ser implementada e enviada para um mempool (pool de memória) separado.

Um "Bundler" é um construtor de blocos que coleta as operações do usuário a partir do mempool, ou um usuário que pode enviar transações para um construtor de blocos. Após um Bundler coletar as UserOperations, ele as enviará para um contrato especial definido como um "Ponto de Entrada" (EntryPoint).

Um "EntryPoint" é um contrato inteligente que valida e executa as UserOperations enviadas por Bundlers.

Um "Paymaster" é um contrato inteligente que pode ajudar a pagar taxas de transação em nome de um usuário. Este recurso é opcional e pode ser usado para permitir que os usuários paguem taxas com tokens EIP-20.

Um "Aggregator" é um contrato de ajuda. Este recurso também é opcional e é usado para validar assinaturas agregadas.

Em essência, a lógica proposta nesta EIP é a seguinte:

Como uma empresa de segurança em blockchain, a Fairyproof estudou esta EIP e esperava encontrar todos os pontos de controle de segurança que deveriam ser mantidos em mente ao auditar uma solução implementada com base nesta EIP.

Estudamos estes cinco conceitos e seus detalhes de implementação propostos. Aqui estão nossas descobertas com os pontos de controle de segurança:

1 . Pontos de Verificação de Segurança para Implementação de UserOperation

Um problema significativo de segurança na lógica proposta pela EIP é que atores mal-intencionados poderiam lançar ataques DOS enviando UserOperations inválidas para enganar o EntryPoint a executar essas operações sem pagar taxas.

Portanto, a validação de UserOperations em todas as interfaces não pode ser ignorada.

As seguintes verificações devem ser feitas para UserOperation:

Ou o remetente é um contrato existente ou o initCode não está vazio (mas não ambos)

Se o initCode não estiver vazio, analise seus primeiros 20 bytes como um endereço de fábrica e verifique se a fábrica está apostada ou ( depositada ). Se a fábrica acessar o estado global, ela deve estar apostada ou ( depositada ).

O verificationGasLimit deve ser suficientemente baixo (<= MAX_VERIFICATION_GAS) e o preVerificationGas deve ser suficientemente alto (suficiente para pagar o custo de gás de calldata da serialização da UserOperation mais PRE_VERIFICATION_OVERHEAD_GAS)

O paymasterAndData está vazio ou começa com o endereço do paymaster que é um contrato que (i) atualmente possui código não vazio na cadeia, (ii) tem um depósito suficiente para pagar pela UserOperation e (iii) não está atualmente banido.

O callgas é pelo menos o custo de uma chamada com valor diferente de zero.

O maxFeePerGas e o maxPriorityFeePerGas devem estar acima de um valor mínimo configurável que o cliente está disposto a aceitar. No mínimo, eles são suficientemente altos para serem incluídos com a block.basefee atual.

Apenas uma UserOperation por remetente pode ser incluída em um único lote. Um remetente está isento dessa regra e pode ter várias UserOperations no pool e em um lote se estiver apostada ou ( depositada ).

2 . Pontos de Verificação de Segurança para a Implementação de EntryPoint's

O parâmetro "UserOperation" nas interfaces handlOps e simulateValidation deve ser verificado.

Particularmente na estrutura de dados UserOperation: o campo "sender" deve ser um endereço contratual inteligente e não um endereço EOA, o valor "nonce" deve ser único para evitar ataques de replay, o "initCode" não deve ser nulo se a conta não estiver na cadeia e precisar ser criada, a "signature" deve ser dependente do chainid e do endereço do EntryPoint para evitar ataques de replay.

O parâmetro "beneficiary" no handleOps e handleAggregatedOps deve ser um endereço de beneficiário válido.

O EIP sugere que o contrato do EntryPoint seja atualizável. O endereço que tem controle de acesso para atualizar o contrato deve ser gerenciado com cuidado e cautela. Caso seja comprometido, o EntryPoint estará exposto a enormes riscos.

3 . Pontos de verificação de segurança para a implementação da IAggregatedAccount

O parâmetro "userOp" na interface de validateUserOp deve ser verificado. Os pontos acima mencionados para "UserOperation" também se aplicam a isto.

O parâmetro "aggregator" deve ser um endereço válido se um agregador for usado ou pode ser ignorado se nenhum agregador for usado. E deve ser o mesmo que o valor de retorno da interface "getAggregator".

O parâmetro "userOpHash" deve ser um valor não-nulo e deve ser um hash sobre o userOp (exceto assinatura), EntryPoint e chainId.

Com relação à implementação da interface validateUserOp, as seguintes coisas devem ser verificadas:

• se seu chamador é um EntryPoint confiável e um endereço de contrato inteligente.

• Se a conta não suportar agregação de assinatura, ela deve verificar se a assinatura é um hash válido do userOpHash, e deve retornar SIG_VALIDATION_FAILED (e não reverter) se a assinatura não corresponder. Se qualquer outro erro ocorrer, a transação deve ser revertida.

• deve pagar seu chamador (EntryPoint) pelo menos o "missingAccountFunds" e pode precisar pagar mais para cobrir transações futuras.

A interface de validateUserOp deve ser verificada e as operações correspondentes devem ser realizadas de acordo com o valor de retorno.

4 . Pontos de verificação de segurança para a implementação do IAggregator

O parâmetro "userOp" na validateUserOpSignature, aggregateSignatures e validateSignatures interfaces deve ser verificado. Os pontos acima mencionados para "UserOperation" também se aplicam a isto.

O parâmetro "signature" no validateSignatures deve ser um valor não-nulo.

Com relação à implementação do Agregador, as seguintes coisas devem ser verificadas especificamente:

• validateSignatures() deve validar as correspondências de assinaturas agregadas para todas as UserOperations na matriz, e reverter o contrário.

• Um agregador deve investir para ser confiável, a menos que seja isento de outra forma.

5. Pontos de verificação de segurança para a implementação do Paymaster

O parâmetro "userOp" na interface validatePaymasterUserOp deve ser verificado. Os pontos acima mencionados para "UserOperation" também se aplicam a isto.

O parâmetro "userOpHash" deve ser um valor não-nulo e ser um hash sobre o userOp (exceto assinatura), EntryPoint e chainId.

O parâmetro "withdrawAddress" nas interfaces withdrawStake e withdrawTo deve ser um endereço válido.

O parâmetro "account" no balanceOf e depositTo das interfaces deve ser um endereço válido não zero.

O parâmetro "withdrawAmount" na interface withdrawalTo não deve ser maior que o valor de retorno da interface balanceOf.

Um Paymaster deve ser um endereço de contrato inteligente válido se ele for introduzido.

Um Paymaster deve ter criptoativos suficientes para pagar operações relevantes, caso seja introduzido.

Um Paymaster deve apostar (ou depositar) para ser confiável.

Conclusão

Estes pontos de controle de segurança não cobrem todos os problemas potenciais de segurança que esta EIP pode introduzir ao implementar uma solução. Eles são apenas o que a Fairyproof está especificamente ciente ao auditar tal solução.

Além destes pontos de verificação, há outras questões importantes que têm sido amplamente discutidas nesta EIP. Estas questões estão principalmente relacionadas a questões lógicas e devem ser levadas em consideração seriamente também quando da auditoria.

Referência:

[1] EIP-4337: Abstração de conta usando Alt Mempool, https://eips.ethereum.org/EIPS/eip-4337

Vitalik Buterin (@vbuterin), Yoav Weiss (@yoavw), Kristof Gazso (@kristofgazso), Namra Patel (@namrapatel), Dror Tirosh (@drortirosh), Shahaf Nacson (@shahafn), Tjaden Hess (@tjade273), "ERC-4337: Abstração de Conta Usando Alt Mempool [DRAFT]," Ethereum Improvement Proposals, no. 4337, setembro de 2021. [Série online]. Disponível em: https://eips.ethereum.org/EIPS/eip-4337.

Artigo escrito por Fairyproof Tech e traduzido para o português por Rafael Ojeda

Você pode ler o artigo original aqui.