Modularização de conta de contrato inteligente: resolvendo o problema de difícil implementação e tornando possível a adoção em larga escala da Web3

Escrito por: Rui S (SevenX Ventures)

Compilado por: Deep Wave TechFlow

introduzir

A mudança de contas de propriedade externa (EOA) para contas de contrato inteligentes (SCAs) está crescendo e é apoiada por muitos entusiastas, incluindo o próprio Vitalik. Apesar do entusiasmo, a adopção da SCA não foi tão difundida como a EOA. As principais questões incluem desafios de mercado em baixa, preocupações com migração, problemas de assinatura, despesas gerais de gás e, mais importante, desafios de engenharia.

Uma das vantagens mais importantes da Abstração de Conta (AA) é a capacidade de personalizar a funcionalidade usando código. No entanto, um grande desafio de engenharia é a não interoperabilidade da funcionalidade AA, e esta fragmentação dificulta a integração e abre a porta ao aprisionamento do fornecedor. Além disso, garantir a segurança ao atualizar e combinar recursos simultaneamente pode ser complexo.

A abstração de contas modulares surgiu como um subconjunto do movimento mais amplo de AA, uma abordagem inovadora para dissociar contas inteligentes de sua funcionalidade personalizada. O objetivo é criar uma estrutura modular para desenvolver carteiras seguras e perfeitamente integradas com diversas funcionalidades. No futuro, ele pode implementar uma “loja de aplicativos” de conta de contrato inteligente gratuita para que carteiras e dApps não se concentrem mais na construção de funções, mas na experiência do usuário.

Breve descrição do AA

A EOA tradicional apresenta muitos desafios, como frases iniciais, gás, cadeia cruzada e transações múltiplas. Nunca pretendemos introduzir complexidade, mas a realidade é que o blockchain não é um jogo fácil para as massas.

A abstração de contas aproveita contas de contratos inteligentes, permitindo verificação e execução programáveis, permitindo que os usuários aprovem uma série de transações de uma só vez, em vez de ter que assinar e transmitir cada transação, e habilitar mais funcionalidades. Traz benefícios para a experiência do usuário (por exemplo, abstração de gás e chaves de sessão), custo (por exemplo, transações em lote) e segurança (por exemplo, recuperação social, assinatura múltipla). Atualmente, existem duas maneiras de implementar a abstração de contas:

• Camada de protocolo: Alguns protocolos fornecem suporte de abstração de conta local. As transações ZKsync, sejam de EOA ou SCA, seguem o mesmo processo, usando um único pool de memória e processo de transação para suportar AA, que Starknet removeu EOA, todos as contas são SCA e possuem carteiras de contratos inteligentes nativas, como Argent.
• Camada de contrato: Para Ethereum e seu equivalente L2, o ERC4337 introduz uma entrada de transação separada para suportar AA sem alterar a camada de consenso. Projetos como Stackup, Alchemy, Etherspot, Biconomy, Candide e Plimico estão construindo infraestrutura de empacotadores, enquanto projetos como Safe, Zerodev, Etherspot e Biconomy estão construindo pilhas e SDKs.

Dilemas da adoção do SCA

O tema da Abstração de Contas (AA) é discutido desde 2015 e ganhou destaque este ano pelo ERC4337. No entanto, o número de contas de contratos inteligentes implementadas ainda é muito menor do que o da EOA.

Vamos nos aprofundar neste dilema:

Impacto do mercado baixista:

Embora AA tenha introduzido benefícios como login contínuo e abstração de Gas, as pessoas que atualmente vivenciam o mercado baixista são compostas principalmente de usuários EOA instruídos, em vez de novos usuários, portanto, não há incentivo para dApps e carteiras. Mesmo assim, alguns aplicativos líderes ainda estão adotando gradualmente AA, como o Cyberconnect, que gerou cerca de 360.000 UserOps (transações AA) em apenas um mês ao apresentar seu sistema AA e solução Gas-free.

Barreiras à migração:

Para carteiras e aplicações que acumularam usuários e ativos, a migração segura e conveniente de ativos continua sendo um desafio. No entanto, iniciativas como a EIP-7377 permitem que as EOAs iniciem transações de migração únicas.

