A mudança de contas de propriedade externa (EOA) para contas de contrato inteligente (SCAs) está ganhando impulso e já é apoiada por muitos empreendedores principais, incluindo Vitalik. Apesar disso, a adoção da SCA não foi tão generalizada como a da EOA. As principais questões incluem o impacto do mercado em baixa, a dificuldade de migrar a EOA para a SCA, questões de assinatura, altos custos de gás e, mais importante, os desafios de desenvolvimento.

A vantagem mais significativa do Account Abstraction (AA) é a capacidade de personalizar a funcionalidade usando código. No entanto, a não interoperabilidade da funcionalidade AA representa um grande desafio, uma vez que esta fragmentação dificulta a integração de AA e reforça a dependência do fornecedor. Além disso, é também um desafio importante garantir a segurança ao mesmo tempo que é atualizável e compostável.

O surgimento da abstração de contas modulares é um nicho na tendência AA, uma abordagem inovadora que separa as contas inteligentes de seus recursos personalizados. O objetivo era criar uma estrutura modular para desenvolver carteiras com vários recursos, segurança e integração perfeita. No futuro, a abstração de conta modular permitirá uma “loja de aplicativos” de conta de contrato inteligente gratuita, permitindo que carteiras e dApps se concentrem em melhorar a experiência do usuário em vez de ter que gastar muito esforço construindo recursos.

Abstração de Conta em Resumo (AA)

O EOA tradicional traz muitos desafios para a exposição das pessoas ao blockchain, como frases de semente, taxas de gás, operações de cadeia cruzada e múltiplas transações.

A abstração de contas aproveita as contas de contratos inteligentes para permitir a validação e a ativação programáveis. Isso significa que os usuários poderão aprovar uma série de transações de uma só vez, em vez de ter que assinar e transmitir cada transação. A abstração de conta também pode permitir mais recursos, como melhor experiência do usuário (por exemplo, extração de gás e chaves de sessão), custos reduzidos (por exemplo, transações em massa) e segurança aprimorada (por exemplo, recuperação social, multiassinatura). Atualmente, existem duas maneiras de abstrair contas:

· Camada de protocolo: Alguns protocolos fornecem nativamente suporte à abstração de conta nativa, as transações ZKSync usam um único mempool e fluxo de transações para suportar AA, tanto do EOA quanto do SCA seguem o mesmo processo, enquanto a Starknet removeu o EOA, todas as contas são SCA e têm carteiras nativas de contratos inteligentes como o Argent.

· Camada de contrato: Para Ethereum e L2s semelhantes, ERC4337 introduziu um mempool separado para suportar AA sem alterar a camada de consenso. Lugares como Stackup, Alchemy, Etherspot, Biconomy, Candide e Plimico estão construindo infraestrutura de empacotadores, enquanto coisas como Safe, Zerodev, Etherspot e Biconomy estão construindo empacotadores e SDKs.

O dilema de adotar a SCA

O tema da abstração de contas (AA) tem sido discutido desde 2015 e foi ainda mais avançado para os holofotes este ano pelo ERC 4337. No entanto, o número de contas de contrato inteligente implantadas ainda está longe de ser tão baixo quanto o EOA.

Vamos nos aprofundar nesse dilema:

1. O impacto de um mercado em baixa

Apesar das vantagens do AA, como login contínuo e abstração de gás, no atual mercado de baixa, onde todos os usuários são usuários EOA educados e não há muitos novos usuários, não há incentivo para dApps e carteiras adotarem SCA. Mesmo assim, alguns dos principais dApps estão adotando gradualmente AA, como o Cyberconnect, que gerou cerca de 360.000 transações UserOps (AA) em apenas um mês, introduzindo seu sistema AA e solução sem gás.

2. Barreiras migratórias

Para carteiras e aplicativos que já acumularam usuários e ativos, continua sendo um desafio migrar ativos de forma segura e conveniente. No entanto, um esquema como o EIP-7377 permite que a EOA inicie uma transação de migração única.

3. Problemas de assinatura

