*Nota do editor: As Contas de Contrato Inteligente (SCAs) estão ganhando força e são apoiadas por muitos empreendedores principais, incluindo a Vitalik, mas ainda há muitos desafios para a adoção da SCA. A abstração de conta (AA) tem a vantagem de usar a personalização de código, mas sua não interoperabilidade introduz problemas de integração e bloqueio do fornecedor. A abstração modular de contas visa criar uma estrutura modular para desenvolver carteiras versáteis, seguras e perfeitamente integradas. *
Rui, um investidor da SevenX Ventures >, identificou os cinco principais desafios para a adoção da SCA – impacto no mercado, dificuldade de migração, problemas de assinatura, altos custos de gás e desafios de engenharia – e discutiu-os mais adiante. Além disso, uma análise da arquitetura de contas de contratos inteligentes modulares aponta que o SCA modular é apenas uma pequena parte dos desafios de adoção.
Para realizar todo o potencial da SCA, as soluções de camada 2 são necessárias para fornecer suporte adicional à camada de protocolo, infraestrutura robusta de empacotadores e pools de memória ponto a ponto, um mecanismo de assinatura SCA mais econômico e viável, sincronização e gerenciamento de SCA entre cadeias e desenvolvimento de interfaces amigáveis.
O que acontecerá a seguir no futuro, à medida que os desafios atuais forem resolvidos e mais pessoas adotarem a SCA? Rui também faz algumas perguntas interessantes. BlockBeats compilou o texto original da seguinte forma:
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.
Breve Abstração de Conta (AA)
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
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 suporte nativo à abstração de contas, as transações ZKSync usam um único mempool e o 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 de contratos inteligentes nativas como a 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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Vamos nos aprofundar nesse dilema:
O impacto do bear market
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.
Obstáculos à migração
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.
Questões relativas à 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.
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.
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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
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 tornar os problemas de segurança mais sérios. 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
Delegar chamada e contrato de proxy
Convites externos e delegados:
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Contratos de proxy e chamadas delegadas
**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! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Arquitetura segura
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 da Safe inclui um contrato de conta segura, um contrato singleton e um contrato de módulo.
Contrato por 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.
单例合约(singleton contract):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 funcionalidade 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.
As mudanças que mudaram desde 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 代理
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
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 invocação 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.
Diferença entre a Conta Inteligente Segura e o método 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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
O nome da função em diferentes designs
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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
É 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 e segurança de módulos
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.
Safe{Core} 协议
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
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 设计
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
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?
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Uma visão aprofundada das arquiteturas e desafios modulares das contas de contratos inteligentes
作者:Rui,Investidor da SevenX Ventures
编译:Luccy,Joyce,BlockBeats
Rui, um investidor da SevenX Ventures >, identificou os cinco principais desafios para a adoção da SCA – impacto no mercado, dificuldade de migração, problemas de assinatura, altos custos de gás e desafios de engenharia – e discutiu-os mais adiante. Além disso, uma análise da arquitetura de contas de contratos inteligentes modulares aponta que o SCA modular é apenas uma pequena parte dos desafios de adoção.
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.
Breve Abstração de Conta (AA)
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-e77dfd1eb3-dd1a6f-cd5cc0.webp)
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 suporte nativo à abstração de contas, as transações ZKSync usam um único mempool e o 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 de contratos inteligentes nativas como a 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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-cd53d3972e-dd1a6f-cd5cc0.webp)
Vamos nos aprofundar nesse dilema:
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.
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.
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.
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.
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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b50e21334e-dd1a6f-cd5cc0.webp)
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 tornar os problemas de segurança mais sérios. 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
Delegar chamada e contrato de proxy
Convites externos e delegados:
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-26b1e8ab3b-dd1a6f-cd5cc0.webp)
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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-421fd8f0e1-dd1a6f-cd5cc0.webp)
Contratos de proxy e chamadas delegadas
**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! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4dc82c32d1-dd1a6f-cd5cc0.webp)
Arquitetura segura
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 da Safe inclui um contrato de conta segura, um contrato singleton e um contrato de módulo.
Contrato por 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.
单例合约(singleton contract):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 funcionalidade 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.
As mudanças que mudaram desde 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 代理
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-dfa51cc0ce-dd1a6f-cd5cc0.webp)
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 invocação 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.
Diferença entre a Conta Inteligente Segura e o método 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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-b01f250655-dd1a6f-cd5cc0.webp)
O nome da função em diferentes designs
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.
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-42db1d92a0-dd1a6f-cd5cc0.webp)
É 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 e segurança de módulos
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.
Safe{Core} 协议
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-4ff8171cf4-dd1a6f-cd5cc0.webp)
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 设计
! [Uma análise aprofundada da arquitetura e dos desafios da conta de contratos inteligentes modulares] (https://img-cdn.gateio.im/webp-social/moments-69a80767fe-96de12199c-dd1a6f-cd5cc0.webp)
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?