Desde 2022, a abstração de contas tem sido um tópico amplamente discutido, e o framework no campo da abstração de contas centrado em PEI-4337 parece ter se tornado um consenso da indústria. A popularidade do conceito de intenção destacou a importância desses componentes de interação do usuário de baixa complexidade.

No entanto, o PEI-4337 ainda tem os pontos fracos como fragmentação de contas inteligentes e experiência do usuário altamente fragmentada da abstração de contas entre cadeias. Este artigo explora como promover ainda mais o desenvolvimento do campo de abstração de contas sob o framework do PEI-4337, tomando projetos como Biconomy, Safe Core e Particle Network como exemplos.

Compreendendo o Conceito de Abstração de Conta da Perspectiva da Abstração do Fluxo de Transação

Em relação à abstração de contas, Vitalik apontou muitas vezes que é uma condição necessária para reduzir o limite de usuários Ethereum e alcançar a adoção em massa. Sua visão central é permitir que os usuários personalizem o método de verificação de assinatura e aproveitem o pagamento de gás, e podem iniciar uma transação on-chain sem quaisquer ativos (comumente conhecida como uma transação sem gás). Somente percebendo esses pré-requisitos os aplicativos Web3 podem melhorar suas taxas de conversão de usuário. Embora propostas abstratas anteriores sem conta ou carteiras de contratos inteligentes possam alcançar experiências semelhantes, elas estão longe de ser flexíveis e eficientes o suficiente. Por exemplo, o Gnosis Safe ainda requer um endereço EOA para acionar transações, e os custos de gás que envolve são extremamente altos. A abstração de contas visa otimizar a estrutura subjacente de contas de contratos inteligentes, abrindo caminho para a próxima geração de sistemas de contas inteligentes. Mas se olharmos para as propostas reais de abstração de contas, descobriremos que seu foco não está no modelo de conta em si. Por exemplo, propostas relacionadas à abstração de contas, como EIP-86, EIP-4337 e EIP-6900, concentram-se na abstração/modularização de todo o processo de processamento de uma transação desde o início até o recebimento por nós, bem como a verificação de assinatura, pagamento de gás, etc., em vez de se concentrar na abstração da estrutura da conta em si. Uma abstração da estrutura da conta. Portanto, parece mais apropriado chamar as várias propostas atuais de "abstrações de fluxo de transação". Se entendermos essas conhecidas propostas de abstração de conta da perspectiva da abstração do fluxo de transações, podemos entender mais facilmente seus pontos principais: esse tipo de abstração de transação realmente visa trazer a experiência do usuário de entrada no nível Web2 e uso do produto para o sistema Ethereum. Isso pode assumir a forma de listas negras/listas brancas, iniciando transações sem verificação de identidade dentro de um determinado período de tempo, transações sem gás, pagamentos em moeda fiduciária, etc.

(Fonte da imagem: Zengo)

No entanto, alguns podem perguntar: essas coisas não poderiam ser alcançadas com carteiras de contratos inteligentes existentes no passado? Qual é o valor de soluções de abstração de conta como o EIP-4337?

Essência do PEI-4337: Soluções Ótimas Locais para Abstração de Conta no Ecossistema Ethereum

Conforme aponta a pergunta acima, embora as carteiras inteligentes anteriores pudessem de fato atingir as funcionalidades mencionadas, os métodos de implementação eram geralmente rudimentares e frequentemente dependiam de infraestruturas de terceiros altamente centralizadas. Por exemplo, no passado, a solução de retransmissão de gás exigia a introdução de nós retransmissores de terceiros (PEI-2771). Além disso, havia uma falta de padrões unificados entre diferentes carteiras inteligentes, o que dificultava o desenvolvimento e a implantação de componentes complementares. A demanda principal de várias PEIs relacionadas à abstração de contas é abordar essas deficiências presentes em diferentes projetos de carteiras, introduzindo um framework padronizado projetado especificamente para carteiras de contratos inteligentes. Este avanço tem como objetivo mudar a estrutura de contas dentro do ecossistema Ethereum de uma estrutura funcional básica para uma estrutura inteligente mais sofisticada com capacidades mais elevadas.

