TL;DR

Desde 2022, a abstração de conta tem sido amplamente discutida no campo, e o framework centrado em torno do PEI-4337 parece ter se tornado um consenso geral na indústria. A popularidade do conceito de abstração tem levado as pessoas a prestarem mais atenção a esses componentes de interação do usuário com baixa barreira de entrada.

No entanto, o EIP-4337 ainda enfrenta pontos problemáticos, como a fragmentação da conta inteligente e experiências de usuário altamente fragmentadas em várias cadeias. Este artigo toma projetos como Biconomy, Safe Core e Particle Network como exemplos para explorar como promover ainda mais o desenvolvimento do campo de abstração de conta dentro do framework EIP-4337.

Sob a perspectiva da abstração do processo de transação, entender o conceito de "abstração de conta"

Em relação à abstração de conta, Vitalik tem repetidamente apontado que é uma condição necessária para reduzir o limiar do usuário para o Ethereum e alcançar a adoção em massa. Sua visão central é permitir que os usuários personalizem métodos de verificação de assinatura + aproveitem o pagamento de gás e iniciem transações on-chain sem nenhum ativo (comumente conhecido como transações sem gás). Somente alcançando esses pré-requisitos que a taxa de conversão de novos usuários para aplicativos Web3 pode ser melhorada.

Propostas anteriores de abstração de conta ou carteiras inteligentes, embora possam alcançar experiências semelhantes, ainda não são flexíveis e eficientes o suficiente. Por exemplo, o Gnosis Safe ainda requer um endereço EOA para acionar transações, e o custo do gás é extremamente alto.

A abstração de conta pretende otimizar a partir da estrutura subjacente das contas de contratos inteligentes, abrindo caminho para a próxima geração de sistemas de contas inteligentes.

No entanto, se olharmos para as propostas reais de abstração de conta, veremos que o foco delas não está no próprio modelo de conta. Por exemplo, propostas relacionadas à abstração de conta como PEI-86, PEI-4337 e PEI-6900 focam na abstração/modularização de todo o fluxo de processamento de uma transação, desde a inicialização até ser recebida pelos nós, verificação de assinatura, pagamento de gás, etc., em vez de focar verdadeiramente na abstração da estrutura da conta. Portanto, parece mais apropriado referir-se a essas várias propostas como "abstração de transação".

Se compreendermos as bem conhecidas propostas de abstração de conta do ponto de vista da “abstração do fluxo de processamento de transações”, podemos entender mais facilmente seus pontos-chave: esse tipo de abstração de transação na verdade tem como objetivo trazer a experiência dos usuários de nível Web2 ao entrarem e usarem produtos no sistema Ethereum, como listas negras/listas brancas, transações iniciadas dentro de um período sem verificação de identidade, transações sem custo de gás, pagamento de taxas em moeda fiduciária, etc.

Alguns podem questionar: Essas funcionalidades não poderiam ser alcançadas no passado com as carteiras de contratos inteligentes existentes? Qual é o valor dos esquemas de abstração de conta como o PEI-4337?

A Essência do PEI-4337: Abstração de Conta como uma Solução Local Ótima no Ecossistema Ethereum

Como a pergunta sugere, embora as carteiras inteligentes anteriores pudessem de fato alcançar as funcionalidades mencionadas, seus métodos de implementação eram frequentemente rudimentares e frequentemente dependiam de instalações de terceiros altamente centralizadas. Por exemplo, os esquemas de pagamento de gás anteriores exigiam a introdução de nós Relayer de terceiros (PEI-2771). Além disso, a falta de padrões unificados entre diferentes implementações de carteiras inteligentes dificultou o desenvolvimento e implantação de componentes complementares.

O objetivo principal de vários PEIs relacionados à abstração de conta é abordar essas deficiências presentes em diferentes projetos de carteiras, introduzindo um framework padronizado especificamente projetado para carteiras de contratos inteligentes. Este framework tem como objetivo transicionar a estrutura de conta dentro do ecossistema Ethereum de uma estrutura funcional básica para uma estrutura inteligente mais sofisticada, aumentando assim a eficiência e escalabilidade do ecossistema como um todo.

