PEI-3074 Experiência de

uso melhor e mais segura

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

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

Contrato Invoker

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 do Invoker é e quais operações o Invoker tem permissão para executar.

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

O processo de execução real provavelmente terá a seguinte aparência:

1. Alice assina com sua chave privada EOA e, em seguida, fornece o conteúdo da assinatura e a assinatura para o Relayer
2. Relayer traz a cadeia para a execução do contrato do Invoker
3. O Invoker verifica a assinatura. Depois de passar pela verificação, ele pode executar 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 manuseio.

Nota 1: Relayer não é necessário. 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 o controle (limitado) do EOA.

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

Se o contrato do Invoker não for à prova de repetição, a mesma autorização poderá ser executada o tempo todo.

Para obter uma introdução ao mecanismo operacional real do PEI-3074, consulte: Introdução ao EIP3074

Application

Batchcall

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

Nota: Isso exigirá que o dApp também apoiar a função Batchcall, como PEI-5792, que está sendo empurrada pela comunidade. Caso contrário, o dApp solicitará que o usuário assine apenas 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 ajam 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 no máximo 1 ETH por dia, prazo de validade da autorização, etc. Essas condições são projetadas e verificadas dentro do contrato do Invoker. 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 atendidas (ou seja, a assinatura do Permit seja legal), a transferência de ETH pode ser realizada como o EOA autorizador, obtendo o efeito do ETH Permit nativo.

Ordem de limite

O usuário preenche o limite ordem condições, e quando as condições são atendidas, ele pode ser executado como o 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 pelo próprio DEX, os usuários não precisam enviar transações para DEX para aprovação antecipada.

Quando Alice completa um ordem, ela executa 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 sejam atendidas, qualquer pessoa pode executar a intenção em nome de seu EOA.

longo que a condição de intenção for atendida, qualquer pessoa poderá 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 PEI-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), não o controle conta. Depois que a chave privada do EOA for perdida, o EOA não poderá mais tempo 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 PEI-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, portanto, precisam pré-aprovar uma quantidade grande o suficiente de dinheiro para que o contrato dApp seja 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 PEI-2612 nativo do token ou o Permit2 não nativo, 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 aprovar mais tempo grande quantidade de dinheiro para cada contrato dApp (e cada token precisa 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 fazer fora da cadeia e podem especificar o valor 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 fraudulento com frequência (1,2,3): as vítimas assinaram por engano o que pensavam ser uma permissão para um dApp, mas na verdade foi dado ao atacante.

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

Nota: O design de permissão atual 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 repetição, 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 PEI-3074 traz uma oportunidade de mudança: quando os desenvolvedores do dApp sabem que o EOA pode executar várias operações complexas por meio do Invoker, o design da interação do dApp não mais tempo precisa 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: ou as operações de aprovação e dApp são executadas juntas com êxito 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 tempo 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 golpes).

Os usuários não mais tempo 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: Isso não significa que os golpes podem ser completamente bloqueados! 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 licenças que não sabem qual operação ou mesmo resultado de execução, os usuários têm mais informações para decidir se autorizam. Embora não seja uma cura perfeita, ainda assim será uma melhoria substancial para a situação atual.

Como o Carteira lida com nonces EOA

O design atual do PEI-3074 incluirá o valor EOA nonce no conteúdo da assinatura, de modo que, longo o EOA enviar uma transação para a cadeia para execução e alterar o valor nonce, todas as autorizações originais do PEI-3074 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 deverá ser impedido de ser alterado. 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 sozinho, não há necessidade de impedir especificamente que o nonce EOA seja alterado, porque a assinatura PEI-3074 ainda deve ser executada antes de um determinado prazo, como a transação. É que a carteira precisa gerenciar mais transações PEI-3074 do EOA: se houver assinaturas PEI-3074 esperando para serem carregadas na cadeia, as transações do próprio EOA terão que esperar.

Nota: O próprio contrato do Invoker manterá (e deve) manter um conjunto de nonce mecanismos, portanto, depois que a assinatura for usada, ela ainda precisará ser assinada 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 PEI-3074 altere as regras para remover os nonce EOA do conteúdo da assinatura antes que eles possam ser adotados em larga escala. Portanto, a carteira só precisa se concentrar no caso de uso de "operações autorizadas pelo usuário" e tratar a assinatura PEI-3074 como uma transação. Não há necessidade de se preocupar em evitar transações de envio de 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 PEI-3074 para a cadeia, haverá duas desvantagens:

1. O usuário precisa assinar duas vezes: uma para a assinatura PEI-3074 e outra para a assinatura na rede transação.
2. Como a transação na rede adicionará 1 ao nonce EOA antes que a transação comece a ser executada, o nonce EOA na assinatura PEI-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 PEI-3074 falhará devido à incompatibilidade nonce EOA.

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

Resumo e destaques

• O PEI-3074 permite que o EOA obtenha os mesmos recursos avançados de execução que os contratos, abrindo muitos novos cenários de aplicativos.
• Isso não apenas 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 PEI-3074 é uma assinatura simples, e os usuários não precisam necessariamente trazer a assinatura para a cadeia para execução, portanto, não há necessidade de se preocupar em reunir ETH para pagar taxas de transação.
• Os usos do PEI-3074 incluem Chamada em lote, Chave de sessão, Permissão de ETH nativa, Ordem de limite e Recuperação social. Muitas delas eram anteriormente impossíveis de serem alcançadas pelas EOAs, e algumas, como Ordem de limite, exigiam métodos de pré-autorização inseguros para serem usadas.
• PEI-3074 também alterará o método de autorização de token atual. O método de aprovação autoriza diretamente um endereço específico a ter o poder de retirar tokens indefinidamente, e exige que o EOA do usuário envie uma transação para executar a aprovação, para que a experiência do usuário e a segurança não sejam boas; O método Permit exige apenas que o usuário assine, e cada assinatura especificará o valor e o período de validade, o que melhora muito a experiência do usuário e a segurança em comparação com o Aprove.
• No entanto, o alvará ainda é muito usado em golpes. Ao assinar, os usuários só podem saber a 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 ela 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 PEI-3074, os usuários (1) não precisam aprovar uma grande quantidade de dinheiro para dApp antecipadamente, mas só precisam aprovar quando há uma operação, que tem o mesmo efeito que a permissão; (2) é apenas uma simples assinatura e não precisa se preocupar em reunir ETH para pagar a taxa de transação, que é a mesma do alvará; (3) cada aprovação é vinculada a uma operação específica e assinada em conjunto, para que os usuários possam saber claramente para que serve essa aprovação, que será mais segura do que a permissão!
• Espera-se que o PEI-3074 possa substituir com sucesso os modos de aprovação e permissão atuais e fornecer aos usuários um método de autorização mais seguro.

Isenção de responsabilidade:

1. Este artigo foi reimpresso 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 prontamente.
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.