Lição 4

Como Construir e Usar uma Conta Inteligente

Um guia prático para criar contas inteligentes usando thirdweb, Biconomy ou Safe SDKs. Ele abrange como configurar um ambiente de desenvolvimento, conectar-se a contas inteligentes a partir de um frontend, implementar fluxos sem gás, simular transações através de bundlers e paymasters, e seguir as melhores práticas para testes e implantação.

Configurando o ambiente de desenvolvimento

Um fluxo de trabalho típico começa com um projeto TypeScript criado através do Vite ou Next.js. Depois de instalar ethers-v6 e dotenv para gerenciamento de chaves, a próxima dependência é o SDK de abstração de conta de sua escolha. A Thirdweb depende de umfábrica de contas contrato que você implanta uma vez—seja imutável ou atualizável—e, em seguida, serve como uma chave de infraestrutura gratuita que desbloqueia seu agregador e pagador hospedados. O painel emite essa chave imediatamente após você criar um projeto e permite chamadas com limite de taxa no Sepolia, Base e Polygon zkEVM.

A Biconomy segue uma estrutura semelhante, mas separa as preocupações de forma mais explícita. Você registra um pagador no console da web, recarrega um tanque de gás e define políticas que decidem quais métodos serão patrocinados. O SDK então injeta o endereço do pagador e a chave da API em cada Operação do Usuárioseus dApps assinam. Este design permite que aplicativos de consumo adicionem fluxos "sem gás" sem expor um servidor de retransmissão privado.

O CLI do Safe implanta uma carteira proxy que herda um contrato singleton testado em batalha; um Safe4337Module opcional anexa ganchos ERC-4337, permitindo que o mesmo cofre entre no alt-mempool sem mudar seu endereço. Os desenvolvedores podem executar o CLI em modo não supervisionado para pré-implantar centenas de proxies para uma campanha de airdrop ou test-net.

Conectando a uma conta inteligente a partir do front-end

Uma vez que as partes de back-end existam na blockchain, uma aplicação React pode expor um único botão "Conectar" que resolve para um contexto de conta inteligente. O wrapper da Thirdweb recebe um client-ID e um factory-address; quando o usuário escolhe qualquer carteira subjacente—MetaMask, uma carteira embutida baseada em e-mail ou uma chave de acesso—o provedor verifica silenciosamente se um contrato já existe, e então o implanta na primeira transação, financiando o gás através do paymaster integrado quando gasless:true está definido.

A Biconomy injeta seu contexto através da classe BiconomySmartAccount, que envolve um Signer do ethers. Após a inicialização, todas as chamadas executadas através deste signer são codificadas como UserOperations e encaminhadas para o bundler. A Safe oferece uma abstração semelhante através de @safe-global/core-kit, onde uma instância SafeAccount substitui ethers.Wallet e expõe auxiliares de alto nível para agrupamento, coleta de assinaturas e execução on-chain.

Personalizando a lógica da carteira: fluxos sem gás e lista branca

Contas inteligentes expõem ganchos que são executados antes que uma UserOperation seja considerada válida, então adicionar recursos como destinos na lista branca ou limites de gastos diários é tão simples quanto atualizar o armazenamento do contrato através de uma transação do proprietário. Para interações sem gás, o desenvolvedor registra um patrocinador paymaster(Biconomy) ou ativa a flag sem gás (thirdweb). Nos bastidores, o pagador pré-assina a operação e depois solicita reembolso de seu tanque de gás; o usuário percebe um saldo de zero ETH, mas completa a ação como se tivesse financiado a carteira por conta própria. A lista de permissões funciona da mesma maneira: uma rotina de validação na carteira verifica os dados da chamada em relação a uma lista permitida e reverte se a chamada estiver fora do escopo, protegendo os usuários de aprovações de contratos maliciosos.

Simulando e assinando transações com agrupadores e pagadores

ERC-4337 introduz um mempool alternativo no qual empacotadores coletar UserOperations, realizar simulação off-chain e envolver conjuntos bem-sucedidos em transações Ethereum ordinárias. Serviços populares incluem Alchemy Rundler, Stackup, Voltaire e Infinitism; cada um expõe um endpoint JSON-RPC que espelha a especificação de referência. A simulação previne operações sem esperança—por exemplo, chamadas que falhariam na validação da carteira—de chegar à cadeia e desperdiçar gás.

Um pagador pode aproveitar esse fluxo. Durante a simulação, o agrupador pergunta ao pagador se ele cobrirá a taxa e, se sim, anexa a assinatura do pagador. Na cadeia, o contrato EntryPoint valida tanto a carteira quanto o pagador em uma única chamada, mescla todas as ações agrupadas e distribui os reembolsos de gás de acordo. Esse mecanismo permite que uma troca patrocine depósitos, um jogo subsidie movimentos dentro do jogo ou um DAO recompense contribuintes sem forçar os usuários a manter ETH.

