Arquitetura modular de conta de contrato inteligente e desafios

Introdução

A mudança de Contas de Propriedade Externa (EOA) para Contas de Contratos Inteligentes (SCA) está a ganhar força e tem sido abraçada por muitos entusiastas, incluindo o próprio Vitalik. Apesar da excitação, a adoção da SCA não é tão difundida como os EOAs. A chave entre eles são os desafios colocados pelos mercados em bear, a preocupação com a migração, questões de assinatura, despesas gerais de gás e, o mais crítico, 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 dos principais desafios de engenharia é a não interoperabilidade das funcionalidades de AA, e a fragmentação dificulta a integração e abre a porta ao bloqueio do fornecedor. Além disso, garantir a segurança ao mesmo tempo em que actualiza e compõe funcionalidades pode ser complexo.

Entre na Abstração de Conta Modular, como um subconjunto do movimento AA mais amplo, esta abordagem inovadora pode separar as contas inteligentes das suas funções personalizadas. O objetivo é criar uma estrutura modular para desenvolver carteiras seguras e perfeitamente integradas com diversas funcionalidades. No futuro, pode realizar uma “loja de aplicações” gratuita para contas de contrato inteligentes que liberta carteiras e DApps de criar funcionalidades mas se concentra na experiência do utilizador.

Depois de ler este artigo, os leitores irão obter informações sobre:

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

Uma breve revisão do AA

Paisagem SCA

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

