Por que há tantos Prop AMMs em Solana, mas ainda é um campo em branco no EVM?

Título original: Must-Watch dApps After Monad Mainnet Launch

Autor original: Optimus, fundador da Waterloo Blockchain

Tradução original: Dingdang, Odaily

Os Prop AMMs rapidamente conquistaram 40% de todo o volume de negociações na Solana. Por que eles ainda não apareceram no EVM?

Os Market Makers Automatizados Proprietários (Proprietary AMMs, ou Prop AMMs) estão rapidamente se tornando uma força dominante no ecossistema DeFi da Solana, atualmente respondendo por mais de 40% do volume de negociação dos principais pares. Esses locais de liquidez especializados, operados por market makers profissionais, conseguem oferecer liquidez profunda e preços mais competitivos, principalmente porque reduzem significativamente o risco de serem explorados por arbitradores que se aproveitam de “cotações expiradas” (stale quotes) para front-running.

Fonte da imagem: dune.com

No entanto, seu sucesso está quase totalmente restrito à Solana. Mesmo em redes Layer 2 rápidas e de baixo custo, como Base ou Optimism, ainda são raros os Prop AMMs no ecossistema EVM. Por que eles não se estabeleceram no EVM?

Este artigo explora três questões principais: o que são Prop AMMs, quais obstáculos técnicos e econômicos eles enfrentam nas chains EVM, e quais novas arquiteturas promissoras podem finalmente trazê-los para a vanguarda do DeFi EVM.

O que é um Prop AMM?

Um Prop AMM é um market maker automatizado em que a liquidez e a precificação são geridas ativamente por um único market maker profissional, ao contrário dos AMMs tradicionais, onde o público fornece liquidez de forma passiva.

Os AMMs tradicionais (como Uniswap v2) geralmente usam a fórmula x * y = k para determinar o preço, onde x e y representam as quantidades dos dois ativos no pool, e k é uma constante. Já nos Prop AMMs, a fórmula de precificação não é fixa, sendo atualizada em alta frequência (normalmente várias vezes por segundo). Como a maioria dos mecanismos internos dos Prop AMMs é uma “caixa preta”, o algoritmo exato não é conhecido externamente. No entanto, o código do contrato inteligente do Prop AMM Obric na Sui é público (graças à descoberta de @markoggwp), e sua constante k depende das variáveis internas mult_x, mult_y e concentration. A imagem abaixo mostra como o market maker atualiza continuamente essas variáveis.

É importante esclarecer: a fórmula à esquerda da curva de precificação do Obric é mais complexa que o simples x*y, mas o ponto-chave para entender o Prop AMM é que ela sempre equivale a uma constante k variável, que o market maker atualiza continuamente para ajustar a curva de preços.

Revisão: Como um AMM determina o preço?

Neste artigo, mencionaremos várias vezes o conceito de “curva de preços”. A curva de preços determina o preço que o usuário paga ao negociar em um AMM, e é justamente a parte que o market maker atualiza continuamente em um Prop AMM. Para entender melhor, vamos revisar como os AMMs tradicionais definem preços.

Tomando como exemplo o pool WETH-USDC na Uniswap v2 (supondo taxa zero). O preço é determinado passivamente pela fórmula x * y = k. Suponha que o pool tenha 100 WETH e 400.000 USDC, então o ponto da curva é x = 100, y = 400.000, e o preço inicial é 400.000 / 100 = 4.000 USDC/WETH. Assim, k = 100 * 400.000 = 40.000.000.

Se um trader quiser comprar 1 WETH, ele precisa adicionar USDC ao pool, reduzindo o WETH para 99. Para manter k constante, o novo ponto (x, y) deve estar na curva, então y deve ser 40.000.000 / 99 ≈ 404.040,40. Ou seja, o trader pagou cerca de 4.040,40 USDC por 1 WETH, um pouco acima do preço inicial. Esse fenômeno é chamado de “slippage”. É por isso que x*y=k é chamada de “curva de preços”: qualquer preço negociável deve estar nessa curva.

Por que os market makers escolhem AMMs em vez de order books centralizados (CLOB)?

Vamos explicar por que os market makers preferem usar AMMs. Imagine que você é um market maker cotando preços em um order book centralizado on-chain (CLOB). Para atualizar suas cotações, você teria que cancelar e substituir milhares de ordens limitadas. Se você tem N ordens, atualizar custa O(N), o que é lento e caro on-chain.

