Ethereum Pectra atualização e EIP-7702: um passo importante para borrar a linha entre EOA e contas de contrato

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 sendo introduzidas. Entre elas, a EIP-7702 fez uma transformação revolucionária na conta externa do Ethereum (EOA). Esta proposta obscureceu a linha entre EOA e contas 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.

Pectra já completou a implantação na rede de teste, e espera-se que seja lançada na mainnet em breve. Este artigo irá analisar em profundidade o mecanismo de implementação do EIP-7702, discutir as oportunidades e desafios que pode trazer, e fornecer orientações práticas para os diferentes participantes.

Análise de Protocolo

Resumo

A EIP-7702 introduz um novo tipo de transação, permitindo que EOA especifique um endereço de contrato inteligente para definir 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 combinabilidade ao EOA, permitindo que os usuários implementem recuperação social, controle de permissões, gestão multi-assinatura, verificação zk, pagamentos por subscrição, patrocínio de transações e processamento em lote de transações, entre outras funcionalidades. A EIP-7702 é perfeitamente compatível com a carteira de contrato inteligente implementada pela EIP-4337, e a integração sem costura entre ambas simplifica significativamente o processo de desenvolvimento e aplicação de novas funcionalidades.

O EIP-7702 introduziu o 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 pode conter várias entradas de autorização, cada uma contendo:

• chain_id: Esta autorização entra em vigor na cadeia
• endereço: endereço de destino delegado
• nonce: deve corresponder ao nonce da conta autorizada atual
• y_parity, r, s: autorizar a conta a assinar os dados da assinatura autorizada

O campo authorization_list em uma transação pode conter várias contas autorizadas diferentes, com entradas de autorização assinadas por (EOA). O iniciador da transação pode ser diferente do autorizador, permitindo que os custos de gas da operação de autorização sejam pagos por outra parte.

implementação

Ao assinar os dados de autorização, o autorizador deve primeiro codificar o chain_id, address e nonce em RLP. Em seguida, os dados codificados devem ser submetidos a uma operação de hash keccak256 juntamente 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 os dados y_parity, r e s. O MAGIC (0x05) é usado como delimitador de domínio, garantindo que os resultados de diferentes tipos de assinatura não entrem em conflito.

Quando o chain_id autorizado for 0, isso significa que o autorizador permite que a autorização ( seja reutilizada em todas as cadeias compatíveis com EVM que suportam EIP-7702, desde que o nonce também corresponda exatamente a ).

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 transmiti-los através do RPC. Antes de a transação ser incluída no bloco e executada, o Proposer fará uma pré-verificação da transação, realizando uma verificação obrigatória do endereço to 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.

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 autorizada 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), o valor nonce deve ser incrementado em 1 ao assinar a transação de autorização.

Ao aplicar um determinado item de autorização na aplicação do nó, se ocorrer algum erro, este 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 alvo da delegação. Devido às restrições do EIP-3541, os usuários não podem implantar código de contrato que comece com o byte 0xef de forma 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 da delegação 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. Aqui estão os aspectos que os participantes do ecossistema devem 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 não se 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 tem o maior controle sobre a conta, e possuir a chave privada permite dispor livremente dos ativos na conta. Mesmo que os usuários ou prestadores de serviços de carteira removam completamente a chave privada armazenada localmente após a conclusão da delegação para o EOA, não podem eliminar completamente o risco de vazamento da chave privada, especialmente em cenários onde há risco de ataque à cadeia de suprimentos.

Para os utilizadores, ao utilizar a conta após a delegação, deve-se sempre priorizar a proteção da chave privada, e estar sempre atento: Not your keys, not your coins.

replay de várias cadeias

Os utilizadores, ao assinarem a autorização de delegação, podem escolher a cadeia em que a delegação pode ser efetiva através do chainId, ou podem optar por usar o chainId 0 para a delegação, permitindo que a delegação seja reproduzida e efetiva em múltiplas cadeias, facilitando assim que os utilizadores possam delegar com uma única assinatura em várias cadeias. No entanto, é importante notar que, na mesma morada de contrato em múltiplas cadeias, pode haver diferentes códigos de implementação.

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

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

não foi possível inicializar

A maioria das carteiras inteligentes em uso atualmente adota um modelo de proxy. Quando a carteira proxy é implantada, ela chama a função de inicialização do contrato através do DELEGateCALL, realizando assim uma operação atômica de inicialização da carteira e implantação da carteira proxy, evitando o problema de ser inicializada 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 através da chamada ao endereço delegado. Isso faz com que o EIP-7702 não possa chamar a função de inicialização para a inicialização da carteira na transação de implantação do contrato, como acontece com o comum contrato proxy ERC-1967.

Para os desenvolvedores, ao combinar o EIP-7702 com a carteira existente EIP-4337, deve-se ter atenção a realizar verificações de permissão durante a operação de inicialização da carteira, como por exemplo, verificar a permissão através da recuperação de endereço de assinatura usando ecrecover, para evitar o risco de que a operação de inicialização da carteira seja ultrapassada.

( Gestão de Armazenamento

Os usuários, ao utilizarem 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 dos 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 da conta, perda de fundos e outras consequências indesejadas.

Para os usuários, deve-se ter cuidado ao lidar com situações 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 processo padrão de reatribuição especificamente para o EIP-7702: incluindo o uso do ERC-7201 para evitar 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 a delegação, o EOA também poderá ser utilizado como um contrato inteligente, portanto, a exchange )CEX### pode enfrentar uma situação de generalização da recarga de contratos inteligentes.

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

( conta conversão

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 uma chamada externa, seu msg.sender também será tx.origin, o que quebrará algumas suposições de segurança que restringem 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 que os futuros participantes poderão ser contratos inteligentes durante o processo de desenvolvimento.

) compatibilidade de contrato

Os tokens ERC-721 e ERC-777 existentes têm a funcionalidade Hook ao realizar transferências de contrato, 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 as funções de callback correspondentes, a fim de garantir a compatibilidade com os tokens principais.

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, e uma vez que o usuário delegue a conta a um contrato malicioso, os atacantes poderão roubar fundos com facilidade.

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 destacar o contrato-alvo da delegação para 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 conta delegada, como 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 próxima atualização Pectra do Ethereum. A EIP-7702 introduz um novo tipo de transação, permitindo que EOA tenha programabilidade e combinabilidade, 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 campo, diferentes participantes do ecossistema, como usuários, prestadores de serviços de carteira, desenvolvedores, CEX, etc., enfrentam muitos desafios e oportunidades na prática. O conteúdo das melhores práticas aqui exposto não pode cobrir todos os riscos potenciais, mas ainda assim vale a pena para todas as partes considerar e aplicar na prática.