Ethereum Pectra Upgrade: As Transformações e Desafios Trazidos pelo EIP-7702

Introdução

Ethereum está prestes a receber a atualização Pectra, que é uma atualização significativa, trazendo várias propostas importantes de melhoria para o Ethereum. Entre elas, a EIP-7702 realiza uma transformação revolucionária na conta externa do Ethereum (EOA). Esta proposta obscurece a linha entre a EOA e a conta de contrato CA, sendo um passo crucial em direção à abstração de contas nativa, após a EIP-4337, trazendo um novo modo de interação para o ecossistema Ethereum.

Pectra já completou a implantação na rede de testes e deverá ser lançado em breve na rede principal. Este artigo analisará em profundidade o mecanismo de implementação do EIP-7702, explorando as oportunidades e desafios que pode trazer, além de fornecer recomendações práticas de operação para diferentes participantes.

Análise de Protocólo

Visão Geral

EIP-7702 introduz um novo tipo de transação que permite 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 programabilidade e composibilidade ao EOA, permitindo que os usuários implementem funções como recuperação social, controle de permissões, gestão de multi-assinaturas, verificação zk, pagamentos por assinatura, patrocínio de transações e processamento em lote de transações. Vale a pena notar que o EIP-7702 é perfeitamente compatível com as carteiras de contrato inteligente implementadas pelo EIP-4337, e a integração perfeita entre os dois simplifica enormemente o desenvolvimento e a aplicação de novas funcionalidades.

EIP-7702 introduziu um tipo de transação como SET_CODE_TX_TYPE (0x04), cuja definição da estrutura de dados é a seguinte:

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, além do campo authorization_list, os restantes seguem a mesma semântica do EIP-4844. Este campo é do tipo lista e pode conter várias entradas de autorização, cada entrada de autorização contém:

• chain_id indica a cadeia na qual esta autorização de delegação é válida
• endereço indica o endereço alvo da delegação
• o nonce deve corresponder ao nonce da conta autorizada atual
• y_parity, r, s são os dados da assinatura autorizada da conta autorizada

O campo authorization_list de uma transação pode conter várias entradas de autorização assinadas por diferentes contas autorizadas ( EOA ), ou seja, o iniciador da transação pode ser diferente do autorizador, permitindo que a operação de autorização do autorizador seja paga em gas.

realizar

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 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, s. MAGIC (0x05) é usado como delimitador de domínio, garantindo que os resultados de diferentes tipos de assinatura não entrem em conflito.

É importante notar que, quando o chain_id autorizado é 0, isso significa que o autorizador permite a reutilização da autorização em todas as cadeias compatíveis com EVM que suportam o EIP-7702 (desde que o nonce também coincida).

Após o autorizador assinar os dados de autorização, o iniciador da transação reunirá esses dados no campo authorization_list para assinatura e transmitirá a transação via RPC. Antes que a transação seja executada e incluída no bloco, o Proposer realizará uma verificação preliminar na transação, na qual o endereço to será rigorosamente verificado para garantir que esta transação não seja uma transação de criação de contrato.

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

Durante o processo de execução da transação, o nó aumentará primeiro o valor nonce do iniciador da transação e, em seguida, realizará a operação applyAuthorization em cada entrada de autorização na authorization_list. Na operação applyAuthorization, o nó verificará primeiro o nonce do autorizador e depois aumentará o nonce do autorizador. Isso significa que se o iniciador da transação e o autorizador forem o mesmo usuário (EOA), o valor nonce deve ser aumentado em 1 ao assinar a transação de autorização.

Quando um nó aplica um determinado item de autorização, se encontrar algum erro, esse item de autorização será ignorado, a transação não falhará e outros itens de autorização continuarão a ser aplicados, garantindo assim que não haja risco de DoS em cenários de autorização em lote.

Após a conclusão da aplicação de autorização, o campo code do endereço do autorizador será configurado como 0xef0100 || address, onde 0xef0100 é um identificador fixo e address é o endereço alvo da delegação. Devido às limitações do EIP-3541, os usuários não conseguem implantar códigos de contrato que começam com bytes 0xef de maneira convencional, garantindo que tais identificadores só possam ser implantados por transações do tipo SET_CODE_TX_TYPE ( 0x04).

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

O novo tipo de transação introduzido pelo EIP-7702 permite que o autorizador ( EOA ) execute código como um contrato inteligente, ao mesmo tempo que mantém 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 para os usuários.

Melhores Práticas

Apesar de o EIP-7702 ter injetado nova vitalidade no ecossistema Ethereum, novos cenários de aplicação também trarão novos riscos. A seguir, estão os aspectos que os participantes do ecossistema precisam estar atentos durante a prática:

armazenamento de chave privada

Mesmo que o 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 assim não pode evitar o risco de vazamento da chave privada do EOA. É importante esclarecer que, após a execução da delegação, a chave privada do EOA ainda possui o controle máximo sobre a conta; quem detém a chave privada pode dispor livremente dos ativos na conta. Após a delegação do EOA, os usuários ou prestadores de serviços de carteira, mesmo que excluam completamente a chave privada armazenada localmente, não podem eliminar totalmente o risco de vazamento da chave privada, especialmente em cenários onde existe o risco de ataque à cadeia de suprimentos.

