Atualização Pectra do Ethereum: Análise Profunda do EIP-7702 e Melhores Práticas
Introdução
Ethereum está prestes a receber a atualização Pectra, que é uma atualização significativa, com várias propostas de melhoria importantes do Ethereum sendo 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, representando 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á concluiu a implementação na rede de testes e deverá ser lançada na mainnet em breve. Este artigo irá analisar em profundidade o mecanismo de implementação do EIP-7702, explorar as oportunidades e desafios que pode trazer, e fornecer um guia prático para diferentes participantes.
Análise do Protocolo
Resumo
O 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, enquanto mantém 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 ambos simplifica significativamente o desenvolvimento e a aplicação de novas funcionalidades.
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ção, exceto o 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, cada entrada de autorização contém:
chain_id indica a cadeia em que esta autorização de delegaçã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 de assinatura autorizados pela conta autorizada.
O campo authorization_list dentro 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 que a operação de autorização do autorizador seja paga em gas.
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 submetidos a um cálculo 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 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 assinatura não entrem em conflito.
Quando o chain_id autorizado pelo autor é 0, isso significa que o autor permite a repetição da autorização ( em todas as cadeias compatíveis com EVM que suportam EIP-7702, desde que o nonce corresponda exatamente a ).
Após o autorizar assinando os dados de autorização, o iniciador da transação irá agregá-los no campo authorization_list para assinar e transmitir a transação via RPC. Antes que a transação seja incluída e executada no bloco, o Proposer fará uma pré-verificação da transação, na qual o endereço to será verificado rigorosamente 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 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 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.
Quando um nó aplica um determinado item de autorização, se encontrar 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 da delegação. Devido às restriçõ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 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 em 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 contas 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 devem ter em mente 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 meios como a recuperação social embutida em contratos inteligentes após a delegação, 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; possuir a chave privada permite dispor livremente dos ativos na conta. Mesmo que os 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 é possível 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 usar a conta após a delegação, deve-se sempre priorizar a proteção das chaves privadas e estar atento: Not your keys, not your coins.
Repetição de múltiplas cadeias
Os usuários, ao assinarem uma autorização de delegação, podem selecionar a cadeia em que a delegação pode ser efetiva através do chainId. Claro que os usuários também podem optar por usar o chainId igual a 0 para a delegação, o que permite que a delegação seja reproduzida e efetiva em várias cadeias, facilitando assim que o usuário faça a delegação com uma única assinatura em várias cadeias. No entanto, é importante notar que, na mesma morada 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 pelo usuário, deve-se verificar se a cadeia de delegação em vigor corresponde à rede atualmente conectada e alertar o usuário sobre os riscos que podem surgir ao assinar uma delegação com chainId igual a 0.
Os usuários também devem estar cientes de que o mesmo endereço de contrato em diferentes cadeias pode não ter o mesmo código de contrato, devendo primeiro entender claramente o objetivo da delegação.
não foi possível inicializar
Atualmente, a maioria das carteiras de contratos inteligentes populares adota um modelo de proxy. O proxy da carteira, ao ser implantado, chamará a função de inicialização do contrato através de DELEGateCALL, alcançando assim uma operação atomizada de inicialização da carteira e implantação da carteira proxy, evitando o problema de ser inicializado antecipadamente. No entanto, quando os usuários utilizam o EIP-7702 para delegar, apenas o campo code do endereço é atualizado, não sendo possível inicializar chamando o endereço delegado. Isso faz com que o EIP-7702 não consiga chamar a função de inicialização para a inicialização da carteira na transação de implantação do contrato, como acontece com os contratos proxy ERC-1967 comuns.
Para os desenvolvedores, ao combinar o EIP-7702 com as carteiras existentes do EIP-4337, deve-se prestar atenção à verificação de permissões durante a operação de inicialização da carteira (, por exemplo, verificando o endereço da assinatura usando o ecrecover ), para evitar o risco de a operação de inicialização da carteira ser antecipada.
Gestão de Armazenamento
Os usuários que utilizam a funcionalidade de delegação EIP-7702 podem, devido a alterações nas necessidades funcionais, atualizações de carteira, entre outros motivos, precisar delegar novamente para um endereço de contrato diferente. 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 ). No caso de uma nova delegação, isso pode resultar na reutilização acidental dos dados do contrato antigo pelo novo contrato, o que pode levar a bloqueio de contas, perda de fundos e outras consequências negativas.
Para os usuários, deve-se ter cuidado ao lidar com situações de reatribuição.
Para os desenvolvedores, durante o processo de desenvolvimento, devem seguir a Namespace Formula proposta pelo ERC-7201, alocando variáveis em locais de armazenamento independentes designados para mitigar o risco de conflitos de armazenamento. Além disso, o ERC-7779 (draft) fornece um processo padrão de reencaminhamento especificamente para o EIP-7702: inclui o uso do ERC-7201 para evitar conflitos de armazenamento, e a verificação da compatibilidade de armazenamento antes do reencaminhamento, bem como a chamada da interface da antiga delegação para limpar os dados antigos do armazenamento.
recarga falsa
Após o usuário fazer uma delegação, o EOA também poderá ser usado como um contrato inteligente, portanto, as exchanges centralizadas (CEX) podem enfrentar a situação de generalização do depósito em contratos inteligentes.
As CEX deve verificar o estado de cada transação de depósito através do trace, prevenindo o risco 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 dos usuários 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 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 apenas a projetos EOA.
Para os desenvolvedores de contratos, supor 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 contrato
Os tokens ERC-721 e ERC-777 existentes possuem a funcionalidade Hook ao realizar transferências de contrato, 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 mais populares.
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 a um contrato malicioso, será fácil para o atacante roubar os fundos.
Para os provedores de serviços de carteira, é especialmente importante apoiar rapidamente transações do tipo EIP-7702 e, quando os usuários realizarem assinaturas delegadas, deve-se destacar o contrato alvo da delegação aos usuários para mitigar o risco de ataques de phishing que eles possam sofrer.
Além disso, realizar uma análise automática mais aprofundada dos contratos alvo da delegação da conta, 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, ao introduzir um novo tipo de transação, confere aos EOA programabilidade e combinabilidade, borrando a linha entre EOA e contas de contrato. Como atualmente não existe um padrão de contrato inteligente compatível com o EIP-7702 que tenha sido testado em campo, diferentes participantes do ecossistema, como usuários, provedores de carteira, desenvolvedores, CEX, entre outros, enfrentam muitos desafios e oportunidades na aplicação prática. O conteúdo das melhores práticas discutido neste artigo não pode abranger todos os riscos potenciais, mas ainda assim vale a pena que todas as partes considerem e apliquem 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.
14 gostos
Recompensa
14
5
Partilhar
Comentar
0/400
ser_ngmi
· 07-21 20:33
Copiar o trabalho de casa está a tornar-se uma rotina, não é só para obter um eoa e um ca.
Ver originalResponder0
ParanoiaKing
· 07-20 23:50
Mais uma pilha de atualizações difíceis de entender, sem palavras.
Ver originalResponder0
YieldHunter
· 07-20 23:49
tecnicamente falando, este eip parece meio suspeito... há dados sobre os custos de tx no testnet?
Ver originalResponder0
EyeOfTheTokenStorm
· 07-20 23:26
É mais uma oportunidade de se preparar antecipadamente? Com base nos dados históricos, após atualizações semelhantes, o ETH costuma ter uma grande subida. No entanto, o mercado está um pouco inflacionado.
Ver originalResponder0
SchrodingerPrivateKey
· 07-20 23:23
Há um novo EIP, a conta de contrato de versão limitada chegou.
Análise do EIP-7702: como a atualização Pectra do Ethereum confere Programabilidade a EOA
Atualização Pectra do Ethereum: Análise Profunda do EIP-7702 e Melhores Práticas
Introdução
Ethereum está prestes a receber a atualização Pectra, que é uma atualização significativa, com várias propostas de melhoria importantes do Ethereum sendo 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, representando 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á concluiu a implementação na rede de testes e deverá ser lançada na mainnet em breve. Este artigo irá analisar em profundidade o mecanismo de implementação do EIP-7702, explorar as oportunidades e desafios que pode trazer, e fornecer um guia prático para diferentes participantes.
Análise do Protocolo
Resumo
O 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, enquanto mantém 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 ambos simplifica significativamente o desenvolvimento e a aplicação de novas funcionalidades.
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, exceto o 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, cada entrada de autorização contém:
O campo authorization_list dentro 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 que a operação de autorização do autorizador seja paga em gas.
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 submetidos a um cálculo 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 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 assinatura não entrem em conflito.
Quando o chain_id autorizado pelo autor é 0, isso significa que o autor permite a repetição da autorização ( em todas as cadeias compatíveis com EVM que suportam EIP-7702, desde que o nonce corresponda exatamente a ).
Após o autorizar assinando os dados de autorização, o iniciador da transação irá agregá-los no campo authorization_list para assinar e transmitir a transação via RPC. Antes que a transação seja incluída e executada no bloco, o Proposer fará uma pré-verificação da transação, na qual o endereço to será verificado rigorosamente 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 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 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.
Quando um nó aplica um determinado item de autorização, se encontrar 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 da delegação. Devido às restriçõ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 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 em 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 contas 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 devem ter em mente 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 meios como a recuperação social embutida em contratos inteligentes após a delegação, 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; possuir a chave privada permite dispor livremente dos ativos na conta. Mesmo que os 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 é possível 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 usar a conta após a delegação, deve-se sempre priorizar a proteção das chaves privadas e estar atento: Not your keys, not your coins.
Repetição de múltiplas cadeias
Os usuários, ao assinarem uma autorização de delegação, podem selecionar a cadeia em que a delegação pode ser efetiva através do chainId. Claro que os usuários também podem optar por usar o chainId igual a 0 para a delegação, o que permite que a delegação seja reproduzida e efetiva em várias cadeias, facilitando assim que o usuário faça a delegação com uma única assinatura em várias cadeias. No entanto, é importante notar que, na mesma morada 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 pelo usuário, deve-se verificar se a cadeia de delegação em vigor corresponde à rede atualmente conectada e alertar o usuário sobre os riscos que podem surgir ao assinar uma delegação com chainId igual a 0.
Os usuários também devem estar cientes de que o mesmo endereço de contrato em diferentes cadeias pode não ter o mesmo código de contrato, devendo primeiro entender claramente o objetivo da delegação.
não foi possível inicializar
Atualmente, a maioria das carteiras de contratos inteligentes populares adota um modelo de proxy. O proxy da carteira, ao ser implantado, chamará a função de inicialização do contrato através de DELEGateCALL, alcançando assim uma operação atomizada de inicialização da carteira e implantação da carteira proxy, evitando o problema de ser inicializado antecipadamente. No entanto, quando os usuários utilizam o EIP-7702 para delegar, apenas o campo code do endereço é atualizado, não sendo possível inicializar chamando o endereço delegado. Isso faz com que o EIP-7702 não consiga chamar a função de inicialização para a inicialização da carteira na transação de implantação do contrato, como acontece com os contratos proxy ERC-1967 comuns.
Para os desenvolvedores, ao combinar o EIP-7702 com as carteiras existentes do EIP-4337, deve-se prestar atenção à verificação de permissões durante a operação de inicialização da carteira (, por exemplo, verificando o endereço da assinatura usando o ecrecover ), para evitar o risco de a operação de inicialização da carteira ser antecipada.
Gestão de Armazenamento
Os usuários que utilizam a funcionalidade de delegação EIP-7702 podem, devido a alterações nas necessidades funcionais, atualizações de carteira, entre outros motivos, precisar delegar novamente para um endereço de contrato diferente. 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 ). No caso de uma nova delegação, isso pode resultar na reutilização acidental dos dados do contrato antigo pelo novo contrato, o que pode levar a bloqueio de contas, perda de fundos e outras consequências negativas.
Para os usuários, deve-se ter cuidado ao lidar com situações de reatribuição.
Para os desenvolvedores, durante o processo de desenvolvimento, devem seguir a Namespace Formula proposta pelo ERC-7201, alocando variáveis em locais de armazenamento independentes designados para mitigar o risco de conflitos de armazenamento. Além disso, o ERC-7779 (draft) fornece um processo padrão de reencaminhamento especificamente para o EIP-7702: inclui o uso do ERC-7201 para evitar conflitos de armazenamento, e a verificação da compatibilidade de armazenamento antes do reencaminhamento, bem como a chamada da interface da antiga delegação para limpar os dados antigos do armazenamento.
recarga falsa
Após o usuário fazer uma delegação, o EOA também poderá ser usado como um contrato inteligente, portanto, as exchanges centralizadas (CEX) podem enfrentar a situação de generalização do depósito em contratos inteligentes.
As CEX deve verificar o estado de cada transação de depósito através do trace, prevenindo o risco 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 dos usuários 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 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 apenas a projetos EOA.
Para os desenvolvedores de contratos, supor 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 contrato
Os tokens ERC-721 e ERC-777 existentes possuem a funcionalidade Hook ao realizar transferências de contrato, 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 mais populares.
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 a um contrato malicioso, será fácil para o atacante roubar os fundos.
Para os provedores de serviços de carteira, é especialmente importante apoiar rapidamente transações do tipo EIP-7702 e, quando os usuários realizarem assinaturas delegadas, deve-se destacar o contrato alvo da delegação aos usuários para mitigar o risco de ataques de phishing que eles possam sofrer.
Além disso, realizar uma análise automática mais aprofundada dos contratos alvo da delegação da conta, 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, ao introduzir um novo tipo de transação, confere aos EOA programabilidade e combinabilidade, borrando a linha entre EOA e contas de contrato. Como atualmente não existe um padrão de contrato inteligente compatível com o EIP-7702 que tenha sido testado em campo, diferentes participantes do ecossistema, como usuários, provedores de carteira, desenvolvedores, CEX, entre outros, enfrentam muitos desafios e oportunidades na aplicação prática. O conteúdo das melhores práticas discutido neste artigo não pode abranger todos os riscos potenciais, mas ainda assim vale a pena que todas as partes considerem e apliquem na operação prática.