5 posts marcados com "Account Abstraction"

AllScale.io é uma plataforma de pagamento de stablecoin legítima e com financiamento de risco — não um projeto de token — que visa freelancers e pequenas empresas em mercados emergentes. Fundada em fevereiro de 2025 e apoiada por $6.5M de VCs de cripto renomados, incluindo YZi Labs, Draper Dragon e KuCoin Ventures, a empresa mostra sinais positivos: uma equipe publicamente identificada com experiência verificável na Kraken, Capital One e Block, além de apoio institucional da incubadora Cyberport de Hong Kong. No entanto, a ausência de auditorias de segurança públicas e a extrema juventude da plataforma (menos de um ano de idade) exigem uma diligência prévia cuidadosa antes de um envolvimento significativo.

O que a AllScale faz e o problema que resolve​

A AllScale se posiciona como o "primeiro neobanco de stablecoin de autocustódia do mundo", projetado especificamente para as mais de 600 milhões de microempresas globais — freelancers, criadores de conteúdo, PMEs e contratados remotos — que enfrentam dificuldades com pagamentos transfronteiriços tradicionais. O problema central: freelancers internacionais enfrentam barreiras de contas bancárias, altas taxas de transferência, perdas na conversão de moeda e atrasos na liquidação que frequentemente excedem 5 dias úteis.

A plataforma permite que as empresas criem faturas, recebam pagamentos em USDT ou USDC, independentemente de como os clientes pagam (cartão de crédito, transferência bancária ou cripto), e acessem os fundos instantaneamente por meio de uma carteira não-custodial. Os principais produtos incluem AllScale Invoice (ativo desde setembro de 2025), AllScale Pay (comércio social via Telegram, WhatsApp, Line) e AllScale Payroll (pagamentos transfronteiriços para contratados). A empresa enfatiza o "cripto invisível" — os clientes podem não saber que estão usando trilhos de blockchain enquanto os comerciantes recebem stablecoins.

Estágio atual de desenvolvimento: A plataforma está em beta público com um produto funcional ativo na mainnet da BNB Chain. Os usuários podem acessar o painel em dashboard.allscale.io, embora uma lista de espera possa ser aplicada.

A arquitetura técnica depende da BNB Chain e da abstração de conta​

A AllScale se baseia na infraestrutura de blockchain existente em vez de operar sua própria cadeia. A pilha de tecnologia primária inclui:

A abordagem baseada em chave de acesso elimina o notório atrito de UX do gerenciamento de frases semente, diminuindo a barreira para a adoção mainstream. A arquitetura de patrocínio de paymaster multi-chain lida com os custos de transação nos bastidores.

O que falta: A AllScale não mantém repositórios públicos no GitHub — a infraestrutura é proprietária e de código fechado. Nenhum endereço de contrato inteligente foi publicado, nenhuma API ou SDK pública está disponível, e a documentação técnica em docs.allscale.io foca em guias de usuário em vez de especificações de arquitetura. Essa opacidade impede a verificação técnica independente de suas alegações.

Sem token nativo — a plataforma usa USDT e USDC​

A AllScale não possui um token de criptomoeda nativo. Esta é uma distinção crítica de muitos projetos Web3: não há ICO, IDO, venda de token ou ativo especulativo envolvido. A empresa opera como uma C-corp tradicional de Delaware levantando financiamento de capital.

A plataforma usa stablecoins de terceiros — principalmente USDT e USDC — como meio de pagamento. Os usuários recebem pagamentos em stablecoins, com conversão automática de pagamentos fiduciários ou por cartão. A integração com a BNB Chain também fornece acesso ao USD1 (a stablecoin afiliada à Binance).

Modelo de receita (estimado, não divulgado publicamente):

• Taxas de transação no processamento de faturas/pagamentos
• Spreads de conversão de moeda em trocas de fiat para stablecoin
• Serviços de gerenciamento de folha de pagamento B2B
• Taxas de integração de on/off-ramp

A ausência de um token elimina certos riscos (volatilidade especulativa, manipulação de tokenomics, preocupações regulatórias de valores mobiliários), mas também significa que não há exposição baseada em token para investidores além da participação acionária.

Quatro fundadores publicamente identificados com históricos verificáveis​

A equipe da AllScale demonstra forte transparência — todos os fundadores são publicamente identificados com históricos profissionais verificáveis:

Shawn Pang (CEO e Co-Fundador): Ciência da Computação e Negócios pela Western University. Ex-Gerente de Produto para fraude de pagamentos na Capital One; primeiro PM no Canadá no TikTok; co-fundou a HashMatrix, uma agência de marketing de crescimento para produtos de IA.

Ruoyang "Leo" Wang (COO e Co-Fundador): Engenharia da Computação pela University of Toronto. Experiência na PingCAP (bancos de dados distribuídos), IBM, AMD e Scotiabank. Experiência anterior em startup com a CP Clickme.

Jun Li e Khalil Lin (Co-Fundadores): Co-fundadores adicionais com experiência jurídica/compliance, supostamente incluindo histórico na OKX. Perfis do LinkedIn disponíveis.

Avrilyn Li (Gerente de Produto Fundadora): Empreendedora de IA para Web3 da Ivey Business School, liderando o produto de folha de pagamento.

A equipe afirma experiência coletiva na Binance, OKX, Kraken, Block (Square), Amazon, Dell e HP. O tamanho total da equipe é de aproximadamente 7-11 funcionários.

Financiamento e investidores​

