A infraestrutura da carteira desempenha um papel crucial na desbloquear da experiência da web3 para a próxima geração de dapps.

Até agora, os usuários tiveram que instalar software adicional, obtê-lo e financiá-lo com uma moeda nova e enfrentar telas de confirmação desconhecidas antes mesmo de fazer a primeira interação no web3. Apesar da melhoria na firewall e do movimento longe de frases-semente, esses obstáculos ainda são pontos de alta rotatividade para aplicações descentralizadas.

O ambiente tem sido propício para inovações que abstraem camadas técnicas, possibilitando a integração intuitiva a novas experiências financeiras, sociais e de jogos sem comprometer o ethos original de auto-guarda e descentralização.

2023 tem sido um ano fundamental para o ecossistema da carteira, com a abstração de conta e desenvolvimentos em todas as camadas da pilha mudando as estruturas de mercado e alterando a forma como pensamos sobre a relação entre usuários, dapps e carteiras.

Abstração de Conta: O quê, Porquê e Como

Podemos pensar na abstração de conta como a desvinculação da gestão de conta da gestão de chaves. Uma conta é uma entidade na blockchain que pode conter ativos e ter um histórico de transações. Os signatários (chaves) são entidades com a autoridade para realizar ações em nome das contas.

Com contas tradicionais (EOAs), uma chave privada mantém o controle exclusivo e total sobre sua conta associada. A rigorosa correspondência 1 para 1 entre a chave privada e a conta significa que:

Os usuários estão limitados a usar soluções de gerenciamento de chaves dedicadas (por exemplo, Metamask, Ledger) ao interagir com o blockchain.

Não há caminho de recurso ao perder uma chave privada e a chave que controla uma conta não pode ser trocada.

Todas as ações originadas por essa chave privada são tratadas como iguais, desde a cunhagem de um NFT gratuito até a movimentação de milhões de dólares.

A abstração de conta torna a conta um contrato inteligente com sua lógica dinâmica para quais chave(s) podem executar ações em seu nome, escopar permissões e realizar verificações e balanços adicionais de acordo com o caso de uso.

Podemos desdobrar ainda mais seus benefícios examinando o que está sendo abstraído.

Porque o protocolo Ethereum só reconhece transações originadas da EOA, a abstração de conta requer uma infraestrutura offchain para relatar transações originadas de contratos inteligentes à cadeia.

ERC-4337 foi introduzido em 2021 como uma maneira padronizada de fazer isso sem alterações no protocolo central. No entanto, alguns projetos estavam oferecendo os benefícios de AA muito antes de o padrão estar totalmente estabelecido.

Carteira segura de assinatura múltipla lançada em 2017 e cresceu para garantir mais de $50B em ativos para DAOs, empresas e indivíduos

A carteira móvel da Argent tem sido impulsionada por contas de contratos inteligentes desde 2018

Carteira de sequência, lançada em 2021, permitiu que a Skyweaver criasse e fizesse login em suas contas inteligentes usando seu e-mail e pagasse taxas usando tokens não nativos

Isso exigia a construção e manutenção de uma infraestrutura de relé personalizada pelo projeto respectivo.

Insira ERC-4337. O padrão oferece uma alternativa descentralizada e resistente à censura para a camada de retransmissão, definindo uma interface para contas, pagadores e agregadores de assinaturas interagirem com retransmissores de terceiros através de um mempool alternativo compartilhado de transações abstraídas de conta ("Operações do Usuário").

Os relayers ("agrupadores") agrupam várias UserOps juntas em uma transação para enviar a um contrato de EntryPoint singleton, que posteriormente verifica se as taxas serão pagas (pela própria conta ou através de pagadores), e executa as UserOps respectivas às contas inteligentes.

Podemos contrastar isso com o modo como a validação e execução acontecem em chains que oferecem abstração de conta nativamente e, portanto, não requerem relés extras (por exemplo, zkSync* e Starknet), bem como a proposta RIP-7560 recentemente publicada para AA nativo no Ethereum e seus rollups.

Em março de 2023, o contrato de entrada 4337 foi implantado na mainnet. Sua comunidade tem sido imensamente bem-sucedida em conseguir que os desenvolvedores participem do movimento de abstração de contas.

