Atualização do Ethereum Pectra em EIP-7702: uma grande mudança que capacita EOA

Introdução

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

A Pectra já completou a implementação na rede de testes e espera-se que em breve seja lançada na rede principal. Este artigo irá analisar em profundidade o mecanismo de implementação do EIP-7702, discutir as oportunidades e desafios que pode trazer, e fornecer um guia prático para os diferentes participantes.

Análise de Protocolo

Resumo

EIP-7702 introduz um novo tipo de transação que permite que EOA especifique um endereço de contrato inteligente, permitindo que defina código para ele. Assim, EOA pode executar código como um contrato inteligente, mantendo a capacidade de iniciar transações. Esta característica confere programabilidade e composabilidade ao EOA, permitindo que os usuários implementem funcionalidades como recuperação social, controle de permissões, gestão de múltiplas assinaturas, verificação zk, pagamentos por subscrição, patrocínio de transações e processamento em lote de transações. Vale mencionar que EIP-7702 é perfeitamente compatível com as carteiras de contrato inteligente implementadas pelo EIP-4337, e a integração sem costura entre os dois simplifica enormemente o desenvolvimento e a aplicação de novas funcionalidades.

A implementação específica do EIP-7702 introduz um tipo de transação chamado SET_CODE_TX_TYPE (0x04), cuja estrutura de dados é 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, além do campo authorization_list, os restantes seguem a mesma semântica que o EIP-4844. Este campo é do tipo lista, onde podem estar incluídos vários itens de autorização, sendo que em cada item de autorização:

• O campo chain_id indica a cadeia em que esta delegação de autorização é válida.
• O campo endereço representa o endereço de destino da delegação
• O campo nonce deve corresponder ao nonce da conta autorizada atual.
• y_parity, r, s campos são os dados de assinatura autorizados da conta autorizada

No campo authorization_list de uma transação podem ser incluídas 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 as operações de autorização sejam pagas com gas pelo autorizador.

implementação

O autorizador, ao assinar os dados de autorização, precisa primeiro codificar o chain_id, address e nonce usando RLP. Em seguida, os dados codificados são submetidos a uma operação de hash keccak256 juntamente com o número MAGIC, obtendo assim os dados a serem assinados. Por fim, usa-se a chave privada do autorizador para assinar os dados hash, obtendo assim os dados y_parity, r, s. Dentre eles, o MAGIC (0x05) é usado como delimitador de domínio, com o objetivo de garantir que os resultados de tipos diferentes de assinatura não entrem em conflito.

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

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 via RPC. Antes que a transação seja executada e incluída em um bloco, o Proposer fará uma verificação preliminar da transação, na qual o endereço to será verificado de forma rigorosa para garantir que esta transação não é 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.

Ao mesmo tempo, este tipo de transação exigirá que o campo authorization_list na transação contenha pelo menos um item de autorização. Se houver vários itens de autorização assinados pelo mesmo autorizador, apenas o último item de autorização terá efeito.

Em seguida, durante o processo de execução da transação, o nó aumentará primeiro o valor nonce do iniciador da transação, e depois 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, em seguida, aumentará o nonce do autorizador. Isso significa que se o iniciador da transação e o autorizador forem o mesmo usuário (EOA), ao assinar a transação de autorização, o valor do nonce deve ser aumentado em 1.

Ao aplicar um determinado item de autorização em um nó, se ocorrer qualquer 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 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 é um identificador fixo e address é o endereço de destino delegado. Devido às limitações do EIP-3541, os usuários não conseguem implantar código de contrato que comece com o byte 0xef de maneira convencional, o que garante que tal identificador só possa ser implantado 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 delegada 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, enquanto 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. Abaixo estão os aspectos que os participantes do ecossistema precisam estar atentos durante o processo prático:

armazenamento de chave privada

Mesmo que o EOA possa resolver problemas de perda de fundos devido ao desaparecimento da chave privada por meio de técnicas como a recuperação social embutida em contratos inteligentes após a delegação, ele ainda não consegue 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. Usuários ou prestadores de serviços de carteira, após concluírem a delegação para o EOA, mesmo que apaguem completamente a chave privada armazenada localmente, não podem eliminar totalmente o risco de vazamento da chave privada, especialmente em cenários onde existem riscos de ataques à cadeia de suprimentos.

