Impacto do EIP-3074 nas Carteiras e DApps

Intermediário5/27/2024, 9:17:11 AM
EIP-3074 permite que contas de propriedade externa (EOAs) deleguem o controle para um contrato especificado, obtendo assim as extensas capacidades de execução semelhantes a contratos. Isso melhora significativamente a experiência do usuário e pode redefinir os atuais métodos de autorização familiares, melhorando a segurança sem comprometer a usabilidade. Nic, do imToken Labs, analisa o impacto do EIP-3074, incluindo melhorias nos métodos de autorização de ativos.

EIP-3074

Experiência do utilizador melhor e mais segura

O EIP-3074 permite que as EOAs deleguem o controlo a contratos específicos, ganhando assim capacidades de execução semelhantes às dos contratos. Antes do EIP-3074, uma EOA só podia realizar uma operação por transação, como aprovar um token ERC20 ou fazer uma troca na Uniswap. Após o EIP-3074, uma EOA pode concluir várias operações numa única transação, permitindo casos de uso anteriormente inimagináveis. Em essência, o EIP-3074 melhora significativamente a experiência do utilizador e remodela os métodos de autorização familiares, ao mesmo tempo que melhora a segurança.

Além disso, com o EIP-3074, as EOAs já não precisam de enviar transações por conta própria na cadeia, eliminando assim a necessidade de adquirir primeiro ETH para pagar as taxas de transação.

Contratos Invoker

Contratos que podem obter controlo de EOAs são chamados de contratos Invoker. Não é qualquer contrato que pode obter controlo; o EOA deve assinar com a sua chave privada, especificando qual contrato Invoker e quais operações autoriza o Invoker a realizar.

O processo normalmente envolve:

Alice assina com a sua chave privada EOA, especificando o contrato Invoker e as operações autorizadas.

Alice submete o conteúdo assinado e a assinatura a um Repassador.

O Relayer envia a transação on-chain para o contrato Invoker.

O Invoker verifica a assinatura e, após validação, executa as operações como a EOA de Alice, como aprovar USDC, trocar ativos na Uniswap e usar algum USDC para pagar ao Relayer como taxa.

Nota: O Relayer é opcional; Alice pode enviar o conteúdo assinado e a assinatura na cadeia por si mesma.

Evitar Ataques de Repetição

O Invoker executa operações como se tivesse controle limitado da EOA da Alice. No entanto, o nonce da EOA não aumenta após a execução, o que significa que a mesma assinatura poderia potencialmente ser reutilizada desde que o nonce da EOA permaneça inalterado. Portanto, o Invoker deve implementar seu mecanismo de nonce para evitar ataques de repetição.

Saber mais

Para uma introdução detalhada ao funcionamento do EIP-3074, por favor consulte:https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

Aplicações do EIP-3074

Chamada em lote

Batchcall permite aos utilizadores combinar múltiplas transações numa, poupando o processo de múltiplas assinaturas de autorização e alguns custos de gás. Note-se que isto requer que as DApps suportem a funcionalidade Batchcall, tal como o EIP-5792 atualmente promovido. Sem tal suporte, as DApps irão solicitar uma transação separada para cada operação, tratando o utilizador como um EOA regular.

Para mais informações sobre EIP-5792, consulte: EIP-5792.

Chave de Sessão

Os utilizadores podem delegar operações a terceiros sob condições específicas usando uma chave de sessão. No exemplo abaixo, a chave de delegação representa o terceiro autorizado, enquanto a política de acesso define as restrições operacionais, como limitar ações ao Uniswap, limitar transferências a 1 ETH por dia ou definir uma data de validade de autorização. Estas condições são concebidas e verificadas dentro do contrato Invoker. Uma vez que as verificações sejam aprovadas, o terceiro pode realizar operações como o EOA do utilizador.

Por exemplo, um Bot do Telegram poderia receber permissões específicas para executar operações em nome do EOA do utilizador.

Permissão ETH nativa

