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

Até agora, os utilizadores tiveram de instalar software adicional, obter e financiar com uma moeda nova, e enfrentar ecrãs de confirmação desconhecidos antes mesmo de fazer a primeira interação no web3. Apesar da melhoria na firewall e do afastamento das frases semente, estes obstáculos ainda são pontos de alto abandono para aplicações descentralizadas.

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

2023 foi um ano crucial para o ecossistema da carteira, com a abstração de conta e desenvolvimentos em todas as camadas da pilha a mudar as estruturas de mercado e a alterar a forma como pensamos sobre a relação entre utilizadores, dapps e carteiras.

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

Podemos pensar na abstração de conta como a separação da gestão de contas 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 autoridade para realizar ações em nome de contas.

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

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

Não há caminho de recurso para 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 da conta transforma a conta num contrato inteligente com a sua lógica dinâmica para quais chave(s) podem realizar ações em seu nome, permissões de escopo e efetuar verificações adicionais de acordo com o caso de uso.

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

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

ERC-4337 foi introduzido em 2021 como uma forma padronizada de fazer isso sem alterações no protocolo principal. No entanto, alguns projetos já estavam aproveitando os benefícios do AA muito antes de o padrão estar completamente desenvolvido.

Carteira segura* multisig 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 alimentada por contas de contratos inteligentes desde 2018

A carteira Sequence, lançada em 2021, permitiu à Skyweaver criar e fazer login em suas contas inteligentes usando seu e-mail e pagar taxas usando tokens não nativos

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

Introduza o 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 uma mempool alternativa compartilhada de transações abstraídas de contas ("Operações do Utilizador").

Os relayers ("bundlers") agrupam vários UserOps juntos em uma transação para enviar a um contrato de EntryPoint único, que posteriormente verifica se as taxas serão pagas (pela própria conta ou por meio de pagadores), e executa os respectivos UserOps das contas inteligentes.

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

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

Isto desencadeou uma onda de novos fornecedores 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 a AA para oferecer aos usuários uma experiência web3 perfeita.

Infraestrutura da Carteira e Pilha AA

Signatários & Gestão de Chaves

A infraestrutura de Assinantes & Gestão de Chaves é responsável por gerar e proteger pares de chaves públicas usadas para assinar mensagens, transações e UserOps. O exemplo mais direto aqui são as carteiras EOA tradicionais, mas surgiram fornecedores de carteiras como serviço para permitir a integração sem semente e a gestão de carteiras através de métodos de autenticação alternativos como social e email.

Por baixo do capô, esses serviços armazenam material chave em HSMs como AWS KMS, ao qual apenas o usuário pode aceder através das suas credenciais de autenticação (Magic, Turnkey), ou operam sob algum esquema SSS/MPC (Privy, Web3Auth, Portal, Capsule) para proteger os materiais.

Lit* melhora este 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 através de um algoritmo DKG, todas as operações ocorrendo em virtualização encriptada. Regras de autenticação arbitrárias podem ser atribuídas ao par de chaves, dando ao aplicativo ou usuário controle total sobre quais interações são permitidas, e impor, por exemplo, limites de gastos. A rede pode ser ainda mais aproveitada por carteiras MPC 2-of-N como opção de backup e recuperação.

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

Os Assinantes 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, isto é especialmente poderoso em conjunto com métodos adicionais de recuperação ou como parte de um sistema de 2FA.

As passkeys são um padrão para autenticação sem palavra-passe construído em cima do WebAuthn. Aqui, um par de chaves é gerado no sistema operativo 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 utilizador tiver optado por fazê-lo.

Uma limitação aqui é que as chaves de acesso e as assinaturas produzidas pelo Hardware Signer não são nativamente reconhecidas por cadeias como o Bitcoin e o 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 segura 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 se autenticou 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 abstraídas de conta aumenta, 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 Aggregator que valida uma única assinatura agregada aprovando várias UserOps, em vez de validar cada uma 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.

Tal como acontece com várias implementações de cliente para Ethereum (por exemplo, geth, erigon, reth), o ecossistema 4337 tem várias 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 empacotadores é semelhante ao dos construtores de blocos, recebendo taxas das operações do usuário que empacota em vez de transações. Na prática, os empacotadores 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 agregadores, uma vez que este híbrido será mais lucrativo do que um construtor sozinho, pois podem selecionar tanto da transação quanto das pools UserOps.

Pagadores

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

Um gestor de política de gás para os programadores definirem as condições sob as quais vão patrocinar o gás. Isso pode ser limitado ao projeto inteiro, ou com base num contrato específico ou num endereço específico da carteira. Os programadores também podem definir como desejam limitar o patrocínio de gás, por exemplo, pelo preço do gás, número de pedidos ou montante patrocinado por mês. Os custos de patrocínio de gás são normalmente incluídos na fatura mensal dos programadores pelo fornecedor de serviços com uma sobretaxa de ~5% para o montante patrocinado.

