Atualização Pectra do Ethereum: 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 significativa, com várias propostas importantes de melhoria do Ethereum a serem introduzidas. Entre elas, a EIP-7702 trouxe uma transformação revolucionária para a conta externa do Ethereum (EOA). Esta proposta obscureceu a linha entre EOA e conta de contrato CA, sendo um passo crucial em direção à abstração de contas nativas, após a EIP-4337, trazendo um novo modo de interação para o ecossistema Ethereum.

A Pectra já concluiu a implantação na rede de teste e deverá ser lançada em breve na rede principal. Este artigo irá analisar detalhadamente o mecanismo de implementação do EIP-7702, explorar as oportunidades e desafios que pode trazer, e fornecer um guia prático para os diferentes participantes.

Análise do Protocolo

Resumo

O EIP-7702 introduz um novo tipo de transação que permite que um EOA especifique um endereço de contrato inteligente, permitindo assim que ele configure código. Dessa forma, o EOA pode executar código como um contrato inteligente, mantendo a capacidade de iniciar transações. Essa característica confere ao EOA programabilidade e combinabilidade, permitindo que os usuários implementem funções como recuperação social, controle de permissões, gestão de múltiplas assinaturas, validação zk, pagamentos por assinatura, patrocínio de transações e processamento em lote de transações. Vale ressaltar que o EIP-7702 é perfeitamente compatível com as carteiras de contratos inteligentes implementadas pelo EIP-4337, e a integração sem costura entre os dois simplifica enormemente o processo de desenvolvimento e aplicação de novas funcionalidades.

A implementação específica do EIP-7702 introduziu um tipo de transação 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, e a lista pode conter múltiplas entradas de autorização, onde em cada entrada de autorização:

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

No campo authorization_list de uma transação podem estar incluídas várias contas autorizadas diferentes, com entradas de autorização assinadas por (EOA), ou seja, o iniciador da transação pode ser diferente do autorizador, permitindo que a operação de autorização seja paga em gas pelo autorizador.

implementação

O autorizador, ao assinar os dados de autorização, precisa 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, obtendo assim os dados a serem assinados. Por fim, utiliza-se a chave privada do autorizador para assinar os dados hash, obtendo assim os dados y_parity, r e s. Entre eles, o MAGIC (0x05) é utilizado como um delimitador de domínio, com o objetivo de garantir 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 repetição da autorização ( em todas as cadeias compatíveis com EVM que suportam EIP-7702, desde que o nonce também coincida exatamente com ).

Após o autorizador assinar os dados de autorização, o iniciador da transação irá agrupá-los no campo authorization_list para assinatura e transmiti-los através de RPC. Antes que a transação seja executada ao ser incluída em um bloco, o Proposer irá realizar uma pré-verificação da transação, na qual o endereço to será verificado obrigatoriamente para garantir que esta transação não seja uma 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 exige 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 autorizado, apenas o último item de autorização terá efeito.

Em seguida, durante o processo de execução da transação, o nó primeiro aumentará 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ó 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), ao assinar a transação de autorização, o valor nonce deve ser aumentado em 1.

Ao aplicar um determinado item de autorização em um nó, se ocorrer 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 massa.

Após a conclusão da aplicação autorizada, o campo code do endereço do autorizador será definido como 0xef0100 || address, onde 0xef0100 é um identificador fixo e address é o endereço alvo da delegação. Devido às limitações da EIP-3541, os usuários não conseguem implantar código de contrato que comece com bytes 0xef através de métodos convencionais, o que garante 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, enquanto mantém a capacidade de iniciar transações. Em comparação com o EIP-4337, isso oferece aos usuários uma experiência mais próxima da abstração de contas nativas (Native AA), reduzindo significativamente a barreira de entrada para os usuários.

Melhores Práticas

Embora o EIP-7702 tenha 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 o processo prático:

armazenamento de chave privada