O contrato inteligente em si não pode assinar mensagens porque não tem uma chave privada como EOA. Tentativas como ERC1271 tornam isso possível, mas a assinatura de mensagens não funciona até a primeira transação, o que, por sua vez, representa um desafio para carteiras implantadas com contrafactuais. O ERC-6492, proposto pela Ambire, é o sucessor retrocompatível do ERC-1271 e pode ser capaz de resolver o problema anterior.

4. Custo do gás

O custo mais alto de implantação, simulação e execução do SCA em comparação com o EOA padrão também é uma barreira para a adoção. No entanto, alguns testes foram realizados, como separar a criação de conta das ações do usuário, eliminar o “sal” associado a uma conta e muito mais.

5. Problemas de engenharia

A equipe do ERC-4337 construiu um repositório de infinitismo étnico que fornece uma implementação básica para desenvolvedores. No entanto, à medida que os desenvolvedores escalam para recursos mais granulares e específicos para diferentes casos de uso, a integração e a decodificação enfrentam mais desafios. Neste artigo, vamos mergulhar nos desafios da engenharia.

Resolva desafios de engenharia com contas modulares de contratos inteligentes

Os desafios de engenharia podem ser desenvolvidos em três aspetos: fragmentação, segurança e capacidade de atualização.

· Fragmentação: Os recursos agora podem ser habilitados de várias maneiras, seja por meio de um SCA específico ou por meio de um sistema de plug-in autônomo. Cada plataforma e provedor de serviços segue seus próprios padrões, levando os desenvolvedores a decidir quais plataformas e provedores de serviços suportar. Isso pode levar a um possível bloqueio da plataforma (fornecedor) ou trabalho redundante.

· Segurança: Embora a dissociação de contas e funções traga o benefício da flexibilidade, também pode exacerbar as preocupações de segurança. Como todos os recursos podem ser revisados juntos, a falta de uma avaliação independente pode aumentar o risco de vulnerabilidades da conta.

· Capacidade de atualização: À medida que sua conta cresce, é importante manter a capacidade de adicionar, substituir ou remover recursos, e cada atualização que reimplanta recursos existentes introduz complexidade.

Para resolver esses problemas, precisamos de contratos atualizáveis para garantir atualizações seguras e eficientes, núcleos reutilizáveis para melhorar a eficiência geral do desenvolvimento e interfaces padronizadas para garantir uma transição suave entre diferentes frontends.

Estes termos convergem para um conceito comum: a construção de uma arquitetura modular de abstração de conta (Modular AA).

A abstração de conta modular é uma subdivisão do desenvolvimento AA mais amplo que prevê a modularização de contas inteligentes para fornecer serviços personalizados aos usuários e permitir que os desenvolvedores aprimorem perfeitamente a funcionalidade com restrições mínimas.

No entanto, estabelecer e promover novas normas em qualquer indústria é um enorme desafio. Até que todos aceitem a mesma norma, muitas soluções diferentes podem surgir na fase inicial. É encorajador ver que aqueles que trabalham para refinar e promover a abstração de contas, seja o SDK 4337, carteiras, equipes de infraestrutura ou designers de camada de protocolo, estão trabalhando juntos para acelerar esse processo.

Estrutura modular: contas mestras e módulos

Como a conta invoca o módulo para implementar a função

Chamada de representante e contrato de proxy

Convites externos e delegados:

Sobre chamadas de delegados

Embora uma “chamada delegada” seja semelhante a uma “chamada”, ela não é executada no contexto do contrato de destino, mas no contexto do estado atual do contrato de chamada. Isso significa que qualquer alteração de estado feita pelo contrato de destino alterará o armazenamento do contrato de chamada.

Contratos de proxy e chamadas de delegados

**Para conseguir uma estrutura componível e atualizável, é necessário introduzir um conceito básico de “contrato de agência”. **

Contrato de proxy: um contrato normal armazena sua lógica e seu estado, e não pode ser atualizado após a implantação. O contrato de proxy é implantado em outro contrato usando uma chamada de delegado. Implemente a função por referência para executá-la no estado atual do contrato de proxy.

Caso de uso: enquanto o contrato de proxy permanece o mesmo, você pode implantar uma nova implementação por trás do broker. Os contratos de proxy são atualizáveis e menos dispendiosos para implantar e manter em blockchains públicas.