Problema de assinatura:

O contrato inteligente em si não pode assinar mensagens naturalmente porque não possui uma chave privada como o EOA. Esforços como o ERC1271 tornam essa assinatura possível, mas a assinatura de mensagens não funciona até a primeira transação, o que representa um desafio para carteiras que usam implantações contrafactuais. O ERC-6492 proposto pela Ambire é um sucessor compatível com versões anteriores do ERC-1271 e pode resolver os problemas anteriores.

Despesas gerais de gás:

A implantação, simulação e execução do SCA incorrem em custos mais elevados do que o EOA padrão. Isso se torna uma barreira para a adoção. No entanto, foram realizados alguns testes, como dissociar a criação de contas das ações do usuário e considerar a eliminação de salts de contas e verificações de existência, para reduzir esses custos.

Dificuldades de engenharia:

A equipe ERC-4337 estabeleceu o repositório eth-infinitiism para fornecer aos desenvolvedores implementações básicas. No entanto, à medida que avançamos para funcionalidades mais granulares ou específicas em diferentes casos de uso, a integração e a decodificação tornam-se desafiadoras.

Neste artigo, nos aprofundaremos na quinta questão: desafios de engenharia.

Contas modulares de contratos inteligentes para resolver desafios de engenharia

Uma explicação adicional dos desafios de engenharia é a seguinte:

• Fragmentação: Vários recursos agora são habilitados de diferentes maneiras, seja por meio de SCAs específicos ou sistemas de plug-ins independentes. Cada um segue seus próprios padrões, forçando os desenvolvedores a decidir quais plataformas oferecer suporte. Isto pode levar ao aprisionamento da plataforma ou à duplicação de esforços.
• Segurança: embora a flexibilidade entre contas e recursos traga vantagens, ela também pode agravar as preocupações de segurança. Os recursos podem ser auditados coletivamente, mas a falta de avaliação independente pode aumentar o risco de violações de contas.
• Capacidade de atualização: À medida que a funcionalidade evolui, é importante manter a capacidade de adicionar, substituir ou remover funcionalidades. A reimplantação da funcionalidade existente a cada atualização introduz complexidade.

Para lidar com 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 que as contas dos contratos possam fazer uma transição suave entre diferentes front-ends.

Esses termos convergem para um conceito comum: construir uma arquitetura modular de abstração de contas (Modular AA).

AA modular é um nicho dentro do movimento mais amplo de AA que prevê a modularização de contas inteligentes para adaptar serviços aos usuários e permitir que os desenvolvedores aprimorem a funcionalidade de maneira integrada com restrições mínimas.

No entanto, estabelecer e promover novos padrões é um enorme desafio em qualquer indústria. Muitas soluções diferentes podem surgir nos estágios iniciais, antes que todos aceitem a solução principal. No entanto, é encorajador que tanto o SDK 4337, os desenvolvedores de carteiras, as equipes de infraestrutura e os designers de protocolo estejam trabalhando juntos para acelerar esse processo.

Estrutura modular: conta principal e módulos

Chamada de delegação e contrato de agência

Chamadas externas e chamadas de delegado:

Embora delegadocall seja semelhante a call, em vez de executar o contrato de destino em seu próprio contexto, ele executa o contrato de destino no estado atual do contrato de chamada. Isto significa que quaisquer alterações de estado feitas pelo contrato de destino serão aplicadas ao armazenamento do contrato de chamada.

Para implementar estruturas combináveis e atualizáveis, é necessário um conhecimento básico denominado “contratos de agência”.

1. Contrato de agente: Contratos comuns armazenam sua lógica e status e não podem ser atualizados após a implantação. Um contrato de procuração usa um delegado para chamar outro contrato. Implemente uma função por referência, que seja executada no estado atual do contrato do agente.
2. Caso de uso: Embora o contrato de proxy permaneça o mesmo, você pode implantar novas implementações por trás do proxy. Os contratos proxy são usados para atualização e são mais baratos para implantar e manter em blockchains públicos.

Arquitetura de segurança