Se as condições forem cumpridas (ou seja, a assinatura do permisso é válida), as operações podem ser executadas como o EOA autorizante, possibilitando a funcionalidade nativa ETH Permit.

Ordem Limitada

Os utilizadores podem definir condições de ordens limitadas, que, uma vez cumpridas, permitem que as operações sejam executadas como a EOA do utilizador. Isso inclui aprovar ativos digitais relevantes para um DApp e trocar ativos no DApp. Comparado com a funcionalidade de ordem limitada fornecida pelos próprios DApps, os utilizadores não precisam de aprovar previamente ativos para o DApp.

Por exemplo, quando Alice completa uma ordem de limite, a aprovação é executada simultaneamente, eliminando a necessidade de aprovação prévia.

Ao projetar as condições de forma mais geral, um contrato de Intenção pode ser criado: desde que as condições especificadas sejam cumpridas, qualquer pessoa pode executar a intenção em nome da EOA do usuário.

Recuperação Social

Se um usuário perder sua chave privada EOA, ele pode usar a autorização EIP-3074 assinada anteriormente, juntamente com assinaturas de partes autorizadas (por exemplo, Marido e Agente Fiduciário), para transferir todos os ativos do EOA. Isso recupera os ativos (transferíveis), não o controle da conta. Uma vez que a chave privada EOA é perdida, o EOA não pode ser usado novamente.

Melhorando os Métodos de Autorização de Ativos

EIP-3074 tem o potencial para melhorar ou até substituir os métodos atuais de aprovação/permissão. As DApps operam atualmente sob a suposição de que os usuários são EOAs: os usuários devem pré-aprovar uma quantidade suficientemente grande de ativos para o contrato DApp para evitar ficar online constantemente e aprovar repetidamente transações. Isso melhora significativamente a experiência do usuário.

Por exemplo, aplicações condicionais como ordens limitadas ou DCA exigem que os utilizadores pré-aprovem uma grande quantidade de ativos para que a DApp possa executar operações quando as condições são cumpridas, potencialmente várias vezes.

No entanto, isso requer que os usuários confiem no DApp ou evitem aprovar DApps falsos, e eles devem ser capazes de remover aprovações em tempo real.

Modelos de permissão recentes como EIP-2612 ou o Permit2 não nativo visam melhorar a experiência do usuário e a segurança do modelo de aprovação. Os usuários não precisam aprovar grandes quantidades de ativos para cada contrato DApp; em vez disso, podem autorizar DApps a retirar uma quantidade especificada de ativos dentro de um tempo especificado, assinando uma vez. Isso reduz consideravelmente a superfície de ataque e melhora a experiência do usuário.

△ Os utilizadores só precisam de assinar off-chain e podem especificar o montante do ativo e o período de validade, proporcionando uma melhor experiência e segurança do que aprovação.

No entanto, na realidade, não apenas aprovar, o modo de permissão ainda é frequentemente explorado como um método fraudulento. As vítimas assinam erroneamente autorizações que acreditam ser para uso do DApp, mas na verdade estão dando autorização aos atacantes.

△ Quando os utilizadores assinam uma autorização, apenas conseguem ver quem estão a autorizar, mas não sabem quais operações serão realizadas em conjunto com ela.

Nota:O design atual do certificado é incompatível com DApps que requerem operações repetitivas, como DCA ou outras aplicações de pagamento periódico. Isto acontece porque o certificado tem um mecanismo anti-replay, então, uma vez que uma transação é concluída, o mesmo certificado não pode ser utilizado novamente. Basicamente, os utilizadores precisam de pré-assinar certificados para cada operação repetitiva futura.

Saber Mais:

Para entender mais sobre incidentes em que o modo de permissão foi explorado como um método de golpe, por favor copie os seguintes links no seu navegador para mais informações:

No entanto, o EIP-3074 traz uma oportunidade de mudança: quando os desenvolvedores de DApp percebem que a EOA pode realizar várias operações complexas através do Invoker, o design das interações do DApp não precisará mais sacrificar a segurança para obter uma melhor experiência do usuário, como "os usuários aprovando uma grande quantidade de ativos antecipadamente" ou "os usuários assinando uma mensagem de permissão para autorizar saques".

Em vez disso, os utilizadores irão associar a operação da DApp com a ação de aprovação, executando-as atomicamente através do Invoker: ou ambas a aprovação e a operação da DApp têm sucesso em conjunto ou falham em conjunto. Não há possibilidade de a ação de aprovação ter sucesso sozinha, por isso os utilizadores podem ter a certeza de que esta ação de aprovação é especificamente para a operação atual.

Além disso, os utilizadores autorizam usando assinaturas fora da cadeia, por isso a experiência do utilizador é a mesma que com a carta! Isto significa que as DApps já não precisarão do modo de autorização! No futuro, as carteiras podem bloquear diretamente ou escrutinar mais estritamente os pedidos de assinatura de autorização sem se preocuparem em impedir os utilizadores de aceder a certas DApps (mas sim em serem explorados por fraudes).

△ Os utilizadores já não autorizarão apenas um determinado endereço, mas também especificarão quais ações podem ser realizadas, e até podem ver os resultados da execução simulada.

Nota:Isto não significa que as fraudes possam ser completamente evitadas! Os utilizadores ainda podem ser enganados por sites de fraude, e os sites de fraude ainda podem criar operações de aprovação ou transferência para os utilizadores assinarem. No entanto, neste ponto, os utilizadores podem pelo menos ver que operações a assinatura está a autorizar. As carteiras até podem simular e mostrar os resultados da execução, mostrando claramente aos utilizadores quem perderá dinheiro e quem ganhará dinheiro. Em comparação com as autorizações em que os utilizadores não podem saber as operações ou os resultados da execução, os utilizadores agora têm mais informações para decidir se autorizam. Embora não seja uma solução perfeita, ainda é uma melhoria significativa em relação à situação atual.

Como as Carteiras Lidam com o Nonce EOA

Atualmente, o design do EIP-3074 inclui o valor do nonce do EOA no conteúdo da assinatura. Portanto, assim que o EOA envia uma transação on-chain que altera o valor do nonce, todas as autorizações existentes do EIP-3074 tornam-se inválidas.

Se um usuário autoriza outros a operar sua EOA em seu nome, como através da Chave de Sessão ou dos métodos de Recuperação Social mencionados acima, o nonce da EOA deve permanecer inalterado. Caso contrário, todas as autorizações devem ser reassinadas e entregues ao curador, o que impacta significativamente tanto a experiência do usuário quanto a robustez do mecanismo.

Se o usuário está autorizando a si mesmo a operar, então não há necessidade de evitar a mudança do nonce EOA. As assinaturas EIP-3074, como transações, devem ser executadas dentro de um certo período. No entanto, as carteiras devem gerir as transações EIP-3074 para o EOA: se houver uma assinatura EIP-3074 aguardando para ir para a cadeia, quaisquer transações EOA devem aguardar.

Nota:O contrato Invoker em si deve manter um mecanismo de nonce separado, para que cada assinatura seja renovada independentemente de alterações no nonce do EOA.

A Chave de Sessão e a Recuperação Social provavelmente serão amplamente adotadas apenas depois de o EIP-3074 modificar as regras para remover o nonce do EOA do conteúdo da assinatura. Portanto, as carteiras devem focar no cenário em que os 'utilizadores se autorizam a operar' e tratar as assinaturas do EIP-3074 como fariam com as transações, evitando preocupações sobre transações EOA que alteram o nonce.

No entanto, se os utilizadores quiserem submeter a sua assinatura EIP-3074 na cadeia por si próprios, existem duas desvantagens:

  1. Os utilizadores precisam de assinar duas vezes: uma vez para a assinatura EIP-3074 e outra vez para a assinatura da transação na cadeia.

  2. Uma vez que a transação on-chain irá incrementar o nonce do EOA antes da execução, o nonce do EOA da assinatura EIP-3074 deve ser pré-incrementado para corresponder à alteração do nonce causada pela transação on-chain.