Para os utilizadores, ao utilizar a conta após a delegação, deve sempre dar prioridade à proteção da chave privada e ter sempre em mente: Not your keys, not your coins.

múltiplas cadeias de replay

Os usuários, ao assinar a autorização de delegação, podem escolher a cadeia em que a delegação pode ser efetiva através do chainId. Claro, os usuários também podem optar por usar o chainId 0 para delegar, o que permite que a delegação seja reproduzida e efetiva em múltiplas cadeias, facilitando assim que os usuários façam a delegação com uma única assinatura em várias cadeias. No entanto, é importante notar que, no mesmo endereço de contrato em múltiplas cadeias, pode haver diferentes códigos de implementação.

Para os provedores de serviços de carteira, ao realizar uma delegação pelo usuário, deve-se verificar se a cadeia de efetivação da delegação corresponde à rede atualmente conectada e alertar os usuários sobre os riscos que podem surgir ao assinar uma delegação com chainId igual a 0.

Os usuários também devem notar que, em diferentes blockchains, 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 populares atualmente utiliza um modelo de proxy. Durante a implantação, o proxy da carteira chama a função de inicialização do contrato através de DELEGateCALL, realizando assim uma operação atômica de inicialização da carteira e implantação do proxy da carteira, evitando o problema de inicialização antecipada. No entanto, ao usar o EIP-7702 para delegação, o usuário apenas atualiza o campo code de seu endereço, não conseguindo inicializar chamando o endereço delegado. Isso impede que o EIP-7702 possa chamar a função de inicialização durante a transação de implantação do contrato, como acontece com contratos proxy comuns ERC-1967.

Para os desenvolvedores, ao combinar o EIP-7702 com carteiras existentes do EIP-4337, deve-se ter cuidado em realizar verificações de permissão durante a operação de inicialização da carteira (por exemplo, verificando a permissão através da recuperação de assinatura com ecrecover), para evitar o risco de a operação de inicialização da carteira ser antecipada.

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 alterações 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 diferentes tipos de dados). Em caso de re-delegação, isso pode levar à reutilização acidental dos dados do antigo contrato pelo novo contrato, resultando em bloqueio de contas, perda de fundos e outras consequências negativas.

Para os utilizadores, deve-se ter cautela ao lidar com a situação de 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 fluxo padrão de reatribuição especialmente para o EIP-7702: incluindo o uso do ERC-7201 para evitar conflitos de armazenamento, e a verificação da compatibilidade de armazenamento antes da reatribuição, bem como a chamada da interface da antiga atribuição para limpar os dados antigos do armazenamento.

Recarga falsa

Após a delegação, o EOA também poderá ser utilizado como um contrato inteligente, portanto, as exchanges centralizadas (CEX) poderão enfrentar a situação de generalização do depósito de contratos inteligentes.

As CEX deve verificar o status 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, 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 faz uma chamada externa, seu msg.sender também será tx.origin, o que quebrará algumas suposições de segurança que limitam a participação de EOA em projetos.

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 podem ser contratos inteligentes.

compatibilidade de contratos

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.

Para os desenvolvedores, o contrato-alvo delegado pelo usuário deve implementar a função de callback correspondente, para garantir a compatibilidade com os tokens mais utilizados.

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. Uma vez que o usuário delegue a conta a um contrato malicioso, será fácil para o atacante roubar fundos.

Para os prestadores 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 mostrar aos usuários o contrato alvo da delegação, a fim de mitigar o risco de ataques de phishing que os usuários possam sofrer.

Além disso, uma análise automática mais aprofundada 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

EIP-7702, ao introduzir um novo tipo de transação, confere ao EOA programabilidade e composição, borrando as fronteiras entre EOA e contas de contrato. Como ainda não existe um padrão de contrato inteligente compatível com EIP-7702 que tenha sido testado na prática, diferentes participantes do ecossistema, como usuários, provedores de serviços de carteira, desenvolvedores, CEX, etc., enfrentam muitos desafios e oportunidades na aplicação prática. O conteúdo das melhores práticas descritas neste artigo não consegue abranger todos os riscos potenciais, mas ainda assim vale a pena para todas as partes considerar sua aplicação na operação prática.