Um contrato inteligente de paymaster valida se uma transação dada é elegível para ser coberta, seja com base no estado onchain como saldos de contas ou em políticas de gestão de gás offchain. O contrato de paymaster detém um saldo de tokens nativos que é usado para pagar o gás e pode conter lógica de 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 em onchain ou offchain:

Os Paymasters Onchain (por exemplo, ERC20Paymaster, StablecoinPaymaster) apenas dependem do estado onchain para verificar se uma transação pode ser coberta pelo paymaster ou não. Isto significa que certos paymasters, como aqueles que aceitam pagamento de gás em ERC-20s, podem ser tornados sem permissão, com a ressalva de que o paymaster tem que ser aprovado pela conta para transferir os tokens de pagamento. Os administradores do contrato do paymaster podem retirar tokens e converter de volta para a moeda nativa para reabastecer o contrato, definir uma margem em cima do preço do ERC20, definir um limite para a diferença de preço para a qual o paymaster atualiza o preço do ERC20 para o próximo 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 assina a transação usando as chaves do paymaster. Embora essa solução seja com permissão, 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 atividade no Discord.

Fábricas de Contas & Estruturas

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

Num nível elevado, os fornecedores de contas inteligentes fornecem 3 coisas principais:

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 após a execução. Também contém lógica para adicionar recursos adicionais à 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, iniciada com o signatário inicial para essa conta. Sob ERC-4337, os dapps podem criar contas inteligentes para seus usuários especificando o endereço do contrato de fábrica de sua escolha de provedor.

Um SDK que oferece aos desenvolvedores a possibilidade de personalização plug-and-play para as contas inteligentes que estão a criar. Isto pode incluir diferentes opções de assinatura, tecnologias de entrada/saída e 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 initCode. As chaves do utilizador podem ser utilizadas para reclamar a conta inteligente e realizar interações dapp subsequentes.

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

Safe é mais conhecido pelo seu produto de carteira inteligente testado em batalha amplamente utilizado por indivíduos, equipes e DAOs. Até à data, já foram implantados mais de 5 milhões de Safes em mais de 12 cadeias, 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 abstratas 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 através de módulos para dar opções adicionais em provedores de relay.

ZeroDev é um fornecedor de contas inteligente lançado no início deste ano, construído para ERC-4337 desde o início. A ZeroDev agrega vários fornecedores de pacotes para abstrair serviços de retransmissão UserOp e expõe um painel de controle 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 pacotes) dominam atualmente a participação de mercado para contas habilitadas para 4337.

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

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 do módulo ainda esteja em estágios muito iniciais, prevemos que os módulos serão descobríveis e instaláveis por:

Desenvolvedores: contas inteligentes embutidas podem ter módulos "pré-instalados" conforme decidido pelo desenvolvedor de dapps, construindo uma carteira inicial com recursos personalizados para seu caso de uso

Os utilizadores finais: as interfaces da carteira podem expor uma “loja de módulos” onde os utilizadores podem descobrir novas funcionalidades e adicioná-las à 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. A 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. As chaves de sessão permitem que as dapps assinem em nome do utilizador para simplificar a UX, comportando-se como chaves privadas temporárias com permissões personalizáveis e tempo de expiração.

Executores. Chamados 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 executar 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 pré ou pós-execução e impor controlos contra a conta. Por exemplo, um hook poderia ser executado pós-execução e reverter quaisquer transações que cumpram certos critérios para criar uma segurança aumentada para o utilizador.

Embora algumas carteiras, como a Candide, tenham desenvolvido módulos que os seus utilizadores podem instalar diretamente, antecipamos um ecossistema rico de módulos de terceiros descobertos numa interface semelhante a uma loja de apps das suas carteiras, ou compostos numa carteira incorporada inicial pelos desenvolvedores de dapp.

Os frameworks de contas inteligentes já são projetados tendo em mente os módulos. O contrato principal da 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 aos módulos completamente delimitados a 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 gestor e registos destinados a promover 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 de execução são projetados para serem combinados com módulos validadores, permitindo que funções personalizadas sejam "encaminhadas" 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 trajetória rumo ao bloqueio de fornecedores ou à necessidade de gerir o encargo técnico de desenvolver as mesmas funcionalidades 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 implementações de contas compatíveis com padrões e plugins sejam interoperáveis 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é-estabelecidas 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 utilizadores a capacidade de instalar software de terceiros nas suas carteiras levanta questões importantes sobre como as interfaces devem curar e expor informações relevantes sobre os módulos.