△ Porque a transação na cadeia aumenta o nonce da EOA, a verificação de assinatura EIP-3074 falhará se os nonces não coincidirem.

△ Os utilizadores precisam de pré-incrementar o nonce EOA na assinatura EIP-3074 para passar com sucesso na verificação.

Ao compreender essas nuances, os provedores de carteira podem gerenciar melhor o tratamento de nonce do EOA, garantindo uma experiência do usuário mais suave e segura com autorizações EIP-3074.

Resumo e destaques

  • EIP-3074 concede às EOAs (Contas de Propriedade Externa) as mesmas capacidades de execução avançadas que os contratos, desbloqueando inúmeros novos cenários de aplicação.
  • Isso não só melhora significativamente a experiência do utilizador, mas também transforma os métodos de autorização atuais, tornando-os mais seguros sem comprometer a usabilidade.
  • Além disso, o EIP-3074 envolve assinaturas simples, para que os utilizadores não tenham necessariamente de executar essas assinaturas na cadeia por si próprios, eliminando a necessidade de reunir ETH para pagar as taxas de transação.
  • Os usos do EIP-3074 incluem Chamada em Lote, Chave de Sessão, Permissão ETH Nativa, Ordem Limitada e Recuperação Social. Muitos destes são originalmente impossíveis de alcançar com EOA, e alguns, como a Ordem Limitada, requerem pré-autorização e outros métodos menos seguros para serem utilizados.
  • Anteriormente, isso era impossível para EOAs. Por exemplo, usar Ordem Limitada exigia métodos menos seguros como pré-autorização.
  • O EIP-3074 também irá alterar os métodos de autorização atuais. O método de aprovação autoriza diretamente um endereço especificado a retirar ativos digitais ilimitados indefinidamente, exigindo que o EOA do utilizador envie uma transação para executar a aprovação, resultando numa fraca experiência do utilizador e segurança. O método de permissão apenas requer a assinatura do utilizador, e cada assinatura especifica o montante do ativo e o período de validade, melhorando significativamente a experiência do utilizador e a segurança em comparação com a aprovação.
  • No entanto, o método de permissão ainda é frequentemente explorado em esquemas fraudulentos. Ao assinar, os utilizadores apenas conseguem ver o endereço, a quantidade de ativos e o período de validade que estão a autorizar, mas não o propósito da autorização. O propósito seria definido noutra assinatura (ou transação). Uma DApp legítima exigiria que o utilizador assinasse tanto a permissão como o propósito, mas estas são duas assinaturas separadas. Portanto, quando solicitados a assinar uma permissão, os utilizadores e as carteiras não conseguem determinar o uso pretendido da permissão.
  • Com o EIP-3074, os utilizadores (1) não precisam de aprovar antecipadamente uma grande quantidade de ativos para o DApp, mas apenas aprovar quando há uma operação e o efeito é o mesmo que permissão; (2) apenas assinar e não precisar de se preocupar em recolher ETH para pagar a taxa do procedimento é o mesmo que permissão; (3) Cada aprovação está vinculada à operação especificada e assinada em conjunto. O utilizador pode saber claramente para que é usada a aprovação desta vez. Isto será mais seguro do que permissão!
  • Espera-se que o EIP-3074 substitua com sucesso os métodos atuais de aprovação e permissão, proporcionando aos usuários um método de autorização mais seguro.

Aviso legal:

  1. Este artigo é reproduzido a partir de [imToken Labs]. Todos os direitos de autor pertencem ao autor original [Nic]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles vão lidar com isso prontamente.
  2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
  3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.

Impacto do EIP-3074 nas Carteiras e DApps

