Arquitetura e desafios da conta de contrato inteligente modular

Introdução

A mudança de contas de propriedade externa (EOA) para contas de contrato inteligentes (SCA) está ganhando força e foi adotada por muitos entusiastas, incluindo o próprio Vitalik. Apesar do entusiasmo, a adopção da SCA não é tão difundida como as EOAs. Os principais entre eles são os desafios colocados pelos mercados em baixa, a preocupação com a migração, as questões de sinalização, as despesas gerais de gás e, o mais importante, as dificuldades de engenharia.

A vantagem mais significativa das Abstrações de Conta (AA) é a capacidade de usar código para personalizar a funcionalidade. No entanto, um grande desafio de engenharia é a não interoperabilidade das funcionalidades AA, e a fragmentação dificulta a integração e abre a porta ao aprisionamento do fornecedor. Além disso, garantir a segurança e ao mesmo tempo atualizar e compor recursos pode ser complicado.

Entre na Abstração de Conta Modular, como um subconjunto do movimento mais amplo de AA, esta abordagem inovadora pode separar contas inteligentes de suas funções personalizadas. O objetivo é criar uma estrutura modular para desenvolver carteiras seguras e perfeitamente integradas com diversas funcionalidades. No futuro, ele poderá criar uma “loja de aplicativos” gratuita para contas de contratos inteligentes que libere carteiras e dApps de recursos de construção, mas com foco na experiência do usuário.

Depois de ler este artigo, os leitores obterão insights sobre:

1. O que é abstração de conta modular
2. Como a conta interage com os módulos
3. Qual é a sequência de chamada dos módulos
4. Como encontrar e verificar módulos de forma aberta

Uma breve revisão de AA

Paisagem SCA

O EOA tradicional apresenta muitos desafios, como frase inicial, gás, cadeia cruzada e transações múltiplas. Nunca pretendemos introduzir complexidade, mas, na verdade, o blockchain não é um jogo fácil para as massas.

A Abstração de Conta aproveita a conta de contrato inteligente, permitindo validação e execução programáveis, onde o usuário é capaz de aprovar uma série de transações de uma só vez, em vez de assinar e transmitir cada uma, e implementar muitos outros recursos. Ele apresenta benefícios à experiência do usuário (por exemplo. abstração de gás e chaves de sessão), custo (por exemplo. transação em lote) e segurança (por exemplo. recuperação social, multi-sig). Atualmente, existem duas maneiras de conseguir a abstração de contas:

1. Camada de protocolo: alguns protocolos fornecem suporte nativo à abstração de conta, as transações ZKsync seguem o mesmo fluxo, sejam originadas de EOA ou SCA, que usa um único mempool e fluxo de transação para suportar AA, e Starknet removeu EOA e todas as contas são SCA, e elas têm carteiras de contratos inteligentes nativas como Argent.
2. Camada de contrato: Para Ethereum e seus L2s equivalentes, o ERC4337 introduz um ponto de entrada separado para transações para suportar AA sem alterar a camada de consenso. Projetos como Stackup, Alchemy, Etherspot, Biconomy, Candide e Plimico estão construindo infraestrutura de bundler, e muitos outros como Safe, Zerodev, Etherspot e Biconomy estão construindo pilha e SDK.

👉 Se você não está familiarizado com AA ou ERC4337, verifique as pesquisas anteriores da SevenX aqui.

O dilema da adoção do SCA

O tema da Abstração de Contas (AA) está em discussão desde 2015 e foi ainda mais destacado pelo ERC4337 este ano. No entanto, o número de contas de contratos inteligentes implementadas ainda é insignificante em comparação com as EOAs.

Vamos nos aprofundar neste dilema:

1. Impacto no mercado baixista:
   Embora o AA introduza benefícios como login contínuo e abstração de gás, o mercado baixista predominante consiste principalmente de usuários EOA instruídos, em vez de novos, portanto, não há incentivo para dApps e carteiras. Mesmo dizendo isso, os principais aplicativos ainda estão no caminho de adotar AA, como o Cyberconnect , que gerou cerca de 360.000 UserOps (transações de AA) por mês, introduzindo seu sistema AA e solução sem gás.