Para os usuários, ao usar a conta após a delegação, a proteção da chave privada deve ser a prioridade, sempre lembrando: Not your keys, not your coins.

múltiplas cadeias de retransmissão

Os usuários, ao assinar uma autorização de delegação, podem selecionar a cadeia em que a delegação pode ser válida através do chainId, podendo também optar por usar o chainId igual a 0 para que a delegação possa ser reproduzida em várias cadeias, facilitando a delegação em várias cadeias com uma única assinatura. No entanto, é importante notar que, no mesmo endereço de contrato em várias cadeias, pode haver diferentes códigos de implementação.

Para os prestadores de serviços de carteira, ao realizar uma delegação, deve-se verificar se a cadeia de ativação da delegação corresponde à rede atualmente conectada e alertar os usuários sobre os riscos que a assinatura de uma delegação com chainId igual a 0 pode acarretar.

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

não foi possível inicializar

A maioria das carteiras de contratos inteligentes atualmente populares utiliza um modelo de proxy. O proxy da carteira, ao ser implantado, chamará a função de inicialização do contrato por meio do DELEGateCALL, para realizar a operação atômica de inicialização da carteira e implantação da carteira proxy, evitando o problema de ser inicializado prematuramente. No entanto, ao usar o EIP-7702 para delegação, o usuário apenas atualizará o campo code do seu endereço, não conseguindo inicializar chamando o endereço delegado. Isso faz com que o EIP-7702 não possa chamar a função de inicialização durante a transação de implantação do contrato, como ocorre com o comum contrato proxy ERC-1967 para inicialização da carteira.

Para os desenvolvedores, ao combinar o EIP-7702 com a carteira existente EIP-4337, deve-se realizar uma verificação de permissões na operação de inicialização da carteira (por exemplo, verificando a permissão através da recuperação de endereço de assinatura com ecrecover), a fim de evitar o risco de a operação de inicialização da carteira ser ultrapassada.

Gestão de Armazenamento

Os usuários, ao utilizarem a funcionalidade de delegação EIP-7702, podem precisar redistribuir 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 dos diferentes contratos pode variar (por exemplo, o slot0 de contratos diferentes pode representar diferentes tipos de dados). No caso de uma nova delegação, isso pode levar à reutilização acidental dos dados do contrato antigo pelo novo contrato, resultando em bloqueio de conta, perda de fundos e outras consequências negativas.

Para os utilizadores, deve-se ter cautela ao lidar com a situação da reatribuição.

Para os desenvolvedores, durante o processo de desenvolvimento, deve-se seguir a Namespace Formula proposta pelo ERC-7201, alocando variáveis em locais de armazenamento independentes designados, a fim de mitigar o risco de conflitos de armazenamento. Além disso, o ERC-7779 (draft) também fornece um processo padrão de reatribuição especificamente para o EIP-7702: incluindo a utilização do ERC-7201 para prevenir conflitos de armazenamento, e validar a compatibilidade de armazenamento antes da reatribuição, bem como chamar a interface do antigo delegado para limpar os dados antigos do armazenamento.

Recarga falsa

Após realizar a delegação, a EOA também poderá ser utilizada como um contrato inteligente, portanto, algumas bolsas podem enfrentar a situação de generalização do depósito de contratos inteligentes.

As exchanges devem verificar o estado de cada transação de recarga através do trace, a fim de 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, o que permite que a conta inicie transações e também seja chamada. Isso significa que, quando a conta chama a si mesma e realiza uma chamada externa, seu msg.sender será também tx.origin, o que quebrará algumas suposições de segurança que limitam a participação de projetos apenas a EOA.

Para os desenvolvedores de contratos, assumir que tx.origin é sempre EOA não será mais viável. 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 poderão ser contratos inteligentes.

compatibilidade de contrato

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

Para os desenvolvedores, os contratos-alvo delegados pelos usuários devem implementar as funções de callback correspondentes, para garantir a compatibilidade com os tokens mais populares.

Verificação de Phishing

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

Para os provedores de serviços de carteira, é especialmente importante apoiar rapidamente transações do tipo EIP-7702, e, quando os usuários realizam assinaturas delegadas, deve-se enfatizar aos usuários a exibição do contrato de destino da delegação, a fim de mitigar o risco de ataques de phishing que os usuários podem sofrer.

Além disso, uma análise automática mais aprofundada dos contratos-alvo da delegação de contas (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 na iminente atualização Pectra do Ethereum. A EIP-7702, ao introduzir um novo tipo de transação, confere programabilidade e combinabilidade ao EOA, borrando a linha entre EOA e contas de contrato. Como ainda não existe um padrão de contrato inteligente compatível com o tipo EIP-7702 que tenha sido testado em situações reais, diferentes participantes do ecossistema, como usuários, provedores de carteiras, desenvolvedores e exchanges, enfrentam muitos desafios e oportunidades na prática. O conteúdo das melhores práticas abordadas neste artigo não consegue cobrir todos os riscos potenciais, mas ainda é digno de consideração e aplicação por todas as partes envolvidas na operação prática.