Intermediário5/27/2024, 9:17:11 AM
EIP-3074 permite que contas de propriedade externa (EOAs) deleguem o controle para um contrato especificado, obtendo assim as extensas capacidades de execução semelhantes a contratos. Isso melhora significativamente a experiência do usuário e pode redefinir os atuais métodos de autorização familiares, melhorando a segurança sem comprometer a usabilidade. Nic, do imToken Labs, analisa o impacto do EIP-3074, incluindo melhorias nos métodos de autorização de ativos.

EIP-3074

Experiência do utilizador melhor e mais segura

O EIP-3074 permite que as EOAs deleguem o controlo a contratos específicos, ganhando assim capacidades de execução semelhantes às dos contratos. Antes do EIP-3074, uma EOA só podia realizar uma operação por transação, como aprovar um token ERC20 ou fazer uma troca na Uniswap. Após o EIP-3074, uma EOA pode concluir várias operações numa única transação, permitindo casos de uso anteriormente inimagináveis. Em essência, o EIP-3074 melhora significativamente a experiência do utilizador e remodela os métodos de autorização familiares, ao mesmo tempo que melhora a segurança.

Além disso, com o EIP-3074, as EOAs já não precisam de enviar transações por conta própria na cadeia, eliminando assim a necessidade de adquirir primeiro ETH para pagar as taxas de transação.

Contratos Invoker

Contratos que podem obter controlo de EOAs são chamados de contratos Invoker. Não é qualquer contrato que pode obter controlo; o EOA deve assinar com a sua chave privada, especificando qual contrato Invoker e quais operações autoriza o Invoker a realizar.

O processo normalmente envolve:

Alice assina com a sua chave privada EOA, especificando o contrato Invoker e as operações autorizadas.

Alice submete o conteúdo assinado e a assinatura a um Repassador.

O Relayer envia a transação on-chain para o contrato Invoker.

O Invoker verifica a assinatura e, após validação, executa as operações como a EOA de Alice, como aprovar USDC, trocar ativos na Uniswap e usar algum USDC para pagar ao Relayer como taxa.

Nota: O Relayer é opcional; Alice pode enviar o conteúdo assinado e a assinatura na cadeia por si mesma.

Evitar Ataques de Repetição

O Invoker executa operações como se tivesse controle limitado da EOA da Alice. No entanto, o nonce da EOA não aumenta após a execução, o que significa que a mesma assinatura poderia potencialmente ser reutilizada desde que o nonce da EOA permaneça inalterado. Portanto, o Invoker deve implementar seu mecanismo de nonce para evitar ataques de repetição.

Saber mais

Para uma introdução detalhada ao funcionamento do EIP-3074, por favor consulte:https://medium.com/taipei-ethereum-meetup/eip3074-%E7%B0%A1%E4%BB%8B-2a880b918234

Aplicações do EIP-3074

Chamada em lote

Batchcall permite aos utilizadores combinar múltiplas transações numa, poupando o processo de múltiplas assinaturas de autorização e alguns custos de gás. Note-se que isto requer que as DApps suportem a funcionalidade Batchcall, tal como o EIP-5792 atualmente promovido. Sem tal suporte, as DApps irão solicitar uma transação separada para cada operação, tratando o utilizador como um EOA regular.

Para mais informações sobre EIP-5792, consulte: EIP-5792.

Chave de Sessão

Os utilizadores podem delegar operações a terceiros sob condições específicas usando uma chave de sessão. No exemplo abaixo, a chave de delegação representa o terceiro autorizado, enquanto a política de acesso define as restrições operacionais, como limitar ações ao Uniswap, limitar transferências a 1 ETH por dia ou definir uma data de validade de autorização. Estas condições são concebidas e verificadas dentro do contrato Invoker. Uma vez que as verificações sejam aprovadas, o terceiro pode realizar operações como o EOA do utilizador.

Por exemplo, um Bot do Telegram poderia receber permissões específicas para executar operações em nome do EOA do utilizador.

Permissão ETH nativa

