O que é Abstração de Conta (AA)

Diferenças entre AA, EOA e CA

A essência da abstração da conta é uma Conta de Contrato. No Ethereum, existem dois tipos de contas:

• Endereço do Contrato
• Contas de Propriedade Externa

Um exemplo simples é que o Endereço do Contrato é o endereço onde o contrato é implantado. Qualquer contrato no Ethereum que pode ser chamado tem um endereço de contrato, como o endereço do contrato do USDT. Uma conta EOA é a conhecida conta ETH, como a conta mostrada na carteira Metamask.

0xdac17f958d2ee523a2206206994597c13d831ec7é o endereço do contrato para tokens USDT. Os endereços de contrato não podem ser criados diretamente de fora; são criados e geridos por EOAs. O EOA que criou o endereço do contrato USDT é 0x36928500Bc1dCd7af6a2B4008875CC336b927D57.

Assim, compreendemos que uma conta AA é um tipo especial de Conta de Contrato (CA) no Ethereum. As contas AA ainda precisam ser criadas por EOAs e são controladas por EOAs externos porque a única forma de interagir com a cadeia Ethereum é através de EOAs. Portanto, a AA serve como uma implementação padronizada e modular de carteiras de CA, que continua a evoluir ao longo do tempo.

Histórico de Desenvolvimento das Contas AA

Acabamos de explicar a relação entre AA e CA. Antes da proposta do padrão ERC-4337, já havia um número significativo de carteiras CA disponíveis. Abaixo, fornecemos informações sobre três carteiras CA populares e como elas operam:

Carteira de Paridade

Durante as fases iniciais do desenvolvimento do Ethereum, surgiram várias carteiras de contratos. A mais conhecida é a carteira Parity, desenvolvida pela equipe de Gavin Wood, os fundadores da PolkaDot. A Parity é implementada em Rust e serve como uma alternativa ao nó Geth, que é desenvolvido em Golang. A Parity Wallet é uma carteira de contrato multiassinatura que permite que várias contas de propriedade externa (EOAs) controlem e gerenciem uma conta de contrato (CA). No entanto, em 2017, um hacker explorou uma falha na carteira Parity e roubou mais de 150.000 ETH. Esse incidente causou uma perda de confiança nas carteiras de contratos.

Como resultado, as carteiras AA requerem prática extensiva e padronização para evitar que incidentes semelhantes ocorram.

Carteira Gnosis

A carteira multi-assinatura Gnosis é atualmente a carteira Multi-sig mais popular e é utilizada pela maioria das instituições e desenvolvedores. Um número significativo de equipes armazena seus fundos de desenvolvimento na carteira multi-assinatura da Gnosis para impedir que os membros da equipe ajam de forma maliciosa. Equipes notáveis que usam o Gnosis Safe incluemYearn,Aave, eBalancer. A segurança do Gnosis Safe é extremamente elevada, mas o seu uso é relativamente caro, o que é um problema comum com as carteiras CA.

UniPass

A carteira Unipass combina a tecnologia MPC e carteiras de contratos CA, permitindo aos utilizadores usar o login social sem a custódia própria de uma carteira EOA. Deve ser notado que tanto a carteira Parity como a Gnosis Safe ainda requerem que os utilizadores guardem as suas chaves privadas. O fluxo geral do Unipass é:

• Login social ao criar uma carteira CA on-chain
• Interação com a cadeia
  Utilizadores iniciam transações
  MPC verifica a validade das transações do utilizador
  Uma carteira EOA controlada por MPC inicia transações na conta CA do usuário
  A conta CA executa a transação e paga gás ao paymaster da UniPass

É importante notar que a solução AA original da Unipass não adere totalmente ao padrão ERC-4337. O controle da carteira ainda é delegado a um EOA controlado pelo MPC da Unipass.

Implementação de AA ( ERC-4337)

A essência do AA é uma conta CA padronizada e modularizada. ERC-4337 manifesta principalmente as seguintes inovações:

• bundler : As contas tradicionais de CA ainda exigem que os utilizadores iniciem transações através de uma conta EOA externa, obrigando os utilizadores a armazenar ETH nas suas contas EOA para taxas de gás. No ERC-4337, os utilizadores empacotam as suas transações como UserOperations e enviam-nas para o bundler, que inicia a transação, eliminando assim a necessidade de os utilizadores reservarem gás antecipadamente.
• Assinaturas Agregadas BLS: O agrupador empacota múltiplas UserOperations numa única transação e gera uma assinatura agregada BLS, que é então validada na cadeia por meio de uma única verificação de assinatura BLS.
• pagador : Os utilizadores podem designar um pagador para pagar o gás.

