De Solana ao EVM: Um Novo Caminho para AMMs Proprietários

Os Prop AMMs conquistaram rapidamente 40% de todo o volume de negociação na Solana. Porque não estão disponíveis no EVM?

Os Proprietary AMMs (Prop AMMs) tornaram-se rapidamente protagonistas no ecossistema DeFi da Solana, sendo responsáveis por mais de 40% do volume de negociação em pares principais. Estes mercados especializados, geridos por market makers profissionais, oferecem liquidez profunda e preços competitivos, sobretudo ao reduzir a exposição dos market makers ao front-running por arbitradores que exploram cotações desatualizadas.

https://dune.com/the_defi_report/prop-amms

No entanto, o sucesso destes AMMs está praticamente restrito à Solana. Porque razão ainda não se afirmaram no ecossistema EVM, mesmo em Layer 2 rápidas e de baixo custo como Base ou Optimism?

Este artigo analisa o conceito de Prop AMMs, os obstáculos técnicos e económicos que enfrentam nas redes EVM, e apresenta uma arquitetura inovadora que poderá finalmente impulsioná-los no DeFi do EVM.

O que são Prop AMMs?

Um Prop AMM é um automated market maker em que a liquidez e os preços de um pool são geridos ativamente por um único market maker profissional, ao invés de serem fornecidos de forma passiva e pelo público.

Ao contrário dos AMMs tradicionais, que utilizam a equação x * y = k para definir preços (onde x e y são as quantidades dos dois ativos no pool e k é uma constante), os Prop AMMs recorrem a uma fórmula distinta, normalmente atualizada várias vezes por segundo. Por serem geralmente uma “caixa preta”, a fórmula usada por cada Prop AMM é desconhecida. Contudo, o código do smart contract do Prop AMM da Obric na Sui é público (graças ao @ markoggwp pela descoberta!), onde o invariante k depende das variáveis internas mult_x, mult_y e concentração. A imagem abaixo ilustra como o market maker atualiza constantemente estas variáveis.

Uma nota importante: o lado esquerdo da fórmula da curva de preços da Obric é mais complexo do que x * y, mas o ponto essencial para compreender os Prop AMMs é que é igual a um invariante k, que o market maker ajusta para modificar a curva de preços.

Recapitulação: Como são definidos os preços num AMM?

O termo “curva de preços” será recorrente neste artigo, pois determina o preço que o utilizador paga numa negociação via AMM e é o elemento que o market maker ajusta no seu Prop AMM para atualizar preços. Antes de aprofundar os Prop AMMs, é útil perceber como os preços são definidos num AMM. Considere um pool Uniswap v2 para WETH-USDC sem taxas. O preço é definido passivamente pela fórmula x * y = k, onde x e y são as quantidades dos dois ativos no pool e k é uma constante. Apenas os pontos da curva correspondem a preços possíveis que o utilizador pode pagar pela sua negociação.

Por exemplo, num pool WETH-USDC com 100 WETH e 400.000 USDC, o ponto atual na curva é x = 100 WETH, y = 400.000 USDC, e o preço inicial é 400.000 USDC / 100 WETH = 4.000 USDC por WETH. Ao calcular o produto constante k, obtemos xy = k = 40.000.000. Se um trader quiser comprar 1 WETH, adiciona USDC ao pool, reduzindo o saldo de WETH para 99. Para manter o valor constante k, o novo saldo de USDC deve ser 40.000.000 / 99 ≈ 404.040,40 USDC. O trader pagou, assim, 4.040,40 USDC por esse 1 WETH, um preço superior ao inicial de $4.000 devido ao impacto de preço (slippage). Por isso, a fórmula x y = k é também chamada de curva de preços, pois qualquer preço possível para esse pool corresponde a um ponto na curva.

Porque pode um Market Maker preferir um AMM em vez de um CLOB?

Vamos ilustrar porque um market maker pode optar por um AMM para market making. Imagine que é um market maker num Central Limit Order Book (CLOB) onchain. Para atualizar as suas cotações, tem de cancelar e substituir milhares de ordens limitadas individuais. Se tiver N ordens, trata-se de uma operação O(N) linear, lenta e dispendiosa em termos computacionais, especialmente onchain.

E se pudesse representar todas as suas cotações numa única curva matemática? Em vez de gerir N ordens distintas, bastaria atualizar alguns parâmetros que definem toda a curva. Isto transforma um problema O(N) num O(1) constante.

