54 postagens marcadas com "blockchain"

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.

No mundo cada vez mais convergente da inteligência artificial e do blockchain, a demanda por confiança e transparência nunca foi tão alta. Como podemos ter certeza de que a saída de um modelo de IA é precisa e não foi adulterada? Como podemos executar cálculos complexos em vastos conjuntos de dados on‑chain sem comprometer segurança ou escalabilidade? A Lagrange Labs está enfrentando essas questões de frente com sua suíte de infraestrutura de conhecimento zero (ZK), visando construir um futuro de “IA que Você Pode Provar”. Este post oferece uma visão objetiva de sua missão, tecnologia e avanços recentes, culminando em seu último paper sobre zk‑SNARKs Dinâmicos.

1. A Equipe e Sua Missão​

A Lagrange Labs está construindo a infraestrutura fundamental para gerar provas criptográficas para qualquer inferência de IA ou aplicação on‑chain. Seu objetivo é tornar a computação verificável, trazendo uma nova camada de confiança ao mundo digital. Seu ecossistema está estruturado em três linhas de produto principais:

• ZK Prover Network: Uma rede descentralizada de mais de 85 nós de prova que fornece o poder computacional necessário para uma ampla gama de tarefas de prova, de IA e rollups a aplicações descentralizadas (dApps).
• DeepProve (zkML): Um sistema especializado para gerar provas ZK de inferências de redes neurais. A Lagrange afirma ser até 158 vezes mais rápido que soluções concorrentes, tornando a IA verificável uma realidade prática.
• ZK Coprocessor 1.0: O primeiro ZK Coprocessor baseado em SQL, permitindo que desenvolvedores executem consultas personalizadas em massivos conjuntos de dados on‑chain e recebam resultados verificavelmente precisos.

2. Um Roadmap para IA Verificável​

A Lagrange tem executado metodicamente um roadmap projetado para resolver os desafios da verificabilidade de IA passo a passo.