(Fonte da imagem: Springer Link)

Isso é semelhante à situação anterior ao ERC-20 ou ERC-721, onde os métodos de implementação, funcionalidades e funções/interfaces fornecidas de muitos tokens eram inconsistentes. Tais inconsistências dificultaram o desenvolvimento de infraestruturas de terceiros complementares e auditorias de código (é difícil imaginar como as aplicações DeFi poderiam ter prosperado até o nível atual sem o protocolo ERC-20).

Padrões de implementação para protocolos/recursos padronizados são pré-requisitos para o design modular, e o desenvolvimento modular é quase um pré-requisito para qualquer área que busque um crescimento vibrante (a divisão do trabalho sendo o primeiro princípio para melhorar a eficiência).

No final, o PEI-4337 se destaca.

PEI-4337 é uma solução ótima local, mas várias perspectivas dentro de seu quadro precisam ser otimizadas

PEI-4337 define um conjunto completo de normas de interface, esclarecendo os módulos esperados em carteiras inteligentes que aderem ao protocolo 4337 e as funções/interfaces que cada módulo deve implementar. Por exemplo, quais funções invocáveis os componentes como bundler, pontos de entrada e pagador devem oferecer externamente. Com essas diretrizes em vigor, as interações entre diferentes componentes tornam-se mais claras, facilitando a integração de ideias de design modular no design de abstração de conta e carteiras inteligentes. Os desenvolvedores que trabalham em módulos de carteira também se beneficiam significativamente. No entanto, olhando puramente do ponto de vista do usuário, o valor trazido pelo paradigma de desenvolvimento de carteira inteligente modular pode não ser imediatamente evidente, uma vez que as mudanças em carteiras de abstração de conta em si podem não ser palpáveis a curto prazo. No entanto, olhando a médio e longo prazo, o valor de protocolos como PEI-4337 se assemelha ao de ERC-20 e ERC-721. Ele lança as bases para o desenvolvimento a longo prazo de carteiras de abstração de conta, marcando um marco significativo. No entanto, PEI-4337 ainda tem inúmeras questões não resolvidas, como:

1. A abstração da conta não é suficientemente fácil de integrar, levando os diferentes desenvolvedores a reinventar inadvertidamente a roda.

2. Compatibilidade fraca entre os módulos de conta, resultando em um ecossistema fragmentado.

3. Alta fragmentação dos ecossistemas de abstração de contas em diferentes cadeias, tornando desafiador oferecer uma experiência unificada e de alta qualidade para usuários finais e desenvolvedores.

Abaixo, vamos aprofundar nas soluções para esses problemas.

Solução de Otimização 1: O Plugin de Abstração de Conta Se Tornará a Configuração Básica

Um dos principais pontos focais nas discussões atuais sobre a abstração de contas é aprimorar a modularização das carteiras de abstração de contas e refinar ainda mais a granularidade de cada módulo. Por exemplo, a Biconomy, com base no PEI-4337 (o PEI-6900 mais refinado será introduzido no futuro), propõe a abstração de contas plug-and-play para impulsionar ainda mais o desenvolvimento modular do ecossistema de abstração de contas.

(Fonte da imagem: Biconomy)

O chamado plugin de abstração de conta é na verdade estabelecer um protocolo que define explicitamente os módulos-chave envolvidos em uma carteira de contrato inteligente, delineando as interfaces/funções que esses módulos devem implementar e especificando os nomes e métodos de chamada dessas interfaces. Os desenvolvedores de terceiros criarão componentes com detalhes variados com base em suas ideias, garantindo que esses componentes estejam em conformidade com os requisitos estabelecidos no protocolo.

A v2 da Biconomy, baseando-se no EIP-4337 como estrutura de protocolo, elaborou normas mais detalhadas e introduziu um conjunto de interfaces não mencionadas no EIP-4337. Ao declarar as funcionalidades que os agrupadores, carteiras inteligentes de contratos, pagadores e outros módulos devem possuir, a Biconomy permite que desenvolvedores de terceiros implementem módulos com as mesmas características, mas detalhes de código diferentes, contanto que sigam as diretrizes do protocolo estabelecidas pela Biconomy (compatíveis com o EIP-4337).