Mas e se você pudesse expressar todas as cotações com uma única curva matemática? Você só precisaria atualizar alguns parâmetros dessa curva, reduzindo a complexidade de O(N) para O(1).

Para ilustrar como a “curva de preços” corresponde a diferentes faixas de preço efetivo, podemos olhar para o SolFi, criado pela Ellipsis Labs — um Prop AMM baseado em Solana. Embora sua curva de preços específica seja desconhecida e oculta, a Ghostlabs desenhou um gráfico mostrando, em um determinado slot da Solana, o preço efetivo de diferentes quantidades de SOL trocadas por USDC. Cada linha representa um pool WSOL/USDC diferente, mostrando que múltiplos níveis de preço podem coexistir. À medida que o market maker atualiza a curva de preços, esse gráfico muda entre os slots.

Fonte da imagem: github

O ponto chave aqui é que, atualizando apenas alguns parâmetros da curva de preços, o market maker pode alterar a distribuição de preços efetivos a qualquer momento, sem precisar modificar N ordens individualmente. Esse é o valor central do Prop AMM — ele permite que market makers ofereçam liquidez dinâmica e profunda com muito mais eficiência de capital e computacional.

Por que a arquitetura da Solana é ideal para Prop AMMs?

Prop AMM é um sistema “gerido ativamente”, o que exige duas condições essenciais:

1. Atualizações baratas (cheap updates)

2. Execução prioritária (priority execution)

Na Solana, esses dois fatores andam juntos: atualizações baratas geralmente significam que a atualização pode obter prioridade de execução.

Por que os market makers precisam disso? Primeiro, eles atualizam a curva de preços constantemente, acompanhando mudanças no inventário ou no preço de referência do ativo (por exemplo, preço em exchanges centralizadas), na velocidade da blockchain. Em chains de alta frequência como a Solana, se o custo de atualização for alto, ajustes frequentes se tornam inviáveis.

Segundo, se o market maker não conseguir que sua atualização fique no topo do bloco, suas cotações antigas podem ser “capturadas” por arbitradores, gerando perdas inevitáveis. Sem essas duas características, o market maker não consegue operar eficientemente e os usuários têm preços piores.

Por exemplo, no Prop AMM HumidiFi da Solana, segundo dados da @SliceAnalytics, o market maker atualiza as cotações até 74 vezes por segundo.

Usuários do EVM podem perguntar: “O slot da Solana dura cerca de 400ms, como o Prop AMM pode atualizar o preço várias vezes em um único slot?”

A resposta está na arquitetura contínua da Solana, que é fundamentalmente diferente do modelo de blocos discretos do EVM.

· EVM: As transações são executadas em ordem após o bloco completo ser proposto e confirmado. Atualizações enviadas no meio só entram no próximo bloco.

· Solana: O validador líder não espera o bloco completo, mas divide as transações em pequenos pacotes (“shreds”) e os transmite continuamente pela rede. Um slot pode ter várias trocas, mas o shred #1 atualiza o preço para swap #1, o shred #2 para swap #2, etc.

Nota: Flashblocks são semelhantes aos shreds da Solana. Segundo @Ashwinningg da Anza Labs, cada slot de 400ms suporta até 32.000 shreds, ou 80 shreds por milissegundo. Se os Flashblocks de 200ms são rápidos o suficiente para os market makers, comparado à arquitetura contínua da Solana, ainda é uma questão em aberto.

Então, por que as atualizações na Solana são tão baratas? E como isso leva à execução prioritária?

Primeiro, embora a implementação dos Prop AMMs na Solana seja uma caixa preta, existem bibliotecas como a Pinocchio, que permitem escrever programas Solana otimizados para uso de Compute Units (CU). O blog da Helius explica como, usando essa biblioteca, o consumo de CU pode cair de cerca de 4.000 para cerca de 100 CU.

Fonte da imagem: github

Agora, a segunda parte. Em um nível mais alto, a Solana prioriza as transações com a maior razão Fee / Compute Units (Compute Units são como o Gas do EVM), similar ao EVM.

· Especificamente, se usar Jito, a fórmula é Jito Tip / Compute Units