Investidores participantes notáveis incluem KuCoin Ventures, Oak Grove Ventures, BlockBooster, Aptos, GSR Ventures e V3V Ventures. Os investidores anjo incluem Gracy Chen e Jedi Lu. A empresa é membro do Programa de Incubação Cyberport de Hong Kong, um acelerador de tecnologia apoiado pelo governo.

Grande preocupação de segurança: sem auditorias públicas ou programa de bug bounty​

Este é o sinal de alerta mais significativo na pesquisa. Apesar de lidar com fundos de usuários por meio de carteiras de contrato inteligente:

• Nenhuma auditoria pública de contrato inteligente de empresas reconhecidas (CertiK, Hacken, Trail of Bits, OpenZeppelin, SlowMist)
• Não listado no CertiK Skynet ou bancos de dados de segurança semelhantes
• Nenhum programa de bug bounty no Immunefi, HackerOne ou Bugcrowd
• Nenhum mecanismo de seguro ou cobertura divulgado
• Nenhuma política de divulgação de segurança publicamente visível

A AllScale afirma ter recursos de segurança, incluindo arquitetura de autocustódia, conformidade automatizada com KYC/KYB/KYT, integração de módulo de segurança de hardware (HSM) para chaves de acesso e suporte a 2FA. O modelo de autocustódia reduz o risco de contraparte da plataforma — se a AllScale fosse comprometida, os fundos dos usuários em suas próprias carteiras estariam teoricamente mais seguros do que em um serviço custodial.

Pelo lado positivo: Nenhum incidente de segurança, hack ou exploração foi relatado para a AllScale. No entanto, dada a juventude da plataforma, essa ausência de incidentes pode simplesmente refletir uma exposição limitada, em vez de uma segurança robusta.

Cenário competitivo e posicionamento de mercado​

A AllScale compete no espaço de pagamentos com stablecoins em rápida evolução:

Fatores de diferenciação da AllScale:

• Modelo de autocustódia (usuários controlam os fundos)
• Autenticação por chave de acesso eliminando o atrito de UX da frase semente
• Taxas de gás zero via abstração de conta
• Foco em mercados emergentes (África, América Latina, Sudeste Asiático)
• Segmentação de PMEs de "última milha" vs. foco em empresas

Desvantagens: Extrema juventude, equipe pequena, histórico limitado, concorrência contra empresas estabelecidas e bem financiadas com canais de distribuição consolidados.

A presença na comunidade está em estágio inicial e focada em B2B​

A AllScale mantém canais sociais Web3 padrão:

• X (Twitter): @allscaleio (ativo desde abril de 2025)
• Telegram: Grupo da comunidade AllScaleHQ
• Discord: Servidor ativo com ID da comunidade visível
• LinkedIn: Página da empresa AllScale Inc
• Newsletter: "The Stablecoin Scoop" no Substack

A comunidade está em estágio inicial, com engajamento principalmente por meio de sessões de AMA, X Spaces e anúncios de parcerias. A AllScale sediou o Scale Stablecoin Summit em Hong Kong (junho de 2025) com o HashKey Group e o Amber Group.

Nenhuma métrica DeFi tradicional se aplica: A AllScale é uma plataforma de pagamentos, não um protocolo DeFi, portanto, as métricas de TVL (Total Value Locked) não são aplicáveis. A plataforma não está listada no DeFiLlama ou Dune Analytics. A contagem de usuários e as métricas de retenção são mencionadas por investidores, mas não são divulgadas publicamente.

Parcerias notáveis incluem BNB Chain (parceiro oficial do ecossistema), Skill Afrika (comunidades de freelancers africanos), Ethscriptions (permanência L1) e Asseto (tokenização de RWA para produtos de rendimento).

A avaliação de risco revela um empreendimento de estágio inicial de risco moderado​

Sinais positivos de legitimidade​

• Equipe publicamente identificada com históricos profissionais verificáveis
• VCs de cripto renomados (YZi Labs, Draper Dragon, Amber Group, KuCoin Ventures)
• Apoio institucional do Cyberport de Hong Kong
• Estrutura legal de C-corp de Delaware
• Produto funcional ativo na mainnet da BNB Chain
• Nenhuma alegação de golpe, reclamações no BBB ou avisos da comunidade encontrados
• Nenhuma preocupação com equipe anônima
• Nenhuma promessa de rendimento irrealista ou especulação de token
• Posicionamento focado em conformidade (GENIUS Act, Hong Kong Stablecoin Ordinance)

Áreas que exigem cautela​

• Extrema juventude: Fundada em fevereiro de 2025, com menos de um ano de idade
• Nenhuma auditoria de segurança pública apesar de lidar com fundos
• Nenhum programa de bug bounty
• Nenhuma avaliação independente de usuários ou feedback da comunidade disponível
• Infraestrutura de código fechado — não é possível verificar as alegações de forma independente
• Cobertura da imprensa principalmente por sindicação de comunicados de imprensa, não por jornalismo independente
• Riscos de centralização: Plataforma operada pela empresa, dependência da BNB Chain
• Equipe pequena (~7-11 pessoas) executando um escopo global ambicioso

Não encontrado (potenciais sinais de alerta pela ausência)​

• Nenhuma métrica de usuário divulgada publicamente
• Nenhum dado de receita
• Nenhum conselho consultivo formal
• Nenhuma licença regulatória específica (estrutura de Hong Kong ainda não efetiva)

Desenvolvimentos recentes e roteiro​

Marcos recentes (2025):

• 8 de dezembro: Rodada seed de $5M anunciada (liderada pela YZi Labs)
• Novembro: AllScale Pay ativo na BNB Chain; parceria com Skill Afrika
• Outubro: Parceria com Ethscriptions para permanência L1
• Setembro: Lançamento do produto AllScale Invoice
• Agosto: Integração da BNB Chain com suporte a USD1
• Junho: Scale Stablecoin Summit em Hong Kong; financiamento pré-seed de $1.5M