Isso é análogo à situação anterior ao surgimento do ERC-20 ou ERC-721, onde os métodos de implementação, funcionalidades e funções/interfaces fornecidas de muitos tokens eram inconsistentes. Tal inconsistência não foi propícia para o desenvolvimento de instalações complementares de terceiros e auditoria de código (é difícil imaginar até que ponto as aplicações DeFi poderiam ter florescido sem o protocolo ERC-20).

Protocolos padronizados/normas de implementação funcional são pré-requisitos para narrativas modulares, e abordagens de desenvolvimento modular são quase pré-requisitos para um desenvolvimento vibrante em qualquer campo (a divisão do trabalho sendo o primeiro princípio de melhoria da eficiência).

No final, EIP-4337 surgiu.

PEI-4337 é uma solução ótima local, mas existem múltiplos ângulos dentro de seu framework que precisam de otimização urgentemente.

PEI-4337 define um conjunto completo de padrões de interface, esclarecendo quais módulos uma carteira inteligente que segue o protocolo 4337 deve ter e quais funções/interfaces cada módulo deve implementar, como Bundler, EntryPoint e Paymaster, e quais funções chamáveis esses componentes devem fornecer.

Uma vez que essas especificações estão claramente definidas, a interação entre diferentes componentes torna-se mais clara, facilitando a introdução do pensamento de design modular no design de abstração de conta e smart wallets, beneficiando grandemente os desenvolvedores de módulos de carteira.

Claro, puramente do ponto de vista do usuário, o valor trazido pelo paradigma de desenvolvimento modular da carteira inteligente ainda não está claro, porque os usuários podem não sentir muita mudança na própria carteira de abstração de conta a curto prazo. No entanto, a médio e longo prazo, o valor de protocolos como o PEI-4337 é semelhante ao ERC-20 e ERC-721. Ele lança as bases para o desenvolvimento a longo prazo das carteiras de abstração de conta e é um marco de significado revolucionário.

No entanto, o PEI-4337 ainda tem muitas questões não resolvidas, como:

1. A funcionalidade da abstração de conta não é suficientemente plug-and-play, tornando fácil para diferentes desenvolvedores reinventar a roda.

2. A compatibilidade deficiente dos módulos de conta leva a um ecossistema fragmentado de sistemas de conta.

3. O ecossistema de abstração de conta altamente fragmentado entre diferentes blockchains torna difícil fornecer aos usuários finais e desenvolvedores uma experiência unificada e de alta qualidade para alcançar uma melhor UX.

Nas seguintes seções, discutiremos soluções para esses problemas.

Direção de Otimização Um: A Modularização da Abstração de Conta se Tornará uma Configuração Básica de Funcionalidade Plug-and-play

Pode-se dizer que um dos principais pontos de discussão atuais relacionados à abstração de conta é como alcançar melhor a modularização das carteiras de abstração de conta e tornar a divisão de cada módulo mais refinada.

Por exemplo, Biconomy, baseado no EIP-4337 (e introduzirá o EIP-6900 mais refinado no futuro), propõe a narrativa da modularização da funcionalidade plug-and-play da abstração de conta para promover ainda mais o desenvolvimento modular do ecossistema de abstração de conta.

A funcionalidade plug-and-play de modularização da abstração de conta é essencialmente alcançada por meio de um protocolo que explicitamente delimita os módulos-chave envolvidos em carteiras de contratos inteligentes, quais interfaces/funções esses módulos devem implementar, e como essas interfaces são nomeadas e chamadas. Posteriormente, desenvolvedores de terceiros irão desenvolver componentes com detalhes variados de acordo com suas próprias ideias, mas esses componentes irão todos cumprir os requisitos delineados no protocolo.