Testando e implantando: melhores práticas para 2025

Os testes locais agora se beneficiam de redes baseadas em fork, como Anvil ou Hardhat-foundry, que podem impersonar um bundler e um paymaster, de modo que todo o ciclo UserOperation ocorra na memória. Antes de ser enviado para a test-net, os projetos são compilados com Solidity 0.8.25 e ativam as execuções de otimizador para corresponder ao bytecode que os auditores irão revisar. Scripts de integração contínua executam passes de análise estática com Slither ou MythX e realizam fuzzing diferencial contra invariantes pretendidos.

A segurança continua sendo primordial: as diretrizes de auditoria de 2025 enfatizam revisões em múltiplas camadas que misturam varreduras automatizadas, análises manuais e testes de penetração ao vivo. As equipes bloqueiam a base de código antes da auditoria, abordam descobertas críticas e publicam o relatório final juntamente com seus metadados de implantação. Uma vez que a auditoria esteja limpa, o contrato de fábrica é implantado primeiro, seguido pelo paymaster (se necessário) e, finalmente, as atualizações de variáveis de ambiente do front-end que apontam para os endpoints de bundler ao vivo. Após o lançamento, ganchos de monitoramento ficam de olho em UserOperations falhadas e chamadas de paymaster revertidas, alertando os desenvolvedores antes que os usuários percebam o tempo de inatividade.

Com esses passos concluídos, um dApp pode apresentar um fluxo de integração com um clique onde novatos criam uma carteira, mintam um NFT ou entrem em uma posição DeFi sem precisar comprar ETH primeiro. O próximo e último módulo irá mapear implantações do mundo real de tais fluxos, pesar as limitações atuais e examinar padrões emergentes como o ERC-6900 que prometem uma modularidade ainda maior.

Isenção de responsabilidade
* O investimento em criptomoedas envolve grandes riscos. Prossiga com cautela. O curso não se destina a servir de orientação para investimentos.
* O curso foi criado pelo autor que entrou para o Gate Learn. As opiniões compartilhadas pelo autor não representam o Gate Learn.
Catálogo
Lição 4

Como Construir e Usar uma Conta Inteligente

Um guia prático para criar contas inteligentes usando thirdweb, Biconomy ou Safe SDKs. Ele abrange como configurar um ambiente de desenvolvimento, conectar-se a contas inteligentes a partir de um frontend, implementar fluxos sem gás, simular transações através de bundlers e paymasters, e seguir as melhores práticas para testes e implantação.

Configurando o ambiente de desenvolvimento

Um fluxo de trabalho típico começa com um projeto TypeScript criado através do Vite ou Next.js. Depois de instalar ethers-v6 e dotenv para gerenciamento de chaves, a próxima dependência é o SDK de abstração de conta de sua escolha. A Thirdweb depende de umfábrica de contas contrato que você implanta uma vez—seja imutável ou atualizável—e, em seguida, serve como uma chave de infraestrutura gratuita que desbloqueia seu agregador e pagador hospedados. O painel emite essa chave imediatamente após você criar um projeto e permite chamadas com limite de taxa no Sepolia, Base e Polygon zkEVM.

A Biconomy segue uma estrutura semelhante, mas separa as preocupações de forma mais explícita. Você registra um pagador no console da web, recarrega um tanque de gás e define políticas que decidem quais métodos serão patrocinados. O SDK então injeta o endereço do pagador e a chave da API em cada Operação do Usuárioseus dApps assinam. Este design permite que aplicativos de consumo adicionem fluxos "sem gás" sem expor um servidor de retransmissão privado.

O CLI do Safe implanta uma carteira proxy que herda um contrato singleton testado em batalha; um Safe4337Module opcional anexa ganchos ERC-4337, permitindo que o mesmo cofre entre no alt-mempool sem mudar seu endereço. Os desenvolvedores podem executar o CLI em modo não supervisionado para pré-implantar centenas de proxies para uma campanha de airdrop ou test-net.

Conectando a uma conta inteligente a partir do front-end

Uma vez que as partes de back-end existam na blockchain, uma aplicação React pode expor um único botão "Conectar" que resolve para um contexto de conta inteligente. O wrapper da Thirdweb recebe um client-ID e um factory-address; quando o usuário escolhe qualquer carteira subjacente—MetaMask, uma carteira embutida baseada em e-mail ou uma chave de acesso—o provedor verifica silenciosamente se um contrato já existe, e então o implanta na primeira transação, financiando o gás através do paymaster integrado quando gasless:true está definido.