Próximos passos:

• Q1 2026: Expansão para o mercado da América Latina
• Futuro: Opções de rendimento DeFi, capacidades cross-chain expandidas, soluções empresariais B2B

Conclusão​

A AllScale.io surge como uma startup legítima em estágio inicial, em vez de uma preocupação com golpes, apoiada por investidores credíveis e uma equipe transparente e verificável. O projeto aborda um problema de mercado real — o atrito nos pagamentos transfronteiriços para freelancers de mercados emergentes — com uma abordagem técnica bem pensada, alavancando a abstração de conta e as stablecoins.

No entanto, duas lacunas significativas exigem atenção antes de um envolvimento significativo: a completa ausência de auditorias de segurança públicas e a infraestrutura de código fechado que impede a verificação independente. Para uma plataforma que lida com fundos de usuários, essas omissões são preocupações materiais, independentemente das credenciais da equipe.

Classificação de risco geral: Moderado. O empreendimento mostra fortes sinais de legitimidade, mas carrega riscos inerentes ao estágio inicial. Usuários em potencial devem começar com pequenas quantias até que as auditorias de segurança sejam publicadas. Parceiros em potencial devem solicitar acesso direto às especificações técnicas e relatórios de auditoria. O projeto vale a pena ser monitorado à medida que amadurece, particularmente para quaisquer anúncios de auditoria de segurança no Q1 de 2026.

Imagine um mundo onde os usuários podem interagir com seu dApp de forma contínua, sem a necessidade de possuir tokens nativos (SUI). Isso não é mais um sonho distante. Com a Gas Station da Sui (também conhecida como Paymaster), os desenvolvedores podem cobrir as taxas de gás em nome de seus usuários, removendo completamente uma das maiores barreiras para novos participantes da Web3 e permitindo uma experiência on-chain verdadeiramente sem atritos.

Este artigo fornece um guia completo para atualizar seu dApp para ser sem gás. Vamos nos aprofundar nos conceitos centrais do Sui Paymaster, sua arquitetura, padrões de implementação e melhores práticas.

1. Contexto e Conceitos Centrais: O que é uma Transação Patrocinada?​

No mundo da blockchain, toda transação requer uma taxa de rede, ou "gás". Para usuários acostumados às experiências contínuas da Web2, isso é um obstáculo cognitivo e operacional significativo. A Sui aborda esse desafio no nível do protocolo com Transações Patrocinadas.

A ideia central é simples: permitir que uma parte (o Patrocinador) pague as taxas de gás SUI para a transação de outra parte (o Usuário). Dessa forma, mesmo que um usuário tenha zero SUI em sua carteira, ele ainda pode iniciar ações on-chain com sucesso.

Paymaster ≈ Gas Station​

No ecossistema Sui, a lógica para patrocinar transações é tipicamente tratada por um serviço off-chain ou on-chain chamado Gas Station ou Paymaster. Suas responsabilidades primárias incluem:

1. Avaliar a Transação: Ele recebe os dados da transação sem gás de um usuário (GasLessTransactionData).
2. Fornecer Gás: Ele bloqueia e aloca a taxa de gás necessária para a transação. Isso geralmente é gerenciado por meio de um pool de gás composto por muitos objetos SUI Coin.
3. Gerar uma Assinatura do Patrocinador: Após aprovar o patrocínio, a Gas Station assina a transação com sua chave privada (SponsorSig), certificando sua disposição em pagar a taxa.
4. Retornar a Transação Assinada: Ele envia de volta os TransactionData, que agora incluem os dados de gás e a assinatura do patrocinador, para aguardar a assinatura final do usuário.

Em suma, uma Gas Station atua como um serviço de reabastecimento para os usuários do seu dApp, garantindo que seus "veículos" (transações) possam viajar sem problemas na rede Sui.

2. Arquitetura de Alto Nível e Fluxo de Interação​

Uma transação típica sem gás envolve a coordenação entre o usuário, o frontend do dApp, a Gas Station e um Sui Full Node. A sequência de interação é a seguinte:

Detalhes do Fluxo:

1. O Usuário realiza uma ação na UI do dApp, que constrói um pacote de dados de transação sem nenhuma informação de gás.
2. O dApp envia esses dados para sua Gas Station designada para solicitar patrocínio.
3. A Gas Station verifica a validade da solicitação (por exemplo, verifica se o usuário é elegível para patrocínio), então preenche a transação com uma Gas Coin e sua assinatura, retornando a transação semi-completa para o dApp.
4. O Usuário vê os detalhes completos da transação em sua carteira (por exemplo, "Comprar um NFT") e fornece a assinatura final. Este é um passo crucial que garante que o usuário mantenha o consentimento e o controle sobre suas ações.
5. O dApp transmite a transação completa, contendo as assinaturas do usuário e do patrocinador, para um Sui Full Node.
6. Após a transação ser finalizada on-chain, a Gas Station pode confirmar isso ouvindo eventos ou recibos on-chain, e então notificar o backend do dApp via um webhook para fechar o ciclo do processo de negócio.

3. Três Modelos de Interação Principais​

Você pode usar os três modelos de interação a seguir individualmente ou em combinação para atender às suas necessidades de negócio.

Modelo 1: Iniciado pelo Usuário → Aprovado pelo Patrocinador (Mais Comum)​

Este é o modelo padrão, adequado para a grande maioria das interações dentro do dApp.