Isso deu início a uma onda de novos provedores de infraestrutura e serviços para o ecossistema da carteira e impulsionou projetos existentes para garantir que suas estratégias comerciais e conjuntos de produtos continuem a atender às necessidades dos desenvolvedores de aplicativos que buscam alavancar AA para oferecer aos usuários uma experiência web3 contínua.

Infraestrutura da Carteira e Pilha AA

Assinantes & Gerenciamento de Chaves

A infraestrutura de Gerenciamento de Signatários e Chaves é responsável por gerar e proteger pares de chaves públicas usadas para assinar mensagens, transações e operações de usuário. O exemplo mais direto aqui são as carteiras EOA tradicionais, mas provedores de carteira como serviço surgiram para possibilitar a integração sem semente e o gerenciamento de carteiras por meio de métodos de autenticação alternativos, como redes sociais e e-mail.

Na prática, esses serviços armazenam material chave em HSMs como AWS KMS, que só o usuário pode acessar por meio de suas credenciais de autenticação (Magic, Turnkey), ou operam sob algum esquema SSS/MPC (Privy, Web3Auth, Portal, Capsule) para proteger os materiais.

Lit* melhora esse design de armazenamento de chaves do lado do servidor descentralizando as chaves. Cada nó na rede armazena uma parte de uma chave privada ECDSA gerada por meio de um algoritmo DKG, todas as operações ocorrendo em virtualização criptografada. Regras de autenticação arbitrárias podem ser atribuídas ao par de chaves, dando ao aplicativo ou usuário controle completo sobre quais interações são permitidas e impondo, por exemplo, limites de gastos. A rede também pode ser aproveitada por carteiras MPC 2-de-N como opção de backup e recuperação.

Este ano, houve uma rápida experimentação para aproveitar os Signatários de Hardware e as Senhas como um signatário de uma conta para fornecer aos usuários o gerenciamento de chaves pronto para uso com dispositivos móveis ou desktop modernos. Esses signatários funcionam nativamente com autenticação biométrica (por exemplo, FaceID, TouchID) para oferecer segurança adicional com uma experiência do usuário familiar.

Os signatários de hardware utilizam subsistemas isolados como o iPhone Secure Enclave e o Android Titan HSM para gerar chaves e assinar mensagens, garantindo segurança a nível de hardware. Como as chaves não podem ser extraídas do dispositivo, isso é mais poderoso em conjunto com métodos adicionais de recuperação ou como parte de um sistema de autenticação de dois fatores (2FA).

Passkeys são um padrão para autenticação sem senha construído em cima do WebAuthn. Aqui, um par de chaves é gerado no sistema operacional do dispositivo e pode ser sincronizado entre dispositivos através de serviços como o iCloud, para que a recuperação seja possível se o usuário optar por fazê-lo.

Uma limitação aqui é que as senhas e assinaturas produzidas pelo Hardware Signer não são nativamente reconhecidas por cadeias como Bitcoin e Ethereum. Eles usam a curva elíptica secp256r1 (R1), enquanto essas cadeias operam na variação K1. Embora haja um trabalho em andamento para verificar o R1 de forma confiável e eficiente, alguns produtos habilitados para Passkey estão passando por serviços como Lit e Turnkey para produzir uma assinatura K1 uma vez que o usuário autentica com sua chave.

Um padrão a ser observado aqui é o EIP-7212, que propõe adicionar a curva R1 diretamente ao EVM como um contrato pré-compilado para que todo dispositivo moderno possa assinar transações nativamente sem serviços de terceiros ou intermediários.

À medida que o volume de transações abstratas de conta cresce, a agregação de assinaturas usando assinaturas BLS poderia levar a taxas de conta inteligentes mais baratas do que EOAs em L2s. 4337 define uma interface para contratos auxiliares de Agregador que valida uma única assinatura agregada aprovando múltiplos UserOps, ao invés de validar cada um separadamente.

Relayers

Relayers (por exemplo, 4337 Bundlers) retransmitem transações ou UserOps para um mempool. Em cadeias com AA nativo, operadores de rede e sequenciadores desempenham esse papel, eliminando a necessidade de relayers dedicados externos.