A versão V2 da Biconomy, baseada no EIP-4337 como estrutura do protocolo, estabeleceu padrões mais detalhados e adicionou um conjunto de interfaces não mencionadas no 4337. Ao especificar as funcionalidades que o Bundler, Smart Contract Wallet, Paymaster e outros módulos devem ter, a Biconomy permite que desenvolvedores de terceiros implementem módulos com detalhes de código diferentes, mas com funcionalidades semelhantes e versões diferentes, desde que cumpram as regras de protocolo predefinidas pela Biconomy (compatíveis com o EIP-4337).

Enquanto isso, a Biconomy também introduziu o slogan da “Loja de Módulos.” Enquanto lança ativamente o SDK do módulo de abstração de conta, a Biconomy incentiva os desenvolvedores a enviarem seus próprios módulos de abstração de conta projetados e inicia o “Módulo como um Serviço,” permitindo que todos os projetos de carteira que estejam em conformidade com o protocolo PEI-4337 adotem diretamente esses módulos de abstração de conta escritos por terceiros. Quando os usuários criam contas inteligentes por meio da interface front-end, eles também terão uma seleção mais diversificada de módulos para escolher.

A modularização não apenas facilita a divisão do trabalho, mas também permite que os usuários alternem, adicionem ou removam rapidamente recursos específicos em carteiras inteligentes (em termos mais simples, ela divide a granularidade em componentes mais finos).

Biconomy aponta que quanto maior o grau de modularização nas carteiras de contratos inteligentes, menos alterações são necessárias ao atualizar ou atualizar (não é necessário atualizar os contratos existentes da Carteira de Contratos Inteligentes dos usuários ou usar DelegateCall, apenas alguns módulos externos precisam ser atualizados), tornando mais fácil para diferentes usuários ou desenvolvedores substituir certos componentes.

Na versão futura da solução de abstração de conta da Biconomy, também fará referência ao PEI-6900, que é mais propício à modularização do que o PEI-4337.

Otimização Direção Dois: Segmentação de Módulo Mais Fina para Resolver Questões de Fragmentação de Conta

Em relação à proposta PEI-6900, a Safe (anteriormente Gnosis Safe) na verdade lançou um whitepaper do Protocolo Core Safe relacionado a ele em agosto deste ano, que se baseia fortemente na PEI-6900.

O EIP-6900 aponta que um problema atual com a abstração de conta modularizada é o problema de "fragmentação" ou "ilha" de contas. Por exemplo, enquanto diferentes fornecedores de módulos de abstração de conta ou diferentes aplicativos DApp podem ser compatíveis com o EIP-4337, o nível de abstração do EIP-4337 para diferentes módulos não é alto o suficiente, e a granularidade é relativamente grossa. Isso deixa uma liberdade "excessiva" para os desenvolvedores de módulos de Conta Inteligente (contas inteligentes armazenam informações do usuário e registram a parte central da verificação de transação personalizada e lógica de pagamento de gás).

Como resultado, diferentes projetos de carteiras tendem a projetar módulos de Conta Inteligente com atributos únicos. Com o tempo, outros provedores de módulos de abstração de conta devem priorizar a compatibilidade com o módulo de Conta Inteligente fornecido, levando ao surgimento de uma cadeia de fornecimento fixa montante acima e abaixo. Isso inevitavelmente leva à fragmentação e desconexão no ecossistema de módulos de abstração de conta. (Isso é semelhante aos primeiros dias da indústria de computadores, quando os desenvolvedores de sistemas operacionais precisavam considerar a compatibilidade com dispositivos de hardware de diferentes fabricantes de hardware de computadores.)

Para resolver o problema da fragmentação do ecossistema e melhorar a compatibilidade entre os módulos de abstração de conta desenvolvidos por diferentes provedores, a melhor abordagem é abstrair ainda mais as contas de carteira de contrato inteligente e tornar a granularidade de segmentação do módulo mais refinada.

Após se inspirar nas ideias do PEI-6900, o whitepaper do Protocolo Safe Core fez otimizações mais detalhadas ao Smart Account (contas de carteira de contrato inteligente dos usuários). O Protocolo Safe Core divide cada módulo chamável de uma conta de carteira de contrato inteligente em várias categorias como Plug-ins, Hooks, validadores de assinatura e processadores de função.