1. Usuário constrói GasLessTransactionData: O usuário realiza uma ação dentro do dApp.
2. Patrocinador adiciona GasData e assina: O backend do dApp envia a transação para a Gas Station, que a aprova, anexa uma Gas Coin e adiciona sua assinatura.
3. Usuário revisa e dá a assinatura final: O usuário confirma os detalhes finais da transação em sua carteira e a assina. O dApp então a submete à rede.

Este modelo atinge um excelente equilíbrio entre segurança e experiência do usuário.

Modelo 2: Airdrops/Incentivos Iniciados pelo Patrocinador​

Este modelo é perfeito para airdrops, incentivos a usuários ou distribuições em lote de ativos.

1. Patrocinador pré-preenche TransactionData + assina: O Patrocinador (tipicamente a equipe do projeto) pré-constrói a maior parte da transação (por exemplo, enviando um NFT por airdrop para um endereço específico) e anexa sua assinatura de patrocínio.
2. A segunda assinatura do usuário a torna efetiva: O usuário só precisa assinar esta transação "pré-aprovada" uma vez para que ela seja executada.

Isso cria uma experiência de usuário extremamente fluida. Com apenas um clique para confirmar, os usuários podem reivindicar recompensas ou completar tarefas, aumentando drasticamente as taxas de conversão de campanhas de marketing.

Modelo 3: GasData Curinga (Modelo de Linha de Crédito)​

Este é um modelo mais flexível e baseado em permissões.

1. Patrocinador transfere um objeto GasData: O Patrocinador primeiro cria um ou mais objetos Gas Coin com um orçamento específico e transfere a propriedade diretamente para o usuário.
2. Usuário gasta livremente dentro do orçamento: O usuário pode então usar livremente essas Gas Coins para pagar por quaisquer transações que ele inicie dentro dos limites e período de validade do orçamento.
3. Gas Coin é devolvida: Uma vez esgotado ou expirado, o objeto Gas Coin pode ser projetado para ser automaticamente destruído ou devolvido ao Patrocinador.

Este modelo é equivalente a dar ao usuário um "cartão de crédito de taxa de gás" com tempo e orçamento limitados, adequado para cenários que exigem um alto grau de autonomia do usuário, como oferecer uma experiência free-to-play durante uma temporada de jogo.

4. Cenários de Aplicação Típicos​

O poder do Sui Paymaster reside não apenas em resolver o problema da taxa de gás, mas também em sua capacidade de se integrar profundamente com a lógica de negócio para criar novas possibilidades.

Cenário 1: Paywalls​

Muitas plataformas de conteúdo ou serviços de dApp exigem que os usuários atendam a certos critérios (por exemplo, possuir um NFT VIP, atingir um certo nível de associação) para acessar recursos. O Paymaster pode implementar essa lógica perfeitamente.

• Fluxo: Um usuário solicita uma ação → o backend do dApp verifica as qualificações do usuário (por exemplo, posse de NFT) → se elegível, ele chama o Paymaster para patrocinar a taxa de gás; se não, ele simplesmente nega a solicitação de assinatura.
• Vantagem: Este modelo é inerentemente resistente a bots e abusos. Como a decisão de patrocínio é tomada no backend, usuários maliciosos não podem ignorar a verificação de qualificação para esgotar os fundos de gás.

Cenário 2: Checkout com Um Clique​

Em cenários de e-commerce ou compras dentro do jogo, simplificar o processo de pagamento é crítico.

• Fluxo: O usuário clica em "Comprar Agora" em uma página de checkout. O dApp constrói uma transação que inclui a lógica de negócio (por exemplo, transfer_nft_to_user). O usuário só precisa assinar para aprovar a transação de negócio em sua carteira, sem se preocupar com o gás. A taxa de gás é coberta pelo Patrocinador do dApp.
• Vantagem: Você pode codificar parâmetros de negócio como um order_id diretamente no ProgrammableTransactionBlock, permitindo uma atribuição on-chain precisa para pedidos de backend.

Cenário 3: Atribuição de Dados​

O rastreamento preciso de dados é fundamental para a otimização de negócios.

• Fluxo: Ao construir a transação, escreva um identificador único (como um order_hash) nos parâmetros da transação ou em um evento que será emitido após a execução.
• Vantagem: Quando a Gas Station recebe o recibo on-chain para uma transação bem-sucedida, ela pode facilmente extrair este order_hash analisando os dados do evento ou da transação. Isso permite um mapeamento preciso entre as mudanças de estado on-chain e pedidos de backend específicos ou ações do usuário.

5. Esqueleto de Código (Baseado no SDK Rust)​

Aqui está um trecho de código simplificado demonstrando os passos centrais de interação.

// Assume tx_builder, sponsor, and wallet have been initialized

// Step 1: On the user or dApp side, construct a gas-less transaction
let gasless_transaction_data = tx_builder.build_gasless_transaction_data(false)?;

// Step 2: On the Sponsor (Gas Station) side, receive the gasless_transaction_data,
// fill it with a Gas Coin, and return the transaction data with the Sponsor's signature.
// The sponsor_transaction_block function handles gas allocation and signing internally.
let sponsored_transaction = sponsor.sponsor_transaction_block(gasless_transaction_data, user_address, gas_budget)?;

// Step 3: The dApp sends the sponsored_transaction back to the user,
// who signs and executes it with their wallet.
let response = wallet.sign_and_execute_transaction_block(&sponsored_transaction)?;

Para uma implementação completa, consulte o Tutorial da Gas Station da documentação oficial da Sui, que oferece exemplos de código prontos para uso.

6. Riscos e Proteção​

Embora poderosa, a implantação de uma Gas Station em um ambiente de produção requer consideração cuidadosa dos seguintes riscos:

• Equivocação (Gasto Duplo): Um usuário malicioso pode tentar usar a mesma Gas Coin para múltiplas transações em paralelo, o que faria com que a Gas Coin fosse bloqueada pela rede Sui. Isso pode ser efetivamente mitigado atribuindo uma Gas Coin única por usuário ou transação, mantendo uma lista negra e limitando a taxa de solicitações de assinatura.
• Gerenciamento de Pool de Gás: Em cenários de alta concorrência, uma única Gas Coin de grande valor pode se tornar um gargalo de desempenho. O serviço da Gas Station deve ser capaz de dividir automaticamente grandes SUI Coins em muitas Gas Coins de menor valor e recuperá-las eficientemente após o uso. Provedores profissionais de Gas Station como a Shinami oferecem soluções maduras e gerenciadas para isso.
• Autorização e Limitação de Taxa: Você deve estabelecer políticas rigorosas de autorização e limitação de taxa. Por exemplo, gerenciar limites e frequências de patrocínio com base no IP do usuário, endereço da carteira ou tokens de API para evitar que o serviço seja esgotado por atores maliciosos.

7. Ferramentas do Ecossistema​

O ecossistema Sui já oferece um rico conjunto de ferramentas para simplificar o desenvolvimento e a implantação do Paymaster:

• SDKs Oficiais (Rust/TypeScript): Incluem APIs de alto nível como sponsor_transaction_block(), reduzindo significativamente a complexidade da integração.
• Shinami Gas Station: Fornece um serviço gerenciado completo, incluindo divisão/recuperação automatizada de Gas Coin, monitoramento detalhado de métricas e notificações por webhook, permitindo que os desenvolvedores se concentrem na lógica de negócio.
• Enoki / Mysten Demos: A comunidade e a Mysten Labs também fornecem implementações de Paymaster de código aberto que podem ser usadas como referência para construir seu próprio serviço.

8. Lista de Verificação de Implementação​

Pronto para atualizar seu dApp para a era sem gás? Revise esta lista de verificação antes de começar:

• Planeje Seu Fluxo de Financiamento: Defina a fonte de financiamento do Patrocinador, orçamento e estratégia de reabastecimento. Configure monitoramento e alertas para métricas chave (por exemplo, saldo do pool de gás, taxa de consumo).
• Reserve Campos de Atribuição: Ao projetar seus parâmetros de transação, certifique-se de reservar campos para identificadores de negócio como order_id ou user_id.
• Implante Políticas Anti-Abuso: Você deve implementar mecanismos rigorosos de autorização, limitação de taxa e registro antes de entrar em produção.
• Ensaie na Testnet: Seja construindo seu próprio serviço ou integrando uma Gas Station de terceiros, sempre conduza testes exaustivos de concorrência e estresse em uma testnet ou devnet primeiro.
• Otimize Continuamente: Após o lançamento, acompanhe continuamente as taxas de sucesso das transações, razões de falha e custos de gás. Ajuste seu orçamento e estratégias com base nos dados.

Conclusão​

O Sui Paymaster (Gas Station) é mais do que apenas uma ferramenta para cobrir as taxas de gás do usuário. É um paradigma poderoso que combina elegantemente uma experiência de usuário "zero SUI on-chain" com a necessidade de negócio de "atribuição on-chain em nível de pedido" dentro de uma única transação atômica. Ele abre o caminho para que usuários da Web2 entrem na Web3 e oferece aos desenvolvedores uma flexibilidade sem precedentes para personalização de negócios.

Com um ecossistema de ferramentas cada vez mais maduro e os atuais baixos custos de gás na rede Sui, nunca houve um momento melhor para atualizar os fluxos de pagamento e interação do seu dApp para a era sem gás.

Como eliminar o atrito da carteira, manter o fluxo de usuários e prever o potencial de crescimento

E se o seu aplicativo Web3 tivesse o mesmo fluxo de inscrição simplificado de um serviço Web2 moderno? Essa é a promessa central do zkLogin na blockchain Sui. Ele funciona como um OAuth para Sui, permitindo que os usuários façam login com contas familiares do Google, Apple, X e outras. Uma prova de conhecimento zero (zero-knowledge proof) vincula de forma segura essa identidade Web2 a um endereço Sui on-chain — sem pop-ups de carteira, sem frases de recuperação (seed phrases), sem rotatividade de usuários (churn).

O impacto é real e imediato. Com centenas de milhares de contas zkLogin já ativas, estudos de caso relatam ganhos massivos na conversão de usuários, saltando de meros 17 % para saudáveis 42 % após a remoção das barreiras tradicionais de carteira. Vamos detalhar como isso funciona e o que pode fazer pelo seu projeto.

Por que as Carteiras Matam a Conversão de Novos Usuários​

Você construiu um dApp inovador, mas seu funil de aquisição de usuários está com vazamentos. O culpado é quase sempre o mesmo: o botão "Conectar Carteira" (Connect Wallet). O onboarding padrão da Web3 é um labirinto de instalações de extensões, avisos de frases de recuperação e questionários de jargão cripto.

É uma barreira massiva para os recém-chegados. Pesquisadores de UX observaram uma queda impressionante de 87 % no momento em que um aviso de carteira aparecia. Em um experimento revelador, simplesmente redirecionar esse aviso para um estágio posterior no processo de checkout aumentou a taxa de conclusão para 94 %. Mesmo para usuários curiosos sobre cripto, o medo principal é: "Posso perder meus fundos se clicar no botão errado." Remover esse único passo intimidador é a chave para desbloquear um crescimento exponencial.