(Os padrões de interface propostos pela Biconomy indicam quais funções os desenvolvedores de módulos de terceiros devem implementar dentro de seus módulos para chamadas externas). Além disso, a Biconomy introduziu o slogan de "Module Store," promovendo ativamente o lançamento de um SDK de módulo de abstração de conta enquanto incentiva os desenvolvedores a enviar seus próprios módulos de abstração de conta projetados. Esta iniciativa tem como objetivo promover o "módulo como serviço," permitindo que todos os projetos de carteira que aderem ao protocolo EIP-4337 adotem diretamente esses módulos de abstração de conta desenvolvidos externamente. Os usuários agora têm escolhas mais diversas sobre quais módulos usar ao criar contas inteligentes através do frontend.

A modularidade não só facilita a divisão do trabalho, mas também permite aos usuários alternar ou adicionar/remover rapidamente determinadas funções em uma carteira inteligente. Para ser direto, permite refinar a granularidade dos componentes. A Biconomy aponta que quanto maior for o grau de modularidade em uma carteira de contrato inteligente, menos mudanças serão necessárias ao atualizá-la ou aprimorá-la. Não há necessidade de atualizar o contrato da Carteira de Contrato Inteligente existente do usuário ou usar o DelegateCall, apenas alguns módulos externos precisam ser atualizados, tornando conveniente para diferentes usuários ou desenvolvedores substituir certos componentes.

No próximo esquema de abstração de conta atualizado da Biconomy, eles também considerarão o PEI-6900, que é mais propício à modularização do que o PEI-4337.

Solução de otimização 2: Segmentação de módulos mais granular para resolver problemas de fragmentação de conta

Em relação ao PEI-6900, o Safe (anteriormente Gnosis Safe) lançou um whitepaper do Protocolo Principal do Safe em agosto deste ano, que se baseia muito no PEI-6900.

(EIP-6900 Esquemático) O EIP-6900 destaca uma questão predominante na atual abstração de contas modulares, que é a "fragmentação" das contas, ou o problema da ilha. Por exemplo, embora diferentes provedores de módulos de abstração de conta ou vários DApps possam ser compatíveis com o EIP-4337, seu nível de abstração em diferentes módulos é insuficiente, com uma granularidade relativamente baixa. Esse cenário permite liberdade "excessiva" para desenvolvedores de módulos de contas inteligentes (a conta inteligente é o componente principal que armazena informações do usuário, registra a validação de transações personalizadas e lida com a lógica de pagamento de gás) para criar módulos com atributos exclusivos. Como resultado, ao longo do tempo, diferentes projetos de carteira tendem a projetar módulos de conta inteligente com propriedades distintas. Essa tendência obriga outros provedores de módulos de abstração de conta a priorizar a compatibilidade com provedores específicos de módulos de contas inteligentes, formando gradualmente cadeias de suprimentos fixas upstream e downstream. Isso inevitavelmente leva à fragmentação e isolamento do ecossistema do módulo de abstração de conta (semelhante aos primeiros dias na indústria de computadores, onde os desenvolvedores de sistemas operacionais tinham que considerar a compatibilidade com hardware de diferentes fabricantes). Para resolver a questão da fragmentação do ecossistema e melhorar a compatibilidade entre os módulos de abstração de conta desenvolvidos por vários provedores, a abordagem ideal é abstrair ainda mais as contas de carteira de contrato inteligente e refinar a granularidade da segmentação de módulos. Seguindo os princípios descritos no EIP-6900, o whitepaper Safe Core Protocol fez otimizações detalhadas para Contas Inteligentes (contas de carteira inteligente dos usuários). O Safe Core Protocol divide os módulos chamáveis dentro de cada conta de carteira inteligente em várias categorias, como plugins, ganchos, validadores de assinatura, processadores de função e muito mais. Os módulos de conta inteligente visam ser o mais leves possível, armazenando apenas dados e funções essenciais, enquanto delegam funções móveis a "processadores de função" ou módulos segmentados semelhantes. Essa abordagem se alinha ao princípio da Navalha de Occam – "as entidades não devem ser multiplicadas desnecessariamente". Se as contas inteligentes em si forem suficientemente leves e não envolverem detalhes muito complicados, as contas inteligentes desenvolvidas por diferentes provedores exibirão estruturas internas mais próximas e maior compatibilidade.