Similar ao Ethereum, que possui múltiplas implementações de cliente (por exemplo, geth, erigon, reth), o ecossistema 4337 possui múltiplas implementações de bundler em diferentes linguagens, tornando a rede mais robusta contra vulnerabilidades de uma única implementação. As especificações 4337 incluem um conjunto de testes para garantir a compatibilidade do bundler em toda a rede. Os implementadores incluem Stackup (Golang), Pimlico, Biconomy, Etherspot (Typescript), Candide (Python), OKX (Java) e Alchemy (Rust).

O modelo de incentivo para os agrupadores é semelhante ao dos construtores de blocos, recebendo taxas das operações do usuário que ele agrupa, em vez de transações. Na prática, os agrupadores precisam de uma API para o construtor de blocos para ver o bloco atual e criar um pacote que seja válido em relação a esse bloco e, portanto, deve ser considerado como parte do construtor de blocos.

À medida que a tração 4337 cresce, podemos esperar que os construtores também sejam bundlers, pois esse híbrido será mais lucrativo do que um construtor sozinho, já que eles podem selecionar tanto das transações quanto das pools de UserOps.

Mestres de Pagamento

Os Pagadores permitem a abstração de taxas ao permitir que os dapps patrocinem o gás para os usuários, permitindo que os usuários paguem taxas usando tokens não nativos ou resolvendo offchain via trilhos de pagamento tradicionais. Os serviços de pagador têm 2 componentes principais:

Um gerente de política de gás para desenvolvedores definir as condições sob as quais eles patrocinarão gás. Isso pode ser limitado ao projeto inteiro, ou com base em um contrato específico ou endereço de carteira. Os desenvolvedores também podem definir como desejam limitar o patrocínio de gás, por exemplo, por preço de gás, # solicitações, ou valor patrocinado/mês. Os custos de patrocínio de gás geralmente são incluídos na fatura mensal dos desenvolvedores pelo provedor de serviços com uma sobretaxa de ~5% para o valor patrocinado.

Um contrato inteligente de pagador valida se uma transação específica é elegível para ser coberta, seja com base no estado onchain como saldos de contas ou políticas de gerenciamento de gás offchain. O contrato de pagador mantém um saldo de tokens nativos que é usado para pagar o gás e pode conter lógica do oráculo de preço que verifica periodicamente a taxa de câmbio entre o token de pagamento (por exemplo, USDC) e o token nativo (por exemplo, ETH).

Os pagadores podem ser categorizados como onchain ou offchain:

Os Pagadores Onchain (por exemplo, ERC20Paymaster, StablecoinPaymaster) dependem apenas do estado onchain para verificar se uma transação pode ser coberta pelo pagador ou não. Isso significa que certos pagadores, como aqueles que aceitam pagamento de gás em tokens ERC-20, podem ser tornados sem permissão, com a ressalva de que o pagador deve ser aprovado pela conta para transferir os tokens de pagamento. Os administradores do contrato do pagador podem sacar tokens e converter de volta para a moeda nativa para reabastecer o contrato, definir uma margem em cima do preço do ERC20, estabelecer um limite para a diferença de preço para a qual o pagador atualiza o preço do ERC20 para a próxima UserOp, ou atualizar manualmente o preço.

Os Paymasters Offchain (por exemplo, VerifyingPaymaster) envolvem interações com a API do paymaster de um provedor de serviços para patrocinar o UserOp. O serviço offchain verifica a elegibilidade e aprova a transação usando as chaves do paymaster. Embora essa solução seja autorizada, os paymasters offchain vêm com os benefícios de economia de gás ao minimizar as verificações onchain. As políticas de gás podem ser mais granulares e levar em consideração atividades offchain, como a atividade no Discord.

Fábricas de Contas & Estruturas

As Fábricas e Estruturas de Contas fornecem implementações inteligentes "headless" e SDKs que dapps e clientes de carteira podem construir por cima, criando contas embutidas auto-custodiais em nome de seus usuários. As contas em si são carteiras de contrato inteligente que possuem sua própria lógica de validação de assinatura, execução e proteção de replay (gerenciamento de nonce). Os proprietários autorizam operações de usuários originadas de suas contas inteligentes usando sua chave.

Em um nível elevado, os fornecedores de contas inteligentes provisionam 3 coisas essenciais:

Uma implementação central para uma carteira de contrato inteligente, com sua própria lógica para validar, executar transações e quaisquer ações adicionais a serem realizadas antes e depois da execução. Também contém lógica sobre como recursos adicionais podem ser adicionados à carteira por meio de módulos nativos e de terceiros.

Um contrato de fábrica que implementa novas instâncias da implementação da carteira, iniciadas com o signatário inicial para essa conta. Sob o ERC-4337, dapps podem criar contas inteligentes para seus usuários especificando o endereço do contrato de fábrica de seu provedor de escolha.

Um SDK que oferece aos desenvolvedores a possibilidade de personalização plug-and-play para as contas inteligentes que estão criando. Isso pode incluir diferentes opções de assinatura, tecnologias de ligar/desligar e de retransmissão.

Sob o ERC-4337, o remetenteO campo de um UserOp refere-se à conta inteligente sob a qual a transação está sendo feita. Se a conta ainda não foi implantada, o EntryPoint implanta a conta a partir do contrato da fábrica especificado no initCodeAs chaves do usuário podem ser usadas para reivindicar a conta inteligente para fazer interações dapp subsequentes.

Provedores de contas como Safe, Zerodev e Biconomy integram-se com gerenciadores de chaves e infraestrutura de autenticação para dar opções às dapps sobre como desejam que os usuários gerenciem suas contas inteligentes. Por exemplo, a integração do Web3Auth da Safe permite que os usuários usem suas contas usando redes sociais ou e-mail, e a integração do Zerodev com Turnkey oferece a opção de gerenciar contas com Passkeys.

Safe é mais conhecido por seu produto de carteira inteligente testado em batalha amplamente utilizado por indivíduos, equipes e DAOs. Até o momento, foram implantados mais de 5 milhões de Safes em mais de 12 blockchains, executando mais de 22 milhões de transações. Antes da v1.4.1 (lançada em julho de 2023), os desenvolvedores já podiam usar o Gelato relay para habilitar transações abstraídas de gás. Essa combinação atualmente alimenta produtos de cartão de débito criptográfico como Gnosis Pay e BasedApp, onde os usuários podem comprar de qualquer fornecedor que aceite Visa usando fundos em sua Safe. A v1.4.1 traz suporte ERC-4337 por meio de módulos para fornecer opções adicionais em provedores de relay.

ZeroDev é um provedor de conta inteligente lançado no início deste ano construído para ERC-4337 desde o início. A ZeroDev agrega vários provedores de agrupamento para abstrair serviços de retransmissão UserOp e expõe um painel de gerenciamento de gás onde os desenvolvedores podem definir o escopo e a lógica de limitação de taxa para patrocinar taxas para os usuários. ZeroDev e Biconomy (que também executa sua própria rede de agrupamento) atualmente dominam a participação de mercado para contas habilitadas para 4337.

O AccountKit da Alchemy apresenta uma implementação de conta inteligente compatível com 4337, "LightAccount", que é baseada na implementação da EF e adiciona suporte ao EIP-1271 (validação de assinaturas originadas de contratos inteligentes) juntamente com transferências de propriedade, rotação de chaves e armazenamento de namespaces.

Módulos de Conta

Módulos de Conta são contratos inteligentes que atuam como componentes instaláveis em uma conta inteligente. Embora a infraestrutura de módulos ainda esteja em estágios muito iniciais, prevemos que os módulos serão descobríveis e instaláveis por:

Desenvolvedores: contas inteligentes incorporadas podem vir com módulos “pré-instalados” conforme decidido pelo desenvolvedor do dapp, construindo uma carteira inicial com recursos personalizados para o caso de uso deles

Usuários finais: as interfaces de carteira podem expor uma “loja de módulos” onde os usuários podem descobrir novos recursos e adicioná-los à sua carteira

Com a AA separando formalmente como a validação e execução do UserOp são tratadas, os módulos podem conter lógica apenas de validação ou apenas de execução.

Validadores. Chamados durante a fase de validação de uma UserOperation. Sua função principal é verificar a assinatura de uma UserOperation e determinar se é válida e deve ser executada. Exemplos incluem multisig, ECDSA, passkeys, validação multichain e chaves de sessão. Chaves de sessão permitem que dapps assinem em nome do usuário para simplificar a UX, comportando-se como chaves privadas temporárias com permissões personalizáveis e tempo de expiração.