Como o zkLogin Funciona (em Linguagem Simples)​

O zkLogin contorna elegantemente o problema da carteira usando tecnologias em que todos os usuários da Internet já confiam. A mágica acontece nos bastidores em alguns passos rápidos:

1. Par de Chaves Efêmeras: Quando um usuário deseja fazer login, um par de chaves temporário de sessão única é gerado localmente em seu navegador. Pense nisso como uma chave de acesso temporária, válida apenas para esta sessão.
2. Dança do OAuth: O usuário faz login com sua conta do Google, Apple ou outra conta social. Seu aplicativo incorpora de forma inteligente um valor exclusivo (nonce) nesta solicitação de login.
3. Serviço ZKP: Após um login bem-sucedido, um serviço ZKP (Zero-Knowledge Proof) gera uma prova criptográfica. Esta prova confirma: "Este token OAuth autoriza o proprietário da chave de acesso temporária", sem nunca revelar a identidade pessoal do usuário on-chain.
4. Derivar Endereço: O JWT (JSON Web Token) do usuário, fornecido pelo provedor OAuth, é combinado com um salt exclusivo para gerar deterministicamente seu endereço Sui permanente. O salt é mantido privado, seja no lado do cliente ou em um backend seguro.
5. Enviar Transação: Seu aplicativo assina transações with a chave temporária e anexa a prova ZK. Os validadores da Sui verificam a prova on-chain, confirmando a legitimidade da transação sem que o usuário precise de uma carteira tradicional.

Guia de Integração Passo a Passo​

Pronto para implementar isso? Aqui está um guia rápido usando o SDK do TypeScript. Os princípios são idênticos para Rust ou Python.

1. Instalar o SDK​

O pacote @mysten/sui inclui todos os utilitários de zklogin que você precisará.

pnpm add @mysten/sui

2. Gerar Chaves e Nonce​

Primeiro, crie um par de chaves efêmero e um nonce vinculado à época (epoch) atual na rede Sui.

const keypair = new Ed25519Keypair();
const { epoch } = await suiClient.getLatestSuiSystemState();
const nonce = generateNonce(keypair.getPublicKey(), Number(epoch) + 2, generateRandomness());

3. Redirecionar para o OAuth​

Construa a URL de login OAuth apropriada para o provedor que você está usando (ex: Google, Facebook, Apple) e redirecione o usuário.

4. Decodificar JWT e Buscar Salt do Usuário​

Após o login e o redirecionamento de volta, obtenha o id_token da URL. Use-o para buscar o salt específico do usuário em seu backend e, em seguida, derive o endereço Sui dele.

const jwt = new URLSearchParams(window.location.search).get('id_token')!;
const salt = await fetch('/api/salt?jwt=' + jwt).then(r => r.text());
const address = jwtToAddress(jwt, salt);

5. Solicitar Prova ZK​

Envie o JWT para um serviço de prova (prover service) para obter a prova ZK. Para desenvolvimento, você pode usar o provador público da Mysten. Em produção, você deve hospedar o seu próprio ou usar um serviço como o Enoki.

const proof = await fetch('/api/prove', {
  method: 'POST',
  body: JSON.stringify({ jwt, ... })
}).then(r => r.json());

6. Assinar e Enviar​

Agora, construa sua transação, defina o remetente como o endereço zkLogin do usuário e execute-a. O SDK cuida de anexar os zkLoginInputs (a prova) automaticamente. ✨

const tx = new TransactionBlock();
tx.moveCall({ target: '0x2::example::touch_grass' }); // Qualquer chamada Move
tx.setSender(address);
tx.setGasBudget(5_000_000);

await suiClient.signAndExecuteTransactionBlock({
  transactionBlock: tx,
  zkLoginInputs: proof // A mágica acontece aqui
});

7. Persistir Sessão​

Para uma experiência de usuário mais fluida, criptografe e armazene o par de chaves e o salt no IndexedDB ou no armazenamento local (local storage). Lembre-se de rotacioná-los a cada poucas épocas para maior segurança.

Modelo de Projeção de KPI​

A diferença que o zkLogin faz não é apenas qualitativa; é quantificável. Compare um funil de integração típico com um potencializado pelo zkLogin:

👉 O que isso significa: Para uma campanha que atrai 10.000 visitantes únicos, essa é a diferença entre 300 ações on-chain no primeiro dia e mais de 2.500.

Melhores Práticas e Pontos de Atenção​

Para criar uma experiência ainda mais fluida, mantenha estas dicas profissionais em mente:

• Use Transações Patrocinadas: Pague pelas taxas das primeiras transações dos seus usuários. Isso remove todo o atrito e proporciona um momento "aha" incrível.
• Manipule os Salts com Cuidado: Alterar o salt de um usuário gerará um novo endereço. Só faça isso se você controlar um caminho de recuperação confiável para eles.
• Exponha o Endereço Sui: Após o cadastro, mostre aos usuários o endereço on-chain deles. Isso permite que usuários avançados o importem para uma carteira tradicional mais tarde, se desejarem.
• Evite Loops de Atualização: Armazene em cache o JWT e o par de chaves efêmeras até que expirem para evitar pedir ao usuário que faça login repetidamente.
• Monitore a Latência do Provador: Fique de olho no tempo de ida e volta da geração da prova. Se exceder 2 segundos, considere hospedar um provador regional para manter as coisas rápidas.

Onde o BlockEden.xyz Agrega Valor​

Embora o zkLogin aperfeiçoe o fluxo voltado para o usuário, escalá-lo introduz novos desafios de backend. É aí que o BlockEden.xyz entra.