EIP-7484 fornece um meio de verificar a legitimidade e segurança de módulos de conta inteligente construídos de forma independente. Aqui, um registro permite que auditores façam declarações sobre a segurança desses módulos. Frontends 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 on-chain de relatórios de auditoria que possa ser analisada por contratos inteligentes para extrair informações relevantes sobre quem realizou as auditorias e quais padrões foram verificados.

Descoberta. Os registos podem ser expostos e consultados por plataformas inteligentes de contas e interfaces de carteira a serem instaladas por programadores ou utilizadores finais.

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

Quando o Chrome permitiu um ecossistema de desenvolvedores para estender a funcionalidade do navegador através de extensões, isso impulsionou-os para a dominação do mercado sobre os 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 Emergentes de Desenvolvimento & Suas Implicações

A pilha de carteira evoluída significa que:

Os desenvolvedores podem criar contas não custodiais para os seus utilizadores no contexto das suas aplicações e procurarão ferramentas como SDKs de ligação 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 carteiras, cada fornecedor com suas próprias características e compromissos em termos de portabilidade de conta, personalização e pressupostos de confiança.

Se brincou com Ethereum dapps em 2018, poderá lembrar-se de receber um popup do Metamask assim que carrega o site. Isto deveu-se a uma falta de boas práticas de UX em torno da ligação de carteiras e dapps, e os programadores muitas vezes recorriam a verificações codificadas para ver se um utilizador tinha uma carteira de extensão instalada usando o navegador.window.ethereumIsso resultou num comportamento imprevisível se os utilizadores tivessem várias carteiras de extensão instaladas, obrigando os utilizadores a escolher uma e criando um mercado menos competitivo para as carteiras.

O protocolo de comunicação WalletConnect* surgiu para permitir que os utilizadores conectem qualquer carteira a qualquer dapp, juntamente com o Web3Modal, uma biblioteca que envolve botões e componentes modais para deixar os utilizadores escolherem qual carteira querem utilizar com o dapp.

Hoje, o Web3Modal é uma das várias bibliotecas de ligação de carteiras, como RainbowKit, Web3Onboard e ConnectKit, que simplificam o processo de deteção de carteiras e autenticação baseada em carteiras para os programadores de dapp. Estas bibliotecas oferecem opções de personalização prontas a usar, funcionalidades de pesquisa de carteiras e ecrãs que redirecionam os utilizadores 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 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 a dapps, e abre um mercado mais competitivo para carteiras.

Embora as bibliotecas de conector 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 barreira elevada para a adoção.

Já estamos a ver um vislumbre de como será o futuro da experiência do utilizador na integração de dapps, à medida que a próxima geração de bibliotecas de carteiras, que aqui chamamos de "SDKs de integração" completamente desenvolvidos, ganha força. Para além da autenticação baseada em carteira, estes SDKs oferecem opções alternativas de registo e login, como email, redes sociais, SMS, e criam carteiras incorporadas para utilizadores sem necessidade de instalar software adicional ou de navegar para longe da dapp.

Os desenvolvedores podem integrar conectores oferecidos por fornecedores-chave diretamente (por exemplo, Magic, Privy, Web3Auth) ou usar aqueles que envolvem múltiplos serviços (por exemplo, Dynamic, Thirdweb, 0xPass) para oferecer opções plug-and-play nas opções de autenticação que desejam expor e no tipo de carteira que desejam criar, personalizando completamente o fluxo de integração. Os SDKs de integração também podem trabalhar com fornecedores de contas inteligentes para criar carteiras inteligentes embutidas, oferecendo mais melhorias 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 incorporadas, o que costumava ser uma linha clara de separação entre carteiras e dapps está começando a se tornar mais difuso.

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

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

À medida que mais dapps procuram atrair utilizadores através de carteiras integradas e vários fornecedores disponíveis, a gestão de contas torna-se rapidamente complicada tanto para os programadores de dapps como para os utilizadores finais. Os programadores de dapps terão de avaliar e gerir vários fornecedores enquanto tentam evitar a dependência. Para os utilizadores finais, criar uma nova carteira por dapp resultará numa experiência de gestão de ativos e identidade fragmentada.

Embora as carteiras específicas do aplicativo sejam desejáveis para determinados casos de uso, como jogos, existem muitas instâncias em que os utilizadores podem aderir ao seu primeiro dapp, criar uma carteira embutida com os seus signatários web2 ou Passkey e querer usar os ativos que acumulam nessa conta em outro dapp, ao fazer login com o mesmo signatário.

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

Moonchute ajuda os utilizadores a gerir várias contas inteligentes interinamente. O seu gestor de contas unificado é uma aplicação e API para descobrir carteiras inteligentes criadas por um determinado signatário, permitindo aos utilizadores gerir ativos de várias contas num só lugar.