O protocolo Safe Core também introduz um registro (semelhante à App Store do iPhone), que contém todos os módulos aprovados e disponíveis. Os usuários podem escolher quais módulos ativar e, cada vez que um novo módulo é ativado, ele deve ser processado pelo Manger.

Geralmente, UserOperation primeiro acionará um plug-in e, em seguida, o Manger verificará se o status do plug-in está normal (registrado no registro). Se estiver normal, a solicitação do plug-in será permitida. Se necessário, o plug-in chamará algumas funções fornecidas pelo Hook ou optará por não fazê-lo. Posteriormente, o status da conta inteligente envolvida em UserOperation será alterado.

Através do método de segmentação de módulo de granularidade fina e do processo de agendamento mencionado acima, o Protocolo Safe Core tenta implementar um conjunto de protocolos de interoperabilidade de módulo de abstração de conta de código aberto. A ideia central é tornar a conta inteligente leve e tão simples quanto uma conta EOA para melhorar a compatibilidade entre os módulos de conta inteligente de diferentes provedores.

Solução de otimização 3: Abstração de Conta Omnichain para Contas Unificadas em Diferentes Blockchains

No entanto, apesar das soluções mencionadas, há ainda um problema significativo a ser resolvido: diferentes chains e várias soluções de Camada 2 estão avançando detalhes de implementação divergentes de abstração de conta, muitos dos quais entram em conflito com PEI-4337, como zkSync Era, Starknet, Flow, etc. Isso fragmenta a UX da carteira para os usuários. Por exemplo, endereços de smart wallet na Starknet não podem ser unificados com os da Arbitrum. Além disso, em um ambiente multi-chain, os usuários têm contas inteligentes implantadas independentemente em diferentes chains, e seus dados de usuário correspondentes muitas vezes estão espalhados por esses contratos. Se dados do usuário, como chaves, precisarem ser atualizados, transações precisam ser iniciadas repetidamente em múltiplas chains, tornando difícil garantir a consistência da Conta Inteligente. Vitalik já propôs anteriormente uma solução de conta inteligente unificada em toda a chain e fácil de gerenciar. Essa solução usa Ethereum ou um ZK-Rollup altamente seguro como a chain de origem e implanta o contrato de Keystore para armazenar a chave global do usuário. Em seguida, todas as contas de contrato inteligente na Camada 2 compartilham a chave global armazenada no contrato Keystore.