• Camada de API: Nossos nós RPC de alto rendimento e roteamento geográfico garantem que suas transações zkLogin sejam processadas com latência mínima, independentemente da localização do usuário.
• Observabilidade: Obtenha painéis prontos para uso para acompanhar métricas importantes como latência de prova, taxas de sucesso/falha e a integridade do seu funil de conversão.
• Conformidade: Para aplicativos que fazem a ponte para moedas fiduciárias, nosso módulo opcional de KYC fornece um on-ramp em conformidade diretamente da identidade verificada do usuário.

Pronto para Lançar?​

A era dos fluxos de carteira desajeitados e intimidadores acabou. Ative um sandbox zkLogin, conecte o endpoint de full-node da BlockEden e veja seu gráfico de cadastros subir — enquanto seus usuários nem precisam ouvir a palavra “carteira”. 😉

Por anos, o mundo cripto tem sido atrapalhado por um problema crítico de usabilidade: a carteira. Carteiras tradicionais, conhecidas como Contas Externamente Possuídas (EOAs), são implacáveis. Uma única frase‑semente perdida significa que seus fundos desaparecem para sempre. Cada ação requer uma assinatura, e as taxas de gás devem ser pagas no token nativo da cadeia. Essa experiência pesada e de alto risco é uma barreira importante para a adoção em massa.

Surge então a Abstração de Conta (AA), uma mudança de paradigma que promete redefinir como interagimos com a blockchain. No seu cerne, a AA transforma a conta do usuário em um contrato inteligente programável, desbloqueando recursos como recuperação social, transações de um clique e pagamentos de gás flexíveis.

A jornada rumo a esse futuro mais inteligente está se desenrolando por três caminhos distintos: o ERC‑4337, já testado em batalha; a AA Nativa, eficiente; e o tão aguardado EIP‑7702. Vamos analisar o que cada abordagem significa para desenvolvedores e usuários.

💡 Caminho 1: O Pioneiro — ERC‑4337​

O ERC‑4337 foi a ruptura que trouxe a abstração de conta para Ethereum e cadeias EVM sem alterar o protocolo central. Pense nele como uma camada inteligente adicionada ao sistema existente.

Ele introduz um novo fluxo de transação envolvendo:

• UserOperations: um novo objeto que representa a intenção do usuário (ex.: “trocar 100 USDC por ETH”).
• Bundlers: atores off‑chain que coletam UserOperations, as agrupam e as enviam à rede.
• EntryPoint: um contrato inteligente global que valida e executa as operações agrupadas.

O Positivo:

• Compatibilidade Universal: pode ser implantado em qualquer cadeia EVM.
• Flexibilidade: permite recursos avançados como chaves de sessão para jogos, segurança multi‑assinatura e patrocínio de gás via Paymasters.

O Trade‑off:

• Complexidade & Custo: introduz uma sobrecarga de infraestrutura significativa (execução de Bundlers) e tem os maiores custos de gás dos três métodos, já que cada operação passa pela lógica extra do EntryPoint. Por isso, sua adoção floresceu principalmente em L2s econômicas como Base e Polygon.

O ERC‑4337 abriu caminho para que outras soluções de AA pudessem existir. Ele provou a demanda e lançou as bases para uma experiência Web3 mais intuitiva.

🚀 Caminho 2: O Ideal Integrado — Abstração de Conta Nativa​

Se o ERC‑4337 é um add‑on, a AA Nativa incorpora recursos inteligentes diretamente na fundação da blockchain. Cadeias como zkSync Era e Starknet foram projetadas desde o início com a AA como princípio central. Nessas redes, toda conta é um contrato inteligente.

O Positivo:

• Eficiência: ao integrar a lógica de AA ao protocolo, elimina‑se as camadas extras, resultando em custos de gás significativamente menores comparados ao ERC‑4337.
• Simplicidade para Devs: desenvolvedores não precisam gerenciar Bundlers nem um mempool separado. O fluxo de transação se assemelha muito ao padrão.

O Trade‑off:

• Fragmentação do Ecossistema: a AA Nativa é específica de cada cadeia. Uma conta no zkSync é diferente de uma conta no Starknet, e nenhuma delas é nativa da mainnet Ethereum. Isso cria uma experiência fragmentada para usuários e desenvolvedores que trabalham em múltiplas cadeias.

A AA Nativa nos mostra o “fim de jogo” em termos de eficiência, mas sua adoção está atrelada ao crescimento dos ecossistemas que a hospedam.

🌉 Caminho 3: A Ponte Pragmática — EIP‑7702​

Previsto para ser incluído na atualização “Pectra” de 2025 da Ethereum, o EIP‑7702 é um divisor de águas projetado para levar recursos de AA às massas de usuários de EOAs existentes. Ele adota uma abordagem híbrida: permite que um EOA delegue temporariamente sua autoridade a um contrato inteligente para uma única transação.

Pense nisso como conceder superpoderes temporários ao seu EOA. Você não precisa migrar fundos nem mudar de endereço. Sua carteira pode simplesmente adicionar uma autorização a uma transação, permitindo executar operações agrupadas (ex.: aprovação + troca em um clique) ou ter seu gás patrocinado.

O Positivo:

• Compatibilidade Retroativa: funciona com os bilhões de dólares protegidos por EOAs atuais. Nenhuma migração necessária.
• Baixa Complexidade: usa o pool de transações padrão, eliminando a necessidade de Bundlers e simplificando drasticamente a infraestrutura.
• Catalisador de Adoção em Massa: ao tornar recursos inteligentes acessíveis a todo usuário Ethereum da noite para o dia, pode acelerar rapidamente a adoção de padrões de UX melhores.