Os módulos de conta inteligente são feitos o mais leves possível, com o contrato de conta armazenando apenas os dados e funções mais básicos, enquanto funções que podem ser movidas para fora são implementadas por módulos especializados como "processadores de função" ou "Plugins." Isso adere ao princípio da Navalha de Occam: "Entidades não devem ser multiplicadas desnecessariamente."

Se a própria conta inteligente for leve o suficiente e não envolver muitos detalhes intrincados, contas inteligentes desenvolvidas por diferentes fabricantes serão mais semelhantes em estrutura interna, e a compatibilidade também será maior.

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 através do contrato Manger.

Em geral, a UserOperation primeiro irá acionar um Plugin específico e, em seguida, o contrato Manager verificará se o status do Plugin está normal (registrado no registro). Se estiver normal, o contrato Manager permitirá que a solicitação do Plugin prossiga. Se necessário, o Plugin pode chamar certas funcionalidades fornecidas por alguns Hooks, ou pode não. Depois, o estado da conta inteligente envolvida na UserOperation será modificado.

Através do processo de segmentação e agendamento de módulos de granularidade mencionados acima, o Protocolo Safe Core tenta promover um protocolo de interoperabilidade de módulo de abstração de conta de código aberto. Sua ideia central é tornar os Smart Accounts o mais leves possível, tornando-os tão simples quanto contas EOA, a fim de melhorar a compatibilidade entre os módulos de Smart Account desenvolvidos por diferentes fabricantes.

Otimizar Direção Três: Abstração de Conta Unificada em Todas as Cadeias, Alcançando Contas Consistentes em Diferentes Cadeias

No entanto, mesmo com as soluções mencionadas, ainda há um problema importante não resolvido: diferentes cadeias e diferentes soluções de Camada 2 estão avançando vários esquemas de implementação de abstração de conta com formas conflitantes, muitas das quais entram em conflito com PEI-4337, como zkSync Era, Starknet, Flow, etc. Essa fragmentação na UX da carteira, por exemplo, torna impossível unificar o endereço da carteira inteligente de um usuário no Starknet com o do Arbitrum.

Além disso, em um ambiente multi-cadeia, os usuários implantaram independentemente Smart Accounts em diferentes cadeias, e seus dados de usuário correspondentes geralmente são armazenados nesses contratos. Se os dados do usuário, como chaves, precisarem ser atualizados, as transações devem ser repetidas em várias cadeias, tornando difícil garantir a consistência das Smart Accounts.

Vitalik próprio propôs anteriormente uma solução unificada e facilmente gerenciável de conta inteligente em todas as cadeias. Esta solução usa Ethereum ou um ZKRollup altamente seguro como a cadeia de origem, implanta um contrato de Keystore para armazenar as chaves globais dos usuários e, em seguida, todas as contas de contrato inteligente na Camada 2 compartilham as chaves globais armazenadas no contrato Keystore。

No entanto, esta solução vem com custos extremamente elevados. Sempre que houver uma alteração nas chaves globais registradas pelo contrato Keystore na cadeia de origem, cada conta na cadeia L2/alvo precisa sincronizar as novas chaves por meio de interações entre cadeias. No entanto, o custo das interações entre cadeias entre Ethereum e L2 é muito alto para os usuários arcarem. Além disso, é importante observar que as contas de contratos inteligentes são diferentes das contas EOA. Enquanto estas últimas, devido ao seu método de geração de endereços único, são naturalmente unificadas em várias cadeias (dentro do ecossistema EVM), as contas de contratos inteligentes são completamente diferentes, o que torna difícil para os usuários obter contas de contratos inteligentes com o mesmo endereço em diferentes cadeias.

Em resposta a isso, a Particle Network propôs sua própria abordagem. Embora a ideia geral esteja alinhada com o conceito de Vitalik de separar o Armazenamento e o Código das contas inteligentes, a Particle Network planeja usar uma cadeia separada - a Cadeia da Particle Network - como banco de dados de Armazenamento completo para contas inteligentes. Através de soluções de mensagens entre cadeias de terceiros (como LayerZero, CCIP, Axelar, Connext, etc.), a Particle Network pretende sincronizar as alterações no Armazenamento de uma conta com as Contas locais de outras cadeias.

