Ethereum Pectra atualização: Análise profunda do EIP-7702 e guia de melhores práticas

Introdução

Ethereum está prestes a receber a atualização Pectra, que é uma atualização de grande importância. Entre elas, a EIP-7702 realizou uma transformação revolucionária na conta externa de Ethereum (EOA). Esta proposta obscureceu a linha entre EOA e a conta de contrato CA, sendo um passo crucial em direção à abstração de contas nativas, trazendo um novo modo de interação para o ecossistema Ethereum.

Pectra já completou a implementação na rede de testes e espera-se que seja lançada na rede principal em breve. Este artigo irá aprofundar a mecânica de implementação do EIP-7702, explorar as oportunidades e desafios que pode trazer, e fornecer orientações práticas para os diferentes participantes.

Análise do Protocolo

Resumo

EIP-7702 introduz um novo tipo de transação, permitindo que EOA especifique um endereço de contrato inteligente e defina seu código. Isso permite que EOA execute código como um contrato inteligente, mantendo a capacidade de iniciar transações. Esta característica confere à EOA programabilidade e composibilidade, permitindo aos usuários implementar funcionalidades como recuperação social, controle de permissões, gestão de múltiplas assinaturas, verificação zk, pagamentos por assinatura, patrocínio de transações e processamento em lote de transações. Vale a pena notar que EIP-7702 é perfeitamente compatível com as carteiras de contrato inteligente implementadas pelo EIP-4337, simplificando o desenvolvimento e a aplicação de novas funcionalidades.

EIP-7702 introduziu o tipo de transação SET_CODE_TX_TYPE (0x04), cuja estrutura de dados está definida da seguinte forma:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, value, data, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

O campo authorization_list é definido como:

authorization_list = [[chain_id, address, nonce, y_parity, r, s], ...]

Na nova estrutura de transação, exceto pelo campo authorization_list, os demais seguem a mesma semântica do EIP-4844. authorization_list é do tipo lista e pode conter várias entradas de autorização. Cada entrada de autorização contém:

• chain_id representa a cadeia em que a autorização de delegação entra em vigor
• endereço indica o endereço alvo da delegação
• nonce deve corresponder ao nonce da conta autorizada atual
• y_parity, r, s são os dados de assinatura autorizados da conta autorizada

Uma transação pode conter uma lista de autorização com várias contas autorizadas diferentes, onde os itens de autorização são assinados por (EOA), permitindo que a operação de autorização do autorizador seja paga em gas.

realização

Quando o autorizador assina os dados de autorização, deve primeiro codificar chain_id, address e nonce usando RLP. Em seguida, os dados codificados são submetidos a uma operação de hash keccak256 junto com o número MAGIC, resultando nos dados a serem assinados. Por fim, o autorizador utiliza sua chave privada para assinar os dados hash, obtendo os dados y_parity, r e s. MAGIC (0x05) é usado como delimitador de domínio, garantindo que os resultados de diferentes tipos de assinaturas não entrem em conflito.

Quando o chain_id autorizado for 0, isso indica que o autorizador permite a reutilização da autorização em todas as cadeias compatíveis com EVM que suportam EIP-7702 (contanto que o nonce também coincida exatamente).

Após o autorizador assinar os dados de autorização, o iniciador da transação irá agregá-los no campo authorization_list para assinatura e transmitir a transação através do RPC. Antes da execução da transação, o Proposer fará uma pré-verificação para garantir que esta transação não seja uma transação de criação de contrato, ou seja, ao enviar uma transação do tipo EIP-7702, o endereço to da transação não pode estar vazio.

Este tipo de transação exige que o campo authorization_list contenha pelo menos uma entrada de autorização. Se várias entradas de autorização forem assinadas pelo mesmo autorizador, apenas a última entrada de autorização terá efeito.

Ao executar a transação, o nó primeiro aumenta o valor nonce do iniciador da transação, em seguida, aplica a operação applyAuthorization a cada entrada de autorização na authorization_list. Na operação applyAuthorization, o nó primeiro verifica o nonce do autorizador e, em seguida, aumenta o nonce do autorizador. Isso significa que se o iniciador da transação e o autorizador forem o mesmo usuário (EOA), o valor do nonce ao assinar a transação de autorização deve ser aumentado em 1.