• Q3 2024: Lançamento do ZK Coprocessor 1.0: Esta versão introduziu circuitos recursivos hiper‑paralelos, que entregaram um aumento médio de velocidade de aproximadamente 2×. Projetos como Azuki e Gearbox já estão utilizando o coprocessor para suas necessidades de dados on‑chain.
• Q1 2025: DeepProve Revelado: A Lagrange anunciou o DeepProve, sua solução para Zero‑Knowledge Machine Learning (zkML). Ele suporta arquiteturas populares de redes neurais como Perceptrons de Múltiplas Camadas (MLPs) e Redes Neurais Convolucionais (CNNs). O sistema alcança acelerações de ordem de magnitude em todas as três etapas críticas: configuração única, geração de prova e verificação, com ganhos de até 158×.
• Q2 2025: Paper sobre zk‑SNARKs Dinâmicos (Último Marco): Este paper apresenta um algoritmo inovador de “atualização”. Em vez de gerar uma prova do zero sempre que os dados ou a computação subjacentes mudam, este método pode “patchar” uma prova antiga (π) em uma nova prova (π'). Essa atualização pode ser feita com complexidade de apenas O(√n log³n), uma melhoria drástica em relação à recomputação completa. Essa inovação é particularmente adequada para sistemas dinâmicos como modelos de IA que aprendem continuamente, lógica de jogos em tempo real e contratos inteligentes evolutivos.

3. Por Que os zk‑SNARKs Dinâmicos Importam​

A introdução de provas atualizáveis representa uma mudança fundamental no modelo de custos da tecnologia de conhecimento zero.

• Um Novo Paradigma de Custos: A indústria passa de um modelo de “recomputação total para cada prova” para “prova incremental baseada no tamanho da mudança”. Isso reduz drasticamente o custo computacional e financeiro para aplicações que sofrem atualizações frequentes e menores.
• Implicações para IA:
  • Fine‑Tuning Contínuo: Quando se faz fine‑tuning em menos de 1 % dos parâmetros de um modelo, o tempo de geração da prova cresce quase linearmente com o número de parâmetros alterados (Δ parâmetros), e não com o tamanho total do modelo.
  • Inferência em Streaming: Isso permite gerar provas simultaneamente ao processo de inferência. Reduz drasticamente a latência entre a decisão de uma IA e a sua liquidação e verificação on‑chain, desbloqueando casos de uso como serviços de IA on‑chain e provas comprimidas para rollups.
• Implicações para Aplicações On‑Chain:
  • zk‑SNARKs Dinâmicos oferecem otimizações massivas de gás e tempo para aplicações caracterizadas por mudanças frequentes e de pequeno porte. Isso inclui livros de ordens de exchanges descentralizadas (DEX), estados de jogos em evolução e atualizações de ledger que envolvem adições ou remoções frequentes.

4. Um Vislumbre da Pilha Tecnológica​

A poderosa infraestrutura da Lagrange é construída sobre uma pilha tecnológica sofisticada e integrada:

• Design de Circuitos: O sistema é flexível, suportando a incorporação de modelos ONNX (Open Neural Network Exchange), parsers SQL e operadores customizados diretamente em seus circuitos.
• Recursão & Paralelismo: A ZK Prover Network facilita provas recursivas distribuídas, enquanto o ZK Coprocessor aproveita o sharding de “micro‑circuitos” para executar tarefas em paralelo, maximizando a eficiência.
• Incentivos Econômicos: A Lagrange está planejando lançar um token nativo, LA, que será integrado a um sistema Double‑Auction‑for‑Recursive‑Auction (DARA). Isso criará um mercado robusto para leilões de computação de provadores, completo com incentivos e penalidades para garantir a integridade da rede.

5. Ecossistema e Adoção no Mundo Real​

A Lagrange não está construindo em um vácuo; sua tecnologia já está sendo integrada por um número crescente de projetos em diferentes setores:

• IA & ML: Projetos como 0G Labs e Story Protocol estão usando o DeepProve para verificar as saídas de seus modelos de IA, garantindo procedência e confiança.
• Rollups & Infraestrutura: Players chave como EigenLayer, Base e Arbitrum participam da ZK Prover Network como nós validadores ou parceiros de integração, contribuindo para sua segurança e poder computacional.
• Aplicações NFT & DeFi: Marcas como Azuki e protocolos DeFi como Gearbox utilizam o ZK Coprocessor para aprimorar a credibilidade de suas consultas de dados e mecanismos de distribuição de recompensas.

6. Desafios e o Caminho à Frente​

Apesar do progresso impressionante, a Lagrange Labs e o campo mais amplo de ZK enfrentam vários obstáculos:

• Gargalos de Hardware: Mesmo com uma rede distribuída, os SNARKs atualizáveis ainda exigem alta largura de banda e dependem de curvas criptográficas otimizadas para GPU para operar eficientemente.
• Falta de Padronização: O processo de mapear frameworks de IA como ONNX e PyTorch para circuitos ZK ainda carece de uma interface universal e padronizada, gerando atrito para desenvolvedores.
• Um Landscape Competitivo: A corrida para construir zkVMs e plataformas de zkCompute generalizadas está se intensificando. Competidores como Risc‑Zero e Succinct também estão avançando significativamente. O vencedor final pode ser quem primeiro comercializar uma toolchain amigável ao desenvolvedor e impulsionada pela comunidade.

7. Conclusão​

A Lagrange Labs está remodelando metodicamente a interseção entre IA e blockchain através da lente da verificabilidade. Sua abordagem oferece uma solução abrangente:

• DeepProve resolve o desafio da inferência confiável.
• O ZK Coprocessor resolve o problema dos dados confiáveis.
• zk‑SNARKs Dinâmicos incorporam a necessidade do mundo real de atualizações contínuas diretamente ao sistema de prova.

Se a Lagrange mantiver sua vantagem de desempenho, resolver o desafio crítico da padronização e continuar a expandir sua rede robusta, estará bem posicionada para se tornar um player fundamental no emergente setor de “IA + Infraestrutura ZK”.

Quando você envia cripto, qual é a sua rotina? Para a maioria de nós, envolve copiar o endereço do destinatário a partir do histórico de transações. Afinal, ninguém consegue memorizar uma sequência de 40 caracteres como 0x1A2b...8f9E. É um atalho conveniente que todos usamos.

Mas e se essa conveniência for uma armadilha cuidadosamente preparada?

Um golpe devastadoramente eficaz chamado Envenenamento de Endereço Blockchain está explorando exatamente esse hábito. Pesquisas recentes da Carnegie Mellon University revelaram a escala chocante dessa ameaça. Em apenas dois anos, nas redes Ethereum e Binance Smart Chain (BSC) sozinhas, os fraudadores realizaram mais de 270 milhões de tentativas de ataque, visando 17 milhões de vítimas e roubando com sucesso pelo menos US$ 83,8 milhões.

Isso não é uma ameaça de nicho; é um dos maiores e mais bem-sucedidos esquemas de phishing cripto em operação hoje. Veja como funciona e o que você pode fazer para se proteger.

Como a Enganação Funciona 🤔​

O envenenamento de endereço é um jogo de truques visuais. A estratégia do atacante é simples, porém brilhante:

1. Gerar um Endereço Similar: O atacante identifica um endereço frequente para o qual você envia fundos. Em seguida, usa computadores poderosos para gerar um novo endereço cripto que tenha os mesmos caracteres iniciais e finais. Como a maioria das carteiras e exploradores de blocos encurtam os endereços para exibição (por exemplo, 0x1A2b...8f9E), o endereço fraudulento parece idêntico ao real à primeira vista.

2. “Envenenar” seu Histórico de Transações: Em seguida, o atacante precisa colocar seu endereço similar no seu histórico de carteira. Ele faz isso enviando uma transação “venenosa”. Isso pode ser:

   • Uma Transferência Minúscula: Ele envia a você uma quantia ínfima de cripto (como US$ 0,001) a partir do endereço similar. Ela passa a aparecer na sua lista de transações recentes.
   • Uma Transferência de Valor Zero: Em um movimento mais astuto, ele explora uma funcionalidade em muitos contratos de token para criar uma transferência falsa, de valor zero, que parece ter vindo de você para o endereço similar dele. Isso faz o endereço falso parecer ainda mais legítimo, como se você já tivesse enviado fundos para ele antes.
   • Uma Transferência de Token Falso: Ele cria um token sem valor, falso (por exemplo, “USDTT” ao invés de USDT) e falsifica uma transação para seu endereço similar, muitas vezes imitando o valor de uma transação real anterior sua.

3. Esperar o Erro: A armadilha está armada. Na próxima vez que você for pagar um contato legítimo, você verifica seu histórico de transações, vê o que acredita ser o endereço correto, copia‑o e confirma o envio. Quando perceber o erro, os fundos já terão desaparecido. E, graças à natureza irreversível da blockchain, não há banco para ligar nem como recuperar o dinheiro.

Um Vislumbre de uma Empresa Criminosa 🕵️‍♂️​

Isso não é obra de hackers solitários. A pesquisa revela que esses ataques são realizados por grandes grupos organizados e altamente lucrativos.

Quem Eles Visam​

Os atacantes não desperdiçam tempo com contas pequenas. Eles visam sistematicamente usuários que são:

• Ricos: Possuem saldos significativos em stablecoins.
• Ativos: Realizam transações frequentes.
• Transatores de Alto Valor: Movimentam grandes somas de dinheiro.

Uma Corrida Armamentista de Hardware​

Gerar um endereço similar é uma tarefa computacional de força bruta. Quanto mais caracteres você quiser combinar, mais exponencialmente difícil fica. Pesquisadores descobriram que, embora a maioria dos atacantes use CPUs padrão para criar falsificações moderadamente convincentes, o grupo criminoso mais sofisticado elevou isso a outro nível.

Esse grupo de elite conseguiu gerar endereços que combinam até 20 caracteres do endereço alvo. Essa façanha é quase impossível com computadores padrão, levando os pesquisadores a concluir que eles utilizam enormes fazendas de GPUs — o mesmo tipo de hardware poderoso usado para jogos de alta performance ou pesquisa em IA. Isso demonstra um investimento financeiro significativo, que eles recuperam facilmente das vítimas. Esses grupos organizados estão operando como um negócio, e o negócio está, infelizmente, em alta.

Como Proteger seus Fundos 🛡️​

Embora a ameaça seja sofisticada, as defesas são simples. Tudo se resume a quebrar maus hábitos e adotar uma postura mais vigilante.

1. Para Todo Usuário (Esta é a parte mais importante):

   • VERIFIQUE O ENDEREÇO COMPLETO. Antes de clicar em “Confirmar”, reserve cinco segundos extras para conferir manualmente todo o endereço, caractere por caractere. Não se limite a olhar apenas os primeiros e últimos dígitos.
   • USE UMA LISTA DE CONTATOS. Salve endereços confiáveis e verificados no livro de endereços ou lista de contatos da sua carteira. Ao enviar fundos, sempre selecione o destinatário dessa lista salva, e não do seu histórico de transações dinâmico.
   • ENVIE UMA TRANSAÇÃO DE TESTE. Para pagamentos grandes ou importantes, envie primeiro uma quantia mínima. Confirme com o destinatário que ele recebeu antes de enviar o valor total.

2. Um Apelo por Carteiras Melhores:

   • Desenvolvedores de carteiras podem ajudar melhorando as interfaces de usuário. Isso inclui exibir mais do endereço por padrão ou adicionar avisos fortes e explícitos quando o usuário está prestes a enviar fundos para um endereço com o qual só interagiu via transferência mínima ou de valor zero.

3. A Solução a Longo Prazo:

   • Sistemas como o Ethereum Name Service (ENS), que permitem mapear um nome legível como seunome.eth ao seu endereço, podem eliminar esse problema completamente. A adoção mais ampla é fundamental.

No mundo descentralizado, você é seu próprio banco, o que também significa que você é seu próprio chefe de segurança. O envenenamento de endereço é uma ameaça silenciosa, porém poderosa, que se alimenta da conveniência e da desatenção. Ao ser deliberado e conferir duas vezes seu trabalho, você garante que seus ativos arduamente conquistados não acabem na armadilha de um fraudador.

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

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

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

Por que as Carteiras Matam a Conversão na Primeira Visita​

Você construiu um dApp inovador, mas seu funil de aquisição de usuários está vazando. O culpado quase sempre é o mesmo: o botão “Conectar Carteira”. O onboarding padrão Web3 é um labirinto de instalações de extensões, avisos de frase‑semente e quizzes de jargões cripto.

É uma barreira enorme para iniciantes. Pesquisadores de UX observaram um abandono impressionante de 87 % no momento em que o prompt de carteira aparece. Em um experimento revelador, simplesmente redirecionar esse prompt para uma fase posterior do checkout elevou a taxa de conclusão para 94 %. Mesmo para usuários curiosos sobre cripto, o medo principal é: “Posso perder meus fundos se clicar no botão errado.” Remover esse único passo intimidador é a chave para desbloquear um crescimento exponencial.

Como o zkLogin Funciona (em Português Simples)​

zkLogin contorna elegantemente o problema da carteira usando tecnologias que todo usuário de internet já confia. A mágica acontece nos bastidores em alguns passos rápidos:

1. Par de Chaves Efêmero: Quando o usuário quer fazer login, um par de chaves temporário, de sessão única, é gerado localmente no navegador. Pense nisso como uma chave‑passe temporária, válida apenas para esta sessão.
2. Dança OAuth: O usuário faz login com sua conta Google, Apple ou outra rede social. Seu app insere de forma inteligente um valor único (nonce) nessa solicitação de login.
3. Serviço ZKP: Após o login bem‑sucedido, um serviço de ZKP (Zero‑Knowledge Proof) gera uma prova criptográfica. Essa prova confirma, “Este token OAuth autoriza o proprietário da chave‑passe temporária,” sem jamais revelar a identidade pessoal do usuário on‑chain.
4. Derivar Endereço: O JWT (JSON Web Token) do provedor OAuth é combinado com um salt único para gerar determinísticamente o endereço Sui permanente do usuário. O salt permanece privado, seja no cliente ou em um backend seguro.
5. Submeter Transação: Seu app assina transações com a chave temporária e anexa a prova ZK. Os validadores Sui verificam a prova on‑chain, confirmando a legitimidade da transação sem que o usuário precise de uma carteira tradicional.

Guia de Integração Passo a Passo​

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

1. Instalar SDK​

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

pnpm add @mysten/sui

2. Gerar Chaves & Nonce​

Primeiro, crie um par de chaves efêmero e um nonce ligado ao epoch atual na rede Sui.

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

3. Redirecionar para OAuth​

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

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

Depois que o usuário fizer login e for redirecionado de volta, capture o id_token da URL. Use‑o para buscar o salt específico do usuário no seu backend e, então, derive o endereço Sui.

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

5. Solicitar Prova ZK​

Envie o JWT para um serviço provedor e obtenha a prova ZK. Para desenvolvimento, você pode usar o provedor público da Mysten. Em produção, hospede seu próprio provedor ou use um serviço como Enoki.

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

6. Assinar & Enviar​

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

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

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

7. Persistir Sessão​

Para uma experiência de usuário ainda mais fluida, criptografe e armazene o par de chaves e o salt no IndexedDB ou local storage. Lembre‑se de rotacioná‑los a cada alguns epochs para melhorar a segurança.

Modelo de Projeção de KPIs​

A diferença que o zkLogin traz não é apenas qualitativa; é quantificável. Compare um funil de onboarding típico com um alimentado por zkLogin:

👉 O que isso significa: Para uma campanha que gera 10 000 visitantes únicos, isso equivale a 300 ações on‑chain no primeiro dia versus mais de 2 500.

Boas Práticas & Armadilhas​

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

• Use Transações Patrocinadas: Pague as taxas das primeiras transações dos seus usuários. Isso elimina todo o atrito e entrega um momento “aha” incrível.
• Manuseie os Salts com Cuidado: Alterar o salt de um usuário gera um novo endereço. Só faça isso se você controlar um caminho de recuperação confiável.
• Exponha o Endereço Sui: Após o cadastro, mostre aos usuários seu endereço on‑chain. Isso capacita usuários avançados a importá‑lo para uma carteira tradicional, se desejarem.
• Previna Loops de Atualização: Cache o JWT e o par de chaves efêmero até que expirem, evitando solicitar login repetidamente.
• Monitore a Latência do Provedor: Fique de olho no tempo de ida‑e‑volta da geração da prova. Se ultrapassar 2 segundos, considere hospedar um provedor regional para manter a experiência ágil.

Onde a BlockEden.xyz Agrega Valor​

Enquanto o zkLogin aperfeiçoa o fluxo voltado ao usuário, escalar isso traz novos desafios de backend. É aí que a BlockEden.xyz entra.

• Camada API: Nossos nós RPC de alta taxa de transferência, roteados geograficamente, garantem que suas transações zkLogin sejam processadas com latência mínima, independentemente da localização do usuário.
• Observabilidade: Dashboards prontos para uso que monitoram métricas chave como latência de prova, razões de sucesso/falha e a saúde do seu funil de conversão.
• Conformidade: Para apps que fazem ponte para fiat, nosso módulo opcional de KYC oferece um on‑ramp compliance direto a partir da identidade verificada do usuário.

Pronto para Lançar?​

A era dos fluxos de carteira engessados e intimidador acabou. Crie um sandbox zkLogin, conecte‑se ao endpoint de full‑node da BlockEden e veja seu gráfico de cadastros subir — enquanto seus usuários nunca precisam ouvir a palavra “carteira”. 😉

1. Liquidez e Crescimento do DeFi da Sui​

Figura: TVL do DeFi da Sui (linha azul) e volume da DEX (barras verdes) cresceram dramaticamente até o Q2 de 2025.

Surto de Valor Total Bloqueado (TVL): A liquidez DeFi da rede Sui cresceu explosivamente ao longo do último ano. De aproximadamente $600 M de TVL no final de 2024, o TVL da Sui disparou para mais de $2 bi até meados de 2025. Na verdade, a Sui atingiu o pico de cerca de $2,55 bi de TVL em 21 de maio de 2025 e manteve‑se bem acima de $2 bi durante grande parte do Q2. Esse aumento de mais de 300 % (um crescimento de 480 % ano‑sobre‑ano desde maio de 2023) posiciona a Sui firmemente entre as top 10 blockchains por TVL DeFi, superando o crescimento de redes como Solana. Os principais catalisadores incluíram adoção institucional e a integração do suporte ao stablecoin USDC nativo, que juntos atraíram grandes fluxos de capital. Notavelmente, os volumes mensais de negociação DEX da Sui subiram para o topo de todas as cadeias – ultrapassando $7–8 bi por mês até meados de 2025 (classificando‑se em 8.º lugar no setor). A liquidez de stablecoins circulante na Sui ultrapassou $1 bi em meados de 2025, após crescer 180 % desde o início do ano, indicando um aprofundamento da liquidez on‑chain. Capital cross‑chain também está fluindo; cerca de $2,7 bi de ativos foram ponteados para o ecossistema Sui, incluindo liquidez de Bitcoin (detalhes abaixo). Essa tendência de crescimento rápido sublinha um ano de entradas líquidas e expansão de usuários para o DeFi da Sui.

Principais DEXs e Provedores de Liquidez: As exchanges descentralizadas são a espinha dorsal da liquidez DeFi da Sui. O protocolo Cetus – um market maker automatizado (AMM) e agregador – tem sido a DEX‑estrela, oferecendo swaps de stablecoins e pools de liquidez concentrada. O Cetus lidera consistentemente em volume (facilitando mais de $12,8 bi em negociações apenas no Q2 2025) enquanto mantém cerca de $80 M de TVL. Outro player chave é o Bluefin, uma DEX multifacetada que opera tanto um AMM spot quanto uma exchange de futuros perpétuos. O Bluefin expandiu suas ofertas em 2025 com recursos inovadores: lançou o BluefinX, o primeiro sistema RFQ (request‑for‑quote) da Sui para melhorar a execução de preços, e integrou otimizações de trading de alta frequência para reduzir a diferença entre desempenho de DEX e CEX. Até o Q2, o AMM do Bluefin detinha cerca de $91 M de TVL e registrou mais de $7,1 bi em volume spot trimestral. Momentum é outra DEX em ascensão – lançou um market maker de liquidez concentrada (CLMM) que rapidamente acumulou $107 M em liquidez, oferecendo um novo primitivo de exchange. O Bucket Protocol introduziu o BUCK, stablecoin over‑collateralizada semelhante ao DAI, mas para Sui. O Bucket mantém o peg a USD por meio de módulos de estabilidade on‑chain. O Bucket também oferece pools de liquidez para tokens como BTC, ETH e SUI. A Bucket tem TVL de aproximadamente $69 M, principalmente sustentando o BUCK. A Momentum também oferece opções de yield trading e recompensas de pontos, combinando gamificação com farming.

Abstração de Conta: A Sui implementou abstração de conta que permite que carteiras de camada‑2 e contratos inteligentes gerenciem a autenticação do usuário, reduzindo a necessidade de interações on‑chain complexas. Essa camada de usabilidade simplifica a experiência do usuário, permitindo login via wallets sociais, autenticação biométrica e até login via e‑mail, tudo sem expor chaves privadas.

Abstração de Conta: A Sui introduziu recursos de abstração de conta que permitem que carteiras de camada‑2 e contratos inteligentes gerenciem a autenticação do usuário, reduzindo a necessidade de interações on‑chain complexas. Essa camada de usabilidade simplifica a experiência do usuário, permitindo login via wallets sociais, autenticação biométrica e até login via e‑mail, tudo sem expor chaves privadas.

2. Abstração de Conta e Experiência do Usuário​

Recursos de Abstração de Conta: A Sui oferece login social, autenticação sem chave privada e RFQ (request‑for‑quote) integrado nas DEXs. Usuários podem conectar suas contas via Google, Apple ou Discord e negociar diretamente sem precisar assinar transações manualmente. Essa abordagem reduz drasticamente a fricção para novos usuários e abre caminho para adoção em massa.

Benefícios de Usabilidade: A abstração de conta elimina a necessidade de criar e gerenciar endereços de contrato complexos. Em vez disso, os usuários interagem com endereços de conta “smart” que podem ser atualizados, revogadas ou delegadas a serviços de custódia. Isso permite recuperação de conta, multisig e autorização baseada em tempo, tudo configurável via UI amigável.

2. Abstração de Conta e Experiência do Usuário​

Recursos de Abstração de Conta: A Sui oferece login social, autenticação sem chave privada e RFQ (request‑for‑quote) integrado nas DEXs. Usuários podem conectar suas contas via Google, Apple ou Discord e negociar diretamente sem precisar assinar transações manualmente. Essa abordagem reduz drasticamente a fricção para novos usuários e abre caminho para adoção em massa.

Benefícios de Usabilidade: A abstração de conta elimina a necessidade de criar e gerenciar endereços de contrato complexos. Em vez disso, os usuários interagem com endereços de conta “smart” que podem ser atualizados, revogados ou delegados a serviços de custódia. Isso permite recuperação de conta, multisig e autorização baseada em tempo, tudo configurável via UI amigável.

3. Próximas Primitivas e Inovações​

Stablecoins Nativas: Em 2024, a Agora Finance lançou o AUSD, o primeiro stablecoin 100 % lastreado em USD nativo da Sui. Até o Q2 2025, o supply de BUCK (stablecoin over‑collateralizada) atingiu $60–66 M, tornando‑se um dos maiores stablecoins nativos da Sui. A Ondo Finance introduziu o USDY, um stablecoin “yield‑bearing” que tokeniza rendimentos de títulos do Tesouro dos EUA.

Integração Bitcoin (BTCfi): Em 2025, a Sui incorporou tBTC da Threshold Network e sBTC da Stacks, trazendo mais de $500 M de liquidez Bitcoin para o ecossistema. Mais de 10 % do TVL da Sui passou a ser composto por ativos derivados de BTC, permitindo que holders de Bitcoin usem seus ativos como colateral em plataformas de empréstimo como a Suilend, que detinha $102 M em ativos baseados em Bitcoin até o Q2.

Primitivas Avançadas de DEX: Protocolos como Magma (ALMM) e Momentum (CLMM) continuam a melhorar a eficiência de capital. O Bluefin lançou estratégias de trading de alta frequência institucional, aproveitando a execução paralela da Sui para reduzir latência e melhorar throughput.

Novos Instrumentos Financeiros e Parcerias: O projeto Graviton, que levantou $50 M em Série A, está construindo uma plataforma modular de trading, lending e cross‑margining na Sui, comparável ao dYdX. Parcerias como xMoney/xPortal para lançar um MasterCard cripto‑potenciado e o pedido da 21Shares por um ETF SUI nos EUA demonstram a convergência entre CeFi e DeFi.

Resumo: Em 2025, o ecossistema DeFi da Sui está florindo com inovação. A liquidez atingiu níveis de múltiplos bilhões de dólares, sustentada por DEXs e lenders de grande porte, e impulsionada por fluxos constantes de capital e crescimento de usuários. Por meio da abstração de conta e do design centrado no usuário, a Sui melhorou drasticamente a experiência DeFi, atraindo um público mais amplo. Com a próxima onda de primitivas – stablecoins nativas, integração de Bitcoin, AMMs avançados, perps e tokens lastreados em ativos reais – a Sui está expandindo os limites do que é possível nas finanças descentralizadas, consolidando‑se como um hub DeFi líder até 2025, caracterizado por profunda liquidez, usabilidade fluida e inovação incessante em primitivas financeiras.

Fontes:

• Sui Foundation – Sui Q2 2025 DeFi Roundup (15 de julho de 2025)
• Sui Foundation – NEAR Intents Brings Lightning‑Fast Cross‑chain Swaps to Sui (17 de julho de 2025)
• Sui Foundation – Sui to Support sBTC and Stacks (BTCfi Use Cases) (1 de maio de 2025)
• Sui Foundation – All About Account Abstraction (4 de outubro de 2023)
• Ainvest News – Sui Network TVL Surpasses $1.4B Driven by DeFi Protocols (14 de julho de 2025)
• Ainvest News – Sui DeFi TVL Surges 480% to $1.8B... (12 de julho de 2025)
• Suipiens (comunidade Sui) – tBTC Integration Brings Bitcoin Liquidity to Sui (17 de julho de 2025)
• Suipiens – Inside Suilend: Sui’s Leading Lending Platform (3 de julho de 2025)
• The Defiant – Ondo to Bring RWA‑Backed Stablecoins onto Sui (7 de fevereiro de 2024)
• Documentação Oficial da Sui – Intro to Sui: User Experience (recursos de abstração de conta)

O relatório Estado das APIs de Blockchain 2025 (da BlockEden.xyz) oferece uma visão abrangente do cenário da infraestrutura de APIs de blockchain. Ele examina tendências emergentes, crescimento do mercado, principais provedores, blockchains suportadas, adoção por desenvolvedores e fatores críticos como segurança, descentralização e escalabilidade. Também destaca como os serviços de API de blockchain estão a impulsionar vários casos de uso (DeFi, NFTs, gaming, empresarial) e inclui comentários sobre as direções da indústria. Abaixo está um resumo estruturado das conclusões do relatório, com comparações dos principais provedores de API e citações diretas da fonte para verificação.

Tendências em Infraestrutura de API de Blockchain (2025)​

O ecossistema de APIs de blockchain em 2025 é moldado por várias tendências chave e avanços tecnológicos:

• Ecossistemas Multi-Chain: A era de uma única blockchain dominante acabou – existem centenas de Layer-1s, Layer-2s e chains específicas de aplicações. Provedores líderes como a QuickNode agora suportam ~15–25 chains, mas na realidade “quinhentas a seiscentas blockchains (e milhares de sub-redes) [estão] ativas no mundo”. Essa fragmentação impulsiona a demanda por infraestrutura que abstrai a complexidade e oferece acesso multi-chain unificado. Plataformas que adotam novos protocolos cedo podem ganhar a vantagem de serem as primeiras, à medida que chains mais escaláveis desbloqueiam novas aplicações on-chain e os desenvolvedores constroem cada vez mais em múltiplas chains. Apenas em 2023, ~131 ecossistemas de blockchain diferentes atraíram novos desenvolvedores, sublinhando a tendência multi-chain.

• Resiliência e Crescimento da Comunidade de Desenvolvedores: A comunidade de desenvolvedores Web3 permanece substancial e resiliente apesar dos ciclos de mercado. No final de 2023, havia mais de 22.000 desenvolvedores de cripto de código aberto ativos mensalmente, uma ligeira queda (~25% YoY) após o hype de 2021, mas notavelmente o número de desenvolvedores “veteranos” experientes cresceu ~15%. Isso indica uma consolidação de construtores sérios e de longo prazo. Esses desenvolvedores exigem infraestrutura confiável e escalável e soluções económicas, especialmente num ambiente de financiamento mais restrito. Com os custos de transação a cair nas principais chains (graças aos L2 rollups) e novas chains de alto débito a entrar em operação, a atividade on-chain está a atingir máximos históricos – alimentando ainda mais a demanda por serviços robustos de nós e APIs.

• Ascensão dos Serviços de Infraestrutura Web3: A infraestrutura de blockchain amadureceu para se tornar um segmento próprio, atraindo financiamento de risco significativo e provedores especializados. A QuickNode, por exemplo, distinguiu-se com alto desempenho (relatado como 2,5× mais rápido que alguns concorrentes) e SLAs de 99,99% de uptime, conquistando clientes empresariais como Google e Coinbase. A Alchemy alcançou uma avaliação de $10 B no pico do mercado, refletindo o entusiasmo dos investidores. Este influxo de capital estimulou a inovação rápida em nós geridos, APIs RPC, indexação/análise e ferramentas para desenvolvedores. Os gigantes tradicionais da nuvem (AWS, Azure, Google Cloud) também estão a entrar na arena com alojamento de nós de blockchain e serviços de ledger geridos. Isso valida a oportunidade de mercado, mas eleva o padrão para provedores menores cumprirem em termos de confiabilidade, escala e funcionalidades empresariais.

• Impulso para a Descentralização (Infraestrutura): Contrariando a tendência de grandes provedores centralizados, há um movimento em direção à infraestrutura descentralizada em linha com o ethos da Web3. Projetos como Pocket Network, Ankr e Blast (Bware) oferecem endpoints RPC através de redes de nós distribuídas com incentivos criptoeconómicos. Essas APIs descentralizadas podem ser económicas e resistentes à censura, embora muitas vezes ainda fiquem atrás dos serviços centralizados em desempenho e facilidade de uso. O relatório observa que “enquanto os serviços centralizados atualmente lideram em desempenho, o ethos da Web3 favorece a desintermediação.” A própria visão da BlockEden de um “marketplace de APIs” aberto com acesso sem permissão (eventualmente governado por token) alinha-se com este impulso, procurando combinar a confiabilidade da infraestrutura tradicional com a abertura das redes descentralizadas. Garantir um onboarding self-service aberto (por exemplo, planos gratuitos generosos, registo instantâneo de chave de API) tornou-se uma prática recomendada da indústria para atrair desenvolvedores de base.

• Convergência de Serviços e Plataformas One-Stop: Os provedores estão a ampliar as suas ofertas para além dos endpoints RPC básicos. Há uma demanda crescente por APIs aprimoradas e serviços de dados – por exemplo, dados indexados (para consultas mais rápidas), APIs GraphQL, APIs de token/NFT, painéis de análise e até integrações de dados off-chain ou serviços de IA. Por exemplo, a BlockEden fornece APIs de indexador GraphQL para Aptos, Sui e Stellar Soroban para simplificar consultas complexas. A QuickNode adquiriu ferramentas de API de NFT (por exemplo, Icy Tools) e lançou um marketplace de add-ons. A Alchemy oferece APIs especializadas para NFTs, tokens, transferências e até um SDK de abstração de conta. Esta tendência “one-stop-shop” significa que os desenvolvedores podem obter nós + indexação + armazenamento + análise de uma única plataforma. A BlockEden até explorou a “inferência de LLM sem permissão” (serviços de IA) na sua infraestrutura. O objetivo é atrair desenvolvedores com um conjunto rico de ferramentas para que não precisem de juntar vários fornecedores.

Tamanho do Mercado e Perspetivas de Crescimento (2025)​

O relatório traça um quadro de crescimento robusto para o mercado de API/infraestrutura de blockchain até 2025 e além:

• O mercado global de infraestrutura Web3 está projetado para crescer a aproximadamente 49% CAGR de 2024 a 2030, indicando um enorme investimento e demanda no setor. Isso sugere que o tamanho geral do mercado poderia duplicar a cada ~1,5–2 anos a essa taxa. (Para contexto, uma previsão externa da Statista citada no relatório estima que o ecossistema de ativos digitais mais amplo atingirá ~$45,3 mil milhões até o final de 2025, sublinhando a escala da economia cripto que a infraestrutura deve suportar.)

• A impulsionar este crescimento está a pressão sobre as empresas (tanto startups Web3 quanto empresas tradicionais) para integrar capacidades de cripto e blockchain. De acordo com o relatório, dezenas de indústrias Web2 (e-commerce, fintech, gaming, etc.) agora exigem funcionalidades de troca de cripto, pagamento ou NFT para se manterem competitivas, mas construir tais sistemas do zero é difícil. Os provedores de API de blockchain oferecem soluções chave na mão – desde APIs de carteira e transação até rampas de entrada/saída de fiat – que fazem a ponte entre os sistemas tradicionais e o mundo cripto. Isso reduz a barreira à adoção, alimentando mais demanda por serviços de API.

• A adoção empresarial e institucional de blockchain também está a aumentar, expandindo ainda mais o mercado. Regulamentações mais claras e histórias de sucesso de blockchain em finanças e cadeia de suprimentos levaram a mais projetos empresariais até 2025. Muitas empresas preferem não executar os seus próprios nós, criando oportunidades para provedores de infraestrutura com ofertas de nível empresarial (garantias de SLA, certificações de segurança, suporte dedicado). Por exemplo, a infraestrutura com certificação SOC2 da Chainstack com SLA de 99,9% de uptime e single sign-on atrai empresas que procuram confiabilidade e conformidade. Provedores que capturam esses clientes de alto valor podem aumentar significativamente a receita.

Em resumo, as perspetivas para 2025 são de forte crescimento para as APIs de blockchain – a combinação de uma base de desenvolvedores em expansão, o lançamento de novas blockchains, o aumento da atividade on-chain e a integração mainstream de serviços de cripto impulsionam a necessidade de infraestrutura escalável. Tanto empresas dedicadas à Web3 quanto gigantes da tecnologia estão a investir pesadamente para atender a essa demanda, indicando um mercado competitivo, mas recompensador.

Principais Provedores de API de Blockchain – Funcionalidades e Comparação​

Vários players chave dominam o espaço de APIs de blockchain em 2025, cada um com diferentes pontos fortes. O relatório da BlockEden compara a BlockEden.xyz (a anfitriã do relatório) com outros provedores líderes como Alchemy, Infura, QuickNode e Chainstack. Abaixo está uma comparação em termos de blockchains suportadas, funcionalidades notáveis, desempenho/uptime e preços:

Fontes: A comparação acima integra dados e citações do relatório da BlockEden.xyz, bem como funcionalidades documentadas dos sites dos provedores (por exemplo, documentação da Alchemy e da Chainstack) para precisão.

Cobertura de Blockchain e Suporte de Rede​

Um dos aspetos mais importantes de um provedor de API é quais blockchains ele suporta. Aqui está uma breve cobertura de chains populares específicas e como elas são suportadas:

• Ethereum Mainnet e L2s: Todos os principais provedores suportam Ethereum. A Infura e a Alchemy especializam-se fortemente em Ethereum (com dados de arquivo completos, etc.). QuickNode, BlockEden e Chainstack também suportam Ethereum como uma oferta principal. Redes de Layer-2 como Polygon, Arbitrum, Optimism, Base são suportadas pela Alchemy, QuickNode e Chainstack, e pela Infura (como add-ons pagos). A BlockEden suporta Polygon (e Polygon zkEVM) e provavelmente adicionará mais L2s à medida que surgirem.

• Solana: Solana é suportada pela BlockEden (eles adicionaram Solana em 2023), QuickNode e Chainstack. A Alchemy também adicionou RPC para Solana em 2022. A Infura não suporta Solana (pelo menos até 2025, permanece focada em redes EVM).

• Bitcoin: Sendo uma não-EVM, o Bitcoin é notavelmente não suportado pela Infura ou Alchemy (que se concentram em chains de contratos inteligentes). QuickNode e Chainstack oferecem acesso RPC ao Bitcoin, dando aos desenvolvedores acesso aos dados do Bitcoin sem executar um nó completo. A BlockEden atualmente não lista o Bitcoin entre as suas redes suportadas (foca-se em plataformas de contratos inteligentes e chains mais recentes).

• Polygon e BNB Chain: Estas populares sidechains do Ethereum são amplamente suportadas. Polygon está disponível na BlockEden, Alchemy, Infura (premium), QuickNode e Chainstack. BNB Smart Chain (BSC) é suportada pela BlockEden (BSC), QuickNode e Chainstack. (A Alchemy e a Infura não listam suporte para BSC, pois está fora do ecossistema Ethereum/consenso em que se focam.)

• Layer-1s Emergentes (Aptos, Sui, etc.): É aqui que a BlockEden.xyz brilha. Foi um dos primeiros provedores para Aptos e Sui, oferecendo APIs RPC e de indexador para estas chains da linguagem Move no seu lançamento. Muitos concorrentes não as suportaram inicialmente. Em 2025, alguns provedores como a Chainstack adicionaram Aptos e outras à sua lista, mas a BlockEden continua a ser altamente conceituada nessas comunidades (o relatório observa que a API GraphQL da BlockEden para Aptos “não pode ser encontrada em nenhum outro lugar” segundo os utilizadores). Suportar novas chains rapidamente pode atrair comunidades de desenvolvedores cedo – a estratégia da BlockEden é preencher as lacunas onde os desenvolvedores têm opções limitadas em novas redes.

• Chains Empresariais (Permissionadas): De forma única, a Chainstack suporta Hyperledger Fabric, Corda, Quorum e Multichain, que são importantes para projetos de blockchain empresariais (consórcios, ledgers privados). A maioria dos outros provedores não atende a estes, focando-se em chains públicas. Isso faz parte do posicionamento empresarial da Chainstack.

Em resumo, Ethereum e as principais chains EVM são universalmente cobertas, Solana é coberta pela maioria, exceto pela Infura, Bitcoin apenas por alguns (QuickNode/Chainstack), e L1s mais recentes como Aptos/Sui pela BlockEden e agora por alguns outros. Os desenvolvedores devem escolher um provedor que cubra todas as redes que a sua dApp precisa – daí a vantagem dos provedores multi-chain. A tendência para mais chains por provedor é clara (por exemplo, QuickNode ~14, Chainstack 50–70+, Blockdaemon 50+, etc.), mas a profundidade do suporte (robustez em cada chain) é igualmente crucial.

Adoção por Desenvolvedores e Maturidade do Ecossistema​

O relatório fornece insights sobre as tendências de adoção por desenvolvedores e a maturidade do ecossistema:

• Crescimento do Uso por Desenvolvedores: Apesar do mercado em baixa de 2022–2023, a atividade de desenvolvedores on-chain permaneceu forte. Com ~22k desenvolvedores ativos mensais no final de 2023 (e provavelmente a crescer novamente em 2024/25), a demanda por infraestrutura fácil de usar é constante. Os provedores estão a competir não apenas em tecnologia bruta, mas na experiência do desenvolvedor para atrair esta base. Funcionalidades como documentação extensa, SDKs e suporte comunitário são agora esperadas. Por exemplo, a abordagem centrada na comunidade da BlockEden (Discord, guilda 10x.pub, hackathons) e as iniciativas de educação da QuickNode visam construir lealdade.

• Adoção do Plano Gratuito: O modelo freemium está a impulsionar o uso generalizado na base. Quase todos os provedores oferecem um plano gratuito que cobre as necessidades básicas de projetos (milhões de requisições por mês). O relatório observa que o plano gratuito da BlockEden de 10M de CUs diários é deliberadamente alto para remover o atrito para desenvolvedores independentes. Os planos gratuitos da Alchemy e da Infura (cerca de 3–4M de chamadas por mês) ajudaram a integrar centenas de milhares de desenvolvedores ao longo dos anos. Esta estratégia semeia o ecossistema com utilizadores que podem mais tarde converter-se para planos pagos à medida que as suas dApps ganham tração. A presença de um plano gratuito robusto tornou-se um padrão da indústria – reduz a barreira de entrada, incentivando a experimentação e a aprendizagem.

• Número de Desenvolvedores nas Plataformas: A Infura historicamente teve o maior número de utilizadores (mais de 400k desenvolvedores há alguns anos), pois foi um dos primeiros padrões. A Alchemy e a QuickNode também desenvolveram grandes bases de utilizadores (o alcance da Alchemy através dos seus programas de educação e o foco da QuickNode em startups Web3 ajudaram-nos a inscrever muitos milhares). A BlockEden, sendo mais recente, relata uma comunidade de mais de 6.000 desenvolvedores a usar a sua plataforma. Embora menor em termos absolutos, isso é significativo dado o seu foco em chains mais recentes – indica uma forte penetração nesses ecossistemas. O relatório estabelece uma meta de duplicar os desenvolvedores ativos da BlockEden até o próximo ano, refletindo a trajetória geral de crescimento do setor.

• Maturidade do Ecossistema: Estamos a ver uma mudança de uma adoção impulsionada pelo hype (muitos novos desenvolvedores a entrar durante os bull runs) para um crescimento mais sustentável e maduro. A queda de desenvolvedores “turistas” após 2021 significa que os que permanecem são mais sérios, e os novos entrantes em 2024–2025 são frequentemente apoiados por um melhor entendimento. Esta maturação exige uma infraestrutura mais robusta: equipas experientes esperam SLAs de alto uptime, melhores análises e suporte. Os provedores responderam profissionalizando os serviços (por exemplo, oferecendo gestores de conta dedicados para empresas, publicando painéis de estado, etc.). Além disso, à medida que os ecossistemas amadurecem, os padrões de uso são mais bem compreendidos: por exemplo, aplicações pesadas em NFT podem precisar de otimizações diferentes (caching de metadados, etc.) do que bots de negociação DeFi (que precisam de dados da mempool e baixa latência). Os provedores de API agora oferecem soluções personalizadas (por exemplo, o já mencionado “Trader Node” da Chainstack para dados de negociação de baixa latência). A presença de soluções específicas da indústria (APIs de gaming, ferramentas de conformidade, etc., muitas vezes disponíveis através de marketplaces ou parceiros) é um sinal de um ecossistema em amadurecimento que serve diversas necessidades.

• Comunidade e Suporte: Outro aspeto da maturidade é a formação de comunidades de desenvolvedores ativas em torno destas plataformas. A QuickNode e a Alchemy têm fóruns comunitários e Discords; a comunidade da BlockEden (com mais de 4.000 construtores Web3 na sua guilda) abrange desde Silicon Valley a NYC e globalmente. Este suporte entre pares e a partilha de conhecimento aceleram a adoção. O relatório destaca o “suporte ao cliente excecional 24/7” como um ponto de venda da BlockEden, com os utilizadores a apreciar a capacidade de resposta da equipa. À medida que a tecnologia se torna mais complexa, este tipo de suporte (e documentação clara) é crucial para integrar a próxima onda de desenvolvedores que podem não estar tão familiarizados com os internos da blockchain.

Em resumo, a adoção por desenvolvedores está a expandir-se de forma mais sustentável. Provedores que investem na experiência do desenvolvedor – acesso gratuito, boa documentação, envolvimento da comunidade e suporte confiável – estão a colher os benefícios da lealdade e do boca a boca na comunidade de desenvolvedores Web3. O ecossistema está a amadurecer, mas ainda tem muito espaço para crescer (novos desenvolvedores a entrar da Web2, clubes de blockchain universitários, mercados emergentes, etc., são todos alvos mencionados para o crescimento em 2025).

Considerações de Segurança, Descentralização e Escalabilidade​

O relatório discute como a segurança, a descentralização e a escalabilidade influenciam a infraestrutura de API de blockchain:

• Confiabilidade e Segurança da Infraestrutura: No contexto dos provedores de API, a segurança refere-se a uma infraestrutura robusta e tolerante a falhas (uma vez que estes serviços geralmente não custodiam fundos, os principais riscos são o tempo de inatividade ou erros de dados). Os principais provedores enfatizam alto uptime, redundância e proteção contra DDoS. Por exemplo, o SLA de 99,99% de uptime da QuickNode e o balanceamento de carga global destinam-se a garantir que uma dApp não fique offline devido a uma falha de RPC. A BlockEden cita o seu histórico de 99,9% de uptime e a confiança conquistada ao gerir $65M em ativos em staking de forma segura (implicando uma forte segurança operacional para os seus nós). A conformidade SOC2 da Chainstack indica um alto padrão de práticas de segurança e tratamento de dados. Essencialmente, estes provedores operam infraestrutura de nós de missão crítica, pelo que tratam a confiabilidade como primordial – muitos têm engenheiros de plantão 24/7 e monitorização em todas as regiões.

• Riscos de Centralização: Uma preocupação bem conhecida na comunidade Ethereum é a dependência excessiva de alguns provedores de infraestrutura (por exemplo, Infura). Se muito tráfego for canalizado através de um único provedor, interrupções ou má conduta da API podem impactar uma grande parte do ecossistema de aplicações descentralizadas. O cenário de 2025 está a melhorar aqui – com muitos concorrentes fortes, a carga está mais distribuída do que em 2018, quando a Infura era quase singular. No entanto, o impulso para a descentralização da infraestrutura visa, em parte, resolver isso. Projetos como a Pocket Network (POKT) usam uma rede de operadores de nós independentes para servir requisições RPC, removendo pontos únicos de falha. A contrapartida tem sido o desempenho e a consistência, mas está a melhorar. O modelo híbrido da Ankr (alguns centralizados, alguns descentralizados) visa igualmente descentralizar sem perder a confiabilidade. O relatório da BlockEden reconhece estas redes descentralizadas como concorrentes emergentes – alinhando-se com os valores da Web3 – mesmo que ainda não sejam tão rápidas ou amigáveis para os desenvolvedores como os serviços centralizados. Podemos ver mais convergência, por exemplo, provedores centralizados a adotar alguma verificação descentralizada (a visão da BlockEden de um marketplace tokenizado é uma dessas abordagens híbridas).

• Escalabilidade e Débito (Throughput): A escalabilidade é dupla: a capacidade das próprias blockchains de escalar (maior TPS, etc.) e a capacidade dos provedores de infraestrutura de escalar os seus serviços para lidar com volumes crescentes de requisições. No primeiro ponto, 2025 vê muitos L1s/L2s com alto débito (Solana, novos rollups, etc.), o que significa que as APIs devem lidar com cargas de trabalho intermitentes e de alta frequência (por exemplo, uma cunhagem popular de NFT em Solana pode gerar milhares de TPS). Os provedores responderam melhorando o seu backend – por exemplo, a arquitetura da QuickNode para lidar com milhares de milhões de requisições por dia, os nós “Ilimitados” da Chainstack e o uso de servidores na nuvem e bare-metal pela BlockEden para desempenho. O relatório observa que a atividade on-chain a atingir máximos históricos está a impulsionar a demanda por serviços de nós, pelo que a escalabilidade da plataforma de API é crucial. Muitos provedores agora exibem as suas capacidades de débito (por exemplo, os planos de nível superior da QuickNode que permitem milhares de milhões de requisições, ou a Chainstack a destacar “desempenho ilimitado” no seu marketing).

• Latência Global: Parte da escalabilidade é reduzir a latência através da distribuição geográfica. Se um endpoint de API estiver apenas numa região, os utilizadores em todo o mundo terão respostas mais lentas. Assim, nós RPC geodistribuídos e CDNs são padrão agora. Provedores como a Alchemy e a QuickNode têm centros de dados em vários continentes. A Chainstack oferece endpoints regionais (e até níveis de produtos especificamente para casos de uso sensíveis à latência). A BlockEden também opera nós em várias regiões para melhorar a descentralização e a velocidade (o relatório menciona planos para operar nós em regiões chave para melhorar a resiliência e o desempenho da rede). Isso garante que, à medida que as bases de utilizadores crescem em todo o mundo, o serviço escala geograficamente.

• Segurança de Dados e Requisições: Embora não seja explicitamente sobre APIs, o relatório aborda brevemente considerações regulatórias e de segurança (por exemplo, a pesquisa da BlockEden sobre a Lei de Certeza Regulatória de Blockchain indicando atenção a operações conformes). Para clientes empresariais, coisas como encriptação, APIs seguras e talvez certificações ISO podem ser importantes. Numa nota mais específica da blockchain, os provedores de RPC também podem adicionar funcionalidades de segurança como proteção contra frontrunning (alguns oferecem opções de retransmissão de TX privadas) ou tentativas automáticas para transações falhadas. A Coinbase Cloud e outros têm proposto funcionalidades de “retransmissão segura”. O foco do relatório é mais na confiabilidade da infraestrutura como segurança, mas vale a pena notar que, à medida que estes serviços se integram mais profundamente em aplicações financeiras, a sua postura de segurança (uptime, resistência a ataques) torna-se parte da segurança geral do ecossistema Web3.

Em resumo, a escalabilidade e a segurança estão a ser abordadas através de infraestrutura de alto desempenho e diversificação. O cenário competitivo significa que os provedores se esforçam pelo maior uptime e débito. Ao mesmo tempo, alternativas descentralizadas estão a crescer para mitigar o risco de centralização. A combinação de ambos provavelmente definirá a próxima fase: uma mistura de desempenho confiável com confiança descentralizada.

Casos de Uso e Aplicações que Impulsionam a Demanda por API​

Os provedores de API de blockchain atendem a uma vasta gama de casos de uso. O relatório destaca vários domínios que são notavelmente dependentes destas APIs em 2025:

• Finanças Descentralizadas (DeFi): As aplicações DeFi (DEXs, plataformas de empréstimo, derivados, etc.) dependem fortemente de dados de blockchain confiáveis. Elas precisam de obter o estado on-chain (saldos, leituras de contratos inteligentes) e enviar transações continuamente. Muitos dos principais projetos DeFi usam serviços como a Alchemy ou a Infura para escalar. Por exemplo, Aave e MakerDAO usam a infraestrutura da Alchemy. As APIs também fornecem dados de nós de arquivo necessários para análises e consultas históricas em DeFi. Com o DeFi a continuar a crescer, especialmente em redes de Layer-2 e implementações multi-chain, ter suporte de API multi-chain e baixa latência é crucial (por exemplo, bots de arbitragem beneficiam de dados da mempool e transações rápidas – alguns provedores oferecem endpoints dedicados de baixa latência por esta razão). O relatório implica que a redução de custos (através de L2s e novas chains) está a impulsionar o uso de DeFi on-chain, o que, por sua vez, aumenta as chamadas de API.

• NFTs e Gaming: Marketplaces de NFT (como o OpenSea) e jogos de blockchain geram um volume significativo de leitura (metadados, verificações de propriedade) e de escrita (cunhagem, transferências). O OpenSea é um cliente notável da Alchemy, provavelmente devido à API de NFT da Alchemy, que simplifica a consulta de dados de NFT em Ethereum e Polygon. A API de NFT cross-chain da QuickNode também se destina a este segmento. Os jogos de blockchain geralmente são executados em chains como Solana, Polygon ou sidechains específicas – provedores que suportam essas redes (e oferecem manuseamento de alto TPS) estão em demanda. O relatório não nomeia explicitamente clientes de gaming, mas menciona projetos de gaming Web3 e metaverso como segmentos em crescimento (e o próprio suporte da BlockEden para coisas como integração de IA pode estar relacionado com aplicações de gaming/NFT no metaverso). As transações no jogo e os marketplaces fazem ping constantemente às APIs dos nós para atualizações de estado.

• Integração Empresarial e Web2: Empresas tradicionais que se aventuram na blockchain (pagamentos, cadeia de suprimentos, identidade, etc.) preferem soluções geridas. O relatório observa que plataformas de fintech e e-commerce estão a adicionar funcionalidades de pagamento e troca de cripto – muitas delas usam APIs de terceiros em vez de reinventar a roda. Por exemplo, processadores de pagamento podem usar APIs de blockchain para transferências de cripto, ou bancos podem usar serviços de nós para consultar dados da chain para soluções de custódia. O relatório sugere um interesse crescente por parte das empresas e até menciona visar regiões como o Médio Oriente e a Ásia, onde a adoção de blockchain empresarial está a aumentar. Um exemplo concreto: a Visa trabalhou com a QuickNode para alguns projetos piloto de blockchain, e a Meta (Facebook) usa a Alchemy para certos projetos de blockchain. Os casos de uso empresariais também incluem análise e conformidade – por exemplo, consultar a blockchain para análise de risco, o que alguns provedores acomodam através de APIs personalizadas ou suportando chains especializadas (como a Chainstack a suportar Corda para consórcios de financiamento comercial). O relatório da BlockEden indica que conseguir alguns estudos de caso empresariais é um objetivo para impulsionar a adoção mainstream.

• Startups Web3 e DApps: Claro, o caso de uso principal é qualquer aplicação descentralizada – de carteiras a dApps sociais e DAOs. As startups Web3 dependem de provedores de API para evitar a execução de nós para cada chain. Muitos projetos de hackathon usam os planos gratuitos destes serviços. Áreas como Redes Sociais Descentralizadas, ferramentas de DAO, sistemas de identidade (DID) e os próprios protocolos de infraestrutura precisam de acesso RPC confiável. A estratégia de crescimento da BlockEden no relatório menciona especificamente visar projetos em estágio inicial e hackathons globalmente – indicando que uma onda constante de novas dApps está a surgir, preferindo não se preocupar com operações de nós.

• Serviços Especializados (IA, Oráculos, etc.): Curiosamente, a convergência de IA e blockchain está a produzir casos de uso onde as APIs de blockchain e os serviços de IA se cruzam. A exploração da BlockEden de “AI-to-earn” (parceria com a Cuckoo Network) e a inferência de IA sem permissão na sua plataforma mostra um ângulo. Oráculos e serviços de dados (Chainlink, etc.) também podem usar a infraestrutura base destes provedores. Embora não seja um “utilizador” tradicional de APIs, estas camadas de infraestrutura por vezes constroem-se umas sobre as outras – por exemplo, uma plataforma de análise pode usar uma API de blockchain para recolher dados para fornecer aos seus utilizadores.

No geral, a demanda por serviços de API de blockchain é ampla – de desenvolvedores amadores a empresas da Fortune 500. DeFi e NFTs foram os catalisadores iniciais (2019–2021) que provaram a necessidade de APIs escaláveis. Em 2025, setores empresariais e novos setores Web3 (social, gaming, IA) estão a expandir ainda mais o mercado. Cada caso de uso tem os seus próprios requisitos (débito, latência, dados históricos, segurança) e os provedores estão a personalizar soluções para atendê-los.

Notavelmente, o relatório inclui citações e exemplos de líderes da indústria que ilustram estes casos de uso:

• “Mais de 1.000 moedas em 185 blockchains são suportadas… permitindo acesso a mais de 330k pares de negociação,” gaba-se um provedor de API de exchange – destacando a profundidade de suporte necessária para a funcionalidade de troca de cripto.
• “Um parceiro relatou um aumento de 130% no volume mensal de transações em quatro meses” após integrar uma API chave na mão – sublinhando como o uso de uma API sólida pode acelerar o crescimento de um negócio de cripto.
• A inclusão de tais insights sublinha que APIs robustas estão a permitir um crescimento real nas aplicações.

Insights e Comentários da Indústria​

O relatório da BlockEden está entrelaçado com insights de toda a indústria, refletindo um consenso sobre a direção da infraestrutura de blockchain. Alguns comentários e observações notáveis:

• Futuro Multi-chain: Como citado no relatório, “a realidade é que existem quinhentas a seiscentas blockchains” por aí. Esta perspetiva (originalmente do relatório de desenvolvedores da Electric Capital ou de uma fonte semelhante) enfatiza que o futuro é plural, não singular. A infraestrutura deve adaptar-se a esta fragmentação. Mesmo os provedores dominantes reconhecem isso – por exemplo, a Alchemy e a Infura (antes quase exclusivamente focadas em Ethereum) estão agora a adicionar múltiplas chains, e o capital de risco está a fluir para startups focadas no suporte a protocolos de nicho. A capacidade de suportar muitas chains (e de o fazer rapidamente à medida que novas surgem) é vista como um fator chave de sucesso.

• Importância do Desempenho: O relatório cita a vantagem de desempenho da QuickNode (2,5× mais rápida), que provavelmente vem de um estudo de benchmarking. Isso tem sido ecoado pelos desenvolvedores – a latência e a velocidade importam, especialmente para aplicações voltadas para o utilizador final (carteiras, plataformas de negociação). Os líderes da indústria frequentemente enfatizam que as aplicações web3 devem parecer tão fluidas quanto as web2, e isso começa com uma infraestrutura rápida e confiável. Assim, a corrida armamentista no desempenho (por exemplo, nós distribuídos globalmente, redes otimizadas, aceleração da mempool) deve continuar.

• Validação Empresarial: O facto de nomes conhecidos como Google, Coinbase, Visa, Meta estarem a usar ou a investir nestes provedores de API é uma forte validação do setor. É mencionado que a QuickNode atraiu grandes investidores como SoftBank e Tiger Global, e a avaliação de $10B da Alchemy fala por si. Os comentários da indústria por volta de 2024/2025 frequentemente notavam que as “pás e picaretas” da cripto (ou seja, a infraestrutura) eram uma aposta inteligente mesmo durante os mercados em baixa. Este relatório reforça essa noção: as empresas que fornecem os alicerces da Web3 estão a tornar-se empresas de infraestrutura críticas por direito próprio, atraindo o interesse de empresas de tecnologia tradicionais e VCs.

• Diferenciação Competitiva: Há uma visão matizada no relatório de que nenhum concorrente único oferece a combinação exata de serviços que a BlockEden oferece (APIs multi-chain + indexação + staking). Isso destaca como cada provedor está a criar um nicho: a Alchemy com ferramentas para desenvolvedores, a QuickNode com velocidade pura e amplitude, a Chainstack com foco em empresas/chains privadas, a BlockEden com chains emergentes e serviços integrados. Os líderes da indústria frequentemente comentam que o bolo está a crescer, então a diferenciação é a chave para capturar certos segmentos em vez de um cenário de vencedor leva tudo. A presença da Moralis (abordagem de SDK web3) e da Blockdaemon/Coinbase Cloud (abordagem pesada em staking) prova ainda mais o ponto – existem diferentes estratégias para a infraestrutura.

• Descentralização vs. Centralização: Líderes de pensamento no espaço (como Vitalik Buterin do Ethereum) têm levantado frequentemente preocupações sobre a dependência de APIs centralizadas. A discussão do relatório sobre a Pocket Network e outros espelha essas preocupações e mostra que mesmo as empresas que operam serviços centralizados estão a planear um futuro mais descentralizado (o conceito de marketplace tokenizado da BlockEden, etc.). Um comentário perspicaz do relatório é que a BlockEden visa oferecer “a confiabilidade da infraestrutura centralizada com a abertura de um marketplace” – uma abordagem provavelmente aplaudida pelos proponentes da descentralização, se alcançada.

• Clima Regulatório: Embora não seja o foco da questão, vale a pena notar que o relatório aborda questões regulatórias e legais de passagem (a menção da Lei de Certeza Regulatória de Blockchain, etc.). Isso implica que os provedores de infraestrutura estão de olho nas leis que podem afetar a operação de nós ou a privacidade de dados. Por exemplo, o GDPR da Europa e como se aplica aos dados dos nós, ou as regulamentações dos EUA sobre a execução de serviços de blockchain. Os comentários da indústria sobre isso sugerem que uma regulamentação mais clara (por exemplo, definir que provedores de serviços de blockchain não custodiais não são transmissores de dinheiro) impulsionará ainda mais o espaço, removendo a ambiguidade.

Conclusão: O Estado das APIs de Blockchain 2025 é um de um cenário de infraestrutura em rápida evolução e crescimento. As principais conclusões incluem a mudança para o suporte multi-chain, um campo competitivo de provedores, cada um com ofertas únicas, um crescimento massivo no uso alinhado com a expansão geral do mercado de cripto, e uma tensão (e equilíbrio) contínua entre desempenho e descentralização. Os provedores de API de blockchain tornaram-se facilitadores críticos para todos os tipos de aplicações Web3 – de DeFi e NFTs a integrações empresariais – e o seu papel só se expandirá à medida que a tecnologia blockchain se tornar mais ubíqua. O relatório sublinha que o sucesso nesta arena requer não apenas tecnologia forte e uptime, mas também envolvimento da comunidade, design focado no desenvolvedor e agilidade no suporte ao próximo grande protocolo ou caso de uso. Em essência, o “estado” das APIs de blockchain em 2025 é robusto e otimista: uma camada fundamental da Web3 que está a amadurecer rapidamente e preparada para um maior crescimento.

Fontes: Esta análise baseia-se no relatório Estado das APIs de Blockchain 2025 da BlockEden.xyz e dados relacionados. Os principais insights e citações foram retirados diretamente do relatório, bem como informações suplementares da documentação dos provedores e artigos da indústria para completude. Todos os links de fontes são fornecidos no texto para referência.