Arquitetura segura

Seguro 架构

O QUE É SEGURO: O Safe é a principal infraestrutura modular de conta inteligente projetada para fornecer segurança e flexibilidade testadas em batalha, e permite que os desenvolvedores criem diversos aplicativos e carteiras. Muitas equipas estão a criar aplicações em cima (ou inspiradas) no Safe. Por exemplo, a Biconomy estendeu o Safe com 4337 nativo e 1/1 multisig quando lançou sua conta de contrato inteligente. Tendo testemunhado a implantação de mais de 164.000 contratos e bloqueado em mais de US $ 30,7 bilhões em valor, Safe é, sem dúvida, um líder em seu espaço.

A estrutura do Safe inclui um contrato de conta segura, um contrato singleton e um contrato de módulo. **

Contrato de procuração: Stateful

A conta segura é um contrato de proxy porque a chamada delegada é um contrato singleton. Uma conta de segurança contém variáveis em que o proprietário, o limite e o endereço de implementação são definidos como agentes, e seu estado é definido com base neles.

单例合约(contrato singleton):Integration Hub(无状态)

O contrato singleton serve contas seguras e define diferentes integrações de contrato de módulo, incluindo Plugin, Hook, Function Handler e Signature Validator.

Módulos: Lógica e Funções Personalizadas

Os contratos de módulo são poderosos. Plugins como tipos modulares podem definir diferentes funções, como fluxos de pagamento, mecanismos de recuperação e chaves de sessão, e podem atuar como uma ponte entre Web2 e Web3 buscando dados off-chain. Outros módulos, como ganchos e manipuladores de função como guardas de segurança, podem responder a qualquer comando.

Alterações após a adoção do Safe:

Contratos atualizáveis: Sempre que um novo plugin é introduzido, um novo singleton precisa ser implantado. O usuário mantém a autonomia para atualizar Safe para a versão singleton desejada.

Módulos componíveis e reutilizáveis: A natureza modular dos plugins permite que os desenvolvedores desenvolvam recursos de forma independente. Eles são livres para escolher e combinar esses plugins de acordo com seu caso de uso, resultando em uma abordagem altamente personalizável.

ERC-2535 Diamante 代理

Sobre ERC2535, Diamond Agent:

ERC2535 modelo Diamond padronizado, um sistema modular de contrato inteligente que pode ser atualizado/dimensionado após a implantação praticamente sem limitações de tamanho. Atualmente, muitas equipes, como o Kernel do Zerodev e os experimentos da Soul Wallet, foram inspirados pela estrutura do Diamante.

O que é a Estrutura Diamantada:**

Diamond Contract: Primary Proxy Contract (Stateful) Diamond é um contrato de proxy que usa um método de chamada de delegado para chamar uma função a partir de sua implementação.

Contrato de módulo/plugin/faceta: lógica e funcionalidade personalizadas (sem estado) Um módulo ou o chamado Facet é um contrato sem estado que pode implantar sua funcionalidade em um ou mais diamantes. São contratos separados e independentes que podem compartilhar funções intrínsecas, bibliotecas e variáveis de estado.

Alterações com Diamond:

Contratos atualizáveis: Diamond fornece uma maneira sistemática de isolar diferentes plugins e conectá-los, compartilhar dados entre eles e também adicionar/substituir/remover qualquer plugin diretamente usando o recurso diamondCut. Com o tempo, não haverá limite para o número de plugins que podem ser adicionados ao Diamond.

Plugins modulares e reutilizáveis: Os plugins implantados podem ser usados por qualquer número de Diamonds, reduzindo drasticamente os custos de implantação.

A diferença entre Safe e Diamond:

Há muitas semelhanças entre as arquiteturas Safe e Diamond, ambas baseadas em seus contratos de proxy principais e contratos lógicos de referência para capacidade de atualização e modularidade.

A principal diferença entre os dois é o tratamento de contratos lógicos. Mais especificamente:

· Flexibilidade: Com um novo plugin ativado, a Safe precisa reimplantar seu contrato singleton para implementar alterações em seu proxy. Em contraste, a Diamond consegue isso diretamente através da função diamondCut em seu contrato de procuração. A diferença na abordagem significa que o Safe mantém um maior grau de controle, enquanto o Diamond introduz maior flexibilidade e modularidade.

