Desde 2022, a abstração de contas tem sido um tópico amplamente discutido, e o quadro no campo da abstração de contas centrado em EIP-4337 parece ter-se tornado um consenso da indústria. A popularidade do conceito de intenção tem sublinhado a importância destes componentes de interação do utilizador de baixa barreira.

No entanto, o EIP-4337 ainda apresenta pontos fracos como fragmentação de contas inteligentes e uma experiência do usuário altamente fragmentada na 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 EIP-4337, tomando projetos como Biconomy, Safe Core e Particle Network como exemplos.

Compreender o Conceito de Abstração de Conta a partir da Perspetiva da Abstração do Fluxo de Transações

Em relação à abstração de contas, Vitalik apontou muitas vezes que é uma condição necessária para baixar o limiar de usuários do 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 possam iniciar uma transação on-chain sem quaisquer ativos (comumente conhecida como transação sem gás). Somente percebendo esses pré-requisitos é que 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, a Gnosis Safe ainda requer um endereço EOA para desencadear transações, e os custos de gás que envolve são extremamente altos. A abstração de contas visa otimizar a estrutura subjacente das 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, veremos 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, se concentram na abstração/modularização de todo o processo de processamento de uma transação, desde o início até ser recebida pelos 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ções". Se entendermos essas propostas bem conhecidas de abstração de conta da perspetiva da abstração do fluxo de transações, podemos entender mais facilmente seus pontos principais: esse tipo de abstração de transação na verdade visa trazer a experiência do usuário de entrada no nível Web2 e uso do produto para o sistema Ethereum. Isto pode assumir a forma de listas negras/listas brancas, iniciando trasactions 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 poderiam perguntar: Não poderiam essas coisas ser alcançadas com carteiras de contratos inteligentes existentes no passado? Qual é o valor das soluções de abstração de conta, como o EIP-4337?

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

Como a questão acima aponta, embora as carteiras inteligentes anteriores pudessem de fato alcançar 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 de retransmissão de terceiros (EIP-2771). Além disso, havia uma falta de padrões unificados entre diferentes carteiras inteligentes, o que prejudicou o desenvolvimento e implantação de componentes complementares. A demanda central de vários EIPs relacionados à 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 visa 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)

Isto é semelhante à situação antes do 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é ao seu nível atual sem o protocolo ERC-20).

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

Em última análise, EIP-4337 destaca-se.

EIP-4337 é uma solução ótima local, mas várias perspectivas dentro da sua estrutura precisam de ser otimizadas

O EIP-4337 define um conjunto completo de padrões de interface, esclarecendo os módulos esperados nas smart wallets que aderem ao protocolo 4337 e as funções/interfaces que cada módulo deve implementar. Por exemplo, quais funções chamáveis devem oferecer externamente componentes como bundler, entrypoints e paymaster. 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 contas 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 carteiras inteligentes modulares pode não ser imediatamente evidente, uma vez que as mudanças nas próprias carteiras de abstração de contas podem não ser palpáveis no curto prazo. No entanto, olhando para o médio a longo prazo, o valor de protocolos como o EIP-4337 assemelha-se ao do ERC-20 e do ERC-721. Ele estabelece as bases para o desenvolvimento a longo prazo de carteiras de abstração de contas, marcando um marco significativo. No entanto, o EIP-4337 ainda tem inúmeras questões por resolver, tais como:

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

2. Fraca compatibilidade entre os módulos de conta, resultando num ecossistema fragmentado.

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

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

Solução de otimização 1: O Plugin de Abstração de Conta Tornar-se-á a Configuração Básica

