Porque é que o Solana está cheio de Prop AMMs enquanto o EVM permanece em branco?

Título do artigo original: dApps imperdíveis após o lançamento da rede principal Monad

Autor do artigo original: @0xOptimus

Tradução do artigo original: Dingdang, Odaily Planet Daily

Os AMM proprietários capturaram rapidamente 40% do volume total de negócios da Solana. Porque é que ainda não apareceram na EVM?

Os Criadores de Mercado Automatizados Proprietários (Prop AMMs) estão rapidamente a tornar-se a força dominante no ecossistema Solana DeFi, contribuindo atualmente com mais de 40% do volume de negociação nos principais pares. Estes locais de liquidez operados por criadores de mercado profissionais podem proporcionar uma liquidez profunda e preços mais competitivos. A principal razão é que reduzem significativamente o risco de os criadores de mercado serem explorados por "cotações obsoletas" para conduzir arbitragem de front-running.

Fonte da imagem: dune.com

No entanto, o seu sucesso limitou-se quase inteiramente à Solana. Mesmo em redes de Camada 2 rápidas e de baixo custo, como a Base ou a Optimism, a presença de Prop AMMs no ecossistema EVM é rara. Porque é que não se enraizaram na EVM?

Este artigo explora principalmente três questões: o que são os Prop AMMs, as barreiras técnicas e económicas que enfrentam na cadeia EVM e as novas arquiteturas promissoras que podem eventualmente colocá-los na vanguarda do EVM DeFi.

O que são Prop AMMs?

Os AMM proprietários são um tipo de criador de mercado automatizado em que um único criador de mercado profissional gere ativamente a liquidez e os preços, em vez de ter fundos fornecidos passivamente pelo público, como nos AMM tradicionais.

Os AMM tradicionais (como o Uniswap v2) utilizam frequentemente a fórmula x * y = k para determinar o preço, em que x e y representam as quantidades dos dois ativos no pool e k é uma constante. Nos AMMs Prop, a fórmula de determinação do preço não é fixa, mas é atualizada com frequência (muitas vezes várias vezes por segundo). Como a mecânica interna da maioria dos AMMs Prop é considerada uma "caixa negra", o mundo externo não conhece o algoritmo exato que utilizam. No entanto, o código do contrato inteligente do AMM Prop na cadeia Sui da Obric é público (graças à descoberta de @markoggwp), onde a invariante k depende das variáveis internas mult_x, mult_y e concentração. A imagem abaixo mostra como o formador de mercado atualiza continuamente estas variáveis.

Um ponto que importa esclarecer é que a fórmula do lado esquerdo da curva de pricing de Obric é mais complexa do que um simples x*y. No entanto, a chave para compreender o Prop AMM é que equivale sempre a uma variável invariante k, e os fornecedores de liquidez atualizam continuamente este k para ajustar a curva de preços.

Análise: Como é que a AMM determina os preços?

Neste artigo, iremos mencionar o conceito de "curva de preço" várias vezes. A curva de preços determina o preço que os utilizadores precisam de pagar ao negociar utilizando um AMM e é a parte que os fornecedores de liquidez atualizam continuamente no Prop AMM. Para melhor compreender isto, podemos primeiro rever o mecanismo de determinação de preços de um AMM tradicional.

Tomando como exemplo o pool WETH-USDC no Uniswap v2 (assumindo que não existem taxas), o preço é determinado passivamente pela fórmula x * y = k. Assumindo que existem 100 WETH e 400.000 USDC no pool, o ponto da curva actual é x = 100, y = 400.000, correspondendo a um preço inicial de 400.000 / 100 = 4.000 USDC/WETH. Daqui resulta uma constante k = 100 * 400.000 = 40.000.000.

Se um trader quiser comprar 1 WETH, precisa de adicionar USDC ao pool, reduzindo o WETH no pool para 99. Para manter o produto k constante, o novo ponto (x, y) ainda deve estar na curva, pelo que y deve passar a ser 40.000.000 / 99 ≈ 404.040,40. Isto significa que o trader pagou cerca de 4.040,40 USDC por 1 WETH, um pouco acima do preço inicial. Este fenómeno é conhecido como "deslizamento de preço". É por isso que x*y=k é chamado de "curva de preço": qualquer preço negociável deve cair nesta curva.

Porque é que os fornecedores de liquidez escolhem o design de AMM em vez do livro de ordens centralizado (CLOB)?

Vamos explicar porque é que os fornecedores de liquidez desejam utilizar o design de AMM para fornecer liquidez. Imagine que é um formador de mercado a cotar num Livro de Ordens Limite Central (CLOB) on-chain. Se pretender atualizar a sua cotação, terá de cancelar e substituir milhares de ordens limite. Se tiver N ordens, o custo de actualização é uma operação O(N), que é lenta e dispendiosa em cadeia.

