Por que precisamos de Account Abstraction?

Ainda há muitos problemas não resolvidos no campo blockchain atual. Entre elas, a dificuldade de usar blockchain, ou seja, a experiência do usuário (UX) de interagir com a cadeia, deve ser a área mais criticada pelo público.

Por exemplo, muitas pessoas pensam que usar chaves é mais complicado do que usar e-mail para gerenciar contas, o gerenciamento de chaves é difícil e inseguro, e cada transferência (como USDC) requer o consumo de tokens nativos (como Éter e Sol), o que é contraintuitivo.

Neste contexto, cada vez mais pessoas estão voltando sua atenção para o campo da abstração de contas para melhorar a experiência do usuário de interações na cadeia e facilitar a adoção em massa.

No processo de exploração, Ethereum propostas abstração de contas soluções como ERC-4337, EIP-3074 e EIP-7702. Outros L1, como Solana têm recursos que permitem abstração de contas de nível protocolo, como PDAs (Endereços Derivados de Programas), e o Cosmos também tem designs semelhantes, como x/authz e Fee Abstraction Module. Neste artigo, apresentaremos e compararemos as soluções acima mencionadas, classificaremos as sutilezas do design de diferentes soluções e demonstraremos as compensações e considerações de diferentes soluções.

Background

EOA vs Conta de Contrato

Conta de propriedade externa (EOA) e Conta de contrato são dois tipos conta definidos no whitepaper Ethereum. As contas EOA são controladas por chaves privadas, e os usuários podem assinar várias transações através das chaves privadas para controlar os ativos no conta. O conta do contrato é controlado pelo código do próprio conta, e outras contas podem fazer com que o contrato conta execute uma lógica específica, chamando o código do contrato conta.

Account Abstraction