Ao autorizar itens de aplicação de nó, se ocorrer algum erro, o item será ignorado, a transação não falhará e outros itens de autorização continuarão a ser aplicados, a fim de evitar riscos de DoS em cenários de autorização em massa.

Após a conclusão da aplicação de autorização, o campo code do endereço do autorizador será definido como 0xef0100 || address, onde 0xef0100 é uma identificação fixa e address é o endereço de destino da delegação. As restrições da EIP-3541 garantem que tal identificação só possa ser implantada por transações do tipo SET_CODE_TX_TYPE (0x04).

Após a autorização ser concluída, se o autorizar quiser remover a autorização, basta definir o endereço de destino delegado como o endereço 0.

A nova tipo de transação introduzido pelo EIP-7702 permite que o autorizador ( EOA ) execute códigos como um contrato inteligente, mantendo ao mesmo tempo a capacidade de iniciar transações. Em comparação com o EIP-4337, isso proporciona aos usuários uma experiência mais próxima da abstração de conta nativa ( Native AA ), reduzindo significativamente a barreira de entrada.

Melhores Práticas

O EIP-7702 traz nova vitalidade para o ecossistema Ethereum, ao mesmo tempo que novos cenários de aplicação trazem novos riscos. Abaixo estão os aspectos que os participantes do ecossistema devem estar atentos durante o processo de prática:

armazenamento de chave privada

Mesmo que a EOA possa resolver problemas de perda de fundos devido à perda da chave privada através de métodos como a recuperação social embutida em contratos inteligentes após a delegação, ainda não é possível evitar o risco de vazamento da chave privada da EOA. Após a execução da delegação, a chave privada da EOA ainda mantém o controle máximo da conta, e quem possui a chave privada pode dispor livremente dos ativos na conta. Mesmo que os usuários ou prestadores de serviços de carteira excluam completamente a chave privada armazenada localmente após concluir a delegação da EOA, não é possível eliminar completamente o risco de vazamento da chave privada, especialmente em cenários onde há risco de ataque à cadeia de suprimentos.

Para os usuários, ao usar contas após a delegação, a proteção da chave privada deve continuar a ser a prioridade, e é importante lembrar: Not your keys, not your coins.

Multi-chain replay

Ao assinar a autorização de delegação, o usuário pode escolher a cadeia em que a delegação entra em vigor através do chainId, ou pode escolher o chainId como 0 para delegar, permitindo que a delegação seja reproduzida em várias cadeias, facilitando que o usuário assine uma vez e delegue em várias cadeias. No entanto, é importante notar que pode haver diferentes códigos de implementação no mesmo endereço de contrato em várias cadeias.

Os prestadores de serviços de carteira devem verificar se a cadeia de efetivação da delegação corresponde à rede atualmente conectada quando o usuário realiza uma delegação, e alertar o usuário sobre os riscos que podem surgir ao assinar uma delegação com chainId igual a 0.

Os usuários também devem estar cientes de que os mesmos endereços de contrato em diferentes cadeias nem sempre têm o mesmo código de contrato, devendo primeiro entender claramente o objetivo da delegação.

não foi possível inicializar

As carteiras de contrato inteligente mais populares atualmente utilizam principalmente o modelo de proxy. O proxy da carteira, ao ser implantado, chama a função de inicialização do contrato através de DELEGateCALL, alcançando uma operação atômica entre a inicialização da carteira e a implantação da carteira proxy, evitando o problema de ser inicializado prematuramente. No entanto, quando o usuário utiliza EIP-7702 para delegar, apenas o campo code do seu endereço será atualizado, não sendo possível inicializá-lo através da chamada do endereço delegado. Isso faz com que o EIP-7702 não consiga chamar a função de inicialização durante a transação de implantação do contrato, como acontece com os contratos proxy ERC-1967 comuns.

Os desenvolvedores devem realizar verificações de permissões (como a verificação de permissões através da recuperação de endereço de assinatura usando ecrecover) durante a operação de inicialização da carteira ao combinar e adaptar o EIP-7702 com a carteira EIP-4337 existente, a fim de evitar o risco de a operação de inicialização da carteira ser ultrapassada.