A ERC-7555 propõe uma interface padronizada inspirada no SSO e um padrão de pedido/resposta para aplicações descobrirem contas de utilizador criadas usando esquemas de assinatura alternativos. Aqui, a aplicação redirecionaria o utilizador para o URI de um fornecedor específico (que poderia ser um domínio auto-hospedado) e analisaria a resposta para um signatário e endereço de conta inteligente associado.

Migrar de EOAs

Outro desafio destacado da AA é uma forma contínua para os utilizadores existentes, que já têm ativos e histórico onchain acumulado em várias EOAs, migrarem para contas inteligentes.

A EIP-7377 propõe um mecanismo in-protocolo para permitir que EOAs enviem uma transação única que implante 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 indexam os ativos e permissões de um endereço de origem específico, e permitem aos usuários selecionar os ativos que desejam movimentar 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 autônoma, Aarc oferece uma solução para agilizar o processo de migração, à medida que buscam adicionar carteiras incorporadas ou recursos AA ao seu produto.

Implicações do AA para gestão de contas multichain

Dada o momentum da atividade AA e L2, podemos antecipar um futuro onde as contas inteligentes se tornam mainstream sobre EOAs com utilizadores a terem ativos em várias cadeias.

Uma vantagem de UX de EOAs é que os utilizadores têm automaticamente 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 utilizador perder a sua chave privada.

Porque a abstração de conta separa a chave da carteira de ativos, é possível rodar chaves para uma determinada conta sem ter que migrar fundos, mantendo o mesmo endereço. As contas inteligentes são capazes de manter o mesmo endereço em várias cadeias usando CREATE2, dando aos utilizadores acesso à conta mesmo que o contrato ainda não tenha sido implantado numa determinada cadeia, utilizando a mesma chave de verificação inicial e implementação de conta.

No entanto, manter o mesmo endereço em várias cadeias pode ser um anti-padrão a longo prazo.

CREATE2 só é possível em cadeias com equivalência de bytecode EVM. Num mundo multichain com zk-Rollups (por exemplo, zkSync) com pequenas deviações para o EVM, esta 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 uma deriva de estado das permissões da conta entre cadeias, pois as alterações nos signatários de uma conta em uma cadeia não propagam automaticamente as novas permissões para aqueles em outras cadeias.

Soluções de longo prazo que foram propostas para multichain AA 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 a partir da Carteira Soul.

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

A gestão de contas e assinaturas 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 cadeias diferentes sem fazer um número extremamente elevado de transações.

Conclusão e Reflexões Finais

A abstração de conta é um movimento para desacoplar signatários de contas, tornando as 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 contas inteligentes catalisou a evolução da infraestrutura da carteira para acomodar AA, dando origem a novas estruturas de mercado, categorias de carteiras, desenvolvimento de dapps e padrões de integração de utilizadores.

A pilha da carteira foi desdobrada em signatários, relayers, provedores de conta e módulos de conta, 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 termos de compensações em relação ao gasto, resistência à censura, bloqueio de fornecedores e interoperabilidade.

Caminhos de migração a partir de EOAs e abstração de contas num 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 estes desenvolvimentos têm implicações significativas em todo o ecossistema:

Para novos utilizadores, as carteiras já não são o único ponto de entrada no web3. As aplicações terão um processo de adesão significativamente melhorado através de carteiras incorporadas, transações sem gás e rampas de acesso na carteira.

Para os utilizadores atuais, as experiências onchain tornar-se-ão mais harmoniosas à medida que as apps aproveitam funcionalidades como chaves de sessão. Os utilizadores avançados têm um controlo mais detalhado sobre as permissões da conta e funcionalidades adicionais da carteira através de módulos.

Para os desenvolvedores, a infraestrutura de conta modular transforma as carteiras em sistemas operativos. 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, na 1kx, estamos orgulhosos de ter apoiado equipas que foram pioneiras nas ideias discutidas neste artigo e continuaremos a monitorizar o espaço para o que está por vir.

Se estiver a trabalhar em soluções neste espaço ou tiver pensamentos adicionais sobre o tópico, entre em contacto@nichanank- gostaria de conversar contigo.

Muitos agradecimentos 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 rever os rascunhos deste.

*denota empresas do portfólio 1kx

Declaração:

1. Este artigo foi republicado de[1kx]，direitos de autor pertencem ao autor original[1kx]，如对转载有异议，请联系Equipe Gate Learn，a equipa irá tratar do assunto o mais rápido possível de acordo com os procedimentos relevantes.
2. Declaração de exoneração de responsabilidade: As opiniões expressas neste artigo representam apenas a opinião pessoal do autor e não constituem qualquer conselho de investimento.
3. As outras versões linguísticas do artigo são traduzidas pela equipe da Gate Learn, quando não especificadoGate.ioNão é permitida a reprodução, distribuição ou plágio de artigos traduzidos sem autorização.