(Estrutura de Abstração de Conta Multi-Cadeia da Particle Network)

Especificamente, o sistema de abstração de conta de cadeia completa da Particle Network tem como objetivo fornecer aos usuários um endereço de conta de contrato inteligente unificado em diferentes cadeias EVM. Isso requer a implantação de um conjunto de Contratos de Deployer em diferentes cadeias. Os usuários devem acionar a geração de uma nova conta na Cadeia da Particle Network, após o que a Cadeia da Particle acionará todos os Contratos de Deployer em várias 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 concluir interações multi-cadeias por meio de contratos na cadeia da Particle sem estar cientes de outras cadeias, e podem usar o Token de Gás Unificado como um método de pagamento de taxa unificado.

A abstração de conta em toda a cadeia também permite Operações de Usuário entre Cadeias, permitindo que os usuários acionem transações na cadeia alvo através das Operações de Usuário e paguem o gás correspondente na cadeia de origem. Por exemplo, permite a compra de NFTs na Base usando USDC da Polygon.

No entanto, a solução da Rede de Partículas requer esforços altamente coordenados entre Contratos Implementadores e componentes de mensagens entre cadeias para sincronizar contas multi-cadeia e Armazenamento da cadeia de origem. Isso coloca altas demandas na ponte de mensagens entre cadeias ou oráculo usada (um desafio que parece existir em todas as soluções relacionadas à interoperabilidade total da cadeia).

No entanto, a sincronização de contas entre cadeias dos usuários pode ser configurada de forma flexível com diferentes combinações de Pontes de Mensagens, em vez de depender de uma única Ponte. Por exemplo, pode ser configurada com uma política de 2/3, onde as alterações no Armazenamento na cadeia de destino são confirmadas apenas após qualquer dois dos LayerZero, Axelar ou Connext confirmarem a alteração, o que pode mitigar o problema de dependência de um único ponto.

A interoperabilidade perfeita em ambas as cadeias EVM e não EVM representa mais um passo na abstração completa de contas em toda a cadeia dentro do ecossistema Ethereum. Apesar dos avanços na gestão de chaves e contas unificadas em cadeias EVM, ainda há espaço para otimização na abstração completa de contas em toda a cadeia. Cadeias que não são compatíveis com EVM, como Aptos, Solana e Sui, não podem garantir a consistência dos endereços de contas de contratos inteligentes gerados pelos usuários com os das cadeias EVM. Além disso, as cadeias não EVM podem ter dificuldades em adotar o conceito de abstração completa de contas em toda a cadeia proposto por Vitalik e Particle Network sem implementar soluções equivalentes ao protocolo PEI-4337.

Além disso, há espaço para melhorias em projetos de carteira compatíveis com o PEI-4337. A maioria das carteiras inteligentes usa nós Bundler operados de forma independente pelas plataformas respectivas, que muitas vezes não estão interconectados. Este isolamento apresenta riscos, como resistência à censura e disponibilidade. Construir uma interface frontal unificada em grande parte das cadeias seria extremamente desafiador. Uma abordagem para lidar com isso é introduzir um design centrado na intenção, adicionando uma camada sobre a abstração de conta completa da cadeia, tratando o ecossistema PEI-4337 do Ethereum ou outras facilidades de abstração de conta nativa de outras cadeias (como zkSync) como instâncias específicas sob a categoria Solver/Reactor, sendo a seleção de Solvers adequados uma tarefa de nível mais alto.

Tomando a Rede de Partículas como exemplo, ele propõe uma abstração concisa da implementação centrada na intenção, onde diferentes projetos de abstração de conta são simplesmente instâncias incluídas na categoria Solver dentro do esquema de intenções.