· Sem Jito: Priority = (taxa prioritária + taxa base) / (1 + CU máximo + CU de assinatura + CU de write lock)

Comparando o uso de Compute Units de uma atualização de Prop AMM com um swap Jupiter, vemos que a atualização é extremamente barata, com uma razão de 1:1000.

Atualização de Prop AMM: Atualização de curva simples é muito barata. A atualização da Wintermute chega a 109 CU, com custo total de apenas 0.000007506 SOL

Jupiter Swap: Um swap roteado pelo Jupiter pode chegar a ~100.000 CU, com custo total de 0.000005 SOL

Devido a essa enorme diferença, os market makers podem pagar uma taxa mínima por atualização e ainda assim garantir uma razão Fee/CU muito maior que as trocas, assegurando execução no topo do bloco e protegendo-se contra arbitragem.

Por que os Prop AMMs ainda não foram implementados no EVM?

Suponha que a atualização de um Prop AMM envolva escrever variáveis que determinam a curva de preços do par. Embora o código dos Prop AMMs na Solana seja uma “caixa preta” (os market makers querem manter suas estratégias confidenciais), podemos usar esse pressuposto para entender como o Obric implementa Prop AMM na Sui: as variáveis de cotação do par são escritas no contrato inteligente via função update.

Obrigado @markoggwp pela descoberta!

Com esse pressuposto, vemos que a arquitetura do EVM apresenta obstáculos significativos, tornando inviável o modelo de Prop AMM da Solana no EVM.

Relembrando, nas blockchains Layer 2 baseadas em OP-Stack (como Base e Unichain), as transações são ordenadas pela taxa prioritária por Gas (semelhante à ordenação Fee / CU da Solana).

No EVM, operações de escrita consomem muito Gas. Comparado à Solana, o custo de um SSTORE no EVM é impressionante:

· SSTORE (0 → não zero): ~22.100 gas

· SSTORE (não zero → não zero): ~5.000 gas

· Swap típico de AMM: ~200.000–300.000 gas

Nota: O Gas no EVM é semelhante ao Compute Unit na Solana. Os números acima assumem uma única escrita por transação (escrita fria), o que é razoável, pois normalmente não se enviam múltiplas atualizações em uma transação.

Ainda que a atualização seja mais barata que o swap, o uso de gas é apenas cerca de 10 vezes menor (atualizações podem envolver múltiplos SSTOREs), enquanto na Solana a razão é de cerca de 1000 vezes.

Isso leva a duas conclusões, tornando o modelo de Prop AMM da Solana mais arriscado no EVM:

1. O alto consumo de gas dificulta garantir prioridade para as atualizações, pois taxas prioritárias baixas não conseguem atingir uma razão alta de taxa/gas. Para garantir que a atualização fique no topo do bloco, é preciso pagar taxas mais altas, aumentando o custo.

2. O risco de arbitragem é maior no EVM, pois a razão entre o gas da atualização e do swap é apenas 1:10, enquanto na Solana é 1:1000. Isso significa que um arbitrador só precisa aumentar sua taxa prioritária em 10 vezes para superar a atualização do market maker, enquanto na Solana precisaria aumentar 1000 vezes. Com essa razão menor, é mais provável que arbitradores capturem cotações desatualizadas, pois o custo é baixo.

Algumas inovações (como o TSTORE do EIP-1153, para armazenamento temporário) oferecem escrita por cerca de 100 gas, mas esse armazenamento é temporário, válido apenas durante uma transação, não servindo para persistir atualizações de preço para swaps subsequentes (por exemplo, durante todo o bloco).

Como trazer Prop AMMs para o EVM?

Antes de responder, por que fazer isso: os usuários sempre querem melhores cotações, ou seja, negociações mais vantajosas. Prop AMMs no Ethereum e nas Layer 2 podem oferecer cotações competitivas que antes só estavam disponíveis na Solana ou em exchanges centralizadas.

Para viabilizar Prop AMMs no EVM, vamos lembrar um dos motivos do sucesso deles na Solana:

· Proteção no topo do bloco: Na Solana, as atualizações de Prop AMM ficam no topo do bloco, protegendo os market makers contra front-running. Isso ocorre porque o consumo de CU é mínimo, então mesmo taxas baixas resultam em uma razão alta de taxa/CU, especialmente em comparação com swaps.