Apesar de o EOA poder resolver problemas de perda de fundos devido à perda de chave privada através de métodos como 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 detém o controle máximo sobre a conta; possuir a chave privada permite dispor livremente dos ativos na conta. Mesmo que usuários ou prestadores de serviços de carteira excluam completamente a chave privada armazenada localmente após completar a delegação para o EOA, não podem eliminar totalmente o risco de vazamento da chave privada, especialmente em cenários onde existe risco de ataque à cadeia de suprimentos.

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

Repetição de múltiplas cadeias

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

Para os prestadores de serviços de carteira, ao realizar um mandato pelo usuário, devem verificar se a cadeia de eficácia do mandato coincide com a rede atualmente conectada e alertar o usuário sobre os riscos que podem advir da assinatura de um mandato com chainId igual a 0.

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 entender claramente o objetivo da delegação.

não foi possível inicializar

As carteiras de contratos inteligentes mais populares atualmente adotam principalmente um modelo de proxy. O proxy da carteira, ao ser implantado, chamará a função de inicialização do contrato através do DELEGateCALL, alcançando assim uma operação atômica entre a inicialização da carteira e a implantação do proxy da carteira, evitando o problema de ser inicializado antes. No entanto, ao usar o EIP-7702 para delegação, o que acontece é que somente o campo code do endereço é atualizado, não sendo possível inicializar chamando o endereço delegado. Isso significa que o EIP-7702 não pode 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 para inicializar a carteira.

Para os desenvolvedores, ao combinar e adaptar o EIP-7702 com a carteira existente EIP-4337, deve-se ter em mente a verificação de permissões durante a operação de inicialização da carteira (, por exemplo, realizando a verificação de permissões através da recuperação da assinatura do endereço utilizando ecrecover ), para evitar o risco de a operação de inicialização da carteira ser apressada.

Gestão de Armazenamento

Os usuários que utilizam a funcionalidade de delegação EIP-7702 podem precisar re-delegar para diferentes endereços de contrato 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, como por exemplo, o slot0 de contratos diferentes pode representar diferentes tipos de dados. Em caso de re-delegação, isso pode causar a reutilização acidental dos dados de contratos antigos pelo novo contrato, resultando em bloqueio de conta, perda de fundos e outras consequências indesejadas.

Os utilizadores devem ser cautelosos ao lidar com a situação de reatribuição.

Para os desenvolvedores, durante o processo de desenvolvimento, devem seguir a Namespace Formula proposta pelo ERC-7201, atribuindo variáveis a 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, validar a compatibilidade de armazenamento antes da reatribuição, e chamar a interface da antiga delegaçã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 uma situação de generalização do recarregamento de contratos inteligentes.

A CEX deve verificar o estado de cada transação de depósito através do trace, a fim de prevenir riscos de depósitos falsos 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 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 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 podem ser contratos inteligentes.

) compatibilidade de contrato

Os tokens ERC-721 e ERC-777 existentes têm a funcionalidade Hook ao transferir para 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, a fim de garantir a compatibilidade com os tokens mais utilizados.

Verificação de Phishing

Após a implementação da delegação EIP-7702, os ativos na conta do usuário podem ser controlados por contratos inteligentes. Uma vez que o usuário delegue a conta a um contrato malicioso, os atacantes poderão roubar fundos com facilidade.

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, devem destacar o contrato alvo da delegação para 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, como inspeções de código aberto, verificações de permissões, etc., pode ajudar melhor os usuários a evitar esse tipo de risco.

Resumo

Este artigo discute a proposta EIP-7702 na próxima atualização Pectra do Ethereum. A EIP-7702, ao introduzir novos tipos de transação, confere aos EOA programabilidade e combinabilidade, borrando as linhas 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 carteira, desenvolvedores, CEX, etc., enfrentam muitos desafios e oportunidades na aplicação prática. O conteúdo das melhores práticas aqui apresentado não abrange todos os riscos potenciais, mas ainda é digno de consideração e aplicação por todas as partes envolvidas na operação prática.