2. Obstáculos à migração:
   Para carteiras e aplicações que acumularam usuários e armazenaram ativos em EOAs, a migração segura e conveniente de ativos continua sendo um desafio. No entanto, iniciativas como a EIP-7377 permitem que as EOAs iniciem uma transação de migração única.
3. Problema de assinatura:
   O contrato inteligente em si naturalmente não pode assinar mensagens, uma vez que não possui uma chave privada como os EOAs. Esforços como o ERC1271 tornam isso possível, mas a assinatura da mensagem não funcionará até a primeira transação, o que representa um desafio para carteiras que usam implantação contrafactual. E o ERC-6492 proposto pela Ambire é um sucessor compatível com versões anteriores do ERC-1271 que potencialmente resolve o problema anterior.
4. Despesas gerais de gás:
   A implantação, simulação e execução de SCAs incorrem em custos mais elevados em comparação com EOAs padrão. Isso se torna um impedimento para a adoção. No entanto, vários testes foram realizados, como dissociar a criação de contas das operações do usuário, e a eliminação do sal da conta e as verificações de existência estão sendo consideradas para reduzir esses custos.
5. Dificuldades de engenharia:
   A equipe ERC-4337 criou o repositório eth-infinitism para fornecer aos desenvolvedores uma implementação básica. No entanto, à medida que avançamos para funções mais diferenciadas ou específicas para diferentes casos de uso, a integração e a decodificação tornam-se desafiadoras.

Neste artigo, mergulharemos no problema nº 5: as dificuldades de engenharia.

🤔️

Conta modular de contrato inteligente para resolver dificuldades de engenharia

Para elaborar mais sobre as dificuldades de engenharia:

1. Fragmentação:
   Os recursos agora são habilitados de diversas maneiras, seja nativamente por SCAs específicos ou por meio de sistemas de plug-ins independentes. Cada um segue seu padrão, forçando os desenvolvedores a decidir quais plataformas endossar. Isso leva a possíveis bloqueios de plataforma ou esforços redundantes.
2. Segurança:
   Embora a flexibilidade entre contas e recursos ofereça vantagens, ela pode ampliar as preocupações de segurança. Os recursos podem ser auditados coletivamente, mas a ausência de avaliações independentes pode aumentar o risco de vulnerabilidades nas contas.
3. Capacidade de atualização:
   À medida que os recursos evoluem, é importante manter a capacidade de adicionar, substituir ou remover funcionalidades. A reimplantação de recursos existentes a cada atualização apresenta complexidades.

Para navegar nessas águas, precisamos de contratos atualizáveis que garantam 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 singular: Construindo uma Arquitetura Modular de Abstração de Conta (Modular AA).

AA modular é um nicho dentro do movimento mais amplo de AA que prevê a modularização de contas inteligentes para personalizá-las para os usuários e capacitar os desenvolvedores a aprimorar recursos de maneira integrada com restrições mínimas.

No entanto, em qualquer indústria, estabelecer e promover um novo padrão é um grande desafio. As fases iniciais podem testemunhar muitas soluções diferentes antes de todos decidirem pela principal. No entanto, é encorajador ver aqueles que trabalham na abstração de contas, sejam eles o SDK 4337, desenvolvedores de carteiras, equipes de infraestrutura ou designers de protocolos, todos se unindo para acelerar o processo.

Estrutura Modular: Conta Principal e Módulos

Como a conta chama módulos para realizar funções

Chamada de delegado e contrato de procuração

Chamada externa e chamada de delegado:

Sobre delegarCall

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

Contrato de proxy e delegadoCall

Para realizar a estrutura combinável e atualizável, é necessário um conhecimento fundamental chamado “contrato de proxy”.

1. Contrato proxy: um contrato normal armazena sua lógica e estados, que não podem ser atualizados após a implantação. Um contrato de proxy usando delegado para outro contrato. Ao referir-se à função de implementação, ela a executa no estado atual do contrato de proxy.
2. Casos de uso: embora o contrato de proxy permaneça imutável, você pode implantar uma nova implementação 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 Segura