Se as condições forem cumpridas (ou seja, a assinatura do permisso é válida), as operações podem ser executadas como o EOA autorizante, possibilitando a funcionalidade nativa ETH Permit.

Ordem Limitada

Os utilizadores podem definir condições de ordens limitadas, que, uma vez cumpridas, permitem que as operações sejam executadas como a EOA do utilizador. Isso inclui aprovar ativos digitais relevantes para um DApp e trocar ativos no DApp. Comparado com a funcionalidade de ordem limitada fornecida pelos próprios DApps, os utilizadores não precisam de aprovar previamente ativos para o DApp.

Por exemplo, quando Alice completa uma ordem de limite, a aprovação é executada simultaneamente, eliminando a necessidade de aprovação prévia.

Ao projetar as condições de forma mais geral, um contrato de Intenção pode ser criado: desde que as condições especificadas sejam cumpridas, qualquer pessoa pode executar a intenção em nome da EOA do usuário.

Recuperação Social

Se um usuário perder sua chave privada EOA, ele pode usar a autorização EIP-3074 assinada anteriormente, juntamente com assinaturas de partes autorizadas (por exemplo, Marido e Agente Fiduciário), para transferir todos os ativos do EOA. Isso recupera os ativos (transferíveis), não o controle da conta. Uma vez que a chave privada EOA é perdida, o EOA não pode ser usado novamente.

Melhorando os Métodos de Autorização de Ativos

EIP-3074 tem o potencial para melhorar ou até substituir os métodos atuais de aprovação/permissão. As DApps operam atualmente sob a suposição de que os usuários são EOAs: os usuários devem pré-aprovar uma quantidade suficientemente grande de ativos para o contrato DApp para evitar ficar online constantemente e aprovar repetidamente transações. Isso melhora significativamente a experiência do usuário.

Por exemplo, aplicações condicionais como ordens limitadas ou DCA exigem que os utilizadores pré-aprovem uma grande quantidade de ativos para que a DApp possa executar operações quando as condições são cumpridas, potencialmente várias vezes.

No entanto, isso requer que os usuários confiem no DApp ou evitem aprovar DApps falsos, e eles devem ser capazes de remover aprovações em tempo real.

Modelos de permissão recentes como EIP-2612 ou o Permit2 não nativo visam melhorar a experiência do usuário e a segurança do modelo de aprovação. Os usuários não precisam aprovar grandes quantidades de ativos para cada contrato DApp; em vez disso, podem autorizar DApps a retirar uma quantidade especificada de ativos dentro de um tempo especificado, assinando uma vez. Isso reduz consideravelmente a superfície de ataque e melhora a experiência do usuário.

△ Os utilizadores só precisam de assinar off-chain e podem especificar o montante do ativo e o período de validade, proporcionando uma melhor experiência e segurança do que aprovação.

No entanto, na realidade, não apenas aprovar, o modo de permissão ainda é frequentemente explorado como um método fraudulento. As vítimas assinam erroneamente autorizações que acreditam ser para uso do DApp, mas na verdade estão dando autorização aos atacantes.

△ Quando os utilizadores assinam uma autorização, apenas conseguem ver quem estão a autorizar, mas não sabem quais operações serão realizadas em conjunto com ela.

Nota:O design atual do certificado é incompatível com DApps que requerem operações repetitivas, como DCA ou outras aplicações de pagamento periódico. Isto acontece porque o certificado tem um mecanismo anti-replay, então, uma vez que uma transação é concluída, o mesmo certificado não pode ser utilizado novamente. Basicamente, os utilizadores precisam de pré-assinar certificados para cada operação repetitiva futura.

Saber Mais:

Para entender mais sobre incidentes em que o modo de permissão foi explorado como um método de golpe, por favor copie os seguintes links no seu navegador para mais informações:

No entanto, o EIP-3074 traz uma oportunidade de mudança: quando os desenvolvedores de DApp percebem que a EOA pode realizar várias operações complexas através do Invoker, o design das interações do DApp não precisará mais sacrificar a segurança para obter uma melhor experiência do usuário, como "os usuários aprovando uma grande quantidade de ativos antecipadamente" ou "os usuários assinando uma mensagem de permissão para autorizar saques".

Em vez disso, os utilizadores irão associar a operação da DApp com a ação de aprovação, executando-as atomicamente através do Invoker: ou ambas a aprovação e a operação da DApp têm sucesso em conjunto ou falham em conjunto. Não há possibilidade de a ação de aprovação ter sucesso sozinha, por isso os utilizadores podem ter a certeza de que esta ação de aprovação é especificamente para a operação atual.

Além disso, os utilizadores autorizam usando assinaturas fora da cadeia, por isso a experiência do utilizador é a mesma que com a carta! Isto significa que as DApps já não precisarão do modo de autorização! No futuro, as carteiras podem bloquear diretamente ou escrutinar mais estritamente os pedidos de assinatura de autorização sem se preocuparem em impedir os utilizadores de aceder a certas DApps (mas sim em serem explorados por fraudes).

△ Os utilizadores já não autorizarão apenas um determinado endereço, mas também especificarão quais ações podem ser realizadas, e até podem ver os resultados da execução simulada.

Nota:Isto não significa que as fraudes possam ser completamente evitadas! Os utilizadores ainda podem ser enganados por sites de fraude, e os sites de fraude ainda podem criar operações de aprovação ou transferência para os utilizadores assinarem. No entanto, neste ponto, os utilizadores podem pelo menos ver que operações a assinatura está a autorizar. As carteiras até podem simular e mostrar os resultados da execução, mostrando claramente aos utilizadores quem perderá dinheiro e quem ganhará dinheiro. Em comparação com as autorizações em que os utilizadores não podem saber as operações ou os resultados da execução, os utilizadores agora têm mais informações para decidir se autorizam. Embora não seja uma solução perfeita, ainda é uma melhoria significativa em relação à situação atual.

Como as Carteiras Lidam com o Nonce EOA

Atualmente, o design do EIP-3074 inclui o valor do nonce do EOA no conteúdo da assinatura. Portanto, assim que o EOA envia uma transação on-chain que altera o valor do nonce, todas as autorizações existentes do EIP-3074 tornam-se inválidas.

Se um usuário autoriza outros a operar sua EOA em seu nome, como através da Chave de Sessão ou dos métodos de Recuperação Social mencionados acima, o nonce da EOA deve permanecer inalterado. Caso contrário, todas as autorizações devem ser reassinadas e entregues ao curador, o que impacta significativamente tanto a experiência do usuário quanto a robustez do mecanismo.

Se o usuário está autorizando a si mesmo a operar, então não há necessidade de evitar a mudança do nonce EOA. As assinaturas EIP-3074, como transações, devem ser executadas dentro de um certo período. No entanto, as carteiras devem gerir as transações EIP-3074 para o EOA: se houver uma assinatura EIP-3074 aguardando para ir para a cadeia, quaisquer transações EOA devem aguardar.

Nota:O contrato Invoker em si deve manter um mecanismo de nonce separado, para que cada assinatura seja renovada independentemente de alterações no nonce do EOA.

A Chave de Sessão e a Recuperação Social provavelmente serão amplamente adotadas apenas depois de o EIP-3074 modificar as regras para remover o nonce do EOA do conteúdo da assinatura. Portanto, as carteiras devem focar no cenário em que os 'utilizadores se autorizam a operar' e tratar as assinaturas do EIP-3074 como fariam com as transações, evitando preocupações sobre transações EOA que alteram o nonce.

No entanto, se os utilizadores quiserem submeter a sua assinatura EIP-3074 na cadeia por si próprios, existem duas desvantagens:

  1. Os utilizadores precisam de assinar duas vezes: uma vez para a assinatura EIP-3074 e outra vez para a assinatura da transação na cadeia.

  2. Uma vez que a transação on-chain irá incrementar o nonce do EOA antes da execução, o nonce do EOA da assinatura EIP-3074 deve ser pré-incrementado para corresponder à alteração do nonce causada pela transação on-chain.