Um dos pontos focais centrais 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 EIP-4337 (o EIP-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 então componentes com detalhes variados com base em suas ideias, garantindo que esses componentes cumpram os requisitos estabelecidos no protocolo.

A v2 da Biconomy, construída com base 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 agregadores, carteiras inteligentes de contratos, paymaster e outros módulos devem possuir, a Biconomy permite que desenvolvedores de terceiros implementem módulos com as mesmas funcionalidades, mas versões diferentes usando detalhes de código diferentes, desde que sigam as diretrizes de 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 “Loja de Módulos”, promovendo ativamente o lançamento de um SDK de módulo de abstração de conta, incentivando os desenvolvedores a submeterem seus próprios módulos de abstração de conta projetados. Esta iniciativa visa 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 mais opções diversas sobre quais módulos usar ao criar contas inteligentes através da interface.

A modularidade não só facilita a divisão do trabalho, mas também permite aos utilizadores alternar ou adicionar/remover rapidamente certas funções numa carteira inteligente. Para ser direto, permite refinar a granularidade dos componentes. A Biconomy aponta que quanto maior for o grau de modularidade numa carteira de contrato inteligente, menos alterações serão necessárias ao atualizá-la ou melhorá-la. Não é necessário atualizar o contrato da carteira de contrato inteligente existente do utilizador ou utilizar o DelegateCall, apenas alguns módulos externos precisam de ser atualizados, tornando mais conveniente para diferentes utilizadores ou desenvolvedores substituir certos componentes.

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

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

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

(EIP-6900 Esquemático) O EIP-6900 destaca uma questão predominante na abstração da conta modular atual, que é a "fragmentação" das contas, ou o problema da ilha. Por exemplo, embora diferentes fornecedores de módulos de abstração de conta ou vários DApps possam ser compatíveis com o EIP-4337, o seu nível de abstração entre diferentes módulos é insuficiente, com uma granularidade relativamente baixa. Esse cenário permite liberdade "excessiva" para os desenvolvedores de módulos de conta inteligente (a conta inteligente é o componente central 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 conta inteligente, formando gradualmente cadeias de suprimentos fixas upstream-downstream. Isso inevitavelmente leva à fragmentação e isolamento do ecossistema de módulos de abstração de contas (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 abordar 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 inteligentes 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 pretendem ser o mais leves possível, armazenando apenas dados e funções essenciais, enquanto delegam funções móveis a "processadores de funções" ou módulos segmentados semelhantes. Esta abordagem alinha-se com o princípio da Navalha de Occam – "as entidades não devem ser multiplicadas desnecessariamente". Se as próprias contas inteligentes 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 utilizadores podem escolher quais módulos ativar e, cada vez que um novo módulo é ativado, deve passar pelo Manger.

Geralmente, UserOperation primeiro acionará um plug-in e, em seguida, o Manger verificará se o status do plug-in é normal (registrado no registro). Se normal, o pedido do plugin será permitido. Se necessário, o plugin chamará algumas funções fornecidas pelo Hook ou optará por não fazê-lo. Mais tarde, 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 processo de agendamento mencionado acima, o Protocolo Core Seguro 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 fornecedores.

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

No entanto, apesar das soluções mencionadas anteriormente, permanece um problema significativo a ser resolvido: diferentes cadeias 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 conflitam com EIP-4337, como zkSync Era, Starknet, Flow, etc. Isso fragmenta a UX da carteira para os usuários. Por exemplo, os endereços da carteira inteligente no Starknet não podem ser unificados com os do Arbitrum. Além disso, em um ambiente de várias cadeias, os usuários implantaram independentemente contas inteligentes em cadeias diferentes, e seus dados de usuário correspondentes muitas vezes estão espalhados por esses contratos. Se os dados do usuário, como chaves, precisarem ser atualizados, as transações precisarão ser iniciadas repetidamente em várias cadeias, 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 cadeia e fácil de gerenciar. Esta solução utiliza Ethereum ou um ZK-Rollup altamente seguro como a cadeia de origem e implanta o contrato 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 acarreta custos significativos. Sempre que as chaves globais registadas no contrato Keystore na cadeia de origem mudam, cada conta na L2/a cadeia de destino precisa de sincronizar as novas chaves através de interações entre cadeias. O custo das interações entre cadeias entre Ethereum e Camada 2 é demasiado elevado para os utilizadores 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 utilizadores obter contas de contratos inteligentes com os mesmos endereços em diferentes cadeias. Em resposta, a Particle Network propôs o seu próprio método. Embora a ideia geral do seu método coincida com o conceito de Vitalik, focando-se na separação do Armazenamento e Código de contas inteligentes, a Particle Network pretende utilizar uma cadeia independente - Cadeia da Particle Network - como base de dados de Armazenamento completa para contas inteligentes. Eles planeiam sincronizar as alterações no Armazenamento de uma conta para o armazenamento local da Conta em outras cadeias através de soluções de mensagens entre cadeias de terceiros (como LayerZero, CCIP, Axelar, Connext, etc.).

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

Em particular, o sistema de Abstração de Conta Omnichain da Rede de Partículas permite aos utilizadores ter um endereço de conta de contrato inteligente unificado em diferentes cadeias EVM. Para isso, é necessário implementar um conjunto de Contratos de Implementação em diferentes cadeias; os utilizadores devem desencadear a geração de novas contas na Cadeia da Rede de Partículas e, em seguida, a Cadeia de Partículas irá desencadear os Contratos de Implementação em todas as 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 interagir em várias cadeias através de contratos na cadeia de Partículas sem estarem 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ário entre cadeias, iniciando transações na cadeia de destino através 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 Particle Network requer um alto grau de colaboração entre o Contrato do Implementador e o componente de mensagens entre cadeias para alcançar a sincronização de contas multi-cadeia e armazenamento de cadeias de origem. Isso coloca na realidade requisitos mais elevados no oráculo ou ponte de mensagem entre cadeias utilizada (o que parece ser uma questão comum em todas as soluções relacionadas com a interoperabilidade entre cadeias). No entanto, a sincronização de contas entre cadeias do utilizador pode configurar flexivelmente a combinação de diferentes Pontes de Mensagem, 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 alterações de armazenamento na cadeia de destino. Esta poderá ser uma solução potencial para o problema de dependência de um único ponto.

A interoperabilidade omnicanal sem costuras 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 contas entre cadeias proposto no debate 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 revela-se imensamente desafiador. Uma solução potencial é introduzir um design centrado na intenção, adicionando uma camada adicional sobre a abstração da conta omnichain. Esta camada incorpora o ecossistema EIP-4337 do Ethereum ou as instalações de abstração de contas nativas de outras cadeias (por exemplo, zkSync) como instâncias específicas sob o tipo Solver/Reator, 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. Diferentes projetos de abstração de conta 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 englobam 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 a prazo 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 componentes do contrato on-chain). O contrato do Solver transmite a diretiva de intenção para o contrato do Reator (gerenciando contas de usuário on-chain), delegando a este último a chamada de outros módulos para cumprir a interação final. Essa estrutura permite que as solicitações dos usuários sejam inicialmente processadas pela rede Solver, aliviando a necessidade de os usuários compreenderem cadeias subjacentes ou diferentes esquemas de abstração de contas, uma tarefa delegada ao Solver para construir soluções específicas. No entanto, essas conceituações ainda são referenciais teóricos, com detalhes de implementação aguardando maior elaboração pela Rede 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 protocolo 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 em interoperabilidade perfeita entre cadeias.

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

Após optimizar o quadro EIP-4337 dentro do ecossistema Ethereum de várias perspectivas e avançar a 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 procura. Este produto deve reduzir a complexidade para os utilizadores finais que utilizam vários serviços de produtos Web3, ao mesmo tempo que se concentra em reduzir as barreiras de entrada para os programadores. Um dos produtos óptimos que cumpre este papel é a Pilha de Serviços de Carteira Inteligente Modular da Particle Network:

Arquitetura de Serviço de Carteira Inteligente da Particle Network

• O serviço oferece uma API amigável ao usuário, permitindo que os desenvolvedores integrem de forma transparente funcionalidades modulares de abstração de conta em suas aplicações.
• Os desenvolvedores podem usar este serviço para criar e gerir contas omnichain, realizar interações entre cadeias e utilizar um método de pagamento unificado de taxas.
• Tais serviços proporcionarão aos desenvolvedores uma forma mais flexível e conveniente de construir aplicações multi-cadeia e promover a adoção generalizada da abstração de contas.

Para além das funcionalidades amigáveis para os programadores acima mencionadas, o aspecto mais crucial da stack do Modular Smart Wallet-as-a-Service da Particle Network é que construiu um ecossistema aberto para o domínio de abstração de contas, baseado em computação de assinaturas e orientado para os programadores. Além dos seus módulos internos de abstração de contas, a Particle Network integra vários tipos de produtos e serviços de abstração de contas. Esta integração acelera a adoção de produtos e serviços em todo o domínio de abstração de contas para os programadores.

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

Aviso Legal：

1. Este artigo é reproduzido a partir de [GateWeb3 Geek]. 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, por favor entre em contato com o Gate Learnequipa e eles vão lidar com isso 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. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.