O conceito de contas abstratas remonta a 2016 (https://github.com/ethereum/EIPs/issues/86). O abstração de contas baseia-se e baseia-se nos dois tipos de conta atuais em Ethereum — EOA e contas de contrato. Isso melhorará a experiência interativa de Ethereum usuários através das seguintes maneiras:

1. Permite que os usuários usem várias assinaturas, como Schnorr, BLS, assinaturas pós-quânticas, etc.;
2. Permite que os usuários paguem taxas de gás usando tokens ERC20 ou lógica de pagamento personalizada;
3. Permite que os usuários recuperem suas contas usando e-mail, mídias sociais, etc.;
4. Permite que os usuários gerenciem os fundos em suas contas com permissões refinadas, como definir um limite de saque diário;
5. Permite que várias operações de na cadeia sejam executadas em uma transação atômica. Por exemplo, um usuário pode concluir as operações de aprovação e permuta em uma transação DEX com uma assinatura.

Ethereum Roadmap

O roteiro Ethereum (https://ethereum.org/en/roadmap/) destaca a futura rota de atualização do Ethereum. Atualmente, a maioria das pesquisas na comunidade Ethereum gira em torno do roteiro Ethereum. A abstração de contas é uma parte imperativa disso:

Fonte: https://x.com/VitalikButerin/status/1741190491578810445

A comunidade Ethereum espera desenvolver o ERC-4337 e implementar soluções abstração de contas dentro do protocolo, através de propostas como EIP-3074 ou EIP-7702, e finalmente chegar ao Endgame abstração de contas.

Apesar do aprimoramento da experiência do usuário, Endgame abstração de contas também é crucial para a computação antiquântica da Ethereum, porque o algoritmo ECDSA usado pelo atual EOA conta não é seguro na era da computação quântica. A adoção do abstração de contas suporta assinaturas pós-quânticas que protegem as contas dos usuários contra as ameaças em evolução da computação quântica.

EIP-3074 vs ERC-4337

Para entender conta contas abstratas, precisamos entender como funciona o EOA. A imagem abaixo é o processo de compra e venda de tokens mais comum na cadeia:

De um modo geral, os usuários precisam emitir duas transações ao comprar e vender: primeiro autorizar a Uniswap a transferir seus USDC para o swap e, em seguida, enviar outra solicitação de transação para a Uniswap executar a ação. O Uniswap transfere o USDC do conta do usuário e envia a quantidade correspondente de ETH para o usuário de acordo com o preço atual.

O ERC-4337 funde as duas operações acima referidas numa única:

Como pode ser visto na figura acima, o usuário precisa assinar duas vezes para autorizar o bundler a operar os ativos do usuário no conta 4337, que é diferente do conta EOA do usuário. Depois que o empacotador obtém autorização, ele mescla o conteúdo autorizado em um pacote e o emite para concluir a transação. Ao mesmo tempo, se o usuário não tiver tokens de Ethereum para taxas de gás, o papel de paymaster também pode ser introduzido, permitindo que o paymaster pague as taxas de gás e obtenha tokens ERC20 de igual valor do usuário.

EIP-3074 e ERC-4337 têm algumas semelhanças, mas o método de implementação do EIP-3074 está no protocolo de Ethereum:

No ERC-4337, autorizamos o Bundler a lidar com ativos em nossa carteira de contrato inteligente na cadeia por meio de assinaturas. Na EIP-3074, o bundler está autorizado a manusear diretamente os ativos em nossa carteira EOA por meio de assinaturas. Para ordem fazer isso, a comunidade Ethereum precisa adicionar dois novos opcodes ao Ethereum protocolo: AUTH e AUTHCALL.

AUTH é usado para verificar se o comportamento do bundler de processar ativos EOA conta do usuário é autorizado, e AUTHCALL é usado para "enganar" o contrato inteligente de interação do usuário (em nosso exemplo, USDC e Uniswap), fazendo o contrato inteligente pensar que a transação é do conta EOA do usuário. A vantagem disso é que os mantenedores do Uniswap e USDC não precisam atualizar o contratos inteligentes implantado e, ao mesmo tempo, as contas EOA podem desfrutar das funções de abstração de contas.

A Comparison Between EIP-3074 and ERC-4337

Na comunidade Ethereum, EIP geralmente refere-se a propostas que exigem atualizações de Ethereum para serem suportadas, enquanto ERC refere-se a especificações que podem ser suportadas sem Ethereum atualizações.

Portanto, pode-se ver pela nomenclatura dos dois esquemas abstração de contas que o ERC-4337 é mais fácil de implementar do que o EIP-3074, porque o ERC-4337 não requer uma forquilha rígida da rede Ethereum. Esta é também uma das razões pelas quais o ERC-4337 foi lançado e é cada vez mais usado em polígonos e bases, mas o EIP-3074 acaba de ser aceito pela 183ª Ethereum All Core Developers Execution Call (ACDE).

Fonte: https://dune.com/niftytable/account-abstraction

Além disso, o ERC-4337 exige que os usuários migrem suas contas correntes para novas contas de contrato e requer DApp suporte para que o EIP-1271 funcione. EIP-3074 não requer esses suportes adicionais. Esta é uma das principais razões para a baixa taxa de adoção do ERC-4337. Ao mesmo tempo, o ERC-4337 não pode suporte uma assinatura para autorizar operações de múltiplas na cadeia sem introduzir um contrato intermediário multichamada, mas o EIP-3074 pode, o que também causa as limitações do ERC-4337.

No entanto, EIP-3074 também tem seus próprios problemas. O mais importante é que o código de operação AUTH tem permissões muito altas, o que pode permitir que o invasor controle completamente o conta EOA do usuário. Afinal, longo como um hacker frauda sua assinatura AUTH, ele pode se desfazer dos ativos em sua carteira EOA. Considerando que os ataques de phishing são atualmente desenfreados, e a maioria deles engana as assinaturas dos usuários, uma vez que o EIP-3074 seja implementado, isso se tornará um problema mais sério.

A este respeito, lightclient, um dos autores do EIP-3074, propôs um método de mitigação para intercetar assinaturas maliciosas no nível da carteira. Para mais detalhes, consulte: https://x.com/lightclients/status/1778823652584120497. O ERC-4337 não tem esse problema, embora os hackers ainda possam enganar os usuários para que assinem UserOps mal-intencionados. Isso se deve à dificuldade de um UserOp obter autoridade de descarte sobre todos os ativos no conta do usuário. No momento em que este artigo foi escrito, os desenvolvedores do ACDE concordaram em remover o EIP-3704 do Pectra Devent 0 e incluir o EIP-7702 no próximo Pectra Devnet 1.

O que mudou no EIP-7702?

EIP-7702 tenta integrar os benefícios do EIP-3074 e do ERC-4337 para formar um caminho do meio. O usuário envia a operação assinada para o empacotador. Quando o bundler envia a transação para a cadeia, o conta EOA do usuário se tornará temporariamente um contrato inteligente conta como 4337 conta. Em seguida, semelhante ao progresso do AUTH no EIP-3074, o conta de contrato inteligente validará a operação do bundler autorizado do usuário. Em seguida, assim como AUTHCALL, execute operações autorizadas pelo usuário. Depois de executar a transação, o conta do usuário será revertido para um conta EOA comum.

Os benefícios do EIP-7702 são os seguintes:

1. Herda todas as vantagens do EIP-3074: não exige que os usuários mudem de contas EOA para contas de contrato inteligente com novos endereços;
2. O código de conta do contrato inteligente e a infraestrutura do ERC-4337 podem ser reutilizados;
3. O contrato inteligente abstração de contas representado pelo ERC-4337 e a solução EOA abstração de contas representada pelo EIP-3074 podem ser fundidos para evitar que Ethereum se dividam em dois sistemas de abstração de contas diferentes e abrir caminho para a Conta de Abstração de Endgame no roteiro Ethereum;
4. Os dois opcodes AUTH e AUTHCALL não serão adicionados ao EVM da Ethereum: tendo em conta o roteiro Ethereum, as contas EOA serão convertidas em abstração de contas no futuro, e estes dois opcodes tornar-se-ão redundantes.

Além disso, o EIP-7702 herda todos os riscos de segurança do EIP-3074.

A comunidade decidiu incluir o EIP-7702 na próxima atualização do Pectra em 2025. Se implementado, mudará consideravelmente o ecossistema Ethereum e trará melhorias incrementais à atual versão ERC-4337 da infraestrutura abstração de contas.

Solana's Program Derived Endereço

Account Abstraction on Solana

Solana's abstração de contas é semelhante ao ERC-4337 de Ethereum. São contas derivadas de contas originais (semelhantes às contas EOA), semelhantes a 4337 contas contratuais. Antes de entender a abstração de contas de Solana, é necessário entender o modelo de conta usado por Solana.

Em termos gerais, as contas podem ser classificadas como contas executáveis que podem executar código ou contas não executáveis que são incapazes de fazê-lo. Examinando isso mais a fundo, há três tipos de contas no Solana: Programa Nativo, Conta de Programa e Conta de Dados.

Os programas nativos fazem parte da implementação do validador e fornecem funções essenciais para a rede Solana, como a criação de novas contas de dados e programas personalizados. Contas de programa são programas personalizados que contêm código executável. As contas de dados podem armazenar dados e gerenciar o estado do programa, conforme definido pelo programa proprietário conta.

Esse modelo conta permite nativamente que contas de programa criem e gerenciem contas específicas, oferecendo aos desenvolvedores a capacidade de definir regras personalizadas e lógica para gerenciá-las. Habilitado por esse modelo de conta, o Program Derived Endereço (PDA), um tipo de conta de dados, amplia as possibilidades de recursos de abstração de contas em Solana desde melhorar a segurança do usuário por meio de carteiras multisig e autenticação de dois fatores até habilitar mecanismos de recuperação social, entre outros.

Programa derivado Endereço Para

contextualizar, todas as contas estão na curva Ed25519 e têm um par de chaves público-privado. PDA, que fica fora da curva Ed25519, é uma cadeia de caracteres de 32 bytes derivada deterministicamente que se parece com uma chave pública e não vem com uma chave privada correspondente. Os PDAs permitem que os desenvolvedores criem regras personalizadas e mecanismos de assinatura de transações que podem permitir que o proprietário do programa conta do PDA realize transações de forma autônoma em nome dos PDAs, totalmente reconhecidos e suportados pela rede Solana.

PDA e Account Abstraction

Ok, agora que entendemos como os PDAs são derivados, você pode estar se perguntando como esses conceitos estão ligados a abstração de contas. A abstração de conta acontece sob o capô através do desempenho de uma função conhecida como Invocação de Programa Cruzado (CPI).

CPIs são funções que permitem que um programa invoque as instruções de outro programa, permitindo a composição de Solana programas. Quando um programa inicia um CPI através de invoke_signed, os programas são capazes de assinar em nome dos PDAs derivados.

Fonte: Solana

Para verificar a legitimidade das transações envolvendo PDAs, Solana tempo de execução chama internamente o create_program_address usando o signers_seeds e o program_id do programa de chamada. Se um PDA válido for encontrado, o tempo de execução associará o PDA ao programa de chamada e reconhecerá o programa como um signatário autorizado.

Atualmente, a Squads está desenvolvendo uma solução abstração de contas em Solana baseada em PDA. No entanto, o produto fornecido pela Squads é atualmente mais parecido com a solução de contrato inteligente conta da Gnosis Safe e ainda não desenvolveu totalmente sua funcionalidade abstração de contas.

Benefícios dos PDAs

1. Execução automatizada de contratos inteligentes: os PDAs permitem projetos de contratos inteligentes mais complexos que podem executar várias operações de forma autônoma em nome do usuário por meio de invocações entre programas.
2. Experiência de usuário aprimorada: os usuários não precisam gerenciar várias transações ou ser expostos à complexidade técnica.
3. Segurança e flexibilidade aprimoradas: Sem uma chave privada, isso reduz o risco de comprometimento de uma chave. Os PDAs podem ser usados para carteiras multisig ou acomodar outros modelos de governança flexíveis que reduzem um único ponto de risco e são especialmente úteis para organizações que gerenciam grandes recursos compartilhados.

Limitações dos PDAs

1. Os PDAs, embora sejam benéficos para estabelecer a base para abstração de contas capacidades, podem ser complexos de implementar em comparação com um par de chaves conta.
2. E, como o ERC-4337, ele exige que os usuários realizem conta migração para um novo conta o que pode suprimir a taxa de adoção de Solana abstração de contas.

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

Com abstração de contas cada vez mais ocupando a mente dos desenvolvedores, authz, parte do núcleo do Cosmos SDK, foi lançado para permitir que um conta execute certas ações em nome de outro conta através do uso de concessões de autorização, que é semelhante com EIP-3074 e EIP-7702.

O Authz vem com vários tipos de autorização predefinidos que delegam o desempenho de determinadas ações, como staking a um beneficiário, melhorando a experiência do usuário como resultado.

Com authz, 3 tipos de autorizações podem ser dadas:

1. Autorização Genérica. Esta concessão de autorização dá permissão irrestrita para o beneficiário executar a mensagem em nome do concedente.
2. SendAuthorization. Esta autorização, tal como a aprovada no ERC20, procura dar ao beneficiário acesso a um limite positivo de gastos que define esse montante máximo que pode ser gasto em nome do concedente.
3. StakeAuthorization. Esta subvenção permite que os beneficiários gerenciem ações de staking como delegar, desdelegar ou redelegar em nome do concedente.

Uma concessão consiste nos bytes de endereço do concedente, bytes de endereço dos beneficiários e os tipos de autorização. O período de tempo também pode ser definido para limitar as permissões dentro de um período de tempo específico. No final de cada bloco, a rede removerá as concessões expiradas através de um processo chamado poda.

Compreender o Quadro Operacional

Authz pode ser usado para dar autorizações para uma variedade de ações, no entanto, para simplificar, vamos examinar como authz funciona para permitir transações de voto genérico.

1. Implementa a interface de autorização antes que qualquer autorização possa ser executada. Nesta fase, também será definido o tipo de mensagem que, neste caso, será MsgVote. Aqui, vemos uma autorização de concessão de Alice para uma ação de voto de governança.
2. Bob gera uma transação de voto não assinada.
3. Bob gera uma transação assinada e executada do voto do beneficiário. A transação é concluída e a autorização será removida se expirar.

Benefícios que o authz traz?

1. Segurança operacional: validadores e outros usuários podem conceder permissões a um conta separado para votar em propostas de governança ou executar determinadas ações, aumentando a segurança conta e reduzindo a carga de segurança.
2. Operações simplificadas: As transações podem ser realizadas com a necessidade de acesso às chaves do validador, as transações da carteira multisig também podem ser simplificadas usando uma única transação para conceder Authz ao beneficiário conta.
3. Sem necessidade de migração: semelhante ao EIP-3074 e EIP-7702, as operações de autorização ocorrem no conta original do usuário. Os usuários não precisam transferir seus ativos do conta original para um novo conta para habilitar abstração de contas.
4. DAO Eficiência Operacional e Flexibilidade: Um subconjunto de direitos de execução pode ser concedido a membros individuais DAO para ações específicas.
5. Estaca Reward Compounding: Authz facilita o uso de retaking e serviços equivalentes para a composição automatizada de recompensas de stake.

Limitações e riscos para Authz:

Preste atenção aos tipos de transações que você está autorizando via Authz. Uma Autorização maliciosa pode executar vários tipos de autorizações que podem ser prejudiciais para o utilizador.

1. GenericAuthorization: dá permissão irrestrita para executar a Msg fornecida em nome do concedente. A menos que esteja totalmente ciente do que você está assinando, é altamente recomendável evitar assinar tais tipos de autorização. Algumas carteiras também podem não fornecer avisos ao assinar transações Authz.
2. SendAuthorization: Permite que o beneficiário envie a quantidade máxima de tokens que o beneficiário pode gastar se não for especificado pelo concedente. Também é importante verificar a AllowList, que especifica o endereço específico para o qual o beneficiário pode enviar os tokens.

Módulo de concessão de taxa

Outro obstáculo à experiência do usuário que frustrou muitos é a necessidade de os usuários de blockchains manterem vários tokens nativos ordem interagir com esses diferentes ecossistemas. Isso contaminou a experiência geral do usuário, especialmente para pessoas nativas não cripto que foram expostas pela primeira vez a uma miríade de cadeias existentes no ecossistema Cosmos.

No entanto, este obstáculo foi ultrapassado com a integração do Módulo de Concessão de Taxas. Semelhante ao contrato paymaster que permite abstração de contas em Ethereum, o Módulo de Concessão de Taxas no Cosmos permite que o concedente conceda subsídios de taxa ao beneficiário, pagando algumas ou todas as taxas de transação. Os fundos permanecem sob o controlo do concedente e este pode revogar o subsídio de subvenção a qualquer momento.

Tipos de subvenções de propinas

O Subsídio de Taxa pode ser categorizado em dois tipos: BasicAllowance e PeriodicAllowance.

O BasicAllowance permite que o beneficiário use as taxas do concedente conta até que o limite de gastos ou o tempo de expiração sejam atingidos. A subvenção será então extinta do Estado. É importante notar que o BasicAllowance implementa uma concessão única de taxas. Se o limite de gastos e o tempo estiverem vazios, não há expiração e limites de gastos no subsídio de taxa.

O PeriodicAllowance permite que as subvenções de honorários sejam periodicamente renovadas após cada período de tempo especificado. Period_spend_limit especifica o número máximo de moedas que podem ser gastas no período. Period_reset mantém o controle de quando o próximo período deve acontecer e period_can_spend rastreia a quantidade de moedas restantes antes de um novo período começar.

Compreender o Quadro Operacional

Usar AllowedMsgAllowance cria uma permissão para tipos de mensagem especificados. O subsídio pode ser BasicAllowance ou PeriodicAllowance. Se o tempo de expiração for definido, FeeAllowance será enfileirado no estado com o prefixo de expiração anexado à concessão e Endblocker verificará o estado FeeAllowanceQueue para concessões expiradas, removendo qualquer um se encontrado. Além de MsgGrantAllowance, uma franquia de taxa também pode ser revogada usando MsgRevokeAllowance.

Em conjunto, os módulos Authz e Fee Grant desbloqueiam casos de uso inovadores e diversificados que, em última análise, constroem uma melhor experiência do usuário no ecossistema Cosmos.

Conclusão

Resumo da conta A partir de 27 de maio de 2024, os números são estimados.

Com a aprovação de ETFs de BTC à vista e ETFs de ETH, a demanda institucional e de varejo aumentou significativamente, prometendo inaugurar uma nova onda de usuários que buscam ganhar exposição ao setor. A abstração de contas se tornará uma narrativa importante este ano, à medida que protocolos e dapps buscam criar uma experiência perfeita para expandir suas comunidades.

AVISO LEGAL

Este material é apenas para informação geral e não constitui, nem deve ser interpretado como, qualquer forma de resultado de pesquisa, aconselhamento profissional, solicitação, oferta, recomendação ou estratégia de negociação. Nenhuma garantia, representação, garantia ou compromisso, expresso ou implícito, é feito quanto à justiça, precisão, pontualidade, integridade ou exatidão de quaisquer informações financeiras e de mercado gerais, análises e/ou opiniões fornecidas neste relatório, e nenhuma responsabilidade é aceita pela HashKey Capital em relação ao uso ou confiança em tais informações. Qualquer informação sobre este relatório está sujeita a alterações sem aviso prévio. Este relatório não foi revisto pela Comissão de Valores Mobiliários e Futuros de Hong Kong, pela Autoridade Monetária de Singapura ou por qualquer autoridade reguladora em Hong Kong ou Singapura.

Por favor, esteja ciente de que os ativos digitais, incluindo criptomoedas, são altamente voláteis e sujeitos a riscos de mercado. O valor dos ativos digitais pode flutuar significativamente, e não há garantia de lucro ou preservação de capital. Deve considerar cuidadosamente a sua própria tolerância ao risco e situação financeira antes de tomar qualquer decisão.

A distribuição deste relatório pode ser restrita em determinadas jurisdições. Este material não constitui a distribuição de qualquer informação ou a realização de qualquer oferta ou solicitação por qualquer jurisdição em que tal ação não seja autorizada ou a qualquer pessoa a quem seja ilegal distribuir tal relatório.

Mantenha-se atualizado com as últimas notícias da HashKey Capital -

Sítio Web — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

LinkedIn — https://www.linkedin.com/company/hashkeycapital/

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

1. Este artigo foi reproduzido a partir de [Medium]. Todos os direitos autorais pertencem ao autor original [HashKey Capital]. Se houver objeções a esta 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.