O diagrama acima descreve aproximadamente o processo de transação padrão sob o ERC-4337:

• Pacotes de utilizador UserOp e envia-los para o aglutinador
• O Bundler verifica a validade do UserOp e empacota-o numa transação
• O Bundler envia a transação para a mainnet ETH
  Ponto de Entrada: Ponto de entrada do contrato para a transação submetida pelo agrupador
  handleOps : Contrato especificamente utilizado para executar transações de utilizadores
  pagador : Contrato utilizado para pagar o gás do utilizador

Podemos resumir as principais diferenças entre AA e CA tradicional da seguinte forma:

• Os utilizadores não submetem transações diretamente, mas deixam a embalagem para o agrupador
• A verificação da assinatura passa da camada de consenso para a camada de contrato, onde o contrato valida a assinatura
• Introdução de um paymaster modularizado, permitindo aos utilizadores escolher livremente quem paga pelo gás

Como AA Difere De MPC

Antes de compreender completamente AA, muitas pessoas frequentemente confundem os conceitos de AA e MPC porque ambos suportam funcionalidades como recuperação social e plugins sem navegador. As diferenças essenciais entre AA e MPC são as seguintes:

• AA ainda é descentralizado e existe na cadeia, enquanto MPC é centralizado e frequentemente hospedado por uma ou mais instituições.
• As transações AA são executadas pelo endereço do contrato AA, enquanto o MPC é realizado pelo EOA hospedado pela instituição, tornando o MPC ainda uma conta EOA gerenciada.
• Uma execução de transação AA envolve interações com vários contratos relacionados com AA na cadeia, enquanto o MPC interage diretamente com a EOA. O MPC não incorre em taxas de gás adicionais.

A seguir, vamos apresentar o MPC e suas características únicas.

• A tecnologia MPC é mais madura e as carteiras quentes das exchanges centralizadas implementaram MPC para prevenir falhas de ponto único, melhorando significativamente a segurança das exchanges centralizadas.
• MPC é composto por vários nós, sendo que cada nó possui apenas uma parte da chave privada. As transações só podem ser assinadas quando vários nós de MPC alcançam consenso. Como resultado, o roubo da chave privada de um único nó não leva à perda de fundos.
• Atualmente, existem muitas soluções de MPC de código aberto. Para princípios específicos, pode consultarhttps://tor.us/, uma solução de nó MPC de código aberto desenvolvida pela Web3Auth.

As soluções de MPC são amplamente utilizadas nos logins sociais atuais, e muitos projetos lançaram carteiras de MPC para proporcionar uma experiência de carteira sem corrente, eliminando a necessidade de os utilizadores instalarem carteiras de plug-ins ou gerirem chaves privadas. Na indústria, estes tipos de carteiras geridas são referidas coletivamente como Wallet-as-a-Service (WaaS). Os projetos maduros incluem:

• Autenticação Web3
• Rede de Partículas
• Magic Link
• Coinbase Base

Perante um número crescente de serviços WaaS, é previsível que no futuro haja mais produtos a oferecer WaaS. No entanto, as exchanges centralizadas têm um volume absoluto de utilizadores e uma vasta experiência comercial neste campo, pelo que é possível que todas as exchanges centralizadas venham a disponibilizar serviços relacionados no futuro.

Vantagens da AA

Recuperação Social

A principal desvantagem das Contas Externamente Proprietárias (EOA) tradicionais é que os utilizadores são responsáveis por armazenar as suas próprias chaves privadas. Esta auto-guarda apresenta os seguintes problemas:

• Alto custo cognitivo. A maioria dos utilizadores não consegue entender as chaves públicas e privadas.
• Se os utilizadores perderem a sua chave privada, não há forma de recuperar a conta.

AA (Account Abstraction) foi projetado para permitir que os usuários configurem contas de recuperação social. Eles podem usar uma ou mais EOAs externas para retomar o controle sobre seu AA. O fluxo comum para recuperação social é o seguinte:

• O utilizador perde o acesso ao EOA atual que controla o AA, ou este é comprometido.
• Dois EOAs adicionais estão vinculados à AA do usuário: \
  EOA do amigo \
  EOA Institucionalmente Custodiada
• Estas duas EOAs iniciam um recurso e, após completarem uma prova multisig 2/3, mudam o EOA vinculado do AA para o novo EOA do utilizador.

