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 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.
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
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.
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.
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:
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.
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.
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 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.
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
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.
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.
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:
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.
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.