59 postagens marcadas com "Blockchain"

As exchanges descentralizadas (DEXs) amadureceram e tornaram-se pilares centrais da negociação de cripto, capturando agora cerca de 20% do volume total do mercado. Dentro deste espaço, a Hyperliquid emergiu como a líder indiscutível em derivativos on-chain. Lançada em 2022 com o objetivo ambicioso de igualar o desempenho das exchanges centralizadas (CEX) on-chain, a Hyperliquid hoje processa milhares de milhões em negociações diárias e controla cerca de 70–75% do mercado de futuros perpétuos de DEXs. Consegue isto combinando a velocidade de nível CEX e a liquidez profunda com a transparência e autocustódia do DeFi. O resultado é uma blockchain e exchange Layer-1 verticalmente integrada que muitos agora chamam de “a blockchain para abrigar todas as finanças”. Este relatório aprofunda a arquitetura técnica, tokenomics, métricas de crescimento para 2025, comparações com outros líderes de DEX, desenvolvimentos do ecossistema e a sua visão para o futuro das finanças on-chain.

Arquitetura Técnica: Uma Chain Verticalmente Integrada e de Alto Desempenho

A Hyperliquid não é apenas uma aplicação de DEX – é uma blockchain Layer-1 completa, construída para o desempenho de negociação. A sua arquitetura consiste em três componentes fortemente acoplados que operam num estado unificado:

• HyperBFT (Consenso): Um mecanismo de consenso personalizado Tolerante a Falhas Bizantinas, otimizado para velocidade e débito. Inspirado em protocolos modernos como o HotStuff, o HyperBFT proporciona finalidade em menos de um segundo e alta consistência para garantir que todos os nós concordem com a ordem das transações. Este consenso Proof-of-Stake foi projetado para lidar com a carga intensa de uma plataforma de negociação, suportando na prática cerca de 100.000–200.000 operações por segundo. No início de 2025, a Hyperliquid tinha cerca de 27 validadores independentes a proteger a rede, um número que está a crescer de forma constante para descentralizar o consenso.
• HyperCore (Motor de Execução): Um motor on-chain especializado para aplicações financeiras. Em vez de usar contratos inteligentes genéricos para a lógica crítica da exchange, o HyperCore implementa livros de ordens de limite central (CLOBs) integrados para futuros perpétuos e mercados spot, bem como outros módulos para empréstimos, leilões, oráculos e mais. Cada colocação de ordem, cancelamento, correspondência de negociação e liquidação é processada on-chain com finalidade de um bloco, resultando em velocidades de execução comparáveis às das exchanges tradicionais. Ao evitar AMMs e lidar com a correspondência de ordens dentro do protocolo, a Hyperliquid alcança liquidez profunda e baixa latência – demonstrou finalidade de negociação <1s e um débito que rivaliza com os locais centralizados. Esta camada de execução personalizada (escrita em Rust) pode, segundo relatos, lidar com até 200.000 ordens por segundo após otimizações recentes, eliminando os estrangulamentos que anteriormente tornavam os livros de ordens on-chain inviáveis.
• HyperEVM (Contratos Inteligentes): Uma camada de execução de propósito geral compatível com Ethereum introduzida em fevereiro de 2025. A HyperEVM permite que os desenvolvedores implementem contratos inteligentes em Solidity e dApps na Hyperliquid com total compatibilidade EVM, semelhante a construir no Ethereum. Crucialmente, a HyperEVM não é um shard ou rollup separado – partilha o mesmo estado unificado com o HyperCore. Isto significa que as dApps na HyperEVM podem interoperar nativamente com os livros de ordens e a liquidez da exchange. Por exemplo, um protocolo de empréstimo na HyperEVM pode ler preços em tempo real do livro de ordens do HyperCore ou até mesmo publicar ordens de liquidação diretamente no livro de ordens através de chamadas de sistema. Esta componibilidade entre contratos inteligentes e a camada de exchange de alta velocidade é um design único: não são necessárias pontes ou oráculos off-chain para que as dApps aproveitem a infraestrutura de negociação da Hyperliquid.

Figura: Arquitetura verticalmente integrada da Hyperliquid mostrando o estado unificado entre o consenso (HyperBFT), o motor da exchange (HyperCore), os contratos inteligentes (HyperEVM) e a ponte de ativos (HyperUnit).

Integração com Infraestrutura On-Chain: Ao construir a sua própria chain, a Hyperliquid integra firmemente funções normalmente isoladas numa única plataforma. A HyperUnit, por exemplo, é o módulo descentralizado de ponte e tokenização de ativos da Hyperliquid que permite depósitos diretos de ativos externos como BTC, ETH e SOL sem wrappers custodiais. Os utilizadores podem bloquear BTC ou ETH nativos e receber tokens equivalentes (por exemplo, uBTC, uETH) na Hyperliquid para usar como garantia de negociação, sem depender de custodiantes centralizados. Este design proporciona “verdadeira mobilidade de garantia” e uma estrutura mais consciente da regulamentação para trazer ativos do mundo real para a on-chain. Graças à HyperUnit (e à integração do USDC da Circle discutida mais tarde), os traders na Hyperliquid podem mover liquidez de outras redes para o ambiente de exchange rápido da Hyperliquid de forma transparente.

Desempenho e Latência: Todas as partes da stack são otimizadas para latência mínima e débito máximo. O HyperBFT finaliza blocos em menos de um segundo, e o HyperCore processa negociações em tempo real, para que os utilizadores experienciem uma execução de ordens quase instantânea. Efetivamente, não há taxas de gás para ações de negociação – as transações do HyperCore são isentas de taxas, permitindo a colocação e cancelamento de ordens de alta frequência sem custo para os utilizadores. (As chamadas normais de contrato EVM na HyperEVM incorrem numa baixa taxa de gás, mas as operações da exchange funcionam sem gás no motor nativo.) Este design de zero gás e baixa latência torna viáveis funcionalidades de negociação avançadas on-chain. De facto, a Hyperliquid suporta os mesmos tipos de ordens avançadas e controlos de risco que as principais CEXs, como ordens de limite e stop, margem cruzada e até 50× de alavancagem nos principais mercados. Em suma, a chain L1 personalizada da Hyperliquid elimina o tradicional compromisso entre velocidade e descentralização. Cada operação é on-chain e transparente, mas a experiência do utilizador – em termos de velocidade de execução e interface – é paralela à de uma exchange centralizada profissional.

Evolução e Escalabilidade: A arquitetura da Hyperliquid nasceu de uma engenharia de primeiros princípios. O projeto foi lançado discretamente em 2022 como uma DEX de perpétuos em alfa fechado numa chain personalizada baseada em Tendermint, provando o conceito de CLOB com ~20 ativos e alavancagem de 50×. Em 2023, transitou para uma L1 totalmente soberana com o novo consenso HyperBFT, alcançando mais de 100.000 ordens por segundo e introduzindo negociação sem gás e pools de liquidez comunitárias. A adição da HyperEVM no início de 2025 abriu as portas para os desenvolvedores, marcando a evolução da Hyperliquid de uma exchange de propósito único para uma plataforma DeFi completa. Notavelmente, todas estas melhorias mantiveram o sistema estável – a Hyperliquid relata 99,99% de tempo de atividade historicamente[25]_. Este historial e integração vertical dão à Hyperliquid um fosso técnico significativo: controla toda a stack (consenso, execução, aplicação), permitindo uma otimização contínua. À medida que a procura cresce, a equipa continua a refinar o software do nó para um débito ainda maior, garantindo a escalabilidade para a próxima onda de utilizadores e mercados on-chain mais complexos.

Tokenomics do $HYPE: Governança, Staking e Acumulação de Valor

O design económico da Hyperliquid centra-se no seu token nativo $HYPE**, introduzido no final de 2024 para descentralizar a propriedade e a governança da plataforma. O lançamento e a distribuição do token foram notavelmente _centrados na comunidade_: em novembro de 2024, a Hyperliquid realizou um Evento de Geração de Tokens (TGE) por airdrop, alocando **31$HYPE não teve alocações para VCs ou investidores privados, refletindo uma filosofia de priorizar a propriedade da comunidade. Esta distribuição transparente visava evitar a pesada propriedade de insiders vista em muitos projetos e, em vez disso, capacitar os verdadeiros traders e construtores na Hyperliquid.

O token $HYPE desempenha múltiplos papéis no ecossistema da Hyperliquid:

• Governança: O $HYPE é um token de governança que permite aos detentores votar em Propostas de Melhoria da Hyperliquid (HIPs) e moldar a evolução do protocolo. Já foram aprovadas atualizações críticas como HIP-1, HIP-2 e HIP-3, que estabeleceram padrões de listagem sem permissão para tokens spot e mercados perpétuos. Por exemplo, a HIP-3 abriu a capacidade para membros da comunidade implementarem novos mercados perpétuos sem permissão, muito como a Uniswap fez para a negociação spot, desbloqueando ativos de cauda longa (incluindo perpétuos de mercados tradicionais) na Hyperliquid. A governança decidirá cada vez mais sobre listagens, ajustes de parâmetros e o uso de fundos de incentivo comunitário.
• Staking e Segurança da Rede: A Hyperliquid é uma chain Proof-of-Stake, portanto, **fazer staking de $HYPE para validadores protege a rede HyperBFT**. Os stakers delegam a validadores e ganham uma porção das recompensas de bloco e taxas. Pouco depois do lançamento, a Hyperliquid habilitou o staking com um **rendimento anual de ~2–2,5$HYPE em staking (ou formas derivadas como o futuro staking líquido beHYPE) também pode ser usado na votação de governança, alinhando os participantes da segurança com a tomada de decisões.
• Utilidade na Exchange (Descontos de Taxas): Deter ou fazer staking de $HYPE confere **descontos nas taxas de negociação** na exchange da Hyperliquid. Semelhante a como o token BNB da Binance ou o DYDX da dYdX oferecem taxas reduzidas, os traders ativos são incentivados a deter$HYPE para minimizar os seus custos. Isto cria uma procura natural pelo token entre a base de utilizadores da exchange, especialmente traders de alto volume.
• Acumulação de Valor via Recompras: O aspeto mais marcante da tokenomics da Hyperliquid é o seu agressivo mecanismo de taxa-para-valor. A Hyperliquid usa a grande maioria da sua receita de taxas de negociação para recomprar e queimar $HYPE no mercado aberto, devolvendo valor diretamente aos detentores de tokens. De facto, **97$HYPE** (e o restante para um fundo de seguro e provedores de liquidez). Esta é uma das taxas de retorno de taxas mais altas da indústria. Em meados de 2025, a Hyperliquid estava a gerar mais de 65 milhões de dólares em receita de protocolo por mês a partir de taxas de negociação – e praticamente tudo isso foi destinado a recompras de $HYPE, criando uma pressão de compra constante. Este modelo de token deflacionário, combinado com uma oferta fixa de 1 mil milhões, significa que a tokenomics do$HYPE está orientada para a acumulação de valor a longo prazo para os stakeholders leais. Também sinaliza que a equipa da Hyperliquid abdica do lucro a curto prazo (nenhuma receita de taxas é tomada como lucro ou distribuída a insiders; até mesmo a equipa principal presumivelmente só beneficia como detentora de tokens), em vez disso, canalizando a receita para o tesouro da comunidade e o valor do token.

• Recompensas para Provedores de Liquidez: Uma pequena porção das taxas (≈3–8%) é usada para recompensar os provedores de liquidez na única Pool de HiperLiquidez (HLP) da Hyperliquid. A HLP é uma pool de liquidez USDC on-chain que facilita o market-making e a liquidação automática para os livros de ordens, análoga a um “cofre de LP”. Os utilizadores que fornecem USDC à HLP ganham uma parte das taxas de negociação em troca. No início de 2025, a HLP estava a oferecer aos depositantes um rendimento anualizado de ~11% a partir das taxas de negociação acumuladas. Este mecanismo permite que os membros da comunidade partilhem do sucesso da exchange, contribuindo com capital para apoiar a liquidez (semelhante em espírito à pool GLP da GMX, mas para um sistema de livro de ordens). Notavelmente, o Fundo de Assistência de seguro da Hyperliquid (denominado em $HYPE) também usa uma porção da receita para cobrir quaisquer perdas da HLP ou eventos invulgares – por exemplo, um _exploit “Jelly” no primeiro trimestre de 2025_ incorreu num défice de 12 milhões de dólares na HLP, que foi totalmente reembolsado aos utilizadores da pool. O modelo de recompra de taxas foi tão robusto que, apesar desse golpe, as recompras de$HYPE continuaram inabaláveis e a HLP permaneceu lucrativa, demonstrando um forte alinhamento entre o protocolo e os seus provedores de liquidez comunitários.

Em resumo, a tokenomics da Hyperliquid enfatiza a propriedade comunitária, a segurança e a sustentabilidade a longo prazo. A ausência de alocações para VCs e a alta taxa de recompra foram decisões que sinalizaram confiança no crescimento orgânico. Os resultados iniciais foram positivos – desde o seu TGE, o preço do $HYPE subiu 4× (em meados de 2025) com base na adoção e receita reais. Mais importante, os utilizadores permaneceram engajados após o airdrop; a atividade de negociação na verdade acelerou após o lançamento do token, em vez de sofrer a típica queda pós-incentivo. Isto sugere que o modelo do token está a alinhar com sucesso os incentivos dos utilizadores com o crescimento da plataforma, criando um ciclo virtuoso para o ecossistema da Hyperliquid.

Volume de Negociação, Adoção e Liquidez em 2025

A Hyperliquid em Números: Em 2025, a Hyperliquid destaca-se não apenas pela sua tecnologia, mas pela escala pura da sua atividade on-chain. Tornou-se rapidamente a maior exchange de derivativos descentralizada por uma larga margem, estabelecendo novos benchmarks para o DeFi. As principais métricas que ilustram a tração da Hyperliquid incluem:

• Domínio de Mercado: A Hyperliquid lida com aproximadamente 70–77% de todo o volume de futuros perpétuos de DEXs em 2025 – uma fatia 8× maior que o próximo concorrente. Por outras palavras, a Hyperliquid por si só representa bem mais de três quartos da negociação de perpétuos descentralizada em todo o mundo, tornando-a a líder clara na sua categoria. (Para contexto, no primeiro trimestre de 2025, isto equivalia a cerca de 56–73% do volume de perpétuos descentralizados, acima dos ~4,5% no início de 2024 – uma ascensão impressionante em um ano.)
• Volumes de Negociação: O volume de negociação acumulado na Hyperliquid ultrapassou 1,5 biliões de dólares em meados de 2025, destacando quanta liquidez fluiu através dos seus mercados. No final de 2024, a exchange já via volumes diários em torno de 10–14 mil milhões de dólares, e o volume continuou a subir com novos influxos de utilizadores em 2025. De facto, durante picos de atividade de mercado (por exemplo, uma febre de memecoins em maio de 2025), o volume de negociação semanal da Hyperliquid atingiu até 780 mil milhões de dólares numa semana – com uma média bem acima de 100 mil milhões de dólares por dia – rivalizando ou excedendo muitas exchanges centralizadas de médio porte. Mesmo em condições estáveis, a Hyperliquid estava com uma média de aproximadamente 470 mil milhões de dólares em volume semanal na primeira metade de 2025. Esta escala é sem precedentes para uma plataforma DeFi; em meados de 2025, a Hyperliquid executava cerca de 6% de *todo* o volume de negociação de cripto globalmente (incluindo CEXs), diminuindo a lacuna entre DeFi e CeFi.
• Open Interest e Liquidez: A profundidade dos mercados da Hyperliquid também é evidente no seu open interest (OI) – o valor total das posições ativas. O OI cresceu de ~$3,3 mil milhões no final de 2024 para cerca de 15 mil milhões de dólares em meados de 2025. Para perspetiva, este OI é cerca de 60–120% dos níveis em grandes CEXs como Bybit, OKX ou Bitget, indicando que traders profissionais estão tão confortáveis em implementar grandes posições na Hyperliquid como em locais centralizados estabelecidos. A profundidade do livro de ordens na Hyperliquid para pares principais como BTC ou ETH é relatada como comparável às principais CEXs, com spreads de compra e venda apertados. Durante certos lançamentos de tokens (por exemplo, a popular memecoin PUMP), a Hyperliquid até alcançou a liquidez mais profunda e o maior volume de qualquer local, superando as CEXs para esse ativo. Isto mostra como um livro de ordens on-chain, quando bem projetado, pode igualar a liquidez de uma CEX – um marco na evolução das DEXs.
• Utilizadores e Adoção: A base de utilizadores da plataforma expandiu-se dramaticamente durante 2024–2025. A Hyperliquid ultrapassou 500.000 endereços de utilizadores únicos em meados de 2025. Apenas na primeira metade de 2025, a contagem de endereços ativos quase duplicou (de ~291k para 518k). Este crescimento de 78% em seis meses foi impulsionado pelo boca-a-boca, um programa de referência e pontos bem-sucedido, e o burburinho em torno do airdrop do $HYPE (que curiosamente reteve os utilizadores em vez de apenas atrair mercenários – não houve queda no uso após o airdrop, e a atividade continuou a subir). Tal crescimento indica não apenas curiosidade pontual, mas adoção genuína por parte dos traders. Acredita-se que uma porção significativa destes utilizadores sejam “baleias” e traders profissionais que migraram de CEXs, atraídos pela liquidez e taxas mais baixas da Hyperliquid. De facto, instituições e empresas de negociação de alto volume começaram a tratar a Hyperliquid como um local primário para a negociação de perpétuos, validando o apelo do DeFi quando os problemas de desempenho são resolvidos.
• Receita e Taxas: Os volumes robustos da Hyperliquid traduzem-se em receita substancial para o protocolo (que, como notado, acumula em grande parte para recompras de $HYPE). Nos últimos 30 dias (em meados de 2025), a Hyperliquid gerou cerca de 65,45 milhões de dólares em taxas de protocolo. Diariamente, isso representa aproximadamente 2,0–2,5 milhões de dólares em taxas ganhas com a atividade de negociação. Anualizado, a plataforma está a caminho de mais de 800 milhões de dólares em receita – um número espantoso que se aproxima das receitas de algumas grandes exchanges centralizadas, e muito acima dos protocolos DeFi típicos. Isto sublinha como o alto volume e a estrutura de taxas da Hyperliquid (pequenas taxas por negociação que se somam em escala) produzem um modelo de receita próspero para apoiar a sua economia de tokens.
• Valor Total Bloqueado (TVL) e Ativos: O TVL do ecossistema da Hyperliquid – representando ativos transferidos para a sua chain e liquidez nos seus protocolos DeFi – subiu rapidamente juntamente com a atividade de negociação. No início do quarto trimestre de 2024 (pré-token), o TVL da chain da Hyperliquid era de cerca de 0,5 mil milhões de dólares, mas após o lançamento do token e a expansão da HyperEVM, o TVL disparou para mais de 2 mil milhões de dólares no início de 2025. Em meados de 2025, atingiu aproximadamente 3,5 mil milhões de dólares (30 de junho de 2025) e continuou a subir. A introdução do USDC nativo (via Circle) e outros ativos impulsionou o capital on-chain para um estimado de 5,5 mil milhões de dólares em AUM até julho de 2025. Isto inclui ativos na pool HLP, pools de empréstimo DeFi, AMMs e saldos de garantia dos utilizadores. A Pool de HiperLiquidez (HLP) da Hyperliquid por si só detinha um TVL em torno de 370–500 milhões de dólares no primeiro semestre de 2025, fornecendo uma reserva de liquidez USDC profunda para a exchange. Adicionalmente, o TVL DeFi da HyperEVM (excluindo a exchange principal) ultrapassou 1 mil milhões de dólares poucos meses após o lançamento, refletindo o rápido crescimento de novas dApps na chain. Estes números colocam firmemente a Hyperliquid entre os maiores ecossistemas de blockchain por TVL, apesar de ser uma chain especializada.

Em resumo, 2025 viu a Hyperliquid escalar para volumes e liquidez semelhantes aos de uma CEX. Classifica-se consistentemente como a principal DEX por volume, e até mede como uma fração significativa da negociação geral de cripto. A capacidade de sustentar meio bilião de dólares em volume semanal on-chain, com meio milhão de utilizadores, ilustra que a promessa de longa data de um DeFi de alto desempenho está a ser realizada. O sucesso da Hyperliquid está a expandir os limites do que os mercados on-chain podem fazer: por exemplo, tornou-se o local de eleição para a listagem rápida de novas moedas (muitas vezes é a primeira a listar perpétuos para ativos em tendência, atraindo enorme atividade) e provou que os livros de ordens on-chain podem lidar com a negociação de blue-chips em escala (os seus mercados de BTC e ETH têm liquidez comparável às principais CEXs). Estas conquistas sustentam a alegação da Hyperliquid como uma potencial base para todas as finanças on-chain no futuro.

Comparação com Outras DEXs Líderes (dYdX, GMX, UniswapX, etc.)

A ascensão da Hyperliquid convida a comparações com outras exchanges descentralizadas proeminentes. Cada um dos principais modelos de DEX – desde derivativos baseados em livro de ordens como a dYdX, a perpétuos baseados em pool de liquidez como a GMX, até agregadores de DEX spot como a UniswapX – adota uma abordagem diferente para equilibrar desempenho, descentralização e experiência do utilizador. Abaixo, analisamos como a Hyperliquid se compara a estas plataformas:

• Hyperliquid vs. dYdX: A dYdX foi a líder inicial em perpétuos descentralizados, mas o seu design inicial (v3) dependia de uma abordagem híbrida: um livro de ordens e motor de correspondência off-chain, combinado com uma liquidação L2 na StarkWare. Isto deu à dYdX um desempenho decente, mas ao custo da descentralização e componibilidade – o livro de ordens era gerido por um servidor central, e o sistema não estava aberto a contratos inteligentes gerais. No final de 2023, a dYdX lançou a v4 como uma app-chain do Cosmos, com o objetivo de descentralizar totalmente o livro de ordens dentro de uma chain PoS dedicada. Isto é filosoficamente semelhante à abordagem da Hyperliquid (ambas construíram chains personalizadas para correspondência de ordens on-chain). A principal vantagem da Hyperliquid tem sido a sua arquitetura unificada e a vantagem inicial na otimização de desempenho. Ao projetar o HyperCore e a HyperEVM em conjunto, a Hyperliquid alcançou velocidade de nível CEX totalmente on-chain antes que a chain do Cosmos da dYdX ganhasse tração. De facto, o desempenho da Hyperliquid superou o da dYdX – pode lidar com um débito muito maior (centenas de milhares de tx/seg) e oferece componibilidade entre contratos que a dYdX (uma chain específica de aplicação sem um ambiente EVM) atualmente não possui. A Artemis Research nota: os protocolos anteriores ou comprometiam o desempenho (como a GMX) ou a descentralização (como a dYdX), mas a Hyperliquid entregou ambos, resolvendo o desafio mais profundo. Isto reflete-se na quota de mercado: em 2025, a Hyperliquid comanda ~75% do mercado de DEX de perpétuos, enquanto a quota da dYdX diminuiu para um dígito. Em termos práticos, os traders consideram a UI e a velocidade da Hyperliquid comparáveis às da dYdX (ambas oferecem interfaces de exchange profissionais, ordens avançadas, etc.), mas a Hyperliquid oferece maior variedade de ativos e integração on-chain. Outra diferença são os modelos de taxas e tokens: o token da dYdX é principalmente um token de governança com descontos de taxas indiretos, enquanto o $HYPE da Hyperliquid acumula diretamente o valor da exchange (via recompras) e oferece direitos de staking. Por fim, na descentralização, ambas são chains PoS – a dYdX tinha ~20 validadores no lançamento vs os ~27 da Hyperliquid no início de 2025 – mas o ecossistema de construtores aberto da Hyperliquid (HyperEVM) torna-a indiscutivelmente mais descentralizada em termos de desenvolvimento e uso. No geral, a Hyperliquid pode ser vista como a sucessora espiritual da dYdX: pegou no conceito de DEX de livro de ordens e tornou-o totalmente on-chain com maior desempenho, o que é evidenciado pela Hyperliquid a atrair volume significativo até mesmo de exchanges centralizadas (algo que a dYdX v3 teve dificuldade em fazer).
• Hyperliquid vs. GMX: A GMX representa o modelo baseado em AMM/pool para perpétuos. Tornou-se popular na Arbitrum em 2022 ao permitir que os utilizadores negociassem perpétuos contra uma liquidez agrupada (GLP) com preços baseados em oráculos. A abordagem da GMX priorizou a simplicidade e o impacto zero no preço para pequenas negociações, mas sacrifica algum desempenho e eficiência de capital. Como a GMX depende de oráculos de preços e de uma única pool de liquidez, negociações grandes ou frequentes podem ser desafiadoras – a pool pode incorrer em perdas se os traders ganharem (os detentores de GLP assumem o lado oposto das negociações), e a latência dos preços dos oráculos pode ser explorada. O modelo de livro de ordens da Hyperliquid evita estes problemas ao corresponder traders peer-to-peer a preços orientados pelo mercado, com market makers profissionais a fornecer liquidez profunda. Isto resulta em spreads muito mais apertados e melhor execução para grandes negociações em comparação com o modelo da GMX. Essencialmente, o design da GMX compromete o desempenho de alta frequência (as negociações só são atualizadas quando os oráculos enviam preços, e não há colocação/cancelamento rápido de ordens), enquanto o design da Hyperliquid se destaca nisso. Os números refletem isto: os volumes e o OI da GMX são uma ordem de magnitude menores, e a sua quota de mercado foi ofuscada pela ascensão da Hyperliquid. Por exemplo, a GMX normalmente suportava menos de 20 mercados (principalmente de grande capitalização), enquanto a Hyperliquid oferece mais de 100 mercados, incluindo muitos ativos de cauda longa – o último é possível porque manter muitos livros de ordens é viável na chain da Hyperliquid, enquanto na GMX adicionar novas pools de ativos é mais lento e arriscado. Do ponto de vista da experiência do utilizador, a GMX oferece uma interface simples ao estilo de swap (boa para iniciantes em DeFi), enquanto a Hyperliquid fornece um painel de exchange completo com gráficos e livros de ordens para traders avançados. Taxas: A GMX cobra uma taxa de ~0,1% nas negociações (que vai para os stakers de GLP e GMX) e não tem recompra de tokens; a Hyperliquid cobra taxas de maker/taker muito baixas (na ordem de 0,01–0,02%) e usa as taxas para recomprar $HYPE para os detentores. Descentralização: A GMX corre em L2s do Ethereum (Arbitrum, Avalanche), herdando uma forte segurança de base, mas a sua dependência de um oráculo de preços centralizado (Chainlink) e de uma única pool de liquidez introduz diferentes riscos centralizados. A Hyperliquid corre a sua própria chain, que é mais nova/menos testada em batalha que o Ethereum, mas os seus mecanismos (livro de ordens + muitos makers) evitam a dependência de oráculos centralizados. Em resumo, a Hyperliquid oferece desempenho superior e liquidez de nível institucional em relação à GMX, ao custo de uma infraestrutura mais complexa. A GMX provou que há procura por perpétuos on-chain, mas os livros de ordens da Hyperliquid provaram ser muito mais escaláveis para negociações de alto volume.
• Hyperliquid vs. UniswapX (e DEXs Spot): A UniswapX é um agregador de negociações para swaps spot recentemente introduzido (construído pela Uniswap Labs) que encontra o melhor preço entre AMMs e outras fontes de liquidez. Embora não seja um concorrente direto em perpétuos, a UniswapX representa a vanguarda da experiência do utilizador de DEX spot. Permite swaps de tokens sem gás e otimizados por agregação, deixando que “fillers” off-chain executem as negociações para os utilizadores. Em contraste, a negociação spot da Hyperliquid usa os seus próprios livros de ordens on-chain (e também tem um AMM nativo chamado HyperSwap no seu ecossistema). Para um utilizador que procura negociar tokens spot, como se comparam? Desempenho: Os livros de ordens spot da Hyperliquid oferecem execução imediata com baixa latência, semelhante a uma exchange centralizada, e graças à ausência de taxas de gás no HyperCore, aceitar uma ordem é barato e rápido. A UniswapX visa poupar gás aos utilizadores no Ethereum ao abstrair a execução, mas, em última análise, a liquidação da negociação ainda acontece no Ethereum (ou outras chains subjacentes) e pode incorrer em latência (à espera de fillers e confirmações de bloco). Liquidez: A UniswapX obtém liquidez de muitos AMMs e market makers em várias DEXs, o que é ótimo para tokens de cauda longa no Ethereum; no entanto, para pares principais, o livro de ordens único da Hyperliquid muitas vezes tem liquidez mais profunda e menos slippage porque todos os traders se congregam num único local. De facto, após lançar os mercados spot em março de 2024, a Hyperliquid viu rapidamente os volumes spot dispararem para níveis recorde, com grandes traders a transferir ativos como BTC, ETH e SOL para a Hyperliquid para negociação spot devido à execução superior, e depois a transferi-los de volta. A UniswapX destaca-se na amplitude de acesso a tokens, enquanto a Hyperliquid se foca na profundidade e eficiência para um conjunto mais curado de ativos (aqueles listados através do seu processo de governança/leilão). Descentralização e UX: A Uniswap (e X) aproveitam a base muito descentralizada do Ethereum e são não-custodiais, mas agregadores como a UniswapX introduzem atores off-chain (fillers a retransmitir ordens) – embora de forma sem permissão. A abordagem da Hyperliquid mantém todas as ações de negociação on-chain com total transparência, e qualquer ativo listado na Hyperliquid obtém os benefícios da negociação nativa em livro de ordens mais a componibilidade com as suas apps DeFi. A experiência do utilizador na Hyperliquid é mais próxima de uma app de negociação centralizada (que os utilizadores avançados preferem), enquanto a UniswapX é mais como uma “meta-DEX” para swaps de um clique (conveniente para negociações casuais). Taxas: As taxas da UniswapX dependem da liquidez da DEX usada (tipicamente 0,05–0,3% em AMMs) mais possivelmente um incentivo para o filler; as taxas spot da Hyperliquid são mínimas e muitas vezes compensadas por descontos de $HYPE. Em suma, **a Hyperliquid compete com a Uniswap e outras DEXs spot ao oferecer um novo modelo: uma exchange spot baseada em livro de ordens numa chain personalizada**. Conquistou um nicho onde traders spot de alto volume (especialmente para ativos de grande capitalização) preferem a Hyperliquid pela sua liquidez mais profunda e experiência semelhante a uma CEX, enquanto utilizadores de retalho a trocar ERC-20s obscuros podem ainda preferir o ecossistema da Uniswap. Notavelmente, o ecossistema da Hyperliquid até introduziu o _Hyperswap_ (um AMM na HyperEVM com ~$70M de TVL) para capturar tokens de cauda longa através de pools de AMM – reconhecendo que AMMs e livros de ordens podem coexistir, servindo diferentes segmentos de mercado.

Resumo das Principais Diferenças: A tabela abaixo descreve uma comparação de alto nível:

Em essência, a Hyperliquid estabeleceu um novo benchmark ao combinar os pontos fortes destas abordagens sem as fraquezas habituais: oferece os tipos de ordens sofisticados, a velocidade e a liquidez de uma CEX (superando a tentativa anterior da dYdX), sem sacrificar a transparência e a natureza sem permissão do DeFi (melhorando o desempenho da GMX e a componibilidade da Uniswap). Como resultado, em vez de simplesmente roubar quota de mercado da dYdX ou da GMX, a Hyperliquid na verdade expandiu o mercado de negociação on-chain ao atrair traders que anteriormente permaneciam nas CEXs. O seu sucesso estimulou outros a evoluir – por exemplo, até a Coinbase e a Robinhood consideraram entrar no mercado de perpétuos on-chain, embora com alavancagem e liquidez muito mais baixas até agora. Se esta tendência continuar, podemos esperar um impulso competitivo onde tanto as CEXs como as DEXs correm para combinar desempenho com ausência de confiança – uma corrida onde a Hyperliquid atualmente goza de uma forte liderança.

Crescimento do Ecossistema, Parcerias e Iniciativas Comunitárias

Uma das maiores conquistas da Hyperliquid em 2025 é ter crescido de uma exchange de produto único para um ecossistema de blockchain próspero. O lançamento da HyperEVM desbloqueou uma explosão Cambriana de projetos e parcerias a construir em torno do núcleo da Hyperliquid, tornando-a não apenas um local de negociação, mas um ambiente completo de DeFi e Web3. Aqui exploramos a expansão do ecossistema e as principais alianças estratégicas:

Projetos do Ecossistema e Tração dos Desenvolvedores: Desde o início de 2025, dezenas de dApps foram implementadas na Hyperliquid, atraídas pela sua liquidez integrada e base de utilizadores. Estas abrangem toda a gama de primitivos DeFi e estendem-se até NFTs e jogos:

• Exchanges Descentralizadas (DEXs): Além dos livros de ordens nativos da Hyperliquid, surgiram DEXs construídas pela comunidade para servir outras necessidades. Notavelmente, a Hyperswap foi lançada como um AMM na HyperEVM, tornando-se rapidamente o principal centro de liquidez para tokens de cauda longa (acumulou mais de 70 milhões de dólares em TVL e 2 mil milhões de dólares em volume em 4 meses). As pools automatizadas da Hyperswap complementam o CLOB da Hyperliquid ao permitir a listagem sem permissão de novos tokens e fornecer um local fácil para projetos iniciarem a sua liquidez. Outro projeto, a KittenSwap (um fork da Velodrome com tokenomics ve(3,3)), também foi lançado para oferecer negociação AMM incentivada para ativos menores. Estas adições de DEX garantem que até mesmo memecoins e tokens experimentais possam prosperar na Hyperliquid através de AMMs, enquanto os principais ativos são negociados em livros de ordens – uma sinergia que impulsiona o volume geral.
• Protocolos de Empréstimo e Rendimento: O ecossistema da Hyperliquid agora apresenta mercados monetários e otimizadores de rendimento que se interligam com a exchange. O HyperBeat é um protocolo de empréstimo/empréstimo emblemático na HyperEVM (com ~$145M de TVL em meados de 2025). Permite que os utilizadores depositem ativos como$HYPE, stablecoins ou até tokens de LP para ganhar juros, e peçam emprestado contra garantia para negociar na Hyperliquid com alavancagem extra. Como o HyperBeat pode ler os preços do livro de ordens da Hyperliquid diretamente e até mesmo acionar liquidações on-chain através do HyperCore, opera de forma mais eficiente e segura do que os protocolos de empréstimo cross-chain. Agregadores de rendimento também estão a surgir – o programa de recompensas “Hearts” do HyperBeat e outros incentivam o fornecimento de liquidez ou depósitos em cofres. Outro participante notável é a Kinetiq, um projeto de staking líquido para $HYPE que atraiu mais de 400 milhões de dólares em depósitos no primeiro dia, indicando um enorme apetite da comunidade por ganhar rendimento com o HYPE. Até mesmo protocolos externos baseados em Ethereum estão a integrar-se: a **EtherFi**, um grande provedor de staking líquido (com ~$9 mil milhões em ETH em staking), anunciou uma colaboração para trazer ETH em staking e novas estratégias de rendimento para a Hyperliquid através do HyperBeat. Esta parceria introduzirá o beHYPE, um token de staking líquido para o HYPE, e potencialmente trará o ETH em staking da EtherFi como garantia para os mercados da Hyperliquid. Tais movimentos mostram confiança de players DeFi estabelecidos no potencial do ecossistema da Hyperliquid.
• Stablecoins e Banca Cripto: Reconhecendo a necessidade de uma moeda on-chain estável, a Hyperliquid atraiu suporte de stablecoins tanto externas como nativas. Mais significativamente, a Circle (emissora do USDC) formou uma parceria estratégica para lançar o USDC nativo na Hyperliquid em 2025. Usando o Protocolo de Transferência Cross-Chain (CCTP) da Circle, os utilizadores poderão queimar USDC no Ethereum e cunhar 1:1 USDC na Hyperliquid, eliminando wrappers e permitindo liquidez direta de stablecoin na chain. Espera-se que esta integração simplifique grandes transferências de capital para a Hyperliquid e reduza a dependência apenas de USDT/USDC em ponte. De facto, na altura do anúncio, os ativos sob gestão da Hyperliquid dispararam para 5,5 mil milhões de dólares, em parte pela antecipação do suporte nativo ao USDC. Do lado nativo, projetos como o Hyperstable lançaram uma stablecoin sobrecolateralizada (USH) na HyperEVM com o token de governança PEG que gera rendimento – adicionando diversidade às opções de stablecoin disponíveis para traders e utilizadores de DeFi.
• Infraestrutura DeFi Inovadora: As capacidades únicas da Hyperliquid estimularam a inovação no design de DEX e derivativos. A Valantis, por exemplo, é um protocolo de DEX modular na HyperEVM que permite aos desenvolvedores criar AMMs personalizados e “pools soberanas” com lógica especializada. Suporta funcionalidades avançadas como tokens de rebase e taxas dinâmicas, e tem 44 milhões de dólares em TVL, mostrando que as equipas veem a Hyperliquid como terreno fértil para impulsionar o design de DeFi. Especificamente para perpétuos, a comunidade aprovou a HIP-3, que abriu o motor Core da Hyperliquid a qualquer pessoa que queira lançar um novo mercado perpétuo. Isto é um divisor de águas: significa que se um utilizador quiser um mercado perpétuo para, digamos, um índice de ações ou uma commodity, pode implementá-lo (sujeito a parâmetros de governança) sem precisar da equipa da Hyperliquid – uma estrutura de derivativos verdadeiramente sem permissão, muito como a Uniswap fez para os swaps de ERC20. Já estão a aparecer mercados lançados pela comunidade para ativos inovadores, demonstrando o poder desta abertura.
• Análise, Bots e Ferramentas: Uma vibrante gama de ferramentas surgiu para apoiar os traders na Hyperliquid. Por exemplo, o PvP.trade é um bot de negociação baseado no Telegram que se integra com a API da Hyperliquid, permitindo que os utilizadores executem negociações de perpétuos via chat e até sigam as posições de amigos para uma experiência de negociação social. Realizou um programa de pontos e um airdrop de tokens que se revelou bastante popular. Do lado da análise, plataformas impulsionadas por IA como o Insilico Terminal e a Katoshi AI adicionaram suporte para a Hyperliquid, fornecendo aos traders sinais de mercado avançados, bots de estratégia automatizados e análises preditivas adaptadas aos mercados da Hyperliquid. A presença destas ferramentas de terceiros indica que os desenvolvedores veem a Hyperliquid como um mercado significativo – para o qual vale a pena construir bots e terminais – semelhante a como muitas ferramentas existem para a Binance ou a Uniswap. Adicionalmente, os provedores de infraestrutura abraçaram a Hyperliquid: a QuickNode e outros oferecem endpoints RPC para a chain da Hyperliquid, a Nansen integrou os dados da Hyperliquid no seu rastreador de portfólio, e exploradores de blockchain e agregadores estão a suportar a rede. Esta adoção de infraestrutura é crucial para a experiência do utilizador e significa que a Hyperliquid é reconhecida como uma rede importante no cenário multi-chain.
• NFTs e Jogos: Além das finanças puras, o ecossistema da Hyperliquid também se aventura em NFTs e jogos cripto, adicionando um sabor comunitário. A HypurrFun é uma plataforma de lançamento de memecoins que ganhou atenção ao usar um sistema de leilão por bot do Telegram para listar tokens de piada (como $PIP e$JEFF) no mercado spot da Hyperliquid. Proporcionou uma experiência divertida, ao estilo Pump.win, para a comunidade e foi instrumental no teste dos mecanismos de leilão de tokens da Hyperliquid antes da HyperEVM. Projetos de NFT como o Hypio (uma coleção de NFT que integra utilidade DeFi) foram lançados na Hyperliquid, e até um jogo alimentado por IA (TheFarm.fun) está a aproveitar a chain para cunhar NFTs criativos e a planear um airdrop de tokens. Estes podem ser de nicho, mas indicam a formação de uma comunidade orgânica – traders que também se envolvem em memes, NFTs e jogos sociais na mesma chain, aumentando a fidelidade do utilizador.

Parcerias Estratégicas: Juntamente com projetos de base, a equipa da Hyperliquid (através da Fundação Hyper) tem procurado ativamente parcerias para estender o seu alcance:

• Carteira Phantom (Ecossistema Solana): Em julho de 2025, a Hyperliquid anunciou uma grande parceria com a Phantom, a popular carteira da Solana, para trazer a negociação de perpétuos na carteira aos utilizadores da Phantom. Esta integração permite que a aplicação móvel da Phantom (com milhões de utilizadores) negocie perpétuos da Hyperliquid nativamente, sem sair da interface da carteira. Mais de 100 mercados com até 50× de alavancagem tornaram-se disponíveis na Phantom, cobrindo BTC, ETH, SOL e mais, com controlos de risco integrados como ordens de stop-loss. A importância é dupla: dá aos utilizadores da comunidade Solana acesso fácil aos mercados da Hyperliquid (ligando ecossistemas), e mostra a força da API e do backend da Hyperliquid – a Phantom não integraria uma DEX que não conseguisse lidar com um grande fluxo de utilizadores. A equipa da Phantom destacou que a liquidez e a liquidação rápida da Hyperliquid foram fundamentais para proporcionar uma experiência de negociação móvel suave. Esta parceria essencialmente incorpora a Hyperliquid como o “motor de perpétuos” dentro de uma carteira de cripto líder, diminuindo drasticamente o atrito para novos utilizadores começarem a negociar na Hyperliquid. É uma vitória estratégica para a aquisição de utilizadores e demonstra a intenção da Hyperliquid de colaborar em vez de competir com outros ecossistemas (neste caso, a Solana).
• Circle (USDC): Como mencionado, a parceria da Circle para implementar o USDC nativo via CCTP na Hyperliquid é uma integração fundamental. Não só legitima a Hyperliquid como uma chain de primeira classe aos olhos de um grande emissor de stablecoins, mas também resolve uma peça crítica de infraestrutura: a liquidez fiduciária. Quando a Circle ativar o USDC nativo para a Hyperliquid, os traders poderão transferir dólares para dentro e para fora da rede da Hyperliquid com a mesma facilidade (e confiança) que mover USDC no Ethereum ou na Solana. Isto simplifica a arbitragem e os fluxos entre exchanges. Adicionalmente, o Protocolo de Transferência Cross-Chain v2 da Circle permitirá que o USDC se mova entre a Hyperliquid e outras chains sem intermediários, integrando ainda mais a Hyperliquid na rede de liquidez multi-chain. Em julho de 2025, a antecipação da chegada do USDC e de outros ativos já tinha impulsionado os pools de ativos totais da Hyperliquid para 5,5 mil milhões de dólares. Podemos esperar que este número cresça assim que a integração da Circle estiver totalmente operacional. Em essência, esta parceria aborda uma das últimas barreiras para os traders: rampas de entrada/saída fiduciárias fáceis para o ambiente de alta velocidade da Hyperliquid.
• Market Makers e Parceiros de Liquidez: Embora nem sempre publicitado, a Hyperliquid provavelmente cultivou relações com empresas profissionais de market-making para iniciar a liquidez do seu livro de ordens. A profundidade observada (muitas vezes rivalizando com a Binance em alguns pares) sugere que os principais provedores de liquidez de cripto (possivelmente empresas como Wintermute, Jump, etc.) estão ativamente a fazer mercados na Hyperliquid. Um indicador indireto: a Auros Global, uma empresa de negociação, publicou um guia “Hyperliquid listing 101” no início de 2025, notando que a Hyperliquid teve uma média de 6,1 mil milhões de dólares em volume diário de perpétuos no primeiro trimestre de 2025, o que implica que os market makers estão a prestar atenção. Adicionalmente, o design da Hyperliquid (com incentivos como rebates de maker ou rendimentos da HLP) e o benefício de não ter gás são muito atrativos para empresas de HFT. Embora parcerias específicas com MMs não sejam nomeadas, o ecossistema beneficia claramente da sua participação.
• Outros: A Fundação Hyper, que supervisiona o desenvolvimento do protocolo, iniciou iniciativas como um Programa de Delegação para incentivar validadores confiáveis e programas comunitários globais (um Hackathon com 250 mil dólares em prémios foi realizado em 2025). Estes ajudam a fortalecer a descentralização da rede e a atrair novos talentos. Há também colaboração com provedores de oráculos (Chainlink ou Pyth) para dados externos quando necessário – por exemplo, se forem lançados mercados de ativos sintéticos do mundo real, essas parcerias serão importantes. Dado que a Hyperliquid é compatível com EVM, ferramentas do Ethereum (como Hardhat, The Graph, etc.) podem ser estendidas com relativa facilidade para a Hyperliquid à medida que os desenvolvedores o exigirem.

Comunidade e Governança: O envolvimento da comunidade na Hyperliquid tem sido alto devido ao airdrop inicial e às votações de governança contínuas. A estrutura da Proposta de Melhoria da Hyperliquid (HIP) viu propostas importantes (HIP-1 a HIP-3) serem aprovadas no seu primeiro ano, sinalizando um processo de governança ativo. A comunidade desempenhou um papel nas listagens de tokens através do modelo de leilão da Hyperliquid – novos tokens são lançados através de um leilão on-chain (muitas vezes facilitado pela HypurrFun ou similar), e os leilões bem-sucedidos são listados no livro de ordens. Este processo, embora permissionado por uma taxa e verificação, permitiu que tokens impulsionados pela comunidade (como memecoins) ganhassem tração na Hyperliquid sem um controlo centralizado. Também ajudou a Hyperliquid a evitar tokens de spam, uma vez que há um custo para listar, garantindo que apenas projetos sérios ou comunidades entusiasmadas o persigam. O resultado é um ecossistema que equilibra a inovação sem permissão com um grau de controlo de qualidade – uma abordagem inovadora no DeFi.

Além disso, a Fundação Hyper (uma entidade sem fins lucrativos) foi criada para apoiar o crescimento do ecossistema. Foi responsável por iniciativas como o lançamento do token $HYPE e a gestão dos fundos de incentivo. A decisão da Fundação de não emitir incentivos de forma imprudente (como observado no The Defiant, não forneceram mineração de liquidez extra após o airdrop) pode ter inicialmente moderado alguns caçadores de rendimento, mas sublinha um foco no uso orgânico em vez de aumentos de TVL a curto prazo. Esta estratégia parece ter valido a pena com um crescimento constante. Agora, movimentos como o envolvimento da EtherFi e outros mostram que, mesmo sem uma mineração de liquidez massiva, a atividade DeFi real está a criar raízes na Hyperliquid devido às suas oportunidades únicas (como altos rendimentos da receita real de taxas e acesso a uma base de negociação ativa).

Para resumir, a Hyperliquid em 2025 está rodeada por um ecossistema florescente e alianças fortes. A sua chain abriga uma stack DeFi abrangente – desde negociação de perpétuos e spot, a AMMs, empréstimos, stablecoins, staking líquido, NFTs e além – grande parte da qual surgiu apenas no último ano. Parcerias estratégicas com nomes como Phantom e Circle estão a expandir o seu alcance de utilizadores e acesso à liquidez em todo o universo cripto. Os aspetos impulsionados pela comunidade (leilões, governança, hackathons) mostram uma base de utilizadores engajada que está cada vez mais investida no sucesso da Hyperliquid. Todos estes fatores reforçam a posição da Hyperliquid como mais do que uma exchange; está a tornar-se uma camada financeira holística.

Perspetiva Futura: A Visão da Hyperliquid para as Finanças Onchain (Derivativos, RWAs e Além)

A rápida ascensão da Hyperliquid levanta a questão: O que se segue? A visão do projeto sempre foi ambiciosa – tornar-se a infraestrutura fundamental para todas as finanças onchain. Tendo alcançado o domínio nos perpétuos on-chain, a Hyperliquid está preparada para expandir para novos produtos e mercados, potencialmente remodelando como os ativos financeiros tradicionais interagem com a cripto. Aqui estão alguns elementos-chave da sua visão de futuro:

• Expandir o Conjunto de Derivativos: Os futuros perpétuos foram a cabeça de ponte inicial, mas a Hyperliquid pode estender-se a outros derivativos. A arquitetura (HyperCore + HyperEVM) poderia suportar instrumentos adicionais como opções, swaps de taxa de juro ou produtos estruturados. Um próximo passo lógico poderia ser uma exchange de opções on-chain ou um AMM de opções a ser lançado na HyperEVM, aproveitando a liquidez e a execução rápida da chain. Com um estado unificado, um protocolo de opções na Hyperliquid poderia fazer hedge diretamente através do livro de ordens de perpétuos, criando uma gestão de risco eficiente. Ainda não vimos uma grande plataforma de opções on-chain surgir na Hyperliquid, mas dado o crescimento do ecossistema, é plausível para 2025-26. Adicionalmente, futuros tradicionais e derivativos tokenizados (por exemplo, futuros sobre índices de ações, commodities ou taxas de câmbio) poderiam ser introduzidos através de propostas HIP – essencialmente trazendo os mercados financeiros tradicionais para a on-chain. A HIP-3 da Hyperliquid já abriu caminho para listar “qualquer ativo, cripto ou tradicional” como um mercado perpétuo, desde que haja um oráculo ou feed de preços. Isto abre a porta para que membros da comunidade lancem mercados de ações, ouro ou outros ativos de forma sem permissão. Se a liquidez e as considerações legais permitirem, a Hyperliquid poderia tornar-se um centro para a negociação tokenizada 24/7 de mercados do mundo real, algo que nem muitas CEXs oferecem em escala. Tal desenvolvimento realizaria verdadeiramente a visão de uma plataforma de negociação global unificada on-chain.
• Ativos do Mundo Real (RWAs) e Mercados Regulados: Trazer ativos do mundo real para o DeFi é uma grande tendência, e a Hyperliquid está bem posicionada para facilitá-lo. Através da HyperUnit e de parcerias como a da Circle, a chain está a integrar-se com ativos reais (fiduciários via USDC, BTC/SOL via tokens wrapped). O próximo passo pode ser a negociação de títulos ou obrigações tokenizadas na Hyperliquid. Por exemplo, pode-se imaginar um futuro onde obrigações do governo ou ações são tokenizadas (talvez sob um sandbox regulatório) e negociadas nos livros de ordens da Hyperliquid 24/7. O design da Hyperliquid já é “consciente da regulamentação” – o uso de ativos nativos em vez de IOUs sintéticos pode simplificar a conformidade. A Fundação Hyper poderia explorar a colaboração com jurisdições para permitir certos RWAs na plataforma, especialmente à medida que a tecnologia de KYC/whitelisting on-chain melhora (a HyperEVM poderia suportar pools permissionadas se necessário para ativos regulados). Mesmo sem tokens RWA formais, os perpétuos sem permissão da Hyperliquid poderiam listar derivativos que seguem RWAs (por exemplo, um swap perpétuo sobre o índice S&P 500). Isso traria exposição a RWAs aos utilizadores de DeFi de uma forma indireta, mas eficaz. Em resumo, a Hyperliquid visa esbater a linha entre os mercados de cripto e os mercados tradicionais – para abrigar todas as finanças, eventualmente é preciso acomodar ativos e participantes do lado tradicional. As bases (em tecnologia e liquidez) estão a ser lançadas para essa convergência.
• Escalabilidade e Interoperabilidade: A Hyperliquid continuará a escalar verticalmente (mais débito, mais validadores) e provavelmente horizontalmente através da interoperabilidade. Com o IBC do Cosmos ou outros protocolos cross-chain, a Hyperliquid pode conectar-se a redes mais amplas, permitindo que ativos e mensagens fluam de forma trustless. Já usa o CCTP da Circle para o USDC; a integração com algo como o CCIP da Chainlink ou o IBC do Cosmos poderia estender as possibilidades de negociação cross-chain. A Hyperliquid poderia tornar-se um centro de liquidez ao qual outras chains recorrem (imagine dApps no Ethereum ou na Solana a executar negociações na Hyperliquid através de pontes trustless – obtendo a liquidez da Hyperliquid sem sair da sua chain nativa). A menção da Hyperliquid como um “centro de liquidez” e a sua crescente quota de open interest (já ~18% de todo o OI de futuros de cripto em meados de 2025) indica que pode ancorar uma rede maior de protocolos DeFi. A abordagem colaborativa da Fundação Hyper (por exemplo, parcerias com carteiras, outras L1s) sugere que eles veem a Hyperliquid como parte de um futuro multi-chain em vez de uma ilha isolada.
• Infraestrutura DeFi Avançada: Ao combinar uma exchange de alto desempenho com programabilidade geral, a Hyperliquid poderia permitir produtos financeiros sofisticados que não eram anteriormente viáveis on-chain. Por exemplo, fundos de hedge on-chain ou estratégias de cofre podem ser construídos na HyperEVM que executam estratégias complexas diretamente através do HyperCore (arbitragem, market making automatizado em livros de ordens, etc.) tudo numa única chain. Esta integração vertical elimina ineficiências como mover fundos entre camadas ou ser vítima de front-running por bots de MEV durante a arbitragem cross-chain – tudo pode acontecer sob o consenso HyperBFT com total atomicidade. Podemos ver um crescimento em cofres de estratégia automatizados que usam os primitivos da Hyperliquid para gerar rendimento (alguns cofres iniciais provavelmente já existem, possivelmente geridos pelo HyperBeat ou outros). O fundador da Hyperliquid resumiu a estratégia como “polir uma aplicação nativa e depois crescer para uma infraestrutura de propósito geral”. Agora que a aplicação de negociação nativa está polida e uma ampla base de utilizadores está presente, a porta está aberta para a Hyperliquid se tornar uma camada de infraestrutura DeFi geral. Isto poderia colocá-la em competição não apenas com DEXs, mas com Layer-1s como Ethereum ou Solana para hospedar dApps financeiras – embora a especialidade da Hyperliquid permaneça qualquer coisa que exija liquidez profunda ou baixa latência.
• Adoção Institucional e Conformidade: O futuro da Hyperliquid provavelmente envolve cortejar players institucionais – fundos de hedge, market makers, até empresas de fintech – para usar a plataforma. O interesse institucional já está a aumentar, dados os volumes e o facto de empresas como Coinbase, Robinhood e outras estarem de olho nos perpétuos. A Hyperliquid pode posicionar-se como o provedor de infraestrutura para as instituições irem on-chain. Poderia oferecer funcionalidades como subcontas, ferramentas de relatórios de conformidade ou pools com whitelist (se necessário para certos utilizadores regulados) – tudo isto preservando a natureza pública e on-chain para o retalho. O clima regulatório influenciará isto: se as jurisdições clarificarem o estatuto dos derivativos DeFi, a Hyperliquid poderia tornar-se um local licenciado de alguma forma ou permanecer uma rede puramente descentralizada à qual as instituições se ligam indiretamente. A menção de “design consciente da regulamentação” sugere que a equipa está atenta a encontrar um equilíbrio que permita a integração com o mundo real sem infringir as leis.
• Capacitação Contínua da Comunidade: À medida que a plataforma cresce, mais tomadas de decisão podem passar para os detentores de tokens. Podemos esperar que futuras HIPs cubram coisas como ajustar parâmetros de taxas, alocar o fundo de incentivo (os ~39% da oferta reservados), introduzir novos produtos (por exemplo, se um módulo de opções fosse proposto) e expandir os conjuntos de validadores. A comunidade desempenhará um grande papel na orientação da trajetória da Hyperliquid, atuando efetivamente como os acionistas desta exchange descentralizada. O tesouro da comunidade (financiado por quaisquer tokens ainda não distribuídos e possivelmente por qualquer receita não usada em recompras) poderia ser direcionado para financiar novos projetos na Hyperliquid ou fornecer subsídios, reforçando ainda mais o desenvolvimento do ecossistema.

Conclusão: A Hyperliquid em 2025 alcançou o que muitos pensavam ser impossível: uma exchange totalmente on-chain que rivaliza com as plataformas centralizadas em desempenho e liquidez. A sua arquitetura técnica – HyperBFT, HyperCore, HyperEVM – provou ser um modelo para a próxima geração de redes financeiras. O modelo do token $HYPE alinha a comunidade de forma estreita com o sucesso da plataforma, criando uma das economias de tokens mais lucrativas e deflacionárias do DeFi. Com volumes de negociação massivos, uma base de utilizadores em expansão e um ecossistema DeFi de rápido crescimento ao seu redor, a Hyperliquid posicionou-se como uma layer-1 de primeira linha para aplicações financeiras. Olhando para o futuro, a sua visão de se tornar “a blockchain para abrigar todas as finanças” não parece rebuscada. Ao trazer mais classes de ativos para a on-chain (potencialmente incluindo ativos do mundo real) e continuando a integrar-se com outras redes e parceiros, a Hyperliquid poderia servir como a espinha dorsal para um sistema financeiro verdadeiramente global, 24/7 e descentralizado. Num futuro assim, as linhas entre os mercados de cripto e tradicionais esbatem-se – e a combinação de alto desempenho e arquitetura trustless da Hyperliquid pode muito bem ser o modelo que as une, construindo o futuro das finanças onchain, um bloco de cada vez.

Fontes:

1. Blog da QuickNode – “Hyperliquid in 2025: A High-Performance DEX...” (Arquitetura, métricas, tokenomics, visão)
2. Artemis Research – “Hyperliquid: A Valuation Model and Bull Case” (Quota de mercado, modelo de token, comparações)
3. The Defiant – “EtherFi Expands to HyperLiquid…HyperBeat” (TVL do ecossistema, interesse institucional)
4. BlockBeats – “Inside Hyperliquid’s Growth – Semiannual Report 2025” (Métricas on-chain, volume, OI, estatísticas de utilizadores)
5. Coingape – “Hyperliquid Expands to Solana via Phantom Partnership” (Integração da carteira Phantom, perpétuos móveis)
6. Mitrade/Cryptopolitan – “Circle integrates USDC with Hyperliquid” (Lançamento do USDC nativo, 5,5 mil milhões de dólares em AUM)
7. Nansen – “What is Hyperliquid? – Blockchain DEX & Trading Explained” (Visão geral técnica, finalidade em menos de um segundo, usos do token)
8. DeFi Prime – “Exploring the Hyperliquid Chain Ecosystem: Deep Dive” (Projetos do ecossistema: DEXs, empréstimos, NFTs, etc.)
9. Wiki/Docs da Hyperliquid – Hyperliquid GitBook & Stats (Listagens de ativos via HIPs, painel de estatísticas)
10. CoinMarketCap – Hyperliquid (HYPE) Listing (Informações básicas sobre a L1 da Hyperliquid e design do livro de ordens on-chain)

TL;DR​

Um airdrop de cripto é a distribuição de tokens para endereços de carteira específicos — frequentemente de graça — para iniciar uma rede, descentralizar a propriedade ou recompensar membros iniciais da comunidade. Métodos populares incluem recompensas retroativas por ações passadas, conversões de pontos em tokens, airdrops para detentores de NFT ou tokens, e campanhas interativas de “missão”. O diabo está nos detalhes: regras de snapshot, mecânicas de reivindicação como provas Merkle, resistência a Sybil, comunicação clara e conformidade legal são críticos para o sucesso. Para os usuários, o valor está ligado à tokenômica e à segurança. Para as equipes, um airdrop bem‑sucedido deve estar alinhado aos objetivos centrais do produto, não apenas gerar hype temporário.

O que realmente é um airdrop?​

Em sua essência, um airdrop de cripto é uma estratégia de marketing e distribuição onde um projeto envia seu token nativo para as carteiras de um grupo específico de usuários. Não se trata apenas de um presente; é um movimento calculado para alcançar metas específicas. Conforme definido por recursos educacionais da Coinbase e da Binance Academy, airdrops são comumente usados quando uma nova rede, protocolo DeFi ou dApp deseja construir rapidamente uma base de usuários. Ao distribuir tokens para usuários potenciais, os projetos podem incentivá‑los a participar da governança, fornecer liquidez, testar novas funcionalidades ou simplesmente tornar‑se membros ativos da comunidade, impulsionando o efeito de rede.

Onde os airdrops aparecem na prática​

Os airdrops vêm em várias formas, cada uma com um propósito estratégico diferente. Aqui estão os modelos mais comuns vistos atualmente.

Retroativo (recompensa por comportamento passado)​

Este é o modelo clássico, projetado para recompensar adotantes iniciais que usaram um protocolo antes de existir um token. O airdrop da Uniswap em 2020 é o exemplo definitivo, estabelecendo o modelo moderno ao distribuir $400 UNI$ para cada endereço que já havia interagido com o protocolo. Foi um “obrigado” poderoso que transformou usuários em proprietários da noite para o dia.

Pontos → token (incentivos primeiro, token depois)​

Tendência dominante em 2024 e 2025, o modelo de pontos gamifica a participação. Projetos rastreiam ações dos usuários — como bridging, swapping ou staking — e concedem “pontos” off‑chain. Mais tarde, esses pontos são convertidos em alocação de tokens. Essa abordagem permite que as equipes meçam e incentivem comportamentos desejados ao longo de um período mais longo antes de lançar um token.

Airdrops para detentores/NFTs​

Este tipo de airdrop tem como alvo usuários que já possuem um token ou NFT específico. É uma forma de recompensar lealdade dentro de um ecossistema existente ou de iniciar um novo projeto com uma comunidade engajada. Um caso famoso é o ApeCoin, que concedeu direitos de reivindicação do token $APE para detentores dos NFTs Bored Ape e Mutant Ape Yacht Club no seu lançamento em 2022.

Programas de ecossistema/governança​

Alguns projetos utilizam uma série de airdrops como parte de uma estratégia de longo prazo para descentralização e crescimento da comunidade. Optimism, por exemplo, realizou múltiplos airdrops para usuários, ao mesmo tempo reservando uma parcela significativa de seu suprimento de tokens para financiamento de bens públicos através do programa RetroPGF. Isso demonstra um compromisso com a construção de um ecossistema sustentável e alinhado a valor.

Como funciona um airdrop (mecânicas que importam)​

A diferença entre um airdrop bem‑sucedido e um caótico costuma depender da execução técnica e estratégica. Aqui estão as mecânicas que realmente importam.

Snapshot & elegibilidade​

Primeiro, o projeto deve decidir quem se qualifica. Isso envolve escolher um snapshot — um bloco ou data específicos — após o qual a atividade do usuário não será mais contabilizada. Os critérios de elegibilidade são então definidos com base nos comportamentos que o projeto deseja recompensar, como bridging de fundos, swaps, fornecimento de liquidez, participação em governança ou até contribuição de código. Para seu airdrop, Arbitrum colaborou com a empresa de análise Nansen para desenvolver um modelo sofisticado de distribuição baseado em um snapshot tomado em um bloco específico em 6 de fevereiro de 2023.

Reivindicação vs. envio direto​

Embora enviar tokens diretamente para carteiras pareça mais simples, a maioria dos projetos maduros usa um fluxo baseado em reivindicação. Isso impede que tokens sejam enviados para endereços perdidos ou comprometidos e exige que os usuários se envolvam ativamente. O padrão mais comum é um Distribuidor Merkle. O projeto publica um “fingerprint” criptográfico (uma raiz Merkle) dos endereços elegíveis on‑chain. Cada usuário pode então gerar uma “prova” única para verificar sua elegibilidade e reivindicar seus tokens. Esse método, popularizado pela implementação open‑source da Uniswap, é econômico em gas e seguro.

Resistência a Sybil​

Airdrops são alvos primários de “farmers” — indivíduos que utilizam centenas ou milhares de carteiras (um “ataque Sybil”) para maximizar recompensas. As equipes empregam vários métodos para combater isso, incluindo análise de clusters de carteiras controladas por uma única entidade, heurísticas (como idade da carteira ou diversidade de atividade) e, mais recentemente, programas de auto‑relato. A campanha da LayerZero em 2024 introduziu um modelo amplamente debatido onde usuários podiam auto‑relatar atividade Sybil para receber uma alocação de 15 %; quem não o fez e foi posteriormente pego foi excluído.

Cronograma de liberação & governança​

Nem todos os tokens de um airdrop ficam disponíveis imediatamente. Muitos projetos implementam um cronograma de liberação (ou período de vesting) para alocações destinadas à equipe, investidores e fundos de ecossistema. Entender esse cronograma é crucial para que os usuários avaliem a pressão futura de oferta no mercado. Plataformas como TokenUnlocks oferecem dashboards públicos que rastreiam esses cronogramas em centenas de ativos.

Estudos de caso (fatos rápidos)​

• Uniswap (2020): Distribuiu $400 UNI$ por endereço elegível, com alocações maiores para provedores de liquidez. Estabeleceu o modelo de reivindicação baseado em prova Merkle como padrão da indústria e demonstrou o poder de recompensar retroativamente uma comunidade.
• Arbitrum (2023): Lançou seu token de governança L2, $ARB, com suprimento inicial de 10 bilhões. O airdrop usou um sistema de pontos baseado em atividade on‑chain antes de um snapshot de 6 de fevereiro de 2023, incorporando análises avançadas e filtros Sybil da Nansen.
• Starknet (2024): Batizou seu airdrop de “Programa de Provisões”, com reivindicações abertas em 20 de fevereiro de 2024. Visou um amplo leque de contribuidores, incluindo usuários iniciais, desenvolvedores de rede e até stakers da Ethereum, oferecendo uma janela de vários meses para reivindicação.
• ZKsync (2024): Anunciado em 11 de junho de 2024, foi uma das maiores distribuições de usuários em Layer 2 até então. Um airdrop único distribuiu 17,5 % do suprimento total de tokens para quase 700 mil carteiras, recompensando a comunidade pioneira do protocolo.

Por que as equipes fazem airdrops (e quando não devem)​

As equipes utilizam airdrops por várias razões estratégicas:

• Iniciar uma rede bidirecional: Airdrops podem semear uma rede com os participantes necessários, sejam provedores de liquidez, traders, criadores ou restakers.
• Descentralizar a governança: Distribuir tokens para uma base ampla de usuários ativos é um passo fundamental rumo à descentralização credível e à governança liderada pela comunidade.
• Recompensar contribuintes iniciais: Para projetos que não realizaram ICO ou venda de tokens, o airdrop é a principal forma de premiar os primeiros crentes que agregaram valor quando o resultado era incerto.
• Comunicar valores: O design de um airdrop pode transmitir os princípios centrais de um projeto. O foco da Optimism em financiamento de bens públicos é um exemplo claro.

Entretanto, airdrops não são solução mágica. As equipes não devem realizar um airdrop se o produto tem baixa retenção, a comunidade é fraca ou a utilidade do token está mal definida. Um airdrop amplifica loops de feedback positivos existentes; não pode consertar um produto quebrado.

Para usuários: como avaliar e participar — com segurança​

Airdrops podem ser lucrativos, mas também trazem riscos significativos. Veja como navegar com segurança.

Antes de correr atrás de um drop​

• Verifique a legitimidade: Sempre confirme anúncios de airdrop pelos canais oficiais do projeto (site, conta X, Discord). Desconfie de links de “reivindicação” enviados por DM, encontrados em anúncios ou promovidos por contas não verificadas.
• Mapeie a economia: Entenda a tokenômica. Qual é o suprimento total? Qual porcentagem é alocada para usuários? Qual o cronograma de vesting para insiders? Ferramentas como TokenUnlocks ajudam a rastrear liberações futuras.
• Conheça o estilo: É um airdrop retroativo que recompensa comportamento passado, ou um programa de pontos que exige participação contínua? As regras diferem, e programas de pontos podem mudar seus critérios ao longo do tempo.

Higiene de carteira​

• Use uma carteira nova: Quando possível, utilize uma carteira dedicada de baixo valor (“burner”) para reivindicar airdrops. Isso isola o risco das suas holdings principais.
• Leia o que você assina: Nunca aprove um transaction blindamente. Sites maliciosos podem induzir você a assinar permissões que permitem drenar seus ativos. Use simuladores de carteira para entender a transação antes de assinar. Revise periodicamente e revogue aprovações antigas com ferramentas como Revoke.cash.
• Cuidado com assinaturas off‑chain: Scammers abusam cada vez mais de assinaturas Permit e Permit2, que são aprovações off‑chain que podem mover seus ativos sem uma transação on‑chain. Seja tão cuidadoso com elas quanto com aprovações on‑chain.

Riscos comuns​

• Phishing e drenos: O risco mais comum é interagir com um site “de reivindicação” falso projetado para drenar sua carteira. Pesquisas de empresas como Scam Sniffer mostram que kits de dreno sofisticados foram responsáveis por perdas massivas entre 2023‑2025.
• Geofencing & KYC: Alguns airdrops podem ter restrições geográficas ou exigir verificação KYC. Sempre leia os termos e condições, pois residentes de certos países podem ser excluídos.
• Impostos (orientação rápida, não consultoria): O tratamento fiscal varia por jurisdição. Nos EUA, o IRS geralmente trata tokens airdrop como renda tributável ao valor de mercado justo na data em que você obtém controle sobre eles. No Reino Unido, a HMRC pode considerar um airdrop como renda se você realizou uma ação para recebê‑lo. A venda posterior dos tokens pode gerar Imposto sobre Ganhos de Capital. Consulte um profissional qualificado.

Para equipes: checklist pragmático de design de airdrop​

Planejando um airdrop? Use este checklist para orientar o processo de design.

1. Clarifique o objetivo: O que você quer alcançar? Recompensar uso real, descentralizar governança, semear liquidez ou financiar construtores? Defina sua meta principal e torne o comportamento alvo explícito.
2. Defina elegibilidade alinhada ao produto: Crie critérios que premiem usuários “sticky” e de alta qualidade. Dê peso a ações que correlacionam com retenção (ex.: saldos ponderados por tempo, trades consistentes) em vez de volume simples, e considere limitar recompensas para “whales”. Estude post‑mortems públicos de grandes airdrops em plataformas como a Nansen.
3. Construa resistência a Sybil: Não dependa de um único método. Combine heurísticas on‑chain (idade da carteira, diversidade de atividade) com análises de clustering. Considere abordagens inovadoras como o modelo de auto‑relato assistido pela comunidade, pioneiro pela LayerZero.
4. Implemente um caminho de reivindicação robusto: Use um contrato Distribuidor Merkle testado em batalha. Publique o dataset completo e a árvore Merkle para que qualquer pessoa possa verificar independentemente a raiz e sua própria elegibilidade. Mantenha a UI de reivindicação mínima, auditada e com limite de taxa para lidar com picos de tráfego sem sobrecarregar seus endpoints RPC.
5. Comunique o plano de liberação: Seja transparente sobre o suprimento total de tokens, alocações para diferentes grupos (comunidade, equipe, investidores) e eventos futuros de liberação. Dashboards públicos geram confiança e suportam dinâmicas de mercado mais saudáveis.
6. Aborde governança, aspectos legais e tributários: Alinhe as capacidades on‑chain do token (votação, compartilhamento de taxas, staking) ao roadmap de longo prazo. Busque assessoria jurídica sobre restrições jurisdicionais e divulgações necessárias. Como mostram as orientações do IRS e da HMRC, detalhes importam.

Glossário rápido​

• Snapshot: Um bloco ou momento específico usado como corte para determinar quem é elegível a um airdrop.
• Reivindicação (Merkle): Método econômico em gas, baseado em prova, que permite usuários elegíveis retirarem sua alocação de token de um contrato inteligente.
• Sybil: Cenário onde um agente usa muitas carteiras para manipular uma distribuição. As equipes utilizam técnicas de filtragem para detectar e remover esses agentes.
• Pontos: Contagens off‑chain ou on‑chain que rastreiam engajamento do usuário. Frequentemente convertem‑se em tokens depois, mas os critérios podem mudar.
• Cronograma de liberação: Linha do tempo que detalha como e quando tokens não circulantes (ex.: alocações de equipe ou investidores) entram no mercado.

Canto do construtor: como a BlockEden pode ajudar​

Lançar um airdrop é uma empreitada enorme. A BlockEden fornece a infraestrutura para garantir que você o faça de forma responsável e eficaz.

• Snapshots confiáveis: Use nossos serviços de RPC de alta taxa de transferência e indexação para calcular elegibilidade em milhões de endereços e critérios complexos, em qualquer cadeia.
• Infra de reivindicação: Receba orientação especializada para projetar e implementar fluxos de reivindicação baseados em provas Merkle.
• Distribuição de tokens: Aproveite nossas soluções de distribuição segura e escalável, com auditoria de contrato e monitoramento de desempenho.
• Análise de resistência a Sybil: Integre nossas ferramentas de análise para identificar e mitigar comportamentos Sybil antes do airdrop.
• Suporte multi‑cadeia: Nossa arquitetura cross‑chain permite executar airdrops simultaneamente em várias blockchains, mantendo consistência e segurança.

Conclusão​

Airdrops de cripto são poderosas alavancas para acelerar a adoção, distribuir valor e fortalecer comunidades blockchain. Quando bem projetados — com snapshots claros, provas Merkle, resistência a Sybil e comunicação transparente — eles podem gerar benefícios duradouros tanto para usuários quanto para equipes. Contudo, seu sucesso depende de alinhamento estratégico, conformidade legal e atenção meticulosa aos detalhes técnicos. Ao combinar essas melhores práticas com a infraestrutura robusta da BlockEden, você está pronto para transformar um simples lançamento de token em um motor de crescimento sustentável para seu ecossistema.

Imagine um mundo onde os usuários podem interagir com seu dApp de forma fluida, sem precisar possuir nenhum token nativo (SUI). Isso já não é mais um sonho distante. Com a Gas Station da Sui (também conhecida como Paymaster), desenvolvedores podem cobrir as taxas de gas em nome de seus usuários, removendo completamente uma das maiores barreiras para novos entrantes no Web3 e permitindo uma experiência on‑chain verdadeiramente sem atritos.

Este artigo fornece um guia completo para transformar seu dApp em uma solução sem gas. Vamos mergulhar nos conceitos centrais do Sui Paymaster, sua arquitetura, padrões de implementação e melhores práticas.

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

No universo blockchain, toda transação requer uma taxa de rede, ou “gas”. Para usuários acostumados às experiências fluidas do Web2, isso representa um obstáculo cognitivo e operacional significativo. A Sui resolve esse desafio ao nível do protocolo com Transações Patrocinadas.

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

Paymaster ≈ Gas Station​

No ecossistema Sui, a lógica de patrocínio de transações costuma ser gerida por um serviço off‑chain ou on‑chain chamado Gas Station ou Paymaster. Suas principais responsabilidades incluem:

1. Avaliar a Transação: Recebe os dados da transação sem gas do usuário (GasLessTransactionData).
2. Fornecer Gas: Bloqueia e aloca a taxa de gas necessária para a transação. Isso geralmente é gerido por um pool de gas composto por vários objetos SUI Coin.
3. Gerar a 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: Envia de volta o TransactionData, que agora inclui os dados de gas e a assinatura do patrocinador, aguardando a assinatura final do usuário.

Em resumo, uma Gas Station funciona como um serviço de reabastecimento para os usuários do seu dApp, garantindo que seus “veículos” (transações) possam viajar suavemente na rede Sui.

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

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

Desdobramento 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 informações de gas.
2. O dApp envia esses dados ao Gas Station designado para solicitar patrocínio.
3. O Gas Station verifica a validade da solicitação (por exemplo, checa se o usuário é elegível), então preenche a transação com um Gas Coin e sua assinatura, retornando a transação semipreenchida ao dApp.
4. O Usuário visualiza os detalhes completos da transação em sua carteira (ex.: “Comprar um NFT”) e fornece a assinatura final. Essa etapa garante que o usuário mantenha consentimento e controle sobre suas ações.
5. O dApp transmite a transação completa, contendo ambas as assinaturas, ao Full Node Sui.
6. Após a finalização on‑chain, o Gas Station pode confirmar o evento escutando receipts ou eventos, e então notificar o backend do dApp via webhook, fechando o ciclo do processo de negócio.

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

Você pode usar os três modelos a seguir individualmente ou combinados, conforme as necessidades do seu negócio.

Modelo 1: Usuário Inicia → Patrocinador Aprova (Mais Comum)​

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

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

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

Modelo 2: Patrocinador Inicia Airdrops/Incentivos​

Ideal para airdrops, incentivos a usuários ou distribuições em lote.

1. Patrocinador pré-preenche TransactionData + assina: O patrocinador (geralmente a equipe do projeto) constrói a maior parte da transação (ex.: airdrop de NFT para um endereço específico) e anexa sua assinatura de patrocínio.
2. Segunda assinatura do Usuário a torna efetiva: O usuário só precisa assinar essa transação “pré‑aprovada” uma vez para que seja executada.

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

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

Um modelo mais flexível e baseado em permissões.

1. Patrocinador transfere um objeto GasData: Primeiro, o patrocinador cria um ou mais objetos Gas Coin com um orçamento específico e transfere a propriedade diretamente ao usuário.
2. Usuário gasta livremente dentro do orçamento: O usuário pode usar esses Gas Coins para pagar quaisquer transações que iniciar, respeitando limites de valor e período de validade.
3. Gas Coin é devolvido: Quando esgotado ou expirado, o objeto Gas Coin pode ser projetado para ser destruído automaticamente ou retornado ao patrocinador.

Esse modelo equivale a oferecer ao usuário um “cartão de crédito de taxas de gas” limitado no tempo e no valor, adequado para cenários que exigem alta 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 vai além de resolver o problema das taxas de gas; ele permite integração profunda com a lógica de negócio para criar novas possibilidades.

Cenário 1: Paywalls​

Plataformas de conteúdo ou serviços dApp frequentemente exigem que usuários cumpram certos critérios (ex.: possuir um NFT VIP, alcançar um nível de membresia) para acessar funcionalidades. O Paymaster pode implementar essa lógica de forma perfeita.

• Fluxo: O usuário solicita uma ação → o backend do dApp verifica as qualificações (ex.: propriedade de NFT) → se elegível, chama o Paymaster para patrocinar a taxa de gas; caso contrário, nega a solicitação de assinatura.
• Vantagem: Modelo inerentemente resistente a bots e abusos. Como a decisão de patrocínio ocorre no backend, usuários maliciosos não podem contornar a verificação para drenar fundos de gas.

Cenário 2: Checkout com Um Clique​

Em e‑commerce ou compras dentro de jogos, simplificar o processo de pagamento é crucial.

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

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

Rastreamento preciso de dados é fundamental para otimização de negócios.

• Fluxo: Ao construir a transação, escreva um identificador único (como order_hash) nos parâmetros da transação ou em um evento que será emitido na execução.
• Vantagem: Quando o Gas Station recebe o receipt on‑chain de uma transação bem‑sucedida, ele pode extrair facilmente esse order_hash analisando o evento ou os dados da transação. Isso permite mapear com precisão mudanças de estado on‑chain a pedidos ou ações específicas no backend.

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

A seguir, um trecho simplificado demonstrando os passos principais da 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 de Gas Station na documentação oficial da Sui, que oferece exemplos de código prontos para uso.

6. Riscos e Proteções​

Embora poderoso, implantar uma Gas Station em produção requer atenção cuidadosa aos seguintes riscos:

• Equivocação (Double‑Spending): Um usuário malicioso pode tentar usar o mesmo Gas Coin em múltiplas transações paralelas, o que faria o Gas Coin ficar bloqueado pela rede Sui. Isso pode ser mitigado atribuindo um Gas Coin único por usuário ou por transação, mantendo uma blacklist e aplicando limites de taxa.
• Gerenciamento do Pool de Gas: Em cenários de alta concorrência, um único Gas Coin de valor elevado pode se tornar um gargalo de desempenho. O serviço de Gas Station deve ser capaz de dividir automaticamente grandes SUI Coins em vários Gas Coins menores e recolhê‑los eficientemente após o uso. Provedores profissionais como a Shinami oferecem soluções gerenciadas maduras para isso.
• Autorização e Rate Limiting: É imprescindível estabelecer políticas rígidas de autorização e limitação de taxa. Por exemplo, controlar limites de patrocínio e frequência com base em IP, endereço de carteira ou tokens de API, evitando que o serviço seja drenado por atores maliciosos.

7. Ferramentas do Ecossistema​

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

• SDKs Oficiais (Rust/TypeScript): Incluem APIs de alto nível como sponsor_transaction_block(), reduzindo significativamente a complexidade de integração.
• Shinami Gas Station: Serviço gerenciado tudo‑em‑um, com divisão/recolhimento automático de Gas Coins, monitoramento detalhado de métricas e notificações via webhook, permitindo que desenvolvedores foquem na lógica de negócio.
• Enoki / Mysten Demos: A comunidade e a Mysten Labs oferecem implementações open‑source de Paymaster que podem servir como referência para construir seu próprio serviço.

8. Checklist de Implementação​

Pronto para levar seu dApp à era sem gas? Confira esta lista antes de iniciar:

• Planeje seu Fluxo de Financiamento: Defina a fonte de fundos do Patrocinador, orçamento e estratégia de reposição. Configure monitoramento e alertas para métricas chave (ex.: saldo do pool de gas, taxa de consumo).
• Reserve Campos de Atribuição: Ao projetar os parâmetros da transação, reserve campos para identificadores de negócio como order_id ou user_id.
• Implemente Políticas Anti‑Abuso: Autorizações estritas, limitação de taxa e mecanismos de logging são obrigatórios antes de ir ao ar.
• Teste em Testnet: Seja construindo seu próprio serviço ou integrando um Gas Station de terceiros, realize testes de concorrência e stress em testnet ou devnet primeiro.
• Otimize Continuamente: Após o lançamento, acompanhe taxas de sucesso, motivos de falha e custos de gas. Ajuste orçamento e estratégias com base nos dados coletados.

Conclusão​

O Sui Paymaster (Gas Station) é mais do que uma ferramenta para cobrir taxas de gas dos usuários. É um paradigma poderoso que combina elegantemente uma experiência “zero SUI on‑chain” para o usuário com a necessidade de negócios de “atribuição on‑chain ao nível de ordem” dentro de uma única transação atômica. Ele abre caminho para que usuários Web2 entrem no Web3 e oferece aos desenvolvedores flexibilidade sem precedentes para personalização de negócios.

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

Estamos felizes em anunciar o lançamento do staking de token SUI na BlockEden.xyz! A partir de hoje, você pode fazer staking dos seus tokens SUI diretamente através da nossa plataforma e ganhar um APY de 2,08% enquanto apoia a segurança e a descentralização da rede SUI.

O que há de novo: uma experiência de staking SUI sem atritos​

Nosso novo recurso de staking traz staking de nível institucional para todos, com uma interface simples e intuitiva que torna a obtenção de recompensas sem esforço.

Principais recursos​

Staking de Um Clique Fazer staking de SUI nunca foi tão fácil. Basta conectar sua carteira Suisplash, inserir a quantidade de SUI que deseja fazer staking e aprovar a transação. Você começará a ganhar recompensas quase imediatamente, sem procedimentos complexos.

Recompensas Competitivas Ganhe um APY de 2,08% competitivo sobre seu SUI em staking. Nossa taxa de comissão de 8% é transparente, garantindo que você saiba exatamente o que esperar. As recompensas são distribuídas diariamente ao final de cada epoch.

Validador Confiável Junte‑se a uma comunidade em crescimento que já fez staking de mais de 22 milhões de SUI com o validador BlockEden.xyz. Temos um histórico comprovado de serviços de validação confiáveis, suportados por infraestrutura de nível empresarial que garante 99,9% de uptime.

Gestão Flexível Seus ativos permanecem flexíveis. O staking é instantâneo, o que significa que suas recompensas começam a acumular imediatamente. Caso precise acessar seus fundos, você pode iniciar o processo de unstaking a qualquer momento. Seu SUI ficará disponível após o período padrão de desbloqueio da rede SUI, de 24 a 48 horas. Você pode acompanhar seus stakes e recompensas em tempo real através do nosso painel.

Por que fazer staking de SUI com a BlockEden.xyz?​

Escolher um validador é uma decisão crítica. Veja por que a BlockEden.xyz é uma escolha sólida para suas necessidades de staking.

Confiabilidade em que você pode confiar​

A BlockEden.xyz tem sido um alicerce da infraestrutura de blockchain desde a sua criação. Nossa infraestrutura de validadores alimenta aplicações empresariais e tem mantido uptime excepcional em múltiplas redes, garantindo geração consistente de recompensas.

Transparente e Justa​

Acreditamos em total transparência. Não há taxas ocultas — apenas uma comissão de 8% clara sobre as recompensas que você ganha. Você pode monitorar seu desempenho de staking com relatórios em tempo real e verificar a atividade do nosso validador on‑chain.

• Endereço do Validador Aberto: 0x3b5664bb0f8bb4a8be77f108180a9603e154711ab866de83c8344ae1f3ed4695

Integração Sem Atritos​

Nossa plataforma foi projetada para simplicidade. Não há necessidade de criar uma conta; você pode fazer staking diretamente da sua carteira. A experiência é otimizada para a carteira Suisplash, e nossa interface limpa e intuitiva foi construída tanto para iniciantes quanto para especialistas.

Como Começar​

Começar a fazer staking de SUI na BlockEden.xyz leva menos de dois minutos.

Etapa 1: Visite a página de Staking​

Acesse blockeden.xyz/dash/stake. Você pode iniciar o processo imediatamente, sem registro de conta.

Etapa 2: Conecte sua Carteira​

Se ainda não a tem, instale a carteira Suisplash. Clique no botão “Connect Wallet” na nossa página de staking e aprove a conexão na extensão da carteira. Seu saldo de SUI será exibido automaticamente.

Etapa 3: Escolha o Valor do Stake​

Insira a quantidade de SUI que deseja fazer staking (mínimo 1 SUI). Você pode usar o botão “MAX” para fazer staking de todo o saldo disponível, deixando uma pequena quantia para taxas de gas. Um resumo mostrará o valor do stake e as recompensas anuais estimadas.

Etapa 4: Confirme e Comece a Ganhar​

Clique em “Stake SUI” e aprove a transação final na sua carteira. Seu novo stake aparecerá no painel em tempo real, e você começará a acumular recompensas imediatamente.

Economia do Staking: O que Você Precisa Saber​

Entender a mecânica do staking é fundamental para gerir seus ativos de forma eficaz.

Estrutura de Recompensas​

• APY Base: 2,08% ao ano
• Frequência de Recompensa: Distribuída a cada epoch (aproximadamente 24 horas)
• Comissão: 8% das recompensas ganhas
• Capitalização: As recompensas são adicionadas à sua carteira e podem ser re‑staked para alcançar crescimento composto.

Exemplo de Ganhos​

A seguir, uma divisão simples dos ganhos potenciais baseada em um APY de 2,08%, após a taxa de comissão de 8%.

Nota: Estes são estimativas. As recompensas reais podem variar conforme as condições da rede.

Considerações de Risco​

O staking envolve certos riscos que você deve conhecer:

• Período de Unbonding: Ao fazer unstaking, seu SUI fica sujeito a um período de 24‑48 horas em que não pode ser acessado nem gera recompensas.
• Risco do Validador: Embora mantenhamos altos padrões, todo validador tem riscos operacionais. Escolher um validador reputado como a BlockEden.xyz é importante.
• Risco da Rede: O staking é uma forma de participação na rede e está sujeito aos riscos inerentes ao protocolo blockchain subjacente.
• Risco de Mercado: O valor de mercado do token SUI pode flutuar, afetando o valor total dos seus ativos em staking.

Excelência Técnica​

Infraestrutura Empresarial​

Nossos nós de validador são construídos sobre uma base de excelência técnica. Utilizamos sistemas redundantes distribuídos em múltiplas regiões geográficas para garantir alta disponibilidade. Nossa infraestrutura é monitorada 24/7 com recursos automáticos de failover, e uma equipe profissional de operações gerencia o sistema continuamente. Também realizamos auditorias de segurança regulares e verificações de conformidade.

Código Aberto e Transparência​

Comprometemo‑nos com os princípios de código aberto. Nossa integração de staking foi desenvolvida para ser transparente, permitindo que os usuários inspecionem os processos subjacentes. Métricas em tempo real estão disponíveis publicamente nos exploradores da rede SUI, e nossa estrutura de taxas é totalmente aberta, sem custos ocultos. Também participamos ativamente da governança da comunidade para apoiar o ecossistema SUI.

Apoio ao Ecossistema SUI​

Ao fazer staking com a BlockEden.xyz, você faz mais do que ganhar recompensas. Você contribui ativamente para a saúde e o crescimento de toda a rede SUI.

• Segurança da Rede: Seu stake aumenta o total que protege a rede SUI, tornando-a mais robusta contra possíveis ataques.
• Descentralização: Apoiar validadores independentes como a BlockEden.xyz reforça a resiliência da rede e impede a centralização.
• Crescimento do Ecossistema: As taxas de comissão que recebemos são reinvestidas na manutenção e desenvolvimento de infraestrutura crítica.
• Inovação: A receita apoia nossa pesquisa e desenvolvimento de novas ferramentas e serviços para a comunidade blockchain.

Segurança e Melhores Práticas​

Priorize a segurança dos seus ativos.

Segurança da Carteira​

• Nunca compartilhe suas chaves privadas ou frase‑semente com ninguém.
• Use uma carteira hardware para armazenar e fazer staking de grandes quantias.
• Sempre verifique os detalhes da transação na sua carteira antes de assinar.
• Mantenha seu software de carteira atualizado para a versão mais recente.

Segurança no Staking​

• Se você é novo no staking, comece com um valor pequeno para se familiarizar com o processo.
• Considere diversificar seu stake entre múltiplos validadores reputados para reduzir risco.
• Monitore regularmente seus ativos em staking e recompensas.
• Certifique‑se de entender o período de unbonding antes de comprometer seus fundos.

Junte‑se ao Futuro do Staking SUI​

O lançamento do staking de SUI na BlockEden.xyz é mais do que um novo recurso; é uma porta de entrada para participação ativa na economia descentralizada. Seja você um usuário experiente de DeFi ou esteja apenas começando, nossa plataforma oferece uma forma simples e segura de ganhar recompensas enquanto contribui para o futuro da rede SUI.

Pronto para começar a ganhar?

Visite blockeden.xyz/dash/stake e faça staking dos seus primeiros tokens SUI hoje mesmo!

Sobre a BlockEden.xyz​

A BlockEden.xyz é um provedor líder de infraestrutura de blockchain que oferece serviços confiáveis, escaláveis e seguros para desenvolvedores, empresas e a comunidade Web3 em geral. De serviços de API a operações de validadores, estamos comprometidos em construir a base para um futuro descentralizado.

• Fundada: 2021
• Redes Suportadas: mais de 15 redes blockchain
• Clientes Empresariais: mais de 500 empresas ao redor do mundo
• Valor Total Garantido: mais de US$ 100 milhões em todas as redes

Nos siga no Twitter, participe do nosso Discord e explore nossa suíte completa de serviços em BlockEden.xyz.

Aviso: Este post de blog tem fins informativos apenas e não constitui aconselhamento financeiro. O staking de criptomoedas envolve riscos, incluindo a possível perda do principal. Por favor, faça sua própria pesquisa e considere sua tolerância ao risco antes de fazer staking.

Introdução​

Os mercados descentralizados de inferência/treinamento de IA visam aproveitar recursos computacionais globais e modelos comunitários de uma forma que não exige confiança (trustless). Projetos como Bittensor, Gensyn e Cuckoo Network (Cuckoo AI) ilustram como a tecnologia blockchain pode impulsionar mercados abertos de IA. Cada plataforma tokeniza ativos-chave de IA – poder computacional, modelos de machine learning e, por vezes, dados – em unidades económicas on-chain. A seguir, aprofundamos as arquiteturas técnicas que sustentam estas redes, como elas tokenizam recursos, as suas estruturas de governança e incentivos, métodos para rastrear a propriedade de modelos, mecanismos de partilha de receitas e as superfícies de ataque (por exemplo, ataques sybil, conluio, parasitismo, envenenamento) que surgem. Uma tabela comparativa no final resume todas as dimensões-chave entre Bittensor, Gensyn e Cuckoo AI.

Arquiteturas Técnicas​

Bittensor: “Internet Neural” Descentralizada em Sub-redes​

O Bittensor é construído sobre uma blockchain de Camada 1 (Layer-1) personalizada (a cadeia Subtensor, baseada no Substrate) que coordena uma rede de nós de modelos de IA através de muitas sub-redes especializadas. Cada sub-rede é uma mini-rede independente focada numa tarefa de IA específica (por exemplo, uma sub-rede para geração de linguagem, outra para geração de imagens, etc.). Os participantes no Bittensor assumem papéis distintos:

• Mineradores – executam modelos de machine learning no seu hardware e fornecem respostas de inferência (ou até realizam treinamento) para a tarefa da sub-rede. Em essência, um minerador é um nó que aloja um modelo de IA que responderá a consultas.
• Validadores – consultam os modelos dos mineradores com prompts e avaliam a qualidade das respostas, formando uma opinião sobre quais mineradores estão a contribuir com resultados valiosos. Os validadores efetivamente pontuam o desempenho dos mineradores.
• Proprietários de Sub-redes – criam e definem sub-redes, estabelecendo as regras para as tarefas a serem realizadas e como a validação é feita nessa sub-rede. Um proprietário de sub-rede poderia, por exemplo, especificar que uma sub-rede é para um determinado conjunto de dados ou modalidade e definir o procedimento de validação.
• Delegadores – detentores de tokens que não executam nós podem delegar (fazer stake) os seus tokens Bittensor (TAO) a mineradores ou validadores para apoiar os melhores desempenhos e ganhar uma parte das recompensas (semelhante ao staking em redes de prova de participação).

O mecanismo de consenso do Bittensor é inovador: em vez da validação de blocos tradicional, o Bittensor usa o consenso Yuma, que é uma forma de “prova de inteligência”. No consenso Yuma, as avaliações dos mineradores pelos validadores são agregadas on-chain para determinar a distribuição de recompensas. A cada bloco de 12 segundos, a rede cria novos tokens TAO e distribui-os de acordo com o consenso dos validadores sobre quais mineradores forneceram trabalho útil. As pontuações dos validadores são combinadas num esquema de mediana ponderada por stake: opiniões discrepantes são cortadas e a opinião da maioria honesta prevalece. Isto significa que se a maioria dos validadores concordar que um minerador foi de alta qualidade, esse minerador receberá uma forte recompensa; se um validador se desviar muito dos outros (possivelmente devido a conluio ou erro), esse validador é penalizado por ganhar menos. Desta forma, a blockchain do Bittensor coordena um ciclo de feedback minerador-validador: os mineradores competem para produzir os melhores resultados de IA, e os validadores curam e classificam esses resultados, com ambos os lados a ganhar tokens proporcionais ao valor que adicionam. Esta arquitetura é frequentemente descrita como uma “rede neural descentralizada” ou “cérebro global”, onde os modelos aprendem com os sinais uns dos outros e evoluem coletivamente. Notavelmente, o Bittensor atualizou recentemente a sua cadeia para suportar compatibilidade com EVM (para contratos inteligentes) e introduziu o dTAO, um sistema de tokens e staking específicos de sub-rede (explicado mais tarde) para descentralizar ainda mais o controlo da alocação de recursos.

Gensyn: Protocolo de Computação Distribuída Trustless​

A Gensyn aborda a IA descentralizada do ponto de vista de um protocolo de computação distribuída para machine learning. A sua arquitetura conecta desenvolvedores (submitters) que têm tarefas de IA (como treinar um modelo ou executar um trabalho de inferência) com fornecedores de computação (solvers) em todo o mundo que têm recursos de GPU/TPU sobressalentes. Originalmente, a Gensyn planeava uma cadeia L1 Substrate, mas mudou para construir no Ethereum como um rollup para maior segurança e liquidez. A rede Gensyn é, portanto, uma Camada 2 (Layer-2) do Ethereum (um rollup do Ethereum) que coordena a publicação de trabalhos e pagamentos, enquanto a computação ocorre off-chain no hardware dos fornecedores.

Uma inovação central do design da Gensyn é o seu sistema de verificação para trabalho off-chain. A Gensyn usa uma combinação de verificação otimista (provas de fraude) e técnicas criptográficas para garantir que, quando um solver afirma ter executado uma tarefa de treinamento/inferência, o resultado está correto. Na prática, o protocolo envolve múltiplos papéis de participantes:

• Submitter – a parte que solicita um trabalho (por exemplo, alguém que precisa de treinar um modelo). Eles pagam a taxa da rede e fornecem o modelo/dados ou a especificação da tarefa.
• Solver – um nó que licita e executa a tarefa de ML no seu hardware. Eles treinarão o modelo ou executarão a inferência conforme solicitado, e depois submeterão os resultados e uma prova de computação.
• Verifier/Challenger – nós que podem auditar ou verificar aleatoriamente o trabalho do solver. A Gensyn implementa um esquema ao estilo Truebit, onde, por padrão, o resultado de um solver é aceite, mas um verificador pode desafiá-lo dentro de uma janela de tempo se suspeitar de um cálculo incorreto. Num desafio, uma “pesquisa binária” interativa através dos passos de computação (um protocolo de prova de fraude) é usada para identificar qualquer discrepância. Isto permite que a cadeia resolva disputas realizando apenas uma parte crítica mínima da computação on-chain, em vez de refazer toda a tarefa dispendiosa.

Crucialmente, a Gensyn foi projetada para evitar a redundância massiva de abordagens ingénuas. Em vez de ter muitos nós a repetir o mesmo trabalho de ML (o que destruiria a economia de custos), a abordagem de “prova de aprendizagem” da Gensyn usa metadados de treinamento para verificar se o progresso da aprendizagem foi feito. Por exemplo, um solver pode fornecer hashes criptográficos ou checkpoints de pesos intermédios do modelo e uma prova sucinta de que estes progrediram de acordo com as atualizações de treinamento. Esta prova probabilística de aprendizagem pode ser verificada de forma muito mais barata do que reexecutar todo o treinamento, permitindo a verificação trustless sem replicação completa. Apenas se um verificador detetar uma anomalia é que uma computação on-chain mais pesada seria acionada como último recurso. Esta abordagem reduz drasticamente a sobrecarga em comparação com a verificação por força bruta, tornando o treinamento de ML descentralizado mais viável. A arquitetura da Gensyn, portanto, enfatiza fortemente o design de jogo criptoeconómico: os solvers colocam um stake ou um depósito, e se eles trapacearem (submetendo resultados errados), perdem esse stake para os verificadores honestos que os apanham. Ao combinar a coordenação da blockchain (para pagamentos e resolução de disputas) com computação off-chain e verificação inteligente, a Gensyn cria um mercado para computação de ML que pode explorar GPUs ociosas em qualquer lugar, mantendo a ausência de confiança. O resultado é um “protocolo de computação” em hiperescala, onde qualquer desenvolvedor pode aceder a poder de treinamento acessível e distribuído globalmente sob demanda.

Cuckoo AI: Plataforma de Serviço de IA Descentralizada Full-Stack​

A Cuckoo Network (ou Cuckoo AI) adota uma abordagem mais integrada verticalmente, com o objetivo de fornecer serviços de IA descentralizados de ponta a ponta, em vez de apenas computação bruta. A Cuckoo construiu a sua própria blockchain (inicialmente uma Camada 1 chamada Cuckoo Chain no Arbitrum Orbit, um framework de rollup compatível com Ethereum) para orquestrar tudo: não só combina trabalhos com GPUs, mas também aloja aplicações de IA e lida com pagamentos num único sistema. O design é full-stack: combina uma blockchain para transações e governança, uma camada de recursos descentralizados de GPU/CPU e aplicações de IA e APIs voltadas para o utilizador no topo. Por outras palavras, a Cuckoo integra todas as três camadas – blockchain, computação e aplicação de IA – dentro de uma única plataforma.

Os participantes na Cuckoo dividem-se em quatro grupos:

• Construtores de Aplicações de IA (Coordenadores) – são desenvolvedores que implementam modelos ou serviços de IA na Cuckoo. Por exemplo, um desenvolvedor pode alojar um gerador de imagens Stable Diffusion ou um chatbot LLM como um serviço. Eles executam Nós Coordenadores, que são responsáveis por gerir o seu serviço: aceitar pedidos de utilizadores, dividi-los em tarefas e atribuir essas tarefas aos mineradores. Os coordenadores fazem stake do token nativo ($CAI) para se juntarem à rede e ganharem o direito de utilizar os mineradores. Eles essencialmente atuam como orquestradores de camada 2 que fazem a interface entre os utilizadores e os fornecedores de GPU.
• Mineradores de GPU/CPU (Nós de Tarefa) – são os fornecedores de recursos. Os mineradores executam o cliente de tarefas da Cuckoo e contribuem com o seu hardware para realizar tarefas de inferência para as aplicações de IA. Por exemplo, um minerador pode receber um pedido de geração de imagem (com um determinado modelo e prompt) de um coordenador e usar a sua GPU para calcular o resultado. Os mineradores também devem fazer stake de $CAI para garantir o compromisso e o bom comportamento. Eles ganham recompensas em tokens por cada tarefa que completam corretamente.
• Utilizadores Finais – os consumidores das aplicações de IA. Eles interagem através do portal web ou APIs da Cuckoo (por exemplo, gerando arte via CooVerse ou conversando com personalidades de IA). Os utilizadores podem pagar com criptomoedas por cada uso ou, possivelmente, contribuir com a sua própria computação (ou stake) para compensar os custos de uso. Um aspeto importante é a resistência à censura: se um coordenador (fornecedor de serviço) for bloqueado ou ficar offline, os utilizadores podem mudar para outro que sirva a mesma aplicação, uma vez que múltiplos coordenadores podem alojar modelos semelhantes na rede descentralizada.
• Stakers (Delegadores) – membros da comunidade que não executam serviços de IA ou hardware de mineração ainda podem participar fazendo stake de $CAI naqueles que o fazem. Ao votar com o seu stake em coordenadores ou mineradores de confiança, eles ajudam a sinalizar a reputação e, em troca, ganham uma parte das recompensas da rede. Este design constrói uma camada de reputação Web3: bons atores atraem mais stake (e, portanto, confiança e recompensas), enquanto maus atores perdem stake e reputação. Mesmo os utilizadores finais podem fazer stake em alguns casos, alinhando-os com o sucesso da rede.

A cadeia Cuckoo (agora em processo de transição de uma cadeia autónoma para um rollup de segurança partilhada) rastreia todas estas interações. Quando um utilizador invoca um serviço de IA, o nó coordenador cria atribuições de tarefas on-chain para os mineradores. Os mineradores executam as tarefas off-chain e devolvem os resultados ao coordenador, que os valida (por exemplo, verificando se a imagem ou texto de saída não é um disparate) e entrega o resultado final ao utilizador. A blockchain lida com a liquidação de pagamentos: para cada tarefa, o contrato inteligente do coordenador paga ao minerador em $CAI (muitas vezes agregando micropagamentos em pagamentos diários). A Cuckoo enfatiza a ausência de confiança e a transparência – todos os participantes fazem stake de tokens e todas as atribuições e conclusões de tarefas são registadas, de modo que a fraude é desencorajada pela ameaça de perder o stake e pela visibilidade pública do desempenho. O design modular da rede significa que novos modelos de IA ou casos de uso podem ser adicionados facilmente: embora tenha começado com a geração de texto para imagem como prova de conceito, a sua arquitetura é geral o suficiente para suportar outras cargas de trabalho de IA (por exemplo, inferência de modelos de linguagem, transcrição de áudio, etc.).

Um aspeto notável da arquitetura da Cuckoo é que ela lançou inicialmente a sua própria blockchain de Camada 1 para maximizar o débito para transações de IA (atingindo um pico de 300k transações diárias durante os testes). Isto permitiu otimizações personalizadas para o agendamento de tarefas de IA. No entanto, a equipa descobriu que manter uma L1 autónoma era dispendioso e complexo, e em meados de 2025 decidiram descontinuar a cadeia personalizada e migrar para um modelo de rollup/AVS (Active Validated Service) no Ethereum. Isto significa que a Cuckoo herdará a segurança do Ethereum ou de uma L2 como o Arbitrum, em vez de executar o seu próprio consenso, mas continuará a operar o seu mercado de IA descentralizado nessa camada de segurança partilhada. A mudança destina-se a melhorar a segurança económica (aproveitando a robustez do Ethereum) e a permitir que a equipa da Cuckoo se concentre no produto em vez da manutenção da cadeia de baixo nível. Em resumo, a arquitetura da Cuckoo cria uma plataforma de serviço de IA descentralizada onde qualquer pessoa pode ligar hardware ou implementar um serviço de modelo de IA, e utilizadores globalmente podem aceder a aplicações de IA com menor custo e menos dependência da infraestrutura das grandes empresas de tecnologia.

Mecanismos de Tokenização de Ativos​

Um tema comum destas redes é a conversão de computação, modelos e dados em ativos on-chain ou unidades económicas que podem ser negociadas ou monetizadas. No entanto, cada projeto foca-se em tokenizar estes recursos de maneiras diferentes:

• Poder Computacional: Todas as três plataformas transformam o trabalho computacional em tokens de recompensa. No Bittensor, a computação útil (inferência ou treinamento feito por um minerador) é quantificada através das pontuações dos validadores e recompensada com tokens TAO a cada bloco. Essencialmente, o Bittensor “mede” a inteligência contribuída e cria TAO como uma mercadoria que representa essa contribuição. A Gensyn trata explicitamente a computação como uma mercadoria – o seu protocolo cria um mercado onde o tempo de GPU é o produto, e o preço é definido pela oferta e procura em termos de tokens. Os desenvolvedores compram computação usando o token, e os fornecedores ganham tokens vendendo os seus ciclos de hardware. A equipa da Gensyn observa que qualquer recurso digital (computação, dados, algoritmos) pode ser representado e negociado num mercado trustless semelhante. A Cuckoo tokeniza a computação através de um token ERC-20 $CAI emitido como pagamento por tarefas concluídas. Os fornecedores de GPU essencialmente “mineram” CAI ao fazerem trabalho de inferência de IA. O sistema da Cuckoo cria registos on-chain de tarefas, então pode-se pensar em cada tarefa de GPU concluída como uma unidade atómica de trabalho que é paga em tokens. A premissa em todos os três é que o poder computacional, de outra forma ocioso ou inacessível, se torna um ativo tokenizado e líquido – seja através de emissões de tokens ao nível do protocolo (como no Bittensor e na Cuckoo inicial) ou através de um mercado aberto de ordens de compra/venda para trabalhos de computação (como na Gensyn).

• Modelos de IA: Representar modelos de IA como ativos on-chain (por exemplo, NFTs ou tokens) ainda é incipiente. O Bittensor não tokeniza os modelos em si – os modelos permanecem off-chain sob a propriedade dos mineradores. Em vez disso, o Bittensor atribui indiretamente um valor aos modelos, recompensando aqueles que têm um bom desempenho. Na prática, a “inteligência” de um modelo é transformada em ganhos de TAO, mas não há um NFT que represente os pesos do modelo ou permita que outros o usem. O foco da Gensyn está nas transações de computação, não explicitamente na criação de tokens para modelos. Um modelo na Gensyn é tipicamente fornecido por um desenvolvedor off-chain (talvez de código aberto ou proprietário), treinado por solvers e devolvido – não há um mecanismo integrado para criar um token que possua o modelo ou a sua propriedade intelectual. (Dito isto, o mercado da Gensyn poderia potencialmente facilitar a negociação de artefactos ou checkpoints de modelos se as partes assim o desejarem, mas o protocolo em si vê os modelos como o conteúdo da computação, em vez de um ativo tokenizado.) A Cuckoo situa-se algures no meio: fala de “agentes de IA” e modelos integrados na rede, mas atualmente não há um token não fungível que represente cada modelo. Em vez disso, um modelo é implementado por um construtor de aplicações e depois servido através da rede. Os direitos de uso desse modelo são implicitamente tokenizados, na medida em que o modelo pode ganhar $CAI quando é usado (através do coordenador que o implementa). Todas as três plataformas reconhecem o conceito de tokenização de modelos – por exemplo, dar às comunidades a propriedade de modelos através de tokens – mas as implementações práticas são limitadas. Como indústria, a tokenização de modelos de IA (por exemplo, como NFTs com direitos de propriedade e partilha de lucros) ainda está a ser explorada. A abordagem do Bittensor de modelos a trocarem valor entre si é uma forma de “mercado de modelos” sem um token explícito por modelo. A equipa da Cuckoo observa que a propriedade descentralizada de modelos é promissora para reduzir as barreiras em comparação com a IA centralizada, mas requer métodos eficazes para verificar os resultados e o uso dos modelos on-chain. Em resumo, o poder computacional é imediatamente tokenizado (é simples pagar tokens por trabalho feito), enquanto os modelos são indireta ou aspiracionalmente tokenizados (recompensados pelos seus resultados, possivelmente representados por stake ou reputação, mas ainda não tratados como NFTs transferíveis nestas plataformas).

• Dados: A tokenização de dados continua a ser a mais difícil. Nenhum dos projetos Bittensor, Gensyn ou Cuckoo tem mercados de dados on-chain totalmente generalizados e integrados (onde conjuntos de dados são negociados com direitos de uso aplicáveis). Os nós do Bittensor podem treinar em vários conjuntos de dados, mas esses conjuntos de dados não fazem parte do sistema on-chain. A Gensyn pode permitir que um desenvolvedor forneça um conjunto de dados para treinamento, mas o protocolo não tokeniza esses dados – são simplesmente fornecidos off-chain para o solver usar. A Cuckoo, da mesma forma, não tokeniza os dados do utilizador; lida principalmente com dados (como prompts ou resultados de utilizadores) de forma transitória para tarefas de inferência. O blog da Cuckoo afirma explicitamente que “os dados descentralizados continuam a ser um desafio para tokenizar” apesar de serem um recurso crítico. Os dados são sensíveis (questões de privacidade e propriedade) e difíceis de manusear com a tecnologia blockchain atual. Assim, enquanto a computação está a ser comoditizada e os modelos começam a sê-lo, os dados permanecem em grande parte off-chain, exceto em casos especiais (alguns projetos fora destes três estão a experimentar uniões de dados e recompensas em tokens por contribuições de dados, mas isso está fora do nosso âmbito atual). Em resumo, o poder computacional é agora uma mercadoria on-chain nestas redes, os modelos são valorizados através de tokens, mas ainda não tokenizados individualmente como ativos, e a tokenização de dados ainda é um problema em aberto (além de reconhecer a sua importância).

Governança e Incentivos​

Um design robusto de governança e incentivos é crucial para que estas redes de IA descentralizadas funcionem de forma autónoma e justa. Aqui, examinamos como cada plataforma se governa (quem toma as decisões, como ocorrem as atualizações ou alterações de parâmetros) e como alinham os incentivos dos participantes através da economia de tokens.

• Governança do Bittensor: Nas suas fases iniciais, o desenvolvimento e os parâmetros das sub-redes do Bittensor eram em grande parte controlados pela equipa principal e por um conjunto de 64 validadores “raiz” na sub-rede principal. Este era um ponto de centralização – alguns validadores poderosos tinham uma influência desproporcional na alocação de recompensas, levando ao que alguns chamaram de “sistema de votação oligárquico”. Para resolver isto, o Bittensor introduziu a governança dTAO (TAO descentralizado) em 2025. O sistema dTAO mudou a alocação de recursos para ser impulsionada pelo mercado e controlada pela comunidade. Concretamente, os detentores de TAO podem fazer stake dos seus tokens em pools de liquidez específicos de sub-redes (essencialmente, eles “votam” em quais sub-redes devem receber mais emissões da rede) e recebem tokens alfa que representam a propriedade nesses pools de sub-redes. As sub-redes que atraem mais stake terão um preço de token alfa mais alto e receberão uma fatia maior da emissão diária de TAO, enquanto as sub-redes impopulares ou com baixo desempenho verão o capital (e, portanto, as emissões) a afastar-se. Isto cria um ciclo de feedback: se uma sub-rede produz serviços de IA valiosos, mais pessoas fazem stake de TAO nela (procurando recompensas), o que dá a essa sub-rede mais TAO para recompensar os seus participantes, fomentando o crescimento. Se uma sub-rede estagnar, os stakers retiram-se para sub-redes mais lucrativas. Na prática, os detentores de TAO governam coletivamente o foco da rede ao sinalizarem financeiramente quais domínios de IA merecem mais recursos. Esta é uma forma de governança on-chain por peso de token, alinhada com os resultados económicos. Além da alocação de recursos, grandes atualizações de protocolo ou alterações de parâmetros provavelmente ainda passam por propostas de governança onde os detentores de TAO votam (o Bittensor tem um mecanismo para propostas e referendos on-chain geridos pela Fundação Bittensor e um conselho eleito, semelhante à governança do Polkadot). Com o tempo, pode-se esperar que a governança do Bittensor se torne cada vez mais descentralizada, com a fundação a recuar à medida que a comunidade (através do stake de TAO) orienta coisas como a taxa de inflação, a aprovação de novas sub-redes, etc. A transição para o dTAO é um grande passo nessa direção, substituindo os decisores centralizados por um mercado de detentores de tokens alinhado por incentivos.

• Incentivos do Bittensor: A estrutura de incentivos do Bittensor está intimamente ligada ao seu consenso. A cada bloco (12 segundos), exatamente 1 TAO é recém-criado e dividido entre os contribuidores de cada sub-rede com base no desempenho. A divisão padrão para a recompensa de bloco de cada sub-rede é 41% para os mineradores, 41% para os validadores e 18% para o proprietário da sub-rede. Isto garante que todos os papéis são recompensados: os mineradores ganham por fazer o trabalho de inferência, os validadores ganham pelo seu esforço de avaliação, e os proprietários de sub-redes (que podem ter iniciado os dados/tarefa para essa sub-rede) ganham um resíduo por fornecerem o “mercado” ou o design da tarefa. Essas percentagens são fixas no protocolo e visam alinhar os incentivos de todos para uma produção de IA de alta qualidade. O mecanismo de consenso Yuma refina ainda mais os incentivos ao ponderar as recompensas de acordo com as pontuações de qualidade – um minerador que fornece melhores respostas (conforme o consenso dos validadores) obtém uma porção maior desses 41%, e um validador que segue de perto o consenso honesto obtém mais da porção do validador. Os maus desempenhos são eliminados economicamente. Além disso, os delegadores (stakers) que apoiam um minerador ou validador normalmente recebem uma parte dos ganhos desse nó (os nós geralmente definem uma comissão e dão o resto aos seus delegadores, semelhante ao staking em redes PoS). Isto permite que os detentores passivos de TAO apoiem os melhores contribuidores e ganhem rendimento, reforçando ainda mais a meritocracia. O token do Bittensor (TAO) é, portanto, um token de utilidade: é necessário para o registo de novos mineradores (os mineradores devem gastar uma pequena quantidade de TAO para se juntarem, o que combate o spam sybil) e pode ser colocado em stake para aumentar a influência ou ganhar através da delegação. Também é previsto como um token de pagamento se utilizadores externos quiserem consumir serviços da rede do Bittensor (por exemplo, pagar TAO para consultar um modelo de linguagem no Bittensor), embora o mecanismo de recompensa interno tenha sido a principal “economia” até agora. A filosofia geral de incentivos é recompensar a “inteligência valiosa” – ou seja, modelos que ajudam a produzir bons resultados de IA – e criar uma competição que melhora continuamente a qualidade dos modelos na rede.

• Governança da Gensyn: O modelo de governança da Gensyn está estruturado para evoluir do controlo da equipa principal para o controlo da comunidade à medida que a rede amadurece. Inicialmente, a Gensyn terá uma Fundação Gensyn e um conselho eleito que supervisionarão as atualizações do protocolo e as decisões do tesouro. Espera-se que este conselho seja composto por membros da equipa principal e líderes comunitários iniciais. A Gensyn planeia um Evento de Geração de Tokens (TGE) para o seu token nativo (frequentemente referido como GENS), após o qual o poder de governança passaria cada vez mais para as mãos dos detentores de tokens através de votação on-chain. O papel da fundação é representar os interesses do protocolo e garantir uma transição suave para a descentralização total. Na prática, a Gensyn provavelmente terá mecanismos de proposta on-chain onde alterações de parâmetros (por exemplo, duração do jogo de verificação, taxas) ou atualizações são votadas pela comunidade. Como a Gensyn está a ser implementada como um rollup do Ethereum, a governança também pode estar ligada à segurança do Ethereum (por exemplo, usando chaves de atualização para o contrato do rollup que eventualmente são entregues a uma DAO de detentores de tokens). A secção de descentralização e governança do litepaper da Gensyn enfatiza que o protocolo deve, em última análise, ser de propriedade global, alinhando-se com o ethos de que a “rede para inteligência de máquina” deve pertencer aos seus utilizadores e contribuidores. Em resumo, a governança da Gensyn começa semi-centralizada, mas está arquitetada para se tornar uma DAO onde os detentores de tokens GENS (potencialmente ponderados por stake ou participação) tomam decisões coletivamente.

• Incentivos da Gensyn: Os incentivos económicos na Gensyn são dinâmicas de mercado diretas, complementadas por segurança criptoeconómica. Os desenvolvedores (clientes) pagam por tarefas de ML no token Gensyn, e os Solvers ganham tokens ao completar essas tarefas corretamente. O preço dos ciclos de computação é determinado por um mercado aberto – presumivelmente, os desenvolvedores podem colocar tarefas com uma recompensa e os solvers podem licitar ou simplesmente aceitá-la se o preço corresponder às suas expectativas. Isto garante que, enquanto houver oferta de GPUs ociosas, a competição levará o custo a uma taxa justa (a equipa da Gensyn projeta uma redução de custos de até 80% em comparação com os preços da nuvem, pois a rede encontra o hardware disponível mais barato globalmente). Por outro lado, os solvers têm o incentivo de ganhar tokens por trabalho; o seu hardware que, de outra forma, estaria ocioso, agora gera receita. Para garantir a qualidade, a Gensyn exige que os solvers coloquem colateral em stake quando assumem um trabalho – se eles trapacearem ou produzirem um resultado incorreto e forem apanhados, perdem esse stake (pode ser cortado e atribuído ao verificador honesto). Os verificadores são incentivados pela chance de ganhar uma recompensa “jackpot” se apanharem um solver fraudulento, semelhante ao design do Truebit de recompensar periodicamente os verificadores que identificam com sucesso computações incorretas. Isto mantém os solvers honestos e motiva alguns nós a agirem como vigilantes. Num cenário ótimo (sem trapaça), os solvers simplesmente ganham a taxa da tarefa e o papel do verificador fica maioritariamente ocioso (ou um dos solvers participantes pode também atuar como verificador de outros). O token da Gensyn serve, portanto, como moeda de gás para comprar computação e como colateral de stake que protege o protocolo. O litepaper menciona uma testnet com tokens não permanentes e que os participantes iniciais da testnet serão recompensados no TGE com tokens reais. Isto indica que a Gensyn alocou alguma oferta de tokens para bootstrapping – recompensando os primeiros adotantes, solvers de teste e membros da comunidade. A longo prazo, as taxas de trabalhos reais devem sustentar a rede. Pode também haver uma pequena taxa de protocolo (uma percentagem de cada pagamento de tarefa) que vai para um tesouro ou é queimada; este detalhe ainda não está confirmado, mas muitos protocolos de mercado incluem uma taxa para financiar o desenvolvimento ou a compra e queima de tokens. Em resumo, os incentivos da Gensyn alinham-se em torno da conclusão honesta de trabalhos de ML: faça o trabalho, seja pago; tente trapacear, perca o stake; verifique os outros, ganhe se apanhar trapaças. Isto cria um sistema económico auto-policiado, destinado a alcançar uma computação distribuída fiável.

• Governança da Cuckoo: A Cuckoo Network integrou a governança no seu ecossistema desde o primeiro dia, embora ainda esteja em fase de desenvolvimento. O token $CAI é explicitamente um token de governança, além dos seus papéis de utilidade. A filosofia da Cuckoo é que os operadores de nós de GPU, os desenvolvedores de aplicações e até os utilizadores finais devem ter uma palavra a dizer na evolução da rede – refletindo a sua visão impulsionada pela comunidade. Na prática, decisões importantes (como atualizações de protocolo ou alterações económicas) seriam decididas por votos ponderados por tokens, presumivelmente através de um mecanismo de DAO. Por exemplo, a Cuckoo poderia realizar votações on-chain para alterar a distribuição de recompensas ou adotar uma nova funcionalidade, e os detentores de $CAI (incluindo mineradores, desenvolvedores e utilizadores) votariam. A votação on-chain já é usada como um sistema de reputação: a Cuckoo exige que cada papel faça stake de tokens, e depois os membros da comunidade podem votar (talvez delegando stake ou através de módulos de governança) em quais coordenadores ou mineradores são confiáveis. Isto afeta as pontuações de reputação e pode influenciar o agendamento de tarefas (por exemplo, um coordenador com mais votos pode atrair mais utilizadores, ou um minerador com mais votos pode receber mais tarefas). É uma mistura de governança e incentivo – usar tokens de governança para estabelecer confiança. A Fundação Cuckoo ou a equipa principal tem guiado a direção do projeto até agora (por exemplo, tomando a recente decisão de descontinuar a cadeia L1), mas o seu blog indica um compromisso em avançar para a propriedade descentralizada. Eles identificaram que executar a sua própria cadeia incorria em altos custos e que a mudança para um rollup permitirá um desenvolvimento mais aberto e integração com ecossistemas existentes. É provável que, uma vez numa camada partilhada (como o Ethereum), a Cuckoo implemente uma DAO mais tradicional para atualizações, com a comunidade a votar usando CAI.

• Incentivos da Cuckoo: O design de incentivos para a Cuckoo tem duas fases: a fase inicial de bootstrapping com alocações fixas de tokens, e um estado futuro com partilha de receitas impulsionada pelo uso. No lançamento, a Cuckoo realizou uma distribuição de “lançamento justo” de 1 bilião de tokens CAI. 51% da oferta foi reservada para a comunidade, alocada como:

  • Recompensas de Mineração: 30% da oferta total reservada para pagar aos mineradores de GPU por realizarem tarefas de IA.
  • Recompensas de Staking: 11% da oferta para aqueles que fazem stake e ajudam a proteger a rede.
  • Airdrops: 5% para os primeiros utilizadores e membros da comunidade como um incentivo à adoção.
  • (Outros 5% foram para subsídios a desenvolvedores para encorajar a construção na Cuckoo.)

  Esta grande alocação significa que, na rede inicial, os mineradores e stakers foram recompensados de um pool de emissão, mesmo que a procura real dos utilizadores fosse baixa. De facto, a fase inicial da Cuckoo apresentou altos rendimentos APY para staking e mineração, o que atraiu com sucesso participantes, mas também “yield farmers” que estavam lá apenas pelos tokens. A equipa notou que muitos utilizadores saíram assim que as taxas de recompensa caíram, indicando que esses incentivos não estavam ligados ao uso genuíno. Tendo aprendido com isso, a Cuckoo está a mudar para um modelo onde as recompensas se correlacionam diretamente com a carga de trabalho real de IA. No futuro (e parcialmente já), quando um utilizador final paga por uma inferência de IA, esse pagamento (em CAI ou possivelmente outro token aceite convertido para CAI) será dividido entre os contribuidores:

  • Mineradores de GPU receberão a maior parte pela computação que forneceram.
  • Coordenador (desenvolvedor da aplicação) ficará com uma porção como o fornecedor de serviço que forneceu o modelo e lidou com o pedido.
  • Stakers que delegaram nesses mineradores ou coordenadores podem receber uma pequena parte ou uma recompensa inflacionária, para continuar a incentivar o apoio a nós fiáveis.
  • Rede/Tesouro pode reter uma taxa para o desenvolvimento contínuo ou para financiar incentivos futuros (ou a taxa pode ser zero/nominal para maximizar a acessibilidade para o utilizador).

  Essencialmente, a Cuckoo está a mover-se para um modelo de partilha de receitas: se uma aplicação de IA na Cuckoo gera ganhos, esses ganhos são distribuídos a todos os contribuidores desse serviço de forma justa. Isto alinha os incentivos para que os participantes beneficiem do uso real em vez de apenas da inflação. A rede já exigia que todas as partes fizessem stake de CAI – isto significa que os mineradores e coordenadores não ganham apenas uma recompensa fixa, mas também possivelmente recompensas baseadas em stake (por exemplo, um coordenador pode ganhar recompensas mais altas se muitos utilizadores fizerem stake nele ou se ele próprio fizer mais stake, semelhante a como os validadores de prova de participação ganham). Em termos de incentivos para os utilizadores, a Cuckoo também introduziu coisas como um portal de airdrop e faucets (que alguns utilizadores exploraram) para semear a atividade inicial. No futuro, os utilizadores podem ser incentivados através de reembolsos em tokens por usarem os serviços ou através de recompensas de governança por participarem na curadoria (por exemplo, talvez ganhando pequenos tokens por avaliarem resultados ou contribuírem com dados). A linha de fundo é que o token da Cuckoo ($CAI) é multifuncional: é o token de gás/taxa na cadeia (todas as transações e pagamentos o usam), é usado para staking e votação, e é a unidade de recompensa pelo trabalho feito. A Cuckoo menciona explicitamente que quer ligar as recompensas de tokens a KPIs de nível de serviço (indicadores-chave de desempenho) – por exemplo, tempo de atividade, débito de consultas, satisfação do utilizador – para evitar incentivos puramente especulativos. Isto reflete um amadurecimento da economia de tokens, de uma simples mineração de liquidez para um modelo mais sustentável e impulsionado pela utilidade.

Propriedade de Modelos e Atribuição de PI​

Lidar com a propriedade intelectual (PI) e os direitos de propriedade de modelos de IA é um aspeto complexo das redes de IA descentralizadas. Cada plataforma adotou uma postura ligeiramente diferente, e geralmente esta é uma área em evolução sem uma solução completa ainda:

• Bittensor: Os modelos no Bittensor são fornecidos pelos nós mineradores, e esses mineradores mantêm o controlo total sobre os pesos dos seus modelos (que nunca são publicados on-chain). O Bittensor não rastreia explicitamente quem “possui” um modelo, além do facto de que ele está a ser executado num determinado endereço de carteira. Se um minerador sair, o seu modelo sai com ele. Assim, a atribuição de PI no Bittensor é off-chain: se um minerador usa um modelo proprietário, não há nada on-chain que imponha ou sequer saiba disso. A filosofia do Bittensor incentiva contribuições abertas (muitos mineradores podem usar modelos de código aberto como GPT-J ou outros) e a rede recompensa o desempenho desses modelos. Poder-se-ia dizer que o Bittensor cria uma pontuação de reputação para os modelos (através das classificações dos validadores), e isso é uma forma de reconhecer o valor do modelo, mas os direitos sobre o modelo em si não são tokenizados ou distribuídos. Notavelmente, os proprietários de sub-redes no Bittensor podem ser vistos como possuidores de uma parte da PI: eles definem uma tarefa (que pode incluir um conjunto de dados ou método). O proprietário da sub-rede cria um NFT (chamado de UID de sub-rede) ao criar uma sub-rede, e esse NFT dá-lhes direito a 18% das recompensas nessa sub-rede. Isto efetivamente tokeniza a criação de um mercado de modelos (a sub-rede), se não as instâncias do modelo. Se considerarmos a definição da sub-rede (digamos, uma tarefa de reconhecimento de fala com um conjunto de dados específico) como PI, isso é pelo menos registado e recompensado. Mas os pesos individuais dos modelos que os mineradores treinam – não há um registo de propriedade on-chain deles. A atribuição vem na forma de recompensas pagas ao endereço desse minerador. O Bittensor atualmente não implementa um sistema onde, por exemplo, várias pessoas possam possuir conjuntamente um modelo e obter uma partilha de receitas automática – a pessoa que executa o modelo (minerador) recebe a recompensa e cabe a ela, off-chain, honrar quaisquer licenças de PI do modelo que usou.

• Gensyn: Na Gensyn, a propriedade do modelo é direta, na medida em que o submitter (aquele que quer um modelo treinado) fornece a arquitetura do modelo e os dados, e após o treinamento, ele recebe o artefacto do modelo resultante. Os solvers que realizam o trabalho não têm direitos sobre o modelo; são como contratados a serem pagos por um serviço. O protocolo da Gensyn assume, portanto, o modelo de PI tradicional: se você tinha direitos legais sobre o modelo e os dados que submeteu, ainda os tem depois de treinado – a rede de computação não reivindica qualquer propriedade. A Gensyn menciona que o mercado também poderia negociar algoritmos e dados como qualquer outro recurso. Isto sugere um cenário onde alguém poderia oferecer um modelo ou algoritmo para uso na rede, possivelmente por uma taxa, tokenizando assim o acesso a esse modelo. Por exemplo, um criador de modelos poderia colocar o seu modelo pré-treinado na Gensyn e permitir que outros o ajustassem através da rede por uma taxa (isto monetizaria efetivamente a PI do modelo). Embora o protocolo não imponha termos de licença, poder-se-ia codificar requisitos de pagamento: um contrato inteligente poderia exigir uma taxa para desbloquear os pesos do modelo para um solver. No entanto, estes são casos de uso especulativos – o design principal da Gensyn é sobre permitir trabalhos de treinamento. Quanto à atribuição, se várias partes contribuírem para um modelo (digamos, uma fornece dados, outra fornece computação), isso provavelmente seria tratado por qualquer contrato ou acordo que eles estabelecessem antes de usar a Gensyn (por exemplo, um contrato inteligente poderia dividir o pagamento entre o fornecedor de dados e o fornecedor de computação). A Gensyn em si não rastreia “este modelo foi construído por X, Y, Z” on-chain, além do registo de quais endereços foram pagos pelo trabalho. Em suma, a PI do modelo na Gensyn permanece com o submitter, e qualquer atribuição ou licenciamento deve ser tratado através de acordos legais fora do protocolo ou através de contratos inteligentes personalizados construídos sobre ele.

• Cuckoo: No ecossistema da Cuckoo, os criadores de modelos (construtores de aplicações de IA) são participantes de primeira classe – eles implementam o serviço de IA. Se um construtor de aplicações ajusta um modelo de linguagem ou desenvolve um modelo personalizado e o aloja na Cuckoo, esse modelo é essencialmente sua propriedade e eles atuam como o proprietário do serviço. A Cuckoo não se apropria de nenhuma propriedade; em vez disso, fornece a infraestrutura para que eles monetizem o uso. Por exemplo, se um desenvolvedor implementa uma IA de chatbot, os utilizadores podem interagir com ela e o desenvolvedor (mais os mineradores) ganham CAI de cada interação. A plataforma atribui, assim, a receita de uso ao criador do modelo, mas não publica explicitamente os pesos do modelo nem os transforma num NFT. Na verdade, para executar o modelo nas GPUs dos mineradores, o nó coordenador provavelmente tem de enviar o modelo (ou o tempo de execução) ao minerador de alguma forma. Isto levanta questões de PI: poderia um minerador malicioso copiar os pesos do modelo e distribuí-los? Numa rede descentralizada, esse risco existe se forem usados modelos proprietários. O foco atual da Cuckoo tem sido em modelos razoavelmente abertos (Stable Diffusion, modelos derivados do LLaMA, etc.) e na construção de uma comunidade, por isso ainda não vimos uma aplicação de direitos de PI através de contratos inteligentes. A plataforma poderia potencialmente integrar ferramentas como execução de modelos encriptados ou enclaves seguros no futuro para proteção de PI, mas nada específico é mencionado na documentação. O que ela rastreia é quem forneceu o serviço de modelo para cada tarefa – como o coordenador é uma identidade on-chain, todo o uso do seu modelo é contabilizado para ele, e ele recebe automaticamente a sua parte das recompensas. Se alguém fosse entregar ou vender um modelo a outra pessoa, efetivamente transferiria o controlo do nó coordenador (talvez até mesmo dando-lhe a chave privada ou o NFT se o papel de coordenador fosse tokenizado). Atualmente, a propriedade comunitária de modelos (através de participações em tokens) não está implementada, mas a visão da Cuckoo aponta para uma IA descentralizada impulsionada pela comunidade, então eles podem explorar a possibilidade de permitir que as pessoas financiem ou governem coletivamente um modelo de IA. A tokenização de modelos para além da propriedade individual ainda é uma área em aberto nestas redes – é reconhecida como um objetivo (permitir que as comunidades possuam modelos de IA em vez de corporações), mas na prática requer soluções para os desafios de PI e verificação acima mencionados.

Em resumo, a propriedade de modelos no Bittensor, Gensyn e Cuckoo é tratada off-chain por meios tradicionais: a pessoa ou entidade que executa ou submete o modelo é efetivamente o proprietário. As redes fornecem atribuição na forma de recompensas económicas (pagando ao contribuidor do modelo pela sua PI ou esforço). Nenhuma das três tem uma licença ou aplicação de royalties integrada no uso de modelos ao nível do contrato inteligente ainda. A atribuição vem através da reputação e da recompensa: por exemplo, os melhores modelos do Bittensor ganham altas pontuações de reputação (que é um registo público) e mais TAO, o que é um crédito implícito aos seus criadores. Com o tempo, podemos ver funcionalidades como pesos de modelo vinculados a NFTs ou licenças descentralizadas para melhor rastrear a PI, mas atualmente a prioridade tem sido fazer as redes funcionarem e incentivarem as contribuições. Todos concordam que verificar a proveniência e os resultados dos modelos é fundamental para permitir verdadeiros mercados de ativos de modelos, e a pesquisa está em andamento nessa direção.

Estruturas de Partilha de Receitas​

Todas as três plataformas devem decidir como dividir o bolo económico quando várias partes colaboram para produzir um resultado de IA valioso. Quem é pago, e quanto, quando um serviço de IA é usado ou quando os tokens são emitidos? Cada uma tem um modelo de partilha de receitas distinto:

• Bittensor: Como mencionado em incentivos, a distribuição de receitas do Bittensor é definida pelo protocolo ao nível do bloco: 41% para os mineradores, 41% para os validadores, 18% para o proprietário da sub-rede para cada emissão de TAO do bloco. Isto é efetivamente uma divisão de receitas integrada para o valor gerado em cada sub-rede. A parte do proprietário da sub-rede (18%) funciona como um royalty pelo “design do modelo/tarefa” ou por iniciar o ecossistema dessa sub-rede. Mineradores e validadores a receberem partes iguais garante que, sem validação, os mineradores não são recompensados (e vice-versa) – eles são simbióticos e cada um recebe uma porção igual das recompensas criadas. Se considerarmos um utilizador externo a pagar TAO para consultar um modelo, o whitepaper do Bittensor prevê que esse pagamento também seja dividido de forma semelhante entre o minerador que responde e os validadores que ajudaram a verificar a resposta (a divisão exata poderia ser determinada pelo protocolo ou pelas forças de mercado). Além disso, os delegadores que fazem stake em mineradores/validadores são efetivamente parceiros – tipicamente, um minerador/validador partilhará uma percentagem do seu TAO ganho com os seus delegadores (isto é configurável, mas muitas vezes a maioria vai para os delegadores). Assim, se um minerador ganhasse 1 TAO de um bloco, isso poderia ser dividido 80/20 entre os seus delegadores e ele próprio, por exemplo, com base no stake. Isto significa que mesmo os não operadores recebem uma parte da receita da rede proporcional ao seu apoio. Com a introdução do dTAO, outra camada de partilha foi adicionada: aqueles que fazem stake no pool de uma sub-rede recebem tokens alfa, que lhes dão direito a algumas das emissões dessa sub-rede (como yield farming). Na prática, qualquer pessoa pode ter uma participação no sucesso de uma sub-rede específica e receber uma fração das recompensas de minerador/validador ao deter tokens alfa (os tokens alfa valorizam à medida que a sub-rede atrai mais uso e emissões). Em suma, a partilha de receitas do Bittensor é fixada por código para os papéis principais, e partilhada adicionalmente por arranjos sociais/de staking. É uma divisão relativamente transparente e baseada em regras – a cada bloco, os participantes sabem exatamente como o 1 TAO é alocado, e assim conhecem os seus “ganhos” por contribuição. Esta clareza é uma das razões pelas quais o Bittensor é por vezes comparado ao Bitcoin para IA – uma emissão monetária determinística onde a recompensa dos participantes é definida matematicamente.

• Gensyn: A partilha de receitas na Gensyn é mais dinâmica e impulsionada pelo mercado, uma vez que as tarefas são precificadas individualmente. Quando um submitter cria um trabalho, ele anexa uma recompensa (digamos, X tokens) que está disposto a pagar. Um solver que completa o trabalho recebe esse X (menos qualquer taxa de rede). Se um verifier estiver envolvido, tipicamente há uma regra como: se nenhuma fraude for detetada, o solver mantém o pagamento total; se a fraude for detetada, o solver é penalizado – perdendo parte ou todo o seu stake – e esse montante penalizado é dado ao verifier como recompensa. Portanto, os verificadores não ganham de todas as tarefas, apenas quando apanham um mau resultado (mais possivelmente uma pequena taxa base por participarem, dependendo da implementação). Não há um conceito integrado de pagar a um proprietário de modelo aqui, porque a suposição é que o submitter ou é o proprietário do modelo ou tem direitos para usá-lo. Poder-se-ia imaginar um cenário onde um submitter está a ajustar o modelo pré-treinado de outra pessoa e uma porção do pagamento vai para o criador original do modelo – mas isso teria de ser tratado fora do protocolo (por exemplo, por um acordo ou um contrato inteligente separado que divide o pagamento do token em conformidade). A partilha ao nível do protocolo da Gensyn é essencialmente cliente -> solver (-> verifier). O modelo de token provavelmente inclui alguma alocação para o tesouro ou fundação do protocolo; por exemplo, uma pequena percentagem do pagamento de cada tarefa pode ir para um tesouro que poderia ser usado para financiar o desenvolvimento ou pools de seguro (isto não é explicitamente declarado nos documentos disponíveis, mas muitos protocolos fazem-no). Além disso, no início, a Gensyn pode subsidiar os solvers através da inflação: os utilizadores da testnet têm prometidas recompensas no TGE, o que é efetivamente uma partilha de receitas da distribuição inicial de tokens (os primeiros solvers e apoiantes recebem uma parte dos tokens por ajudarem a iniciar, semelhante a um airdrop ou recompensa de mineração). Com o tempo, à medida que os trabalhos reais dominam, as recompensas inflacionárias diminuiriam, e o rendimento dos solvers viria principalmente dos pagamentos dos utilizadores. A abordagem da Gensyn pode ser resumida como um modelo de receita de taxa por serviço: a rede facilita um pagamento direto daqueles que precisam de trabalho feito para aqueles que fazem o trabalho, com os verificadores e possivelmente os stakers de tokens a receberem uma parte apenas quando desempenham um papel na segurança desse serviço.

• Cuckoo: A partilha de receitas da Cuckoo evoluiu. Inicialmente, como não havia muitos utilizadores finais pagantes, a partilha de receitas era essencialmente uma partilha de inflação: as alocações de 30% para mineração e 11% para staking da oferta de tokens significavam que os mineradores e stakers estavam a partilhar os tokens emitidos pelo pool de lançamento justo da rede. Na prática, a Cuckoo realizava coisas como pagamentos diários de CAI aos mineradores proporcionais às tarefas concluídas. Esses pagamentos vinham em grande parte da alocação de recompensa de mineração (que faz parte da oferta fixa reservada). Isto é semelhante a como muitas blockchains de Camada 1 distribuem recompensas de bloco aos mineradores/validadores – não estava ligado ao uso real por utilizadores externos, era mais para incentivar a participação e o crescimento. No entanto, como destacado no seu blog de julho de 2025, isto levou a um uso que era incentivado pela agricultura de tokens em vez de uma procura real. A próxima fase para a Cuckoo é um verdadeiro modelo de partilha de receitas baseado em taxas de serviço. Neste modelo, quando um utilizador final usa, digamos, o serviço de geração de imagens e paga $1 (em termos de cripto), esse $1 em tokens seria dividido talvez assim: 0,70 para o minerador que fez o trabalho de GPU, 0,20 para o desenvolvedor da aplicação (coordenador) que forneceu o modelo e a interface, e 0,10 para os stakers ou o tesouro da rede. (Nota: as proporções exatas são hipotéticas; a Cuckoo ainda não as especificou publicamente, mas isto ilustra o conceito.) Desta forma, todos os contribuidores para a entrega do serviço recebem uma parte da receita. Isto é análogo, por exemplo, a uma economia de partilha de viagens mas para IA: o veículo (minerador de GPU) recebe a maioria, o motorista ou plataforma (coordenador que construiu o serviço de modelo) recebe uma parte, e talvez a governança/stakers da plataforma recebam uma pequena taxa. A menção da Cuckoo a “modelos de partilha de receitas e recompensas de tokens diretamente ligadas a métricas de uso” sugere que se um serviço ou nó específico lidar com um grande volume, os seus operadores e apoiantes ganharão mais. Eles estão a afastar-se dos rendimentos fixos apenas por bloquear tokens (que era o caso com o seu APY de staking inicialmente). Em termos concretos: se você fizer stake num coordenador que acaba por alimentar uma aplicação de IA muito popular, poderá ganhar uma porção das taxas dessa aplicação – um verdadeiro cenário de staking como investimento em utilidade, em vez de staking apenas por inflação. Isto alinha os incentivos de todos para atrair utilizadores reais que pagam por serviços de IA, o que por sua vez devolve valor aos detentores de tokens. Vale a pena notar que a cadeia da Cuckoo também tinha taxas para transações (gás), então os mineradores que produziam blocos (inicialmente os mineradores de GPU também contribuíam para a produção de blocos na cadeia Cuckoo) também recebiam taxas de gás. Com o encerramento da cadeia e a migração para um rollup, as taxas de gás provavelmente serão mínimas (ou no Ethereum), então a principal receita torna-se as próprias taxas de serviço de IA. Em resumo, a Cuckoo está a transitar de um modelo impulsionado por subsídios (a rede paga aos participantes do seu pool de tokens) para um modelo impulsionado pela procura (os participantes ganham de pagamentos reais de utilizadores). O token ainda desempenhará um papel no staking e na governança, mas os ganhos diários dos mineradores e desenvolvedores de aplicações devem vir cada vez mais de utilizadores que compram serviços de IA. Este modelo é mais sustentável a longo prazo e espelha de perto a partilha de receitas SaaS da Web2, mas implementado através de contratos inteligentes e tokens para transparência.

Superfícies de Ataque e Vulnerabilidades​

A descentralização da IA introduz vários desafios de incentivo e segurança. Analisamos agora os principais vetores de ataque – ataques sybil, conluio, parasitismo e envenenamento de dados/modelos – e como cada plataforma os mitiga ou permanece vulnerável a eles:

• Ataques Sybil (identidades falsas): Numa rede aberta, um atacante pode criar muitas identidades (nós) para obter recompensas ou influência desproporcionais.

  • Bittensor: A resistência a ataques sybil é fornecida principalmente pelo custo de entrada. Para registar um novo minerador ou validador no Bittensor, é necessário gastar ou fazer stake de TAO – isto pode ser um requisito de queima ou de depósito. Isto significa que criar N nós falsos incorre em N vezes o custo, tornando grandes enxames sybil caros. Além disso, o consenso do Bittensor liga a influência ao stake e ao desempenho; um sybil sem stake ou com mau desempenho ganha pouco. Um atacante teria de investir pesadamente e também fazer com que os seus nós sybil contribuíssem com trabalho útil para obter qualquer recompensa significativa (o que não é uma estratégia sybil típica). Dito isto, se um atacante tiver muito capital, ele poderia adquirir a maioria do TAO e registar muitos validadores ou mineradores – efetivamente um sybil por riqueza. Isto sobrepõe-se ao cenário de ataque de 51%: se uma única entidade controlar >50% do TAO em stake numa sub-rede, eles podem influenciar fortemente o consenso. A introdução do dTAO pelo Bittensor ajuda um pouco aqui: espalha a influência por sub-redes e requer o apoio de staking da comunidade para que as sub-redes prosperem, tornando mais difícil para uma entidade controlar tudo. Ainda assim, ataques sybil por um adversário bem financiado continuam a ser uma preocupação – a análise do Arxiv nota explicitamente que o stake está bastante concentrado agora, então a barreira para um ataque de maioria não é tão alta quanto desejado. Para mitigar isto, foram sugeridas propostas como limites de stake por carteira (por exemplo, limitar o stake efetivo no 88º percentil para evitar que uma carteira domine). Em resumo, o Bittensor depende da identidade ponderada por stake (não se pode criar identidades baratas sem stake proporcional) para lidar com sybils; é razoavelmente eficaz, exceto sob um atacante muito engenhoso.
  • Gensyn: Ataques sybil na Gensyn manifestar-se-iam como um atacante a criar muitos nós solver ou verifier para manipular o sistema. A defesa da Gensyn é puramente económica e criptográfica – as identidades em si não importam, mas fazer trabalho ou colocar colateral sim. Se um atacante criar 100 nós solver falsos, mas eles não tiverem trabalhos ou stake, não conseguem nada. Para ganhar tarefas, um nó sybil teria de licitar competitivamente e ter o hardware para fazer o trabalho. Se eles licitarem abaixo do preço sem capacidade, falharão e perderão o stake. Da mesma forma, um atacante poderia criar muitas identidades de verificador na esperança de ser escolhido para verificar (se o protocolo selecionar verificadores aleatoriamente). Mas se houver muitos, a rede ou o publicador do trabalho pode limitar o número de verificadores ativos. Além disso, os verificadores precisam potencialmente de realizar a computação para verificá-la, o que é dispendioso; ter muitos verificadores falsos não ajuda, a menos que se possa realmente verificar os resultados. Um ângulo sybil mais pertinente na Gensyn é se um atacante tentar encher a rede com trabalhos ou respostas falsas para desperdiçar o tempo dos outros. Isso é mitigado exigindo também um depósito dos submitters (um submitter malicioso que publica trabalhos falsos perde o seu pagamento ou depósito). No geral, o uso de stakes/depósitos obrigatórios e a seleção aleatória para verificação pela Gensyn significa que um atacante ganha pouco ao ter múltiplas identidades, a menos que também traga recursos proporcionais. Torna-se um ataque mais caro em vez de um barato. O modelo de segurança otimista assume pelo menos um verificador honesto – os sybils teriam de sobrecarregar e ser todos os verificadores para trapacear consistentemente, o que novamente volta a possuir a maioria do stake ou do poder computacional. A resistência sybil da Gensyn é, portanto, comparável à de um rollup otimista: enquanto houver um ator honesto, os sybils não podem causar danos sistémicos facilmente.
  • Cuckoo: A prevenção de ataques sybil na Cuckoo depende do staking e da avaliação da comunidade. Cada papel na Cuckoo (minerador, coordenador, até mesmo utilizador em alguns casos) requer o staking de $CAI. Isto aumenta imediatamente o custo das identidades sybil – um atacante que crie 100 mineradores falsos precisaria de adquirir e bloquear stake para cada um. Além disso, o design da Cuckoo tem um elemento humano/comunitário: novos nós precisam de ganhar reputação através de votação on-chain. Um exército sybil de nós novos sem reputação é improvável que receba muitas tarefas ou a confiança dos utilizadores. Os coordenadores, em particular, têm de atrair utilizadores; um coordenador falso sem historial não obteria uso. Para os mineradores, os coordenadores podem ver as suas estatísticas de desempenho (tarefas bem-sucedidas, etc.) no Cuckoo Scan e preferirão mineradores fiáveis. A Cuckoo também tinha um número relativamente pequeno de mineradores (40 GPUs num ponto da beta), então qualquer influxo estranho de muitos nós seria notável. O ponto fraco potencial é se o atacante também explorar o sistema de reputação – por exemplo, eles fazem stake de muito CAI nos seus nós sybil para fazê-los parecer respeitáveis ou criam contas de “utilizador” falsas para se votarem a si mesmos. Isto é teoricamente possível, mas como tudo é curado por tokens, custa tokens fazê-lo (estaria essencialmente a votar com o seu próprio stake nos seus próprios nós). A equipa da Cuckoo também pode ajustar os parâmetros de staking e recompensa se for observado comportamento sybil (especialmente agora que se está a tornar um serviço de rollup mais centralizado; eles podem pausar ou penalizar maus atores). Em suma, os sybils são mantidos à distância ao exigir "pele em jogo" (stake) e precisar de aprovação da comunidade. Ninguém pode simplesmente entrar com centenas de GPUs falsas e colher recompensas sem um investimento significativo que os participantes honestos poderiam gastar melhor em hardware real e stake.

• Conluio: Aqui consideramos múltiplos participantes a conspirarem para manipular o sistema – por exemplo, validadores e mineradores em conluio no Bittensor, ou solvers e verifiers em conluio na Gensyn, etc.

  • Bittensor: O conluio foi identificado como uma preocupação real. No design original, um punhado de validadores poderia conspirar para sempre votar a favor de certos mineradores ou de si mesmos, distorcendo a distribuição de recompensas injustamente (isto foi observado como concentração de poder na sub-rede raiz). O consenso Yuma oferece alguma defesa: ao tomar uma mediana das pontuações dos validadores e penalizar aqueles que se desviam, impede que um pequeno grupo em conluio impulsione dramaticamente um alvo, a menos que sejam a maioria. Por outras palavras, se 3 de 10 validadores conspirarem para dar a um minerador uma pontuação super alta, mas os outros 7 não, as pontuações discrepantes dos conspiradores são cortadas e a recompensa do minerador é baseada na pontuação mediana (portanto, o conluio não ajuda significativamente). No entanto, se os conspiradores formarem >50% dos validadores (ou >50% do stake entre os validadores), eles efetivamente são o consenso – eles podem concordar em pontuações altas falsas e a mediana refletirá a sua visão. Este é o cenário clássico de ataque de 51%. Infelizmente, o estudo do Arxiv descobriu que algumas sub-redes do Bittensor, onde uma coligação de apenas 1-2% dos participantes (em termos de contagem) controlava a maioria do stake, devido à forte concentração de tokens. Isto significa que o conluio por alguns grandes detentores era uma ameaça credível. A mitigação que o Bittensor está a seguir através do dTAO é democratizar a influência: ao permitir que qualquer detentor de TAO direcione o stake para as sub-redes, dilui o poder de grupos fechados de validadores. Além disso, propostas como staking côncavo (retornos decrescentes para stake excessivo) e limites de stake visam quebrar a capacidade de uma entidade em conluio de acumular demasiado poder de voto. A suposição de segurança do Bittensor agora é semelhante à prova de participação: nenhuma entidade única (ou cartel) a controlar >50% do stake ativo. Enquanto isso se mantiver, o conluio é limitado porque os validadores honestos anularão as pontuações más e os proprietários de sub-redes em conluio não podem aumentar arbitrariamente as suas próprias recompensas. Finalmente, sobre o conluio entre proprietários de sub-redes e validadores (por exemplo, um proprietário de sub-rede a subornar validadores para classificarem bem os mineradores da sua sub-rede), o dTAO remove o controlo direto dos validadores, substituindo-o por decisões dos detentores de tokens. É mais difícil conspirar com “o mercado”, a menos que se compre a oferta de tokens – nesse caso, não é realmente conluio, é uma aquisição. Portanto, a principal técnica anti-conluio do Bittensor é o consenso algorítmico (corte da mediana) e a ampla distribuição de tokens.

  • Gensyn: O conluio na Gensyn provavelmente envolveria um solver e um verifier (ou múltiplos verifiers) a conspirarem para enganar o sistema. Por exemplo, um solver poderia produzir um resultado falso e um verifier em conluio poderia intencionalmente não o desafiar (ou até mesmo atestar que está correto se o protocolo pedisse aos verifiers para assinarem). Para mitigar isto, o modelo de segurança da Gensyn requer pelo menos um verifier honesto. Se todos os verifiers estiverem em conluio com o solver, então um resultado mau passa sem ser desafiado. A Gensyn aborda isto incentivando muitos verifiers independentes (qualquer um pode verificar) e pela teoria dos jogos de que um verifier poderia ganhar uma grande recompensa ao quebrar o conluio e desafiar (porque receberia o stake do solver). Essencialmente, mesmo que haja um grupo a concordar em conspirar, cada membro tem um incentivo para desertar e reivindicar a recompensa para si – esta é uma configuração clássica do Dilema do Prisioneiro. A esperança é que isso mantenha os grupos de conluio pequenos ou ineficazes. Outro conluio potencial é entre múltiplos solvers para aumentar os preços ou monopolizar tarefas. No entanto, como os desenvolvedores podem escolher onde publicar as tarefas (e as tarefas não são unidades idênticas que podem ser facilmente monopolizadas), o conluio de solvers no preço seria difícil de coordenar globalmente – qualquer solver que não estivesse em conluio poderia licitar mais baixo para ganhar o trabalho. A dinâmica de mercado aberto contraria o conluio de preços, assumindo pelo menos alguns participantes competitivos. Mais um ângulo: conluio de verifiers para prejudicar solvers – por exemplo, verifiers a acusarem falsamente solvers honestos para roubar o seu stake. A prova de fraude da Gensyn é binária e on-chain; uma acusação falsa falharia quando a recomputação on-chain não encontrasse erro, e presumivelmente o verifier malicioso perderia então algo (talvez um depósito ou reputação). Portanto, um conluio de verifiers a tentar sabotar solvers seria apanhado pelo processo de verificação do protocolo. Em resumo, a arquitetura da Gensyn é robusta enquanto pelo menos uma parte em qualquer conjunto em conluio tiver um incentivo para ser honesta – uma propriedade da verificação otimista semelhante a exigir um minerador honesto no Bitcoin para eventualmente expor uma fraude. O conluio é teoricamente possível se um atacante puder controlar todos os verifiers e solvers numa tarefa (como a maioria da rede), mas então eles poderiam simplesmente trapacear sem precisar de conluio per se. Os incentivos criptoeconómicos são organizados para tornar a sustentação do conluio irracional.

  • Cuckoo: O conluio na Cuckoo poderia acontecer de algumas maneiras:

    1. Um coordenador em conluio com mineradores – por exemplo, um coordenador poderia sempre atribuir tarefas a um conjunto de mineradores amigos e dividir as recompensas, ignorando outros mineradores honestos. Como os coordenadores têm discrição no agendamento de tarefas, isto pode acontecer. No entanto, se os mineradores amigos forem de qualidade inferior, os utilizadores finais podem notar um serviço lento ou mau e sair, então o coordenador é desincentivado de um favoritismo puro que prejudica a qualidade. Se o conluio for para manipular recompensas (digamos, submeter tarefas falsas para dar tokens aos mineradores), isso seria detetado on-chain (muitas tarefas com talvez entradas idênticas ou nenhum utilizador real) e pode ser penalizado. A transparência on-chain da Cuckoo significa que quaisquer padrões incomuns poderiam ser sinalizados pela comunidade ou pela equipa principal. Além disso, como todos os participantes fazem stake, um anel de coordenador-minerador em conluio corre o risco de perder o seu stake se for apanhado a abusar do sistema (por exemplo, se a governança decidir penalizá-los por fraude).
    2. Mineradores em conluio entre si – eles podem partilhar informações ou formar um cartel para, digamos, todos votarem uns nos outros na reputação ou todos se recusarem a servir um coordenador específico para extrair taxas mais altas. Estes cenários são menos prováveis: a votação de reputação é feita por stakers (incluindo utilizadores), não pelos próprios mineradores a votarem uns nos outros. E recusar serviço apenas levaria os coordenadores a encontrar outros mineradores ou a levantar alarmes. Dada a escala relativamente pequena atualmente, qualquer conluio seria difícil de esconder.
    3. Conluio para manipular a governança – grandes detentores de CAI poderiam conspirar para aprovar propostas a seu favor (como definir uma taxa exorbitante ou redirecionar o tesouro). Este é um risco em qualquer governança de tokens. A melhor mitigação é distribuir amplamente o token (o lançamento justo da Cuckoo deu 51% à comunidade) e ter uma supervisão comunitária ativa. Além disso, como a Cuckoo se afastou da L1, a governança on-chain imediata pode ser limitada até que se estabeleçam numa nova cadeia; a equipa provavelmente mantém um controlo multisig no entretanto, o que ironicamente impede o conluio por estranhos maliciosos à custa de ser temporariamente centralizado. No geral, a Cuckoo apoia-se na transparência e no staking para lidar com o conluio. Há um elemento de confiança nos coordenadores para se comportarem porque querem atrair utilizadores num ambiente competitivo. Se o conluio levar a um serviço de pior qualidade ou a uma manipulação óbvia de recompensas, os stakeholders podem votar para os remover ou parar de fazer stake em maus atores, e a rede pode penalizá-los ou bloqueá-los. A natureza razoavelmente aberta (qualquer um pode tornar-se um coordenador ou minerador se fizer stake) significa que o conluio exigiria um grande esforço coordenado que seria evidente. Não é tão matematicamente prevenido como no Bittensor ou na Gensyn, mas a combinação de stake económico e governança comunitária fornece um controlo.

• Parasitismo (Problemas de Free-rider): Refere-se a participantes que tentam colher recompensas sem contribuir com valor equivalente – por exemplo, um validador que não avalia realmente, mas ainda assim ganha, ou um minerador que copia as respostas de outros em vez de computar, ou utilizadores a cultivar recompensas sem fornecerem entradas úteis.

  • Bittensor: Um problema conhecido de free-rider no Bittensor é a “cópia de pesos” por validadores preguiçosos. Um validador poderia simplesmente copiar a opinião da maioria (ou as pontuações de outro validador) em vez de avaliar independentemente os mineradores. Ao fazer isso, eles evitam o custo de executar consultas de IA, mas ainda recebem recompensas se as suas pontuações submetidas parecerem alinhadas com o consenso. O Bittensor combate isto medindo o alinhamento de consenso e a contribuição informacional de cada validador. Se um validador sempre apenas copia os outros, ele pode alinhar-se bem (para não ser penalizado pesadamente), mas não adiciona valor único. Os desenvolvedores do protocolo discutiram dar recompensas mais altas a validadores que fornecem avaliações precisas, mas não puramente redundantes. Técnicas como a infusão de ruído (dar deliberadamente aos validadores consultas ligeiramente diferentes) poderiam forçá-los a trabalhar de verdade em vez de copiar – embora não esteja claro se isso está implementado. O Arxiv sugere emissão ponderada pelo desempenho e métodos de pontuação composta para ligar melhor o esforço do validador à recompensa. Quanto aos mineradores, um possível comportamento de free-rider seria se um minerador consultasse outros mineradores e retransmitisse a resposta (uma forma de plágio). O design do Bittensor (com consultas descentralizadas) pode permitir que o modelo de um minerador chame outros através do seu próprio dendrite. Se um minerador apenas retransmite a resposta de outro, um bom validador pode detetar isso porque a resposta pode não corresponder consistentemente às capacidades do modelo reivindicadas pelo minerador. É difícil de detetar algoritmicamente, mas um minerador que nunca computa resultados originais deve eventualmente pontuar mal em algumas consultas e perder reputação. Outro cenário de free-rider eram os delegadores a ganharem recompensas sem fazerem trabalho de IA. Isso é intencional (para envolver os detentores de tokens), então não é um ataque – mas significa que algumas emissões de tokens vão para pessoas que apenas fizeram stake. O Bittensor justifica isto como alinhamento de incentivos, não recompensas desperdiçadas. Em suma, o Bittensor reconhece o problema do free-rider do validador e está a ajustar os incentivos (como dar pontuações de confiança do validador que impulsionam aqueles que não se desviam ou copiam). A sua solução é essencialmente recompensar o esforço e a correção de forma mais explícita, para que não fazer nada ou copiar cegamente renda menos TAO ao longo do tempo.
  • Gensyn: Na Gensyn, os free-riders teriam dificuldade em ganhar, porque é preciso fornecer computação ou apanhar alguém a trapacear para obter tokens. Um solver não pode “fingir” trabalho – ele tem de submeter uma prova válida ou arriscar-se a ser penalizado. Não há mecanismo para ser pago sem fazer a tarefa. Um verifier poderia teoricamente ficar ocioso e esperar que outros apanhassem fraudes – mas então não ganha nada (porque apenas aquele que levanta a prova de fraude recebe a recompensa). Se demasiados verifiers tentarem ser free-riders (não recomputando realmente as tarefas), então um solver fraudulento pode passar despercebido porque ninguém está a verificar. O design de incentivos da Gensyn aborda isto com a recompensa jackpot: basta um verifier ativo para apanhar um trapaceiro e obter um grande pagamento, então é racional que pelo menos um faça sempre o trabalho. Outros que não fazem o trabalho não prejudicam a rede, exceto por serem inúteis; eles também não recebem recompensa. Assim, o sistema filtra naturalmente os free-riders: apenas os verifiers que realmente verificam terão lucro a longo prazo (outros gastam recursos em nós para nada ou muito raramente conseguem uma recompensa por acaso). O protocolo também pode randomizar qual verifier tem a oportunidade de desafiar para desencorajar todos os verifiers de assumirem que “alguém fará isso”. Como as tarefas são pagas individualmente, não há um análogo de “recompensas de staking sem trabalho”, além dos incentivos da testnet que são temporários. Uma área a observar é a otimização multitarefa: um solver pode tentar reutilizar o trabalho entre tarefas ou terceirizá-lo secretamente para alguém mais barato (como usar uma nuvem centralizada) – mas isso não é realmente um parasitismo prejudicial; se eles entregarem resultados corretos a tempo, não importa como o fizeram. Isso é mais como arbitragem do que um ataque. Em resumo, o design do mecanismo da Gensyn deixa pouco espaço para os free-riders ganharem, porque cada token distribuído corresponde a um trabalho feito ou a uma trapaça punida.
  • Cuckoo: A fase inicial da Cuckoo criou inadvertidamente um problema de free-rider: o airdrop e o staking de alto rendimento atraíram utilizadores que estavam lá apenas para cultivar tokens. Estes utilizadores circulavam tokens através de faucets ou manipulavam as tarefas do airdrop (por exemplo, usando continuamente prompts de teste gratuitos ou criando muitas contas para reivindicar recompensas) sem contribuírem para o valor da rede a longo prazo. A Cuckoo reconheceu isto como um problema – essencialmente, as pessoas estavam a “usar” a rede não pela saída de IA, mas pelo ganho de recompensa especulativa. A decisão de encerrar a cadeia L1 e reorientar foi em parte para se livrar destes desalinhamentos de incentivos. Ao ligar as futuras recompensas de tokens ao uso real (ou seja, você ganha porque o serviço está realmente a ser usado por clientes pagantes), o apelo do free-rider diminui. Há também um cenário de parasitismo do lado do minerador: um minerador poderia juntar-se, receber tarefas e de alguma forma não as executar, mas ainda assim reivindicar a recompensa. No entanto, o coordenador está a verificar os resultados – se um minerador não devolver nenhuma saída ou uma saída má, o coordenador não a contará como uma tarefa concluída, então o minerador não seria pago. Os mineradores também podem tentar escolher as tarefas fáceis e abandonar as difíceis (por exemplo, se alguns prompts forem mais lentos, um minerador pode desconectar-se para evitá-los). Isto poderia ser um problema, mas os coordenadores podem notar a fiabilidade de um minerador. Se um minerador abandona frequentemente, o coordenador pode parar de lhe atribuir tarefas ou penalizar o seu stake (se tal mecanismo existir ou simplesmente não o recompensar). Parasitismo do utilizador – como muitos serviços de IA têm testes gratuitos, um utilizador poderia enviar spam de pedidos para obter resultados sem pagar (se houver um modelo subsidiado). Isso não é tanto um problema ao nível do protocolo, mas sim ao nível do serviço; cada coordenador pode decidir como lidar com o uso gratuito (por exemplo, exigindo um pequeno pagamento ou limitando). Como a Cuckoo inicialmente ofereceu brindes (como gerações de imagens de IA gratuitas para atrair utilizadores), alguns aproveitaram-se, mas isso fazia parte do marketing de crescimento esperado. À medida que essas promoções terminam, os utilizadores terão de pagar, portanto, não há almoço grátis para explorar. No geral, a nova estratégia da Cuckoo de mapear a distribuição de tokens para a utilidade real visa explicitamente eliminar o problema do free-rider de “minerar tokens por fazer loops sem sentido”.

• Envenenamento de Dados ou Modelos: Refere-se à introdução maliciosa de dados ou comportamentos maus de modo que os modelos de IA se degradem ou os resultados sejam manipulados, bem como questões de conteúdo prejudicial ou tendencioso a ser contribuído.

  • Bittensor: O envenenamento de dados no Bittensor significaria um minerador a dar intencionalmente respostas incorretas ou prejudiciais, ou validadores a avaliar propositadamente respostas boas como más. Se um minerador produzir lixo ou conteúdo malicioso consistentemente, os validadores darão pontuações baixas, e esse minerador ganhará pouco e eventualmente sairá – o incentivo económico é fornecer qualidade, então “envenenar” os outros não traz benefício para o atacante (a menos que o seu objetivo seja puramente sabotagem às suas próprias custas). Poderia um minerador malicioso envenenar outros? No Bittensor, os mineradores não se treinam diretamente uns aos outros (pelo menos não por design – não há um modelo global a ser atualizado que possa ser envenenado). O modelo de cada minerador é separado. Eles aprendem no sentido de que um minerador poderia pegar amostras interessantes de outros para se ajustar, mas isso é totalmente opcional e depende de cada um. Se um ator malicioso enviasse spam de respostas sem sentido, os validadores honestos filtrariam isso (eles pontuariam baixo), então não influenciaria significativamente o processo de treinamento de nenhum minerador honesto (além disso, um minerador provavelmente usaria o conhecimento de pares com alta pontuação, não de baixa pontuação). Portanto, o envenenamento de dados clássico (injetar dados de treinamento maus para corromper um modelo) é mínimo na configuração atual do Bittensor. O risco mais relevante é a manipulação da resposta do modelo: por exemplo, um minerador que produz conteúdo subtilmente tendencioso ou perigoso que não é óbvio para os validadores. No entanto, como os validadores também são projetados por humanos ou pelo menos agentes algorítmicos, a toxicidade ou erro flagrante é provavelmente detetado (algumas sub-redes podem até ter validadores de IA a verificar conteúdo inseguro). Um cenário de pior caso é se um atacante de alguma forma tivesse a maioria dos validadores e mineradores em conluio para empurrar uma certa saída incorreta como “correta” – eles poderiam então enviesar o consenso da rede sobre as respostas (como todos os validadores em conluio a votarem a favor de uma resposta maliciosa). Mas para um utilizador externo ser prejudicado por isso, ele teria de realmente consultar a rede e confiar na saída. O Bittensor ainda está numa fase em que está a construir capacidade, não sendo amplamente usado para consultas críticas por utilizadores finais. Quando o for, espera-se que tenha filtragem de conteúdo e diversidade de validadores para mitigar tais riscos. Do lado do validador, um validador malicioso poderia fornecer avaliações envenenadas – por exemplo, consistentemente votar contra um certo minerador honesto para eliminar a concorrência. Com stake suficiente, eles podem conseguir empurrar esse minerador para fora (se as recompensas do minerador caírem tanto que ele saia). Este é um ataque ao mecanismo de incentivo. Novamente, se eles não forem a maioria, o corte da mediana frustrará um validador discrepante. Se eles forem a maioria, funde-se com o cenário de conluio/51% – qualquer maioria pode reescrever as regras. A solução volta à descentralização: impedir que qualquer entidade domine. Em resumo, o design do Bittensor inerentemente penaliza contribuições de dados/modelos envenenados através do seu sistema de pontuação – contribuições más recebem baixo peso e, portanto, baixa recompensa. Não há um repositório de modelos permanente para envenenar; tudo é dinâmico e continuamente avaliado. Isto proporciona resiliência: a rede pode gradualmente “esquecer” ou ignorar maus atores à medida que as suas contribuições são filtradas pelos validadores.
  • Gensyn: Se um solver quisesse envenenar um modelo a ser treinado (como introduzir uma backdoor ou viés durante o treinamento), ele poderia tentar fazê-lo secretamente. O protocolo Gensyn verificaria se o treinamento prosseguiu de acordo com o algoritmo especificado (passos de descida de gradiente estocástico, etc.), mas não detetaria necessariamente se o solver introduziu um gatilho de backdoor subtil que não aparece nas métricas de validação normais. Este é um problema mais insidioso – não é uma falha da computação, é uma manipulação dentro dos graus de liberdade permitidos do treinamento (como ajustar os pesos para uma frase gatilho). Detetar isso é um problema de pesquisa ativo em segurança de ML. A Gensyn não tem um mecanismo especial para envenenamento de modelos além do facto de que o submitter poderia avaliar o modelo final num conjunto de teste à sua escolha. Um submitter experiente deve sempre testar o modelo devolvido; se descobrir que ele falha em algumas entradas ou tem um comportamento estranho, pode disputar o resultado ou recusar o pagamento. Talvez o protocolo pudesse permitir que um submitter especificasse certos critérios de aceitação (como “o modelo deve atingir pelo menos X de precisão neste conjunto de teste secreto”) e se o resultado do solver falhar, o solver não é pago na totalidade. Isto dissuadiria o envenenamento porque o atacante não cumpriria os critérios de avaliação. No entanto, se o veneno não impactar a precisão em testes normais, poderia passar despercebido. Os verifiers na Gensyn apenas verificam a integridade da computação, não a qualidade do modelo, então não detetariam overfitting intencional ou trojans, desde que os registos de treinamento pareçam válidos. Portanto, isto permanece uma questão de confiança ao nível da tarefa: o submitter tem de confiar que o solver não envenenará o modelo ou usar métodos como ensembling de múltiplos resultados de treinamento de diferentes solvers para diluir a influência de qualquer solver único. Outro ângulo é o envenenamento de dados: se o submitter fornecer dados de treinamento, um solver malicioso poderia ignorar esses dados e treinar em outra coisa ou adicionar dados lixo. Mas isso provavelmente reduziria a precisão, o que o submitter notaria no desempenho do modelo de saída. O solver então não receberia o pagamento total (já que presumivelmente eles querem atingir uma meta de desempenho). Portanto, o envenenamento que degrada o desempenho é autodestrutivo para a recompensa do solver. Apenas um veneno que é neutro em desempenho, mas malicioso (uma backdoor) é um perigo real, e isso está fora do âmbito da verificação típica de blockchain – é um desafio de segurança de machine learning. A melhor mitigação da Gensyn é provavelmente social: usar modelos conhecidos e respeitáveis, ter várias execuções de treinamento, usar ferramentas de código aberto. Em tarefas de inferência (se a Gensyn também for usada para trabalhos de inferência), um solver em conluio poderia retornar saídas incorretas que enviesam uma certa resposta. Mas os verifiers detetariam saídas erradas se executassem o mesmo modelo, então isso é menos um envenenamento e mais apenas trapaça, que as provas de fraude abordam. Em suma, a Gensyn protege o processo, não a intenção. Garante que o treinamento/inferência foi feito corretamente, mas não que o resultado é bom ou livre de malícias ocultas. Isso permanece um problema em aberto, e o whitepaper da Gensyn provavelmente não o resolve totalmente ainda (poucos o fazem).
  • Cuckoo: Como a Cuckoo atualmente se foca na inferência (servindo modelos existentes), o risco de envenenamento de dados/modelos é relativamente limitado à manipulação de saída ou envenenamento de conteúdo. Um minerador malicioso pode tentar adulterar o modelo que lhe é dado para executar – por exemplo, se for fornecido um checkpoint do Stable Diffusion, ele poderia trocá-lo por um modelo diferente que talvez insira alguma marca d'água subtil ou anúncio em cada imagem. No entanto, o coordenador (que é o proprietário do modelo) normalmente envia tarefas com uma expectativa do formato de saída; se um minerador retornar saídas fora da especificação consistentemente, o coordenador sinalizará e banirá esse minerador. Além disso, os mineradores não podem modificar facilmente um modelo sem afetar notavelmente as suas saídas. Outro cenário é se a Cuckoo introduzir modelos treinados pela comunidade: então os mineradores ou fornecedores de dados podem tentar envenenar os dados de treinamento (por exemplo, alimentar muitos rótulos errados ou texto tendencioso). A Cuckoo precisaria de implementar a validação de dados de crowdsourcing ou a ponderação de contribuidores. Isto ainda não é uma funcionalidade, mas o interesse da equipa em IA personalizada (como a menção a um coach de vida de IA ou aplicações de aprendizagem) significa que eles podem eventualmente lidar com dados de treinamento fornecidos pelo utilizador, o que exigirá verificações cuidadosas. Sobre a segurança do conteúdo, como os mineradores da Cuckoo realizam inferência, pode-se preocupar com eles a produzirem conteúdo prejudicial, mesmo que o modelo normalmente não o fizesse. Mas os mineradores não têm incentivo para alterar as saídas arbitrariamente – eles são pagos pela computação correta, não pela criatividade. Se alguma coisa, um minerador malicioso pode saltar a computação completa para economizar tempo (por exemplo, retornar uma imagem desfocada ou uma resposta genérica). O coordenador ou o utilizador veria isso e classificaria mal esse minerador (e provavelmente não pagaria por essa tarefa). A privacidade é outra faceta: um minerador malicioso pode vazar ou registar dados do utilizador (como se um utilizador inserisse texto ou imagens sensíveis). Isto não é envenenamento, mas é um ataque à confidencialidade. A postura de privacidade da Cuckoo é que está a explorar métodos de preservação da privacidade (a menção a uma VPN que preserva a privacidade no ecossistema sugere um foco futuro). Eles poderiam incorporar técnicas como enclaves seguros ou inferência dividida para manter os dados privados dos mineradores. Ainda não implementado, mas uma consideração conhecida. Finalmente, o blog da Cuckoo enfatiza a verificação eficaz das saídas do modelo e a garantia de uma operação de modelo descentralizada segura como chave para tornar a tokenização de modelos viável. Isto indica que eles estão cientes de que para descentralizar verdadeiramente a IA, é preciso proteger-se contra coisas como saídas envenenadas ou modelos com mau funcionamento. Possivelmente, eles pretendem usar uma combinação de incentivos criptoeconómicos (penalização de stake para maus atores) e sistemas de classificação de utilizadores (os utilizadores podem sinalizar saídas más, e esses mineradores perdem reputação). O sistema de reputação pode ajudar aqui: se um minerador retornar mesmo um resultado obviamente malicioso ou incorreto, os utilizadores/coordenadores podem votar negativamente, impactando fortemente a sua capacidade de ganho futuro. Sabendo disso, os mineradores são incentivados a serem consistentemente corretos e a não introduzirem nenhum veneno. Em essência, a Cuckoo confia, mas verifica: é mais tradicional no sentido de que se alguém se comportar mal, você identifica e remove-o (com a perda de stake como punição). Ainda não tem defesas especializadas para envenenamento subtil de modelos, mas a estrutura de ter proprietários de aplicações específicos (coordenadores) no comando adiciona uma camada de supervisão – esses proprietários serão motivados a garantir que nada comprometa a integridade do seu modelo, pois a sua própria receita e reputação dependem disso.

Em conclusão, embora as redes de IA descentralizadas introduzam novas superfícies de ataque, elas também implementam uma mistura de defesas criptográficas, de teoria dos jogos e de governança comunitária: A resistência a ataques sybil é em grande parte tratada pela exigência de stake económico para participação. A resistência ao conluio vem do alinhamento de incentivos (o comportamento honesto é mais lucrativo) e de mecanismos de consenso que limitam o impacto de pequenos grupos em conluio. A prevenção de free-riders é alcançada ao ligar estreitamente as recompensas ao trabalho útil real e penalizar ou eliminar aqueles que não contribuem com nada. O envenenamento e ataques relacionados continuam a ser desafiadores, mas os sistemas mitigam os casos flagrantes através de avaliação contínua e da capacidade de penalizar ou ejetar atores maliciosos. Estas plataformas estão ativamente a pesquisar e a iterar nestes designs – como evidenciado pelos ajustes contínuos do Bittensor ao Yuma e ao dTAO, e pela mudança na tokenomics da Cuckoo – para garantir um ecossistema de IA descentralizado, seguro e autossustentável.

Avaliação Comparativa​

Para destacar as diferenças e semelhanças entre Bittensor, Gensyn e Cuckoo AI, a tabela seguinte fornece uma comparação lado a lado através de dimensões-chave:

Tabela: Comparação de funcionalidades de Bittensor, Gensyn e Cuckoo AI em arquitetura, foco, papéis, consenso, tokens, tokenização de ativos, governança, incentivos e segurança.

O Valor Máximo Extraível (MEV) refere-se ao lucro que um "insider" da blockchain (minerador/validador ou outro ator privilegiado) pode obter ao reordenar, incluir ou excluir transações arbitrariamente em um bloco. A extração de MEV não controlada pode levar a uma ordenação injusta de transações, taxas elevadas (devido a leilões de gás prioritário) e centralização de poder na produção de blocos. Vários protocolos surgiram para suprimir o MEV prejudicial ou impor uma ordenação justa de transações. Este relatório compara quatro abordagens proeminentes: Flashbots v2 (o sistema MEV-Boost da Flashbots pós-Merge para Ethereum), SUAVE (o futuro Single Unifying Auction for Value Expression da Flashbots), Anoma (uma arquitetura centrada em intenções que reimagina como as transações são combinadas e ordenadas) e Skip Protocol (um kit de ferramentas baseado no Cosmos para gestão soberana de MEV no protocolo). Examinamos cada um em termos de seus algoritmos de enfileiramento/ordenação de transações, mecanismos de mitigação ou extração de MEV, modelos de incentivo, características de conformidade e neutralidade, arquitetura técnica (consenso e criptografia) e progresso de desenvolvimento. Resumos estruturados e uma tabela de comparação são fornecidos para destacar seus pontos fortes e trade-offs na busca pela justiça e na redução das externalidades negativas do MEV.

Flashbots v2 (MEV-Boost & BuilderNet no Ethereum)​

O Flashbots v2 denota o ecossistema atual da Flashbots no Ethereum pós-Proof-of-Stake, centrado no MEV-Boost e em iniciativas recentes como o BuilderNet. O Flashbots v2 baseia-se no paradigma de separação proponente/construtor (PBS) para abrir a construção de blocos a um mercado competitivo de construtores, protegendo ao mesmo tempo os utilizadores do Ethereum de ataques de MEV no mempool público.

• Ordenação de Transações (Enfileiramento e Algoritmo): O MEV-Boost da Flashbots introduz um mercado de construção de blocos off-chain. Os validadores (proponentes) terceirizam a construção de blocos para construtores especializados através de um relay, em vez de ordenarem as transações localmente. Vários construtores competem para fornecer o bloco com o maior pagamento, e o validador assina cegamente o cabeçalho do bloco com a oferta mais alta (uma abordagem PBS). Este design substitui efetivamente a ordenação de primeiro a chegar, primeiro a ser servido do mempool público por um leilão de lances selados para blocos inteiros. Os construtores determinam a ordenação das transações internamente para maximizar os pagamentos totais (incluindo oportunidades de MEV), geralmente preferindo bundles com arbitragens ou liquidações lucrativas no topo do bloco. Ao usar o MEV-Boost, o Ethereum evitou os caóticos leilões de gás prioritário (PGAs) que anteriormente determinavam a ordenação; em vez de utilizadores e bots licitarem através de taxas de gás em tempo real (aumentando o congestionamento), o MEV-Boost centraliza a ordenação por bloco para o construtor mais competitivo. As filas de transações são, portanto, geridas privadamente por construtores, que podem ver os bundles ou transações recebidas e organizá-las para um lucro ótimo. Uma desvantagem é que esta ordenação orientada pelo lucro não impõe inerentemente "justiça" para os utilizadores – por exemplo, os construtores ainda podem incluir fluxos de ordens tóxicos como ataques sanduíche se forem lucrativos – mas otimiza a eficiência ao extrair MEV através de um leilão controlado em vez de guerras de gás ad-hoc. Desenvolvimentos recentes visaram tornar a ordenação mais neutra: por exemplo, o novo BuilderNet da Flashbots (lançado no final de 2024) permite que vários construtores colaboradores partilhem o fluxo de ordens e construam blocos coletivamente num Ambiente de Execução Confiável, introduzindo regras de ordenação verificáveis para melhorar a justiça. Isto afasta a ordenação de blocos de um único construtor centralizado para uma rede descentralizada de construção de blocos com regras que podem ser auditadas quanto à neutralidade.

• Mecanismos de Supressão vs. Extração de MEV: O Flashbots v2 facilita principalmente a extração de MEV de uma forma mais benigna em vez de a eliminar. O sistema original da Flashbots (v1) em 2021 permitia que os searchers enviassem bundles (conjuntos de transações preferenciais) diretamente aos mineradores, o que suprimia externalidades prejudiciais (sem front-running público, sem transações falhadas devido a corridas) enquanto ainda extraía MEV. Na era do MEV-Boost, o MEV é extraído por construtores que agrupam transações lucrativas, mas a competição de soma negativa é reduzida: os searchers já não enviam spam para o mempool com transações concorrentes e taxas de gás exorbitantes, o que mitiga o congestionamento da rede e as taxas excessivas para os utilizadores. O Flashbots v2 também fornece ferramentas de mitigação de MEV para os utilizadores: por exemplo, o Flashbots Protect RPC permite que os utilizadores submetam transações privadamente a um relay, impedindo o front-running no mempool público (ninguém pode ver ou reordenar a transação antes da inclusão). Outra iniciativa, o MEV-Share, permite que os utilizadores partilhem apenas informação suficiente sobre as suas transações para atrair lances de MEV, capturando uma parte do valor para si próprios. No entanto, o Flashbots v2 não "impede" MEV como sanduíches ou arbitragem – canaliza estas atividades através de um leilão eficiente que, argumentavelmente, democratiza quem pode extrair o MEV. Recentemente, o design do BuilderNet tem o objetivo explícito de “neutralizar jogos de fluxo de ordens de soma negativa” e partilhar o MEV de volta com a comunidade através de regras de reembolso on-chain. O BuilderNet calcula reembolsos pagos aos fornecedores de fluxo de ordens de transações (como carteiras ou DApps) proporcionais ao MEV que as suas transações geraram, redistribuindo valor que de outra forma seria lucro puro para os construtores. Em resumo, o Flashbots v2 maximiza a eficiência da extração de MEV (garantindo que quase todo o valor extraível num bloco é efetivamente capturado) enquanto introduz medidas para conter as piores externalidades e devolver algum valor aos utilizadores. Fica aquém de impor uma ordenação justa (as transações ainda são ordenadas pelo lucro do construtor), mas através da submissão privada, construção multipartidária e reembolsos, suprime o dano negativo ao utilizador (como a derrapagem por front-running e efeitos de censura) tanto quanto possível dentro do modelo de leilão.

• Estrutura de Incentivo Económico: O Flashbots v2 alinha os incentivos entre validadores, construtores e searchers através do leilão PBS. Os Validadores beneficiam ao terceirizar a produção de blocos – eles simplesmente aceitam o lance mais alto e recebem o valor do lance (além das recompensas de consenso), o que aumentou drasticamente a parte do MEV que vai para os validadores em comparação com a era em que os mineradores não tinham tais leilões. Os construtores são incentivados a competir entre si, encontrando a ordenação mais lucrativa de transações (muitas vezes incorporando estratégias de searchers), e mantêm qualquer lucro de MEV restante após pagar o lance do validador. Na prática, a competição força os construtores a pagar a maior parte do MEV aos validadores (muitas vezes >90% do lucro), mantendo apenas uma margem fina. Os Searchers (agora interagindo com os construtores através de bundles ou transações diretas) ainda ganham ao descobrir oportunidades de MEV (arbitragem, liquidação, etc.), mas devem licitar a maior parte do seu lucro para ganhar a inclusão – efetivamente, os lucros dos searchers são transferidos para os validadores através dos lances dos construtores. Este equilíbrio competitivo maximiza a receita total da rede (beneficiando validadores/stakers) mas aperta as margens individuais dos searchers. O Flashbots v2, assim, desencoraja acordos exclusivos: qualquer searcher ou construtor com uma estratégia de MEV privada é incentivado a licitá-la através do relay aberto para evitar ser superado, levando a um mercado mais aberto. A introdução do BuilderNet adiciona um incentivo para os originadores de fluxo de ordens (como DEXs ou carteiras) – ao dar-lhes reembolsos pelo MEV que as suas transações criam, incentiva os utilizadores e as aplicações a enviar o fluxo de ordens para o ecossistema BuilderNet. Este mecanismo alinha os utilizadores com o sistema: em vez de serem adversários (utilizadores vs. extratores de MEV), os utilizadores partilham do MEV, pelo que estão mais dispostos a participar no leilão de forma justa. No geral, a economia do Flashbots v2 favorece a colaboração em detrimento da competição na construção de blocos: os validadores obtêm a receita máxima sem risco, os construtores competem na qualidade da execução, e os searchers inovam para encontrar MEV mas abdicam da maioria dos lucros para ganhar lances, enquanto os utilizadores ganham proteção e possivelmente reembolsos.

• Conformidade e Resistência à Censura: A conformidade regulatória tornou-se uma questão controversa para a Flashbots após o Merge do Ethereum. O relay padrão da Flashbots implementou inicialmente a conformidade com as sanções da OFAC (censurando certas transações como as do Tornado Cash) – levando a que ~80% dos blocos do Ethereum no final de 2022 fossem "conformes com a OFAC" e levantando preocupações de centralização/censura na comunidade. O Flashbots v2 abordou isto fomentando um ecossistema multi-relay onde os validadores podem escolher relays não censores (por exemplo, UltraSound, Agnostic) ou até mesmo executar os seus próprios. A Flashbots tornou o seu código de relay de código aberto em meados de 2022 para encorajar a competição global de relays e a transparência. Adicionalmente, o MEV-Boost v1.4 introduziu funcionalidades como uma configuração de lance mínimo para que os proponentes pudessem rejeitar lances baixos de construtores censores e recorrer a blocos locais, trocando algum lucro pela inclusão de todas as transações. Esta funcionalidade deu explicitamente aos validadores uma forma de melhorar a resistência à censura do Ethereum a um pequeno custo. No final de 2024, a Flashbots deu um passo adiante ao descontinuar o seu próprio construtor centralizado em favor do BuilderNet – uma rede colaborativa destinada a ser “incensurável e neutra”. O BuilderNet usa TEEs (Intel SGX) para manter o fluxo de ordens de transações encriptado e compromete-se verificavelmente com uma regra de ordenação, o que pode ajudar a impedir que construtores individuais censurem transações específicas. Com múltiplos participantes a construir blocos conjuntamente dentro de enclaves seguros, nenhuma parte única pode facilmente excluir uma transação sem ser detetada. Em suma, o Flashbots v2 evoluiu de um relay único (e inicialmente censor) para uma infraestrutura mais descentralizada com participação aberta e objetivos explícitos de neutralidade. A conformidade é deixada para as políticas individuais de relays/construtores (e os validadores podem escolher), em vez de ser imposta pelo protocolo. A trajetória é em direção à neutralidade credível: eliminar quaisquer pontos de estrangulamento controlados pela Flashbots que possam ser pressionados por reguladores. A Flashbots comprometeu-se publicamente a remover-se como operador central e a descentralizar todos os aspetos da cadeia de fornecimento de MEV a longo prazo.

• Arquitetura Técnica e Criptografia: O Flashbots v2 opera de forma híbrida, off-chain e no protocolo. O leilão principal (MEV-Boost) acontece off-chain através da rede de construtores e relays, mas liga-se diretamente ao consenso do Ethereum: os validadores executam um cliente sidecar (mev-boost) que interage com os relays usando a API de Construtor padronizada. Em termos de consenso, o Ethereum ainda usa o PoS padrão (Casper/Hotstuff) – o MEV-Boost não altera as regras de consenso da L1; apenas muda quem monta o bloco. Inicialmente, o leilão da Flashbots exigia confiar que o relay e o construtor não roubariam transações ou censurariam – não havia garantias criptográficas (o sistema dependia do incentivo económico de que os construtores devem entregar uma carga útil válida correspondente ao seu lance ou perdem o slot). Com o tempo, o Flashbots v2 integrou mais tecnologia de segurança. A introdução de Ambientes de Execução Confiáveis (TEE) através do BuilderNet é uma mudança arquitetónica notável: os construtores executam dentro de enclaves SGX para que mesmo o operador do construtor não possa ver o fluxo de ordens de transações bruto (impedindo-os de o vazar ou fazer front-running). Estes enclaves seguem coletivamente um protocolo para produzir blocos, o que pode permitir uma justiça verificável (por exemplo, provar que as transações foram ordenadas por uma regra comprometida ou que nenhuma entidade não autorizada as viu antes da inclusão). Embora o SGX seja usado (uma abordagem baseada em hardware), a pesquisa da Flashbots também está a explorar primitivas criptográficas puras – por exemplo, criptografia de limiar para privacidade do mempool e computação segura multipartidária – para eventualmente substituir ou complementar os TEEs e reduzir ainda mais a confiança. A pilha de software do Flashbots v2 inclui clientes personalizados como o MEV-geth (agora obsoleto) e construtores baseados em Rust (por exemplo, rbuilder), e adere às especificações de construtor do Ethereum para interoperabilidade. Em resumo, a arquitetura é modular: uma rede de relays, construtores e agora enclaves, situada entre os utilizadores e os proponentes do Ethereum. Prioriza o desempenho (licitação rápida, entrega de blocos) e está gradualmente a adicionar garantias criptográficas de privacidade e ordenação justa. Nenhum novo algoritmo de consenso é introduzido; em vez disso, o Flashbots v2 funciona ao lado do consenso do Ethereum, evoluindo o pipeline de produção de blocos em vez das regras de consenso.

• Roteiro de Desenvolvimento e Marcos: A Flashbots progrediu através de fases iterativas. O Flashbots v1 (2020–2021) envolveu o lançamento do MEV-geth e os primeiros leilões de bundles off-chain com mineradores. Em meados de 2021, mais de 80% do hashrate do Ethereum estava a executar o MEV-geth da Flashbots, confirmando a adoção da abordagem. O Flashbots v2 (2022) foi concebido antes do The Merge: em novembro de 2021, a Flashbots publicou a arquitetura MEV-Boost para o Ethereum PoS. Depois que o Ethereum mudou para PoS (15 de setembro de 2022), o MEV-Boost foi ativado em poucos dias e rapidamente alcançou a adesão da maioria dos validadores. Marcos subsequentes incluíram a abertura do código do relay (agosto de 2022) e do construtor de blocos interno da Flashbots (novembro de 2022) para estimular a competição. No final de 2022, a Flashbots também adicionou funcionalidades focadas na resistência à censura e resiliência (por exemplo, lance mínimo para proponentes) e escreveu sobre o “Custo da Resiliência” para encorajar os validadores a preferirem por vezes a inclusão ao lucro. Ao longo de 2023, melhorar a descentralização dos construtores tornou-se um foco principal: a Flashbots lançou o “rbuilder” (um construtor de alto desempenho em Rust) em julho de 2024 como uma implementação de referência para diminuir a barreira para novos construtores. Finalmente, no final de 2024, a Flashbots lançou o BuilderNet (alfa) em colaboração com parceiros (Beaverbuild, Nethermind). Em dezembro de 2024, a Flashbots encerrou o seu construtor centralizado e migrou todo o fluxo de ordens para o BuilderNet – um passo significativo em direção à descentralização. No início de 2025, o BuilderNet v1.2 foi lançado com melhorias de segurança e onboarding (incluindo builds de enclave reproduzíveis). Estes marcos marcam a transição da Flashbots de uma solução centralizada expedita para um protocolo mais aberto e gerido pela comunidade. Olhando para o futuro, a Flashbots está a convergir com a sua visão de próxima geração (SUAVE) para descentralizar totalmente a camada de construção de blocos e incorporar tecnologia de privacidade avançada. Muitas lições do Flashbots v2 (por exemplo, a necessidade de neutralidade, âmbito multi-chain e inclusão do utilizador nas recompensas de MEV) informam diretamente o roteiro do SUAVE.

SUAVE (Single Unifying Auction for Value Expression da Flashbots)​

SUAVE é o ambicioso protocolo de próxima etapa da Flashbots, projetado como um mercado de MEV descentralizado e interdomínio e uma camada de sequenciamento justo de transações. O seu objetivo é desagregar os mempools e a construção de blocos das blockchains individuais e fornecer uma plataforma unificada onde os utilizadores expressam preferências, uma rede descentralizada executa transações de forma ótima, e os construtores de blocos produzem blocos em muitas chains de uma forma credivelmente neutra. Em suma, o SUAVE procura maximizar a extração total de valor, devolvendo ao mesmo tempo valor aos utilizadores e preservando a descentralização da blockchain. A Flashbots introduziu o SUAVE no final de 2022 como "o futuro do MEV" e tem vindo a desenvolvê-lo abertamente desde então.

• Enfileiramento e Ordenação de Transações: De uma perspetiva geral, o SUAVE funciona como uma rede de blockchain independente que outras chains podem usar como um mempool e construtor de blocos plug-and-play. Em vez de as transações serem enfileiradas no mempool de cada chain e ordenadas por mineradores ou validadores locais, os utilizadores podem enviar as suas transações (ou, mais genericamente, preferências) para o mempool da rede SUAVE. O mempool do SUAVE serve então como um pool de leilão global de preferências de todas as chains participantes. A ordenação das transações é determinada através deste leilão e da subsequente otimização da execução. Especificamente, o SUAVE introduz um conceito de preferências: a submissão de um utilizador não é apenas uma transação bruta para uma chain, mas pode codificar um objetivo ou uma troca condicional (possivelmente abrangendo várias chains) e um lance associado que o utilizador está disposto a pagar pela sua realização. O algoritmo de ordenação/enfileiramento no SUAVE tem várias etapas: Primeiro, os utilizadores publicam as suas preferências no mempool do SUAVE (o “Ambiente Universal de Preferências”), que agrega todas as ordens de forma privada e global. Em seguida, nós especializados chamados executores (análogos a searchers/solvers) monitorizam este mempool e competem num Mercado de Execução Ótima para satisfazer estas preferências. Eles efetivamente "enfileiram" transações ao encontrar correspondências ou uma ordenação de execução ótima para elas. Finalmente, o SUAVE produz saídas de bloco para cada chain conectada através de uma camada de Construção de Blocos Descentralizada: muitos construtores (ou executores do SUAVE a atuar como construtores) colaboram para construir blocos usando a ordem de transações (agora otimizada) derivada das preferências dos utilizadores. Em termos práticos, a ordenação do SUAVE é flexível e orientada pelo utilizador: um utilizador pode especificar condições como "executar a minha troca apenas se o preço < X" ou mesmo expressar uma intenção abstrata ("trocar o token A por B à melhor taxa dentro de 1 minuto") em vez de uma transação estrita. O sistema enfileira estas intenções até que um executor encontre uma ordenação ou correspondência ótima (possivelmente agrupando com outras). Como o SUAVE é agnóstico em relação à blockchain, pode coordenar a ordenação entre chains (impedindo cenários em que arbitragens entre chains são perdidas devido a mempools separados e não coordenados). Essencialmente, o SUAVE implementa um leilão global de MEV: todos os participantes partilham uma camada de sequenciamento, que ordena as transações com base em preferências e lances agregados em vez de simples tempo ou preço do gás. Isto tem o efeito de nivelar o campo de jogo – todo o fluxo de ordens passa por uma única fila transparente (embora encriptada para privacidade, como discutido abaixo) em vez de acordos exclusivos ou mempools privados. O algoritmo de ordenação do SUAVE ainda está a ser refinado, mas provavelmente envolverá leilões em lote com preservação de privacidade e algoritmos de correspondência para que resultados "justos" (como excedente total máximo ou preços ótimos para o utilizador) possam ser alcançados em vez de puro primeiro a chegar, primeiro a ser servido. Notavelmente, o SUAVE pretende impedir que qualquer ator único manipule a ordenação: é nativo do Ethereum e consciente do MEV, com um mempool encriptado que prioriza a privacidade e protege contra quaisquer pontos centrais de controlo. Em resumo, a fila do SUAVE é um pool de fluxo de ordens unificado onde a ordenação é determinada por uma combinação de lances de utilizadores, estratégia de executores e (eventualmente) restrições de justiça criptográficas, em vez de proponentes de blocos a correr por prioridade.

• Mecanismos de Supressão/Extração de MEV: A filosofia do SUAVE é que o MEV pode ser aproveitado em benefício dos utilizadores e para a segurança da rede se for feito de maneira cooperativa e descentralizada. Em vez de ignorar o MEV ou deixá-lo concentrar-se em poucas mãos, o SUAVE explicitamente revela oportunidades de MEV e devolve o valor a quem o cria (utilizadores) tanto quanto possível. O mecanismo principal é o leilão de fluxo de ordens: sempre que a transação (preferência) de um utilizador tem MEV – por exemplo, pode ser alvo de back-running para lucro – o SUAVE realizará um leilão entre executores (searchers) pelo direito de executar essa oportunidade de MEV. Os searchers (executores) licitam prometendo uma parte do lucro de volta ao utilizador como pagamento (este é o campo "lance" do utilizador na sua preferência, que vai para quem a cumprir). O resultado é uma extração de MEV competitiva que direciona a receita para o utilizador em vez do extrator. Por exemplo, se uma grande troca de um utilizador numa DEX cria uma oportunidade de arbitragem de $100, os searchers no SUAVE podem reduzir o lucro oferecendo, digamos,$90 de volta ao utilizador como um reembolso, ficando apenas com $10. Isto suprime os aspetos negativos do MEV, como a extração de valor do utilizador, e transforma o MEV num benefício para o utilizador (os utilizadores efetivamente obtêm melhoria de preço ou reembolsos). O design do SUAVE também suprime o front-running e outro MEV malicioso: as transações no mempool do SUAVE podem ser mantidas encriptadas até que um bloco esteja a ser construído (usando enclaves SGX inicialmente, movendo-se para criptografia de limiar). Isto significa que nenhum ator externo pode ver transações pendentes para fazer front-running; só quando transações suficientes são recolhidas e um bloco é finalizado é que são desencriptadas e executadas, semelhante em espírito a leilões em lote ou mempools encriptados que removem a vantagem de prioridade temporal dos bots. Adicionalmente, como os executores otimizam a execução em muitas preferências, o SUAVE pode eliminar a competição ineficiente (como dois bots a lutar pela mesma arbitragem enviando spam). Em vez disso, o SUAVE seleciona o melhor executor através do leilão e esse executor realiza a troca uma vez, com o resultado a beneficiar o utilizador e a rede. O SUAVE atua assim como um agregador de MEV e uma “fada madrinha”: não elimina o MEV (as oportunidades lucrativas ainda são aproveitadas), mas essas oportunidades são realizadas sob regras transparentes e com os lucros largamente distribuídos aos utilizadores e validadores (e não desperdiçados em taxas de gás ou guerras de latência). Ao unificar os mempools, o SUAVE também aborda o MEV interdomínio de uma forma amigável para o utilizador – por exemplo, uma arbitragem entre a Uniswap no Ethereum e uma DEX na Arbitrum poderia ser capturada por um executor do SUAVE e uma parte paga aos utilizadores de ambos os lados, em vez de ser perdida ou exigir um arbitrador centralizado. Importante, o SUAVE suprime as forças centralizadoras do MEV: acordos de fluxo de ordens exclusivos (onde entidades privadas capturam MEV) tornam-se desnecessários se todos estiverem a usar o leilão comum. A visão final do SUAVE é reduzir a extração de MEV prejudicial (como ataques sanduíche que causam derrapagem), tornando-os não lucrativos ou reembolsando a derrapagem, e usar o “bom MEV” (arbitragem, liquidações) para fortalecer as redes (através da partilha de receitas e execução ótima). Nas próprias palavras da Flashbots, o objetivo do SUAVE é garantir que “os utilizadores transacionem com a melhor execução e taxas mínimas” enquanto “os validadores obtêm a receita máxima” – ou seja, qualquer MEV presente é extraído da forma mais alinhada com o utilizador.

• Estrutura de Incentivo Económico: O SUAVE introduz novos papéis e fluxos de incentivo na cadeia de fornecimento de MEV. Os principais participantes são utilizadores, executores, construtores/validadores de blocos e os operadores da rede SUAVE (validadores da chain SUAVE). Os Utilizadores definem um lance (pagamento) na sua preferência, que será pago se as suas condições forem cumpridas. Este lance é o incentivo para os executores: um executor que cumpre a intenção do utilizador (por exemplo, faz back-running da sua troca para obter um preço melhor) pode reivindicar o lance como recompensa. Os utilizadores estão, portanto, a pagar diretamente pela qualidade da execução, como se estivessem a publicar uma recompensa. Os Executores (Searchers) são motivados a pegar nas preferências dos utilizadores do mempool do SUAVE e a otimizá-las porque ganham o lance do utilizador mais qualquer lucro de arbitragem extra inerente à transação. Os executores competirão para oferecer o melhor resultado ao utilizador, porque o utilizador pode definir o seu lance de forma que só pague se o executor realmente alcançar o resultado desejado (o lance pode ser condicional a resultados on-chain através de oráculos). Por exemplo, um utilizador pode dizer: "Pagarei 0.5 ETH a quem executar esta transação de forma que eu obtenha pelo menos X de saída; caso contrário, não há pagamento." Isto alinha os incentivos dos executores com o sucesso do utilizador. Validadores/Construtores do SUAVE: A própria chain SUAVE será provavelmente uma rede Proof-of-Stake (design a ser determinado), pelo que os validadores (que produzem blocos no SUAVE) ganham taxas de transação no SUAVE (que vêm dos utilizadores que publicam lances e outras operações). Como o SUAVE é uma chain compatível com EVM, também pode haver um token nativo ou um sistema de taxas de gás para essas transações. Estes validadores também desempenham um papel no sequenciamento de blocos interdomínio; no entanto, a inclusão final do bloco em cada L1 ainda é feita pelo validador dessa L1. Em muitos casos, o SUAVE produzirá um modelo de bloco parcial ou completo que um proponente do Ethereum ou de outra chain pode adotar. Esse construtor pode pagar ao SUAVE (ou aos executores do SUAVE) uma parte do MEV. A Flashbots mencionou que os validadores do SUAVE são incentivados por taxas de rede normais, enquanto os executores são incentivados por lances. Distribuição de Valor: A abordagem do SUAVE tende a empurrar o valor para as extremidades: os utilizadores capturam valor (através de melhores preços ou reembolsos diretos), e os validadores capturam valor (através do aumento de taxas/lances). Em teoria, se o SUAVE cumprir a sua missão, a maior parte do MEV será devolvida aos utilizadores ou usada para compensar os validadores por protegerem a rede, em vez de se concentrar nos searchers. A própria Flashbots indicou que não planeia extrair rendas do SUAVE e não ficará com uma parte além do necessário para o arranque – eles querem projetar o mercado, não monopolizá-lo. Outra consideração de incentivo são os construtores inter-chain: o SUAVE permite que os construtores de blocos acedam a MEV interdomínio, o que significa que um construtor numa chain pode ganhar taxas adicionais ao incluir transações que completam arbitragens com outra chain. Isto incentiva os construtores/validadores de diferentes chains a participarem todos no SUAVE, porque ficar de fora significa perder receita. Essencialmente, o design económico do SUAVE tenta alinhar todos os participantes para se juntarem ao leilão comum: os utilizadores porque obtêm melhor execução (e talvez reembolsos de MEV), os validadores porque obtêm a receita máxima, e os searchers porque é lá que o fluxo de ordens é agregado. Ao concentrar o fluxo de ordens, o SUAVE também ganha uma vantagem de informação sobre qualquer ator isolado (todas as preferências num só lugar), o que pressiona economicamente todos a cooperarem dentro do SUAVE em vez de se separarem. Em resumo, os incentivos do SUAVE promovem um ciclo virtuoso: mais fluxo de ordens → melhores oportunidades de MEV combinadas → lances mais altos para utilizadores/validadores → mais fluxo de ordens. Isto contrasta com a competição de soma zero e os acordos exclusivos do passado, visando em vez disso a “coopetição” onde o MEV é um valor partilhado para crescer e distribuir.

• Considerações de Conformidade e Regulamentação: O SUAVE está a ser construído com neutralidade credível e resistência à censura como princípios fundamentais. Por design, o SUAVE remove intermediários centrais – não há um único mempool ou um único construtor para atacar ou regular. As transações (preferências) no SUAVE podem ser totalmente encriptadas e privadas até serem executadas, usando enclaves seguros e, eventualmente, técnicas criptográficas. Isto significa que a censura ao nível do conteúdo da transação é impraticável, uma vez que os validadores/construtores nem sequer conseguem ler os detalhes da transação antes de finalizarem a ordem. O SUAVE força essencialmente uma abordagem de “não confie, verifique”: os participantes não precisam de confiar numa entidade para não censurar, porque a própria arquitetura do sistema (rede descentralizada + encriptação) garante que as preferências de todos são incluídas de forma justa. Além disso, o SUAVE pretende ser uma rede aberta e sem permissões – a Flashbots convida explicitamente todas as partes (utilizadores, searchers, carteiras, outras blockchains) a participar. Não há KYC ou barreiras de permissão no seu design. Isto pode levantar questões com os reguladores (por exemplo, o protocolo poderia facilitar a extração de MEV em transações sancionadas), mas como o SUAVE é apenas uma plataforma descentralizada, a aplicação seria difícil e análoga a tentar regular o mempool de uma blockchain. O foco do SUAVE na privacidade (através de SGX e, mais tarde, criptografia) também protege os dados dos utilizadores e o fluxo de ordens de monitorização indesejada, o que é positivo para a segurança do utilizador, mas pode entrar em conflito com os desejos regulatórios de transparência. Por outro lado, a abordagem do SUAVE poderia ser vista como mais justa e em conformidade com o espírito dos mercados abertos: ao criar um campo de jogo nivelado e devolver valor aos utilizadores, reduz os aspetos exploratórios do MEV que poderiam atrair a ira regulatória (como fazer back-running de utilizadores sem o seu consentimento). O SUAVE também pode ajudar a eliminar dark pools não regulamentados – uma razão pela qual os reguladores podem estar preocupados com o MEV são as vendas de fluxo de ordens exclusivas (que se assemelham a insider trading). O SUAVE substitui-as por um leilão público transparente, argumentavelmente uma estrutura de mercado mais compatível. Em termos de funcionalidades de conformidade explícitas, o SUAVE poderia permitir múltiplas políticas de ordenação: por exemplo, comunidades ou jurisdições poderiam implementar os seus próprios executores com certos filtros ou preferências. No entanto, a base é que o SUAVE tentará ser maximamente neutro: “eliminar quaisquer pontos centrais de controlo, incluindo a Flashbots” e evitar incorporar quaisquer decisões políticas ao nível do protocolo. A Flashbots salientou que não controlará o mercado do SUAVE à medida que este amadurece – o que significa que não haverá um kill-switch central ou um botão de censura. A governação (se houver) do SUAVE ainda não está definida publicamente, mas pode-se esperar que envolva a comunidade em geral e possivelmente um token, em vez do decreto de uma empresa. Em resumo, o SUAVE é projetado para se alinhar com os princípios descentralizados, que por natureza resistem a certo controlo regulatório (censura), enquanto potencialmente aliviam algumas preocupações regulatórias ao tornar a extração de MEV mais equitativa e transparente.

• Arquitetura Técnica (Consenso e Criptografia): O SUAVE operará o seu próprio ambiente de blockchain – pelo menos inicialmente. É descrito como uma chain compatível com EVM especializada em preferências e MEV. A arquitetura tem três componentes principais: (1) o Ambiente Universal de Preferências (a chain SUAVE + mempool, onde as preferências são publicadas e agregadas), (2) o Mercado de Execução (executores off-chain ou on-chain que resolvem/otimizam as preferências, semelhante a um “motor de correspondência de ordens” descentralizado), e (3) a Construção de Blocos Descentralizada (uma rede de participantes do SUAVE que montam blocos para vários domínios). No seu núcleo, o consenso do SUAVE será provavelmente um consenso BFT Proof-of-Stake (semelhante ao Ethereum ou Cosmos) para operar a própria chain SUAVE – embora ainda esteja a ser decidido se o SUAVE se tornará uma L1, uma L2 do Ethereum, ou um conjunto de contratos de “restaking”. Uma possibilidade é que o SUAVE possa começar como uma layer-2 ou sidechain que usa o Ethereum para finalidade, ou aproveitar conjuntos de validadores existentes. O modelo de segurança é TBD, mas as discussões incluíram torná-lo uma L3 do Ethereum ou uma chain do Cosmos. Criptograficamente, o SUAVE apoia-se fortemente em Hardware Confiável e encriptação no seu roteiro inicial. A fase SUAVE Centauri implementa um “leilão de fluxo de ordens consciente da privacidade” no qual a Flashbots (centralmente) opera enclaves SGX para manter o fluxo de ordens de searchers e utilizadores privado. Em SUAVE Andromeda, planeiam usar leilões e construção de blocos baseados em SGX sem confiar na Flashbots (os enclaves fornecem confidencialidade para que nem mesmo a Flashbots possa espreitar). Em SUAVE Helios, o objetivo é ter uma rede de construção descentralizada baseada em SGX – o que significa que muitas partes independentes executam enclaves que constroem blocos coletivamente, alcançando tanto privacidade como descentralização. A longo prazo, a Flashbots está a pesquisar enclaves seguros personalizados e substitutos criptográficos como decriptação de limiar e computação multipartidária para reduzir a dependência do SGX da Intel. Por exemplo, podem usar um esquema de encriptação de limiar onde os validadores do SUAVE detêm conjuntamente uma chave para desencriptar transações apenas depois de a ordenação ser decidida (garantindo que ninguém pode fazer front-run). Este conceito é semelhante ao Ferveo da Anoma ou a outras ideias de “ordenação justa via encriptação de limiar”. Adicionalmente, o SUAVE trata as preferências do utilizador como contratos inteligentes na sua chain. A preferência de um utilizador pode conter um predicado de validade e uma condição de pagamento – isto é essencialmente um pedaço de código que diz “se o resultado X for alcançado na chain Y, então pague ao executor Z esta quantia”. A chain SUAVE precisa de lidar com oráculos e verificação inter-chain para saber quando uma preferência foi cumprida (por exemplo, ler o estado do Ethereum para ver se uma troca aconteceu). Isto implica que a arquitetura do SUAVE envolverá clientes leves on-chain ou sistemas de oráculos para as chains conectadas, bem como potencialmente liquidação atómica inter-chain (para garantir, por exemplo, que um executor pode executar no Ethereum e na Arbitrum e reivindicar atomicamente o lance). O SUAVE planeia ser altamente extensível: por ser compatível com EVM, contratos arbitrários (as “preferências” nativas do SUAVE ou mesmo dapps normais) poderiam ser executados nele, embora a intenção seja mantê-lo focado na coordenação do fluxo de ordens. Em termos de consenso, o SUAVE pode inovar ao ser uma chain centrada em intenções em vez de uma chain centrada em transações, mas, em última análise, deve ordenar mensagens (preferências) e produzir blocos como qualquer chain. Pode-se imaginar o SUAVE a adotar um algoritmo de consenso otimizado para throughput e finalidade de baixa latência, uma vez que se situará no caminho crítico das transações para muitas chains. Talvez um consenso de finalidade instantânea ao estilo Tendermint ou mesmo um consenso baseado em DAG pudesse ser usado para confirmar rapidamente as preferências. Independentemente disso, as características distintivas do SUAVE estão na camada de transação, não na camada de consenso: o uso de tecnologia de privacidade (SGX, encriptação de limiar) para ordenação, comunicação interdomínio e lógica de roteamento de ordens inteligentes incorporada no protocolo. Isto torna-o uma espécie de “meta-camada” sobre as blockchains existentes. Tecnicamente, cada chain participante precisará de confiar nas saídas do SUAVE em certa medida (por exemplo, um proponente do Ethereum precisaria de aceitar um bloco construído pelo SUAVE ou incluir sugestões do SUAVE). A Flashbots indicou que o SUAVE será introduzido gradualmente e de forma opt-in – os domínios podem escolher adotar o sequenciamento do SUAVE para os seus blocos. Se amplamente adotado, o SUAVE poderia tornar-se uma rede de roteamento de transações consciente do MEV de facto para a Web3. Para resumir, a arquitetura do SUAVE é um casamento de blockchain e leilão off-chain: uma chain especializada para coordenação, casada com computação segura off-chain entre executores, tudo ancorado por garantias criptográficas de justiça e privacidade.

• Roteiro de Desenvolvimento e Marcos: A Flashbots delineou o roteiro do SUAVE em três marcos principais, nomeados após sistemas estelares: Centauri, Andromeda, e Helios. Centauri (a primeira fase, em desenvolvimento em 2023) foca-se na construção de um leilão de fluxo de ordens centralizado mas que preserva a privacidade. Nesta fase, a Flashbots executa o serviço de leilão (provavelmente em SGX) que permite aos searchers licitarem para fazer back-run de transações de utilizadores, devolvendo o MEV aos utilizadores de forma privada. Inclui também o lançamento de uma devnet do SUAVE para testes iniciais. De facto, em agosto de 2023, a Flashbots tornou de código aberto um cliente SUAVE inicial (suave-geth) e lançou a Toliman, a primeira testnet pública do SUAVE. Esta testnet tem sido usada para experimentar a expressão de preferências e a lógica básica de leilão. Andromeda (a próxima fase) lançará a primeira mainnet do SUAVE. Aqui, os utilizadores poderão expressar preferências numa rede ao vivo, e o Mercado de Execução operará (executores a cumprir intenções). Andromeda também introduz leilões e construção de blocos baseados em SGX de uma forma mais distribuída – removendo a necessidade de confiar na Flashbots como operador, e tornando o sistema verdadeiramente sem permissões para searchers e construtores. Um dos resultados desta fase é usar o SGX para encriptar o fluxo de ordens de uma forma que mesmo os construtores de blocos não possam espreitar, mas ainda assim possam construir blocos (ou seja, fluxo de ordens “aberto mas privado”). Helios é a ambiciosa terceira fase onde o SUAVE alcança total descentralização e funcionalidade inter-chain. Em Helios, uma rede descentralizada de construtores em SGX produz blocos colaborativamente (sem domínio de um único construtor). Além disso, o SUAVE irá “integrar um segundo domínio” para além do Ethereum – o que significa que irá lidar com MEV para pelo menos duas chains, demonstrando leilões de MEV inter-chain. Adicionalmente, a expressão e execução de MEV interdomínio serão ativadas (os utilizadores podem publicar intenções verdadeiramente multi-chain e tê-las executadas atomicamente). Para além de Helios, a Flashbots antecipa explorar hardware personalizado e criptografia avançada (como provas zk ou MPC) para reforçar ainda mais as garantias de confiança. Atualizações e marcos principais até agora: Novembro de 2022 – SUAVE anunciado; Agosto de 2023 – primeiro lançamento de código do SUAVE e testnet (Toliman); em curso em 2024 – fase Centauri do leilão de fluxo de ordens a funcionar (a Flashbots deu a entender que isto está a ser testado com transações de utilizadores num ambiente fechado). Um marco notável será o lançamento da mainnet do SUAVE (Andromeda), que, em meados de 2025, está no horizonte. A Flashbots comprometeu-se a construir o SUAVE abertamente e a convidar à colaboração de todo o ecossistema. Isto reflete-se na pesquisa e nas discussões do fórum, como as publicações da série “Stargazing” que atualizam sobre a evolução do design do SUAVE. O objetivo final para o SUAVE é que se torne uma peça de infraestrutura de propriedade da comunidade – a “camada de sequenciamento descentralizada” para toda a cripto. Alcançar isto marcará um marco importante na luta pela ordenação justa: se o SUAVE tiver sucesso, o MEV deixaria de ser uma floresta escura para se tornar uma fonte de valor transparente e partilhada, e nenhuma chain única teria de sofrer os efeitos centralizadores do MEV por si só.

Anoma (Arquitetura Centrada em Intenções para Descoberta Justa de Contrapartes)​

Anoma é uma abordagem radicalmente diferente para permitir a ordenação justa e a mitigação de MEV – é uma arquitetura completa para infraestrutura de blockchain baseada em intenções. Em vez de adicionar um leilão a chains existentes, a Anoma repensa o paradigma de transações desde o início. Na Anoma, os utilizadores não transmitem transações concretas; eles transmitem intenções – declarações do estado final que desejam – e a própria rede descobre contrapartes e forma transações que cumprem essas intenções. Ao integrar a descoberta de contrapartes, ordenação justa e privacidade ao nível do protocolo, a Anoma visa eliminar virtualmente certas formas de MEV (como o front-running) e permitir uma troca e liquidação descentralizada “livre de front-runners”. A Anoma é mais uma estrutura do que uma única chain: qualquer blockchain pode ser uma “instância fractal” da Anoma ao adotar a sua arquitetura de gossip de intenções e correspondência. Para esta discussão, focamo-nos na primeira implementação da Anoma (por vezes chamada Anoma L1) e nas suas características de protocolo principais, no que diz respeito à justiça e ao MEV.

• Enfileiramento e Ordenação de Transações: A Anoma descarta o mempool convencional de transações; em vez disso, tem uma rede de gossip de intenções. Os utilizadores transmitem uma intenção, por exemplo, “Quero trocar 100 DAI por pelo menos 1 ETH” ou “Quero pedir emprestado contra uma garantia à melhor taxa.” Estas intenções são ordens parciais – não especificam caminhos de execução exatos, apenas o resultado desejado e as restrições. Todas as intenções são propagadas pela rede e recolhidas. A ordenação na Anoma funciona em duas fases: (1) Descoberta/Correspondência de Contrapartes, e (2) Execução de Transações com Ordenação Justa. Na fase 1, nós especializados chamados solvers monitorizam continuamente o pool de intenções e tentam encontrar conjuntos de intenções que se complementam para formar uma transação válida. Por exemplo, se a Alice pretende trocar DAI por ETH e o Bob pretende trocar ETH por DAI, um solver pode combiná-los. Se várias intenções forem compatíveis (como um livro de ordens de compra e venda), os solvers podem encontrar uma correspondência ou preço de compensação ótimo. Importante, isto acontece off-chain na rede de solvers – efetivamente um matchmaking algorítmico. Assim que um solver (ou grupo de solvers) constrói uma transação completa (ou conjunto de transações) que cumpre algumas intenções, eles submetem-na à chain para execução. É aqui que entra a fase 2: o consenso da Anoma irá então ordenar estas transações submetidas pelos solvers em blocos. No entanto, o consenso da Anoma é projetado para ser justo na ordem: usa técnicas criptográficas (encriptação de limiar) para garantir que as transações são ordenadas sem serem influenciadas pelo seu conteúdo ou pelo tempo exato de submissão. Especificamente, a Anoma planeia usar o Ferveo, um esquema de encriptação de limiar, ao nível do mempool. Funciona da seguinte forma: os solvers encriptam as transações que querem propor usando uma chave pública coletiva dos validadores. Os validadores incluem estas transações encriptadas em blocos sem conhecerem os seus detalhes. Só depois de uma transação ser finalizada num bloco é que os validadores a desencriptam coletivamente (cada um contribuindo com uma parte da chave de decriptação). Isto garante que nenhum validador pode fazer front-run seletivamente ou reordenar com base no conteúdo de uma transação – eles comprometem-se com uma ordenação às cegas. O algoritmo de consenso ordena efetivamente as transações (na verdade, intenções) de uma forma mais próxima de primeiro a ser visto ou em lote, uma vez que todas as transações num determinado “lote” (bloco) são encriptadas e reveladas simultaneamente. Na prática, a Anoma pode implementar leilões em lote para certas aplicações: por exemplo, uma intenção de troca pode ser recolhida ao longo de N blocos (mantida encriptada), depois todas desencriptadas juntas após N blocos e combinadas por solvers num único lote. Isto impede que atores rápidos vejam as ordens de outros e reajam dentro desse lote – uma enorme vantagem para a justiça (esta técnica é inspirada nos Leilões de Lote Frequentes e foi proposta para eliminar as vantagens do trading de alta frequência). Adicionalmente, os predicados de validade da Anoma (contratos inteligentes ao nível da aplicação) podem impor restrições de justiça no resultado da ordenação. Por exemplo, uma aplicação de DEX na Anoma pode ter uma regra: “todas as trocas num lote recebem o mesmo preço de compensação, e os solvers não podem inserir transações adicionais para explorar os utilizadores”. Como estas regras fazem parte da validade do estado, qualquer bloco que contenha uma correspondência injusta (digamos, um solver tentou inserir uma autotroca a um preço melhor) seria inválido e rejeitado pelos validadores. Em resumo, a ordenação na Anoma acontece como corresponder e depois encriptar+ordenar: as intenções são conceptualmente enfileiradas até que um solver forme uma transação, e depois essa transação é ordenada por um consenso de ordem justa (impedindo o MEV típico). Efetivamente, não há corrida no mempool, uma vez que as intenções dos utilizadores não estão a competir diretamente com base no preço do gás ou na prioridade temporal. Em vez disso, a competição é para os solvers encontrarem correspondências, e depois essas correspondências são executadas de uma forma que ninguém pode mudar a ordem ou intercetá-las em trânsito. Esta arquitetura promete neutralizar muitos vetores de MEV – não há conceito de fazer front-running a uma intenção porque as intenções não são acionáveis até que o solver as monte, e nessa altura já estão encriptadas no bloco. É um modelo de enfileiramento fundamentalmente diferente, destinado a eliminar explorações de prioridade baseadas no tempo.

• Mecanismos de Supressão/Extração de MEV: A Anoma é projetada para minimizar o “mau MEV” por construção. Ao ter as trocas resolvidas através de resolução em lote e encriptação de limiar, ataques de MEV típicos como o sanduíche são impossíveis – ninguém vê uma intenção e pode inserir a sua própria antes dela, porque as intenções não são transações que vivem num mempool transparente. Os solvers apenas produzem transações finais correspondidas depois de a oportunidade de inserção ter passado (devido à encriptação e ao loteamento). Numa DEX baseada na Anoma, os utilizadores não seriam alvo de front-running ou back-running no sentido tradicional, porque todas as trocas num lote são executadas juntas a um preço uniforme (impedindo que um atacante explore a mudança de preço entre elas). Isto essencialmente suprime o MEV predatório como arbitragem em DEX ou sanduíche; o valor que teria sido levado por um bot é, em vez disso, retido pelos utilizadores (eles obtêm um preço justo). A abordagem da Anoma à arbitragem também é notável: em muitos casos, se várias intenções criarem uma oportunidade de arbitragem, o solver que as combina incorporará esse lucro na correspondência (por exemplo, combinar preços diferentes e obter um lucro líquido). Mas como vários solvers podem competir para fornecer a melhor correspondência, a competição pode forçar os solvers a devolver a maior parte dessa vantagem aos utilizadores na forma de melhores termos de preenchimento. Por exemplo, se um utilizador quer vender ao preço A e outro quer comprar ao preço B (B > A implica uma lacuna), um solver poderia satisfazer ambos a um preço intermédio e capturar a diferença como lucro – mas se outro solver oferecer aos utilizadores um preço ainda mais próximo um do outro (deixando menos lucro), ele ganhará a intenção. Assim, os solvers competem para reduzir as margens de MEV em benefício dos utilizadores, de forma semelhante a como os searchers no Flashbots competem através de taxas. A diferença é que isto acontece algoritmicamente através da correspondência de intenções em vez de licitação de gás. Ainda pode haver “MEV extraído” na Anoma, mas é provável que se confine a solvers a ganhar taxas modestas pelo seu serviço. Notavelmente, a Anoma espera que a maior parte do fluxo de ordens seja internalizada pelo protocolo ou pela lógica da aplicação. Em alguns casos, isto significa que o que seria uma oportunidade de MEV se torna apenas uma taxa de protocolo normal. Por exemplo, a primeira instância fractal da Anoma (Namada) implementa uma AMM de curva de ligação on-chain; a arbitragem nessa AMM é capturada pelo mecanismo da AMM (como um rebalanceador embutido) em vez de arbitradores externos. Outro exemplo: uma intenção de empréstimo que oferece juros altos poderia ser combinada com uma intenção de empréstimo; nenhum terceiro liquidatário é necessário se a garantia cair, porque as próprias intenções poderiam lidar com o rebalanceamento ou o protocolo poderia auto-liquidar a um preço justo. Ao eliminar os extratores de terceiros, a Anoma reduz a prevalência da extração de MEV off-chain. Adicionalmente, a Anoma enfatiza a privacidade (através do subsistema Taiga de circuitos ZK). Os utilizadores podem optar por manter as suas intenções parcial ou totalmente protegidas (por exemplo, montantes ou tipos de ativos ocultos). Isto suprime ainda mais o MEV: se os detalhes de uma grande ordem estiverem ocultos, ninguém pode visar a extração de valor. Só após a correspondência e execução é que os detalhes podem surgir, altura em que já é tarde demais para explorar. Em resumo, o mecanismo da Anoma é em grande parte sobre prevenir o MEV em vez de o extrair: ao agrupar transações em lote, encriptar o mempool e incorporar o alinhamento económico na correspondência, tenta garantir que há pouca oportunidade para arbitragem maliciosa ou front-running. O MEV necessário (como arbitragem para igualar preços entre mercados) é tratado por solvers ou pela lógica do protocolo de uma forma minimizada em confiança. Poder-se-ia dizer que a Anoma visa a “minimização do MEV”, esforçando-se por resultados como se cada utilizador tivesse acesso à contraparte perfeita instantaneamente, sem fugas de informação. Qualquer valor extraído para facilitar isso (a recompensa do solver) é semelhante a uma pequena taxa de serviço, não a um ganho inesperado por explorar assimetria.

• Estrutura de Incentivo Económico: Na Anoma, os solvers assumem o papel análogo tanto a casamenteiros como a construtores de blocos. Eles incorrem em custos (computação, talvez depositar garantias) para encontrar correspondências de intenções, e são recompensados quando propõem com sucesso transações que são incluídas. Os solvers podem ganhar de várias maneiras: podem cobrar uma taxa ou um spread dentro da transação que constroem (por exemplo, dando aos utilizadores termos ligeiramente menos favoráveis e ficando com a diferença, semelhante a como um agregador de DEX pode ficar com uma pequena parte). Ou, certas intenções podem incluir explicitamente uma recompensa para o solver (como "Estou disposto a pagar até 0.01 ETH para que isto seja feito"). O modelo de compensação exato é flexível, mas a chave é que os solvers competem. Se um solver tentar cobrar uma taxa demasiado alta, outro pode propor uma solução com um resultado melhor para o utilizador e ganhar a inclusão. Esta dinâmica competitiva destina-se a manter os lucros dos solvers sob controlo e alinhados com a prestação de valor. Validadores (Produtores de Blocos): Os validadores da Anoma executam o consenso que ordena e executa as transações. São incentivados por recompensas de bloco e taxas, como em qualquer blockchain. Notavelmente, se as intenções forem correspondidas entre vários utilizadores, a transação resultante pode ter várias fontes de taxas (cada utilizador pode contribuir com uma taxa ou uma porção de ativos). É possível que o modelo de taxas da Anoma permita a divisão de taxas, mas tipicamente os validadores receberão as taxas de gás padrão para processar transações. Em fases futuras, a Anoma planeia um “consenso sob demanda” e um token nativo. A ideia é que muitas instâncias da Anoma (ou shards) possam existir, e algumas possam ser iniciadas temporariamente para tarefas específicas (“consenso ad-hoc” para necessidades particulares de aplicações). O token seria provavelmente usado para fazer staking e proteger estas instâncias. Os incentivos aqui garantem que a rede tem validadores suficientes para processar todas as transações correspondidas de forma fiável e que se comportam honestamente no processo de decriptação de limiar (talvez com condições de slashing se tentarem desencriptar cedo ou censurar). Utilizadores: Os utilizadores na Anoma potencialmente poupam dinheiro e obtêm melhores resultados em vez de pagarem MEV implicitamente. Por exemplo, podem consistentemente obter melhores preços de troca do que numa chain tradicional, o que significa que o valor fica com eles. Em alguns casos, os utilizadores também podem pagar taxas explícitas para incentivar os solvers, especialmente para intenções complexas ou quando desejam uma correspondência mais rápida. Mas como os utilizadores podem expressar intenções sem especificar como fazê-las, eles descarregam o trabalho pesado para os solvers e só pagam se valer a pena. Há também uma noção de que “os proprietários de intenções podem definir os seus próprios trade-offs de segurança/desempenho” – por exemplo, um utilizador pode dizer “Vou esperar mais tempo por um preço melhor” ou “Vou pagar mais por uma execução imediata.” Esta flexibilidade permite que os próprios utilizadores decidam quanto oferecer aos solvers ou validadores, alinhando os incentivos económicos com as suas necessidades. Redistribuição de MEV: Se algum MEV ocorrer (como ARB inter-chain ou algo do género), a arquitetura da Anoma poderia permitir capturá-lo no sistema. Por exemplo, múltiplos shards ou instâncias da Anoma podem coordenar-se para liquidar uma arbitragem atómica multi-chain, e o lucro poderia ser partilhado ou queimado (dependendo do design) em vez de deixar um arbitrador externo ficar com tudo. Em geral, como a Anoma dá às aplicações controlo sobre o fluxo de transações, é possível implementar estratégias de MEV de propriedade do protocolo (semelhante à filosofia do Skip) ao nível da aplicação. Por exemplo, uma aplicação DeFi na Anoma poderia encaminhar automaticamente todas as trocas dos utilizadores através de um solver no protocolo que garante a melhor execução e partilha qualquer lucro adicional com os utilizadores ou com os fornecedores de liquidez. O efeito líquido é que os extratores de MEV de terceiros são desintermediados. Economicamente, isto é de soma positiva para os participantes honestos (utilizadores, LPs, etc.), mas pode reduzir as oportunidades para os searchers clássicos. No entanto, novos papéis como solvers especializados (talvez um se foque na correspondência de NFTs, outro em trocas de FX, etc.) surgirão. Estes solvers são análogos aos searchers de MEV de hoje, mas operam dentro das regras do sistema e provavelmente têm margens de lucro menos insanas devido à competição e às restrições do protocolo. Por último, a visão da Fundação Anoma sugere que a Anoma seja uma infraestrutura de bem público. Haverá um token nativo, presumivelmente ANOMA, que pode capturar valor através de taxas ou ser necessário para staking. Pode-se prever incentivos de token (recompensas inflacionárias, etc.) para validadores e talvez até para solvers para impulsionar a atividade. No momento da escrita, os detalhes sobre a economia do token não são finais, mas o roteiro confirma que um token Anoma e um consenso nativo sob demanda estão planeados em fases futuras. Para resumir, o modelo de incentivos da Anoma encoraja o comportamento cooperativo: os solvers ganham ao ajudar os utilizadores a obter o que querem, não ao explorá-los; os validadores ganham ao proteger a rede e ordenar de forma justa; e os utilizadores “pagam” principalmente ao ceder algum MEV aos solvers ou taxas, mas idealmente muito menos do que o MEV implícito que perderiam noutros sistemas.

• Conformidade e Neutralidade: A Anoma, sendo uma estrutura, não uma única rede, pode ser instanciada de várias formas – algumas podem ser permissionadas, mas a Anoma L1 principal e instâncias semelhantes destinam-se a ser sem permissões e com privacidade aprimorada. Ao incorporar funcionalidades de privacidade pesadas (como intenções protegidas usando provas de conhecimento zero no Taiga), a Anoma alinha-se com a visão de que a privacidade financeira é um direito. Isto pode colocá-la em conflito com certos regimes regulatórios que exigem visibilidade aberta das transações. No entanto, o design da Anoma também pode evitar certas armadilhas regulatórias. Por exemplo, se o front-running e a seleção injusta de ordens forem eliminados, as preocupações com a manipulação de mercado são mitigadas – um regulador pode apreciar que os utilizadores não estão a ser sistematicamente explorados por insiders. Adicionalmente, o conceito de “modelos de segurança definidos pelo utilizador” implica que os utilizadores ou comunidades podem optar por diferentes pressupostos de confiança. Potencialmente, uma aplicação regulada poderia ser construída na Anoma onde, digamos, o solver ou um subconjunto de validadores são entidades com KYC, garantindo a conformidade para esse domínio de intenção particular. A Anoma como camada base não imporia KYC a todos, mas poder-se-ia implementar predicados de validade que exigem (por exemplo) uma prova de elegibilidade para certas transações (como uma prova de não ser um endereço sancionado, ou uma verificação de credenciais) se uma aplicação o necessitasse. A arquitetura é flexível o suficiente para suportar a conformidade ao nível da aplicação sem comprometer a neutralidade da camada base. Em relação à censura: a encriptação de limiar da Anoma significa que, mesmo que os validadores quisessem censurar, não podem visar intenções específicas porque não as veem em texto simples. A única coisa que poderiam fazer é recusar-se a incluir transações encriptadas de certos solvers ou utilizadores, mas isso seria óbvio (e contra as regras do protocolo se feito arbitrariamente). A expectativa é que as regras de consenso desencorajem a censura – por exemplo, talvez se um bloco não incluir todas as intenções desencriptadas disponíveis do último lote, ele possa ser considerado inválido ou menos preferível. Em qualquer caso, a descentralização dos validadores e a natureza encriptada das cargas úteis garantem um alto grau de resistência à censura. Sobre a neutralidade: a Anoma visa ser uma plataforma geral não controlada por nenhuma entidade única. A pesquisa e o desenvolvimento são liderados pela Heliax (a equipa por trás da Anoma e da Namada), mas uma vez ao vivo, uma rede Anoma seria gerida pela comunidade. É provável que haja governação on-chain para atualizações, etc., o que poderia levantar questões de conformidade (por exemplo, poderia um governo subverter a governação para mudar as regras?), mas isso é uma questão geral de blockchain. Uma característica interessante relacionada com a conformidade é que a Anoma suporta múltiplas instâncias paralelas – o que significa que se poderia ter um pool de intenções isolado ou um shard para certos tipos de ativos ou jurisdições. Isto não é explicitamente para regulação, mas poderia permitir, por exemplo, um pool de intenções de CBDC onde apenas bancos autorizados executam solvers, coexistindo com um pool de DeFi livre. A modularidade da arquitetura oferece flexibilidade para segregar, se necessário, enquanto ainda permite a interoperabilidade através de pontes de intenções. Finalmente, em termos de compatibilidade legal, todo o conceito de intenções da Anoma pode evitar algumas classificações que atormentam a cripto tradicional: como uma intenção não é uma transação vinculativa até ser correspondida, pode-se argumentar que os utilizadores mantêm mais controlo (é como publicar uma ordem numa bolsa, que tem um precedente legal mais claro, em vez de executar diretamente uma troca). Isto pode ajudar com coisas como o tratamento fiscal (o sistema poderia potencialmente dar um recibo unificado de uma troca de vários passos em vez de muitas transações) – embora isto seja especulativo. No geral, a Anoma prioriza a descentralralização, privacidade e autonomia do utilizador, o que historicamente pode entrar em conflito com as expectativas regulatórias, mas os ganhos de justiça e transparência podem ganhar favor. Essencialmente, traz a sofisticação dos motores de correspondência financeira tradicionais para a on-chain, mas sem operadores centralizados. Se os reguladores chegarem a entender esse modelo, podem vê-lo como uma estrutura de mercado mais ordenada e justa do que o vale-tudo dos mempools.

• Arquitetura Técnica (Consenso e Criptografia): A arquitetura da Anoma é complexa, compreendendo vários componentes: Typhon (rede, mempool, consenso, execução) e Taiga (a camada de privacidade de conhecimento zero). O núcleo do Typhon é a camada de gossip de intenções e uma abordagem inovadora para consenso + correspondência combinados. O protocolo de consenso da Anoma estende o consenso BFT típico com o conceito de “Predicados de Validade” e “Prova de Correspondência de Ordem”. Essencialmente, cada aplicação na Anoma pode definir um predicado de validade que deve ser satisfeito para as transações (pense nisso como condições de contrato inteligente que se aplicam ao nível do bloco, não apenas ao nível da transação). Isto permite impor propriedades como preços de compensação de leilões em lote, etc., como descrito. O próprio algoritmo de consenso provavelmente baseia-se em BFT ao estilo Tendermint ou HotStuff (uma vez que a Anoma está no reino do Cosmos e suporta IBC). De facto, a testnet inicial da Anoma (Feigenbaum em 2021) e a Namada usam consenso ao estilo Tendermint com modificações. Uma modificação importante é a integração da encriptação de limiar (Ferveo) no pipeline do mempool. Tipicamente, o Tendermint seleciona um proponente que ordena as transações. Na Anoma, o proponente ordenaria intenções/transações encriptadas. O Ferveo provavelmente funciona fazendo com que os validadores concordem periodicamente numa chave pública de limiar, e cada intenção submetida pelos solvers é encriptada para essa chave. Durante a proposta de bloco, todas as transações encriptadas são incluídas; após a proposta, os validadores executam um protocolo para desencriptá-las (talvez o próximo bloco contenha as saídas desencriptadas ou algum esquema semelhante). Isto adiciona uma fase ao consenso, mas garante a justiça da ordem. Criptograficamente, isto usa geração de chave distribuída e decriptação de limiar (pelo que depende de pressupostos como pelo menos 2/3 dos validadores serem honestos para não vazar ou desencriptar dados antecipadamente). No lado da privacidade, o Taiga fornece provas zkSNARK ou zk-STARK que permitem que as intenções permaneçam parcial ou totalmente protegidas. Por exemplo, um utilizador pode submeter uma intenção de troca sem revelar o tipo de ativo ou a quantidade; ele fornece uma prova ZK de que tem saldo suficiente e que a transação será válida se correspondida, sem revelar detalhes. Isto é análogo a como as transações protegidas no Zcash funcionam, mas estendido a intenções. O uso de provas recursivas é mencionado, o que significa que vários passos de uma transação (ou várias intenções) podem ser provados numa única prova sucinta para eficiência. A interação entre o Taiga e o Typhon significa que alguns solvers e validadores podem estar a operar sobre texto cifrado ou compromissos em vez de valores em texto simples. Por exemplo, um solver pode corresponder intenções que são expressas de forma confidencial, resolvendo uma equação de compromissos. Isto é criptografia de ponta e vai além do que a maioria das blockchains atuais faz. Outra peça chave é a integração com o IBC: as instâncias da Anoma podem comunicar com outras chains (especialmente chains do Cosmos) através do protocolo de Comunicação Inter-Blockchain. Isto significa que uma intenção na Anoma poderia potencialmente desencadear uma ação noutra chain (através de uma mensagem IBC) ou consumir dados do estado de outra chain. A Fase 1 da Mainnet no roteiro da Anoma menciona especificamente um “adaptador” no Ethereum e em rollups para permitir que as intenções da Anoma acedam à liquidez da EVM. Provavelmente, um solver da Anoma poderia compor uma transação que, digamos, usa a Uniswap no Ethereum, criando uma intenção que, quando correspondida, envia uma mensagem para o Ethereum para executar uma troca (talvez através de um relayer ou de algo como uma ponte IBC). O consenso tem de garantir a atomicidade: presumivelmente, a saída da Anoma pode ser como uma única transação que abrange várias chains (algo como iniciar uma transação na chain A e esperar um resultado na chain B). Alcançar a liquidação atómica inter-chain é difícil; possivelmente a Anoma começará por liquidar numa chain de cada vez (a Fase 1 foca-se no ecossistema Ethereum, provavelmente significando que as intenções da Anoma serão liquidadas na L1 ou L2s do Ethereum de uma só vez). Mais tarde, as “chains Chimera” e o consenso sob demanda podem permitir que sidechains personalizadas sejam iniciadas para lidar com correspondências inter-chain particulares. Em termos de desempenho, a abordagem da Anoma pode ser mais intensiva computacionalmente (solvers a resolver problemas de correspondência NP-difíceis, validadores a fazer criptografia pesada). Mas o trade-off é uma experiência de utilizador vastamente melhorada (sem transações falhadas, melhores preços, etc.). O desenvolvimento da Anoma requer a construção destes componentes inovadores quase do zero: a Heliax tem vindo a criar a Juvix, uma nova linguagem para escrever predicados de validade e intenções, e muita pesquisa (algumas referências do site da Anoma falam sobre estes conceitos em detalhe). Marcos principais: A primeira testnet pública da Anoma, Feigenbaum, foi lançada em novembro de 2021 como uma demonstração do gossip básico de intenções. Subsequentemente, a Heliax mudou o foco para o lançamento da Namada (uma L1 focada em privacidade que pode ser vista como uma instância da Anoma focada em transferências de ativos) – a Namada foi lançada em 2023 e inclui funcionalidades como transferências protegidas e encriptação de limiar Ferveo para o seu mempool. Isto mostra a tecnologia em ação num caso de uso mais restrito. Entretanto, as testnets da visão completa da Anoma têm sido lançadas em fases (uma “testnet de verão de 2023” foi mencionada na comunidade). O roteiro indica que a mainnet da Fase 1 integrará o Ethereum, a Fase 2 adicionará mais chains e criptografia avançada, e eventualmente o consenso nativo e o token chegarão. A separação de “consenso e token em fase futura” sugere que a mainnet inicial da Anoma pode depender do Ethereum (por exemplo, aproveitando a segurança do Ethereum ou tokens existentes em vez de ter o seu próprio desde o primeiro dia). Possivelmente, eles lançarão uma L2 ou sidechain que publica no Ethereum. E mais tarde iniciarão a sua própria rede PoS com um token. Esta abordagem faseada é interessante – pode ser para diminuir a barreira à adoção (usar o capital existente no Ethereum em vez de lançar uma nova moeda inicialmente). Em conclusão, a arquitetura da Anoma é inovadora e abrangente: casa a justiça criptográfica (encriptação de limiar, provas ZK) com um novo paradigma de transação (correspondência baseada em intenções) e capacidades inter-chain. É, sem dúvida, a tentativa mais agressiva de erradicar o MEV tradicional ao nível do protocolo, fazendo o que nenhuma chain legada faz: motores de correspondência justos incorporados. A complexidade é alta, mas se for bem-sucedida, uma chain Anoma poderia fornecer aos utilizadores garantias de execução quase semelhantes às de uma CEX num ambiente descentralizado, o que é um santo graal na UX e justiça da blockchain.

Skip Protocol (Controlo Soberano de MEV e Kit de Ferramentas de Ordenação Justa do Cosmos)​

O Skip Protocol é uma solução líder de MEV no ecossistema Cosmos, focada em dar a cada blockchain (“app-chain”) as ferramentas para gerir a ordenação de transações e a captura de MEV nos seus próprios termos. Ao contrário do Flashbots ou da Anoma, que propõem sistemas que abrangem toda a rede, o Skip alinha-se com a filosofia de soberania do Cosmos: cada chain pode integrar os módulos do Skip para impor regras de ordenação justa personalizadas, executar leilões de espaço de bloco no protocolo e capturar MEV para os stakeholders ou utilizadores da chain. O Skip pode ser pensado como um conjunto de módulos do Cosmos SDK e infraestrutura que, juntos, permitem a Construção de Blocos de Propriedade do Protocolo (POB) e o sequenciamento flexível de transações. Foi adotado em chains como Osmosis, Juno, Terra e outras no Cosmos, e também está a colaborar com projetos como a futura chain da dYdX para mitigação de MEV. Os elementos chave incluem um mecanismo de leilão on-chain para transações prioritárias, lógica de ordenação de transações ao nível do consenso e mecanismos na aplicação para reciclar MEV (“bom MEV”) para benefício do protocolo.

• Algoritmos de Enfileiramento e Ordenação de Transações: Numa chain típica do Cosmos (usando consenso Tendermint/BFT), o mempool ordena as transações aproximadamente por taxa e tempo de chegada, e o proponente do bloco pode escolher qualquer ordenação ao criar um bloco (sem restrições algorítmicas para além de incluir transações válidas). O Skip muda isto ao introduzir regras de ordenação impostas pelo consenso e mempools de múltiplas vias (lanes). Usando a nova interface ABCI++ do Cosmos (que permite personalizar a proposta e o processamento de blocos), o módulo Protocol-Owned Builder (POB) do Skip pode particionar o bloco em lanes distintas com diferentes políticas de ordenação. Por exemplo, uma lane poderia ser uma lane de leilão Top-of-Block onde as transações com o lance mais alto (talvez de bots de arbitragem ou trocas urgentes) são colocadas primeiro no bloco numa ordem fixa, outra lane poderia ser uma lane Gratuita para transações de utilizadores comuns sem taxas, e uma lane Padrão para transações normais com taxas. O componente BlockBuster do módulo do Skip permite que os desenvolvedores definam estas lanes e a sua lógica de ordenação de forma modular. Crucialmente, estas regras são impostas por todos os validadores: quando um proponente constrói um bloco, os outros validadores verificarão se as transações do bloco aderem às regras de ordenação acordadas (através das verificações ProcessProposal do ABCI). Se não, eles podem rejeitar o bloco. Isto significa que mesmo um proponente malicioso ou que procura lucro não pode desviar-se (por exemplo, não pode inserir a sua própria transação de front-run à frente de um licitante vencedor do leilão, porque isso violaria a regra de ordenação). Alguns exemplos de regras de ordenação que o Skip permite: (a) Ordenar transações por preço de gás decrescente (taxa) – garantindo que a transação com a taxa mais alta tenha sempre prioridade. Isto formaliza um esquema justo de “pagar por prioridade” em vez de aleatório ou baseado no tempo. (b) Deve incluir pelo menos uma transação de atualização de preço de oráculo antes de quaisquer trocas – garantindo que os feeds de dados são atualizados, o que impede cenários em que um proponente poderia ignorar as atualizações de oráculo para explorar preços desatualizados. (c) Limitar o número de transações especiais no topo do bloco – por exemplo, apenas um bundle vencedor do leilão pode ocupar o topo, para evitar o spam de muitas pequenas capturas de MEV. (d) Nenhuma transação que viole uma propriedade de estado – o Skip permite regras de ordenação com estado, como “após construir o bloco, garantir que nenhuma troca de DEX foi executada a um preço pior do que se estivesse no final do bloco” (uma forma de garantir que não ocorreu um ataque sanduíche). Uma regra concreta descrita é uma “condição de zero front-running em todas as DEXs”, o que poderia significar que se alguma transação tivesse sido afetada por outras posteriores de uma forma que indicasse front-running, o bloco seria inválido. Isto é poderoso: é essencialmente tornar a justiça parte da validade do bloco. As chains do Cosmos podem implementar tais regras porque controlam a sua pilha completa. A estrutura do Skip oferece uma forma estruturada de o fazer através do AuctionDecorator no SDK, que pode verificar cada transação contra as regras configuradas. Adicionalmente, o Skip fornece melhorias no mempool: o mempool do nó pode simular blocos antecipadamente, filtrar transações falhadas, etc., para ajudar os proponentes a seguir as regras eficientemente. Por exemplo, se a lane de leilão de um bloco deve ter os lances mais altos, o mempool pode ser ordenado por lances para essa lane. Se um bloco deve incluir apenas transações que resultem numa certa condição de estado, o nó do proponente pode simular transações à medida que as seleciona para garantir que a condição se mantém. Em resumo, o Skip permite uma ordenação determinística e definida pela chain em vez de a deixar inteiramente ao capricho do proponente ou à simples prioridade do preço do gás. As chains adotam o módulo de construtor do Skip para efetivamente codificar a sua política de ordenação de transações no protocolo. Isto promove a justiça porque todos os validadores impõem as mesmas regras, removendo a oportunidade de um único proponente fazer uma reordenação arbitrária para MEV, a menos que seja dentro do mecanismo permitido (como o leilão, onde é transparente e competitivo). O enfileiramento de transações no modelo do Skip pode envolver filas separadas por lane. Por exemplo, uma lane de leilão pode enfileirar transações de lances especiais (o Skip usa um tipo especial MsgAuctionBid para licitar pela inclusão no topo do bloco). Esses lances são recolhidos a cada bloco e o mais alto é selecionado. Entretanto, as transações normais são enfileiradas no mempool padrão. Essencialmente, o Skip introduz uma fila estruturada: uma para lances prioritários, uma para gratuitas ou outras, etc., cada uma com os seus próprios critérios de ordenação. Esta abordagem modular significa que cada chain pode personalizar como equilibra justiça e receita – por exemplo, a Osmosis pode dizer “não queremos nenhum leilão de MEV, mas impomos justiça na ordem através de encriptação de limiar” (eles implementaram encriptação de limiar com a ajuda do Skip e outros), enquanto outra chain pode dizer “permitimos leilões para MEV, mas exigimos que parte dos lucros seja queimada”. O Skip suporta ambos. Esta configurabilidade da ordenação é a marca registada do Skip.

• Mecanismos de Mitigação e Extração de MEV: A abordagem do Skip ao MEV é frequentemente descrita como “MEV de propriedade do protocolo” e “multiplicidade”. MEV de propriedade do protocolo significa que o próprio protocolo da blockchain, através do seu código e governação, captura ou redistribui o MEV em vez de o deixar para validadores individuais ou externos. Multiplicidade refere-se a garantir que as transações “certas” (múltiplas) são incluídas – essencialmente não excluindo transações legítimas de utilizadores em favor de apenas transações de MEV, e talvez incluindo múltiplas oportunidades de MEV num bloco, se possível (para que nenhum searcher único monopolize). Concretamente, o Skip fornece ferramentas para capturar MEV de formas que beneficiam a rede: uma é o Skip Select, um sistema de leilão de espaço de bloco para inclusão no topo do bloco. No Skip Select, os searchers (como bots de arbitragem) submetem bundles com gorjetas aos validadores, semelhante aos bundles do Flashbots, exceto que é feito nativamente on-chain através dos módulos do Skip. O bundle (ou bundles) com o pagamento mais alto é então automaticamente inserido no topo do bloco na ordem especificada. Isto garante que essas transações são executadas como pretendido, e o validador (ou a chain) recolhe a gorjeta. Este mecanismo pega no que era um processo OTC off-chain (no Ethereum) e torna-o um leilão aberto e on-chain – melhorando a transparência e o acesso. Outro mecanismo é o ProtoRev (Módulo de Receita de Protótipo), que o Skip desenvolveu para a Osmosis. O ProtoRev é um módulo de arbitragem on-chain que deteta e executa automaticamente arbitragens cíclicas (como as que envolvem múltiplos pools) dentro da execução do bloco e acumula o lucro para o tesouro da chain ou para o pool comunitário. Essencialmente, a Osmosis decidiu que certo “bom MEV” (como arbitragem que mantém os preços alinhados) ainda deveria acontecer (para a eficiência do mercado), mas o próprio protocolo faz a arbitragem e captura o lucro, distribuindo-o mais tarde (por exemplo, para stakers ou como incentivos de mineração de liquidez). Isto elimina a necessidade de bots de arbitragem externos nessas oportunidades e garante que o valor permanece no ecossistema. O ProtoRev foi o primeiro do seu género numa chain importante e demonstra como a integração profunda pode mitigar as externalidades do MEV: os utilizadores que negoceiam na Osmosis enfrentam menos derrapagem porque, se existir uma arbitragem após a sua troca, o protocolo irá fechá-la e essencialmente reembolsar o valor de volta para a Osmosis (o que poderia beneficiar indiretamente os utilizadores através de taxas mais baixas ou recompras de tokens, etc.). Além disso, o Skip capacita as chains a implementar medidas anti-MEV como a encriptação de limiar para o mempool. Por exemplo, a Osmosis, em colaboração com o Skip e outros, está a implementar a encriptação do mempool, onde as transações são submetidas encriptadas e só são reveladas após um tempo fixo (semelhante à ideia da Anoma, mas ao nível da chain). Embora não seja um produto do Skip per se, a arquitetura do Skip é compatível – o leilão do Skip pode funcionar em transações encriptadas, fazendo o leilão com base em lances declarados em vez de ler o conteúdo da transação. Em termos de supressão de MEV prejudicial: as regras de consenso do Skip como “não é permitido front-running” (impostas por verificações de estado) são uma medida direta para parar o comportamento malicioso. Se um validador tentar incluir um ataque sanduíche, outros validadores detetariam que o resultado do estado viola a regra de não front-running (por exemplo, poderiam verificar que nenhuma troca foi imediatamente precedida e seguida por outra do mesmo endereço de uma forma que tirou vantagem). Esse bloco seria rejeitado. Sabendo disto, os validadores nem sequer tentarão incluir tais padrões, protegendo assim os utilizadores pela lei do protocolo. O Skip também incentiva a queima ou redistribuição da receita de MEV para evitar incentivos perversos. Por exemplo, uma chain pode optar por queimar todos os lucros do leilão ou colocá-los num fundo comunitário em vez de os dar todos ao proponente do bloco. Isto reduz o incentivo para os validadores reordenarem as transações eles próprios, uma vez que podem não lucrar pessoalmente com isso (dependendo da escolha da chain). Em resumo, o kit de ferramentas do Skip permite que cada chain extraia cirurgicamente o MEV onde é benéfico (por exemplo, arbitragem para manter a eficiência do mercado, liquidações para manter os mercados de empréstimo saudáveis) e garanta que o valor é capturado pelo protocolo ou pelos utilizadores, enquanto proíbe e previne estritamente o MEV malicioso (como o front-running prejudicial ao utilizador). É uma mistura pragmática de extração e supressão, adaptada pela governação: em vez de uma solução única para todos, o Skip capacita as comunidades a decidir qual MEV é “bom” (e automatizar a sua captura) e qual é “mau” (e proibi-lo através de regras de consenso). O resultado é um ambiente de negociação mais justo nas chains habilitadas pelo Skip e uma fonte de receita adicional que pode financiar bens públicos ou reduzir custos (uma das publicações do blog do Skip nota que a captura justa de MEV pode ser usada para “distribuir justamente a receita entre todos os participantes da rede”).

• Estrutura de Incentivo Económico: A introdução do Skip muda fundamentalmente os incentivos, especialmente para validadores e comunidades de chains no Cosmos. Tradicionalmente, um validador no Cosmos pode extrair MEV reordenando privadamente as transações no seu bloco (uma vez que o Cosmos não tem um leilão de MEV por defeito). Com o Skip, os validadores concordam com um protocolo onde o MEV é capturado através de leilões ou módulos e muitas vezes partilhado. Os Validadores ainda beneficiam: podem receber uma parte dos lucros do leilão ou taxas extras dos mecanismos do Skip, mas, importante, todos os validadores (não apenas o proponente) podem beneficiar se for projetado dessa forma. Por exemplo, alguns leilões do Skip podem ser configurados para que a receita seja dividida entre todos os stakers ou de acordo com as decisões da governação, em vez de ser um vencedor-leva-tudo para o proponente. Isto alinha os validadores coletivamente para executarem o software do Skip, porque mesmo os não-proponentes obtêm segurança (sabendo que se alguém tentar um bloco inválido, não valerá a pena) e possivelmente receita. Algumas chains podem ainda dar ao proponente a maior parte da taxa do leilão de MEV (para maximizar o incentivo imediato para incluí-lo), mas mesmo assim é transparente e competitivo, argumentavelmente reduzindo a chance de acordos por baixo da mesa. Chain/Comunidade: O conceito de MEV de propriedade do protocolo significa que a blockchain e os seus stakeholders capturam o MEV. Por exemplo, a Osmosis direciona os lucros do ProtoRev para o seu pool comunitário, transformando efetivamente o MEV numa receita adicional do protocolo que pode financiar o desenvolvimento ou ser distribuída aos stakers de OSMO. Isto torna a comunidade em geral uma “proprietária” desse MEV, alinhando o interesse de todos em extrair MEV de formas saudáveis. Se os utilizadores sabem que o MEV está a ser usado para melhorar a chain ou a tokenomics, podem aceitá-lo melhor do que se fosse para um bot aleatório. Searchers: No modelo do Skip, os searchers/bots independentes podem ter menos a fazer on-chain porque algumas oportunidades são aproveitadas pela lógica do protocolo (como o ProtoRev) e outras são canalizadas através de leilões. No entanto, o Skip não elimina os searchers – em vez disso, canaliza-os para licitarem através das rotas adequadas. Um searcher ainda pode tentar uma estratégia complexa, mas para garantir a inclusão num local específico, deve participar no leilão do Skip (Skip Select) submetendo o seu bundle com um lance. Se não o fizer, corre o risco de um validador o ignorar em favor de alguém que licitou ou do mecanismo da própria chain aproveitar a oportunidade. Assim, os searchers no Cosmos estão a evoluir para trabalhar com o Skip: por exemplo, muitos arbitradores na Osmosis agora submetem as suas arbitragens através do sistema do Skip. Eles pagam uma parte à chain, ficando com menos lucro, mas é o preço a pagar para jogar. Com o tempo, alguns papéis de “searcher” podem ser totalmente absorvidos (como a arbitragem de back-running – o ProtoRev lida com isso, pelo que nenhum searcher externo pode competir). Isto pode reduzir o spam e o esforço desperdiçado na rede (não há mais múltiplos bots a correr; apenas uma execução de protocolo). Utilizadores: Os utilizadores finais têm a ganhar devido a um ambiente mais justo (sem ataques de MEV surpresa). Além disso, algumas configurações do Skip recompensam explicitamente os utilizadores: a redistribuição de MEV aos utilizadores é possível. Por exemplo, uma chain pode decidir reembolsar parte da receita do leilão de MEV aos utilizadores cujas trocas criaram esse MEV (semelhante à ideia de reembolso do Flashbots). A Astroport, uma DEX na Terra, integrou o Skip para partilhar a receita de MEV com os swappers – o que significa que se a troca de um utilizador tivesse MEV, parte desse valor é devolvido a ele por defeito. Isto alinha-se com o ethos de que o MEV deve ir para os utilizadores. Embora nem todas as chains façam isto, a opção existe através da infraestrutura do Skip para implementar tais esquemas. O próprio Skip Protocol (a empresa/equipa) tem um modelo de negócio onde fornece estas ferramentas muitas vezes gratuitamente aos validadores (para encorajar a adoção), e monetiza através de parcerias com chains (B2B). Por exemplo, o Skip pode ficar com uma pequena taxa do MEV capturado ou cobrar às chains por funcionalidades avançadas/suporte. É mencionado que o Skip é gratuito para validadores, mas usa um modelo B2B com as chains. Isto significa que o Skip tem um incentivo para maximizar o MEV capturado pela chain e pela comunidade (para que a chain fique satisfeita e talvez partilhe uma porção conforme o acordo). Mas como a governação está envolvida, qualquer taxa que o Skip cobre é geralmente acordada pela comunidade. O efeito económico é interessante: profissionaliza a extração de MEV como um serviço fornecido às chains. Ao fazê-lo, desincentiva o comportamento desonesto – os validadores não precisam de fazer acordos obscuros individualmente, podem simplesmente usar o Skip e obter um fluxo fiável de receita extra que é socialmente aceite. O comportamento honesto (seguir as regras do protocolo) rende quase tanto ou mais lucro do que tentar enganar, porque se enganar, o seu bloco pode ser inválido ou pode ser punido socialmente, etc. A Governação desempenha um papel significativo: adotar o módulo do Skip ou definir os parâmetros (como a percentagem do leilão, a distribuição dos lucros) é feito através de propostas on-chain. Isto significa que os resultados económicos (quem fica com o MEV) são, em última análise, determinados pelo voto da comunidade. Por exemplo, o Cosmos Hub está a debater a adoção do SDK de construtor do Skip para possivelmente redirecionar o MEV para o tesouro ou para os stakers do Hub. Este alinhamento através da governação garante que o uso do MEV é visto como legítimo pela comunidade. Transforma o MEV de um subproduto tóxico num recurso público que pode ser alocado (para segurança, utilizadores, desenvolvedores, etc.). Em resumo, o Skip remodela os incentivos de tal forma que os validadores coletivamente e os utilizadores/comunidade beneficiam, enquanto os aproveitadores de MEV oportunistas são ou cooptados para o sistema (como licitantes) ou eliminados pelo design. Todos ficam melhor em teoria: os utilizadores perdem menos valor para o MEV, os validadores ainda são compensados (possivelmente até mais no total, devido aos leilões), e a rede como um todo pode usar o MEV para se fortalecer (financeiramente ou através de uma experiência mais justa). Os únicos perdedores são aqueles que prosperaram na extração de soma zero sem devolver valor.

• Compatibilidade de Conformidade e Regulamentação: A estrutura do Skip, ao capacitar a governação da chain, na verdade torna mais fácil para as chains garantirem a conformidade ou políticas específicas, se assim o desejarem. Como o Skip opera ao nível do protocolo, uma chain pode optar por impor certas regras de filtragem ou ordenação de transações para cumprir com as regulamentações. Por exemplo, se uma chain quisesse bloquear endereços sancionados, poderia integrar uma regra AnteHandler ou AuctionDecorator no módulo do Skip que invalida blocos que contenham endereços na lista negra. Isto é, sem dúvida, mais simples do que no Ethereum, onde a censura é uma escolha off-chain de validadores individuais; no Cosmos com o Skip, poderia ser uma regra para toda a chain (embora fosse controversa e contra os ideais de descentralização para muitos). Alternativamente, uma chain poderia impor algo como “transações de on-ramp FIAT devem aparecer antes de outras” se mandatado por alguma lei. O kit de ferramentas do Skip não vem com regras de conformidade predefinidas, mas é flexível o suficiente para implementá-las se uma comunidade for compelida a fazê-lo (através da governação). Por outro lado, o Skip pode reforçar a resistência à censura: ao distribuir a receita de MEV e dar acesso igual, reduz a vantagem de qualquer validador único que possa censurar para obter lucro. Adicionalmente, se os mempools com encriptação de limiar (como o que a Osmosis está a adicionar) se tornarem padrão com o Skip, isso ocultará o conteúdo das transações, tornando a censura mais difícil (como na Anoma). O Skip é uma infraestrutura neutra – pode ser usado para cumprir ou resistir, dependendo da governação. Como as chains do Cosmos são frequentemente específicas de uma jurisdição (a comunidade da Terra pode preocupar-se com as leis coreanas, a Kava pode preocupar-se com as leis dos EUA, etc.), ter a opção de configurar a conformidade é valioso. Por exemplo, uma chain do Cosmos permissionada (como uma chain institucional) ainda poderia usar o módulo de construtor do Skip, mas talvez exigir que apenas endereços na lista branca possam licitar em leilões, etc., alinhando-se com as suas regulamentações. A compatibilidade regulatória também se prende com a transparência: os leilões on-chain do Skip produzem um registo público de transações de MEV e quem pagou o quê. Isto poderia, na verdade, satisfazer algumas preocupações regulatórias sobre justiça (todos tiveram a oportunidade de licitar, e é auditável). É mais transparente do que pagamentos por baixo da mesa a validadores. Além disso, ao capturar o MEV on-chain, o Skip reduz a probabilidade de cartéis off-chain ou dark pools, que os reguladores temem devido à opacidade. Por exemplo, sem o Skip, os validadores podem fazer acordos privados com searchers (como se viu com os problemas de censura dos relays). Com o Skip, a expectativa é que se use o leilão oficial – que é aberto e registado – para obter prioridade. Isto fomenta um mercado aberto acessível a todos os bots igualmente, o que é, sem dúvida, mais justo e menos propenso a conluio (o conluio é possível, mas existe supervisão da governação). Outro ângulo de conformidade: como o Skip lida com a captura de valor, se a receita de MEV for para um pool comunitário ou tesouro, isso pode levantar questões (é uma taxa, é tributável, etc.?). Mas estas são semelhantes a como as taxas de transação são tratadas, pelo que nada de fundamentalmente novo legalmente. No Cosmos, as comunidades das chains também podem decidir como usar esse fundo (queimar, distribuir, etc.), o que podem alinhar com qualquer orientação legal, se necessário (por exemplo, podem evitar enviá-lo para uma fundação se isso desencadear questões fiscais e, em vez disso, queimá-lo). Em termos de resistência à censura, uma nota interessante: ao impor regras de validade de bloco, o Skip impede que os validadores censurem certas transações se isso violar as regras. Por exemplo, se uma chain tivesse uma regra “deve incluir pelo menos uma atualização de oráculo”, um validador censor não poderia simplesmente omitir todas as transações de oráculo (que podem vir de certas fontes) porque o seu bloco seria inválido. Assim, ironicamente, as regras do Skip podem forçar a inclusão de transações críticas (anti-censura) da mesma forma que poderiam ser usadas para forçar a exclusão de transações não permitidas. Tudo depende do que a comunidade definir. Neutralidade: A postura padrão do Skip é capacitar as chains a “proteger os utilizadores de MEV negativo e melhorar a experiência do utilizador”, o que implica neutralidade e amigabilidade para com o utilizador. Não há uma rede central do Skip a tomar decisões – cada chain é soberana. O Skip como empresa pode aconselhar ou fornecer padrões (como um formato de leilão recomendado), mas, em última análise, os detentores de tokens da chain decidem. Esta descentralização da política de MEV para a governação de cada chain pode ser vista como mais compatível com a diversidade regulatória: por exemplo, uma chain baseada nos EUA poderia implementar a conformidade com a OFAC se pressionada legalmente, sem afetar outras chains. Não é um único relay a censurar em muitas chains; é uma escolha por chain. Do ponto de vista de um regulador, o Skip não introduz nenhuma atividade ilícita adicional – apenas reorganiza como as transações são ordenadas. Se alguma coisa, pode reduzir a volatilidade (menos guerras de gás) e criar uma execução mais previsível, o que pode ser uma vantagem. Resumindo, a arquitetura do Skip é altamente adaptável às necessidades de conformidade, preservando ao mesmo tempo a opção de máxima resistência à censura se as comunidades priorizarem isso. Mantém o MEV à luz do dia e sob controlo coletivo, o que provavelmente torna os ecossistemas de blockchain mais robustos contra atores maliciosos e repressões regulatórias, uma vez que a autogovernação pode abordar proativamente os piores abusos.

• Arquitetura Técnica e Implementação: O Skip Protocol está firmemente integrado na pilha do Cosmos SDK. A entrega principal é um conjunto de módulos (por exemplo, x/builder) e modificações como a implementação do mempool BlockBuster. As chains do Cosmos executam um consenso (Tendermint/CometBFT) que oferece hooks ABCI para preparar e processar propostas. O Skip aproveita as extensões ABCI++ que permitem executar código entre a proposta de bloco e a finalização. É assim que impõe a ordenação: o PrepareProposal pode reordenar as transações do bloco de acordo com as regras das lanes antes de transmitir a proposta, e o ProcessProposal nos validadores recetores pode verificar se a ordenação e a validade do estado correspondem às expectativas. Esta é uma funcionalidade moderna (Cosmos SDK v0.47+), e o POB do Skip é compatível com as versões recentes do SDK. Nos bastidores, os módulos do Skip mantêm estruturas de dados para leilões (por exemplo, um livro de ordens on-chain de lances para o topo do bloco). Eles também provavelmente usam tipos de transação prioritários. O README mostra um MsgAuctionBid especial e lógica personalizada para lidar com ele. Assim, os searchers interagem enviando estas mensagens através de transações normais do Cosmos, que o módulo depois interceta e coloca adequadamente. O AnteHandler do módulo de construtor (o AuctionDecorator) pode consumir lances de leilão e decidir os vencedores na fase de montagem do bloco. Criptograficamente, o Skip não adiciona inerentemente novos requisitos criptográficos (além do que a chain escolher, como criptografia de limiar para o mempool, que é separado). Depende da honestidade de >2/3 dos validadores para impor as regras e não conspirar para as quebrar. Se uma maioria conspirasse, eles poderiam tecnicamente mudar as regras através da governação ou ignorá-las, tornando essa a nova regra de facto. Mas isso acontece com qualquer lógica de chain. O design do Skip tenta tornar mecanicamente impossível que um único validador engane em pequena escala. Por exemplo, qualquer tentativa de desviar a ordenação será apanhada por outros porque é objetiva. Assim, reduz a confiança em proponentes individuais. Em termos de desempenho, executar leilões e verificações extras adiciona sobrecarga. No entanto, os blocos do Cosmos são relativamente pequenos e o tempo entre blocos é muitas vezes de alguns segundos, o que é suficiente para estas operações na maioria dos casos. A simulação (pré-execução de transações para garantir que não há falhas e que as restrições de ordenação são cumpridas) pode ser a parte mais pesada, mas os validadores já fazem a execução de blocos normalmente, pelo que isto é semelhante. A presença de múltiplas lanes significa separação do mempool: por exemplo, uma transação pode precisar de especificar qual a lane que está a visar (leilão vs. gratuita vs. padrão). O design do BlockBuster do Skip tinha de facto lanes separadas como lanes/auction, lanes/free, etc., provavelmente filas de mempool separadas. Isso garante, por exemplo, que as transações gratuitas não atrasem ou interfiram com as de leilão. É um pouco como ter várias classes de prioridade no agendamento. Outro aspeto é a segurança e o mau comportamento: Se um proponente tentar manipular o leilão (por exemplo, incluir a sua própria transação, mas alegar que seguiu as regras), outros validadores rejeitarão o bloco. O consenso do Cosmos provavelmente passará para o próximo proponente, punindo o anterior por assinatura dupla ou simplesmente por falhar (dependendo do cenário). Assim, o modelo de segurança da chain lida com isso – não é necessário um slashing especial pelo Skip para além do consenso existente. Poder-se-ia estender o Skip para punir por ordenação maliciosa, mas provavelmente é desnecessário se o bloco simplesmente falhar. Desenvolvimento e Ferramentas: O código do Skip foi tornado de código aberto (inicialmente em skip-mev/pob e agora provavelmente movido para um novo repositório após os lançamentos estáveis). Eles passaram por testnets e iterações com chains parceiras. No roteiro, vimos: Proposta 341 da Osmosis (aprovada no outono de 2022) para integrar o ProtoRev e leilões com o Skip – entregue no início de 2023. A Astroport da Terra integrou a partilha de MEV com o Skip em 2023. O Cosmos Hub está a avaliar o “Block SDK” do Skip, que traria funcionalidades semelhantes para o Hub. Outra fronteira interessante é o MEV inter-chain através do Interchain Scheduler – a comunidade do Cosmos Hub está a explorar um leilão de MEV inter-chain onde o MEV de muitas chains poderia ser negociado no Hub, e o Skip está envolvido nessas discussões (a pesquisa da Zerocap notou o planeado interchain scheduler do IBC). A tecnologia do Skip poderia servir como a espinha dorsal para tais leilões inter-chain porque já está a fazer leilões em chains individuais. Isso seria análogo ao objetivo interdomínio do SUAVE, mas dentro do Cosmos. Quanto às atualizações chave: o Skip foi lançado em meados de 2022. Em meados de 2023, eles tinham um lançamento estável do POB para o SDK v0.47+ (que muitas chains estão a atualizar). Eles também levantaram financiamento inicial, indicando desenvolvimento ativo. Outro concorrente no Cosmos, a Mekatek, oferece funcionalidade semelhante. Isto talvez tenha acelerado o roteiro do Skip para se manter à frente. O Skip continua a refinar funcionalidades como lanes de transações privadas (talvez para ocultar a sua transação até ser incluída) e regras de validade mais complexas à medida que surgem casos de uso. Por ser modular, uma chain como a dYdX (que terá um livro de ordens) pode usar o Skip para garantir a justiça na correspondência de ordens on-chain, etc., pelo que as ferramentas do Skip podem adaptar-se a diferentes lógicas de aplicação. Tecnicamente, a solução do Skip é mais simples do que construir uma chain totalmente nova: é atualizar as capacidades das chains existentes. Esta abordagem incremental e opt-in permitiu uma adoção bastante rápida – por exemplo, habilitar leilões na Osmosis não exigiu um novo algoritmo de consenso, apenas adicionar um módulo e coordenar os validadores para executarem o software atualizado (o que eles fizeram, uma vez que era benéfico e foi aprovado pela governação). Em resumo, a arquitetura do Skip está embutida no software de nó de cada chain, personalizando o mempool e o pipeline de proposta de bloco. É uma abordagem de engenharia pragmática para a ordenação justa: usar o que já existe (Tendermint BFT), adicionar lógica para o guiar. O trabalho pesado (como encontrar arbitragens) pode até ser feito pelo próprio módulo da chain (o ProtoRev usa o código Wasm e Rust embutido da Osmosis para analisar os pools). Assim, grande parte do manuseamento do MEV passa a ser on-chain. Esta abordagem on-chain tem de ser cuidadosamente codificada para eficiência e segurança, mas está sob o escrutínio da comunidade. Se alguma regra for problemática (demasiado rigorosa, etc.), a governação pode ajustá-la. Assim, técnica e socialmente, o Skip transforma o MEV em apenas mais um parâmetro da chain a ser otimizado e governado, em vez de um faroeste. Esta é uma postura única possibilitada pela flexibilidade do Cosmos.

Análise Comparativa de SUAVE, Anoma, Skip e Flashbots v2​

Estes quatro protocolos abordam o problema do MEV e da ordenação justa de diferentes ângulos, adaptados aos seus respetivos ecossistemas e filosofias de design. O Flashbots v2 é uma solução incremental e pragmática para a arquitetura atual do Ethereum: abraça os leilões de MEV, mas tenta democratizar e suavizar o seu impacto (através de coordenação off-chain, privacidade SGX e mecanismos de partilha). O SUAVE é o plano futuro da Flashbots para criar uma plataforma de MEV inter-chain que maximiza o valor total e os benefícios para o utilizador – essencialmente, escalando o modelo de leilão para uma rede global descentralizada e que preserva a privacidade. A Anoma é uma reimaginação completa de como as transações são formuladas e executadas, com o objetivo de eliminar as causas profundas da ordenação injusta, usando intenções, correspondência mediada por solvers e justiça criptográfica no consenso. O Skip é uma abordagem de chain soberana, integrando a justiça e a captura de MEV ao nível do protocolo numa base por chain, especialmente no Cosmos, através de regras e leilões configuráveis.

Cada um tem pontos fortes e trade-offs:

• Justiça e Garantias de Ordenação: A Anoma oferece a justiça teórica mais forte (sem front-running por design, lotes encriptados), mas requer um novo paradigma e tecnologia complexa que ainda está a ser provada. O Skip pode impor regras de justiça concretas em chains existentes (impedindo front-runs ou impondo primeiro a entrar, primeiro a sair dentro das lanes), mas está limitado ao que cada comunidade escolhe impor. O SUAVE e o Flashbots v2 melhoram a justiça em termos de acesso (leilões abertos em vez de acordos secretos, proteção contra sniping no mempool público), mas não impedem inerentemente a execução de uma estratégia de MEV determinada – apenas garantem que ela paga aos utilizadores ou é feita de forma neutra.
• Redistribuição de MEV: O SUAVE e o Flashbots visam explicitamente devolver o MEV aos utilizadores/validadores: o SUAVE através de lances/reembolsos dos utilizadores, o Flashbots através de competições de construtores e reembolsos. O Skip pode canalizar o MEV para os utilizadores (conforme configurado, por exemplo, no caso da Astroport) ou para fundos comunitários. A Anoma evita a redistribuição explícita porque o objetivo é evitar a extração em primeiro lugar – idealmente, os utilizadores apenas obtêm preços justos, o que é equivalente a não perder valor para o MEV.
• Âmbito (Domínio Único vs. Múltiplo): O Flashbots v2 e o Skip focam-se nos seus próprios domínios (Ethereum e chains individuais do Cosmos, respetivamente). O SUAVE é inerentemente multi-domínio – vê o MEV inter-chain como uma motivação principal. A Anoma também considera eventualmente intenções multi-chain, mas nas fases iniciais pode ser dentro de uma instância fractal de cada vez, e depois ligando-se através de adaptadores. O leilão inter-chain do SUAVE poderia desbloquear arbitragem e coordenação que outros não conseguem fazer tão facilmente (exceto talvez um Interchain Scheduler com a ajuda do Skip no Cosmos).
• Complexidade e Adoção: O Flashbots v2 foi relativamente fácil de adotar (um sidecar de cliente) e rapidamente capturou a maioria dos blocos do Ethereum. O Skip também aproveita a tecnologia existente e está a ver adoção no Cosmos com propostas de governação diretas. O SUAVE e a Anoma são mais revolucionários – requerem novas redes ou grandes mudanças. O desafio do SUAVE será conseguir que muitas chains e utilizadores adiram a uma nova camada; o desafio da Anoma é criar um novo ecossistema e convencer os desenvolvedores a construir num modelo centrado em intenções.
• Conformidade e Neutralidade: Todos os quatro oferecem melhorias na transparência. O Flashbots v2/SUAVE removem elementos da floresta escura, mas tiveram de gerir questões de censura – o SUAVE está a ser explicitamente construído para evitar esses pontos centrais. A Anoma, com privacidade por defeito, protege ao máximo os utilizadores (mas pode preocupar os reguladores devido à atividade encriptada). O modelo do Skip dá a cada chain autonomia para encontrar um equilíbrio de conformidade. Se um regulador exigisse “sem leilões de MEV” ou “sem privacidade”, um Ethereum a usar o Flashbots poderia enfrentar um conflito, enquanto uma chain do Cosmos a usar o Skip poderia simplesmente não implementar essas funcionalidades ou ajustá-las. Em termos de neutralidade: o SUAVE e a Anoma visam a neutralidade credível (todos acedem a um sistema em termos iguais; ambos são essencialmente redes de bens públicos). O Flashbots v2 é neutro ao oferecer acesso aberto, mas existe alguma centralização no mercado de construtores (embora mitigada pelos esforços do buildernet). A neutralidade do Skip depende da governação – idealmente, faz com que o MEV não favoreça nenhum insider único, mas poder-se-ia configurá-lo mal e prejudicar a neutralidade (embora improvável, pois exigiria consenso da governação para o fazer).
• Diferenças de Arquitetura Técnica: O Flashbots v2 e o SUAVE são mercados off-chain em camadas sobre a chain: introduzem papéis especializados (construtores, relays, executores) e usam hardware ou criptografia para os proteger. A Anoma e o Skip integram-se diretamente no consenso ou na máquina de estados. A Anoma altera o ciclo de vida da transação e o próprio consenso (com encriptação de limiar e intenções unificadas). O Skip liga-se ao consenso do Tendermint através do ABCI++, mas não muda o algoritmo fundamental – é um ajuste na camada de aplicação. Esta diferença significa que o SUAVE/Flashbots podem teoricamente servir muitas chains sem que cada chain precise de ser atualizada (eles correm em paralelo a elas), enquanto a Anoma/Skip exigem que cada chain ou instância use o novo software. O SUAVE está um pouco no meio: é uma chain separada, mas para usá-la eficazmente, outras chains precisam de pequenos ajustes (para aceitar blocos construídos pelo SUAVE ou enviar saídas para o SUAVE). A sofisticação criptográfica é mais alta na Anoma (ZK, MPC, criptografia de limiar, tudo num só), moderada no SUAVE (criptografia de limiar e SGX, mais criptografia normal para pontes), e relativamente baixa no Flashbots v2 (SGX, assinaturas padrão) e no Skip (principalmente assinaturas padrão, mais o que a chain usar, como decriptação de limiar, se optar por isso).
• Estágio de Desenvolvimento: O Flashbots v2 está em produção no Ethereum (desde setembro de 2022). O Skip está em produção em várias chains do Cosmos (a partir de 2022–2023). O SUAVE está na fase de testnet/devnet com partes a serem lançadas (alguma funcionalidade de leilão em teste, testnet Toliman ao vivo). A Anoma também está na fase de testnet (um vision paper, implementações parciais como a mainnet da Namada, e provavelmente uma testnet da Anoma a exigir códigos de convite em 2023). Assim, em termos de dados do mundo real: o Flashbots v2 e o Skip demonstraram resultados (por exemplo, o Flashbots v2 entregou milhões a validadores e baixou os preços médios do gás durante períodos de alto MEV; o ProtoRev do Skip gerou fundos significativos para a comunidade Osmosis e preveniu muitos ataques sanduíche quando a encriptação de limiar começou). O SUAVE e a Anoma são promissores, mas têm de se provar operacional e economicamente.

Para cristalizar estas comparações, a tabela abaixo resume os aspetos chave de cada protocolo lado a lado:

Cada solução visa o problema do MEV de uma camada diferente – o Flashbots v2 funciona em torno do consenso L1, o SUAVE propõe uma nova camada L1.5, a Anoma redesenha a própria L1, e o Skip aproveita a personalização modular da L1. Na prática, estas abordagens não são mutuamente exclusivas e podem até complementar-se (por exemplo, uma chain do Cosmos pode usar o Skip internamente e também enviar intenções para o SUAVE para MEV inter-chain, ou o Ethereum pode implementar alguma justiça na ordem semelhante à da Anoma no futuro, enquanto ainda usa o Flashbots para mercados de construtores). A tabela ilustra as suas propriedades comparativas: o Flashbots v2 já está a proporcionar melhorias no Ethereum, mas ainda extrai MEV (apenas de forma mais equitativa e eficiente); o SUAVE visa um resultado de sinergia máxima onde todos cooperam através de uma rede – o seu sucesso dependerá da ampla adoção e da entrega técnica da privacidade e descentralização prometidas; a Anoma oferece talvez a repressão de MEV mais poderosa ao mudar completamente o funcionamento das transações, mas enfrenta o grande desafio de iniciar um novo ecossistema e provar o seu protocolo complexo; o Skip atinge um equilíbrio pragmático para o Cosmos, permitindo que as comunidades governem ativamente o MEV e a justiça nos seus próprios termos – é menos radical que a Anoma, mas mais integrado que o Flashbots, e já está a mostrar resultados tangíveis no Cosmos.

Conclusão e Perspetivas​

A supressão de MEV e a ordenação justa continuam a ser um dos “Problemas do Prémio Millennium da cripto”. Os quatro protocolos analisados – Flashbots v2, SUAVE, Anoma e Skip – representam um espectro de soluções: desde mitigações imediatas em estruturas existentes até mudanças de paradigma totais no processamento de transações. O Flashbots v2 demonstrou o poder dos mercados de MEV abertos para reduzir o caos e redistribuir valor, embora navegando por trade-offs como a censura, que estão a ser abordados através da descentralização. Mostra que mudanças incrementais (como leilões PBS e mempools privados) podem reduzir significativamente a dor do MEV a curto prazo. O SUAVE, o próximo passo da Flashbots, leva esse ethos adiante para uma arena unificada inter-chain – se tiver sucesso, poderemos ver um futuro onde os utilizadores são rotineiramente pagos pelo MEV que as suas trocas criam e onde a produção de blocos em muitas redes é colaborativa e encriptada para justiça. A Anoma aponta para uma evolução mais fundamental: ao remover o conceito de transações prioritárias e substituí-lo por um sistema de correspondência de intenções, poderia eliminar classes inteiras de MEV e desbloquear dApps financeiras mais expressivas. A sua ordenação justa na camada de consenso (via encriptação de limiar e leilões em lote) é um vislumbre de como as próprias blockchains podem fornecer garantias de justiça, não apenas complementos off-chain. O Skip Protocol, entretanto, exemplifica um meio-termo num contexto multi-chain – dá às chains individuais a agência para decidir como equilibrar a receita de MEV e a proteção do utilizador. A sua adoção precoce no Cosmos mostra que muitos dos efeitos nefastos do MEV podem ser combatidos hoje com engenharia de protocolo ponderada e consentimento da comunidade.

No futuro, podemos esperar uma polinização cruzada de ideias: os investigadores do Ethereum estão a estudar o consenso de ordem justa e a encriptação de limiar (inspirados por projetos como a Anoma e o mempool encriptado da Osmo) para potencial inclusão em soluções L1 ou L2. O SUAVE da Flashbots pode interagir com as chains do Cosmos (talvez até através do Skip), uma vez que procura ser agnóstico em relação à chain. O conceito de intenção da Anoma pode influenciar o design de aplicações mesmo em plataformas tradicionais (por exemplo, a CoW Swap no Ethereum já usa um modelo de solver; pode-se vê-la como uma dApp “semelhante à Anoma”). O sucesso do Skip pode encorajar outros ecossistemas (Polkadot, Solana, etc.) a adotar controlos de MEV no protocolo semelhantes. Um tema chave é o alinhamento económico – todos estes protocolos esforçam-se por alinhar os incentivos daqueles que protegem a rede com o bem-estar dos utilizadores, para que explorar os utilizadores não seja lucrativo ou não seja possível. Isto é crucial para a saúde a longo prazo dos ecossistemas de blockchain e para evitar a centralização.

Em resumo, SUAVE, Anoma, Skip e Flashbots v2 contribuem cada um com peças do quebra-cabeça para a ordenação justa e a mitigação de MEV. O Flashbots v2 estabeleceu um modelo para leilões de MEV que outros emulam, o Skip provou que a imposição on-chain é viável, a Anoma expandiu a imaginação do que é possível ao reconstruir o modelo de transação, e o SUAVE procura unificar e descentralizar os ganhos dos últimos anos. A solução final pode envolver elementos de todos: leilões globais que preservam a privacidade, interfaces de utilizador centradas em intenções, regras de justiça ao nível da chain e construção de blocos colaborativa. A partir de 2025, a luta contra a injustiça induzida pelo MEV está bem encaminhada – estes protocolos estão a transformar o MEV de uma inevitabilidade sombria numa parte gerida, e até produtiva, da economia cripto, enquanto se aproximam cada vez mais do ideal de “a melhor execução para os utilizadores com a infraestrutura mais descentralizada”.

Aqui está um resumo consolidado do relatório sobre inovações na Experiência de Desenvolvedor Web3 (DevEx).

Resumo Executivo​

A experiência de desenvolvedor Web3 avançou significativamente em 2024‑2025, impulsionada por inovações em linguagens de programação, cadeias de ferramentas e infraestrutura de implantação. Os desenvolvedores relatam maior produtividade e satisfação graças a ferramentas mais rápidas, linguagens mais seguras e fluxos de trabalho simplificados. Este resumo consolida descobertas sobre cinco cadeias de ferramentas principais (Solidity, Move, Sway, Foundry e Cairo 1.0) e duas tendências importantes: implantação de rollup com “um clique” e recarregamento a quente de contratos inteligentes.

Comparação das Cadeias de Ferramentas para Desenvolvedores Web3​

Cada cadeia de ferramentas oferece vantagens distintas, atendendo a diferentes ecossistemas e filosofias de desenvolvimento.

• Solidity (EVM): Continua sendo a linguagem mais dominante devido ao seu enorme ecossistema, bibliotecas extensas (por exemplo, OpenZeppelin) e frameworks maduros como Hardhat e Foundry. Embora não possua recursos nativos como macros, sua ampla adoção e forte suporte da comunidade a tornam a escolha padrão para Ethereum e a maioria das L2 compatíveis com EVM.
• Move (Aptos/Sui): Prioriza segurança e verificação formal. Seu modelo baseado em recursos e a ferramenta Move Prover ajudam a prevenir bugs comuns como reentrância por design. Isso a torna ideal para aplicações financeiras de alta segurança, embora seu ecossistema seja menor e esteja centrado nas blockchains Aptos e Sui.
• Sway (FuelVM): Projetada para máxima produtividade do desenvolvedor, permitindo que desenvolvedores escrevam contratos, scripts e testes em uma única linguagem semelhante ao Rust. Ela aproveita a arquitetura de alta taxa de transferência e baseada em UTXO da Fuel Virtual Machine, tornando‑se uma escolha poderosa para aplicações intensivas em desempenho na rede Fuel.
• Foundry (Toolkit EVM): Um kit de ferramentas transformador para Solidity que revolucionou o desenvolvimento EVM. Oferece compilação e testes extremamente rápidos, permitindo que desenvolvedores escrevam testes diretamente em Solidity. Recursos como fuzz testing, fork da mainnet e “cheatcodes” fizeram dele a escolha principal para mais da metade dos desenvolvedores Ethereum.
• Cairo 1.0 (Starknet): Representa uma grande melhoria na DevEx para o ecossistema Starknet. A transição para uma sintaxe de alto nível inspirada em Rust e ferramentas modernas (como o gerenciador de pacotes Scarb e o Starknet Foundry) tornou o desenvolvimento para ZK‑rollups significativamente mais rápido e intuitivo. Embora algumas ferramentas, como depuradores, ainda estejam amadurecendo, a satisfação dos desenvolvedores disparou.

Inovações-Chave na DevEx​

Duas tendências principais estão mudando a forma como os desenvolvedores constroem e implantam aplicações descentralizadas.

Implantação de Rollup com “Um Clique”​

Lançar uma blockchain personalizada (L2/appchain) tornou‑se radicalmente mais simples.

• Fundação: Frameworks como o OP Stack da Optimism fornecem um modelo modular e de código aberto para construir rollups.
• Plataformas: Serviços como Caldera e Conduit criaram plataformas Rollup‑as‑a‑Service (RaaS). Eles oferecem painéis web que permitem aos desenvolvedores implantar um rollup mainnet ou testnet customizado em minutos, com expertise mínima em engenharia de blockchain.
• Impacto: Isso possibilita experimentação rápida, reduz a barreira para criar cadeias específicas de aplicativos e simplifica o DevOps, permitindo que as equipes foquem em sua aplicação em vez da infraestrutura.

Recarregamento a Quente de Contratos Inteligentes​

Esta inovação traz o ciclo de feedback instantâneo do desenvolvimento web moderno para o espaço blockchain.

• Conceito: Ferramentas como Scaffold‑ETH 2 automatizam o ciclo de desenvolvimento. Quando um desenvolvedor salva uma alteração em um contrato inteligente, a ferramenta recompila automaticamente, reimplanta em uma rede local e atualiza o front‑end para refletir a nova lógica.
• Impacto: O recarregamento a quente elimina etapas manuais repetitivas e encurta drasticamente o loop de iteração. Isso torna o processo de desenvolvimento mais envolvente, diminui a curva de aprendizado para novos desenvolvedores e incentiva testes frequentes, resultando em código de maior qualidade.

Conclusão​

O panorama de desenvolvimento Web3 está amadurecendo a um ritmo acelerado. A convergência de linguagens mais seguras, ferramentas mais rápidas como Foundry e implantação simplificada de infraestrutura via plataformas RaaS está reduzindo a lacuna entre blockchain e desenvolvimento de software tradicional. Essas melhorias na DevEx são tão críticas quanto inovações em nível de protocolo, pois capacitam desenvolvedores a criar aplicações mais complexas e seguras mais rapidamente. Isso, por sua vez, impulsiona o crescimento e a adoção de todo o ecossistema blockchain.

Fontes:

• Solidity Developer Survey 2024 – Soliditylang (2025)
• Moncayo Labs on Aptos Move vs Solidity (2024)
• Aptos Move Prover intro – Monethic (2025)
• Fuel Labs – Fuel & Sway Documentation (2024); Fuel Book (2024)
• Spearmanrigoberto – Foundry vs Hardhat (2023)
• Medium (Rosario Borgesi) – Building Dapps with Scaffold‑ETH 2 (2024)
• Starknet/Cairo developer survey – Cairo‑lang.org (2024)
• Starknet Dev Updates – Starknet.io (2024–2025)
• Solidity forum – Macro preprocessor discussion (2023)
• Optimism OP Stack overview – CoinDesk (2025)
• Caldera rollup platform overview – Medium (2024)
• Conduit platform recap – Conduit Blog (2025)
• Blockchain DevEx literature review – arXiv (2025)

Introdução​

O rápido crescimento das blockchains de Camada 1 (Layer-1) e Camada 2 (Layer-2) fragmentou a experiência do utilizador Web3. Atualmente, os utilizadores gerem múltiplas carteiras, redes e pontes de tokens apenas para realizar tarefas complexas que abrangem várias chains. A abstração de chain e a arquitetura centrada em intenção surgiram como paradigmas chave para simplificar este cenário. Ao abstrair detalhes específicos da chain e permitir que os utilizadores ajam com base em intenções (resultados desejados) em vez de criar transações explícitas por chain, estas abordagens prometem uma experiência cross-chain unificada e fluida. Este relatório aprofunda os princípios fundamentais da abstração de chain, o design de modelos de execução focados em intenção, implementações do mundo real (como Wormhole e Etherspot), os fundamentos técnicos (relayers, smart wallets, etc.) e os benefícios de UX para programadores e utilizadores finais. Também resumimos insights da EthCC 2025 – onde a abstração de chain e as intenções foram tópicos em destaque – e fornecemos uma tabela comparativa de diferentes abordagens de protocolo.

Princípios da Abstração de Chain​

A abstração de chain refere-se a qualquer tecnologia ou framework que apresenta múltiplas blockchains a utilizadores e programadores como se fossem um único ambiente unificado. A motivação é eliminar a fricção causada pela heterogeneidade das chains. Na prática, a abstração de chain significa:

• Interfaces Unificadas: Em vez de gerir carteiras e endpoints RPC separados para cada blockchain, os utilizadores interagem através de uma única interface que oculta os detalhes da rede. Os programadores podem construir dApps sem implementar contratos separados em cada chain ou escrever lógica de ponte personalizada para cada rede.
• Sem Bridging Manual: A movimentação de ativos ou dados entre chains acontece nos bastidores. Os utilizadores não executam manualmente transações de ponte do tipo lock/mint nem trocam por tokens de ponte; a camada de abstração trata disso automaticamente. Por exemplo, um utilizador poderia fornecer liquidez num protocolo, independentemente da chain em que a liquidez reside, e o sistema encaminharia os fundos adequadamente.
• Abstração de Taxas de Gás: Os utilizadores já não precisam de deter o token nativo de cada chain para pagar o gás nessa chain. A camada de abstração pode patrocinar as taxas de gás ou permitir que o gás seja pago num ativo à escolha do utilizador. Isto reduz a barreira de entrada, uma vez que não é necessário adquirir ETH, MATIC, SOL, etc., separadamente.
• Lógica Agnóstica à Rede: A lógica da aplicação torna-se agnóstica à chain. Contratos inteligentes ou serviços off-chain coordenam-se para executar as ações do utilizador em qualquer chain necessária, sem exigir que o utilizador mude manualmente de rede ou assine múltiplas transações. Em essência, a experiência do utilizador é de uma “meta-chain” ou de uma camada de aplicação agnóstica à blockchain.

A ideia central é permitir que os utilizadores se concentrem no que querem alcançar, e não em qual chain ou como o alcançar. Uma analogia familiar são as aplicações web que abstraem a localização do servidor – tal como um utilizador não precisa de saber em que servidor ou base de dados o seu pedido toca, um utilizador Web3 não deveria precisar de saber que chain ou ponte é usada para uma ação. Ao encaminhar transações através de uma camada unificada, a abstração de chain reduz a fragmentação do ecossistema multi-chain atual.

Motivação: O impulso para a abstração de chain surge dos pontos de dor nos fluxos de trabalho cross-chain atuais. Gerir carteiras separadas por chain e realizar operações cross-chain de múltiplos passos (trocar na Chain A, fazer ponte para a Chain B, trocar novamente na Chain B, etc.) é tedioso e propenso a erros. A liquidez fragmentada e as carteiras incompatíveis também limitam o crescimento das dApps entre ecossistemas. A abstração de chain aborda estes problemas ao ligar de forma coesa os ecossistemas. É importante notar que trata o Ethereum e as suas muitas L2s e sidechains como parte de uma única experiência de utilizador. A EthCC 2025 enfatizou que isto é crítico para a adoção em massa – os oradores argumentaram que um futuro Web3 verdadeiramente centrado no utilizador “deve abstrair as blockchains”, fazendo com que o mundo multi-chain pareça tão fácil como uma única rede.

Arquitetura Centrada em Intenção: De Transações a Intenções​

As interações tradicionais de blockchain são centradas em transações: um utilizador cria e assina explicitamente uma transação que executa operações específicas (chama uma função de contrato, transfere um token, etc.) numa chain escolhida. Num contexto multi-chain, alcançar um objetivo complexo pode exigir muitas dessas transações em diferentes redes, cada uma iniciada manualmente pelo utilizador na sequência correta. A arquitetura centrada em intenção inverte este modelo. Em vez de microgerir transações, o utilizador declara uma intenção – um objetivo de alto nível ou resultado desejado – e deixa um sistema automatizado descobrir as transações necessárias para a cumprir.

Sob um design baseado em intenção, um utilizador pode dizer: “Trocar 100 USDC na Base por 100 USDT na Arbitrum”. Esta intenção encapsula o o quê (trocar um ativo por outro numa chain de destino) sem prescrever o como. Um agente especializado (frequentemente chamado de solver) assume então a tarefa de a completar. O solver determinará como executar melhor a troca entre chains – por exemplo, pode fazer a ponte do USDC da Base para a Arbitrum usando uma ponte rápida e depois realizar uma troca para USDT, ou usar um protocolo de troca cross-chain direto – o que quer que produza o melhor resultado. O utilizador assina uma única autorização, e o solver trata da sequência complexa nos bastidores, incluindo encontrar a rota ótima, submeter as transações necessárias em cada chain, e até adiantar quaisquer taxas de gás necessárias ou assumir riscos intermédios.

Como as Intenções Potenciam a Execução Flexível: Ao dar ao sistema a liberdade de decidir como cumprir um pedido, o design centrado em intenção permite camadas de execução muito mais inteligentes e flexíveis do que as transações fixas do utilizador. Algumas vantagens:

• Encaminhamento Ótimo: Os solvers podem otimizar por custo, velocidade ou fiabilidade. Por exemplo, múltiplos solvers podem competir para cumprir a intenção de um utilizador, e um leilão on-chain pode selecionar aquele que oferece o melhor preço (ex: a melhor taxa de câmbio ou as taxas mais baixas). Esta competição reduz os custos para o utilizador. O protocolo Mayan Swift da Wormhole é um exemplo que incorpora um leilão inglês on-chain na Solana para cada intenção, mudando a competição de uma corrida de “primeiro a chegar” para uma licitação baseada em preço para melhores resultados para o utilizador. O solver que consegue executar a troca de forma mais lucrativa para o utilizador ganha a licitação e executa o plano, garantindo que o utilizador obtém o máximo valor. Este tipo de descoberta de preço dinâmica não é possível quando um utilizador pré-especifica um único caminho numa transação regular.
• Resiliência e Flexibilidade: Se uma ponte ou DEX estiver indisponível ou subótima no momento, um solver pode escolher um caminho alternativo. A intenção permanece a mesma, mas a camada de execução pode adaptar-se às condições da rede. As intenções permitem, assim, estratégias de execução programável – por exemplo, dividir uma ordem ou tentar novamente por outra rota – tudo invisível para o utilizador final, que apenas se preocupa com o facto de o seu objetivo ser alcançado.
• Ações Multi-Chain Atómicas: As intenções podem abranger o que tradicionalmente seriam múltiplas transações em diferentes chains. Os frameworks de execução esforçam-se para que toda a sequência pareça atómica ou, pelo menos, gerida em caso de falha. Por exemplo, o solver pode considerar a intenção cumprida apenas quando todas as sub-transações (ponte, troca, etc.) são confirmadas, e reverter ou compensar se algo falhar. Isto garante que a ação de alto nível do utilizador é completada na totalidade ou não é de todo, melhorando a fiabilidade.
• Descarregar a Complexidade: As intenções simplificam drasticamente o papel do utilizador. O utilizador não precisa de entender que pontes ou exchanges usar, como dividir a liquidez ou como agendar operações – tudo isso é descarregado para a infraestrutura. Como um relatório coloca, “os utilizadores focam-se no o quê, não no como”. Um benefício direto é a experiência do utilizador: interagir com aplicações blockchain torna-se mais parecido com usar uma aplicação Web2 (onde um utilizador simplesmente solicita um resultado, e o serviço trata do processo).

Em essência, uma arquitetura centrada em intenção eleva o nível de abstração de transações de baixo nível para objetivos de alto nível. A comunidade Ethereum está tão interessada neste modelo que a Ethereum Foundation introduziu o Open Intents Framework (OIF), um padrão aberto e arquitetura de referência para construir sistemas de intenção cross-chain. O OIF define interfaces padrão (como o formato de intenção ERC-7683) para como as intenções são criadas, comunicadas e liquidadas entre chains, para que muitas soluções diferentes (pontes, relayers, mecanismos de leilão) possam ser integradas de forma modular. Isto encoraja todo um ecossistema de solvers e protocolos de liquidação que podem interoperar. A ascensão das intenções está fundamentada na necessidade de fazer com que o Ethereum e os seus rollups pareçam “uma única chain” da perspetiva da UX – rápido e sem atritos o suficiente para que a movimentação entre L2s ou sidechains aconteça em segundos, sem dores de cabeça para o utilizador. Padrões iniciais como o ERC-7683 (para formato e ciclo de vida de intenção padronizados) até ganharam o apoio de líderes como Vitalik Buterin, sublinhando o ímpeto por trás dos designs centrados em intenção.

Resumo dos Benefícios Chave: Para resumir, as arquiteturas centradas em intenção trazem vários benefícios chave: (1) UX Simplificada – os utilizadores declaram o que querem e o sistema descobre o resto; (2) Fluidez Cross-Chain – operações que abrangem múltiplas redes são tratadas de forma transparente, tratando efetivamente muitas chains como uma só; (3) Escalabilidade para Programadores – os programadores de dApps podem alcançar utilizadores e liquidez em muitas chains sem reinventar a roda para cada uma, porque a camada de intenção fornece ganchos padronizados para a execução cross-chain. Ao dissociar o que precisa ser feito de como/onde é feito, as intenções atuam como a ponte entre a inovação amigável ao utilizador e a complexa interoperabilidade nos bastidores.

Blocos de Construção Técnicos da Abstração Cross-Chain​

Implementar a abstração de chain e a execução baseada em intenção requer uma pilha de mecanismos técnicos a trabalhar em conjunto. Os componentes chave incluem:

• Relayers de Mensagens Cross-Chain: No cerne de qualquer sistema multi-chain está uma camada de mensagens que pode transportar dados e valor de forma fiável entre blockchains. Protocolos como Wormhole, Hyperlane, Axelar, LayerZero, e outros fornecem esta capacidade ao retransmitir mensagens (muitas vezes com provas ou atestados de validadores) de uma chain de origem para uma ou mais chains de destino. Estas mensagens podem transportar comandos como “executar esta intenção” ou “cunhar este ativo” na chain de destino. Uma rede de relayers robusta é crucial para o encaminhamento unificado de transações – serve como o “serviço postal” entre chains. Por exemplo, a rede de 19 nós Guardian da Wormhole observa eventos nas chains conectadas e assina um VAA (verifiable action approval) que pode ser submetido a qualquer outra chain para provar que um evento ocorreu. Isto dissocia a ação de qualquer chain única, permitindo um comportamento agnóstico à chain. Os relayers modernos focam-se em ser agnósticos à chain (suportando muitos tipos de chain) e descentralizados para segurança. A Wormhole, por exemplo, estende-se para além das chains baseadas em EVM para suportar Solana, chains Cosmos, etc., tornando-a uma escolha versátil para comunicação cross-chain. A camada de mensagens também lida frequentemente com a ordenação, tentativas e garantias de finalidade para transações cross-chain.

• Carteiras de Contrato Inteligente (Abstração de Conta): A abstração de conta (ex: ERC-4337 do Ethereum) substitui contas de propriedade externa por contas de contrato inteligente que podem ser programadas com lógica de validação personalizada e capacidades de transação de múltiplos passos. Isto é uma base para a abstração de chain porque uma smart wallet pode servir como a única meta-conta do utilizador, controlando ativos em todas as chains. Projetos como Etherspot usam carteiras de contrato inteligente para permitir funcionalidades como o agrupamento de transações e chaves de sessão entre chains. A intenção de um utilizador pode ser empacotada como uma única operação de utilizador (em termos do 4337) que o contrato da carteira expande depois em múltiplas sub-transações em diferentes redes. As smart wallets também podem integrar paymasters (patrocinadores) para pagar taxas de gás em nome do utilizador, permitindo uma verdadeira abstração de gás (o utilizador pode pagar numa stablecoin ou não pagar de todo). Mecanismos de segurança como chaves de sessão (chaves temporárias com permissões limitadas) permitem que os utilizadores aprovem intenções que envolvem múltiplas ações sem múltiplos pedidos, enquanto limitam o risco. Em suma, a abstração de conta fornece o contentor de execução programável que pode interpretar uma intenção de alto nível e orquestrar os passos necessários como uma série de transações (frequentemente através dos relayers).

• Orquestração de Intenções e Solvers: Acima da camada de mensagens e de carteira vive a rede de solvers de intenções – os cérebros que descobrem como cumprir as intenções. Em algumas arquiteturas, esta lógica é on-chain (ex: um contrato de leilão on-chain que combina ordens de intenção com solvers, como no leilão da Wormhole na Solana para o Mayan Swift). Noutras, são agentes off-chain a monitorizar um mempool de intenções ou um livro de ordens (por exemplo, o Open Intents Framework fornece um solver de referência em TypeScript que ouve novos eventos de intenção e depois submete transações para os cumprir). Os solvers normalmente têm de lidar com: encontrar rotas de liquidez (através de DEXes, pontes), descoberta de preço (garantindo que o utilizador obtém uma taxa justa), e por vezes cobrir custos intermédios (como colocar colateral ou assumir risco de finalidade – entregar fundos ao utilizador antes da transferência cross-chain estar totalmente finalizada, acelerando assim a UX com algum risco para o solver). Um sistema centrado em intenção bem desenhado envolve frequentemente competição entre solvers para garantir que a intenção do utilizador é executada de forma ótima. Os solvers podem ser incentivados economicamente (ex: ganham uma taxa ou lucro de arbitragem por cumprir a intenção). Mecanismos como leilões de solvers ou agrupamento podem ser usados para maximizar a eficiência. Por exemplo, se múltiplos utilizadores tiverem intenções semelhantes, um solver pode agrupá-las para minimizar as taxas de ponte por utilizador.

• Liquidez Unificada e Abstração de Tokens: Mover ativos entre chains introduz o problema clássico de liquidez fragmentada e tokens embrulhados. As camadas de abstração de chain frequentemente abstraem os próprios tokens – com o objetivo de dar ao utilizador a experiência de um único ativo que pode ser usado em muitas chains. Uma abordagem são os tokens omnichain (onde um token pode existir nativamente em múltiplas chains sob uma única oferta total, em vez de muitas versões embrulhadas incompatíveis). A Wormhole introduziu as Native Token Transfers (NTT) como uma evolução das pontes tradicionais de lock-and-mint: em vez de infinitos tokens IOU “ponteados”, o framework NTT trata os tokens implementados em várias chains como um único ativo com controlos de cunhagem/queima partilhados. Na prática, fazer a ponte de um ativo sob NTT significa queimar na origem e cunhar no destino, mantendo uma única oferta circulante. Este tipo de unificação de liquidez é crucial para que a abstração de chain possa “teleportar” ativos sem confundir o utilizador com múltiplas representações de tokens. Outros projetos usam redes ou pools de liquidez (ex: Connext ou Axelar) onde os fornecedores de liquidez fornecem capital em cada chain para trocar ativos, para que os utilizadores possam efetivamente trocar um ativo pelo seu equivalente noutra chain num único passo. O exemplo do fundo Securitize SCOPE é ilustrativo: um token de fundo institucional foi tornado multichain de modo que os investidores podem subscrever ou resgatar no Ethereum ou no Optimism, e nos bastidores o protocolo da Wormhole move o token e até o converte em formas que geram rendimento, removendo a necessidade de pontes manuais ou múltiplas carteiras para os utilizadores.

• Camadas de Execução Programáveis: Finalmente, certas inovações on-chain potenciam fluxos de trabalho cross-chain mais complexos. O suporte a multi-chamadas atómicas e o agendamento de transações ajudam a coordenar intenções de múltiplos passos. Por exemplo, os Programmable Transaction Blocks (PTBs) da blockchain Sui permitem agrupar múltiplas ações (como trocas, transferências, chamadas) numa única transação atómica. Isto pode simplificar o cumprimento de intenções cross-chain na Sui, garantindo que todos os passos acontecem ou nenhum acontece, com uma única assinatura do utilizador. No Ethereum, propostas como a EIP-7702 (código de contrato inteligente para EOAs) estendem as capacidades das contas de utilizador para suportar coisas como gás patrocinado e lógica de múltiplos passos mesmo na camada base. Além disso, ambientes de execução especializados ou routers cross-chain podem ser empregados – por exemplo, alguns sistemas encaminham todas as intenções através de uma L2 ou hub particular que coordena as ações cross-chain (o utilizador pode apenas interagir com esse hub). Exemplos incluem projetos como a L1 do Push Protocol (Push Chain) que está a ser projetada como uma camada de liquidação dedicada para operações agnósticas à chain, apresentando contratos inteligentes universais e finalidade sub-segundo para acelerar as interações cross-chain. Embora não universalmente adotadas, estas abordagens ilustram o espectro de técnicas usadas para realizar a abstração de chain: desde a orquestração puramente off-chain até à implementação de nova infraestrutura on-chain construída propositadamente para a execução de intenções cross-chain.

Em resumo, a abstração de chain é alcançada através da sobreposição destes componentes: uma camada de encaminhamento (relayers a enviar mensagens entre chains), uma camada de conta (smart wallets que podem iniciar ações em qualquer chain), e uma camada de execução (solvers, liquidez e contratos que executam as intenções). Cada peça é necessária para garantir que, da perspetiva do utilizador, interagir com uma dApp através de múltiplas blockchains seja tão suave como usar uma aplicação de uma única chain.

Estudo de Caso 1: Wormhole – Encaminhamento Baseado em Intenção e Agnóstico à Chain​

A Wormhole é um protocolo de interoperabilidade cross-chain líder que evoluiu de uma ponte de tokens para uma rede abrangente de passagem de mensagens com funcionalidade baseada em intenção. A sua abordagem à abstração de chain é fornecer uma camada de encaminhamento de mensagens uniforme que conecta mais de 20 chains (incluindo chains EVM e não-EVM como a Solana), e sobre isso, construir protocolos de aplicação agnósticos à chain. Elementos chave da arquitetura da Wormhole incluem:

• Camada de Mensagens Genérica: No seu cerne, a Wormhole é uma ponte de publicação/subscrição genérica. Validadores (Guardians) observam eventos em cada chain conectada e assinam um VAA (ação verificável) que pode ser submetido em qualquer outra chain para reproduzir o evento ou chamar um contrato de destino. Este design genérico significa que os programadores podem enviar instruções ou dados arbitrários cross-chain, não apenas transferências de tokens. A Wormhole garante que as mensagens são entregues e verificadas de forma consistente, abstraindo se a origem foi Ethereum, Solana ou outra chain.

• Transferências de Tokens Agnósticas à Chain: A Token Bridge (Portal) original da Wormhole usava uma abordagem de lock-and-mint. Recentemente, a Wormhole introduziu as Native Token Transfers (NTT), um framework melhorado para tokens multichain. Com NTT, os ativos podem ser emitidos nativamente em cada chain (evitando tokens embrulhados fragmentados), enquanto a Wormhole trata da contabilidade das queimas e cunhagens entre chains para manter a oferta sincronizada. Para os utilizadores, isto parece que um token se “teleporta” entre chains – eles depositam numa chain e retiram o mesmo ativo noutra, com a Wormhole a gerir a contabilidade de cunhagem/queima. Esta é uma forma de abstração de tokens que esconde a complexidade dos diferentes padrões de tokens e endereços em cada chain.

• Protocolos xApp Baseados em Intenção: Reconhecendo que a ponte de tokens é apenas uma parte da UX cross-chain, a Wormhole desenvolveu protocolos de nível superior para cumprir intenções do utilizador, como trocas ou transferências com gestão de taxas de gás. Em 2023–2024, a Wormhole colaborou com o agregador de DEX cross-chain Mayan para lançar dois protocolos focados em intenção, frequentemente chamados de xApps (aplicações cross-chain) no ecossistema Wormhole: Mayan Swift e Mayan MCTP (Multichain Transfer Protocol).

  • Mayan Swift é descrito como um “protocolo de intenção cross-chain flexível” que essencialmente permite a um utilizador solicitar uma troca de token da Chain A para a Chain B. O utilizador assina uma única transação na chain de origem, bloqueando os seus fundos e especificando o resultado desejado (ex: “quero pelo menos X quantidade do token Y na chain de destino até ao tempo T”). Esta intenção (a ordem) é então captada por solvers. De forma única, o Wormhole Swift usa um leilão on-chain na Solana para conduzir uma descoberta de preço competitiva para a intenção. Os solvers monitorizam um contrato especial na Solana; quando uma nova ordem de intenção é criada, eles licitam comprometendo-se com a quantidade do token de saída que podem entregar. Durante um curto período de leilão (ex: 3 segundos), as licitações competem para aumentar o preço. O maior licitante (que oferece a taxa mais favorável ao utilizador) ganha e recebe o direito de cumprir a troca. A Wormhole então transporta uma mensagem para a chain de destino autorizando esse solver a entregar os tokens ao utilizador, e outra mensagem de volta para libertar os fundos bloqueados do utilizador para o solver como pagamento. Este design garante que a intenção do utilizador é cumprida ao melhor preço possível de forma descentralizada, enquanto o utilizador só teve de interagir com a sua chain de origem. Também dissocia a troca cross-chain em dois passos (bloquear fundos, depois cumprir no destino) para minimizar o risco. O design centrado em intenção aqui mostra como a abstração permite uma execução inteligente: em vez de um utilizador escolher uma ponte ou DEX específica, o sistema encontra o caminho e o preço ótimos automaticamente.

  • Mayan MCTP foca-se em transferências de ativos cross-chain com gestão de gás e taxas. Aproveita o CCTP (Cross-Chain Transfer Protocol) da Circle – que permite que USDC nativo seja queimado numa chain e cunhado noutra – como base para a transferência de valor, e usa a passagem de mensagens da Wormhole para coordenação. Numa transferência MCTP, a intenção de um utilizador pode ser simplesmente “mover o meu USDC da Chain A para a Chain B (e opcionalmente trocar por outro token na B)”. O contrato da chain de origem aceita os tokens e um destino desejado, depois inicia uma queima via CCTP e publica simultaneamente uma mensagem Wormhole transportando metadados como o endereço de destino do utilizador, o token desejado no destino, e até um gas drop (uma quantidade dos fundos ponteados para converter em gás nativo no destino). Na chain de destino, assim que a Circle cunha o USDC, um relayer da Wormhole garante que os metadados da intenção são entregues e verificados. O protocolo pode então, por exemplo, trocar automaticamente uma porção de USDC pelo token nativo para pagar o gás, e entregar o resto à carteira do utilizador (ou a um contrato especificado). Isto fornece uma ponte de um passo, com gás incluído: o utilizador não precisa de adquirir gás na nova chain ou realizar uma troca separada por gás. Está tudo codificado na intenção e tratado pela rede. O MCTP demonstra assim como a abstração de chain pode lidar com a abstração de taxas e transferências fiáveis num único fluxo. O papel da Wormhole é transmitir de forma segura a intenção e a prova de que os fundos foram movidos (via CCTP) para que o pedido do utilizador seja cumprido de ponta a ponta.

Ilustração da arquitetura de troca centrada em intenção da Wormhole (Mayan Swift). Neste design, o utilizador bloqueia ativos na chain de origem e define um resultado (intenção). Os solvers licitam num leilão on-chain pelo direito de cumprir essa intenção. O solver vencedor usa mensagens da Wormhole para coordenar o desbloqueio de fundos e a entrega do resultado na chain de destino, tudo enquanto garante que o utilizador recebe o melhor preço pela sua troca.

• UX Unificada e Fluxos de Um Clique: As aplicações baseadas na Wormhole estão cada vez mais a oferecer ações cross-chain de um clique. Por exemplo, o Wormhole Connect é um SDK de frontend que dApps e carteiras integram para permitir que os utilizadores façam a ponte de ativos com um único clique – nos bastidores, ele chama a ponte de tokens da Wormhole e (opcionalmente) relayers que depositam gás na chain de destino. No caso de uso do fundo Securitize SCOPE, um investidor no Optimism pode comprar tokens do fundo que originalmente vivem no Ethereum, sem fazer a ponte de nada manualmente; a camada de liquidez da Wormhole move automaticamente os tokens e até os converte numa forma que gera rendimento, para que o utilizador veja apenas um produto de investimento unificado. Tais exemplos destacam o ethos da abstração de chain: o utilizador realiza uma ação de alto nível (investir no fundo, trocar X por Y) e a plataforma trata da mecânica cross-chain silenciosamente. A retransmissão de mensagens padrão da Wormhole e a entrega automática de gás (através de serviços como o Relayer Automático da Wormhole ou o Serviço de Gás da Axelar integrado em alguns fluxos) significam que o utilizador muitas vezes assina apenas uma transação na sua chain de origem e recebe o resultado na chain de destino sem mais intervenção. Da perspetiva do programador, a Wormhole fornece uma interface uniforme para chamar contratos entre chains, tornando a construção de lógica cross-chain mais simples.

Em resumo, a abordagem da Wormhole à abstração de chain é fornecer a infraestrutura (relayers descentralizados + contratos padronizados em cada chain) sobre a qual outros podem construir para criar experiências agnósticas à chain. Ao suportar uma grande variedade de chains e oferecer protocolos de nível superior (como o leilão de intenções e a transferência com gestão de gás), a Wormhole permite que as aplicações tratem o ecossistema blockchain como um todo conectado. Os utilizadores beneficiam por não precisarem mais de se preocupar com a chain em que estão ou como fazer a ponte – seja a mover liquidez ou a fazer uma troca multi-chain, as xApps centradas em intenção da Wormhole visam tornar tudo tão fácil como uma interação de uma única chain. O co-fundador da Wormhole, Robinson Burkey, notou que este tipo de infraestrutura atingiu uma “maturidade à escala institucional”, permitindo que até emissores de ativos regulados operem de forma transparente entre redes e abstraiam as restrições específicas da chain para os seus utilizadores.

Estudo de Caso 2: Etherspot – A Abstração de Conta Encontra as Intenções​

A Etherspot aborda o problema da UX cross-chain da perspetiva das carteiras e das ferramentas para programadores. Fornece um SDK de Abstração de Conta e uma pilha de protocolo de intenção que os programadores podem integrar para dar aos seus utilizadores uma experiência multi-chain unificada. Na prática, a Etherspot combina carteiras de contrato inteligente com lógica de abstração de chain para que a única conta inteligente de um utilizador possa operar em muitas redes com atrito mínimo. As características chave da arquitetura da Etherspot incluem:

• Smart Wallet Modular (Abstração de Conta): Cada utilizador da Etherspot obtém uma carteira de contrato inteligente (estilo ERC-4337) que pode ser implementada em múltiplas chains. A Etherspot contribuiu para padrões como o ERC-7579 (interface mínima de contas inteligentes modulares) para garantir que estas carteiras são interoperáveis e atualizáveis. O contrato da carteira atua como o agente do utilizador e pode ser personalizado com módulos. Por exemplo, um módulo pode permitir uma visão de saldo unificada – a carteira pode reportar o agregado dos fundos de um utilizador em todas as chains. Outro módulo pode permitir chaves de sessão, para que o utilizador possa aprovar uma série de ações com uma única assinatura. Como a carteira está presente em cada chain, pode iniciar transações diretamente localmente quando necessário (com os bundlers e relayers de backend da Etherspot a orquestrar a coordenação cross-chain).

• Bundler de Transações e Paymasters: A Etherspot gere um serviço de bundler (chamado Skandha) que recolhe operações de utilizador das smart wallets, e um serviço de paymaster (Arka) que pode patrocinar taxas de gás. Quando um utilizador aciona uma intenção através da Etherspot, ele efetivamente assina uma mensagem para o seu contrato de carteira. A infraestrutura da Etherspot (o bundler) traduz isso em transações reais nas chains relevantes. Crucialmente, pode agrupar múltiplas ações – por exemplo, uma troca DEX numa chain e uma transferência de ponte para outra chain – numa meta-transação que o contrato de carteira do utilizador executará passo a passo. O paymaster significa que o utilizador pode não precisar de pagar qualquer gás L1; em vez disso, a dApp ou um terceiro poderia cobri-lo, ou a taxa poderia ser retirada noutro token. Isto realiza a abstração de gás na prática (uma grande vitória de usabilidade). De facto, a Etherspot destaca que com as próximas funcionalidades do Ethereum como a EIP-7702, até as Contas de Propriedade Externa poderiam ganhar capacidades sem gás semelhantes às carteiras de contrato – mas as contas inteligentes da Etherspot já permitem intenções sem gás via paymasters hoje.

• API de Intenção e Solvers (Pulse): No topo da camada de conta, a Etherspot fornece uma API de Intenção de alto nível conhecida como Etherspot Pulse. O Pulse é o motor de abstração de chain da Etherspot que os programadores podem usar para permitir intenções cross-chain nas suas dApps. Numa demonstração do Etherspot Pulse no final de 2024, eles mostraram como um utilizador poderia realizar uma troca de token do Ethereum para um ativo na Base, usando uma interface de aplicação React simples com um clique. Nos bastidores, o Pulse tratou da transação multi-chain de forma segura e eficiente. As características chave do Pulse incluem Saldos Unificados (o utilizador vê todos os ativos como um único portfólio, independentemente da chain), Segurança com Chaves de Sessão (privilégios limitados para certas ações para evitar aprovações constantes), Trocas Baseadas em Intenção, e Integração de Solvers. Por outras palavras, o programador apenas chama uma intenção como swap(tokenA na Chain1 -> tokenB na Chain2 para o utilizador) através do SDK da Etherspot, e o Pulse descobre como fazê-lo – seja encaminhando através de uma rede de liquidez como a Socket ou chamando uma DEX cross-chain. A Etherspot integrou-se com várias pontes e agregadores de DEX para encontrar rotas ótimas (é provável que esteja a usar alguns dos conceitos do Open Intents Framework também, dado o envolvimento da Etherspot na comunidade de intenções do Ethereum).

• Educação e Padrões: A Etherspot tem sido uma defensora vocal dos padrões de abstração de chain. Lançou conteúdo educacional explicando as intenções e como “os utilizadores declaram o resultado desejado, enquanto os solvers tratam do processo de backend”, enfatizando a UX simplificada e a fluidez cross-chain. Eles enumeram benefícios como os utilizadores não precisarem de se preocupar com pontes ou gás, e as dApps ganharem escalabilidade ao aceder facilmente a múltiplas chains. A Etherspot também está a colaborar ativamente com projetos do ecossistema: por exemplo, referencia o Open Intents Framework da Ethereum Foundation e explora a integração de novos padrões de mensagens cross-chain (ERC-7786, 7787, etc.) à medida que surgem. Ao alinhar-se com padrões comuns, a Etherspot garante que o seu formato de intenção ou interface de carteira pode funcionar em conjunto com outras soluções (como Hyperlane, Connext, Axelar, etc.) escolhidas pelo programador.

• Casos de Uso e UX para Programadores: Para os programadores, usar a Etherspot significa que podem adicionar funcionalidades cross-chain sem reinventar a roda. Uma dApp DeFi pode permitir que um utilizador deposite fundos em qualquer chain onde tenha ativos, e a Etherspot abstrairá as diferenças de chain. Uma aplicação de jogos poderia permitir que os utilizadores assinassem uma única transação para reivindicar um NFT numa L2 e tê-lo automaticamente ponteado para o Ethereum, se necessário para negociação. O SDK da Etherspot essencialmente oferece chamadas de função agnósticas à chain – os programadores chamam métodos de alto nível (como um transfer() ou swap() unificado) e o SDK trata de localizar os fundos do utilizador, movê-los se necessário, e atualizar o estado entre chains. Isto reduz significativamente o tempo de desenvolvimento para suporte multi-chain (a equipa afirma uma redução de até 90% no tempo de desenvolvimento ao usar a sua plataforma de abstração de chain). Outro aspeto é o RPC Playground e as ferramentas de depuração que a Etherspot construiu para fluxos de AA, que facilitam o teste de operações de utilizador complexas que podem envolver múltiplas redes. Tudo isto está orientado para tornar a integração da abstração de chain tão simples como integrar uma API de pagamentos na Web2.

Da perspetiva do utilizador final, uma aplicação potenciada pela Etherspot pode oferecer uma experiência de onboarding e diária muito mais suave. Novos utilizadores podem iniciar sessão com login social ou email (se a dApp usar o módulo de conta social da Etherspot) e obter uma conta inteligente automaticamente – sem necessidade de gerir frases de semente para cada chain. Eles podem receber tokens de qualquer chain para o seu único endereço (o endereço da smart wallet é o mesmo em todas as chains suportadas) e vê-los numa única lista. Se quiserem realizar uma ação (trocar, emprestar, etc.) numa chain onde não têm o ativo ou gás, o protocolo de intenção encaminhará automaticamente os seus fundos e ações para que isso aconteça. Por exemplo, um utilizador com USDC na Polygon que queira participar num pool DeFi do Ethereum poderia simplesmente clicar em “Investir no Pool” – a aplicação (via Etherspot) trocará o USDC pelo ativo necessário, fará a ponte para o Ethereum, depositará no contrato do pool, e até tratará das taxas de gás retirando uma pequena porção do USDC, tudo num único fluxo. O utilizador nunca é confrontado com erros de “por favor, mude para a rede X” ou “precisa de ETH para gás” – esses são tratados nos bastidores. Esta experiência de um clique é exatamente o que a abstração de chain procura alcançar.

O CEO da Etherspot, Michael Messele, falou na EthCC 2025 sobre “abstração de chain avançada” e destacou que tornar a Web3 verdadeiramente agnóstica à blockchain pode capacitar tanto utilizadores como programadores, melhorando a interoperabilidade, escalabilidade e UX. As próprias contribuições da Etherspot, como a demonstração do Pulse de trocas cross-chain com uma única intenção, mostram que a tecnologia já está aqui para simplificar drasticamente as interações cross-chain. Como a Etherspot posiciona, as intenções são a ponte entre as possibilidades inovadoras de um ecossistema multi-chain e a usabilidade que os utilizadores finais esperam. Com soluções como a deles, as dApps podem oferecer experiências “sem atrito” onde as diferenças de chain desaparecem para o fundo, acelerando a adoção em massa da Web3.

Melhorias na Experiência do Utilizador e do Programador​

Tanto a abstração de chain como as arquiteturas centradas em intenção estão, em última análise, ao serviço de uma melhor experiência do utilizador (UX) e experiência do programador (DX) num mundo multi-chain. Algumas das melhorias notáveis incluem:

• Onboarding Fluido: Novos utilizadores podem ser integrados sem se preocuparem com a blockchain em que estão. Por exemplo, um utilizador pode receber uma única conta inteligente que funciona em todo o lado, possivelmente criada com um login social. Eles podem receber qualquer token ou NFT nesta conta de qualquer chain sem confusão. Já não é necessário que um recém-chegado aprenda sobre a mudança de redes no MetaMask ou a salvaguarda de múltiplas frases de semente. Isto reduz significativamente a barreira de entrada, pois usar uma dApp parece mais próximo de um registo numa aplicação Web2. Projetos que implementam a abstração de conta frequentemente permitem a criação de carteiras baseadas em email ou OAuth, com a conta inteligente resultante a ser agnóstica à chain.

• Ações Cross-Chain com Um Clique: Talvez o ganho de UX mais visível seja a condensação do que costumavam ser fluxos de trabalho de múltiplos passos e múltiplas aplicações em um ou dois cliques. Por exemplo, uma troca de token cross-chain anteriormente poderia exigir: trocar o Token A por um ativo ponteável na Chain 1, ir a uma UI de ponte para o enviar para a Chain 2, depois trocar para o Token B na Chain 2 – e gerir as taxas de gás em ambas as chains. Com sistemas centrados em intenção, o utilizador simplesmente solicita “Trocar A na Chain1 por B na Chain2” e confirma uma vez. Todos os passos intermediários (incluindo a aquisição de gás na Chain2, se necessário) são automatizados. Isto não só poupa tempo, mas também reduz as chances de erro do utilizador (usar a ponte errada, enviar para o endereço errado, etc.). É semelhante à conveniência de reservar um voo com múltiplas escalas através de um único site de viagens, em vez de comprar manualmente cada trecho separadamente.

• Sem Ansiedade com o Gás Nativo: Os utilizadores não precisam de trocar constantemente por pequenas quantidades de ETH, MATIC, AVAX, etc., apenas para pagar por transações. A abstração de taxas de gás significa que ou a dApp cobre o gás (e talvez cobre uma taxa no token transacionado ou através de um modelo de subscrição), ou o sistema converte um pouco do ativo do utilizador automaticamente para pagar as taxas. Isto tem um enorme impacto psicológico – remove uma classe de avisos confusos (chega de erros de “gás insuficiente”) e permite que os utilizadores se concentrem nas ações que lhes interessam. Várias palestras na EthCC 2025 notaram a abstração de gás como uma prioridade, por exemplo, a EIP-7702 do Ethereum permitirá até que contas EOA tenham gás patrocinado no futuro. Na prática hoje, muitos protocolos de intenção entregam uma pequena quantidade do ativo de saída como gás na chain de destino para o utilizador, ou utilizam paymasters conectados a operações de utilizador. O resultado: um utilizador pode, por exemplo, mover USDC da Arbitrum para a Polygon sem nunca tocar em ETH em nenhum dos lados, e ainda assim ter a sua carteira Polygon capaz de fazer transações imediatamente à chegada.

• Gestão Unificada de Ativos: Para os utilizadores finais, ter uma visão unificada de ativos e atividades através de chains é uma grande melhoria na qualidade de vida. A abstração de chain pode apresentar um portfólio combinado – então o seu 1 ETH na mainnet e 2 ETH de stETH ponteado no Optimism podem ambos aparecer apenas como “saldo de ETH”. Se tiver stablecoins USD em cinco chains diferentes, uma carteira agnóstica à chain poderia mostrar o seu valor total em USD e permitir gastar a partir dele sem que tenha de fazer a ponte manualmente. Isto parece mais com uma aplicação bancária tradicional que mostra um único saldo (mesmo que os fundos estejam espalhados por contas nos bastidores). Os utilizadores podem definir preferências como “usar a rede mais barata por defeito” ou “maximizar o rendimento” e o sistema pode alocar automaticamente as transações para a chain apropriada. Enquanto isso, todo o seu histórico de transações poderia ser visto numa única linha do tempo, independentemente da chain. Tal coerência é importante para uma adoção mais ampla – esconde a complexidade da blockchain sob metáforas familiares.

• Produtividade Aumentada para Programadores: Do lado do programador, as plataformas de abstração de chain significam não mais escrever código específico da chain para cada integração. Em vez de integrar cinco pontes diferentes e seis exchanges para garantir a cobertura de ativos e redes, um programador pode integrar uma API de protocolo de intenção que abstrai isso. Isto não só poupa esforço de desenvolvimento, mas também reduz a manutenção – à medida que novas chains ou pontes surgem, os mantenedores da camada de abstração tratam da integração, e a dApp apenas beneficia disso. O resumo semanal da Etherspot destacou que soluções como a plataforma de abstração de chain da Okto afirmam reduzir o tempo de desenvolvimento de dApps multi-chain em até 90%, fornecendo suporte pronto a usar para as principais chains e funcionalidades como otimização de liquidez. Em essência, os programadores podem focar-se na lógica da aplicação (ex: um produto de empréstimo, um jogo) em vez das complexidades das transferências cross-chain ou da gestão de gás. Isto abre a porta para que mais programadores Web2 entrem na Web3, pois podem usar SDKs de nível superior em vez de precisarem de um conhecimento profundo de blockchain para cada chain.

• Novas Experiências Componíveis: Com intenções e abstração de chain, os programadores podem criar experiências que antes eram demasiado complexas para tentar. Por exemplo, estratégias de yield farming cross-chain podem ser automatizadas: um utilizador poderia clicar em “maximizar o rendimento dos meus ativos” e um protocolo de intenção poderia mover ativos entre chains para as melhores quintas de rendimento, fazendo isso continuamente à medida que as taxas mudam. Os jogos podem ter ativos e missões que abrangem múltiplas chains sem exigir que os jogadores façam a ponte de itens manualmente – o backend do jogo (usando um framework de intenção) trata da teleportação de itens ou da sincronização de estado. Até a governação pode beneficiar: uma DAO poderia permitir que um utilizador votasse uma vez e tivesse esse voto aplicado em todos os contratos de governação das chains relevantes através de mensagens cross-chain. O efeito geral é a componibilidade: assim como o DeFi numa única chain permitiu a composição de protocolos tipo Lego, as camadas de intenção cross-chain permitem que protocolos em diferentes chains se componham. Uma intenção do utilizador pode acionar ações em múltiplas dApps através de chains (ex: desembrulhar um NFT numa chain e vendê-lo num mercado noutra), o que cria fluxos de trabalho mais ricos do que operações isoladas de uma única chain.

• Redes de Segurança e Fiabilidade: Um aspeto de UX muitas vezes subestimado é o tratamento de erros. Nas primeiras interações cross-chain, se algo corresse mal (fundos presos numa ponte, uma transação a falhar depois de enviar fundos, etc.), os utilizadores enfrentavam um pesadelo de resolução de problemas em múltiplas plataformas. Os frameworks de intenção podem incorporar lógica de repetição, seguro ou mecanismos de proteção do utilizador. Por exemplo, um solver pode assumir o risco de finalidade – entregando os fundos do utilizador no destino imediatamente (em segundos) e esperando pela finalidade mais lenta da chain de origem. Isto significa que o utilizador não fica preso à espera de minutos ou horas pela confirmação. Se uma intenção falhar parcialmente, o sistema pode reverter ou reembolsar automaticamente. Como todo o fluxo é orquestrado com passos conhecidos, há mais espaço para compensar o utilizador se algo quebrar. Alguns protocolos estão a explorar escrow e seguro para operações cross-chain como parte da execução da intenção, o que seria impossível se o utilizador estivesse a saltar manualmente por obstáculos – ele suportaria esse risco sozinho. Em suma, a abstração pode tornar a experiência geral não apenas mais suave, mas também mais segura e confiável para o utilizador médio.

Todas estas melhorias apontam para uma única tendência: reduzir a carga cognitiva sobre os utilizadores e abstrair a canalização da blockchain para o segundo plano. Quando bem feito, os utilizadores podem nem sequer perceber que chains estão a usar – eles apenas acedem a funcionalidades e serviços. Os programadores, por outro lado, conseguem construir aplicações que exploram a liquidez e as bases de utilizadores em muitas redes a partir de uma única base de código. É uma mudança de complexidade das bordas (aplicações do utilizador) para o meio (protocolos de infraestrutura), o que é uma progressão natural à medida que a tecnologia amadurece. O tom da EthCC 2025 ecoou este sentimento, com a “infraestrutura componível e transparente” citada como um objetivo primordial para a comunidade Ethereum.

Insights da EthCC 2025​

A conferência EthCC 2025 (realizada em julho de 2025 em Cannes) sublinhou o quão central a abstração de chain e o design baseado em intenção se tornaram no ecossistema Ethereum. Um bloco dedicado de sessões focou-se em unificar as experiências do utilizador através das redes. As principais conclusões do evento incluem:

• Alinhamento da Comunidade sobre Abstração: Várias palestras de líderes da indústria ecoaram a mesma mensagem – simplificar a experiência multi-chain é crítico para a próxima onda de adoção da Web3. Michael Messele (Etherspot) falou sobre avançar “em direção a um futuro agnóstico à blockchain”, Alex Bash (carteira Zerion) discutiu “unificar a UX do Ethereum com abstração e intenções”, e outros introduziram padrões concretos como o ERC-7811 para a abstração de chain de stablecoins. O próprio título de uma palestra, “Não Há Futuro Web3 Sem Abstração de Chain”, encapsulou o sentimento da comunidade. Por outras palavras, há um amplo acordo de que, sem resolver a usabilidade cross-chain, a Web3 não alcançará o seu pleno potencial. Isto representa uma mudança em relação a anos anteriores, onde o foco principal era escalar a L1 ou L2 – agora que muitas L2s estão ativas, conectá-las para os utilizadores é a nova fronteira.

• O Papel do Ethereum como um Hub: Os painéis da EthCC destacaram que o Ethereum está a posicionar-se não apenas como uma chain entre muitas, mas como a fundação de um ecossistema multi-chain. A segurança do Ethereum e a sua abstração de conta 4337 na mainnet podem servir como a base comum que sustenta a atividade em várias L2s e sidechains. Em vez de competir com os seus rollups, o Ethereum (e por extensão a comunidade Ethereum) está a investir em protocolos que fazem com que toda a rede de chains pareça unificada. Isto é exemplificado pelo apoio da Ethereum Foundation a projetos como o Open Intents Framework, que abrange muitas chains e rollups. A vibração na EthCC foi que a maturidade do Ethereum é demonstrada ao abraçar um “ecossistema de ecossistemas”, onde o design centrado no utilizador (independentemente da chain) é primordial.

• Stablecoins e Ativos do Mundo Real como Catalisadores: Um tema interessante foi a interseção da abstração de chain com stablecoins e RWAs (Ativos do Mundo Real). As stablecoins foram repetidamente notadas como uma “força de ancoragem” no DeFi, e várias palestras (ex: sobre a abstração de chain de stablecoins ERC-7811) analisaram como tornar o uso de stablecoins agnóstico à chain. A ideia é que um utilizador médio não deveria precisar de se preocupar em que chain o seu USDC ou DAI reside – deveria ter o mesmo valor e ser utilizável em qualquer lugar de forma transparente. Vimos isto com o fundo da Securitize a usar a Wormhole para se tornar multichain, abstraindo efetivamente um produto institucional através de chains. As discussões na EthCC sugeriram que resolver a UX cross-chain para stablecoins e RWAs é um grande passo em direção a finanças baseadas em blockchain mais amplas, uma vez que estes ativos exigem experiências de utilizador suaves para a adoção por instituições e utilizadores mainstream.

• Entusiasmo e Ferramentas para Programadores: Workshops e eventos paralelos (como o Multichain Day) introduziram os programadores às novas ferramentas disponíveis. Projetos de hackathon e demonstrações mostraram como as APIs de intenção e os SDKs de abstração de chain (de várias equipas) poderiam ser usados para criar dApps cross-chain em dias. Havia um entusiasmo palpável de que o “Santo Graal” da UX Web3 – usar múltiplas redes sem o perceber – está ao alcance. A equipa do Open Intents Framework realizou um workshop para iniciantes explicando como construir uma aplicação habilitada para intenções, provavelmente usando o seu solver e contratos de referência. Os programadores que tinham lutado com pontes e implementação multi-chain no passado estavam interessados nestas soluções, como evidenciado pelas sessões de perguntas e respostas (conforme relatado informalmente nas redes sociais durante a conferência).

• Anúncios e Colaboração: A EthCC 2025 também serviu de palco para anunciar colaborações entre projetos nesta área. Por exemplo, uma parceria entre um fornecedor de carteiras e um protocolo de intenção ou entre um projeto de ponte e um projeto de abstração de conta foram sugeridas. Um anúncio concreto foi a integração da Wormhole com o ecossistema Stacks (trazendo a liquidez do Bitcoin para os fluxos cross-chain), o que não era diretamente abstração de chain para o Ethereum, mas exemplificava a conectividade em expansão através de ecossistemas cripto tradicionalmente separados. A presença de projetos como Zerion (carteira), Safe (contas inteligentes), Connext, Socket, Axelar, etc., todos a discutir interoperabilidade, sinalizou que muitas peças do quebra-cabeça estão a juntar-se.

No geral, a EthCC 2025 pintou um quadro de uma comunidade a convergir em torno da inovação cross-chain centrada no utilizador. A frase “infraestrutura componível” foi usada para descrever o objetivo: todas estas L1s, L2s e protocolos devem formar um tecido coeso sobre o qual as aplicações podem construir sem precisar de juntar as coisas ad-hoc. A conferência deixou claro que a abstração de chain e as intenções não são apenas palavras da moda, mas áreas ativas de desenvolvimento que atraem talento e investimento sérios. A liderança do Ethereum nisto – através de financiamento, estabelecimento de padrões e fornecimento de uma camada base robusta – foi reafirmada no evento.

Comparação de Abordagens à Abstração de Chain e Intenções​

A tabela abaixo compara vários protocolos e frameworks proeminentes que abordam a experiência do utilizador/programador cross-chain, destacando a sua abordagem e características chave:

(Legenda da tabela: AA = Abstração de Conta, ChA = Abstração de Chain, AMB = ponte de mensagens arbitrárias)

Cada uma das abordagens acima aborda o desafio da UX cross-chain de um ângulo ligeiramente diferente – algumas focam-se na carteira/conta do utilizador, outras na passagem de mensagens da rede, e outras na camada de API do programador – mas todas partilham o objetivo de tornar as interações blockchain agnósticas à chain e orientadas por intenção. Notavelmente, estas soluções não são mutuamente exclusivas; na verdade, muitas vezes complementam-se. Por exemplo, uma aplicação poderia usar a smart wallet + paymasters da Etherspot, com o padrão Open Intents para formatar a intenção do utilizador, e depois usar a Axelar ou a Connext nos bastidores como a camada de execução para realmente fazer a ponte e realizar as ações. A tendência emergente é a componibilidade entre as próprias ferramentas de abstração de chain, construindo em última análise em direção a uma Internet de Blockchains onde os utilizadores navegam livremente.

Conclusão​

A tecnologia blockchain está a passar por uma mudança de paradigma, de redes isoladas e operações manuais para uma experiência unificada e orientada por intenção. A abstração de chain e a arquitetura centrada em intenção estão no cerne desta transformação. Ao abstrair as complexidades de múltiplas chains, elas permitem uma Web3 centrada no utilizador, na qual as pessoas interagem com aplicações descentralizadas sem precisarem de entender que chain estão a usar, como fazer a ponte de ativos, ou como adquirir gás em cada rede. A infraestrutura – relayers, contas inteligentes, solvers e pontes – trata colaborativamente desses detalhes, muito como os protocolos subjacentes da Internet encaminham pacotes sem que os utilizadores conheçam a rota.

Os benefícios na experiência do utilizador já são tangíveis: onboarding mais suave, trocas cross-chain com um clique, e interações de dApp verdadeiramente transparentes através de ecossistemas. Os programadores também são capacitados por SDKs e padrões de nível superior que simplificam drasticamente a construção para um mundo multi-chain. Como visto na EthCC 2025, há um forte consenso na comunidade de que estes desenvolvimentos não são apenas melhorias excitantes, mas requisitos fundamentais para a próxima fase de crescimento da Web3. Projetos como Wormhole e Etherspot demonstram que é possível reter a descentralização e a ausência de confiança, oferecendo ao mesmo tempo uma facilidade de uso semelhante à da Web2.

Olhando para o futuro, podemos esperar uma maior convergência destas abordagens. Padrões como as intenções ERC-7683 e a abstração de conta ERC-4337 provavelmente tornar-se-ão amplamente adotados, garantindo a compatibilidade entre plataformas. Mais pontes e redes integrar-se-ão com frameworks de intenção abertos, aumentando a liquidez e as opções para os solvers cumprirem as intenções dos utilizadores. Eventualmente, o termo “cross-chain” pode desaparecer, pois as interações não serão pensadas em termos de chains distintas – muito como os utilizadores da web não pensam em que centro de dados o seu pedido atingiu. Em vez disso, os utilizadores simplesmente invocarão serviços e gerirão ativos num ecossistema blockchain unificado.

Em conclusão, a abstração de chain e o design centrado em intenção estão a tornar o sonho multi-chain uma realidade: entregando os benefícios da inovação diversificada da blockchain sem a fragmentação. Ao centrar os designs nas intenções do utilizador e abstrair o resto, a indústria está a dar um passo importante para tornar as aplicações descentralizadas tão intuitivas e poderosas como os serviços centralizados de hoje, cumprindo a promessa da Web3 para um público mais amplo. A infraestrutura ainda está a evoluir, mas a sua trajetória é clara – uma experiência Web3 transparente e orientada por intenção está no horizonte, e irá redefinir como percebemos e interagimos com as blockchains.

Fontes: A informação neste relatório foi recolhida de uma variedade de recursos atualizados, incluindo documentação de protocolos, publicações de blog de programadores e palestras da EthCC 2025. As referências chave incluem a documentação oficial da Wormhole sobre os seus protocolos de intenção cross-chain, a série de blogues técnicos da Etherspot sobre abstração de conta e de chain, e as notas de lançamento do Open Intents Framework da Ethereum Foundation, entre outros, conforme citado ao longo do texto. Cada citação é indicada no formato 【fonte†linhas】 para identificar o material de origem original que suporta as declarações feitas.

Introdução​

Anunciada para lançamento público em 3 de maio de 2023, após um extenso testnet de três ondas, a blockchain Sui introduziu um sistema inovador de precificação de gas projetado para beneficiar tanto usuários quanto validadores. No seu cerne está o Preço de Gas de Referência (RGP), uma taxa base de gas em toda a rede que os validadores concordam no início de cada época (aproximadamente 24 horas).

Este sistema visa criar um ecossistema mutuamente benéfico para detentores do token SUI, validadores e usuários finais, oferecendo custos de transação baixos e previsíveis ao mesmo tempo em que recompensa validadores por comportamento eficiente e confiável. Este relatório aprofunda como o RGP é determinado, os cálculos que os validadores realizam, seu impacto na economia da rede, sua evolução por meio da governança e como ele se compara a outros modelos de gas em blockchains.

O Mecanismo de Preço de Gas de Referência (RGP)​

O RGP da Sui não é um valor estático, mas é reestabelecido a cada época por meio de um processo dinâmico conduzido pelos validadores.

• A Pesquisa de Preço de Gas: No início de cada época, cada validador submete seu “preço de reserva” — o preço mínimo de gas que está disposto a aceitar para processar transações. O protocolo então ordena essas submissões por stake e define o RGP para aquela época no percentil de 2/3 ponderado por stake. Esse design garante que validadores que representam uma supermaioria (pelo menos dois terços) do stake total estejam dispostos a processar transações a esse preço, assegurando um nível confiável de serviço.

• Cadência de Atualização e Requisitos: Embora o RGP seja definido a cada época, os validadores precisam gerenciar ativamente suas cotações. Segundo as diretrizes oficiais, os validadores devem atualizar sua cotação de preço de gas pelo menos uma vez por semana. Além disso, se houver uma mudança significativa no valor do token SUI, como uma flutuação de 20 % ou mais, os validadores devem atualizar sua cotação imediatamente para garantir que o RGP reflita com precisão as condições de mercado atuais.

• Regra de Contagem e Distribuição de Recompensas: Para garantir que os validadores cumpram o RGP acordado, a Sui emprega uma “regra de contagem”. Ao longo de uma época, os validadores monitoram o desempenho uns dos outros, verificando se seus pares estão processando prontamente transações precificadas pelo RGP. Esse monitoramento gera uma pontuação de desempenho para cada validador. No final da época, essas pontuações são usadas para calcular um multiplicador de recompensa que ajusta a parte de cada validador nas recompensas de stake.

  • Validadores que tiveram bom desempenho recebem um multiplicador de ≥1, aumentando suas recompensas.
  • Validadores que atrasaram, pararam ou falharam em processar transações ao RGP recebem um multiplicador de <1, efetivamente reduzindo parte de seus ganhos.

Esse sistema de duas partes cria uma estrutura de incentivos poderosa. Ele desencoraja validadores de cotar um preço irrealisticamente baixo que não possam sustentar, pois a penalidade financeira por desempenho insuficiente seria severa. Em vez disso, os validadores são motivados a submeter o menor preço que possam manejar de forma sustentável e eficiente.

Operações de Validador: Calculando a Cotação de Preço de Gas​

Do ponto de vista de um validador, definir a cotação do RGP é uma tarefa operacional crítica que impacta diretamente a lucratividade. Requer a construção de pipelines de dados e camadas de automação para processar diversos inputs de fontes on‑chain e off‑chain. Os principais inputs incluem:

• Unidades de gas executadas por época
• Recompensas de staking e subsídios por época
• Contribuições ao fundo de armazenamento
• Preço de mercado do token SUI
• Despesas operacionais (hardware, hospedagem em nuvem, manutenção)

O objetivo é calcular uma cotação que garanta recompensas líquidas positivas. O processo envolve várias fórmulas chave:

1. Calcular Custo Operacional Total: Determina as despesas do validador em moeda fiduciária para uma dada época.

   $$\text{Custo}_{\text{época}} = (\text{Unidades de Gas Totais}_{\text{época}}) \times (\text{Custo em \$ por Unidade de Gas}_{\text{época}})$$

2. Calcular Recompensas Totais: Determina a receita total do validador em moeda fiduciária, proveniente tanto de subsídios do protocolo quanto de taxas de transação.

   $$\text{\$Recompensas}_{\text{época}} = (\text{Recompensas de Stake Totais em SUI}_{\text{época}}) \times (\text{Preço do Token SUI})$$

   Onde Recompensas de Stake Totais é a soma de quaisquer Subsídios de Stake fornecidos pelo protocolo e das Taxas de Gas coletadas das transações.

3. Calcular Recompensas Líquidas: Medida final de lucratividade para um validador.

   $$\text{\$Recompensas Líquidas}_{\text{época}} = \text{\$Recompensas}_{\text{época}} - \text{\$Custo}_{\text{época}}$$

Modelando seus custos e recompensas esperados em diferentes níveis de RGP, os validadores podem determinar uma cotação ótima a ser submetida à Pesquisa de Preço de Gas.

No lançamento da mainnet, a Sui definiu o RGP inicial como um 1.000 MIST fixo (1 SUI = 10⁹ MIST) nas primeiras uma a duas semanas. Isso proporcionou um período operacional estável para que os validadores coletassem dados suficientes de atividade da rede e estabelecessem seus processos de cálculo antes que o mecanismo dinâmico de pesquisa entrasse em pleno efeito.

Impacto no Ecossistema Sui​

O mecanismo RGP molda profundamente a economia e a experiência do usuário em toda a rede.

• Para Usuários: Taxas Previsíveis e Estáveis: O RGP funciona como uma âncora credível para os usuários. A taxa de gas de uma transação segue a fórmula simples: Preço de Gas do Usuário = RGP + Gorjeta. Em condições normais, nenhuma gorjeta é necessária. Durante congestionamento da rede, os usuários podem adicionar uma gorjeta para ganhar prioridade, criando um mercado de taxas sem alterar o preço base estável dentro da época. Esse modelo oferece muito mais estabilidade de taxa do que sistemas onde a taxa base muda a cada bloco.

• Para Validadores: Uma Corrida à Eficiência: O sistema fomenta competição saudável. Validadores são incentivados a reduzir seus custos operacionais (por meio de otimização de hardware e software) para poder cotar um RGP mais baixo de forma lucrativa. Essa “corrida à eficiência” beneficia toda a rede ao reduzir os custos de transação. O mecanismo também empurra os validadores a manter margens de lucro equilibradas; cotar muito alto corre o risco de ser excluído do cálculo do RGP, enquanto cotar muito baixo leva a perdas operacionais e penalidades de desempenho.

• Para a Rede: Descentralização e Sustentabilidade: O mecanismo RGP ajuda a garantir a saúde de longo prazo da rede. A “ameaça de entrada” de novos validadores mais eficientes impede que os validadores existentes colaborem para manter preços altos. Além disso, ao ajustar suas cotações com base no preço de mercado do token SUI, os validadores asseguram coletivamente que suas operações permaneçam sustentáveis em termos reais, isolando a economia de taxas da rede da volatilidade do preço do token.

Governança e Evolução do Sistema: SIP‑45​

O mecanismo de gas da Sui não é estático e evolui por meio da governança. Um exemplo proeminente é o SIP‑45 (Submissão Prioritária de Transações), proposto para refinar a priorização baseada em taxas.

• Problema Abordado: Análises mostraram que simplesmente pagar um preço de gas alto nem sempre garante inclusão mais rápida da transação.
• Mudanças Propostas: A proposta incluiu aumentar o preço máximo de gas permitido e introduzir uma “difusão amplificada” para transações que pagam significativamente acima do RGP (por exemplo, ≥5× RGP), garantindo que sejam rapidamente disseminadas pela rede para inclusão prioritária.

Isso demonstra o compromisso de iterar o modelo de gas com base em dados empíricos para melhorar sua eficácia.

Comparação com Outros Modelos de Gas em Blockchains​

O modelo RGP da Sui é único, especialmente quando comparado ao EIP‑1559 da Ethereum.

Críticas Potenciais e Desafios​

Apesar de seu design inovador, o mecanismo RGP enfrenta desafios potenciais:

• Complexidade: O sistema de pesquisas, regras de contagem e cálculos off‑chain é intricado e pode representar uma curva de aprendizado para novos validadores.
• Reação Lenta a Picos: O RGP é fixo por época e não pode reagir a surtos repentinos de demanda no meio da época, o que pode gerar congestionamento temporário até que os usuários comecem a adicionar gorjetas.
• Potencial de Conluio: Em teoria, validadores poderiam coludir para definir um RGP alto. Esse risco é mitigado principalmente pela natureza competitiva do conjunto de validadores permissionless.
• Ausência de Queima de Taxas: Diferente da Ethereum, a Sui recicla todas as taxas de gas para validadores e o fundo de armazenamento. Isso recompensa os operadores da rede, mas não cria pressão deflacionária sobre o token SUI, recurso valorizado por alguns detentores.

Perguntas Frequentes (FAQ)​

Por que fazer staking de SUI? Staking de SUI assegura a rede e gera recompensas. Inicialmente, essas recompensas são fortemente subsidiadas pela Sui Foundation para compensar a baixa atividade da rede. Esses subsídios diminuem 10 % a cada 90 dias, com a expectativa de que as recompensas provenientes de taxas de transação cresçam e se tornem a principal fonte de rendimento. SUI em stake também concede direitos de voto na governança on‑chain.

Meu SUI em stake pode ser slashado? Sim. Enquanto os parâmetros ainda são finalizados, aplica‑se o “Slash de Regra de Contagem”. Um validador que receba pontuação de desempenho zero de 2/3 de seus pares (por baixo desempenho, comportamento malicioso, etc.) terá suas recompensas slashadas por um valor a ser determinado. Stakers também podem perder recompensas se seu validador escolhido apresentar downtime ou cotar um RGP subótimo.

As recompensas de staking são compostas automaticamente? Sim, as recompensas de staking na Sui são distribuídas e re‑stakadas (compostas) automaticamente a cada época. Para acessar as recompensas, é necessário fazer o unstake explicitamente.

Qual é o período de desbloqueio (unbonding) do SUI? Inicialmente, stakers podem desbloquear seus tokens imediatamente. Espera‑se a implementação de um período de desbloqueio, onde os tokens ficam bloqueados por um tempo definido após o unstake, sujeito à governança.

Mantenho a custódia dos meus tokens SUI ao fazer staking? Sim. Ao fazer staking de SUI, você delega seu stake, mas continua com controle total sobre seus tokens. Você nunca transfere a custódia para o validador.