Mas e se pudesse representar todas as cotações com uma curva matemática? Simplesmente atualizando alguns parâmetros-chave que definem esta curva, pode transformar uma operação O(N) numa complexidade constante O(1).

Para demonstrar visualmente como a "Curva de Preço" corresponde a diferentes gamas de preços efetivas, podemos referir o SolFi criado pela Ellipsis Labs — um Prop AMM baseado no Solana. Embora a sua curva de preço específica seja desconhecida e oculta, a Ghostlabs criou um gráfico que mostra o preço efetivo ao trocar quantidades variáveis de SOL por USDC dentro de um determinado slot Solana (período de bloco). Cada linha representa um pool WSOL/USDC diferente, ilustrando que podem coexistir várias gamas de preços. À medida que o fornecedor de liquidez atualiza a curva de preços, este gráfico de preços efetivos também muda entre os diferentes slots.

Fonte da imagem: GitHub

O ponto-chave aqui é que, atualizando apenas alguns parâmetros da curva de preços, os fornecedores de liquidez podem alterar dinamicamente a distribuição efetiva dos preços a qualquer momento, sem terem de modificar cada uma das N ordens individualmente. Esta é precisamente a principal proposta de valor do Prop AMM — permite aos fornecedores de liquidez oferecer liquidez dinâmica e profunda com maior eficiência de capital e computacional.

Porque é que a arquitetura do Solana é ideal para o Prop AMM?

O Prop AMM é um sistema "ativamente gerido", o que significa que requer duas condições principais:

1. Baixos custos de atualização

2. Execução prioritária

Em Solana, estes dois aspetos estão interligados: as atualizações de baixo custo significam, muitas vezes, que as atualizações podem ter uma execução prioritária.

Mas porque é que os fornecedores de liquidez precisam destes dois pontos? Em primeiro lugar, atualizarão continuamente a curva de preços com base nas alterações de inventário ou nas flutuações nos preços dos índices de ativos (por exemplo, preços de exchanges centralizadas) à velocidade da blockchain. Numa blockchain de alta frequência como a Solana, se os custos de atualização forem demasiado elevados, realizar ajustes de alta frequência seria desafiante.

Em segundo lugar, se um fornecedor de liquidez não conseguir incluir a sua atualização no topo de um bloco, a sua cotação antiga será "preterida" pelos arbitradores, resultando em perdas inevitáveis. Sem estas duas características, os fornecedores de liquidez não podem operar eficientemente, e os utilizadores receberiam piores preços de negociação.

Utilizando o exemplo do Prop AMM HumidiFi em Solana, de acordo com os dados da @SliceAnalytics, o fornecedor de liquidez atualiza a sua cotação até 74 vezes por segundo.

Os jogadores vindos do EVM podem perguntar: "O slot de Solana é de aproximadamente 400 ms, como é que o Prop AMM pode atualizar o preço várias vezes num único slot?"

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

· EVM: As transações são normalmente executadas sequencialmente após um bloco completo ser proposto e finalmente confirmado. Isto significa que as atualizações enviadas no meio entram em vigor no bloco seguinte.

· Solana: Os nós Validadores Líderes não aguardam um bloco completo; em vez disso, dividem as transações em pequenos pacotes de dados (denominados "fragmentos") e transmitem-nos continuamente para a rede. Dentro de um slot, podem existir várias exchanges, mas a atualização de preço no fragmento nº 1 afeta o swap nº 1, e a atualização de preço no fragmento nº 2 afeta o swap nº 2.

Nota: Os flashblocks são semelhantes aos shreds da Solana. De acordo com @Ashwinningg, da Anza Labs, na conferência CBER, o limite do slot de 32.000 shreds a cada 400 ms equivale a 80 shreds por milissegundo. Se os Flashblocks de 200 ms são suficientemente rápidos para satisfazer os requisitos dos fornecedores de liquidez permanece uma questão em aberto em comparação com a arquitetura contínua da Solana.

Então, porque é que as atualizações sobre Solana são tão baratas? E o que leva à sua execução prioritária?

Em primeiro lugar, embora a implementação da Prop AMM no Solana seja uma caixa negra, existe uma biblioteca como a Pinocchio que optimiza a forma como as CUs são escritas nos programas Solana. O blog do Helius fornece uma explicação maravilhosa. Com esta biblioteca, o consumo de UC dos programas Solana pode ser reduzido de cerca de 4000 UC para aproximadamente 100 UC.

Fonte da imagem: github

Agora, vamos analisar a segunda parte. A um nível superior, a Solana prioriza as transações selecionando aquelas com a maior relação Taxa/Unidades de Computação (Unidades de Computação são semelhantes ao Gas da EVM), à semelhança da EVM.

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

· Caso contrário: Prioridade = (Gorjeta + Taxa Base) / (1 + Limite de CU + Assinatura CU + Bloqueio de Gravação CU)