Através deste processo de apelo, mesmo que o utilizador perca o controlo do EOA que governa o AA, ainda pode mudar para um novo EOA. Ao contrário do login social MPC (Computação Multi-Partes), esta recuperação social é totalmente descentralizada e não tem um único ponto de falha.

Delegação de Gás

A delegação de gás é fundamental para a adoção em massa da blockchain. Para novos utilizadores que entram na Web3, o maior ponto de dor é pré-financiar as taxas de gás. Ao utilizar o Paymaster da AA para delegar gás, os novos utilizadores podem ser subsidiados, reduzindo assim a barreira de entrada para as aplicações Web3.

Sem atrito entre cadeias

Outra questão central que afeta a adoção em massa do Web3 é a compatibilidade entre blockchains. O Paymaster, através da integração de protocolos entre blockchains como Layer0/Warmhole, permite aos utilizadores depositar na Chain A (por exemplo, Ethereum) e usar aplicativos de forma transparente noutra Chain B (por exemplo, Matic ou BSC), fazendo com que as fronteiras entre as blockchains desapareçam e ajudando novos Dapps a ganhar utilizadores de outras blockchains.

Desvantagens do AA atual

Embora tenhamos discutido as vantagens do AA, o padrão ERC-4337 ainda está a iterar rapidamente para resolver as suas desvantagens atuais:

Criação separada para cada cadeia/camada 2

Ao contrário do EOA, uma vez que um EOA é criado, pode ser usado em qualquer cadeia compatível com EVM, uma vez que o mesmo par de chaves público-privado pode ser usado para interagir em diferentes cadeias. No entanto, devido à natureza do AA como uma Conta de Contrato (CA), um novo contrato de AA precisa ser implantado separadamente em cada cadeia ou Camada2. O alto custo de implantação de contratos de AA pode desencorajar os usuários de adotar AAs.

Além disso, se os utilizadores fizerem implantações de forma inadequada, como usar Fábricas diferentes para implantar contas de contratos AA, podem acabar com endereços AA diferentes em diferentes cadeias, o que pode causar confusão significativa e dificuldade na utilização e compreensão. Embora as Fábricas de Carteiras AA atuais tenham conseguido gerar o mesmo endereço AA em diferentes cadeias, os utilizadores ainda precisam ter cuidado ao verificar os protocolos que estão a usar para garantir que os seus endereços AA permaneçam consistentes em várias cadeias, evitando assim quaisquer problemas ou confusões futuras.

Altos Custos de Implementação

Como mencionado, as contas AA exigem que os usuários implementem os contratos AA gerados pela Wallet Factory em diferentes cadeias e Layer2 separadamente. Mesmo com as sidechains atuais, cadeias compatíveis com EVM e taxas de gás mais baixas da Layer2, ainda é um gasto significativo. Com as taxas de gás atuais e o preço do ETH a $1800, implementar uma conta AA na mainnet do ETH custaria aproximadamente $20-$40, enquanto em cadeias compatíveis com EVM ou Layer2, variaria de $0.5 a $5. Para a maioria dos usuários, é difícil aceitar o custo de implementação antes mesmo de usar o Dapp. Supondo que esse custo seja subsidiado por um Agregador ou Pagador, o custo do subsídio ainda é muito alto e requer um forte incentivo.

Custo de gás significativamente mais alto do que EOAs

Dependendo da implementação de AA e do número de transações agrupadas numa única transação Bundler (quanto mais transações, menor o custo de gás por UserOP), o consumo de gás das transações padrão ERC-4337 atuais pode ser várias vezes mais alto do que o das contas regulares EOA. Isto deve-se ao facto de uma transação iniciada por uma conta AA frequentemente exigir a chamada de 3 ou mais contratos e envolver cálculos complexos como a verificação de assinatura BLS on-chain. O padrão ERC-4337 atual também está a ser otimizado para este fim, com o seguinte roteiro:

• Simplificando o número de contratos chamados em transações de conta AA
• Introdução de contratos pré-compilados de curva elíptica no ETH para reduzir o consumo de gás para verificação de assinatura on-chain

Estimativa de Taxa de Gás sob o Padrão ERC-4337

Acabamos de mencionar o custo relativamente elevado de usar o padrão ERC-4337. Quais são os custos específicos? Primeiro, vamos apresentar um conceito, que é a fórmula de cálculo das taxas de gás:

taxa = gás × preço

Então, quais são os custos de implementação e utilização do ERC-4337? A equipe da StackUp forneceu estimativas precisas no seu blog.

https://www.stackup.sh/blog/how-much-more-expensive-is-erc-4337

Tabela 1. Gás para transações ERC-4337

