EIP-3074

Experiência de utilização melhor e mais segura

O EIP-3074 permite que a EOA (Contas de Propriedade Externa) transfira o controle para um contrato especificado, obtendo assim as mesmas capacidades de execução avançadas que o contrato. Antes do EIP-3074, um EOA só podia executar uma operação por transação, como aprovar o ERC20 ou trocar no Uniswap. Após o EIP-3074, um EOA pode executar várias operações ao mesmo tempo, ou até mesmo realizar tarefas anteriormente inimagináveis. Simplificando, o EIP-3074 melhora muito a experiência do usuário, e o conhecido método de autorização de token será remodelado, aumentando a segurança sem alterar a experiência do usuário.

Além disso, através do EIP-3074, a EOA não precisa mais longo enviar transações para a cadeia por si só, eliminando o problema de ter que levantar ETH para pagar taxas de transação.

Contrato do invocador

O contrato que pode obter o controle do EOA é chamado de contrato Invoker. É claro que não é qualquer contrato que pode obter o controle do EOA: o EOA deve assinar com uma chave privada, e o conteúdo da assinatura especificará claramente qual contrato Invoker é e quais operações o Invoker está autorizado a executar.

O conteúdo da assinatura EOA especificará claramente qual contrato Invoker (endereço do invocador) e autorizará as operações desse contrato Invoker (commit)

O processo de execução real provavelmente será assim:

1. Alice assina com sua chave privada EOA e, em seguida, dá o conteúdo da assinatura e assinatura para o Relayer
2. Relayer traz a cadeia para a execução do contrato
3. Invoker O Invoker verifica a assinatura. Depois de passar na verificação, ele pode realizar operações como um EOA, como aprovar USDC, depois ir para Uniswap para exchange e, finalmente, transferir alguns USDC para o Relayer como uma taxa de manipulação.

Nota 1: Não é necessário rematar. Alice também pode trazer seu próprio conteúdo de assinatura e selo para a cadeia.

Depois que o Invoker verificar a assinatura e começar a executar a operação, ela será executada como Alice EOA, o que é como obter controle (limitado) do EOA.

No entanto, deve notar-se que o valor de nonce do EOA não será aumentado após a execução, pelo que a mesma assinatura pode ser reutilizada (longo como o EOA nonce permanece inalterado), pelo que o Invoker precisa de implementar o seu próprio mecanismo de nonce para evitar a repetição.

Se o contrato Invoker não for à prova de reprodução, a mesma autorização pode ser executada o tempo todo.

Para uma introdução ao mecanismo de funcionamento real do EIP-3074, consulte: Introdução ao EIP3074

Application

Permita que os usuários mesclem a execução de várias transações em uma, salvando o processo de várias assinaturas autorizadas e alguns custos de gás.

Nota: Isso exigirá que o dApp também suporte a função Batchcall, como EIP-5792, que está sendo pressionada pela comunidade. Caso contrário, o dApp só solicitará que o usuário assine uma vez para cada operação se tratar o usuário como um EOA normal.

Session Key

Os usuários também podem permitir que terceiros atuem em seu nome sob certas condições. A chave delegada no diagrama abaixo é o terceiro autorizado; a política de acesso é a restrição de execução, como limitá-lo a operar apenas Uniswap, transferir um máximo de 1 ETH por dia, período de validade da autorização, etc. Estas condições são concebidas e verificadas no âmbito do contrato Invoker. À medida longo que a verificação é passada, o terceiro pode executar operações como EOA de um usuário.

O Telegram Bot pode receber permissões específicas para realizar operações em nome do EOA do usuário

Native ETH Permit

Desde longo que as condições sejam cumpridas (ou seja, a assinatura da Permissão é legal), a transferência de ETH pode ser realizada como o autorizante EOA, alcançando o efeito da Licença de ETH nativa.

Ordem de limite

O usuário preenche as condições de limite ordem e, quando as condições são atendidas, pode ser executado como EOA do usuário, incluindo a aprovação de tokens para DEX, indo para DEX para resgate, etc. Em comparação com o Ordem de limite fornecido pela própria DEX, os usuários não precisam enviar transações para DEX para aprovação antecipada.

Quando Alice completa um ordem, ela executará uma aprovação ao mesmo tempo, eliminando a necessidade de aprovação prévia.

Se a condição for projetada para ser mais geral, ela se tornará como um contrato de intenção: longo que as condições especificadas pelo usuário forem atendidas, qualquer pessoa pode executar a intenção em nome de seu EOA.

À medida longo que a condição de intenção é atendida, qualquer pessoa pode iniciar a execução em nome do EOA do usuário

Recuperação Social

Quando o usuário perde a chave privada EOA, ela (Alice) pode usar a autorização EIP-3074 que assinou, juntamente com as assinaturas de sua pessoa autorizada (Marido e Agente Fiduciário) para transferir todos os ativos do EOA. Na realidade, o que é recuperado são os ativos (transferíveis) e não o controlo conta. Depois que a chave privada EOA é perdida, o EOA não pode mais longo ser usado.