A Biconomy injeta seu contexto através da classe BiconomySmartAccount, que envolve um Signer do ethers. Após a inicialização, todas as chamadas executadas através deste signer são codificadas como UserOperations e encaminhadas para o bundler. A Safe oferece uma abstração semelhante através de @safe-global/core-kit, onde uma instância SafeAccount substitui ethers.Wallet e expõe auxiliares de alto nível para agrupamento, coleta de assinaturas e execução on-chain.

Personalizando a lógica da carteira: fluxos sem gás e lista branca

Contas inteligentes expõem ganchos que são executados antes que uma UserOperation seja considerada válida, então adicionar recursos como destinos na lista branca ou limites de gastos diários é tão simples quanto atualizar o armazenamento do contrato através de uma transação do proprietário. Para interações sem gás, o desenvolvedor registra um patrocinador paymaster(Biconomy) ou ativa a flag sem gás (thirdweb). Nos bastidores, o pagador pré-assina a operação e depois solicita reembolso de seu tanque de gás; o usuário percebe um saldo de zero ETH, mas completa a ação como se tivesse financiado a carteira por conta própria. A lista de permissões funciona da mesma maneira: uma rotina de validação na carteira verifica os dados da chamada em relação a uma lista permitida e reverte se a chamada estiver fora do escopo, protegendo os usuários de aprovações de contratos maliciosos.

Simulando e assinando transações com agrupadores e pagadores

ERC-4337 introduz um mempool alternativo no qual empacotadores coletar UserOperations, realizar simulação off-chain e envolver conjuntos bem-sucedidos em transações Ethereum ordinárias. Serviços populares incluem Alchemy Rundler, Stackup, Voltaire e Infinitism; cada um expõe um endpoint JSON-RPC que espelha a especificação de referência. A simulação previne operações sem esperança—por exemplo, chamadas que falhariam na validação da carteira—de chegar à cadeia e desperdiçar gás.

Um pagador pode aproveitar esse fluxo. Durante a simulação, o agrupador pergunta ao pagador se ele cobrirá a taxa e, se sim, anexa a assinatura do pagador. Na cadeia, o contrato EntryPoint valida tanto a carteira quanto o pagador em uma única chamada, mescla todas as ações agrupadas e distribui os reembolsos de gás de acordo. Esse mecanismo permite que uma troca patrocine depósitos, um jogo subsidie movimentos dentro do jogo ou um DAO recompense contribuintes sem forçar os usuários a manter ETH.

Testando e implantando: melhores práticas para 2025

Os testes locais agora se beneficiam de redes baseadas em fork, como Anvil ou Hardhat-foundry, que podem impersonar um bundler e um paymaster, de modo que todo o ciclo UserOperation ocorra na memória. Antes de ser enviado para a test-net, os projetos são compilados com Solidity 0.8.25 e ativam as execuções de otimizador para corresponder ao bytecode que os auditores irão revisar. Scripts de integração contínua executam passes de análise estática com Slither ou MythX e realizam fuzzing diferencial contra invariantes pretendidos.

A segurança continua sendo primordial: as diretrizes de auditoria de 2025 enfatizam revisões em múltiplas camadas que misturam varreduras automatizadas, análises manuais e testes de penetração ao vivo. As equipes bloqueiam a base de código antes da auditoria, abordam descobertas críticas e publicam o relatório final juntamente com seus metadados de implantação. Uma vez que a auditoria esteja limpa, o contrato de fábrica é implantado primeiro, seguido pelo paymaster (se necessário) e, finalmente, as atualizações de variáveis de ambiente do front-end que apontam para os endpoints de bundler ao vivo. Após o lançamento, ganchos de monitoramento ficam de olho em UserOperations falhadas e chamadas de paymaster revertidas, alertando os desenvolvedores antes que os usuários percebam o tempo de inatividade.

Com esses passos concluídos, um dApp pode apresentar um fluxo de integração com um clique onde novatos criam uma carteira, mintam um NFT ou entrem em uma posição DeFi sem precisar comprar ETH primeiro. O próximo e último módulo irá mapear implantações do mundo real de tais fluxos, pesar as limitações atuais e examinar padrões emergentes como o ERC-6900 que prometem uma modularidade ainda maior.

Isenção de responsabilidade
* O investimento em criptomoedas envolve grandes riscos. Prossiga com cautela. O curso não se destina a servir de orientação para investimentos.
* O curso foi criado pelo autor que entrou para o Gate Learn. As opiniões compartilhadas pelo autor não representam o Gate Learn.