Safe é uma infraestrutura de conta inteligente modular líder, projetada para fornecer segurança e flexibilidade comprovadas em batalha, permitindo que os desenvolvedores criem diversos aplicativos e carteiras. É importante notar que muitas equipes estão construindo com base ou inspiradas no Safe. Biconomy lança sua conta estendendo 4337 nativo e assinatura múltipla 1/1 no Safe. Com mais de 164.000 contratos implantados e mais de US$ 30,7 bilhões em valor bloqueado, a Safe é sem dúvida a melhor escolha neste espaço.

Estrutura segura

Contrato de Conta Segura: Contrato de Agente Principal (Stateful)

A conta segura é um contrato proxy porque delega chamadas de contrato singleton. A conta Safe contém o proprietário, o limite e o endereço de implementação, que são definidos como variáveis para o agente, definindo assim o seu estado.

Contrato de instância única: Centro de integração (sem estado)

O singleton atende a conta Safe e integra e define diferentes integrações, incluindo plug-ins, ganchos, manipuladores de funções e validadores de assinatura.

Contrato de Módulo: Lógica e Funções Personalizadas

Os módulos são muito poderosos. Sendo um tipo modular, os plug-ins podem definir diferentes funções, como fluxos de pagamento, mecanismos de recuperação e chaves de sessão, e servir como uma ponte cruzada entre Web2 e Web3, obtendo dados fora da cadeia. Outros módulos, como Hooks, atuam como proteções de segurança e manipuladores de funções respondem a quaisquer instruções.

O que acontece quando adotamos o Safe

Contrato atualizável:

Sempre que um novo plugin é introduzido, um novo singleton precisa ser implantado. Os usuários mantêm a autonomia para atualizar o Safe para a versão singleton desejada para atender às suas preferências e requisitos.

Módulos Combináveis e Reutilizáveis:

A natureza modular dos plug-ins permite que os desenvolvedores criem funcionalidades de forma independente. Eles ficam então livres para selecionar e combinar esses plug-ins de acordo com seus próprios casos de uso, facilitando uma abordagem altamente personalizável.

Agente Diamante ERC-2535

Sobre ERC2535 e Agente Diamante

O ERC2535 padroniza o Diamond Agent, um sistema modular de contrato inteligente que pode ser atualizado/expandido após a implantação e praticamente não tem limitações de tamanho. Até agora, muitas equipes foram inspiradas nele, como o Kernel da Zerodev e os experimentos da Soul Wallet.

Qual é a estrutura Diamante

1. Contrato Diamond: Contrato de Agente Principal (Stateful) Diamond é um contrato proxy que chama funções desde sua implementação através de chamadas delegadas.
2. Módulo/plug-in/contrato facetado: Lógica e funcionalidade personalizadas (sem estado) Um módulo ou a chamada faceta é um contrato sem estado que pode implantar sua funcionalidade em um ou mais Diamonds. São contratos independentes que podem compartilhar funções internas, bibliotecas e variáveis de estado.

O que acontece quando adotamos Diamond

1. Contratos atualizáveis: Diamond fornece uma maneira sistemática de isolar diferentes plug-ins e conectá-los, e adicionar/substituir/remover diretamente qualquer plug-in por meio da função DiamondCut. Não há limite para o número de plug-ins que podem ser adicionados ao Diamond ao longo do tempo.
2. Plug-ins modulares e reutilizáveis: Um plug-in implantado pode ser usado por qualquer número de Diamonds, reduzindo bastante os custos de implantação.

Diferença entre Conta Inteligente Segura e Método Diamante

Existem muitas semelhanças entre as arquiteturas Safe e Diamond, com ambas contando com contratos de proxy como núcleo e referenciando contratos lógicos para capacidade de atualização e modularidade.

Porém, a principal diferença está no tratamento dos contratos lógicos. Aqui estão instruções mais detalhadas:

1. Flexibilidade: Com novos plug-ins habilitados, o Safe precisa reimplantar seu contrato singleton para implementar mudanças em seu agente. Em contraste, Diamond faz isso diretamente através da função diamanteCut em seu delegado. Esta diferença na abordagem significa que o Safe mantém um maior grau de controle, enquanto o Diamond introduz maior flexibilidade e modularidade.
2. Segurança: Atualmente, o delegadocall é utilizado em ambas as estruturas, o que permite que código externo manipule o armazenamento do contrato principal. Na arquitetura Safe, delegado aponta para um único contrato lógico, enquanto Diamond usa delegado entre vários contratos de módulos (plug-ins). Portanto, é possível que um plug-in malicioso substitua outro plug-in, introduzindo assim o risco de conflitos de armazenamento que podem comprometer a integridade do agente.
3. **Custo:**A flexibilidade inerente à abordagem Diamond traz consigo maiores preocupações de segurança. Isso adiciona um fator de custo e requer uma auditoria completa sempre que um novo plugin é adicionado. O segredo é garantir que esses plug-ins não interfiram nas funcionalidades uns dos outros, o que pode ser um desafio para pequenas e médias empresas que tentam manter padrões de segurança rígidos.

O “Método Safe Smart Account” e o “Método Diamante” são exemplos de diferentes estruturas envolvendo agentes e módulos. É fundamental equilibrar flexibilidade e segurança, e é provável que as duas abordagens se complementem no futuro.

Ordem do módulo: validador, executor e Hook

Vamos expandir nossa discussão apresentando o padrão proposto pela equipe da Alchemy, ERC6900, que foi inspirado no Diamond e adaptado especificamente para o ERC-4337. Ele resolve o desafio da modularidade em contas inteligentes, fornecendo uma interface comum e coordenando o trabalho entre desenvolvedores de plugins e carteiras.

Quando se trata do processo de transação de AA, existem três processos principais: Verificação, Execução e Gancho. Conforme discutimos anteriormente, essas etapas podem ser gerenciadas chamando o módulo usando uma conta proxy. Embora projetos diferentes possam usar nomes diferentes, é importante capturar uma lógica subjacente semelhante.

• Verificação: Garanta a autenticidade e autoridade do chamador sobre a conta.
• Execução: Execute qualquer lógica personalizada permitida pela conta.
• Hook: Como um módulo executado antes ou depois de outra função. Ele pode modificar o estado ou fazer com que toda a chamada seja desfeita.

Separar módulos com base em lógicas diferentes é crucial. Uma abordagem padronizada deve especificar como a verificação, execução e funções de gancho de conta de contrato inteligente devem ser escritas. Seja Safe ou ERC6900, a padronização ajuda a reduzir a necessidade de esforços de desenvolvimento exclusivos para uma implementação ou ecossistema específico e evita a dependência de fornecedores.

Descoberta e segurança do módulo

Uma solução que está crescendo envolve a criação de um local que permita aos usuários descobrir módulos verificáveis, o que poderíamos chamar de “registro”. Este registro é semelhante a uma “loja de aplicativos” projetada para facilitar um mercado modular simplificado, mas próspero.

Protocolo{Principal}Seguro

O protocolo Safe{Core} é um protocolo de conta de contrato inteligente interoperável e de código aberto, projetado para aumentar a acessibilidade para uma variedade de fornecedores e desenvolvedores por meio de padrões e regras claramente definidos, ao mesmo tempo em que mantém uma segurança forte.

1. Conta: No protocolo Safe{Core}, o conceito de conta é flexível e não restrito a uma implementação específica. Isso permite que vários provedores de serviços de conta participem.
2. **Gerente: **O gerente atua como coordenador entre contas, cadastros e módulos. Também é responsável pela segurança, atuando como camada de permissões.
3. Registro: O registro define atributos de segurança e aplica padrões de módulos como ERC6900, com o objetivo de criar um ambiente de “loja de aplicativos” aberto para descoberta e segurança.
4. **Módulos: **Os módulos controlam a funcionalidade e são fornecidos em vários tipos iniciais, incluindo plug-ins, ganchos, verificadores de assinatura e manipuladores de funções. Os desenvolvedores podem contribuir com isso, desde que atendam aos padrões estabelecidos.

Design de strass

O processo se desenrola da seguinte forma:

• Criar definição de esquema: Os esquemas servem como estruturas de dados predefinidas para uso em provas. As empresas podem personalizar o padrão com base em seus casos de uso específicos.
• Criando um módulo baseado em um padrão: O contrato inteligente é registrado como um módulo, obtém o bytecode e seleciona o ID do padrão. Esses dados são então armazenados no registro.
• Obter a prova de um módulo: Um provador/auditor pode fornecer provas para um módulo com base no esquema. Esses certificados podem incluir identificadores exclusivos (UIDs) e referências a outros certificados para vinculação. Eles podem ser propagados na cadeia e verificar se certos limites são atendidos na cadeia alvo.
• **Use analisadores para implementar lógica complexa: **Os analisadores são opcionalmente definidos em padrões. Eles podem ser chamados durante a criação do módulo, estabelecimento de provas e desmontagem. Esses analisadores permitem que os desenvolvedores incorporem lógica complexa e diversificada, mantendo a estrutura da prova.
• **Acesso de consulta fácil de usar: **As consultas fornecem uma maneira para os usuários acessarem informações seguras no front-end. O EIP pode ser encontrado aqui.

Embora este modelo ainda esteja em seus estágios iniciais, ele tem potencial para estabelecer um padrão de forma descentralizada e colaborativa. Seu registro permite que os desenvolvedores registrem seus módulos, os auditores verifiquem sua segurança, as carteiras integrem e os usuários encontrem facilmente os módulos e verifiquem suas informações de atestado. Pode haver os seguintes usos no futuro:

• **Certificadores: **Entidades confiáveis, como Safe, podem trabalhar com Rhinestone como certificadores para módulos internos. Ao mesmo tempo, provadores independentes também podem participar.
• **Desenvolvedores de Módulos: **Com a formação de um mercado aberto, é possível que desenvolvedores de módulos comercializem seu trabalho por meio de um cadastro.
• Usuários: Por meio de interfaces fáceis de usar, como carteiras ou dApps, os usuários podem visualizar informações do módulo e delegar confiança a diferentes provadores.

O conceito de “registro de módulo” oferece oportunidades lucrativas para desenvolvedores de plug-ins e módulos. Também poderia abrir caminho para um “mercado de módulos”. Alguns destes aspectos podem ser supervisionados pela equipa Safe, enquanto outros podem manifestar-se como mercados descentralizados que convidam todos a contribuir e fornecem uma pista de auditoria transparente. Ao adotar essa abordagem, podemos evitar a dependência de fornecedores e apoiar a expansão do EVM, proporcionando uma melhor experiência de usuário que atrai um público mais amplo.

Embora estes métodos garantam a segurança de módulos individuais, a segurança geral das contas de contratos inteligentes não é absolutamente confiável. Combinar módulos legítimos e provar que eles não possuem conflitos de armazenamento pode ser um desafio, enfatizando a importância das carteiras ou da infraestrutura AA na resolução de tais problemas.

Resumir

Ao aproveitar uma pilha modular de contas de contratos inteligentes, os provedores de carteiras e dApps podem escapar da complexidade da manutenção técnica. Ao mesmo tempo, os desenvolvedores de módulos externos têm a oportunidade de fornecer serviços profissionais adaptados às necessidades individuais. No entanto, os desafios que precisam de ser abordados incluem encontrar um equilíbrio entre flexibilidade e segurança, impulsionar o avanço de padrões modulares e implementar interfaces padronizadas que permitam aos utilizadores atualizar e modificar facilmente as suas Contas Inteligentes.

No entanto, as contas modulares de contratos inteligentes (SCA) são apenas uma peça do quebra-cabeça da adoção. Para concretizar plenamente o potencial do SCA, também é necessário suporte à camada de protocolo de soluções de segunda camada, bem como uma infra-estrutura de empacotamento poderosa e pools de memória ponto a ponto, mecanismos de assinatura SCA mais econômicos e viáveis, sincronização SCA entre cadeias e gerenciamento, além de desenvolver interfaces fáceis de usar.

Prevemos um futuro com ampla participação, o que levanta algumas questões interessantes: Uma vez que o processo de encomenda da SCA se torne suficientemente rentável, como é que os mecanismos tradicionais de valor extraível dos mineiros (MEV) entrarão no espaço, construirão empacotadores e capturarão valor? Quando a infraestrutura amadurecer, como a Abstração de Conta (AA) pode se tornar a camada base para transações “baseadas em intenção”? Fique atento, pois esta área está em constante evolução.