Atualização Pectra do Ethereum: EIP-7702 traz uma transformação revolucionária para EOA
Introdução
Ethereum está prestes a receber a atualização Pectra, que é uma atualização de grande importância, com várias propostas de melhoria significativas a serem introduzidas. Entre elas, a EIP-7702 realizou uma transformação revolucionária na conta externa do Ethereum (EOA). Esta proposta nebuliza a linha entre EOA e a 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 testes e espera-se que seja lançada na rede principal em breve. Este artigo irá analisar detalhadamente o mecanismo de implementação do EIP-7702, explorar as oportunidades e desafios que pode trazer e fornecer guias práticos para diferentes participantes.
Análise de Protocolo
Resumo
O EIP-7702 introduz um novo tipo de transação que permite que uma EOA especifique um endereço de contrato inteligente para definir seu código. Isso permite que a EOA execute código como um contrato inteligente, mantendo a capacidade de iniciar transações. Esta característica confere à EOA programabilidade e combinabilidade, 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 a pena notar que o EIP-7702 é perfeitamente compatível com a carteira de contrato inteligente implementada pelo EIP-4337, e a integração sem costura entre os dois simplifica significativamente o desenvolvimento e a aplicação de novas funcionalidades.
O EIP-7702 introduziu um tipo de transação SET_CODE_TX_TYPE (0x04), cuja estrutura de dados é definida da seguinte forma:
Na nova estrutura de transações, exceto pelo campo authorization_list, os demais seguem a mesma semântica do EIP-4844. Este campo é do tipo lista e pode conter várias entradas de autorização, onde cada entrada de autorização contém:
chain_id representa a cadeia na qual esta autorização de delegação é válida.
address representa o endereço de destino 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 autorizadora
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 a operação de autorização com pagamento de gas por parte do autorizador.
implementação
Quando o autorizador assina os dados de autorização, deve primeiro codificar chain_id, address e nonce em RLP. Em seguida, os dados codificados são combinados com o número MAGIC e submetidos a uma operação de hash keccak256 para obter 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, com o objetivo de garantir que os resultados de diferentes tipos de assinatura não entrem em conflito.
Deve-se notar que, quando o chain_id autorizado pelo autorizador é 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 corresponda a ).
Após o autorizar assinar os dados de autorização, o iniciador da transação irá reunir esses dados no campo authorization_list para assinar e transmitir a transação através do RPC. Antes que a transação seja executada e incluída no bloco, o Proposer 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 é 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 um item de autorização; se houver vários itens de autorização assinados pelo mesmo autorizador, apenas o último item de autorização será efetivo.
Durante a execução da transação, o nó irá primeiro aumentar o valor de 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ó irá primeiro verificar 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 do nonce deve ser aumentado em 1 ao assinar a transação de autorização.
Quando um nó aplica uma determinada entrada de autorização e encontra qualquer erro, essa entrada de autorização será ignorada, a transação não falhará e outras entradas de autorização continuarão a ser aplicadas, para garantir 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 limitações do EIP-3541, os usuários não podem implantar código de contrato que começa com bytes 0xef de forma 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 desejar remover a autorização, basta definir o endereço alvo da delegação como o endereço 0.
O novo tipo de transação introduzido pelo EIP-7702 permite que o autorizado ( EOA ) execute código como um contrato inteligente, mantendo 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. Abaixo estão os aspectos que os participantes do ecossistema precisam estar atentos durante o processo prático:
armazenamento da chave privada
Mesmo que a EOA possa usar métodos como a recuperação social embutida em contratos inteligentes para resolver problemas de perda de fundos devido ao roubo de chaves privadas após a delegação, ainda não se pode evitar o risco de vazamento da chave privada da EOA. É importante esclarecer que, após a execução da delegação, a chave privada da EOA ainda possui o controle máximo sobre a conta; quem possui a chave privada pode dispor dos ativos na conta à vontade. Após a conclusão da delegação pela EOA, mesmo que o usuário ou o provedor de serviços de carteira exclua completamente a chave privada armazenada localmente, não se pode 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 a conta após a delegação, a proteção da chave privada ainda deve ser a prioridade, e é importante lembrar: Not your keys, not your coins.
Repetição de Multi-Chain
Os usuários podem escolher a cadeia em que a autorização de delegação é válida através do chainId ao assinar a autorização de delegação, e também podem optar por usar o chainId igual a 0 para a delegação, permitindo que a delegação seja 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, podem existir códigos de implementação diferentes.
Para os prestadores de serviços de carteira, ao delegar por parte do utilizador, deve-se verificar se a cadeia de efetivação da delegação corresponde à rede atualmente conectada e alertar o utilizador sobre os riscos associados à assinatura de delegações com chainId igual a 0.
Os usuários também devem estar cientes de que o mesmo endereço de contrato em diferentes cadeias nem sempre possui o mesmo código de contrato, e devem primeiro entender claramente o objetivo da delegação.
não foi possível inicializar
A maioria das carteiras de contratos inteligentes populares 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 para realizar a operação atômica de inicialização da carteira e implantação da carteira proxy, evitando o problema de ser inicializada antes. No entanto, ao usar o EIP-7702 para delegação, apenas o campo code do endereço é atualizado, não sendo possível inicializar através da chamada ao endereço delegado. Isso impede que o EIP-7702 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 EIP-4337 existente, deve-se ter atenção à verificação de permissões durante a operação de inicialização da carteira, por exemplo, verificando as permissões através da recuperação de endereço de assinatura usando ecrecover, para evitar o risco de a operação de inicialização da carteira ser ultrapassada.
( Gestão de Armazenamento
Ao usar a função de delegação EIP-7702, os usuários podem precisar delegar novamente para um endereço de contrato diferente devido a alterações nos requisitos de função, atualizações de carteira, etc. No entanto, podem existir diferenças na estrutura de armazenamento de diferentes contratos ), por exemplo, faixas horárias0 de contratos diferentes podem representar diferentes tipos de ### de dados, o que pode levar a que o novo contrato reutilize acidentalmente os dados do contrato antigo em caso de redelegação, o que pode levar a consequências indesejáveis, como o bloqueio de contas e perdas de capital.
Os usuários devem lidar com a situação de reatribuição com cautela.
Para os desenvolvedores, durante o processo de desenvolvimento, deve-se seguir a Namespace Formula proposta pelo ERC-7201, alocando 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 o uso do ERC-7201 para evitar conflitos de armazenamento, e verificar a compatibilidade de armazenamento antes da reatribuição, bem como chamar a interface da antiga delegação para limpar os dados antigos do armazenamento.
( recarga falsa
Após o usuário fazer a delegação, o EOA também poderá ser utilizado como um contrato inteligente, portanto, a exchange centralizada )CEX### pode enfrentar a situação de generalização dos depósitos em contratos inteligentes.
A CEX deve verificar o estado de cada transação de recarga através do trace, a fim de prevenir o risco de falsas recargas em contratos inteligentes.
( Conversão de conta
Após a implementação da delegação EIP-7702, o tipo de conta dos usuários pode ser convertido livremente entre EOA e SC, permitindo que a conta inicie transações e 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 apenas a 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 de msg.sender == tx.origin para se defender contra ataques de reentrada também falhará.
Os desenvolvedores devem assumir que os futuros participantes podem ser contratos inteligentes durante o processo de desenvolvimento.
) compatibilidade de contrato
Os tokens ERC-721 e ERC-777 existentes têm a funcionalidade de Hook ao transferir para contratos, o que significa que o receptor 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 poderão ser controlados por contratos inteligentes. Assim que o usuário delegar a conta para um contrato malicioso, será muito fácil para os atacantes roubar os fundos.
Para os provedores 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 os usuários serem vítimas de ataques de phishing.
Além disso, a análise automática mais profunda dos contratos alvo da delegação de contas, como a verificação de código aberto, verificação de permissões, etc., ### pode ajudar melhor os usuários a evitar esses tipos de 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 às 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, prestadores de serviços de carteira, desenvolvedores, CEX, entre outros, enfrentam vários desafios e oportunidades na aplicação prática. O conteúdo das melhores práticas aqui exposto não consegue abranger todos os riscos potenciais, mas ainda assim merece ser considerado e aplicado por todos os envolvidos na operação prática.
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
17 Curtidas
Recompensa
17
9
Repostar
Compartilhar
Comentário
0/400
notSatoshi1971
· 07-26 08:08
Antes de começar a negociar o mercado, é melhor estar deitado numa emboscada. 7702必起飞
Ver originalResponder0
0xSunnyDay
· 07-24 10:37
Esta atualização é mesmo brutal 8 Foi para cima
Ver originalResponder0
BasementAlchemist
· 07-23 13:37
Mais uma onda de inovação nas contas de contratos? É muito absurdo.
Ver originalResponder0
MEVHunterX
· 07-23 13:21
É a próxima história do 4337 ~ Cheira bem, vamos em frente!
Ver originalResponder0
PanicSeller69
· 07-23 13:20
Uma olhada e já vamos bombear. Quando vamos começar a comprar na baixa o V神?
Ver originalResponder0
FastLeaver
· 07-23 13:14
Outra atualização?? Puxar o tapete alerta
Ver originalResponder0
PerennialLeek
· 07-23 13:12
Subiu várias vezes, quem entende, entende.
Ver originalResponder0
WinterWarmthCat
· 07-23 13:12
O caixa eletrónico fala! Nova atualização? Vamos falar sobre a retirada.
Ver originalResponder0
Web3ExplorerLin
· 07-23 13:07
fascinante... eip-7702 pode ser o salto quântico que o eth precisa agora
Atualização Pectra do Ethereum: EIP-7702 desfoca os limites entre EOA e CA, iniciando uma nova era de abstração de contas nativa
Atualização Pectra do Ethereum: EIP-7702 traz uma transformação revolucionária para EOA
Introdução
Ethereum está prestes a receber a atualização Pectra, que é uma atualização de grande importância, com várias propostas de melhoria significativas a serem introduzidas. Entre elas, a EIP-7702 realizou uma transformação revolucionária na conta externa do Ethereum (EOA). Esta proposta nebuliza a linha entre EOA e a 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 testes e espera-se que seja lançada na rede principal em breve. Este artigo irá analisar detalhadamente o mecanismo de implementação do EIP-7702, explorar as oportunidades e desafios que pode trazer e fornecer guias práticos para diferentes participantes.
Análise de Protocolo
Resumo
O EIP-7702 introduz um novo tipo de transação que permite que uma EOA especifique um endereço de contrato inteligente para definir seu código. Isso permite que a EOA execute código como um contrato inteligente, mantendo a capacidade de iniciar transações. Esta característica confere à EOA programabilidade e combinabilidade, 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 a pena notar que o EIP-7702 é perfeitamente compatível com a carteira de contrato inteligente implementada pelo EIP-4337, e a integração sem costura entre os dois simplifica significativamente o desenvolvimento e a aplicação de novas funcionalidades.
O 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ções, exceto pelo campo authorization_list, os demais seguem a mesma semântica do EIP-4844. Este campo é do tipo lista e pode conter várias entradas de autorização, onde cada entrada de autorização contém:
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 a operação de autorização com pagamento de gas por parte do autorizador.
implementação
Quando o autorizador assina os dados de autorização, deve primeiro codificar chain_id, address e nonce em RLP. Em seguida, os dados codificados são combinados com o número MAGIC e submetidos a uma operação de hash keccak256 para obter 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, com o objetivo de garantir que os resultados de diferentes tipos de assinatura não entrem em conflito.
Deve-se notar que, quando o chain_id autorizado pelo autorizador é 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 corresponda a ).
Após o autorizar assinar os dados de autorização, o iniciador da transação irá reunir esses dados no campo authorization_list para assinar e transmitir a transação através do RPC. Antes que a transação seja executada e incluída no bloco, o Proposer 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 é 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 um item de autorização; se houver vários itens de autorização assinados pelo mesmo autorizador, apenas o último item de autorização será efetivo.
Durante a execução da transação, o nó irá primeiro aumentar o valor de 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ó irá primeiro verificar 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 do nonce deve ser aumentado em 1 ao assinar a transação de autorização.
Quando um nó aplica uma determinada entrada de autorização e encontra qualquer erro, essa entrada de autorização será ignorada, a transação não falhará e outras entradas de autorização continuarão a ser aplicadas, para garantir 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 limitações do EIP-3541, os usuários não podem implantar código de contrato que começa com bytes 0xef de forma 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 desejar remover a autorização, basta definir o endereço alvo da delegação como o endereço 0.
O novo tipo de transação introduzido pelo EIP-7702 permite que o autorizado ( EOA ) execute código como um contrato inteligente, mantendo 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. Abaixo estão os aspectos que os participantes do ecossistema precisam estar atentos durante o processo prático:
armazenamento da chave privada
Mesmo que a EOA possa usar métodos como a recuperação social embutida em contratos inteligentes para resolver problemas de perda de fundos devido ao roubo de chaves privadas após a delegação, ainda não se pode evitar o risco de vazamento da chave privada da EOA. É importante esclarecer que, após a execução da delegação, a chave privada da EOA ainda possui o controle máximo sobre a conta; quem possui a chave privada pode dispor dos ativos na conta à vontade. Após a conclusão da delegação pela EOA, mesmo que o usuário ou o provedor de serviços de carteira exclua completamente a chave privada armazenada localmente, não se pode 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 a conta após a delegação, a proteção da chave privada ainda deve ser a prioridade, e é importante lembrar: Not your keys, not your coins.
Repetição de Multi-Chain
Os usuários podem escolher a cadeia em que a autorização de delegação é válida através do chainId ao assinar a autorização de delegação, e também podem optar por usar o chainId igual a 0 para a delegação, permitindo que a delegação seja 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, podem existir códigos de implementação diferentes.
Para os prestadores de serviços de carteira, ao delegar por parte do utilizador, deve-se verificar se a cadeia de efetivação da delegação corresponde à rede atualmente conectada e alertar o utilizador sobre os riscos associados à assinatura de delegações com chainId igual a 0.
Os usuários também devem estar cientes de que o mesmo endereço de contrato em diferentes cadeias nem sempre possui o mesmo código de contrato, e devem primeiro entender claramente o objetivo da delegação.
não foi possível inicializar
A maioria das carteiras de contratos inteligentes populares 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 para realizar a operação atômica de inicialização da carteira e implantação da carteira proxy, evitando o problema de ser inicializada antes. No entanto, ao usar o EIP-7702 para delegação, apenas o campo code do endereço é atualizado, não sendo possível inicializar através da chamada ao endereço delegado. Isso impede que o EIP-7702 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 EIP-4337 existente, deve-se ter atenção à verificação de permissões durante a operação de inicialização da carteira, por exemplo, verificando as permissões através da recuperação de endereço de assinatura usando ecrecover, para evitar o risco de a operação de inicialização da carteira ser ultrapassada.
( Gestão de Armazenamento
Ao usar a função de delegação EIP-7702, os usuários podem precisar delegar novamente para um endereço de contrato diferente devido a alterações nos requisitos de função, atualizações de carteira, etc. No entanto, podem existir diferenças na estrutura de armazenamento de diferentes contratos ), por exemplo, faixas horárias0 de contratos diferentes podem representar diferentes tipos de ### de dados, o que pode levar a que o novo contrato reutilize acidentalmente os dados do contrato antigo em caso de redelegação, o que pode levar a consequências indesejáveis, como o bloqueio de contas e perdas de capital.
Os usuários devem lidar com a situação de reatribuição com cautela.
Para os desenvolvedores, durante o processo de desenvolvimento, deve-se seguir a Namespace Formula proposta pelo ERC-7201, alocando 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 o uso do ERC-7201 para evitar conflitos de armazenamento, e verificar a compatibilidade de armazenamento antes da reatribuição, bem como chamar a interface da antiga delegação para limpar os dados antigos do armazenamento.
( recarga falsa
Após o usuário fazer a delegação, o EOA também poderá ser utilizado como um contrato inteligente, portanto, a exchange centralizada )CEX### pode enfrentar a situação de generalização dos depósitos em contratos inteligentes.
A CEX deve verificar o estado de cada transação de recarga através do trace, a fim de prevenir o risco de falsas recargas em contratos inteligentes.
( Conversão de conta
Após a implementação da delegação EIP-7702, o tipo de conta dos usuários pode ser convertido livremente entre EOA e SC, permitindo que a conta inicie transações e 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 apenas a 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 de msg.sender == tx.origin para se defender contra ataques de reentrada também falhará.
Os desenvolvedores devem assumir que os futuros participantes podem ser contratos inteligentes durante o processo de desenvolvimento.
) compatibilidade de contrato
Os tokens ERC-721 e ERC-777 existentes têm a funcionalidade de Hook ao transferir para contratos, o que significa que o receptor 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 poderão ser controlados por contratos inteligentes. Assim que o usuário delegar a conta para um contrato malicioso, será muito fácil para os atacantes roubar os fundos.
Para os provedores 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 os usuários serem vítimas de ataques de phishing.
Além disso, a análise automática mais profunda dos contratos alvo da delegação de contas, como a verificação de código aberto, verificação de permissões, etc., ### pode ajudar melhor os usuários a evitar esses tipos de 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 às 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, prestadores de serviços de carteira, desenvolvedores, CEX, entre outros, enfrentam vários desafios e oportunidades na aplicação prática. O conteúdo das melhores práticas aqui exposto não consegue abranger todos os riscos potenciais, mas ainda assim merece ser considerado e aplicado por todos os envolvidos na operação prática.