Primeiro, a interface do usuário é responsável por traduzir solicitações de linguagem natural ou quaisquer interações do usuário em descrições programáticas específicas, que incluem restrições de entrada e restrições de saída (em outras palavras, condições para entradas aceitáveis e intervalos para resultados de saída aceitáveis). Posteriormente, um ou mais Solvers na rede de Solvers encaminharão a Transação contendo restrições específicas de entrada-saída para os contratos Solver implantados na cadeia (Solver abrange não apenas instalações de nó, mas também componentes de contrato on-chain). O contrato Solver então passará as instruções de Intenção para o contrato Reactor (que gerencia as contas on-chain do usuário), delegando a execução para completar a interação final.

O pedido do usuário é inicialmente recebido pela rede Solver, permitindo que os usuários não precisem se preocupar excessivamente com as cadeias subjacentes ou a construção de diferentes esquemas de abstração de contas, pois esta parte é tratada pelo Solver para construir soluções específicas.

Claro, essas ideias são atualmente apenas um quadro teórico, e os detalhes de implementação ainda estão pendentes de implantação oficial pela Rede de Partículas. O que fica claro é que inevitavelmente surgirá um mercado competitivo de Solvers no futuro, onde os usuários podem iniciar leilões para vários Solvers proporem soluções diferentes. Através de transações simuladas locais, a solução ótima pode ser selecionada e o Solver correspondente pode ser recompensado. Quanto à forma de incentivos, isso depende das considerações dos designers de protocolo da rede Solver (a Rede de Partículas pretende usar tokens PNT como incentivos para seu mercado de leilões Solver).

O Intent atual basicamente protege os detalhes complexos subjacentes e abstrai uma camada superior. Um design em camadas semelhante ao protocolo TCP/IP é necessário tanto para a experiência do usuário quanto para o desenvolvedor em uma interoperabilidade contínua entre cadeias.

Adotando a ampla adoção da abstração de conta

Quando otimizamos o framework 4337 dentro do ecossistema Ethereum sob vários ângulos e promovemos simultaneamente a interoperabilidade contínua entre os ecossistemas Ethereum e não Ethereum, a fim de apoiar a adoção generalizada da abstração de conta, acreditamos que ainda há a necessidade de um produto que abranja tanto os lados da oferta quanto da demanda. Não só deve reduzir as barreiras para os usuários finais utilizarem vários serviços de produtos Web3, mas também focar nos desenvolvedores de serviços para diminuir seu limiar.

Um dos melhores produtos para desempenhar esse papel é o produto Modular Smart Wallet-as-a-Service (Modular Smart Wallet-as-a-Service) da Particle Network:

O serviço fornece uma API fácil de usar que permite aos desenvolvedores integrar de forma transparente a funcionalidade de abstração de conta modular em suas aplicações. Os desenvolvedores podem usar este serviço para criar e gerenciar contas em várias cadeias, realizar interações entre cadeias e utilizar um método de pagamento de taxas unificado. Esse serviço oferecerá aos desenvolvedores uma maneira mais flexível e conveniente de construir aplicações multi-cadeias, promovendo assim a adoção generalizada da abstração de contas.

Além das funcionalidades amigáveis para desenvolvedores mencionadas acima, o aspecto mais significativo é que o produto Modular Smart Wallet-as-a-Service da Particle Network construiu um ecossistema aberto para abstração de conta na comunidade de desenvolvedores, com base em computação de assinatura. Além de fornecer módulos de produto de abstração de conta autodesenvolvidos, integra vários tipos de produtos e serviços de abstração de conta, facilitando a rápida adoção de produtos e serviços de vários desenvolvedores em todo o domínio de abstração de conta.

Ao alinhar a tecnologia com a demanda e abordar as limitações do framework ERC-4337 em todos os aspectos, a melhoria na experiência do desenvolvedor catalisará o surgimento de mais produtos com experiências de usuário excepcionais. Isso acelerará a transição da indústria Web3 de ser orientada para entusiastas de criptografia para ser amigável ao consumidor e mainstream.

Aviso legal：

1. Este artigo é reproduzido a partir de[Tencent website], 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 Gate Learnequipe e eles vão lidar com isso prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem conselhos 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.