Gestão de Armazenamento

Quando os usuários utilizam a funcionalidade de delegação EIP-7702, podem precisar re-delegar para um endereço de contrato diferente devido a mudanças nas necessidades funcionais, atualizações de carteira, entre outros motivos. No entanto, a estrutura de armazenamento de diferentes contratos pode apresentar diferenças (por exemplo, o slot0 de contratos diferentes pode representar tipos de dados distintos), e a re-delegação pode levar à reutilização acidental dos dados do contrato antigo pelo novo contrato, resultando em bloqueio de contas, perda de fundos e outras consequências indesejadas.

Os usuários devem lidar com cautela com situações de reatribuição.

Os desenvolvedores devem seguir a Namespace Formula proposta pelo ERC-7201 durante o processo de desenvolvimento, alocando variáveis em locais de armazenamento independentes designados, para mitigar o risco de conflitos de armazenamento. Além disso, o ERC-7779 (draft) também fornece um processo padrão de reatribuição especialmente para o EIP-7702: incluindo o uso do ERC-7201 para evitar conflitos de armazenamento, verificar a compatibilidade de armazenamento antes da reatribuição, e chamar a interface de delegação antiga para limpar os dados antigos do armazenamento.

Recarga falsa

Após o usuário realizar a delegação, o EOA também poderá ser utilizado como um contrato inteligente, portanto, a exchange centralizada (CEX) pode enfrentar uma situação de generalização do depósito de contratos inteligentes.

CEX deve verificar o estado de cada transação de recarga através do trace, para prevenir o risco de recargas falsas em contratos inteligentes.

Conversão de conta

Após a implementação da delegação EIP-7702, o tipo de conta do usuário pode ser convertido livremente entre EOA e SC, permitindo que a conta inicie transações e também seja chamada. Isso significa que, quando a conta se chama e realiza chamadas externas, seu msg.sender também será tx.origin, o que quebrará algumas suposições de segurança que limitam a participação de projetos apenas a EOA.

Os desenvolvedores de contratos não devem mais assumir que tx.origin é sempre EOA. Da mesma forma, a verificação através de msg.sender == tx.origin para defender contra ataques de reentrada também falhará.

Os desenvolvedores devem assumir durante o processo de desenvolvimento que os futuros participantes podem ser todos contratos inteligentes.

compatibilidade de contrato

Os tokens ERC-721 e ERC-777 existentes possuem a funcionalidade Hook ao realizar transferências de contratos, o que significa que o destinatário deve implementar a função de callback correspondente para receber os tokens com sucesso.

Os desenvolvedores devem garantir que o contrato-alvo delegado pelo usuário implemente as funções de callback correspondentes, a fim de assegurar a compatibilidade com os tokens principais.

Verificação de Phishing

Após a implementação da delegação EIP-7702, os ativos nas contas dos usuários poderão ser controlados por contratos inteligentes, e uma vez que o usuário delegue a conta para um contrato malicioso, será fácil para o atacante roubar os fundos.

Os prestadores de serviços de carteira devem apoiar rapidamente transações do tipo EIP-7702 e, ao realizar a assinatura delegada, destacar ao usuário o contrato alvo da delegação, a fim de mitigar o risco de ataques de phishing que o usuário possa sofrer.

Além disso, uma análise automática mais profunda dos contratos alvo da delegação da conta (verificação de código aberto, verificação de permissões, etc.) pode ajudar melhor os usuários a evitar tais riscos.

Resumo

Este artigo discute a proposta EIP-7702, que será incluída na próxima atualização Pectra do Ethereum. A EIP-7702 introduz novos tipos de transações, permitindo que os EOA tenham programabilidade e combinabilidade, borrando a linha entre EOA e contas de contrato. Como ainda não existem padrões de contratos inteligentes compatíveis com o tipo EIP-7702 testados em situações reais, diferentes participantes do ecossistema, como usuários, provedores de carteira, desenvolvedores, CEX, entre outros, enfrentam muitos desafios e oportunidades na aplicação prática. O conteúdo das melhores práticas descrito neste artigo não pode cobrir todos os riscos potenciais, mas ainda vale a pena para todas as partes considerarem sua aplicação nas operações práticas.