A tabela acima mostra:

• O custo de criar uma conta AA é aproximadamente 20 vezes o custo de uma transação EOA.
• As transferências de tokens nativos em contas AA custam cerca de 4 vezes mais do que em contas EOA.
• Para transferências ERC20, os AAs custam apenas 1,5 vezes mais do que os EOAs.

Tabela 2. Estimativas de taxas de gás para transações ERC-4337

Esta tabela fornece estimativas de custos para várias operações na conta AA ERC-4337 usando os preços atuais do gás. Podemos observar o seguinte:

• Na mainnet ETH, o custo de criar uma conta de AA é muito alto, aproximadamente $20-30.
• Sob Rollup, devido à tecnologia de compressão de dados, o custo de criar uma conta AA é menor, similar ao custo das transferências.
• Em outras cadeias compatíveis com a EVM, o custo de criar uma conta AA é relativamente menor devido à menor taxa base de gás.

Em resumo, devido ao alto custo de criação de contas AA ERC-4337 na mainnet, é provável que a adoção generalizada ocorra primeiro nas cadeias Layer2 e EVM-compatíveis.

Compatibilidade Dapp e Compatibilidade do Navegador Blockchain

Outro obstáculo ao desenvolvimento de AA é a compatibilidade da infraestrutura com contratos AA. A maioria dos Dapps fora da cadeia AA nativa só suporta contas EOA. O suporte para AA requer que os Dapps usem o SDK da AA para transações e modifiquem os parâmetros de consulta para informações do usuário.

Além disso, os navegadores de blockchain, como o Etherscan, são principalmente projetados para EOAs. Para melhorar a conveniência de consultar contas AA, esses navegadores podem exigir uma série de otimizações de UI e UX.

Abstração de Conta Nativa (AA Nativo)

Prós e contras do AA nativo

Exceto o Ethereum, a maioria das novas blockchains públicas já implementou contas AA nativas.

• Prós
  Suporte da camada de consenso

Os AA nativos são implementados na camada de consenso da cadeia, o que significa que não requerem desenvolvedores da comunidade para implementação. Estes são geralmente contratos internos ou contratos do sistema desenvolvidos e mantidos pelos desenvolvedores da blockchain.

Custos de implementação mais baixos e taxas adicionais de gás

Os contratos internos frequentemente têm permissões e prioridades mais elevadas, e os cálculos de gás deles são diferentes dos contratos externos. Portanto, os AAs nativos têm custos de implementação mais baixos e geralmente não adicionam sobrecarga significativa de gás.

• Desvantagens
  Menor flexibilidade

A atualização dos AAs nativos requer que os desenvolvedores da cadeia pública sejam responsáveis, sendo frequentemente necessárias bifurcações suaves ou duras. Isso os torna menos flexíveis do que o ERC-4337 modular, limitando o ritmo de iteração e lançamento de novos recursos.

• Aprenda com a experiência do ERC-4337 e aumente a escalabilidade

As cadeias com AAs nativos estão a estudar ativamente a extensibilidade e modularidade do ERC-4337, permitindo que mais funcionalidades sejam construídas em cima dos AAs nativos.

Perto

O Near implementa AAs nativos na camada de consenso com contas armazenadas diretamente no blockchain. Suporta múltiplas chaves de acesso e recuperação social (email, número de telefone). A seguinte imagem ilustra as diferenças entre uma conta ETH e uma conta Near.

Aptos / Sui

Devido ao modelo de Propriedade de Recursos em Aptos e Sui, tanto Aptos quanto Sui implementaram AA nativo na camada de consenso. Tomando Aptos como exemplo, uma conta de Aptos é um conjunto de recursos na blockchain, então ao criar uma conta de Aptos, é necessário pré-pagar Aptos para concluir a inicialização da conta. As contas de Aptos/Sui também suportam a alteração da chave de autenticação, mas o endereço da conta permanece o mesmo, entre outras funcionalidades de AA.

ZKsync

Ao contrário do Near/Aptos/Sui/Starknet, o ZKsync suporta tanto EOA como AA na camada de consenso. Portanto, o ZKsync pode iniciar transações usando tanto EOA como AA, permitindo que seja usado com carteiras populares como Metamask e Argent. O design de AA do ZKSync é baseado no ERC-4337, tornando-o compatível com carteiras e Dapps que suportam o EIP-4337. Atualmente, o custo adicional de gás para transações de AA no ZKsync é aproximadamente execution_gas + 20000, o que equivale a cerca de 0.01USD no momento da redação. Este é um custo baixo em comparação com o ERC-4337 de AA não nativo.

