Ethereum está prestes a receber a atualização Pectra, uma atualização significativa que introduzirá várias propostas de melhoria importantes. Dentre elas, a EIP-7702 realizou uma transformação revolucionária na conta externa do Ethereum (EOA). Esta proposta obscureceu a linha entre 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.
A Pectra já foi implantada na rede de testes e espera-se que seja lançada na mainnet em breve. Este artigo irá analisar detalhadamente o mecanismo de implementação do EIP-7702, explorando as oportunidades e desafios que pode trazer, e fornecerá guias práticos para diferentes participantes.
Análise de Protocolo
Resumo
EIP-7702 introduz um novo tipo de transação, permitindo que EOA especifique um endereço de contrato inteligente e defina um código para ele. Isso permite que EOA execute código como um contrato inteligente, mantendo a capacidade de iniciar transações. Essa característica confere programabilidade e combinabilidade 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 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 contrato inteligente implementadas pelo EIP-4337, e a integração perfeita entre ambos simplifica significativamente o desenvolvimento e a aplicação de novas funcionalidades.
EIP-7702 introduziu um tipo de transação como SET_CODE_TX_TYPE (0x04), cuja estrutura de dados é definida da seguinte forma:
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 entrada de autorização contém:
chain_id indica a cadeia na qual esta delegação de autorização é válida
endereço 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 da assinatura autorizada da conta autorizada
O campo authorization_list de uma transação pode conter várias entradas de autorização de diferentes contas autorizadas, onde ( EOA ) assina as entradas de autorização, ou seja, o iniciador da transação pode ser diferente do autorizador para realizar operações de autorização com pagamento de gás pelo autorizador.
implementação
O autorizador, ao assinar os dados de autorização, deve 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, 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 e s. O MAGIC (0x05) é utilizado como delimitador de domínio, com o objetivo de garantir que os resultados de diferentes tipos de assinaturas não entrem em conflito.
É importante notar que, quando o chain_id autorizado é 0, isso significa que o autoriza 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 corresponda exatamente a ).
Após o autorizar assinar os dados de autorização, o iniciador da transação irá agrupá-los no campo authorization_list para assinatura e transmiti-los via RPC. Antes que a transação seja executada e incluída em um bloco, o Proposer realizará uma pré-verificação da transação, onde o endereço to será verificado 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, esse 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, 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, 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.
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 autorizada, o campo code do endereço do autorizador será definido como 0xef0100 || address, onde 0xef0100 é uma identificação fixa e address é o endereço de destino delegado. Devido às limitações da 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 identificação só possa ser implantada através de 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 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 conta nativa ( 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 casos de uso também trarão novos riscos. A seguir, estão os aspectos que os participantes do ecossistema devem estar atentos durante o processo prático:
armazenamento da chave privada
Embora o EOA possa utilizar meios como a recuperação social integrada em contratos inteligentes para resolver problemas de perda de fundos devido à perda da chave privada após a delegação, ainda não é possível evitar o risco de vazamento da chave privada do EOA. É importante esclarecer que, após executar a delegação, a chave privada do EOA ainda possui o controle máximo sobre a conta, e quem detiver a chave privada pode 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 do EOA, não é possível eliminar totalmente o risco de vazamento da chave privada, especialmente em cenários onde existe o risco de ataque à cadeia de suprimentos.
Para os utilizadores, ao usar a conta após a delegação, os utilizadores ainda devem colocar a proteção da chave privada em primeiro lugar, devendo estar sempre atentos: Not your keys, not your coins.
Repetição de múltiplas cadeias
Os usuários, ao assinar a autorização de delegação, podem escolher a cadeia na qual a delegação pode ser efetiva através do chainId. Claro que os usuários também podem optar por usar chainId igual a 0 para a delegação, o que permite que a delegação seja reproduzida em múltiplas 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 por parte do usuário, deve-se verificar se a cadeia de ativação da delegação corresponde à rede atualmente conectada e alertar o usuário sobre os riscos que a assinatura de uma delegação com chainId igual a 0 pode trazer.
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 primeiro entender claramente o objetivo da delegação.
não é possível inicializar
Atualmente, a maioria das carteiras de contratos inteligentes populares utiliza um modelo de proxy. O proxy da carteira, ao ser implementado, chama a função de inicialização do contrato por meio do DELEGateCALL, alcançando assim uma operação atômica na inicialização da carteira e na implementação da carteira proxy, evitando o problema de ser inicializada antes. No entanto, quando os usuários utilizam o EIP-7702 para delegar, apenas o campo code do seu endereço será atualizado, não permitindo a inicialização chamando o endereço delegado. Isso faz com que o EIP-7702 não consiga, como os comuns contratos proxy ERC-1967, chamar a função de inicialização na transação de implementação do contrato para a inicialização da carteira.
Para os desenvolvedores, ao combinar o EIP-7702 com as carteiras existentes do EIP-4337, é importante prestar atenção à 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 de assinaturas com ecrecover (, a fim de evitar o risco de que a operação de inicialização da carteira seja corrida.
) Gestão de Armazenamento
Os usuários que utilizam a função de delegação EIP-7702 podem precisar redirecionar a delegação para diferentes endereços de contrato devido a mudanças nas necessidades da funcionalidade, atualizações de carteira, entre outros motivos. No entanto, a estrutura de armazenamento dos diferentes contratos pode apresentar variações, ### por exemplo, o slot0 de contratos diferentes pode representar tipos diferentes de dados, ( e, no caso de uma nova delegação, isso pode resultar na reutilização acidental dos dados do contrato antigo pelo novo contrato, levando a consequências negativas, como bloqueio de contas e perdas financeiras.
Os usuários devem 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( 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, assim como chamar a interface do antigo delegado para limpar os dados antigos do armazenamento.
) Recarga falsa
Após realizar a delegação, o EOA também poderá ser utilizado como um contrato inteligente, portanto, as exchanges poderão enfrentar a situação de generalização do depósito em contratos inteligentes.
As exchanges devem verificar o estado de cada transação de recarga por meio de trace, a fim de prevenir o risco de falsos depósitos 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 seja chamada. Isso significa que, quando a conta chama a si mesma e realiza 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.
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 presumir que os futuros participantes podem ser contratos inteligentes durante o processo de desenvolvimento.
compatibilidade de contratos
Os tokens ERC-721 e ERC-777 existentes têm a funcionalidade de Hook ao transferir para o 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, 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 podem ser controlados por contratos inteligentes. Assim que o usuário delegar a conta a um contrato malicioso, os atacantes poderão roubar fundos com facilidade.
Para os prestadores de serviços de carteira, é particularmente importante apoiar rapidamente transações do tipo EIP-7702, e ao realizar uma assinatura delegada, deve-se destacar o contrato de destino para o usuário, a fim de mitigar o risco de ataques de phishing que o usuário possa sofrer.
Além disso, uma análise automática mais aprofundada dos contratos-alvo da delegação de contas, 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 explora a proposta EIP-7702 na iminente atualização Pectra do Ethereum. A EIP-7702, ao introduzir novos tipos de transações, confere programabilidade e combinabilidade ao EOA, borrando as linhas entre EOA e contas de contrato. Como atualmente 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, provedores de carteira, desenvolvedores e exchanges, enfrentam numerosos desafios e oportunidades na prática. O conteúdo das melhores práticas apresentadas neste artigo não cobre todos os riscos potenciais, mas ainda assim é digno de consideração e aplicação por todas as partes na operação prática.
Esta página pode conter conteúdos de terceiros, que são fornecidos apenas para fins informativos (sem representações/garantias) e não devem ser considerados como uma aprovação dos seus pontos de vista pela Gate, nem como aconselhamento financeiro ou profissional. Consulte a Declaração de exoneração de responsabilidade para obter mais informações.
6 gostos
Recompensa
6
5
Partilhar
Comentar
0/400
PermabullPete
· 19h atrás
embarque já está a arrebentar, Carteira de encomendas também vai explodir
Ver originalResponder0
StablecoinEnjoyer
· 19h atrás
Está um pouco adiantado, parece que o Vitalik Buterin está a fazer grandes coisas novamente.
Ver originalResponder0
Token_Sherpa
· 20h atrás
meh... outra proposta que não vai resolver os verdadeiros problemas do eth, para ser honesto
EIP-7702 Profundidade análise: a atualização Pectra do Ethereum irá borrar os limites entre EOA e CA
Ethereum Pectra atualização: EIP-7702 Profundidade análise
Introdução
Ethereum está prestes a receber a atualização Pectra, uma atualização significativa que introduzirá várias propostas de melhoria importantes. Dentre elas, a EIP-7702 realizou uma transformação revolucionária na conta externa do Ethereum (EOA). Esta proposta obscureceu a linha entre 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.
A Pectra já foi implantada na rede de testes e espera-se que seja lançada na mainnet em breve. Este artigo irá analisar detalhadamente o mecanismo de implementação do EIP-7702, explorando as oportunidades e desafios que pode trazer, e fornecerá guias práticos para diferentes participantes.
Análise de Protocolo
Resumo
EIP-7702 introduz um novo tipo de transação, permitindo que EOA especifique um endereço de contrato inteligente e defina um código para ele. Isso permite que EOA execute código como um contrato inteligente, mantendo a capacidade de iniciar transações. Essa característica confere programabilidade e combinabilidade 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 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 contrato inteligente implementadas pelo EIP-4337, e a integração perfeita entre ambos simplifica significativamente o desenvolvimento e a aplicação de novas funcionalidades.
EIP-7702 introduziu um tipo de transação como 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 entrada de autorização contém:
O campo authorization_list de uma transação pode conter várias entradas de autorização de diferentes contas autorizadas, onde ( EOA ) assina as entradas de autorização, ou seja, o iniciador da transação pode ser diferente do autorizador para realizar operações de autorização com pagamento de gás pelo autorizador.
implementação
O autorizador, ao assinar os dados de autorização, deve 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, 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 e s. O MAGIC (0x05) é utilizado como delimitador de domínio, com o objetivo de garantir que os resultados de diferentes tipos de assinaturas não entrem em conflito.
É importante notar que, quando o chain_id autorizado é 0, isso significa que o autoriza 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 corresponda exatamente a ).
Após o autorizar assinar os dados de autorização, o iniciador da transação irá agrupá-los no campo authorization_list para assinatura e transmiti-los via RPC. Antes que a transação seja executada e incluída em um bloco, o Proposer realizará uma pré-verificação da transação, onde o endereço to será verificado 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, esse 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, 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, 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.
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 autorizada, o campo code do endereço do autorizador será definido como 0xef0100 || address, onde 0xef0100 é uma identificação fixa e address é o endereço de destino delegado. Devido às limitações da 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 identificação só possa ser implantada através de 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 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 conta nativa ( 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 casos de uso também trarão novos riscos. A seguir, estão os aspectos que os participantes do ecossistema devem estar atentos durante o processo prático:
armazenamento da chave privada
Embora o EOA possa utilizar meios como a recuperação social integrada em contratos inteligentes para resolver problemas de perda de fundos devido à perda da chave privada após a delegação, ainda não é possível evitar o risco de vazamento da chave privada do EOA. É importante esclarecer que, após executar a delegação, a chave privada do EOA ainda possui o controle máximo sobre a conta, e quem detiver a chave privada pode 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 do EOA, não é possível eliminar totalmente o risco de vazamento da chave privada, especialmente em cenários onde existe o risco de ataque à cadeia de suprimentos.
Para os utilizadores, ao usar a conta após a delegação, os utilizadores ainda devem colocar a proteção da chave privada em primeiro lugar, devendo estar sempre atentos: Not your keys, not your coins.
Repetição de múltiplas cadeias
Os usuários, ao assinar a autorização de delegação, podem escolher a cadeia na qual a delegação pode ser efetiva através do chainId. Claro que os usuários também podem optar por usar chainId igual a 0 para a delegação, o que permite que a delegação seja reproduzida em múltiplas 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 por parte do usuário, deve-se verificar se a cadeia de ativação da delegação corresponde à rede atualmente conectada e alertar o usuário sobre os riscos que a assinatura de uma delegação com chainId igual a 0 pode trazer.
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 primeiro entender claramente o objetivo da delegação.
não é possível inicializar
Atualmente, a maioria das carteiras de contratos inteligentes populares utiliza um modelo de proxy. O proxy da carteira, ao ser implementado, chama a função de inicialização do contrato por meio do DELEGateCALL, alcançando assim uma operação atômica na inicialização da carteira e na implementação da carteira proxy, evitando o problema de ser inicializada antes. No entanto, quando os usuários utilizam o EIP-7702 para delegar, apenas o campo code do seu endereço será atualizado, não permitindo a inicialização chamando o endereço delegado. Isso faz com que o EIP-7702 não consiga, como os comuns contratos proxy ERC-1967, chamar a função de inicialização na transação de implementação do contrato para a inicialização da carteira.
Para os desenvolvedores, ao combinar o EIP-7702 com as carteiras existentes do EIP-4337, é importante prestar atenção à 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 de assinaturas com ecrecover (, a fim de evitar o risco de que a operação de inicialização da carteira seja corrida.
) Gestão de Armazenamento
Os usuários que utilizam a função de delegação EIP-7702 podem precisar redirecionar a delegação para diferentes endereços de contrato devido a mudanças nas necessidades da funcionalidade, atualizações de carteira, entre outros motivos. No entanto, a estrutura de armazenamento dos diferentes contratos pode apresentar variações, ### por exemplo, o slot0 de contratos diferentes pode representar tipos diferentes de dados, ( e, no caso de uma nova delegação, isso pode resultar na reutilização acidental dos dados do contrato antigo pelo novo contrato, levando a consequências negativas, como bloqueio de contas e perdas financeiras.
Os usuários devem 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( 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, assim como chamar a interface do antigo delegado para limpar os dados antigos do armazenamento.
) Recarga falsa
Após realizar a delegação, o EOA também poderá ser utilizado como um contrato inteligente, portanto, as exchanges poderão enfrentar a situação de generalização do depósito em contratos inteligentes.
As exchanges devem verificar o estado de cada transação de recarga por meio de trace, a fim de prevenir o risco de falsos depósitos 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 seja chamada. Isso significa que, quando a conta chama a si mesma e realiza 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.
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 presumir que os futuros participantes podem ser contratos inteligentes durante o processo de desenvolvimento.
compatibilidade de contratos
Os tokens ERC-721 e ERC-777 existentes têm a funcionalidade de Hook ao transferir para o 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, 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 podem ser controlados por contratos inteligentes. Assim que o usuário delegar a conta a um contrato malicioso, os atacantes poderão roubar fundos com facilidade.
Para os prestadores de serviços de carteira, é particularmente importante apoiar rapidamente transações do tipo EIP-7702, e ao realizar uma assinatura delegada, deve-se destacar o contrato de destino para o usuário, a fim de mitigar o risco de ataques de phishing que o usuário possa sofrer.
Além disso, uma análise automática mais aprofundada dos contratos-alvo da delegação de contas, 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 explora a proposta EIP-7702 na iminente atualização Pectra do Ethereum. A EIP-7702, ao introduzir novos tipos de transações, confere programabilidade e combinabilidade ao EOA, borrando as linhas entre EOA e contas de contrato. Como atualmente 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, provedores de carteira, desenvolvedores e exchanges, enfrentam numerosos desafios e oportunidades na prática. O conteúdo das melhores práticas apresentadas neste artigo não cobre todos os riscos potenciais, mas ainda assim é digno de consideração e aplicação por todas as partes na operação prática.