Arquitetura Segura

O que é seguro:

Safe é uma infraestrutura modular de contas inteligentes líder, projetada para fornecer segurança e flexibilidade testadas em batalha, e permite que os desenvolvedores criem diversos aplicativos e carteiras. Notavelmente, muitas equipes estão construindo com base no Safe ou inspiradas nele. A Biconomy lançou sua conta expandindo o Safe com assinaturas múltiplas nativas 4337 e 1/1. Testemunhando a implantação de mais de 164.000 contratos e bloqueando mais de 30,7 bilhões em valor, a Safe é sem dúvida a principal no espaço.

Estrutura do What's Safe

1. Contrato de conta segura: contrato de proxy principal (stateful)
   A conta segura é um contrato proxy porque delega chamadas de contrato singleton. A conta segura contém proprietários, limites e endereços de implementação, todos definidos como variáveis do proxy, definindo assim seu estado.
2. Contrato Singleton: Hub de Integração (Sem Estado)
   Singleton atende a conta Safe e integra e define diferentes integrações, incluindo Plugin, Hook, Function Handler e Signature Validator.
3. Contrato do módulo: Lógica e recursos personalizados:
   Os módulos são poderosos. Os plug-ins de tipo modular podem definir diferentes recursos, como streaming de pagamento, mecanismos de recuperação e chaves de sessão, e podem servir como uma ponte entre web2 e web3, buscando dados fora da cadeia. Outros módulos, como o Hook como proteção de segurança e o Function Handler, respondem a quaisquer instruções.

O que acontece quando adotamos o Safe:

1. Contratos atualizáveis:
   A implantação de um novo singleton é necessária sempre que novos plug-ins são introduzidos. Os usuários mantêm a autonomia para atualizar seu Safe para a versão singleton desejada, alinhando-se com suas preferências e requisitos.
2. Módulos combináveis e reutilizáveis:
   A natureza modular dos plug-ins permite que os desenvolvedores criem funcionalidades de forma independente. Eles podem então selecionar e combinar livremente esses plug-ins com base em seus casos de uso, promovendo uma abordagem altamente personalizável.

Proxies Diamante ERC-2535

Arquitetura Diamante ERC2535

Sobre ERC2535, Proxies Diamante:

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

Qual é a estrutura do diamante:

1. Contrato Diamond: Contrato de proxy principal (Stateful) Um diamante é um contrato de proxy que chama funções de suas implementações usando delegadocall.
2. Contrato de módulo/plugin/faceta: lógica e recursos personalizados (sem estado) Um módulo ou o chamado Facet é um contrato sem estado que pode implantar seus recursos em um ou mais diamantes. São contratos separados e 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 compartilhar dados entre eles, além de adicionar/substituir/remover diretamente qualquer plug-in usando a função diamanteCut. Não há limite para a quantidade de plugins que podem ser adicionados aos diamantes ao longo do tempo.
2. Plug-in modular e reutilizável: um plug-in implantado pode ser usado por qualquer número de diamantes para reduzir tremendamente os custos de implantação.

Diferença entre Safe Smart Account e Diamond Approach:

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

No entanto, a principal distinção reside no tratamento de contratos lógicos. Aqui está uma visão mais detalhada:

1. Flexibilidade:
   No contexto da habilitação de novos plugins, a Safe necessita da redistribuição de seu contrato Singleton para implementar a mudança em seu Proxy. Em contraste, Diamond consegue isso diretamente através da função diamanteCut em seu Proxy. Essa variação na abordagem se traduz em Safe mantendo um maior grau de controle, enquanto Diamond introduz flexibilidade e modularidade aprimoradas.
2. Segurança:
   delegadocall, utilizado em ambas as estruturas por enquanto, pode permitir que código externo manipule o armazenamento do contrato principal. Na arquitetura Safe, o delegado aponta para um único contrato lógico, enquanto o Diamond emprega o delegado em vários contratos-plugins de módulos. Consequentemente, um plugin malicioso tem o potencial de substituir outro plugin, introduzindo assim o risco de colisões de armazenamento que podem comprometer a integridade do Proxy.