Então, como trazer atualizações de Prop AMM para o topo dos blocos nas Layer 2 EVM? Existem duas opções: reduzir o custo de escrita ou criar um canal prioritário para atualizações de Prop AMM.

Devido ao problema de crescimento do estado no EVM, reduzir o custo de escrita não é viável, pois SSTORE barato levaria a ataques de spam no estado.

Propomos criar um canal prioritário para atualizações de Prop AMM. Esta é a solução viável e o foco deste artigo.

@MarkToda, da equipe Uniswap, propôs um novo método, usando contrato inteligente de armazenamento global + estratégia de construtor de bloco dedicada:

Funciona assim:

· Contrato de armazenamento global: Um contrato inteligente simples é implantado como armazenamento público de chave-valor. O market maker escreve os parâmetros da curva de preços nesse contrato (por exemplo, set(ETH-USDC_CONCENTRATION, 4000)).

· Estratégia do construtor: Este é o componente off-chain. O construtor de blocos identifica transações enviadas ao contrato de armazenamento global, reserva os primeiros 5–10% do gas do bloco para essas atualizações e as ordena por taxa, evitando spam.

Nota: As transações devem ser enviadas diretamente ao endereço do armazenamento global, caso contrário não há garantia de ficarem no topo do bloco.

Exemplo de algoritmo personalizado de construção de bloco pode ser visto em rblib.

Integração do Prop AMM: O contrato Prop AMM do market maker lê os dados da curva de preços do contrato de armazenamento global durante o swap para fornecer cotações.

Essa arquitetura resolve dois problemas:

1. Proteção: A estratégia do construtor cria um “canal rápido”, garantindo que todas as atualizações de preço sejam executadas antes das negociações no bloco, eliminando o risco de front-running.

2. Custo-benefício: O market maker não precisa competir com todos os usuários DeFi por taxas altas para ficar no topo do bloco, apenas dentro do mercado local de taxas reservado para atualizações, reduzindo drasticamente o custo.

As negociações dos usuários serão executadas com base na curva de preços definida pelo market maker na atualização inicial do bloco, garantindo cotações frescas e seguras. Esse modelo recria no EVM o ambiente de atualizações baratas e prioritárias da Solana, abrindo caminho para Prop AMMs no EVM.

No entanto, esse modelo também tem algumas desvantagens, que deixo para discussão ao final do artigo.

Conclusão

A viabilidade dos Prop AMMs depende de resolver um problema econômico central: atualizações baratas e execução prioritária para evitar front-running.

Embora a arquitetura padrão do EVM torne essas operações caras e arriscadas, novos designs oferecem abordagens diferentes para o problema. Combinando contratos inteligentes de armazenamento global on-chain e estratégias de construtor off-chain, é possível criar um “canal rápido” dedicado, garantindo execução no topo do bloco e estabelecendo um mercado local de taxas. Isso não só torna os Prop AMMs viáveis no EVM, como pode transformar todo o DeFi EVM que depende de atualizações de oráculos no topo do bloco.

Perguntas em aberto

· Será que a velocidade de 200ms dos Flashblocks no EVM é suficiente para competir com a arquitetura contínua da Solana?

· Na Solana, a maior parte do fluxo dos AMMs vem do agregador Jupiter, que oferece SDK para fácil integração. Mas nas Layer 2 EVM, o fluxo é disperso entre vários agregadores e não há SDK público — isso é um desafio para os Prop AMMs?

· Na Solana, as atualizações dos Prop AMMs consomem apenas cerca de 100 CU — como isso é implementado?

· O modelo de canal rápido garante apenas atualizações no topo do bloco. Se houver várias trocas em um Flashblock, como o market maker atualiza o preço entre elas?

· É possível escrever programas EVM otimizados em Yul ou Huff, semelhante à otimização Pinocchio na Solana?

· Como os Prop AMMs se comparam aos RFQs?

· Como evitar que o market maker ofereça uma cotação atraente no bloco N para atrair usuários e depois atualize para uma cotação ruim no bloco N+1? Como o Jupiter previne isso?

· O recurso Ultra Signaling do Jupiter Ultra V3 permite que Prop AMMs diferenciem tráfego nocivo de benigno e ofereçam cotações mais justas. Qual a importância desse tipo de agregador para Prop AMMs no EVM?

Link original