Comparando as Unidades de Computação de uma actualização do Prop AMM com o Jupiter Swap, é evidente que a actualização é extremamente barata, com um rácio de 1:1000.

Atualização do Prop AMM: A atualização da curva simples é muito barata. A atualização do Wintermute custa apenas 109 CU, com um custo total de apenas 0,000007506 SOL.

Troca de Júpiter: Uma troca pela rota de Júpiter pode atingir ~100.000 CU, com um custo total de 0,000005 SOL

Devido a esta diferença significativa, os fornecedores de liquidez apenas têm de pagar uma taxa mínima pelas transações de atualização, conseguindo uma relação taxa/CU muito mais elevada do que as exchanges, garantindo que as atualizações são executadas no topo do bloco, protegendo-se de ataques de arbitragem.

Porque é que a Proposta AMM ainda não chegou ao EVM?

Assumindo que uma atualização do Prop AMM envolve a escrita numa variável que determina a curva de preço do par de ativos. Embora o código do Prop AMM em Solana seja uma "caixa negra", com os fornecedores de liquidez a quererem manter as suas estratégias confidenciais, podemos utilizar esta suposição para compreender como a Obric implementou o Prop AMM em Sui: a variável que determina o preço do par de ativos é gravada no contrato inteligente através de uma função de atualização.

Obrigado a @markoggwp pela descoberta!

Com esta suposição, encontramos uma barreira significativa na arquitetura do EVM que torna o modelo Prop AMM de Solana inviável no EVM.

Recorde-se que, nas blockchains OP-Stack Layer 2 (como Base e Unichain), as transações são priorizadas com base em taxas por gás (semelhante à classificação Fee/CU da Solana).

Na EVM, o custo de Gas das operações de gravação é extremamente elevado. Comparado com as atualizações da Solana, o custo de gravação de um valor na 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 típica de AMM: ~200.000–300.000 gás

Nota: O gás na EVM é semelhante às Unidades Computacionais (CUs) no Solana. Os números de gás SSTORE acima pressupõem que cada transação tem apenas uma gravação (gravação a frio), o que é razoável, dado que várias atualizações não são normalmente enviadas numa única transação.

Embora as atualizações ainda sejam mais baratas do que as trocas, a eficiência do gás é de apenas cerca de 10x (as atualizações podem envolver vários SSTOREs), enquanto no Solana, esta proporção é de cerca de 1000x.

Isto leva a duas conclusões que tornam o mesmo modelo Solana Prop AMM mais arriscado no EVM:

1. Os custos de gás elevados dificultam a garantia da prioridade de atualização: Taxas de gás mais baixas não garantem uma relação taxa/gás elevada. Para garantir que as atualizações não são antecipadas e colocadas no topo de um bloco, são necessárias taxas de gás mais elevadas, aumentando os custos.

2.º Maior risco de arbitragem na EVM: A relação entre a atualização do Gas e o swap de Gas na EVM é de apenas 1:10, enquanto na Solana é de 1:1000. Isto significa que os arbitradores precisam de aumentar as taxas em apenas 10x para antecipar a atualização de um fornecedor de liquidez, em comparação com 1000x na Solana. Neste cenário de rácio mais baixo, os arbitradores são mais propensos a antecipar as atualizações de preços para captar cotações obsoletas devido ao baixo custo.

Algumas inovações (como o TSTORE do EIP-1153 para armazenamento temporário) proporcionam um custo de gravação de cerca de 100 gás, mas este armazenamento é efémero, válido apenas dentro de uma única transação e não pode ser utilizado para persistir atualizações de preços para utilização posterior em negociações de derivados (por exemplo, durante todo o período de um bloco).

Como apresentar o Prop AMM ao EVM?

Antes de responder, vamos abordar o "porquê fazer isto": os utilizadores querem sempre melhores cotações de negociação, o que significa mais retorno do investimento. O Ethereum e o Prop AMM da Camada 2 podem fornecer aos utilizadores cotações competitivas que anteriormente só estavam disponíveis na Solana ou em corretores centralizados.

Para tornar a Proposta AMM viável no EVM, vamos rever uma das razões do seu sucesso em Solana:

· Proteção de atualização no topo do bloco: Na Solana, as atualizações do Prop AMM estão no topo do bloco para proteger os fornecedores de liquidez do front-running. As atualizações no topo são possíveis porque o custo unitário computacional é mínimo, permitindo que mesmo as taxas baixas atinjam uma elevada relação taxa/CU, especialmente em comparação com as negociações de derivados.

Então, como podemos introduzir atualizações do Prop AMM no topo do bloco numa blockchain EVM de Camada 2? Existem duas abordagens: reduzir o custo de gravação ou criar um canal prioritário para atualizações do Prop AMM.