(Fonte da imagem: https://vitalik.ca/general/2023/06/20/deeperdive.html)

No entanto, esta solução incorre em custos significativos. Sempre que as chaves globais registradas no contrato Keystore na cadeia de origem mudam, cada conta na L2/na cadeia de destino precisa sincronizar as novas chaves por meio de interações entre cadeias. O custo das interações entre cadeias entre Ethereum e Camada 2 é muito alto para os usuários suportarem. Além disso, é crucial notar que as contas de contratos inteligentes diferem das EOAs. Estas últimas, devido à sua abordagem única de geração de endereços, são inherentemente unificadas em várias cadeias EVM. Mas as contas de contratos inteligentes são totalmente diferentes, tornando desafiador para os usuários obter contas de contratos inteligentes com os mesmos endereços em diferentes cadeias. Em resposta, a Particle Network propôs seu próprio método. Embora a ideia geral de seu método esteja alinhada com o conceito de Vitalik, focando na separação do Armazenamento e Código de contas inteligentes, a Particle Network pretende utilizar uma cadeia independente—Cadeia da Particle Network—como banco de dados de Armazenamento completo para contas inteligentes. Eles planejam sincronizar as alterações no Armazenamento de uma conta para o armazenamento local da Conta em outras cadeias via soluções de mensagens entre cadeias de terceiros (como LayerZero, CCIP, Axelar, Connext, etc.).

(Estrutura de Abstração de Conta Multichain da Particle Network)

Particularmente, o sistema de Abstração de Conta Omnichain da Particle Network permite que os usuários tenham um endereço de conta de contrato inteligente unificado em diferentes cadeias EVM. Isso requer a implantação de um conjunto de Contratos de Implementação em diferentes cadeias; os usuários devem acionar a geração de novas contas na Cadeia da Particle Network e, em seguida, a Cadeia da Particle acionará os Contratos de Implementação em todas as cadeias para garantir que os endereços de conta de contrato inteligente gerados para os usuários em diferentes cadeias sejam consistentes. Alternativamente, os usuários podem se envolver em interações multi-cadeia através de contratos na cadeia da Particle sem estar cientes de outras cadeias e podem utilizar o Token de Gás Unificado como método de pagamento universal para taxas de transação.

A Abstração de Conta Omnichain também permite operações de usuários entre cadeias, iniciando transações na cadeia de destino por meio de operações de usuário e pagando o gás correspondente na cadeia de origem. Por exemplo, isso permite que os usuários comprem NFTs na Base usando $USDC da Polygon.

No entanto, a solução da Rede Particle Network requer um alto grau de colaboração entre o Contrato Implementador e o componente de mensagens entre cadeias para alcançar a sincronização de contas multi-cadeia e armazenamento de cadeia de origem. Isso, na verdade, impõe requisitos mais altos ao oráculo ou à ponte de mensagens entre cadeias utilizada (o que parece ser um problema comum em todas as soluções relacionadas à interoperabilidade omnichain). No entanto, a sincronização de contas entre cadeias do usuário pode configurar flexivelmente a combinação de diferentes Pontes de Mensagens, em vez de depender de uma única ponte. Por exemplo, pode ser configurado como uma estratégia 2/3, dependendo da confirmação de qualquer dois dos LayerZero, Axelar e Connext para confirmar as alterações de armazenamento na cadeia de destino. Isso pode ser uma solução potencial para o problema da dependência de um único ponto.

A interoperabilidade sem emendas em toda a cadeia entre EVM e não-EVM é mais um passo em direção à abstração de contas omnicanal dentro do ecossistema Ethereum

Apesar de ter gerenciamento de chaves e contas unificadas em cadeias EVM, ainda há áreas para otimização dentro da abstração de contas omnichain. Cadeias não compatíveis com EVM, como Aptos, Solana, Sui, etc., não podem garantir que os endereços de contas de contratos inteligentes sejam consistentes com aqueles em cadeias EVM. Além disso, as cadeias não-EVM considerariam difícil adotar o conceito de abstração de conta cross-chain proposto na discussão anterior se não implementarem o protocolo ERC-4337 com uma solução equivalente. Além disso, há espaço para melhorias dentro de projetos de carteira compatíveis com EIP-4337. Os nós Bundler usados pela maioria das carteiras inteligentes são oficialmente executados de forma independente, às vezes até mesmo isoladamente uns dos outros, criando vários riscos (como riscos relacionados à resistência à censura e disponibilidade). Construir uma interface de frontend unificada que abranja a maioria das cadeias se mostra imensamente desafiador. Uma solução potencial é introduzir um design centrado na intenção, adicionando uma camada adicional sobre a abstração da conta omnichain. Essa camada incorpora o ecossistema EIP-4337 do Ethereum ou os recursos de abstração de conta nativos de outras cadeias (por exemplo, zkSync) como instâncias específicas sob o tipo Solver/Reactor, com a tarefa de selecionar o Solver apropriado sendo uma responsabilidade de nível superior. Tomando a Rede de Partículas como exemplo, propõe uma implementação concisa e abstrata centrada na intenção. Projetos de abstração de conta diferentes são apenas instâncias incluídas na categoria Solver dentro do esquema de intenção. Em primeiro lugar, o frontend do usuário transforma solicitações de linguagem natural ou qualquer interação do usuário em descrições programáticas específicas que abrangem restrições de entrada e saída (Em outras palavras, essas são condições que permitem entradas que satisfazem os requisitos do usuário e resultados de saída dentro de um intervalo específico). Posteriormente, dentro da rede Solver, transações específicas do Solver encaminham transações contendo restrições precisas de entrada e saída para contratos do Solver implantados na cadeia (os Solvers abrangem não apenas a infraestrutura do nó, mas também os componentes do contrato on-chain). O contrato do Solver transmite a diretiva Intent para o contrato do Reactor (gerenciamento de contas de usuário on-chain), delegando este último para chamar outros módulos para cumprir a interação final. Essa estrutura permite que as solicitações do usuário sejam inicialmente processadas pela rede do Solver, aliviando a necessidade de os usuários compreenderem cadeias subjacentes ou diferentes esquemas de abstração de conta, uma tarefa delegada ao Solver para a construção de soluções específicas. No entanto, essas conceituações ainda são referenciais teóricos, com detalhes de implementação aguardando maior elaboração por Redes de Partículas. É evidente que um mercado competitivo de Solver surgirá no futuro, permitindo que os usuários iniciem lances onde vários Solvers propõem soluções distintas. Através de transações simuladas localmente, a solução ideal pode ser selecionada e os incentivos correspondentes podem ser fornecidos ao seu Solver. A estrutura de incentivos será moldada pelos designers de protocolos da rede Solver (a Particle Network pretende usar tokens PNT como tokens de incentivo para seu mercado de leilões Solver). Atualmente, a essência da intenção protege detalhes complexos das camadas inferiores e abstrai uma camada superior. Esse design em camadas, que se assemelha ao protocolo TCP/IP, é essencial para melhorar a experiência do usuário e a experiência do desenvolvedor na interoperabilidade perfeita entre cadeias.

Abraçando a Adoção em Massa da Abstração de Conta

Após otimizar o framework EIP-4337 dentro do ecossistema Ethereum em vários aspectos e avançar na interoperabilidade contínua entre os ecossistemas Ethereum e não Ethereum, acreditamos que, para apoiar a adoção em massa da abstração de contas, ainda precisamos de um produto que abranja os lados da oferta e da demanda. Este produto deve reduzir a complexidade para os usuários finais que utilizam vários serviços de produtos Web3, ao mesmo tempo que se concentra na redução das barreiras de entrada dos desenvolvedores. Um dos produtos ideais que desempenham esse papel é a Pilha de Serviços de Carteira Inteligente Modular da Particle Network:

Arquitetura de Wallet-as-a-Service inteligente da Particle Network

• O serviço oferece uma API amigável ao usuário, permitindo que os desenvolvedores integrem facilmente funcionalidades modulares de abstração de conta em suas aplicações.
• Desenvolvedores podem usar este serviço para criar e gerenciar contas omnichain, realizar interações entre cadeias e usar um método unificado de pagamento de taxas.
• Tais serviços fornecerão aos desenvolvedores uma maneira mais flexível e conveniente de criar aplicativos de várias cadeias e promover a adoção generalizada da abstração de contas.

Além das características amigáveis aos desenvolvedores acima, o aspecto mais crucial da pilha de Serviço de Carteira Inteligente Modular da Particle Network é que ela construiu um ecossistema aberto para o domínio de abstração de conta, baseado em cálculo de assinatura e orientado para os desenvolvedores. Ao lado de seus módulos de produto de abstração de conta internos, a Particle Network integra vários tipos de produtos e serviços de abstração de conta. Essa integração acelera a adoção de produtos e serviços em todo o domínio de abstração de conta para os desenvolvedores.

(Design modular da Smart Wallet-as-a-Service da Particle Network) Deixe a tecnologia atender às necessidades dos usuários. Após resolver as limitações do framework ERC-4337, a melhoria da experiência do desenvolvedor levará ao surgimento de mais produtos com excelentes experiências do usuário, acelerando a transição do Web3 de uma indústria financeira amigável ao cripto-punk para uma indústria amigável ao consumidor para as massas.

Aviso legal：

1. Este artigo é reproduzido a partir de [极客 Web3]. Todos os direitos autorais pertencem ao autor original [Peter Pan, Co-fundador e CTO da Particle Network & Faust，极客Web3]. Se houver objeções a esta reimpressão, entre em contato com o Portão Aprender equipe, e eles vão lidar com isso prontamente.
2. Aviso de responsabilidade: As opiniões e pontos de vista expressos neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.