Quando o usuário perde a chave privada EOA, outras pessoas autorizadas podem assinar e autorizar a transferência de ativos EOA.

Impacto do EIP-3074

Melhorando os métodos de autorização de token e potencialmente substituindo aprovar/permitir?

Atualmente, os dApps são projetados sob a suposição de que o usuário é um EOA: o usuário deve "pré-aprovar" e "aprovar uma quantidade suficiente de dinheiro" para o contrato dApp. Isso significa que os usuários não precisam ficar online o tempo todo, esperar que o dApp seja executado ou reaprovar constantemente, melhorando muito a experiência do usuário. Para aplicativos acionados por condições, como ordens de limite ou DCA, os usuários podem não estar on-line quando as condições são atendidas, então eles precisam pré-aprovar uma quantidade grande o suficiente de dinheiro para o contrato dApp ser executado, e pode ser um processo repetitivo.

O usuário deve aprovar uma quantia grande o suficiente para o dApp com antecedência para que o dApp possa operar com seu dinheiro.

Mas também é necessário confiar no dApp ou evitar aprovar o dApp falso, e ser capaz de remover a aprovação imediatamente

Os modos de permissão que apareceram mais tarde, como o token nativo EIP-2612 ou o não-nativo Permit2, são todos para melhorar a experiência de uso e a segurança do modo de aprovação: os usuários não precisam mais longo aprovar uma grande quantidade de dinheiro para cada contrato dApp (e cada token tem que ser aprovado uma vez). Em vez disso, o usuário só precisa "assinar um nome" para autorizar o contrato dApp a "retirar o valor especificado" dentro do "tempo especificado". Isso não só reduz muito a superfície de ataque, mas também melhora muito a experiência do usuário.

Os usuários só precisam assinar fora da cadeia, e podem especificar a quantidade e o período de validade, proporcionando uma melhor experiência de usuário e segurança do que aprovar.

Mas, na verdade, não apenas aprovar, o modo de permissão tem sido usado como um método de ataque de golpe com frequência (1,2,3): as vítimas assinaram erroneamente o que pensavam ser uma permissão para um dApp, mas na verdade foi dado ao invasor.

Quando os usuários assinam uma permissão, eles só podem ver quem autorizar, mas não sabem quais operações serão emparelhadas com ela para serem executadas.

Nota: O design atual da licença não é compatível com dApps de operação repetitiva, como DCA ou outros aplicativos de pagamento regulares. Isso ocorre porque a permissão tem um mecanismo de proteção contra replay, portanto, uma vez que uma transferência é concluída, a mesma permissão não pode ser usada novamente, o que significa que os usuários têm que assinar uma permissão com antecedência para cada operação repetitiva futura.

No entanto, o EIP-3074 traz uma oportunidade de mudança: quando os desenvolvedores dApp sabem que a EOA pode executar várias operações complexas através do Invoker, o design da interação dApp não precisa mais longo sacrificar a segurança em ordem para melhorar a experiência do usuário, como "os usuários pré-aprovam uma grande quantidade de dinheiro" e "os usuários assinam uma mensagem de permissão para autorizar a retirada". Em vez disso, os usuários vinculam as operações dApp para aprovar e executar a execução atômica por meio do Invoker: as operações aprovam e dApp são executadas com êxito juntas ou falham juntas. Não há possibilidade de sucesso apenas para aprovação, então os usuários podem ter certeza de que essa aprovação é para esta operação. E os usuários estão usando fora da cadeia autorização de assinatura, então a experiência do usuário é a mesma que permitir! Isso significa que o dApp não precisará mais longo do modo de permissão! No futuro, as carteiras podem banir diretamente ou realizar revisões mais rigorosas de solicitações de assinatura de permissão, sem ter que se preocupar se isso fará com que os usuários não usem alguns dApps (mas, por sua vez, sejam usados para fraudes).

Os usuários não mais longo simplesmente autorizar um determinado endereço, mas autorizar um determinado endereço e o que fazer, e até mesmo ver o resultado da execução simulada.

Nota: Isto não significa que as fraudes possam ser completamente bloqueadas! Os usuários ainda podem ser enganados em sites fraudulentos, e sites fraudulentos ainda podem organizar operações de aprovação ou transferência para os usuários assinarem, mas neste momento os usuários podem pelo menos ver o que essa assinatura vai fazer, e as carteiras podem até simular exibir resultados de execução e apresentá-los aos usuários, para que os usuários possam saber claramente quem perderá quanto dinheiro e quem ganhará quanto dinheiro. Em comparação com as licenças que não sabem qual operação ou mesmo resultado da execução, os usuários têm mais informações para decidir se autorizam. Embora não seja uma cura perfeita, continuará a ser uma melhoria substancial da situação atual.

Como o Carteira lida com nonces EOA

O design atual do EIP-3074 incluirá o valor de nonce EOA no conteúdo da assinatura, de modo que, longo EOA enviar uma transação para a cadeia para execução e alterar o valor nonce, todas as autorizações EIP-3074 originais serão invalidadas.

