Por que precisamos da abstração da conta?

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 o 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 Ether e Sol), o que é contraintuitivo.

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

No processo de exploração, Ethereum propôs soluções abstração de conta como ERC-4337, PEI-3074 e PEI-7702. Outros L1, como Solana têm recursos que permitem abstração de conta de nível protocolo, como PDAs (Program Derived Addresses), 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 os trade-offs 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 de conta definidos no whitepaper Ethereum. As contas EOA são controladas por chaves privadas, e os usuários podem assinar várias transações por meio 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 execute conta lógica específica chamando o código do contrato de conta.

Abstração

de conta O conceito de contas abstratas pode ser rastreado até 2016 (https://github.com/ethereum/EIPs/issues/86). O abstração de conta é baseado e construído sobre os 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 múltiplas 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 diário de saque;
5. Permite que várias operações de na rede sejam executadas em uma transação atômica. Por exemplo, um usuário pode concluir as operações de aprovação e troca em uma transação DEX com uma assinatura.

Ethereum Roadmap

O roteiro Ethereum (https://ethereum.org/en/roadmap/) destaca a rota de atualização futura 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 conta dentro do protocolo, através de propostas como PEI-3074 ou PEI-7702, e finalmente chegar ao Endgame abstração de conta.

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

PEI-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 o Uniswap a transferir seus USDC para o swap e, em seguida, enviar outra solicitação de transação para o 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 mescla as duas transações acima em uma única:

Como pode ser visto na figura acima, o usuário precisa assinar duas vezes para autorizar o empacotador 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 Ethereum para gás taxas, 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.

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

No ERC-4337, autorizamos o Bundler a lidar com ativos em nossa carteira de contrato inteligente na rede por meio de assinaturas. No PEI-3074, o empacotador está autorizado a lidar diretamente com 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.

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

Uma comparação entre PEI-3074 e ERC-4337

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

Portanto, pode-se ver pela nomenclatura dos dois esquemas de abstração de conta que o ERC-4337 é mais fácil de implementar do que o PEI-3074, porque o ERC-4337 não requer um garfo rígido 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ígono e base, mas o PEI-3074 acaba de ser aceito pelo 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 atuais para novas contas de contrato e precisa de DApp apoiar para que o PEI-1271 funcione. PEI-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 apoiar uma assinatura para autorizar várias operações de na rede sem introduzir um contrato intermediário de várias chamadas, mas o PEI-3074 pode, o que também causa as limitações do ERC-4337.

No entanto, PEI-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 fraudar 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 PEI-3074 seja implementado, isso se tornará um problema mais sério.

Nesse sentido, o lightclient, um dos autores do PEI-3074, propôs um método de mitigação para interceptar 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 maliciosos. 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 PEI-3704 do Pectra Devent 0 e incluir o PEI-7702 no próximo Pectra Devnet 1.

O que mudou no PEI-7702?

PEI-7702 tenta integrar os benefícios do PEI-3074 e do ERC-4337 para formar um caminho do meio. O usuário envia a operação assinada para o empacotador. Quando o empacotador 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 PEI-3074, o conta de contrato inteligente validará a operação autorizada do empacotador do usuário. Em seguida, assim como o AUTHCALL, realize 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 PEI-7702 são os seguintes:

1. Herda todas as vantagens do PEI-3074: não exige que os usuários mudem de contas EOA para contas de contrato inteligente com novos endereços; pode realizar várias operações em uma transação atômica;
2. O código de conta de contrato inteligente e a infraestrutura do ERC-4337 podem ser reutilizados;
3. O abstração de conta de contrato inteligente representado pelo ERC-4337 e a solução EOA abstração de conta representada pelo PEI-3074 podem ser mesclados para evitar que Ethereum se dividam em dois sistemas de abstração de conta diferentes e abrir caminho para a Conta de Abstração de Ultimato no roteiro Ethereum;
4. Os dois opcodes AUTH e AUTHCALL não serão adicionados ao EVM de Ethereum: levando em conta o roteiro Ethereum, as contas EOA serão convertidas em abstração de conta no futuro, e esses dois opcodes se tornarão redundantes.

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

A comunidade decidiu incluir o PEI-7702 na próxima atualização do Pectra em 2025. Se implementado, ele mudará muito o ecossistema Ethereum e trará melhorias incrementais para a atual versão ERC-4337 da infraestrutura abstração de conta.

Solana's Program Derived Endereço

Account Abstraction on Solana

Solana's abstração de conta é semelhante ao ERC-4337 de Ethereum. São contas derivadas de contas originais (semelhantes às contas EOA), semelhantes a 4337 contas de contrato. Antes de entender o abstração de conta de Solana, é necessário entender o modelo de conta utilizado 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 não podem fazê-lo. Examinando isso mais a fundo, há três tipos de contas no Solana: Programa Nativo, Conta do 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 conta do programa proprietário.

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 conta em Solana desde o aumento da segurança do usuário por meio de carteiras multisig e autenticação de dois fatores até a habilitação de 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 está 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ção que podem permitir que o proprietário do programa conta do PDA execute transações de forma autônoma em nome dos PDAs, totalmente reconhecidos e suportados pela rede Solana.

PDA e Abstração de Conta

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 conta. A abstração da conta acontece sob o capô através do desempenho de uma função conhecida como Cross Program Invocation (CIP).

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 CIP por meio de invoke_signed, os programas podem assinar em nome dos PDAs derivados.

Fonte: Solana

Para verificar a legitimidade de 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 conta em Solana baseada em PDA. No entanto, o produto fornecido pela Squads é atualmente mais parecido com a solução de conta de contrato inteligente da Gnosis Safe e ainda não desenvolveu totalmente sua abstração de conta funcionalidade.

Benefícios dos PDAs

1. Execução automatizada de contratos inteligentes: os PDAs permitem designs de contratos inteligentes mais complexos que podem executar várias operações de forma autônoma em nome do usuário por meio de chamadas 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 da 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 de PDAs

1. Os PDAs, embora benéficos para estabelecer as bases para abstração de conta recursos, podem ser complexos de implementar em comparação com um par de chaves conta.
2. E, como o ERC-4337, 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 conta.

Account Abstraction on Cosmos (Authz & Fee Grant)

Cosmos x/authz

Com o abstração de conta ocupando cada vez mais a mente dos desenvolvedores, o authz, parte do SDK principal do Cosmos, foi lançado para permitir que um conta realize certas ações em nome de outro conta por meio do uso de concessões de autorização que é semelhante com PEI-3074 e PEI-7702.

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

Com o 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 que o beneficiário execute a mensagem em nome do concedente.
2. EnviarAutorização. Essa autorização, assim como a aprovada no ERC20, busca dar ao donatário acesso a um limite de gasto positivo que define o valor máximo que pode ser gasto em nome do concedente.
3. Autorização de Participação. Essa concessão permite que os bolsistas gerenciem ações de estaca, 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. Ao final de cada bloco, a rede removerá concessões expiradas por meio de um processo chamado poda.

Entendendo a estrutura operacional

Authz pode ser usado para dar autorizações para uma variedade de ações, no entanto, para simplificar, examinaremos como o 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 donatá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 a chaves validadoras, as transações de 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 PEI-3074 e PEI-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 o abstração de conta.
4. DAO Eficiência Operacional e Flexibilidade: Um subconjunto de direitos de execução pode ser dado a membros individuais DAO para ações específicas.
5. Staking Composição de recompensas: A Authz facilita o uso de serviços de retomada e serviços equivalentes para a composição automatizada de recompensas de stake.

Limitações e riscos para a 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 usuário.

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

Fee Grant Module

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

No entanto, esse obstáculo foi superado com a integração do Módulo de Outorga de Honorários. Semelhante ao contrato paymaster que permite abstração de conta em Ethereum, o Fee Grant Module no Cosmos permite que o concedente conceda subsídios de taxa ao donatário, pagando algumas ou todas as taxas de transação. Os recursos permanecem sob o controle do concedente e ele pode revogar o subsídio a qualquer momento.

Tipos de Subvenções de Taxas

O Subsídio de Honorários 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 seja atingido. A concessã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á vencimento e teto de gastos no abono da taxa.

O PeriodicAllowance permite que as concessões de honorários sejam renovadas periodicamente 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 acompanha 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.

Entendendo a estrutura operacional

O uso de 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 se encontrado. Além do MsgGrantAllowance, um subsídio de taxa também pode ser revogado usando MsgRevokeAllowance.

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

Conclusão

Abstração da conta Em 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 à imparcialidade, precisão, pontualidade, integridade ou correção de quaisquer informações financeiras e de mercado gerais, análises e/ou opiniões fornecidas neste relatório, e nenhuma responsabilidade ou 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 revisado pela Comissão de Valores Mobiliários e Futuros de Hong Kong, pela Autoridade Monetária de Cingapura ou por qualquer autoridade regulatória em Hong Kong ou Cingapura.

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. Você deve considerar cuidadosamente 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 certas 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 para qualquer pessoa a quem seja ilegal distribuir tal relatório.

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

Website — https://hashkey.capital/

Twitter — https://twitter.com/HashKey_Capital

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

Isenção de responsabilidade:

1. Este artigo foi reproduzido de [Medium]. Todos os direitos autorais pertencem ao autor original [HashKey Capital]. 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.