Para visualizar como uma curva de preços (ex. x*y = k) pode originar diferentes preços efetivos, vejamos o SolFi, o Prop AMM criado pela Ellipsis Labs. Embora a curva de preços seja desconhecida, a Ghostlabs produziu o gráfico abaixo que mostra o preço efetivo de SOL para USDC para diferentes quantidades de SOL a serem trocadas num dado slot da Solana. (Para leitores EVM, o número do slot é análogo ao número do bloco). Cada linha representa um pool WSOL/USDC distinto, mostrando como podem oferecer diferentes escalões de preços simultaneamente. À medida que o market maker atualiza a curva de preços, o gráfico de preços efetivos altera-se entre slots.

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

O ponto essencial é que, ao atualizar apenas alguns valores da curva de preços, o market maker pode alterar este gráfico de preços efetivos conforme pretender, em vez de atualizar N ordens diferentes. Esta é a proposta central dos Prop AMMs, permitindo ao market maker fornecer liquidez profunda e dinâmica com grande eficiência de capital e computacional.

Porque a arquitetura da Solana é ideal para Prop AMMs

Os Prop AMMs são geridos ativamente. Isto exige duas condições: atualizações baratas e execução prioritária. Na Solana, as atualizações baratas garantem execução prioritária.

Porque precisam os market makers destas duas condições? Primeiro, os market makers atualizam as suas curvas de preços à velocidade da rede, com base em fatores como inventário atual e variações no preço de índice do ativo (ex.: de exchanges centralizadas). Em redes rápidas como Solana, isto seria caro se as atualizações não fossem baratas.

Segundo, se o market maker não conseguir que a sua atualização seja processada no topo do bloco, as suas cotações desatualizadas serão “apanhadas” por arbitradores, causando perdas garantidas.

Sem ambas as condições, os market makers não operam eficientemente, resultando em piores preços para o utilizador.

Por exemplo, Prop AMMs da Solana como HumidiFi atualizam as suas cotações 74 vezes por segundo (dados de @ SliceAnalytics), como mostra a imagem abaixo:

https://dune.com/queries/5980584/9644764

Vindo do universo EVM, pode-se perguntar: “Se os slots da Solana duram ~400ms, como pode um Prop AMM atualizar o preço várias vezes num único slot?”

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

• EVM: As transações são geralmente executadas sequencialmente quando um bloco completo é proposto e finalizado. Uma atualização enviada a meio do bloco só será refletida no bloco seguinte.
• Solana: O validador líder não espera para construir um bloco completo. Divide as transações recebidas em pequenos pacotes (“shreds”) e transmite-os continuamente à rede. Podem ocorrer várias trocas num slot, mas uma atualização de preço no shred #1 afeta a troca #1, enquanto a atualização no shred #2 afeta a troca #2.

Nota: Soluções como Flashblocks são análogas aos shreds da Solana. Segundo @ Ashwinningg da Anza Labs, na conferência CBER, existe um limite de 32.000 shreds por slot de 400ms, ou seja, até 80 shreds por milissegundo! Se Flashblocks de 200ms são rápidos o suficiente para market makers, comparando com a arquitetura contínua da Solana, é uma questão em aberto.

Então, porque são as atualizações tão baratas na Solana e como isso garante execução prioritária?

Embora a implementação de Prop AMMs na Solana seja uma caixa preta, existem bibliotecas como Pinocchio para criar programas Solana otimizados em CU. O blog da Helius explica (aqui) como programas Solana podem passar de ~4000 CU para ~100 CU.

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

Em termos práticos, a Solana prioriza transações com maior relação Fee / Computer Units (Compute Units são análogas ao Gas do EVM), tal como no EVM.

