TL;DR

Desde 2022, a abstração de contas tem sido amplamente discutida no setor, e o framework centrado em torno do EIP-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 com o usuário de baixa complexidade.

No entanto, EIP-4337 ainda enfrenta pontos problemáticos como a fragmentação de contas inteligentes 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 contas dentro do framework EIP-4337.

Do ponto de vista da abstração do processo de transação, compreender o conceito de “abstração de contas”

Em relação à abstração de contas, Vitalik tem repetidamente salientado que é uma condição necessária para reduzir o limiar do utilizador para o Ethereum e alcançar a adoção em massa. A sua visão principal é permitir aos utilizadores personalizar os métodos de verificação de assinaturas + desfrutar do pagamento de taxas, e iniciar transações on-chain sem quaisquer ativos (comumente conhecido como transações sem taxas de gás). Apenas ao alcançar estes pré-requisitos é que a taxa de conversão de novos utilizadores para aplicações Web3 pode ser melhorada.

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

A abstração de contas 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 contas, veremos que o foco delas não está no modelo de conta em si. Por exemplo, propostas relacionadas com a abstração de contas, como EIP-86, EIP-4337 e EIP-6900, focam na abstração/modularização de todo o fluxo de processamento de uma transação, desde a sua iniciação até ser recebida pelos nós, verificação de assinatura, pagamento de gás, etc., em vez de focarem verdadeiramente na abstração da estrutura da conta. Portanto, parece mais apropriado referir-se a estas várias propostas como 'abstração de transações'.

Se compreendermos as propostas de abstração de contas bem conhecidas da perspetiva de 'abstração do fluxo de processamento de transações', podemos entender mais facilmente os seus pontos-chave: este tipo de abstração de transações tem como objetivo trazer a experiência dos utilizadores de nível Web2 ao entrarem e usarem produtos no sistema Ethereum, como listas negras/listas brancas, transações iniciadas num período sem verificação de identidade, transações sem custos de gás, pagamento de taxas em moeda fiduciária, etc.

Alguns podem questionar: Será que estas funcionalidades não poderiam ser alcançadas no passado com carteiras de contratos inteligentes existentes? Qual é o valor de esquemas de abstração de contas como EIP-4337?

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

Como a pergunta sugere, embora as carteiras inteligentes passadas 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, esquemas de pagamento de gás anteriores exigiam a introdução de nós Relayer de terceiros (EIP-2771). Além disso, a falta de padrões unificados entre diferentes implementações de carteiras inteligentes prejudicou o desenvolvimento e a implantação de componentes complementares.

O objetivo principal de vários EIPs relacionados com a abstração de contas é resolver estas deficiências presentes em diferentes projetos de carteiras, introduzindo um quadro padronizado especificamente concebido para carteiras de contratos inteligentes. Este quadro tem como objetivo transicionar a estrutura de contas dentro do ecossistema Ethereum de uma estrutura funcional básica para uma estrutura inteligente mais sofisticada, melhorando assim a eficiência e escalabilidade do ecossistema como um todo.

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

Os 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.

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

EIP-4337 define um conjunto completo de normas 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 que funções invocáveis esses componentes devem fornecer.

Uma vez que estas especificações estejam claramente definidas, a interação entre diferentes componentes torna-se mais clara, tornando mais fácil introduzir o pensamento de design modular no design da abstração de contas e das carteiras inteligentes, beneficiando grandemente os desenvolvedores de módulos de carteiras.

Naturalmente, puramente do ponto de vista do utilizador, o valor trazido pelo paradigma de desenvolvimento de carteiras inteligentes modulares ainda não está claro porque os utilizadores podem não sentir muita mudança na própria carteira de abstração de contas a curto prazo. No entanto, a médio e longo prazo, o valor de protocolos como o EIP-4337 é semelhante ao ERC-20 e ERC-721. Ele lança as bases para o desenvolvimento a longo prazo de carteiras de abstração de contas e é um marco de significado revolucionário.

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

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

2. A fraca compatibilidade dos módulos de contas leva a um ecossistema fragmentado de sistemas de contas.

3. O ecossistema altamente fragmentado de abstração de contas entre diferentes blockchains torna difícil proporcionar aos utilizadores finais e programadores uma experiência unificada e de alta qualidade para alcançar uma melhor UX.

Nas secções seguintes, iremos discutir soluções para estes problemas.

Direção de otimização um: A modularização da abstração de contas tornar-se-á 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 contas é como alcançar melhor a modularização das carteiras de abstração de contas e tornar a divisão de cada módulo mais refinada.

Por exemplo, Biconomy, com base 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 contas para promover ainda mais o desenvolvimento modular do ecossistema de abstração de contas.

A funcionalidade plug-and-play modularização da abstração de contas, também chamada assim, é essencialmente alcançada através de um protocolo que delimita explicitamente os principais módulos envolvidos nas carteiras inteligentes de contratos, que interfaces/funções esses módulos devem implementar, e como essas interfaces são nomeadas e chamadas. Posteriormente, os 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 de protocolo, estabeleceu padrões mais detalhados e adicionou um lote de interfaces não mencionadas em 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).