3. Custo:
   A flexibilidade inerente à abordagem Diamond vem acompanhada de preocupações ampliadas de segurança. Isso aumenta o fator custo, necessitando de auditorias abrangentes a cada adição de um novo plugin. A chave é garantir que esses plug-ins não interfiram nas funções uns dos outros, o que representa um desafio, especialmente para pequenas e médias empresas que se esforçam para manter padrões de segurança robustos.

A “abordagem Safe Smart Account” e a “Abordagem Diamante” servem como exemplos de estruturas distintas envolvendo proxies e módulos. Como equilibrar flexibilidade e segurança é crucial, e estes dois métodos poderão potencialmente complementar-se no futuro.

Sequência de módulos: validador, executor e gancho

Qual é a sequência de chamada dos módulos

Vamos expandir nossa discussão apresentando o ERC6900, um padrão proposto pela equipe Alchemy , inspirado no Diamond e adaptado especificamente para o ERC-4337. Ele aborda o desafio da modularidade em contas inteligentes, fornecendo interfaces comuns e coordenando os esforços 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 gancho. Todas essas etapas podem ser gerenciadas usando a conta proxy para chamar módulos, conforme discutimos anteriormente. Embora projetos diferentes possam usar nomes diferentes, é importante compreender a lógica subjacente semelhante.

Nomes de funções em design diferente

1. Validação: Garante a autenticidade e autoridade do chamador para a conta.
2. Execução: executa qualquer lógica personalizada permitida pela conta.
3. Gancho: atua 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.

ERC6900

É crucial separar módulos com base em uma lógica diferente. Uma abordagem padronizada deve ditar como as funções de validação, execução e gancho para contas de contratos inteligentes devem ser escritas. Seja Safe 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 de fornecedores.

Descoberta e segurança de módulos

Como encontrar e verificar módulos de forma aberta

Uma solução que está ganhando força envolve a criação de um local que permite aos usuários descobrir módulos verificáveis, que podemos chamar de “registro”. Este registro funciona como uma “App Store” e visa promover um mercado modular simplificado, mas próspero.

Protocolo{Core} Seguro

Protocolo{Core} Seguro

O protocolo Safe{Core} é um protocolo interoperável e de código aberto para contas de contratos inteligentes, projetado para aprimorar a acessibilidade para vários fornecedores e desenvolvedores, ao mesmo tempo que mantém uma segurança robusta por meio de padrões e regras bem definidos.

1. Conta: no protocolo Safe{Core} , o conceito de conta é flexível e não está vinculado a uma implementação específica. Isso permite que diversos provedores de serviços de conta participem.
2. Gerente: O Gerente atua como coordenador entre Contas, Registros e Módulos. Também é responsável pela segurança como camada de permissão.
3. Registros: Os registros definem atributos de segurança e aplicam padrões como ERC6900 para módulos, com o objetivo de criar um ambiente de “loja de aplicativos” aberto para descoberta e segurança.
4. Módulos: Os módulos lidam com funcionalidades e vêm em vários tipos iniciais, incluindo Plugins, Ganchos, Validadores de Assinatura e Manipuladores de Funções. Eles estão abertos à contribuição dos desenvolvedores, desde que atendam aos padrões estabelecidos.

Design de strass

Design de strass

O processo se desenrola da seguinte forma:

1. Criando uma definição de esquema: um esquema serve como uma estrutura de dados predefinida necessária para atestação. Ele pode ser personalizado pelas empresas para se alinhar aos seus casos de uso específicos.
2. Criando Módulos Baseados em um Esquema: Os contratos inteligentes são registrados como módulos, obtendo bytecode e escolhendo um ID de esquema. Esses dados são então armazenados no registro.
3. Obtenção de atestado para um módulo: Atestadores/auditores podem fornecer atestados para módulos com base no esquema. Esses atestados podem incluir um identificador exclusivo (UID) e referências a outros atestados para encadeamento. Eles podem se propagar entre cadeias e verificar se limites específicos são atendidos nas cadeias de destino.
4. Implementando Lógica Complexa com Resolvedores: Os resolvedores, opcionalmente definidos no esquema, entram em ação. Eles poderiam ser invocados durante a criação do módulo, estabelecimento de atestado e revogação. Esses resolvedores permitem que os desenvolvedores incorporem lógicas complexas e diversas, mantendo estruturas de atestado.
5. Acesso de consulta amigável: As consultas oferecem um meio para os usuários acessarem informações de segurança no front-end. Encontre este EIP aqui.