Se o usuário estiver autorizando outra pessoa a operar o EOA, como a chave de sessão ou o método de recuperação social mencionado acima, o nonce do EOA deve ser impedido de mudar. Caso contrário, é necessário assinar todas as autorizações novamente e entregá-las ao síndico, o que tem um impacto considerável na experiência do usuário e na robustez do mecanismo.

Se o usuário estiver autorizado a operar por conta própria, não há necessidade de impedir especificamente que o nonce EOA seja alterado, porque a assinatura EIP-3074 ainda deve ser executada antes de um determinado prazo como a transação. É apenas que a carteira precisa gerenciar mais transações EIP-3074 do EOA: se houver assinaturas EIP-3074 esperando para serem carregadas na cadeia, então as transações do próprio EOA terão que esperar.

Nota: O próprio contrato Invoker manterá (e deverá) um conjunto de mecanismos de nonce, portanto, depois que a assinatura for usada, ele ainda precisa ser assinado novamente, independentemente de o EOA nonce alterações.

A Chave de Sessão e a Recuperação Social provavelmente terão que esperar até que o EIP-3074 altere as regras para remover o nonce EOA do conteúdo da assinatura antes que eles possam ser adotados em grande escala. Portanto, a carteira só precisa se concentrar no caso de uso de "operações autorizadas pelo usuário" e tratar a assinatura EIP-3074 como uma transação. Não há necessidade de se preocupar em evitar o envio de transações EOA ou alterar o nonce EOA.

No entanto, deve-se notar que, se o usuário quiser trazer seu próprio conteúdo de assinatura EIP-3074 para a cadeia, haverá duas desvantagens:

1. O usuário precisa assinar duas vezes: uma para a assinatura EIP-3074 e outra para a assinatura na cadeia transação.
2. Como a transação na cadeia adicionará 1 ao nonce EOA antes que a transação comece a ser executada, o nonce EOA na assinatura EIP-3074 do usuário precisa ser pré-adicionado 1 para corresponder ao EOA nonce +1 causado pela própria cadeia.

Como a cadeia adicionará 1 ao EOA nonce primeiro, a verificação da assinatura EIP-3074 falhará devido a incompatibilidade de nonce EOA.

Se os usuários adicionarem 1 ao nonce EOA na assinatura EIP-3074 antes de trazê-lo para a cadeia, a verificação poderá prosseguir sem problemas.

Resumo e destaques

• O EIP-3074 permite que o EOA obtenha os mesmos recursos de execução avançados que os contratos, abrindo muitos novos cenários de aplicativos.
• Isso não só melhorará muito a experiência do usuário, mas também mudará o método de autorização de token atual, tornando-o mais seguro, mantendo a mesma experiência do usuário.
• Além disso, o EIP-3074 é uma assinatura simples, e os usuários não precisam necessariamente trazer a assinatura para a cadeia para execução, então não há necessidade de se preocupar em reunir ETH para pagar taxas de transação.
• Os usos do EIP-3074 incluem Batch Call, Session Key, Native ETH Permit, Ordem de limite e Social Recovery. Muitas delas eram anteriormente impossíveis de alcançar e algumas, como Ordem de limite, exigiam a utilização de métodos de pré-autorização inseguros.
• EIP-3074 também alterará o método de autorização de token atual. O método approve autoriza diretamente um endereço específico a ter o poder de retirar tokens indefinidamente, e requer que o EOA do usuário envie uma transação para executar a aprovação, de modo que a experiência do usuário e a segurança não sejam boas; O método de permissão requer apenas que o usuário assine, e cada assinatura especificará a quantidade e o período de validade, o que melhora muito a experiência e a segurança do usuário em comparação com a aprovação.
• No entanto, a permissão ainda é frequentemente usada em golpes. Ao assinar, os usuários só podem saber quem autorizar, quanto e o prazo de validade, mas não sabem para que serve essa autorização. "Para que serve" será outra assinatura (ou transação). Os dApps normais permitirão que os usuários assinem a permissão e "para que serve", mas ainda serão duas assinaturas diferentes, portanto, quando solicitado a assinar a permissão, nem o usuário nem a carteira podem saber para que essa permissão será usada.
• Com o EIP-3074, os usuários (1) não precisam aprovar uma grande quantidade de dinheiro para dApp com antecedência, mas só precisam aprovar quando há uma operação, que tem o mesmo efeito que a permissão; (2) é apenas uma assinatura simples e não precisa se preocupar em reunir ETH para pagar a taxa de transação, que é a mesma que a permissão; (3) cada aprovação está ligada a uma operação específica e assinada em conjunto, para que os utilizadores possam saber claramente para que serve esta aprovação, o que será mais seguro do que a licença!
• Espera-se que o EIP-3074 possa substituir com sucesso os atuais modos de aprovação e permissão e fornecer aos usuários um método de autorização mais seguro.

Declaração de exoneração de responsabilidade:

1. Este artigo foi reproduzido a partir de [imToken Labs]. Todos os direitos autorais pertencem ao autor original [Nada]. Se houver objeções a essa reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso imediatamente.
2. Isenção de Responsabilidade: Os pontos de vista e opiniões expressos neste artigo são exclusivamente 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 mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.