A Abstração de Conta aproveita a conta de contrato inteligente permitindo a validação e execução programáveis, onde o utilizador é 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. Introduz benefícios à experiência do utilizador (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 da conta:

1. Camada de protocolo: Alguns protocolos fornecem suporte de abstração de conta nativa, as transaçõesZKSync seguem o mesmo fluxo, quer sejam originárias de EOA ou SCA que usa um único mempool e fluxo de transações para suportar AA, e a Starknet removeu a EOA e todas as contas são SCA, e têm carteiras de contrato inteligentes nativas como Argent.
2. Camada contratual: 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 a construir infraestruturas de bundler, e muitos mais como Safe, Zerodev, Etherspot e Biconomy estão a construir pilha e SDK.

👉 Se não está familiarizado com AA ou ERC4337, consulte a pesquisa anterior da SevenX aqui.

O Dilema da Adoção da SCA

O tópico da Abstração de Contas (AA) está em discussão desde 2015 e foi ainda mais impulsionado para a ribalta pelo ERC4337 este ano. No entanto, o número de contas de contratos inteligentes implantadas ainda é pálido em comparação com os EOAs.

Vamos mergulhar neste dilema:

1. Bear Market Impact:
   Mesmo que o AA introduza benefícios como login contínuo e abstração de gás, o mercado em alta predominante consiste principalmente em usuários EOA instruídos em vez de novos, portanto, não há incentivo para DApps e carteiras. Mesmo dizendo isso, as principais aplicações ainda estão a caminho da adoção de AA, como a Cyberconnect conduziu cerca de 360.000 UserOps (transações de AA) só por mês, introduzindo o seu sistema AA e a solução sem gás.
2. Obstáculos de migração:
   Para carteiras e aplicações que acumularam utilizadores e armazenaram ativos em EOAs, a migração de ativos de forma segura e conveniente continua a ser um desafio. No entanto, iniciativas como o EIP-7377 permitem que os 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 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 propõe um desafio para as carteiras que utilizam a implementação contrafactual. E o ERC-6492 proposto pela Amire é um sucessor compatível com versões anteriores do ERC-1271 que potencialmente resolve o problema anterior.
4. Despesas gerais de gás:
   Implementar, simular e executar SCAs incorre em custos mais elevados em comparação com os EOAs padrão. Isto torna-se um impedimento para a adoção. No entanto, vários testes foram realizados, como dissociar a criação de conta das operações do utilizador e eliminar o sal da conta e verificações de existência estão a ser considerados para reduzir esses custos.
5. Dificuldades de engenharia:
   A equipa ERC-4337 criou o repo eth-infinitism para fornecer aos programadores uma implementação fundamental. No entanto, à medida que nos ramificamos para funções mais matizadas ou específicas para diferentes casos de uso, a integração e a decodificação tornam-se desafiadoras.

Neste artigo, vamos mergulhar no problema #5: as dificuldades de engenharia.

🤔 ️

Conta modular de contrato inteligente para resolver dificuldades de engenharia

Para aprofundar mais sobre as dificuldades de engenharia:

1. Fragmentação:
   As funcionalidades estão agora activadas de várias formas, seja nativamente por SCAs específicos ou através de sistemas de plugins independentes. Cada um segue o seu padrão, forçando os programadores a decidir quais plataformas endossar. Isto conduz a potenciais bloqueios da plataforma ou a esforços redundantes.
2. Segurança:
   Embora a flexibilidade entre contas e funcionalidades ofereça vantagens, pode ampliar as preocupações com a segurança. Os recursos podem ser auditados coletivamente, mas a ausência de avaliações independentes pode aumentar o risco de vulnerabilidades da conta.
3. Capacidade de actualização:
   À medida que as funcionalidades evoluem, é importante manter a capacidade de adicionar, substituir ou remover funcionalidades. Reimplantar as funcionalidades existentes a cada atualização introduz complexidades.

Para navegar nestas águas, precisamos de contratos actualizáveis que garantam actualizações seguras e eficientes, núcleos reutilizáveis para aumentar a eficiência geral do desenvolvimento e interfaces padronizadas para garantir que as contas de contrato possam fazer a transição suave entre diferentes front-end.

Estes termos convergem para um conceito singular: Construir uma Arquitetura de Abstração de Conta Modular (Modular AA).

O AA modular é um nicho dentro do movimento AA mais amplo que prevê a modularização de contas inteligentes para personalizá-las para os utilizadores e capacitar os programadores a melhorarem perfeitamente as funcionalidades 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 se estabelecerem na principal. No entanto, é encorajador ver aqueles que trabalham na abstração de contas, seja o SDK 4337, desenvolvedores de carteiras, equipas de infraestrutura ou designers de protocolo, todos se unindo para acelerar o processo.

Estrutura Modular: Conta Principal e Módulos

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

Delegar chamada e contrato de procuração

Chamada externa e chamada de delegado:

Sobre o DelegadeCall

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

Contrato de proxy e DelegadeCall

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

1. Contrato de proxy: Um contrato normal armazena a sua lógica e estados, que não é capaz de atualizar após a implementação. Um contrato de procuração usando delegatecall para outro contrato. Ao referir-se à função de implementação, executa-a no estado atual do contrato de proxy.
2. Casos de uso: Enquanto o contrato de proxy permanece imutável, pode implementar uma nova implementação atrás do proxy. Os contratos de proxy são utilizados para a capacidade de actualização e são mais baratos de implementar e manter em blockchains públicos.

Arquitetura segura

Arquitetura segura

O que é seguro:

A Safe é uma infraestrutura de conta inteligente modular líder projetada para fornecer segurança e flexibilidade testadas em batalha, capacita os desenvolvedores a criar diversas aplicações e carteiras. Notavelmente, muitas equipas estão a construir em cima do Safe ou inspiradas por ele. A Biconomy lançou a sua conta expandindo o Safe com 4337 e 1/1 multi-assinaturas nativas. Testemunhando a implantação de mais de 164.000 contratos e fixando mais de 30,7 mil milhões em valor, a Safe é sem dúvida a primeira no espaço.

Qual é a estrutura do Safe

1. Contrato de conta segura: Contrato de procuração principal (Stateful) A
   conta segura é um contrato de procuração porque delega um contrato de single. A Conta Segura contém proprietários, limite e os endereços de implementação estão todos definidos como as variáveis do proxy, definindo assim o seu estado.
2. Contrato Singleton: Integration Hub (Stateless) O
   Singleton serve 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 características personalizadas:
   Os módulos são poderosos. Os plug-ins como um tipo modular podem definir diferentes funcionalidades como fluxos de pagamento, mecanismos de recuperação e chaves de sessão, e podem servir como uma ponte entre a web2 e a web3 ao buscar dados fora da cadeia. Outros módulos como o Hook como guarda 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 utilizadores mantêm a autonomia para actualizar o seu Safe para a versão singleton desejada, alinhando-se com as suas preferências e requisitos.
2. Módulos Composable e Reutilizáveis:
   A natureza modular dos plugins permite que os programadores criem funcionalidades de forma independente. Podem então selecionar e combinar livremente estes plugins com base nos seus casos de uso, promovendo uma abordagem altamente personalizável.

ERC-2535 Proxies de Diamante

ERC2535 Arquitetura de diamantes

Sobre ERC2535, Diamond Proxies:

O ERC2535 normaliza diamantes, um sistema modular de contrato inteligente que pode ser actualizado/alargado após a implementação e praticamente não tem limite de tamanho. Até agora, muitas equipas inspiraram-se nele, como o Kernel do Zerodev e a experiência do Soul Wallet.

O que é estrutura de diamante:

1. Contrato de diamante: Contrato de proxy principal (Stateful) Um diamante é um contrato de proxy que chama funções das suas implementações usando delegatecall.
2. Módulo/Plugin/Contrato de faceta: Lógica e características personalizadas (Stateless) Um módulo ou a chamada Faceta é um contrato sem estado que poderia implementar as suas características em um ou mais diamantes. São contratos separados e independentes que podem partilhar funções internas, bibliotecas e variáveis de estado.

O que acontece quando adotamos o Diamond:

1. Contratos atualizáveis: O Diamond fornece uma maneira sistemática de isolar diferentes plugins e conectá-los e partilhar dados entre eles, também adiciona/substitui/remove diretamente qualquer plugin usando a função DiamondCut. Não há limite para a quantidade de plugins que podem ser adicionados aos diamantes ao longo do tempo.
2. Plugin modular e reutilizável: Um plugin implementado pode ser usado por qualquer número de diamantes para reduzir tremendamente os custos de implementação.

Diferença entre Safe Smart Account e Diamond Approach:

As semelhanças abundam entre as arquiteturas Safe e Diamond, ambas confiando em contratos de proxy no seu núcleo e fazendo referência a contratos lógicos para alcançar a capacidade de atualização e modularidade.

No entanto, a principal distinção reside no tratamento de contratos lógicos. Aqui está um olhar mais atento:

1. Flexibilidade:
   No contexto da activação de novos plugins, a Safe necessita da reimplementação do seu contrato Singleton para implementar a alteração no seu Proxy. Em contraste, o Diamond consegue isso diretamente através da função DiamondCut no seu Proxy. Esta variação na abordagem traduz-se em Segurança reter um grau mais elevado de controlo, enquanto o Diamond introduz maior flexibilidade e modularidade.
2. Segurança:
   delegatecall, utilizado em ambas as estruturas por enquanto, pode permitir que código externo manipule o armazenamento do contrato principal. Na arquitetura Safe, delegatecall aponta para um único contrato lógico, enquanto o Diamond emprega delegatecall em vários contratos de módulo - plug-ins. 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 de mãos dadas com preocupações de segurança ampliadas. Isso aumenta o fator de custo, exigindo auditorias abrangentes a cada adição de um novo plugin. A chave é garantir que estes plugins não interfiram nas funções uns dos outros, apresentando um desafio, particularmente para pequenas ou médias empresas que se esforçam para manter padrões de segurança robustos.

A “abordagem Safe Smart Account” e a “Diamond Approach” servem como exemplos de estruturas distintas envolvendo proxies e módulos. Como equilibrar flexibilidade e segurança é crucial, e estes dois métodos podem potencialmente complementar um ao outro no futuro.

Sequência de módulos: Validador, Executor e Gancho

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

Vamos expandir a nossa discussão apresentando o ERC6900, um padrão proposto pela equipa da Alchemy, inspirado no Diamond e adaptado especificamente para ERC-4337. Aborda o desafio da modularidade nas contas inteligentes, fornecendo interfaces comuns e coordena os esforços entre os 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. Estas etapas podem ser geridas usando a conta de proxy para chamar módulos, como 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 que a conta permita.
3. Hook: Funciona como um módulo que é executado antes ou depois de outra função. Pode modificar o estado ou fazer com que toda a chamada se desfaça.

ERC6900

É crucial separar os módulos com base numa lógica diferente. Uma abordagem padronizada deve ditar como as funções de validação, execução e gancho para contas de contrato inteligentes devem ser escritas. Quer se trate de Safe ou ERC6900, a normalização ajuda a reduzir a necessidade de esforços de desenvolvimento únicos específicos para determinadas implementações ou ecossistemas e evita o bloqueio do fornecedor.

Módulos Descoberta e Segurança

Como encontrar e verificar módulos de forma aberta

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

Protocolo{Core} Seguro

Protocolo{Core} Seguro

O Safe{Core} Protocol é um protocolo de código aberto e interoperável para contas de contrato inteligentes, concebido para melhorar a acessibilidade de vários fornecedores e programadores, mantendo uma segurança robusta através de normas e regras bem definidas.

1. Conta: No protocolo Safe{Core}, o conceito de conta é flexível e não está vinculado a uma implementação específica. Isto permite que diversos prestadores de serviços de conta participem.
2. Gestor: O Gestor serve como coordenador entre Contas, Registos e Módulos. Também é responsável pela segurança como a camada de autorização.
3. Registros: Os registos definem atributos de segurança e aplicam padrões como o ERC6900 para Módulos, com o objetivo de criar um ambiente aberto de “loja de aplicações” tanto para a descoberta como para a 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ção. Estão abertos para os programadores contribuírem, desde que cumpram os padrões estabelecidos.

Design de strass

Design de strass

O processo desenrola-se da seguinte forma:

1. Criando uma Definição de Esquema: Um esquema serve como uma estrutura de dados predefinida necessária para o atestado. Pode ser personalizado pelas empresas para se alinhar com os seus casos de uso específicos.
2. Criando módulos com base em um esquema: Os contratos inteligentes são registados como módulos, obtendo bytecode e escolhendo uma ID de esquema. Estes dados são então armazenados no registo.
3. Obtenção de Atestado para um Módulo: Os atestadores/auditores podem fornecer atestados para módulos numa base de esquema. Estes atestados podem incluir um identificador único (UID) e referências a outros atestados para encadeamento. Podem propagar-se através das cadeias e verificar se os limiares específicos são atingidos nas cadeias de destino.
4. Implementando lógica complexa com resolvedores: Resolvedores, opcionalmente definidos no esquema, entram em jogo. Podem ser invocados durante a criação do módulo, estabelecimento do atestado e revogação. Estes resolvedores permitem que os programadores incorporem lógica intrincada e diversificada enquanto mantêm as estruturas de atestado.
5. Acesso de consulta fácil de usar: As consultas oferecem um meio para os utilizadores acederem a informações de segurança a partir do front-end. Encontre este EIP aqui.

Embora este esquema esteja nas suas fases iniciais, tem o potencial de estabelecer um padrão de forma descentralizada e colaborativa. O seu registo permite que os programadores registem os seus módulos, auditores verifiquem a sua segurança e as carteiras se integrem e permite aos utilizadores localizar módulos sem esforço e verificar as 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 de módulos internos. Simultaneamente, os atestadores independentes podem participar.
2. Desenvolvedores de Módulos: À medida que um mercado aberto toma forma, os programadores de módulos podem potencialmente rentabilizar o seu trabalho através do registo.
3. Utilizadores: Envolvendo-se através de interfaces fáceis de usar, como carteiras ou DApps, os utilizadores podem examinar as informações do módulo e delegar confiança a diversos attestadores.

O conceito de “Registo de Módulos” abre caminhos para monetização para programadores de plugins e módulos. Poderia abrir ainda mais o caminho para um “Module Marketplace”. Alguns aspetos podem ser supervisionados pela equipa da Safe, enquanto outros podem manifestar-se como mercados descentralizados, contribuições convidativas e registos de auditoria transparentes para todos. Ao incorporar isso, podemos evitar o bloqueio do fornecedor e apoiar a expansão do EVM adicionando uma experiência de utilizador melhorada que atrai um público mais vasto.

Embora estas 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 têm colisões de armazenamento pode ser um desafio, sublinhando a importância da carteira ou da infra-estrutura AA para resolver tais preocupações.

Pensamentos finais

Ao utilizar uma pilha modular de contas de contrato inteligente, os fornecedores de carteiras e DApps podem ser libertados das complexidades da manutenção tecnológica. Enquanto isso, os programadores 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 os padrões modulares e implementar interfaces padronizadas que permitem aos utilizadores actualizar e modificar facilmente as suas contas inteligentes.

No entanto, as Smart Contract Accounts (SCA) modulares representam apenas uma peça do puzzle da adoção. Para realizar plenamente o potencial do SCA, é necessário suporte adicional à camada de protocolo a partir das soluções de Camada 2, de modo a uma infra-estrutura robusta de bundler e mempool ponto a ponto, mecanismo de assinatura SCA mais rentável e viável, sincronização e gestão de SCA entre cadeias e desenvolver interfaces fáceis de usar.

Olhando para o futuro, imaginamos um futuro em que a participação seja generalizada, gerando questões intrigantes: Uma vez que o fluxo de pedidos SCA se torne suficientemente rentável, como os mecanismos tradicionais do Miner Extractable Value (MEV) entrarão em campo para construir empacotadores e capturar valor? Quando a infraestrutura amadurece, como podem as abstrações de contas (AA) servir como a camada fundamental para transações “baseadas em intenção”? Fique ligado; a paisagem está a evoluir a cada minuto.

Peças importantes

1. Whitepaper seguro: https://github.com/safe-global/safe-core-protocol-specs/blob/main/whitepaper.pdf
2. Rhinestone doc: 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 da [SevenX Ventures ]. Todos os direitos de autor pertencem ao autor original [SevenX Ventures]. Se houver objeções a esta reimpressão, contacte a equipa do Gate Learn, e eles tratarão disso imediatamente.
2. Isenção de responsabilidade: As opiniões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outras línguas são feitas pela equipa do Gate Learn. A menos que mencionado, é proibido copiar, distribuir ou plagiar os artigos traduzidos.