Starknet

Starknet suporta nativamente AA e não suporta transações iniciadas por EOA. As contas AA no Starknet são projetadas com base no ERC-4337. Atualmente, os contratos AA no Starknet são fornecidos pela OpenZeppelin e desenvolvidos usando Cairo.

ICP

As contas AA nativas em ICP são chamadas de Identidade na Internet (II para abreviar). A implementação de II é diferente do ERC-4337. II utiliza o WebAuthn, comumente usado em estruturas Web2, permitindo aos usuários controlar suas contas usando os chips de segurança integrados em seus smartphones. Os usuários podem adicionar e remover dispositivos livremente. Em essência, II transforma os dispositivos de smartphone do usuário em carteiras de hardware.

Infraestrutura AA existente

Agrupador

O Bundler substitui o Mempool node anterior no ecossistema AA. Os UserOps já não são enviados para os Validadores, mas sim para os Bundlers para serem embalados e processados na cadeia. Os bundlers principais são os seguintes:

• Agrupador de Stackup:

O empacotador da Stackup é implementado em Go lang e tem como objetivo integrar-se perfeitamente com o Go Ethereum (geth). É o primeiro empacotador de padrão de produção nesta lista que está em plena conformidade com ERC-4337. A Stackup é ativamente mantida e tem documentação abrangente, tornando-a o empacotador mais popular no momento. A Stackup fornece serviços de empacotamento, eliminando a necessidade de equipes configurarem seu próprio serviço de empacotamento.

• Infinitism Bundler

O bundler da Infinitism é desenvolvido em TypeScript e foi desenvolvido pelo autor original do ERC-4337. A Infinitism também desenvolve contratos ERC-4337, tornando seu bundler altamente compatível com o ERC-4337. No entanto, é necessária uma verificação adicional para desempenho e estabilidade, uma vez que é desenvolvido em TypeScript.

• Sílio(AA-bundler) está a ser desenvolvido por Vid Kersic, um membro essencial do protocolo Ethereum, utilizando Rust. Isto contribuirá para a integração de ferramentas AA no ecossistema Rust.
• Skandha

Skandha é um agrupador baseado em TypeScript desenvolvido pela Etherspot. Etherspot está ativo na implementação da mempool do agrupador. Skandha passou em todos os testes em abril de 2023.

• Voltaire

Voltaire é um protocolo de agrupamento desenvolvido pela equipa Candide para suportar a sua própria carteira Candide. Voltaire é uma implementação baseada em Python do ERC-4337. Atualmente, o Voltaire fornece um bom suporte para a própria carteira de código aberto da Candide.

• Rundler

Rundler é um protocolo Bundler desenvolvido pela Alchemy, o maior fornecedor de serviços de nó para Ethereum. Atualmente, o Rundler não é de código aberto, mas devido à grande base de usuários da Alchemy, pode receber suporte significativo de tráfego.

Pontos de Dor do Agrupador

O Bundler encontra-se atualmente numa fase de desenvolvimento e iteração rápidos.

• Comunicação entre bundlers

O ponto de dor atual que o agrupador precisa abordar são as questões de consistência e comunicação do mempool do agrupador. Supondo que existam múltiplos protocolos de agrupamento no mercado e haja falta de comunicação entre eles, isso pode levar a um problema grave de ataques DDoS ao agrupador. Se um usuário enviar transações simultaneamente para vários agrupadores sem comunicação entre eles, esses agrupadores irão empacotar e enviar UserOps simultaneamente ao validador. No entanto, apenas o UserOp do primeiro agrupador será executado e as transações dos agrupadores restantes serão rejeitadas devido ao mesmo nonce. Neste caso, se o pagador do usuário tiver saldo insuficiente, os agrupadores pagarão gás inválido por esses UserOps. Portanto, atualmente, a comunicação entre os agrupadores é um problema que precisa ser abordado para evitar ataques de spam de UserOp aos agrupadores.

• Descentralização do agrupador

Os atuais agrupadores são altamente centralizados. Se os agrupadores colocarem certos utilizadores em lista negra, isso faria com que as suas transações não pudessem ser executadas. Isso vai contra a natureza descentralizada e sem permissão da blockchain.

Pagador

O Paymaster é uma parte importante do AA, pois pode subsidiar as taxas de gás dos utilizadores e reduzir significativamente a barreira de entrada para a Web3. Aqui estão algumas implementações populares do paymaster:

• pagador de acumulações
  O pagador da Stackups faz parte do ecossistema Stackups AA. A Stackups implementou um painel de pagador onde DApps ou outros fornecedores de serviços podem configurar suas próprias contas de subsídio emhttps://app.stackup.sh/sign-inpatrocinar as transações dos utilizadores.

• Painel Biconomy

O Painel Biconomy permite que organizações e desenvolvedores utilizem componentes AA em seus projetos. Os proprietários de projetos podem configurar seus projetos para pagar taxas de gás para os usuários através de mestres de pagamento e adicionar condições de patrocínio de gás. Ao registrar seu mestre de pagamento para qualquer cadeia suportada, os DApps podem simplificar muito a experiência Web3 para os usuários.

Carteiras

• Ambire
  Ambire é uma carteira web baseada em AA que é auto-custodial e suporta carteiras de plugin, carteiras de hardware e logins sociais. Ambire emite também tokens de carteira para a governação da carteira Ambire. Atualmente, Ambire suporta cadeias compatíveis com EVM mainstream e Layer2.
• Argent
  Argent é atualmente a carteira mais popular no ecossistema Layer2 e já suporta projetos Layer2 mainstream como Starknet e ZKsync.
• Abacate
  Avocado é uma carteira web que permite aos utilizadores pagar todas as taxas de gás usando USDC e proporciona uma experiência de utilizador sem problemas em diferentes redes.
• Seguro
  Seguro é a carteira de assinatura múltipla CA mencionada anteriormente desenvolvida pela Gnosis. Devido à sua alta segurança e custos de uso, é principalmente usada por instituições e equipes para gestão de fundos.
• Sequência
  A Sequence suporta logins sociais e fornece uma experiência de carteira sem plugins.

O Significado do AA para a Adoção em Massa da Web3

AA alcança centralização, usabilidade e segurança simultaneamente.

Contas EOA tradicionais muitas vezes lutam para alcançar simultaneamente descentralização, usabilidade e segurança.

• Carteiras EOA autogeridas como o Metamask satisfazem a descentralização, mas exigem que os utilizadores gerem as suas chaves privadas, o que representa uma grande barreira à entrada para novos utilizadores. Além disso, se o dispositivo for comprometido, há o risco de roubo da chave privada.
• As contas de EOA custodial MPC eliminam a necessidade de os utilizadores guardarem as suas chaves privadas, mas o MPC em si ainda é controlado por uma instituição. Se a instituição agir de forma maliciosa ou for hackeada, introduz um único ponto de falha, o que vai contra a lógica de descentralização da blockchain.
• Por outro lado, as carteiras AA podem resolver esses problemas. Durante o onboarding do usuário, os agrupadores podem criar contas para os usuários e gerenciar as chaves privadas EOA da AA. À medida que os usuários se familiarizam com a Web3 ou quando seus ativos on-chain atingem um certo limite, o controle da conta EOA da AA pode ser descentralizado por meio de contratos inteligentes, como o uso de carteiras de hardware.

O delegação de gás do mestre de pagamentos transfere o encargo de custo para os utilizadores

No quadro EOA tradicional, os usuários muitas vezes precisam adquirir tokens blockchain como ETH através de moedas fiduciárias para usar aplicativos Web3. Isso geralmente envolve o uso de bolsas centralizadas (CEX) para depositar moeda fiduciária, trocá-la pelo token necessário e, finalmente, transferi-la para uma conta EOA recém-criada. Esse processo requer uma compreensão significativa do Web3 e é complicado em muitas regiões. Ao introduzir pagadores em AA, os custos iniciais de embarque para os usuários podem ser delegados aos proprietários de projetos de DApps. A transferência de taxas de gás tem implicações significativas para a adoção em massa do Web3.

Segurança Reforçada

• Auditorias de segurança para pagador

Atualmente, o ERC-4337 está nos seus estágios iniciais e estão a ser desenvolvidas inúmeras ferramentas com base nele. Do lado do paymaster, o UserOp do utilizador pode ser auditado para evitar que ocorra um tapete, como aprovações excessivas ou transferências de fundos não autorizadas. A auditoria de segurança do paymaster pode ser realizada utilizando métodos bem estabelecidos no setor financeiro web2 para rever transações problemáticas e garantir a segurança dos fundos do utilizador.

• Isolamento de conta

Outra inovação em desenvolvimento é o isolamento de segurança de contas, como separar a conta de fundos da conta de jogo, etc. Quando os usuários usam funções DeFi familiares e de transferência, a conta de fundos com auditoria de segurança mais rigorosa é utilizada. Quando os usuários tentam GameFi ou DeFi pouco familiares, a conta de jogo é utilizada. Dessa forma, sem aumentar as chaves privadas que os usuários precisam gerenciar, o design de isolamento de segurança de contas garante a segurança dos fundos dos usuários no nível subjacente.