Devido ao problema de crescimento de estado do EVM, a redução da abordagem de custo de escrita é menos viável, uma vez que SSTOREs baratos levariam a ataques de inchaço de estado.

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

@MarkToda, da Uniswap, propôs uma nova abordagem, alavancando uma estratégia de Contrato Inteligente de Armazenamento Global + Construtor de Blocos Dedicado:

Veja como funciona:

· Contrato de Armazenamento Global: Implemente um contrato inteligente simples como um repositório público de chave-valor. Os fornecedores de liquidez escrevem parâmetros de curva de preços para este contrato (por exemplo, set(ETH-USDC_CONCENTRATION, 4000)).

· Estratégia do Construtor: Este é um componente off-chain essencial. O construtor de blocos identifica as transações enviadas para o contrato de armazenamento global, aloca 5% a 10% do Gás do bloco a estas transações de atualização, prioriza-as por taxa e classifica-as para evitar transações de spam.

Nota: as transações devem ser enviadas diretamente para o endereço de armazenamento global para garantir a colocação no topo do bloco.

Exemplos de algoritmos de construção de blocos personalizados podem ser encontrados em rblib.

Integração do Prop AMM: O contrato do Prop AMM dos fornecedores de liquidez lê os dados da curva de preços do contrato de armazenamento global durante os swaps para fornecer cotações.

Esta arquitetura aborda habilmente duas questões:

1. Proteção: A estratégia do construtor cria uma "via rápida" para garantir que todas as atualizações de preços no bloco são executadas antes das transações, eliminando o risco de frontrunning.

2. Eficiência de custos: os fornecedores de liquidez já não competem com todos os utilizadores de DeFi pelos elevados preços do gás para chegar ao topo do bloco; em vez disso, apenas têm de competir pelo bloco superior reservado para as transações de atualização no mercado de taxas locais, reduzindo significativamente os custos.

As transações do utilizador serão executadas com base na curva de preços definida pelo fornecedor de liquidez no início do mesmo bloco, garantindo a atualização e a segurança das cotações. Este modelo replica o ambiente de atualização de baixo custo e alta prioridade da Solana na EVM, abrindo caminho para o Prop AMM na EVM.

No entanto, este modelo também apresenta algumas desvantagens, que deixarei no final deste artigo para discussão.

Conclusão

A viabilidade da Prop AMM depende da abordagem de uma questão económica central: execução barata e prioritária para evitar a corrida à liderança.

Embora a arquitetura EVM padrão torne estas operações dispendiosas e arriscadas, os novos designs oferecem abordagens diferentes para resolver este problema. Ao combinar contratos inteligentes de armazenamento global on-chain e a estratégia de construção off-chain no novo design, pode ser criada uma "via rápida" dedicada para garantir a execução de atualizações no topo do bloco, ao mesmo tempo que se estabelece um mercado de taxas local e controlado. Isto não só torna o Prop AMM viável no EVM, como também pode revolucionar todo o EVM DeFi que depende de atualizações de oráculos no topo do bloco.

Perguntas abertas

· A velocidade do Flashblock de 200 ms do Prop AMM no EVM é suficiente para competir com a arquitetura contínua do Solana?

· Em Solana, a maior parte do tráfego AMM provém de um único agregador chamado Júpiter, que fornece um SDK para uma fácil integração com o AMM. No entanto, na Camada 2 EVM, o tráfego é disperso por vários agregadores sem SDK público. Isto representa um desafio para o Prop AMM?

· Em Solana, as atualizações do Prop AMM consomem apenas cerca de 100 UC. Qual é o mecanismo de implementação por detrás desta eficiência?

· O modelo de caminho rápido garante atualizações apenas no topo de um bloco. Se existirem várias exchanges dentro de um Flashblock, como é que os fornecedores de liquidez atualizam os preços entre essas exchanges?

· É possível escrever programas EVM otimizados utilizando linguagens como Yul ou Huff, à semelhança da abordagem de otimização Pinóquio de Solana?

· Como é que o Prop AMM se compara com o RFQ?

· Como podemos evitar que os fornecedores de liquidez ofereçam cotações competitivas no Bloco N para atrair utilizadores e depois atualizem para cotações não competitivas no Bloco N+1? Como é que a Jupiter mitiga esse risco?

· A funcionalidade Ultra Signaling do Jupiter Ultra V3 permite ao Prop AMM diferenciar entre tráfego prejudicial e benigno, fornecendo cotações mais precisas. Qual a importância destes recursos agregadores para o Prop AMM no EVM?

Link da publicação original

Bem-vindo à comunidade oficial BlockBeats:

Grupo de subscrição do Telegram: https://t.me/theblockbeats

Grupo de discussão do Telegram: https://t.me/BlockBeats_App

Conta oficial no Twitter: https://twitter.com/BlockBeatsAsia