Executores. Chamado durante a fase de execução de uma UserOperation. Eles estendem a lógica de execução da conta e permitem um conjunto mais diversificado de ações que ela pode realizar nativamente. Exemplos incluem ações automatizadas que são acionadas fora do fluxo de execução regular do ERC-4337, como trocas automáticas de tokens quando o preço atinge um certo limite.

Hooks. Execute antes ou depois da execução e aplicar controles contra a conta. Por exemplo, um hook poderia ser executado depois da execução e reverter quaisquer transações que atendam a certos critérios para criar uma segurança aumentada para o usuário.

Embora algumas carteiras, como a Candide, tenham desenvolvido módulos que seus usuários podem instalar diretamente, antecipamos um ecossistema rico de módulos de terceiros descobertos em uma interface semelhante a uma loja de aplicativos de suas carteiras, ou compostos em uma carteira embutida de “inicialização” pelos desenvolvedores de dapp.

Estruturas de conta inteligente já estão projetadas com módulos em mente. O contrato principal do Safe lida com a lógica de gerenciamento de módulos para adicionar e remover módulos da conta, mas deixa a lógica e o armazenamento relacionados ao módulo completamente isolados em um contrato separado. Essa separação de preocupações mitiga o risco de módulos de terceiros sobrescreverem o mesmo estado, comprometendo a segurança e o comportamento esperado da conta.

O Protocolo Safe{Core} introduz um framework aberto com módulos, ganchos, um gerente e registros destinados a fomentar um ecossistema de contas inteligentes componíveis inspirado nas aprendizagens do produto de carteira da Safe.

ZeroDev classifica explicitamente seus módulos ("plugins") como validação ou execução. Os módulos Executor são projetados para serem combinados com módulos validadores, permitindo que funções personalizadas sejam "roteadas" por diferentes validadores. Por exemplo, uma função de "transferência de NFT" que só permite que NFTs sejam transferidos via 2FA.

Algumas considerações na construção de um ecossistema robusto de contas inteligentes modulares:

Interoperabilidade. Com vários fornecedores de contas inteligentes, cada um com sua própria abordagem sobre como terceiros podem adicionar novos recursos às contas, os desenvolvedores de módulos estão em uma trajetória em direção ao bloqueio do fornecedor ou tendo que gerenciar o ônus técnico de desenvolver os mesmos recursos para estar em conformidade com várias implementações de contas. Algumas soluções para mitigar isso:

ERC-6900 para contas de contrato inteligente modulares e plugins define interfaces para contas de contrato inteligente modulares (MSCAs), módulos (“plugins) permitindo que qualquer implementação de conta compatível com padrões e plugins seja interoperável entre si.

O ModuleKit da Rhinestone para construção e teste de módulos de contas inteligentes fornece modelos e estruturas para testar módulos em diferentes implementações de contas, uma biblioteca de integrações (por exemplo, protocolos DeFi), condições pré-construídas para execução e automação de segurança para analisar o código do módulo e sinalizar vulnerabilidades de segurança.

Segurança. Dar aos usuários a capacidade de instalar software de terceiros em suas carteiras traz questões importantes sobre como as interfaces devem curar e expor informações relevantes sobre módulos.

EIP-7484 fornece um meio de verificar a legitimidade e segurança de módulos de contas inteligentes construídos de forma independente. Aqui, um registro permite que auditores façam declarações sobre a segurança desses módulos. Interfaces e contas inteligentes podem consultar o registro para obter dados de declaração, verificando que um módulo é seguro para uso. Consulte o registro Rhinestone para uma implementação de referência disso.

Mais amplamente, o EIP-7512 tem como objetivo criar um padrão para uma representação onchain de relatórios de auditoria analisáveis por contratos inteligentes para extrair informações relevantes sobre quem realizou as auditorias e quais padrões foram verificados.

Descoberta. Registos podem ser expostos e consultados por plataformas de contas inteligentes e interfaces de carteira a serem instaladas por desenvolvedores ou usuários finais.

A capacidade de estender a funcionalidade da carteira transforma contas em plataformas de desenvolvimento e novos canais de distribuição para produtos e serviços web3. Já estamos vendo isso com o Metamask Snaps, que permite aos usuários personalizar sua carteira de extensão do navegador com alertas de segurança (através do WalletGuard), recursos de privacidade (através do Nocturne) e interoperabilidade com cadeias não EVM, como Starknet e Bitcoin.