• Com Jito, a fórmula é Jito Tip / Compute Units,
• sem Jito, Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) (https://solana.com/docs/core/fees)

Comparando os Compute Units de uma atualização de Prop AMM e de um Jupiter Swap, vemos que uma atualização de Prop AMM é extremamente barata, com uma relação de 1 para 1000.

Atualização Prop AMM: Uma simples atualização de curva pode custar apenas 109 CU, com uma taxa total de 0,000007506 SOL

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Jupiter Swap: Uma troca via Jupiter pode custar até ~100.000 CU. A taxa total para esta tx foi de 0,000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

Com esta diferença, o market maker pode garantir execução prioritária para as suas atualizações ao pagar uma pequena taxa, atingindo uma relação Fee/CU muito superior à de um swapper. Isto garante que a atualização é executada de forma barata e no topo do bloco, protegendo contra arbitragem tóxica.

Porque não estão os Prop AMMs já disponíveis no EVM?

Suponhamos que as atualizações de um Prop AMM consistem em escrever variáveis que definem a curva de preços de um par de negociação. Embora o código dos Prop AMMs na Solana seja uma caixa preta, onde os market makers preservam o segredo da sua vantagem, esta suposição é válida após observarmos a implementação do Prop AMM da Obric na Sui, onde as variáveis que definem a cotação dos pares são escritas no smart contract via funções de atualização.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

Menção ao @ markoggwp pela descoberta!

Com esta suposição, a arquitetura do EVM apresenta um obstáculo significativo que torna o modelo Prop AMM da Solana inviável.

Recorde que em blockchains Layer 2 OP-Stack como Base e Unichain, as transações são ordenadas por Priority Fee por Gas (tal como na Solana, por Fee / CU).

No EVM, o consumo de gas para escritas é elevado. Um simples armazenamento via SSTORE é muito mais caro do que uma atualização na Solana.

• SSTORE (zero para não-zero): ~22.100 gas
• SSTORE (não-zero para não-zero): ~5.000 gas
• Swap num AMM típico: ~200.000 - 300.000 gas

O Gas no EVM é análogo aos Compute Units na Solana.

Os valores de gas do SSTORE assumem apenas 1 escrita por transação (cold writes), o que é razoável pois não se enviaria mais do que uma atualização por transação.

Embora uma atualização seja mais barata que um swap, a relação de consumo é apenas ~10x (uma atualização pode usar múltiplos SSTOREs), comparando com ~1000x na Solana.

Daqui resultam dois problemas que tornam o modelo Prop AMM da Solana mais arriscado no EVM.

1. Como o consumo de gas é alto, uma priority fee pequena não resulta numa Priority Fee / Gas elevada. Para garantir que a atualização não seja front-run e esteja no topo do bloco, será necessária uma priority fee maior, tornando-a mais cara.
2. Como a relação entre gas de atualização e swap no EVM é apenas 1:10, em vez de 1:1000 na Solana, um arbitrador no EVM só precisa aumentar a sua Priority Fee em 10x para superar e fazer front-run à atualização do market maker, enquanto na Solana seria necessário 1000x. Neste contexto, um arbitrador tem mais probabilidade de fazer front-run a uma atualização de preço para aproveitar cotações desatualizadas, pois o custo é menor.

Inovações como o EIP-1153 (TSTORE para armazenamento transitório) permitem escritas de 100-gas, mas este armazenamento é efémero e só dura uma transação. Não pode ser usado para persistir uma atualização de preço para um swap subsequente (ex.: durante um bloco).

Como podemos trazer Prop AMMs para o EVM?

Antes de responder, vejamos o “porquê”. Os utilizadores procuram sempre melhores cotações nas suas negociações, pois isso significa obter melhores condições. Prop AMMs na Ethereum e em blockchains Layer 2 permitiriam cotações mais competitivas, que atualmente só existem na Solana e em exchanges centralizadas.

Para tornar os Prop AMMs viáveis no EVM, recordemos uma das razões para o seu sucesso na Solana:

• Atualizações Prop AMM no topo do bloco na Solana protegem o market maker de front-running. Estão no topo porque usam poucos Compute Units, e uma taxa baixa resulta numa relação Fee / CUs elevada, especialmente em comparação com swaps.

Como trazer atualizações Prop AMM no topo do bloco para Layer 2 EVM? Existem duas abordagens: reduzir o custo das escritas ou criar uma via prioritária para atualizações Prop AMM.

Reduzir o custo das escritas é improvável devido ao problema de crescimento do estado no EVM, onde SSTOREs baratos poderiam facilitar spam de estado.

Propomos criar uma via prioritária para atualizações Prop AMM.

Uma abordagem inovadora, sugerida por @ MarkToda da equipa Uniswap, propõe um smart contract Global Storage (repositório) combinado com uma política de builder especializada.

https://github.com/flashbots/global-storage-smart-contract

Como funciona:

• Global Storage Contract: Um smart contract simples serve como armazenamento público chave-valor. Os market makers escrevem os parâmetros da curva de preços neste contrato (ex.: set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy: Este componente offchain é fundamental. Os block builders implementam uma política que reconhece transações enviadas para o endereço do Global Storage contract. A política reserva automaticamente os primeiros 5-10% do gas do bloco para estas transações de atualização, ordenando-as pela priority fee, para evitar spam.

É fundamental que a transação tenha “to” para o endereço do Global Storage, para evitar que transações que chamem outras funções de swap fiquem no topo do bloco.

• Abaixo, um exemplo de algoritmo de construção de blocos usando rblib.

• Integração Prop AMM: O smart contract do Prop AMM lê os dados da curva de preços do Global Storage contract no momento do swap, ao definir a cotação para o utilizador.

Esta arquitetura resolve ambos os problemas.

• Proteção: A política do builder cria uma “faixa rápida” que garante que todas as atualizações de preços num bloco são executadas antes de qualquer swap, eliminando o risco de front-running dentro do mesmo bloco.
• Eficiência de custos: Os market makers deixam de competir contra todos os utilizadores DeFi para chegar ao topo do bloco com taxas de gas mais altas. Competem apenas contra outras transações de atualização num mercado de taxas local para a secção reservada do topo do bloco. Isto reduz drasticamente o custo de garantir execução prioritária.

O swap do utilizador é executado contra a curva de preços definida pela atualização do market maker no início do bloco, garantindo uma cotação atualizada e protegida. Este modelo recria o ambiente de atualização rápida e barata que permitiu aos Prop AMMs prosperar na Solana, abrindo caminho para uma nova era de eficiência de mercado no EVM.

Contudo, este modelo apresenta desvantagens que deixo para discussão no final do artigo.

Conclusão

A viabilidade dos Proprietary AMMs depende de resolver um problema económico central: a necessidade de execução prioritária barata para evitar front-running.

Embora a arquitetura padrão do EVM torne isto caro e arriscado, um novo design apresenta uma abordagem alternativa. Ao combinar um smart contract Global Storage onchain com uma política de builder offchain, é possível criar uma “faixa rápida” dedicada para atualizações de preços. Este modelo garante execução no topo do bloco para atualizações de oráculo, estabelecendo um mercado de taxas local e contido, resolvendo os principais obstáculos e tornando não só os Prop AMMs possíveis, mas potencialmente transformadores para todo o DeFi EVM que depende de atualizações de oráculo no topo do bloco.

Questões em aberto

• Prop AMMs no EVM a velocidades Flashblock de 200ms são suficientemente rápidos para competir com a arquitetura contínua da Solana?
• Na Solana, a maioria do orderflow para AMMs provém do agregador Jupiter, que fornece um SDK para ligação ao agregador. Nas Layer 2 EVM, o fluxo está disperso por vários agregadores sem SDK público. Isto é um desafio para Prop AMMs no EVM?
• Como são implementados os Prop AMMs para que as suas atualizações na Solana usem apenas ~100 CU?
• O modelo de faixa rápida proposto só contempla atualizações Prop AMM no topo do bloco. Com Flashblocks de 200ms, pode haver múltiplos swaps num Flashblock e o market maker pode querer atualizar o preço entre negociações. Como implementar isso?
• Podem linguagens como Yul ou Huff ser usadas para escrever programas EVM otimizados, à semelhança do uso da Pinocchio na Solana?
• Como se comparam Prop AMMs com RFQs?
• Como evitar que market makers apresentem uma cotação favorável no bloco N para atrair o utilizador, que envia a transação no bloco N+1, onde o market maker atualiza a cotação para uma menos favorável? Como previne isto o Jupiter?
• O Ultra V3 do Jupiter introduz o “Ultra Signaling” que permite distinguir entre fluxo tóxico e não-tóxico, oferecendo cotações 3 bps mais apertadas. Quão relevantes são estas funcionalidades de agregador para trazer Prop AMMs ao EVM?

P.S.: Procuro oportunidades para palestras em conferências sobre este tema. Se estiver ligado a eventos durante o Devconnect, contacte-me para discutir possibilidades!

Disclaimer:

1. Este artigo é uma reprodução de [0xOptimus]. Todos os direitos de autor pertencem ao autor original [0xOptimus]. Se tiver objeções a esta reprodução, contacte a equipa Gate Learn, que tratará do assunto prontamente.
2. Isenção de responsabilidade: As opiniões expressas neste artigo são da exclusiva responsabilidade do autor e não constituem aconselhamento de investimento.
3. As traduções do artigo para outros idiomas são realizadas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.