· Seguro: Atualmente usado em ambas as estruturas, permite que o código externo manipule o armazenamento do contrato principal. Na arquitetura Safe, as chamadas delegadas apontam para um único contrato lógico, enquanto o Diamond usa chamadas de representante em vários contratos-plug-ins de módulo. Como resultado, é possível que um plugin malicioso substitua outro plugin, introduzindo o risco de conflitos de armazenamento e comprometendo a integridade do proxy.

· Custo: Na abordagem Diamond, flexibilidade e segurança se unem. Isso aumenta o custo, e toda vez que um novo plugin é adicionado, ele precisa ser totalmente auditado. A chave é garantir que esses plugins não interfiram com a funcionalidade uns dos outros, um propósito que é desafiador, especialmente para pequenas e médias empresas que lutam para manter altos padrões de segurança.

O “Método de Conta Inteligente Segura” e o “Método Diamante” são exemplos de diferentes estruturas envolvendo agentes e módulos. Equilibrar flexibilidade e segurança é fundamental, e estas duas abordagens continuarão a evoluir e a complementar-se no futuro.

Ordem do módulo: Validador, Executor e Gancho

Vamos discutir isso mais adiante, apresentando ERC6900, um padrão inspirado em diamantes da equipe da Alchemy que é adaptado especificamente para o ERC-4337. Ele resolve os desafios da modularidade de conta inteligente, fornecendo uma interface comum e coordena o trabalho entre desenvolvedores de plugins e carteiras.

Quando se trata do processo de transação de AA, existem três processos principais: validação, execução e pegging. Como discutimos anteriormente, todas essas etapas podem ser gerenciadas usando o módulo de chamada de conta proxy. Embora projetos diferentes possam usar nomes diferentes, é importante compreender a lógica subjacente da semelhança.

Nomes de funções em designs diferentes

Validador: Garante a autenticidade e as permissões do chamador da conta.

Execução (UTOR): Execute qualquer lógica personalizada que a conta permita.

Gancho: Atua como um módulo que é executado antes ou depois de outra função. Ele pode modificar o estado ou desfazer toda a chamada.

É importante separar os módulos de acordo com lógicas diferentes. A abordagem padronizada deve especificar como escrever funções de validação, execução e indexação para contas de contrato inteligente. Seja seguro ou ERC6900, a padronização ajuda a reduzir a necessidade de esforços de desenvolvimento exclusivos específicos para determinadas implementações ou ecossistemas e evita a dependência do fornecedor.

Descoberta de módulos e segurança

Como encontrar e validar módulos de forma aberta: Uma solução que está sendo desenvolvida envolve a criação de uma área que permite aos usuários descobrir módulos verificáveis, que podem ser chamados de “registro”. O registro funciona como uma “loja de aplicativos” e visa promover um mercado modular simplificado, mas próspero.

Seguro{Core} 协议

O protocolo Safe{Core} é um protocolo de código aberto e interoperável para contas de contratos inteligentes projetado para melhorar a acessibilidade para uma ampla gama de fornecedores e desenvolvedores, mantendo uma forte segurança por meio de padrões e regras bem definidos.

· Contas: No protocolo Safe{Core}, o conceito de contas é flexível e não está vinculado a uma implementação específica. Isso permite que diferentes provedores de serviços de conta se envolvam.

· Gerente: O gerente atua como coordenador entre contas, registros e módulos. Ele também cuida da segurança como uma camada de licenciamento.

· Registro: O registro define atributos de segurança e impõe padrões de módulo, como ERC6900 para criar um ambiente aberto de “loja de aplicativos” para descoberta e segurança.

· Módulos: Os módulos lidam com a funcionalidade e têm uma variedade de tipos iniciais, incluindo plugins, ganchos, validadores de assinatura e manipuladores de funções. Os desenvolvedores podem participar, desde que atendam aos critérios estabelecidos.

Strass 设计

O processo desenrola-se da seguinte forma:

· Criar um esquema: um esquema fornece uma estrutura de dados predefinida. As pessoas podem adaptá-lo para se adequar ao seu caso de uso específico.