Quando o Chrome permitiu um ecossistema de desenvolvedores estender a funcionalidade do navegador por meio de extensões, isso os impulsionou para a dominação do mercado sobre jardins murados incumbentes, apesar de serem uma década mais jovens. Embora seja difícil para a maioria de nós imaginar como será a experiência da carteira quando as contas modulares se tornarem mainstream, os trilhos já estão sendo colocados para a inovação sem permissão seguir seu curso.

Padrões de Desenvolvimento Emergentes e Suas Implicações

A pilha de carteira evoluída significa que:

Os desenvolvedores podem criar contas não custodiais para seus usuários no contexto de seus aplicativos e buscarão ferramentas como SDKs de conector para lhes dar opções sobre como construir a jornada de integração de ponta a ponta.

As carteiras embutidas são uma nova categoria de carteira, cada fornecedor com suas próprias características e compensações em termos de portabilidade de conta, personalização e pressupostos de confiança.

Se você brincou com dapps Ethereum em 2018, você pode se lembrar de receber um popup do Metamask assim que carregar o site. Isso se deve à falta de boas práticas de UX ao conectar carteiras e dapps, e os desenvolvedores frequentemente recorriam a verificações rígidas para ver se um usuário tem uma carteira de extensão instalada usando o navegador.window.ethereumIsso resultou em um comportamento imprevisível se os usuários tivessem várias carteiras de extensão instaladas, forçando os usuários a escolherem uma e criando um mercado menos competitivo para as carteiras.

O protocolo de comunicação WalletConnect* surgiu para permitir que os usuários conectem qualquer carteira a qualquer dapp, juntamente com o Web3Modal, uma biblioteca que envolve botões e componentes modais para permitir que os usuários escolham com qual carteira desejam usar o dapp.

Hoje, o Web3Modal é uma das várias bibliotecas de conexão de carteira, como RainbowKit, Web3Onboard e ConnectKit, que simplificam o processo de detecção de carteira e autenticação baseada em carteira para os desenvolvedores de dapp. Essas bibliotecas oferecem opções de temas prontos, recursos de busca de carteira e telas que redirecionam os usuários para instalar carteiras caso ainda não tenham uma.

Mais recentemente, o EIP-6963 foi finalizado como um mecanismo alternativo de descoberta de carteira para window.ethereum, permitindo que dapps e scripts injetados fornecidos por extensões se comuniquem de maneira previsível. Graças ao padrão, os usuários agora têm mais opções ao escolher uma carteira de extensão de sua preferência para se conectar aos dapps, e abre um mercado mais competitivo para carteiras.

Embora as bibliotecas de conexão tenham melhorado significativamente o DevEx e UX, a expectativa de que os usuários já tenham ou instalem software adicional para interagir com dapps ainda representa uma grande barreira para a adoção.

Já estamos vendo um vislumbre de como será o futuro da experiência do usuário de integração de dapps, à medida que a próxima geração de bibliotecas de carteiras, que chamaremos aqui de “SDKs de integração” totalmente desenvolvidos, ganha força. Além da autenticação baseada em carteira, esses SDKs oferecem opções alternativas de registro e login, como e-mail, redes sociais, SMS, e criam carteiras incorporadas para usuários sem exigir que instalem software adicional ou naveguem para longe do dapp.

Os desenvolvedores podem integrar conectores oferecidos pelos principais provedores diretamente (por exemplo, Magic, Privy, Web3Auth) ou usar aqueles que envolvem múltiplos serviços (por exemplo, Dynamic, Thirdweb, 0xPass) para fornecer opções plug-and-play sobre as opções de autenticação que desejam expor e o tipo de carteira que desejam criar, personalizando completamente o fluxo de integração. Os SDKs de integração também podem se integrar com provedores de contas inteligentes para criar carteiras inteligentes incorporadas, oferecendo ainda mais aprimoramentos de UX como transações sem gás e rampas de entrada/saída.

Com o aumento da adoção de carteiras “headless” e um movimento em direção a carteiras embutidas, o que costumava ser uma linha clara de separação entre carteiras e dapps está começando a se confundir.