Embora este esquema 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 e as carteiras se integrem e permite que os usuários localizem módulos sem esforço e verifiquem suas informações de atestado. Vários usos futuros podem ser:

1. Atestadores: Entidades confiáveis, como a Safe, poderiam colaborar com a Rhinestone como atestadores para módulos internos. Simultaneamente, atestadores independentes poderiam participar.
2. Desenvolvedores de Módulos: À medida que um mercado aberto toma forma, os desenvolvedores de módulos poderiam potencialmente monetizar seu trabalho por meio do registro.
3. Usuários: interagindo por meio de interfaces fáceis de usar, como carteiras ou dApps, os usuários podem examinar as informações do módulo e delegar confiança a diversos atestadores.

O conceito de “Registro de Módulo” abre caminhos para monetização para desenvolvedores de plugins e módulos. Isso poderia abrir ainda mais caminho para um “mercado de módulos”. Alguns aspectos podem ser supervisionados pela equipa da Safe, enquanto outros podem manifestar-se como mercados descentralizados, convidando contribuições e registos de auditoria transparentes para todos. Ao incorporar isso, podemos evitar a dependência de fornecedores e apoiar a expansão do EVM, adicionando uma experiência de usuário aprimorada que atrai um público mais amplo.

Embora essas abordagens garantam a segurança de um único módulo, a segurança mais ampla das contas de contratos inteligentes não é infalível. Combinar módulos legítimos e provas de que não apresentam colisões de armazenamento pode ser um desafio, ressaltando a importância da carteira ou da infraestrutura AA para resolver tais preocupações.

Pensamentos finais

Ao utilizar uma pilha modular de contas de contratos inteligentes, os provedores de carteira e dApps podem ser liberados das complexidades da manutenção tecnológica. Enquanto isso, os desenvolvedores de módulos externos têm a oportunidade de oferecer serviços especializados adaptados às necessidades individuais. No entanto, os desafios a enfrentar incluem encontrar um equilíbrio entre flexibilidade e segurança, impulsionar padrões modulares e implementar interfaces padronizadas que permitam aos utilizadores atualizar e modificar facilmente as suas contas inteligentes.

No entanto, as Contas de Contrato Inteligente (SCA) modulares representam apenas uma peça do quebra-cabeça da adoção. Para concretizar plenamente o potencial do SCA, é necessário suporte adicional à camada de protocolo das soluções da Camada 2, assim como uma infraestrutura robusta de empacotadores e mempool peer-to-peer, mecanismo de assinatura SCA mais econômico e viável, sincronização e gerenciamento SCA cross-chain e desenvolver interfaces fáceis de usar.

Olhando para o futuro, vislumbramos um futuro onde a participação será generalizada, suscitando questões intrigantes: Quando o fluxo de encomendas SCA se tornar suficientemente rentável, como é que os mecanismos tradicionais de Miner Extractable Value (MEV) entrarão em campo para construir pacotes e capturar valor? Quando a infraestrutura amadurecer, como as Abstrações de Contas (AA) poderão servir como camada fundamental para transações “baseadas em intenções”? Fique atento; a paisagem está evoluindo a cada minuto.

Peças importantes

1. Artigo seguro: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Documento de strass: https://docs.rhinestone.wtf/
3. Documento Biconomy: https://www.biconomy.io/post/making-biconomy-smart-accounts-modular

Isenção de responsabilidade:

1. Este artigo foi reimpresso de [SevenX Ventures ]. Todos os direitos autorais pertencem ao autor original [SevenX Ventures]. Se houver objeções a esta reimpressão, entre em contato com a equipe do Gate Learn e eles cuidarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e pontos de vista expressos 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 do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.