· Criar módulos com base no esquema: O contrato inteligente registrado como um módulo obtém o bytecode e seleciona a ID do esquema, e os dados são armazenados no registro.

· Obter atestado do módulo: O provador/auditor pode fornecer prova do módulo com base na arquitetura. Esses atestados podem incluir um identificador exclusivo (UID) e referências a outros atestados usados para o link. Eles podem se propagar entre cadeias e verificar se a cadeia de destino atende a determinados limites.

· Implementar lógica complexa com um resolvedor: O analisador (opcional) entra em ação. Eles podem ser chamados durante a criação do módulo, estabelecimento de atestado e revogação. Esses analisadores permitem que os desenvolvedores integrem lógicas complexas e diversas, mantendo estruturas de prova.

Acesso de consulta amigável: a consulta fornece uma maneira para os usuários acessarem informações de segurança a partir do front-end.

Embora o modelo ainda esteja em seus estágios iniciais, ele tem o potencial de estabelecer padrões de forma descentralizada e colaborativa. O registro permite que os desenvolvedores registrem seus módulos, auditores verifiquem sua segurança, carteiras se integrem e permite que os usuários encontrem facilmente módulos e verifiquem suas informações de atestado. Várias utilizações futuras poderão ser:

· Attestor: Uma entidade confiável como a Safe pode trabalhar com a Rhinestone como um provador para módulos internos. Ao mesmo tempo, também podem aderir certificadores independentes.

· Desenvolvedor de módulos: Com a formação de um mercado aberto, é possível que os desenvolvedores de módulos monetizem seu trabalho através de um registro.

· Usuários: Participar através de uma interface amigável, como uma carteira ou dApp, permite que os usuários verifiquem as informações do módulo e deleguem confiança a diferentes provadores.

O conceito de um “registro de módulo” abre caminhos para os desenvolvedores de plugins e módulos monetizarem. Poderia ainda abrir caminho a um “mercado de módulos”. Alguns aspetos podem ser supervisionados pela equipe Safe, enquanto outros podem se manifestar como um mercado descentralizado que convida todos a contribuir e fornece uma trilha de auditoria transparente. A incorporação disso evita a dependência do fornecedor e apoia a expansão do EVM, adicionando uma experiência de usuário aprimorada que atrai um público mais amplo.

Embora esses métodos garantam a segurança de módulos individuais, as contas de contratos inteligentes não são infalíveis quando se trata de segurança mais ampla. Pode ser um desafio combinar com módulos de conformidade e provar que eles não têm conflitos de armazenamento, o que destaca a importância das carteiras ou da infraestrutura AA na abordagem desses problemas.

Resumo

Ao alavancar uma pilha de contas de contrato inteligente modular, os provedores de carteira e dApps podem ser liberados das complexidades da manutenção técnica. Ao mesmo tempo, os desenvolvedores de módulos externos têm a oportunidade de fornecer serviços profissionais personalizados. No entanto, os desafios que precisam ser enfrentados incluem encontrar um equilíbrio entre flexibilidade e segurança, pressionar por padrões modulares e implementar interfaces padronizadas que permitam aos usuários atualizar e modificar facilmente suas contas inteligentes.

Além disso, as Contas de Contrato Inteligente Modulares (SCAs) são apenas uma pequena parte do quebra-cabeça de adoção. Para realizar todo o potencial do SCA, as soluções de Camada 2 são necessárias para fornecer suporte adicional à camada de protocolo, como infraestrutura robusta de empacotadores e pools de memória ponto a ponto, um mecanismo de assinatura SCA mais econômico e viável, mecanismos de sincronização e gerenciamento de SCA entre cadeias e o desenvolvimento de interfaces amigáveis.

No futuro, haverá mais adoção do SCA, mas também levantará algumas questões interessantes: como os mecanismos tradicionais de valor extraível de minerador (MEV) entrarão no espaço para construir empacotadores e capturar valor quando o fluxo de ordens SCA se tornar lucrativo o suficiente, e como a abstração de conta (AA) servirá como camada base para transações “baseadas em intenção” quando a infraestrutura amadurecer?