Carteiras autônomas vs. Carteiras embutidas vs. Carteiras específicas de aplicativos

Os usuários do Web3 hoje estão acostumados a interagir com dapps através de carteiras autônomas como Metamask ou aquelas oferecidas através do WalletConnect, acumulando seus ativos e pegada onchain para uma ou algumas contas.

À medida que mais dapps procuram atrair usuários por meio de carteiras embutidas e vários fornecedores disponíveis, a gestão de contas rapidamente se torna complicada tanto para os desenvolvedores de dapps quanto para os usuários finais. Os desenvolvedores de dapps terão que avaliar e gerenciar vários fornecedores, tentando evitar a dependência. Para os usuários finais, criar uma nova carteira por dapp resultará em uma experiência de gestão de ativos e identidade fragmentada.

Embora as carteiras específicas de aplicativos sejam desejáveis para determinados casos de uso, como jogos, há muitas situações em que os usuários podem aderir ao seu primeiro dapp, criar uma carteira incorporada com seus signatários web2 ou Passkey e desejam utilizar os ativos que acumulam nessa conta em outro dapp ao fazer login com o mesmo signatário.

Capsule é um provedor de carteira embutida baseado em MPC que apresenta portabilidade de carteira em dapps que usam seu serviço, dando aos usuários acesso a uma carteira existente usando o mesmo login de e-mail. Podemos antecipar que em breve isso será uma oferta básica entre os provedores de WaaS.

Moonchute ajuda os usuários a gerenciar várias contas inteligentes no intervalo. Seu gerenciador de contas unificado é um aplicativo e API para descobrir carteiras inteligentes criadas por um determinado signatário, permitindo aos usuários gerenciar ativos de várias contas em um só lugar.

ERC-7555 propõe uma interface padronizada inspirada em SSO e um padrão de solicitação/resposta para que aplicativos descubram contas de usuário criadas usando esquemas de assinatura alternativos. Aqui, o aplicativo redirecionaria o usuário para um determinado URI do provedor (que poderia ser um domínio auto-hospedado) e analisaria a resposta para um signatário e endereço de conta inteligente associado.

Migrando de EOAs

Outro desafio importante do AA é uma maneira perfeita para os usuários existentes, que já têm ativos e histórico on-chain acumulado em múltiplos EOAs, migrarem para contas inteligentes.

EIP-7377 propõe um mecanismo em protocolo para permitir que EOAs enviem uma transação única que implanta código em sua conta, efetivamente "atualizando" um EOA para uma carteira inteligente.

Aarc tem como objetivo resolver a migração de ativos para dapps e usuários finais. Seu UI e SDK indexa os ativos e permissões de um endereço de origem específico e permite que os usuários selecionem os ativos que desejam mover para qualquer endereço de destino, que pode ser uma conta inteligente, outro EOA ou uma carteira MPC incorporada criada com login social. Para dapps com usuários existentes que estão acostumados ao fluxo de carteira independente, Aarc oferece uma solução para simplificar o processo de migração, pois procuram adicionar carteiras incorporadas ou recursos de AA ao seu produto.

Implicações AA para gerenciamento de contas multichain

Dada a dinâmica da atividade AA e L2, podemos antecipar um futuro onde as contas inteligentes se tornam mainstream sobre EOAs com usuários tendo ativos em várias cadeias.

Uma vantagem de UX das EOAs é que os usuários automaticamente têm acesso ao mesmo endereço em diferentes cadeias EVM usando a mesma chave privada. A desvantagem é que não é possível alterar as chaves que controlam um determinado endereço, e todos os fundos podem ser perdidos se o usuário perder sua chave privada.

Porque a abstração de conta separa o armazenamento de chaves do armazenamento de ativos, é possível girar chaves para uma conta específica sem ter que migrar fundos, mantendo o mesmo endereço. As contas inteligentes são capazes de manter o mesmo endereço em diferentes redes usando CREATE2, dando aos usuários acesso à conta mesmo que o contrato ainda não tenha sido implantado em uma determinada rede, usando a mesma chave de verificação inicial e implementação de conta.

No entanto, manter o mesmo endereço em todas as blockchains pode ser um anti-padrão a longo prazo.

