Título original: dApps Imperdíveis Após o Lançamento da Monad Mainnet
Autor do texto original: Optimus
Fonte original:
Reprodução: Mars Finance
Os AMMs de Prop rapidamente ocuparam 40% de todo o volume de negociações da Solana. Por que ainda não apareceram na EVM?
Os Market Makers Automáticos Proprietários (Proprietary AMMs, abreviados como Prop AMMs) estão rapidamente se tornando a força dominante no ecossistema DeFi da Solana, contribuindo atualmente com mais de 40% do volume de transações nas principais pares de negociação. Esses locais de liquidez especializados, operados por market makers profissionais, são capazes de fornecer liquidez profunda e preços mais competitivos, sendo que a razão principal para isso é a redução significativa do risco de arbitragem por “cotações desatualizadas” (stale quotes) que podem ser usadas para front-running.
No entanto, o seu sucesso está quase completamente limitado ao Solana. Mesmo em redes Layer 2 rápidas e de baixo custo, como a Base ou a Optimism, o Prop AMM ainda é raramente visto no ecossistema EVM. Por que eles não se enraizaram no EVM?
Este artigo explora principalmente três questões: o que são Prop AMM, quais obstáculos técnicos e econômicos enfrentam nas cadeias EVM, e novas arquiteturas promissoras que podem, em última análise, levá-los à vanguarda do DeFi EVM.
O que é Prop AMM?
O Prop AMM é um tipo de market maker automatizado gerido ativamente por um único market maker profissional que gere a liquidez e a precificação, ao contrário do AMM tradicional, que depende do público para fornecer fundos de forma passiva.
Os AMM tradicionais (como o Uniswap v2) normalmente utilizam a fórmula x * y = k para determinar preços, onde x e y representam respectivamente a quantidade de dois ativos no pool, e k é um valor constante. No entanto, no Prop AMM, a fórmula de preços não é fixa, mas é atualizada com alta frequência (geralmente várias vezes por segundo). Como a maioria dos mecanismos internos do Prop AMM são considerados “caixas pretas”, o exterior não sabe qual algoritmo exato eles utilizam. No entanto, o código do contrato inteligente do Prop AMM Obric na cadeia Sui é público (graças à descoberta de @markoggwp), e seu invariante k depende das variáveis internas mult_x, mult_y e concentration. A imagem abaixo mostra como os market makers atualizam continuamente essas variáveis.
Um ponto que precisa ser esclarecido é que a fórmula à esquerda da curva de preços do Obric é mais complexa do que simplesmente x*y, mas a chave para entender o Prop AMM é que ela é sempre igual a uma constante variável k, e os criadores de mercado atualizarão continuamente esse k para ajustar a curva de preços.
Revisão: Como o AMM determina o preço?
Neste artigo, iremos mencionar várias vezes o conceito de “curva de preços”. A curva de preços determina o preço que os usuários precisam pagar ao utilizar a negociação AMM, e também é a parte que os formadores de mercado atualizam constantemente no Prop AMM. Para entender melhor isso, podemos primeiro rever a forma como os preços são definidos no AMM tradicional.
Tomando como exemplo o pool WETH-USDC no Uniswap v2 (supondo que não haja taxas). O preço é determinado passivamente pela fórmula x * y = k. Supondo que haja 100 WETH e 400.000 USDC no pool, o ponto da curva é x = 100, y = 400.000, correspondendo a um preço inicial de 400.000 / 100 = 4.000 USDC/WETH. Assim, podemos obter a constante k = 100 * 400.000 = 40.000.000.
Se um trader quiser comprar 1 WETH, ele precisa adicionar USDC ao pool, fazendo com que a quantidade de WETH no pool diminua para 99. Para manter o produto constante k, o novo ponto (x, y) ainda precisa estar na curva, portanto y deve se tornar 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. Este fenômeno é chamado de “deslizamento de preço” (slippage). Esta é a razão pela qual x*y=k é chamado de “curva de preço”: qualquer preço negociável deve estar nesta curva.
Por que os market makers escolheriam o design AMM em vez do livro de ordens centralizado (CLOB)?
Vamos explicar por que os market makers desejam usar um design de AMM para fazer market making. Imagine que você é um market maker que está cotando em um livro de ordens limite central (CLOB) na blockchain. Se você quiser atualizar sua cotação, precisará cancelar e substituir milhares de ordens limite. Se você tiver N ordens, o custo de atualização é uma operação de nível O(N), o que é lento e caro na blockchain.
E se você pudesse representar todas as cotações com uma única curva matemática? Você só precisa atualizar alguns poucos parâmetros que definem essa curva, transformando a operação de O(N) em uma complexidade constante de O(1).
Para mostrar visualmente como a “curva de preços” corresponde a diferentes intervalos de preços válidos, podemos nos referir ao SolFi criado pela Ellipsis Labs - um AMM Prop baseado em Solana. Embora sua curva de preços específica seja desconhecida e esteja oculta, a Ghostlabs traçou um gráfico que mostra os preços válidos ao trocar diferentes quantidades de SOL por USDC dentro de um determinado slot do Solana (período de tempo de bloco). Cada linha representa um pool diferente de WSOL/USDC, indicando que múltiplos níveis de preços podem existir simultaneamente. À medida que os formadores de mercado atualizam a curva de preços, este gráfico de preços válidos também mudará entre diferentes slots.
O ponto chave aqui é que, ao atualizar apenas um pequeno número de parâmetros da curva de preços, os market makers podem alterar a distribuição de preços efetiva a qualquer momento, sem precisar modificar individualmente N ordens. Este é exatamente o valor central da proposta do Prop AMM - ele permite que os market makers ofereçam liquidez dinâmica e profunda com maior eficiência de capital e computacional.
Por que a arquitetura da Solana é muito adequada para o Prop AMM?
O Prop AMM é um sistema de “gestão ativa”, o que significa que requer duas condições-chave:
-
Atualizações de baixo custo (cheap updates)
-
Direito de execução prioritária
No Solana, estes dois são complementares: atualizações de baixo custo geralmente significam que as atualizações podem obter prioridade de execução.
Por que os market makers precisam desses dois pontos? Primeiro, eles atualizam continuamente a curva de preços com base nas mudanças de estoque ou nas flutuações do preço do índice de ativos (por exemplo, o preço das exchanges centralizadas) a uma velocidade de execução em blockchain. Em blockchains de alta frequência como a Solana, se o custo de atualização for muito alto, será difícil realizar ajustes de alta frequência.
Além disso, se os formadores de mercado não conseguirem que as atualizações fiquem no topo do bloco, suas cotações antigas serão “roubadas” por arbitradores, causando inevitáveis perdas. Se faltarem essas duas características, os formadores de mercado não poderão operar de forma eficiente, e os usuários também obterão preços de negociação piores.
Tomando o Prop AMM HumidiFi na Solana como exemplo, segundo dados da @SliceAnalytics, esse market maker atualiza os preços até 74 vezes por segundo.
Jogadores do EVM podem perguntar: “O slot da Solana é de aproximadamente 400ms, como é que o Prop AMM consegue atualizar o preço várias vezes dentro de um único slot?”
A resposta está na arquitetura contínua da Solana, que é essencialmente diferente do modelo de blocos discretos do EVM.
· EVM: As transações são geralmente executadas em ordem após o bloco completo ser proposto e finalmente confirmado. Isso significa que as atualizações enviadas no meio só entrarão em vigor no próximo bloco.
· Solana: Os nós de validação líderes não esperam por blocos completos, mas dividem as transações em pequenos pacotes de dados (chamados de “shred”) e os transmitem continuamente para a rede. Um slot pode conter várias transações, mas shred #1 的价格更新影响 swap #1, shred #2 的价格更新影响 swap #2.
Nota: Flashblocks é semelhante ao shred do Solana. De acordo com a apresentação de @Ashwinningg da Anza Labs na conferência CBER, cada slot de 400ms tem um limite de 32.000 shreds, o que equivale a 80 shreds por milissegundo. Quanto à rapidez dos Flashblocks de 200ms para atender à demanda dos market makers, ainda é uma questão em aberto em comparação com a arquitetura contínua do Solana.
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 do Prop AMM na Solana seja uma caixa-preta, existem bibliotecas como a Pinocchio que podem otimizar a maneira como os programas da Solana são escritos. O blog da Helius apresenta uma introdução brilhante sobre isso, através dessa biblioteca, o consumo de CU dos programas Solana pode ser reduzido de cerca de 4000 CU para cerca de 100 CU.
Agora, vejamos a segunda parte. Em um nível mais alto, a Solana prioriza as transações escolhendo aquelas com a maior taxa de Fee / Compute Units (Compute Units é semelhante ao Gas da EVM), semelhante à EVM.
· Especificamente, se usar Jito, a fórmula é Jito Tip / Unidades de Cálculo
· Não usar: Prioridade = ( taxa prioritária + taxa base ) / (1 + limite de CU + assinatura de CU + bloqueio de escrita de CU )
Comparando as unidades de computação da atualização do Prop AMM com o Jupiter Swap, pode-se ver que a atualização é extremamente barata, com uma proporção de 1:1000.
Atualização do Prop AMM: atualização de curva simples extremamente barata. A atualização da Wintermute custa apenas 109 CU, com um custo total de apenas 0.000007506 SOL.
Jupiter Swap: o swap através do roteador Jupiter pode chegar a ~100,000 CU, com uma taxa total de 0.000005 SOL
Devido a essa enorme diferença, os market makers apenas precisam pagar uma taxa muito pequena para atualizar as transações, conseguindo assim uma taxa Fee/CU muito superior à da troca, garantindo que as atualizações sejam executadas no topo do bloco, protegendo-se contra ataques de arbitragem.
Por que o Prop AMM ainda não foi implementado na EVM?
Suponha que a atualização do Prop AMM envolva a escrita de variáveis que determinam a curva de preços do par de negociação. Embora o código do Prop AMM na Solana seja uma “caixa-preta”, e os formadores de mercado queiram manter sua estratégia em segredo, podemos usar essa suposição para entender como a Obric implementa o Prop AMM na Sui: as variáveis que determinam a cotação do par de negociação são escritas no contrato inteligente através da função update.
Obrigado @markoggwp pela descoberta!
Usando essa suposição, descobrimos que a arquitetura do EVM apresenta obstáculos significativos que tornam o modelo Prop AMM da Solana inviável no EVM.
Revisando, nas blockchains OP-Stack Layer 2 (como Base e Unichain), as transações são ordenadas por taxa de prioridade por Gas (semelhante ao Solana que ordena por Fee / CU).
No EVM, o consumo de Gas para operações de escrita é muito alto. Em comparação com as atualizações do Solana, o custo de escrever um valor no EVM através do opcode SSTORE é impressionante:
· SSTORE（0 → não 0）：~22.100 gás
· SSTORE (não 0 → não 0): ~5.000 gás
· Troca AMM típica: ~200.000–300.000 gás
Nota: O Gas na EVM é semelhante à unidade de computação (CU) na Solana. O número de gas SSTORE acima assume que cada transação tem apenas uma escrita (escrita fria), o que é razoável, pois geralmente não se enviam várias atualizações em uma única transação.
Embora as atualizações ainda sejam mais baratas do que as trocas, a taxa de uso de gás é apenas cerca de 10 vezes (atualizações podem envolver várias SSTORE), enquanto na Solana essa proporção é de cerca de 1000 vezes.
Isto traz duas conclusões, tornando o mesmo modelo Solana Prop AMM mais arriscado na EVM:
-
O alto consumo de Gas torna difícil garantir taxas prioritárias para atualizações, e taxas prioritárias mais baixas não conseguem alcançar altas taxas de Gas. Para garantir que as atualizações não sejam executadas antes e fiquem no topo do bloco, são necessárias taxas prioritárias mais altas, o que aumenta os custos.
-
O risco de arbitragem na EVM é maior, a atualização de Gas e a proporção de Gas de troca na EVM é apenas 1:10, enquanto na Solana é de 1:1000. Isso significa que os arbitradores precisam apenas aumentar a taxa de prioridade em 10 vezes para ultrapassar as atualizações dos market makers, enquanto na Solana precisam aumentar em 1000 vezes. Com essa proporção mais baixa, os arbitradores têm maior probabilidade de antecipar as atualizações de preços para obter cotações atrasadas, uma vez que o custo é baixo.
Algumas inovações (como o TSTORE do EIP-1153, para armazenamento temporário) oferecem cerca de 100 gas para escrita, mas esse armazenamento é temporário, válido apenas em uma única transação, não podendo ser usado para persistir atualizações de preço para uso em transações de swap subsequentes (por exemplo, durante todo o bloco).
Como introduzir o Prop AMM no EVM?
Antes de responder, primeiro responda “por que fazer”: os usuários sempre esperam obter cotações de negociação melhores, o que significa que as transações são mais vantajosas. O Prop AMM de Ethereum e Layer 2 pode fornecer aos usuários cotações competitivas que normalmente só poderiam ser obtidas na Solana ou em exchanges centralizadas.
Para tornar o Prop AMM viável na EVM, vamos rever uma das razões pelas quais teve sucesso na Solana:
· Atualização de proteção no topo do bloco: na Solana, a atualização do Prop AMM está localizada no topo do bloco, podendo proteger os market makers de front-running. A atualização está no topo porque a unidade de cálculo consome muito pouco, e mesmo com taxas baixas, pode alcançar uma alta relação de taxas/CU, especialmente em comparação com negociações de swaps.
Então, como introduzir a atualização do Prop AMM no topo do bloco da blockchain EVM Layer 2? Existem duas maneiras: ou reduzir o custo de escrita, ou criar um canal de prioridade para a atualização do Prop AMM.
Devido ao problema de crescimento do estado do EVM, a abordagem de reduzir os custos de escrita não é muito viável, pois um SSTORE barato pode levar a ataques de estado lixo.
Nós propomos criar um canal prioritário para a atualização do Prop AMM. Esta é uma solução viável e também o foco deste artigo.
A equipe do Uniswap, @MarkToda, propôs um novo método que implementa: contratos inteligentes de armazenamento global + estratégia de construtores de blocos especializados.
O seu funcionamento é o seguinte:
· Contrato de armazenamento global: implantar contratos inteligentes simples como armazenamento público de chave-valor. Os market makers escrevem os parâmetros da curva de preços nesse contrato (por exemplo, set(ETH-USDC_CONCENTRATION, 4000)).
· Estratégia do construtor: Este é um componente chave off-chain. O construtor de blocos identifica as transações enviadas para o contrato de armazenamento global, aloca de 5 a 10% do Gas do bloco para essas transações de atualização e as classifica por prioridade de taxa, evitando transações de spam.
Por favor, note que as transações devem ser enviadas diretamente para o endereço de armazenamento global, caso contrário, não é garantido que fiquem no topo do bloco.
Exemplo de algoritmo de construção de bloco personalizado pode ser encontrado em rblib.
Integração de Prop AMM: O contrato Prop AMM do market maker lê os dados da curva de preços do contrato de armazenamento global durante a troca, a fim de fornecer cotações.
Esta arquitetura resolve de forma inteligente dois problemas:
-
Proteção: A estratégia do construtor cria um “canal rápido”, garantindo que todas as atualizações de preços dentro do bloco sejam executadas antes da negociação, eliminando o risco de front-running.
-
Custo-benefício: Os market makers não precisam mais competir com todos os usuários DeFi por transações no topo do bloco com preços de gás altos, apenas precisam competir no mercado local de taxas para garantir o topo do bloco para transações atualizadas, reduzindo significativamente os custos.
As transações dos usuários serão executadas com base na curva de preços definida na atualização inicial do mesmo bloco pelo formador de mercado, garantindo a frescura e a segurança das cotações. Este modelo reproduz um ambiente de atualizações de baixo custo e alta prioridade no EVM, abrindo caminho para o Prop AMM no EVM.
No entanto, este modelo também tem algumas desvantagens, que deixarei no final deste artigo para discussão.
Conclusão
A viabilidade do Prop AMM depende da resolução de problemas económicos centrais: execução barata e prioritária para prevenir front-running.
Embora a arquitetura EVM padrão torne essas operações caras e arriscadas, um novo design oferece uma abordagem diferente para resolver esse problema. A nova concepção que combina contratos inteligentes de armazenamento global em cadeia com estratégias de construtores fora da cadeia pode criar “canais rápidos” dedicados, garantindo a execução de atualizações no topo do bloco, enquanto estabelece um mercado de taxas local e controlado. Isso não apenas torna o Prop AMM viável na EVM, mas também pode trazer uma revolução para todo o EVM DeFi que depende de atualizações de oráculos no topo do bloco.
Pergunta aberta
· A velocidade de 200ms do Flashblock da Prop AMM na EVM é suficiente para competir com a arquitetura contínua da Solana?
· A maior parte do fluxo AMM na Solana vem de um único agregador, o Jupiter, que fornece um SDK para facilitar a integração do AMM. No entanto, na Layer 2 EVM, o fluxo está disperso em vários agregadores e não há um SDK público. Isso representa um desafio para o Prop AMM?
· A atualização do Prop AMM na Solana consome apenas cerca de 100 CU, como funciona o seu mecanismo de implementação?
· O modelo de canal rápido garante apenas a atualização do topo do bloco. Se houver várias trocas dentro de um Flashblock, como os market makers atualizam o preço entre essas trocas?
· É possível escrever programas EVM otimizados em linguagens como Yul ou Huff, semelhantes à solução de otimização Pinocchio na Solana?
· Como é a comparação entre Prop AMM e RFQ?
· Como evitar que os market makers ofereçam cotações de alta qualidade no bloco N para induzir os usuários e, em seguida, atualizem para cotações ruins no bloco N+1? Como o Jupiter se protege contra isso?
· A funcionalidade Ultra Signaling do Jupiter Ultra V3 permite que o Prop AMM diferencie entre tráfego nocivo e não nocivo, oferecendo cotações mais ajustadas. Qual a importância dessas características de agregador para o Prop AMM na EVM?