Perspetivas e Oportunidades para AA

Experiência de Segurança Aprimorada com Chips Seguros Nativos para Celulares/Computadores e Carteiras de Hardware

Atualmente, muitos dispositivos, como smartphones e laptops, têm chips seguros incorporados, como o Apple T2 Security Chip usado no Mac e no iPhone. Portanto, fundamentalmente, cada dispositivo com um chip Tee é uma carteira de hardware confiável. No entanto, esses chips seguros atualmente não suportam algoritmos comuns de assinatura de blockchain como ECDSA.

• A segurança atual das chaves privadas EOA
  Plugins/carteiros móveis

A segurança atual das chaves privadas de EOA em plugins/cartões móveis é armazenada diretamente em texto simples no dispositivo. Se o dispositivo for comprometido, os ativos do usuário podem ser rapidamente perdidos. Portanto, carteiras de extensão do navegador como o Metamask têm alta usabilidade, mas baixa segurança.

Carteiras de hardware

As carteiras de hardware garantem que as chaves privadas nunca saem do dispositivo e não podem ser acessadas diretamente por partes externas. No entanto, a maioria dos utilizadores não consegue transportar as suas carteiras de hardware consigo o tempo todo, resultando em alta segurança, mas baixa usabilidade.

• Introduzindo AA, usando um chip seguro para segurança do dispositivo

Ao usar a carteira AA e o inovador método de verificação on-chain, as transações podem ser diretamente assinadas pelo chip seguro do dispositivo, garantindo que a chave privada do usuário nunca saia do dispositivo. Isso oferece maior segurança em comparação com as contas tradicionais EOA. Atualmente, a Identidade na Internet do Internet Computer e um projeto chamado Porton Wallet no ETHBogota Hackathon implementaram uma solução que utiliza a assinatura do chip seguro do dispositivo e a chave de sessão, permitindo aos usuários aproveitar totalmente a segurança de seus dispositivos, como smartphones ou computadores, equivalente a uma carteira de hardware.

Graças ao design altamente modular do ERC-4337, através da sua expansão e iteração, as contas AA alcançarão uma segurança significativamente melhorada.

Cross-chain + AA: Experiência sem cadeia para usuários

Atualmente, outro obstáculo para a adoção em massa do Web3 é a fragmentação dos ecossistemas de blockchain em diferentes cadeias.

• Experiência de usar DApp em várias cadeias atualmente

Como exemplo simples, vamos considerar um usuário na Ethereum (ETH) que deseja experimentar uma aplicação na Binance Smart Chain (BSC). O que deve fazer este usuário? Primeiro, o usuário precisa trocar os seus ETH pelos correspondentes USDT/USDC e depois utilizar uma ponte entre cadeias para transferir esses tokens da ETH para a BSC. Depois disso, o usuário precisa comprar alguns BNB de uma exchange centralizada (CEX) e transferi-los para a BSC. Só então o usuário pode começar a experimentar várias aplicações DeFi na BSC. Todo este processo é demorado, tem pouca segurança e tem uma curva de aprendizagem íngreme, especialmente para novos usuários que podem não estar familiarizados com pontes entre cadeias.

• Experiência após a introdução do AA + cross-chain paymaster

Através dos atuais protocolos de cadeia cruzada comumente usados, como Layer0 + AA, o processo de usar DApp em diferentes cadeias pode ser muito simplificado. O paymaster pode integrar totalmente protocolos de cadeia cruzada para conseguir "cobrar uma vez, pagar em qualquer lugar". Por exemplo, se um usuário recarrega USDC no mestre de pagamento de ETH, desde que a conta AA do usuário em cadeias diferentes seja a mesma e esteja vinculada ao mesmo mestre de pagamento, o paymaster pode lidar com a contabilidade em nome do usuário. O usuário não precisa transferir manualmente ativos para qualquer cadeia/camada2 compatível com EVM com o mesmo endereço de conta.

Colocação de anúncios, Subsídio de promoção Dapp para gás

A maior vantagem de introduzir o paymaster é que estabelece programaticamente condições para subsidiar os utilizadores do Dapp.

• Subsídios sem AA e pagador