Entretanto, 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 contas, a Biconomy incentiva os desenvolvedores a submeterem os seus próprios módulos de abstração de contas e inicia o “Módulo como um Serviço,” permitindo que todos os projetos de carteira que cumpram o protocolo EIP-4337 adotem diretamente esses módulos de abstração de contas escritos por terceiros. Quando os utilizadores criam contas inteligentes através da interface front-end, terão também uma seleção mais diversificada de módulos para escolher.

A modularização não só facilita a divisão do trabalho, mas também permite aos utilizadores alternar, adicionar ou remover rapidamente funcionalidades específicas em carteiras inteligentes (em termos mais simples, divide a granularidade em componentes mais finos).

A Biconomy aponta que quanto maior for 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 das carteiras de contratos inteligentes existentes dos utilizadores ou usar DelegateCall, apenas alguns módulos externos específicos precisam de ser atualizados), tornando mais fácil para diferentes utilizadores ou desenvolvedores substituir certos componentes.

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

Direção de otimização dois: Segmentação de módulos mais fina para resolver problemas de fragmentação de conta

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

O EIP-6900 aponta que um problema atual com a abstração de contas modularizada é o problema de "fragmentação" ou "ilha" de contas. Por exemplo, enquanto diferentes fornecedores de módulos de abstração de contas ou diferentes aplicações DApp podem ser compatíveis com o EIP-4337, o nível de abstração do EIP-4337 para diferentes módulos não é suficientemente alto 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 contas devem priorizar a compatibilidade com o módulo de Conta Inteligente fornecido, levando ao surgimento de uma cadeia de fornecimento fixa a montante e a jusante. Isso leva inevitavelmente à fragmentação e desconexão no ecossistema de módulos de abstração de contas. (Isso é semelhante aos primeiros dias da indústria de computadores, quando os desenvolvedores de sistemas operacionais tinham que 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 contas desenvolvidos por diferentes fornecedores, a melhor abordagem é abstrair ainda mais as contas da carteira de contratos inteligentes e tornar a granularidade da segmentação do módulo mais fina.

Após recorrer às ideias do EIP-6900, o whitepaper do Protocolo Safe Core fez otimizações mais detalhadas ao Smart Account (contas de carteira de contrato inteligente dos utilizadores). O Protocolo Safe Core divide cada módulo chamável de uma conta de carteira de contrato inteligente em várias categorias, como Plugins, Hooks, validadores de assinaturas e processadores de funções.

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 as 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 suficientemente leve e não envolver demasiados detalhes intricados, as contas inteligentes desenvolvidas por diferentes fabricantes serão mais semelhantes na 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 irá primeiro acionar um Plugin específico e, em seguida, o contrato Manager verificará se o estado do Plugin está normal (registrado no registro). Se estiver normal, o contrato Manager permitirá que o pedido do Plugin prossiga. Se necessário, o Plugin pode chamar certas funcionalidades fornecidas por alguns Hooks, ou pode não. Posteriormente, o estado da conta inteligente envolvida na UserOperation será modificado.

Através do processo de segmentação e agendamento de módulos de granularidade fina mencionado acima, o Protocolo Core Seguro tenta promover um protocolo de interoperabilidade de módulos de abstração de contas de código aberto. A 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 Contas Unificada em Todas as Cadeias, Alcançar Contas Consistentes em Diferentes Cadeias

No entanto, mesmo com as soluções mencionadas, ainda existe um problema importante não resolvido: diferentes cadeias e diferentes soluções de Camada 2 estão avançando com vários esquemas de implementação de abstração de contas com formas conflitantes, muitos dos quais conflituam com EIP-4337, tais 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, num ambiente multi-cadeia, os utilizadores implementaram independentemente Contas Inteligentes em diferentes cadeias, e os respetivos dados de utilizador são frequentemente armazenados nesses contratos. Se os dados do utilizador, como chaves, precisarem de ser atualizados, as transações têm de ser repetidas em várias cadeias, o que torna difícil garantir a consistência das Contas Inteligentes.

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

No entanto, esta solução vem com custos extremamente elevados. Sempre que há uma alteração nas chaves globais registradas pelo contrato Keystore na cadeia de origem, cada conta na cadeia L2/destino precisa sincronizar as novas chaves através de interações entre cadeias. No entanto, o custo das interações entre cadeias entre Ethereum e L2 é muito alto para os usuários pagarem. Além disso, é importante notar que as contas de contrato inteligente são diferentes das contas EOA. Enquanto estes últimos, devido ao seu método único de geração de endereços, são naturalmente unificados em várias cadeias (dentro do ecossistema EVM), as contas de contrato inteligente são completamente diferentes, tornando difícil para os usuários obter contas de contrato inteligente com o mesmo endereço em cadeias diferentes.

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

(Estrutura de Abstração de Contas Multi-Chain da Rede de Partículas)

Especificamente, o sistema de abstração de contas completo da Particle Network tem como objetivo fornecer aos utilizadores um endereço de conta de contrato inteligente unificado em diferentes cadeias EVM. Isso requer a implementação de um conjunto de Contratos de Implementação em diferentes cadeias. Os utilizadores devem desencadear a geração de uma nova conta na Cadeia da Particle Network, após o que a Cadeia da Particle desencadeará todos os Contratos de Implementação em várias cadeias para garantir que os endereços de conta de contrato inteligente gerados para os utilizadores em diferentes cadeias sejam consistentes. Alternativamente, os utilizadores podem concluir interações multi-cadeia através de contratos na cadeia da Particle sem estarem cientes de outras cadeias, e podem utilizar o Unified Gas Token como método de pagamento de taxas unificado.

A abstração de contas em toda a cadeia também permite Operações de Utilizador entre Cadeias, permitindo que os utilizadores desencadeiem transações na cadeia alvo através de Operações de Utilizador 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 de Implementação e componentes de mensagens entre cadeias para sincronizar contas multi-cadeia e Armazenamento de cadeias de origem. Isso coloca altas exigências sobre o oráculo ou ponte de mensagens entre cadeias usada (um desafio que parece existir em todas as soluções relacionadas com a interoperabilidade total das cadeias).

No entanto, a sincronização de contas entre cadeias dos utilizadores 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, em que as alterações ao Armazenamento na cadeia de destino são confirmadas apenas após duas das camadas LayerZero, Axelar, ou Connext confirmarem a alteração, o que pode mitigar o problema da dependência de um único ponto.

A interoperabilidade contínua em ambas as cadeias EVM e não EVM representa mais um passo na abstração de contas completas 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 de contas completas. As 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 aqueles nas cadeias EVM. Além disso, as cadeias não EVM podem ter dificuldades em adotar o conceito de abstração de contas completa proposto por Vitalik e pela Particle Network sem implementar soluções equivalentes ao protocolo EIP-4337.

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

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

Em primeiro lugar, a interface do utilizador é responsável por traduzir pedidos em linguagem natural ou qualquer interação do utilizador em descrições programáticas específicas, que incluem restrições de entrada e restrições de saída (ou seja, condições para entradas aceitáveis e intervalos para resultados de saída aceitáveis). Posteriormente, um ou mais Solvers na rede de Solvers irão encaminhar a Transação contendo restrições específicas de entrada-saída para os contratos Solver implantados na cadeia (Solver abrange não apenas as facilidades do nó, mas também componentes de contratos na cadeia). O contrato Solver passará então as instruções de Intenção para o contrato Reactor (que gere as contas na cadeia do utilizador), delegando a execução para completar a interação final.

O pedido do utilizador é inicialmente recebido pela rede Solver, permitindo que os utilizadores não tenham de 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, estas ideias são atualmente apenas um quadro teórico, e os detalhes de implementação ainda estão pendentes de implementação oficial pela Particle Network. O que é claro é que inevitavelmente surgirá um mercado competitivo de Solvers no futuro, onde os utilizadores podem iniciar leilões para múltiplos Solvers proporem diferentes soluções. 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, depende das considerações dos designers do protocolo da rede Solver (a Particle Network pretende usar tokens PNT como incentivos para o seu mercado de leilões de Solvers).

O Intent atual essencialmente 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, garantindo uma interoperabilidade contínua entre as cadeias.

Abraçando a adoção generalizada da abstração de contas

Quando otimizamos o framework 4337 dentro do ecossistema Ethereum a partir de várias perspetivas e promovemos simultaneamente a interoperabilidade contínua entre os ecossistemas Ethereum e não-Ethereum, com o objetivo de apoiar a adoção generalizada da abstração de contas, acreditamos que ainda há necessidade de um produto que abranja tanto o lado da oferta quanto o da procura. Não só deve reduzir as barreiras para os utilizadores finais usarem vários serviços de produtos Web3, mas também focar nos desenvolvedores de serviços para diminuir o seu limiar.

Um dos melhores produtos para desempenhar este papel é o produto de Carteira Inteligente Modular como Serviço (Carteira Inteligente Modular como Serviço) da Particle Network:

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

Para além das funcionalidades amigas dos programadores mencionadas acima, o aspeto mais significativo é que o produto de Carteira Inteligente Modular como Serviço (Modular Smart Wallet-as-a-Service) da Particle Network construiu um ecossistema aberto para abstração de contas na comunidade de programadores, com base no cálculo de assinaturas. Além de fornecer módulos de produtos de abstração de contas auto-desenvolvidos, integra vários tipos de produtos e serviços de abstração de contas, facilitando a rápida adoção de produtos e serviços de vários programadores em todo o domínio de abstração de contas.

Ao alinhar a tecnologia com a demanda e abordar as limitações do quadro ERC-4337 em todos os ângulos, 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 amigável para entusiastas de criptomoedas e orientada para finanças para ser amigável para o consumidor e mainstream.

Aviso Legal:

1. Este artigo é reimpresso de[Tencent website], Todos os direitos de autor 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 Learnequipa e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.