CREATE2 só é possível em cadeias com equivalência de bytecode EVM. Em um mundo multichain com zk-Rollups (por exemplo, zkSync) com pequenas variações no EVM, essa abordagem não será suficiente.

Podemos esperar que as chaves necessárias para acessar várias contas vão mudar ao longo do tempo, à medida que as carteiras expõem recursos adicionais de assinatura e rotação de chaves. Sob a configuração atual, isso pode rapidamente causar um desvio de estado das permissões da conta entre as cadeias, já que as mudanças nos signatários de uma conta em uma cadeia não propagam automaticamente as novas permissões para aquelas em outras cadeias.

Soluções de longo prazo que foram propostas para AA multichain incluem:

Um contrato de armazenamento de chaves dedicado que uma conta de usuário em várias cadeias lê ao verificar permissões. Veja uma implementação disso da Carteira Soul.

Usando resolutores multichain ENS como uma camada de abstração para diferentes endereços.

A gestão de conta e assinatura entre cadeias ainda é uma área de pesquisa ativa. O objetivo final aqui é que um usuário possa alterar as chaves que têm acesso a várias contas em diferentes cadeias sem realizar um número extremamente alto de transações.

Conclusão e Pensamentos Finais

A abstração de conta é um movimento para desvincular signatários de contas, tornando contas baseadas em contratos (em vez de EOAs) como entidades de primeira classe na blockchain, dando aos usuários flexibilidade na gestão de chaves e permissões de conta.

ERC-4337 como um padrão para retransmissão de transações iniciadas por conta inteligente tem catalisado a evolução da infraestrutura de carteira para acomodar AA, dando origem a novas estruturas de mercado, categorias de carteira, desenvolvimento de dapp e padrões de integração de usuários.

A pilha da carteira foi desagrupada em signatários, relayadores, provedores de contas e módulos de contas, dando aos desenvolvedores a opção de como desejam personalizar a experiência do usuário final. Isso vem com o custo adicional de avaliar cada provedor em relação aos seus trade-offs em termos de custos gerais, resistência à censura, lock-in de fornecedor e interoperabilidade.

Os caminhos de migração de EOAs e a abstração de contas em um contexto multichain ainda são áreas de pesquisa em andamento. Esperamos ver as primeiras implementações das soluções propostas no próximo ano.

Acreditamos que esses desenvolvimentos têm implicações significativas em todo o ecossistema:

Para novos usuários, as carteiras não são mais o único ponto de entrada no web3. As aplicações terão uma integração aprimorada por meio de carteiras embutidas, transações sem gás e rampas de acesso na carteira.

Para os usuários atuais, as experiências onchain se tornarão mais fluidas à medida que os aplicativos aproveitam recursos como chaves de sessão. Os usuários avançados têm mais controle granular sobre as permissões da conta e recursos adicionais da carteira por meio de módulos.

Para os desenvolvedores, a infraestrutura de contas modulares transforma as carteiras em sistemas operacionais. Os mercados de módulos são um novo canal de distribuição sem permissão para produtos e serviços web3.

A infraestrutura da carteira continuará a catalisar a adoção da web3. Nós, da 1kx, estamos orgulhosos de ter apoiado equipes que foram pioneiras nas ideias discutidas neste artigo e continuaremos a monitorar o espaço para ver o que está por vir.

Se estiver trabalhando em soluções nesse espaço ou tiver pensamentos adicionais sobre o assunto, entre em contato@nichanank - adoraria conversar com você.

Muito obrigado a David Sneider, John Rising, Konrad Kopp, Kurt Larsen, Marc Sednaoui, Dogan Alparslan, Vivian Phung, Derek Rein, Tom Terado, Diana Biggs, Mel Quarto e pet3rpan por revisarem os rascunhos deste.

*denota empresas do portfólio 1kx

Declaração:

1. Este artigo foi republicado de[1kx]，direitos autorais pertencem ao autor original[1kx]，如对转载有异议，请联系Equipe Gate Learn，a equipe irá lidar com o processo relevante o mais rápido possível.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são apenas as opiniões pessoais do autor e não constituem qualquer tipo de conselho de investimento.
3. As outras versões do artigo em outros idiomas são traduzidas pela equipe Gate Learn, se não mencionadasGate.ioNão é permitida a cópia, distribuição ou plágio de artigos traduzidos.