△ Porque a transação na cadeia aumenta o nonce da EOA, a verificação de assinatura EIP-3074 falhará se os nonces não coincidirem.

△ Os utilizadores precisam de pré-incrementar o nonce EOA na assinatura EIP-3074 para passar com sucesso na verificação.

Ao compreender essas nuances, os provedores de carteira podem gerenciar melhor o tratamento de nonce do EOA, garantindo uma experiência do usuário mais suave e segura com autorizações EIP-3074.

Resumo e destaques

  • EIP-3074 concede às EOAs (Contas de Propriedade Externa) as mesmas capacidades de execução avançadas que os contratos, desbloqueando inúmeros novos cenários de aplicação.
  • Isso não só melhora significativamente a experiência do utilizador, mas também transforma os métodos de autorização atuais, tornando-os mais seguros sem comprometer a usabilidade.
  • Além disso, o EIP-3074 envolve assinaturas simples, para que os utilizadores não tenham necessariamente de executar essas assinaturas na cadeia por si próprios, eliminando a necessidade de reunir ETH para pagar as taxas de transação.
  • Os usos do EIP-3074 incluem Chamada em Lote, Chave de Sessão, Permissão ETH Nativa, Ordem Limitada e Recuperação Social. Muitos destes são originalmente impossíveis de alcançar com EOA, e alguns, como a Ordem Limitada, requerem pré-autorização e outros métodos menos seguros para serem utilizados.
  • Anteriormente, isso era impossível para EOAs. Por exemplo, usar Ordem Limitada exigia métodos menos seguros como pré-autorização.
  • O EIP-3074 também irá alterar os métodos de autorização atuais. O método de aprovação autoriza diretamente um endereço especificado a retirar ativos digitais ilimitados indefinidamente, exigindo que o EOA do utilizador envie uma transação para executar a aprovação, resultando numa fraca experiência do utilizador e segurança. O método de permissão apenas requer a assinatura do utilizador, e cada assinatura especifica o montante do ativo e o período de validade, melhorando significativamente a experiência do utilizador e a segurança em comparação com a aprovação.
  • No entanto, o método de permissão ainda é frequentemente explorado em esquemas fraudulentos. Ao assinar, os utilizadores apenas conseguem ver o endereço, a quantidade de ativos e o período de validade que estão a autorizar, mas não o propósito da autorização. O propósito seria definido noutra assinatura (ou transação). Uma DApp legítima exigiria que o utilizador assinasse tanto a permissão como o propósito, mas estas são duas assinaturas separadas. Portanto, quando solicitados a assinar uma permissão, os utilizadores e as carteiras não conseguem determinar o uso pretendido da permissão.
  • Com o EIP-3074, os utilizadores (1) não precisam de aprovar antecipadamente uma grande quantidade de ativos para o DApp, mas apenas aprovar quando há uma operação e o efeito é o mesmo que permissão; (2) apenas assinar e não precisar de se preocupar em recolher ETH para pagar a taxa do procedimento é o mesmo que permissão; (3) Cada aprovação está vinculada à operação especificada e assinada em conjunto. O utilizador pode saber claramente para que é usada a aprovação desta vez. Isto será mais seguro do que permissão!
  • Espera-se que o EIP-3074 substitua com sucesso os métodos atuais de aprovação e permissão, proporcionando aos usuários um método de autorização mais seguro.

Aviso legal:

  1. Este artigo é reproduzido a partir de [imToken Labs]. Todos os direitos de autor pertencem ao autor original [Nic]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles vão lidar com isso prontamente.
  2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
  3. As traduções do artigo para outros idiomas são feitas pela equipe do Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.
今すぐ始める
登録して、
$100
のボーナスを獲得しよう!