O Trade‑off:

• Não é “AA Completa”: o EIP‑7702 não resolve a gestão de chaves para o próprio EOA. Se você perder sua chave privada, ainda estará sem acesso. Ele foca mais em aprimorar as capacidades de transação do que em reformular a segurança da conta.

Comparação Lado a Lado​

O Futuro é Convergente e Centrado no Usuário​

Esses três caminhos não são mutuamente exclusivos; eles convergem para um futuro onde a carteira deixa de ser ponto de atrito.

1. Recuperação Social Torna‑se Padrão 🛡️: A era de “chaves perdidas, fundos perdidos” está terminando. A AA permite recuperação baseada em guardiões, tornando a autocustódia tão segura e indulgente quanto uma conta bancária tradicional.
2. UX de Jogos Reimaginada 🎮: Chaves de sessão permitirão jogabilidade fluida sem pop‑ups constantes de “aprovar transação”, finalmente fazendo os jogos Web3 se sentirem como jogos Web2.
3. Carteiras como Plataformas Programáveis: As carteiras se tornarão modulares. Usuários poderão adicionar um “módulo DeFi” para farming automatizado ou um “módulo de segurança” que exija 2FA para transferências grandes.

Para desenvolvedores e provedores de infraestrutura como Blockeden.xyz, essa evolução é extremamente empolgante. A complexidade de Bundlers, Paymasters e os diversos padrões de AA cria uma oportunidade enorme para oferecer infraestrutura robusta, confiável e abstraída. O objetivo é uma experiência unificada onde o desenvolvedor possa integrar recursos de AA facilmente, e a carteira escolha inteligentemente entre ERC‑4337, AA Nativa ou EIP‑7702 conforme a cadeia suporte.

A carteira finalmente recebe a atualização que merece. A transição de EOAs estáticas para contas inteligentes dinâmicas não é apenas uma melhoria — é a revolução que tornará o Web3 acessível e seguro para o próximo bilhão de usuários.

Olá e bem‑vindo de volta ao nosso blog de blockchain! Hoje, vamos mergulhar em uma proposta empolgante chamada ERC-4337, que introduz a abstração de conta ao Ethereum sem exigir mudanças no protocolo da camada de consenso. Em vez disso, essa proposta depende de infraestrutura de camada superior para alcançar seus objetivos. Vamos explorar o que o ERC-4337 tem a oferecer e como ele resolve as limitações do ecossistema Ethereum atual.

O que é ERC-4337?​

ERC-4337 é uma proposta que introduz a abstração de conta ao Ethereum por meio do uso de um mempool separado e de um novo tipo de objeto pseudo‑transação chamado UserOperation. Usuários enviam objetos UserOperation para o mempool alternativo, onde uma classe especial de atores chamada bundlers os empacota em uma transação que faz uma chamada handleOps a um contrato dedicado. Essas transações são então incluídas em um bloco.

A proposta visa alcançar vários objetivos:

1. Permitir que os usuários utilizem carteiras de contrato inteligente com lógica de verificação arbitrária como suas contas principais.
2. Eliminar completamente a necessidade de contas externamente possuídas (EOAs).
3. Garantir descentralização ao permitir que qualquer bundler participe do processo de inclusão de operações de usuário abstraídas.
4. Permitir que toda a atividade ocorra em um mempool público, eliminando a necessidade de os usuários conhecerem endereços de comunicação direta de atores específicos.
5. Evitar suposições de confiança nos bundlers.
6. Evitar a necessidade de alterações no consenso do Ethereum para uma adoção mais rápida.
7. Suportar outros casos de uso, como aplicações que preservam privacidade, operações atômicas múltiplas, pagamento de taxas de transação com tokens ERC‑20 e transações patrocinadas por desenvolvedores.

Compatibilidade Retroativa​

Como o ERC-4337 não altera a camada de consenso, não há problemas diretos de compatibilidade retroativa para o Ethereum. Contudo, contas pré‑ERC‑4337 não são facilmente compatíveis com o novo sistema porque carecem da função validateUserOp necessária. Isso pode ser resolvido criando uma conta compatível com ERC‑4337 que re‑implementa a lógica de verificação como um wrapper e definindo‑a como o remetente de operação confiável da conta original.

Implementação de Referência​

Para quem deseja aprofundar nos detalhes técnicos do ERC‑4337, uma implementação de referência está disponível em https://github.com/eth-infinitism/account-abstraction/tree/main/contracts.

Considerações de Segurança​

O contrato de ponto de entrada para o ERC‑4337 deve ser amplamente auditado e formalmente verificado, pois serve como ponto central de confiança para todo o sistema. Embora essa abordagem reduza a carga de auditoria e verificação formal para contas individuais, ela concentra o risco de segurança no contrato de ponto de entrada, que deve ser robustamente verificado.

A verificação deve cobrir duas reivindicações principais:

1. Segurança contra sequestro arbitrário: o ponto de entrada só chama uma conta genericamente se validateUserOp para essa conta específica tiver sido aprovado.
2. Segurança contra drenagem de taxas: se o ponto de entrada chamar validateUserOp e passar, ele também deve fazer a chamada genérica com calldata igual a op.calldata.

Conclusão​

ERC‑4337 é uma proposta empolgante que visa introduzir a abstração de conta ao Ethereum sem exigir mudanças no protocolo da camada de consenso. Ao usar infraestrutura de camada superior, abre novas possibilidades para descentralização, flexibilidade e diversos casos de uso. Embora existam considerações de segurança a serem abordadas, essa proposta tem o potencial de melhorar significativamente o ecossistema Ethereum e a experiência do usuário.