No passado, houve casos em que projetos do ecossistema Web3 subsidiaram gás para atrair clientes. No entanto, subsidiar contas EOA sem definir condições programaticamente muitas vezes levou ao uso indevido de fundos de subsídio por bots e fraudadores, como transferir diretamente os fundos de subsídio, sem atrair clientes genuínos.

• Subsídios com paymaster

Atualmente, os painéis do pagador geralmente incluem a funcionalidade de subsidiar as taxas de gás para Dapps. Os desenvolvedores de projetos podem facilmente definir as condições para os subsídios no painel, para que apenas transações que atendam a condições específicas sejam elegíveis para o subsídio. Ao controlar as condições de transação nos subsídios através do pagador, os Dapps podem atrair mais usuários genuínos mantendo os custos sob controle.

• Devido ao design modular do ERC-4337, os futuros pagadores podem integrar mais serviços, como os fornecedores de serviços de publicidade, abrindo possibilidades mais amplas para a adoção em massa de aplicações Web3.

Crescimento explosivo em Mobile DApps

Sob o EOA, devido à predominância da Metamask, os atuais Dapps são principalmente acessados através de interfaces web, resultando em uma maior participação de mercado para carteiras de plug-ins web. No entanto, a adoção em massa do web3 depende da participação de usuários móveis, tornando o desenvolvimento e adaptação do AA mais Mobile Native.

Jogos Totalmente On-Chain

Com a crescente popularidade do Dark Forest, a tendência de jogos totalmente on-chain está a surgir silenciosamente. No entanto, a experiência do utilizador ao usar EOA (Contas Possuídas Externamente) nos jogos é muito fraca. Imagine ter de usar uma carteira para autorização ou assinatura de transações sempre que realiza qualquer ação num jogo. Esta interrupção constante impede os jogadores de se concentrarem totalmente no próprio jogo. Para resolver este problema, foram desenvolvidas Contas Arcade, que são versões especializadas de AA regulares, especificamente para jogos totalmente on-chain. Estas contas autorizam operações de jogo específicas, permitindo aos jogadores participar em jogos totalmente on-chain sem a necessidade de autorização e assinatura de transações repetitivas. Como resultado, a experiência de jogo é muito melhorada. É provável que o aumento de jogos totalmente on-chain no futuro impulsione a adoção generalizada de contas AA.

Transações Baseadas em Intenções

Recentemente, o conceito de transações baseadas em intenção ganhou popularidade com o surgimento do Unibot, e a Uniswap também lançou o projeto Uniswap X para promover a implementação de transações baseadas em intenção. O exemplo a seguir pode explicar o que são transações baseadas em intenção:

• Alice quer trocar 1 ETH por 1000 USDT. Alice envia esta intenção para uma pool de transações específica. A intenção define que Alice irá transferir 1 ETH e receber 1000 USDT. A intenção também define o período de validade da transação, digamos 1 hora.
• Outros traders no pool de transações procuram continuamente intenções executáveis.

Se alguém estiver disposto a executar a intenção, a contraparte inicia outra intenção de transferir 1000 USDT para Alice e receber 1 ETH.

A transação foi correspondida com sucesso.

• Finalmente, um agrupador agrupa vários intentos e os envia para o blockchain.

As transações baseadas em intenções proporcionam as seguintes vantagens:

• Preço de execução determinístico, que proporciona uma vantagem significativa em comparação com a incerteza de preço das swaps.
• Taxas de gás mais baixas, uma vez que várias transações de intenção podem ser agregadas e submetidas à blockchain, reduzindo o consumo de gás para transações individuais.
• Experiências de negociação mais diversificadas, à medida que as transações baseadas em intenções abrem a possibilidade de correspondência de negociações fora da cadeia, levando ao surgimento de modelos de negociação mais diversos, como Unibot, que implementa funcionalidades de livro de ordens e front-running.

Atualmente, o CowSwap implementou Transações Baseadas em Intenções com base em EOA. No entanto, as Transações Baseadas em Intenções com base em EOA ainda requerem que os utilizadores autorizem (ERC-20, Aprovar) antes de iniciar a transação. No entanto, sob a nova arquitetura de conta do AA, os utilizadores podem enviar Aprovar e Intenção juntos para o agrupador. O agrupador do AA pode aceder simultaneamente à Intenção Poll, combinar intenções e proporcionar uma experiência de negociação mais conveniente.

Aviso legal：

1. Este artigo foi republicado de [chaincatcher]. Todos os direitos de autor pertencem ao autor original [Presidente: Bill Qian, Investigador: Bonan Yuan]. Se houver objeções a esta reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso prontamente.
2. Responsabilidade Legal: As opiniões expressas 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 da Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.