O protocolo Ethereum e o ecossistema mais amplo têm como objetivo melhorar continuamente o valor que o Ethereum pode fornecer. Um gargalo-chave em todo o ecossistema para melhorar o Ethereum tem sido o Valor Extraível Máximo (MEV)MEV). MEV refere-se ao valor máximo que o agente do protocolo responsável por incluir, ordenar e excluir transações em um bloco pode extrair do sistema. Esta postagem resume os métodos propostos para mitigar os efeitos negativos do MEV em aplicativos e no protocolo, e investiga as futuras direções de pesquisa.

Este post está organizado da seguinte forma:

A primeira seção propõe uma categorização bidimensional de técnicas de mitigação de MEV fora do protocolo. Um exemplo de cada categoria é explorado.

A seção seguinte explora por que o protocolo Ethereum não pode funcionar como a infraestrutura que previne ou rebate MEV.

Em terceiro lugar, exploramos o que o protocolo Ethereum faz para evitar as externalidades negativas do MEV.

Finalmente, argumentamos que nenhuma das técnicas de mitigação de MEV discutidas, dentro ou fora do protocolo, pode resolver todos os problemas causados pelo MEV simultaneamente.

O início deste post funciona como uma sistemização parcial do conhecimento de mitigação de MEV. No entanto, a quarta seção apresenta um argumento relativamente novo de que a mitigação de MEV fora do protocolo não resolve os problemas de MEV no protocolo. Este argumento é baseado em um papelporDavide Crapise eu.

Esta postagem refere-se a técnicas de mitigação dentro e fora do protocolo. Com técnicas de mitigação MEV dentro do protocolo, queremos dizer mecanismos que fazem parte das regras do protocolo Ethereum ou que exigiriam a alteração das regras do protocolo Ethereum. Técnicas de mitigação fora do protocolo são todos os mecanismos que não estão dentro do protocolo.

Mitigação de MEV fora do protocolo

MEV impõe aluguel aos usuários que interagem com uma blockchain. Para aumentar o valor que o Ethereum facilita, é intuitivo diminuir o aluguel que o MEV representa. O objetivo das técnicas de mitigação de MEV fora do protocolo é diminuir o efeito inibidor de valor que o MEV representa sem alterar as regras do protocolo do Ethereum.

Vamos usar como exemplo como MEV é extraído em Automated Market Makers (AMMs) e, consequentemente, como pode ser mitigado. Muitas AMMs funcionam da seguinte forma:

Os provedores de liquidez (LPs) fornecem vários tokens diferentes a um AMM e permitem que o AMM defina os preços contra os quais os usuários podem negociar com os tokens do LP.

Um AMM ajusta seus preços apenas em resposta às transações incluídas em novos blocos. Esse ajuste discreto contrasta com as contínuas flutuações de preços dos tokens subjacentes nos mercados externos.

Quando um bloco precisa ser proposto, o produtor de bloco pode incluir transações que usam o preço de mercado externo publicamente observável para arbitrar as cotações obsoletas em uma AMM, extraindo assim MEV.

Esta forma de MEV, conhecida como Perda-Versus-Rebalanceamento (LVR), é um custo para provedores de liquidez. Mantendo as taxas que são pagas aos provedores de liquidez constantes, a quantidade de liquidez fornecida diminui com a quantidade de LVR extraído do AMM. Menos liquidez significa que as negociações dos usuários têm um impacto de preço maior, o que torna mais caro para os usuários negociarem no AMM. Um objetivo do design do AMM é diminuir o custo que o LVR impõe ao AMM. Da mesma forma, um objetivo do design de aplicativos, em geral, é diminuir o custo de MEV para os usuários.

Existem muitas maneiras pelas quais o custo do MEV pode ser reduzido. Em linhas gerais, as técnicas de mitigação do MEV fora do protocolo são divididas ao longo de dois eixos:

• Técnicas de mitigação de MEV de infraestrutura específica de aplicativo ou compartilhada.
• Prevenindo MEV ou reembolsando MEV.

O primeiro eixo é se um aplicativo mitiga MEV por si só ou depende de alguma infraestrutura compartilhada. O segundo eixo é mais complicado. Um aplicativo pode ser projetado para evitar a exposição do MEV em primeiro lugar ou pode vender o direito de extrair o MEV e reembolsar as receitas de vendas para aqueles extraídos. O reembolso do MEV usa ligeiramente a definição de MEV, que é o valor que o ator responsável por incluir, ordenar e excluir transações pode extrair do sistema. O MEV reembolsado não é extraído do sistema e, portanto, não se enquadra estritamente na definição de MEV. Ainda assim, usar o termo MEV pode ser útil, uma vez que todos os conceitos relacionados ao MEV se aplicam ao valor que é reembolsado, exceto para onde a receita vai. Veremos exemplos de todas as quatro possibilidades e discutiremos suas vantagens relativas.

Figura 1: Categorização bidimensional das técnicas de mitigação de MEV fora do protocolo com exemplos para cada categoria.

Especificidade de Aplicação e Prevenção de MEV: A Função Maximizando AMM.

A técnica de mitigação de MEV que geralmente é conceitualmente mais intuitiva para aqueles que ouvem falar de MEV pela primeira vez é uma aplicação que evita a exposição ao MEV. Um exemplo empolgante é o gate.função maximizando o AMMproposto porAndrea CanidioeRobin Fritsch. Ele agrupa as negociações coletadas ao longo de um período de tempo e executa tudo a um preço de compensação uniforme. Os autores mostram que elimina a RVP e a sanduíche, outra forma de MEV. A intuição é que todos os participantes negociam ao preço marginal do pool após o lote e que os arbitradores são incentivados a negociar até o ponto em que esse preço é igual ao preço do mercado externo. Este sistema é semelhante a um leilão frequente de lotes proposto pela Budish, Cramton e Shim (2015)na literatura financeira tradicional. A propósito, é um excelente exemplo das sinergias entre finanças descentralizadas e tradicionais. As ideias de finanças tradicionais podem ser implementadas nas finanças descentralizadas; o aprendizados da implementação pode então ser usado para informar as finanças tradicionais.

Application-Specific e Rebating MEV: O MEV captura AMM.

O MEV capturando AMM (McAMM)é um exemplo de mitigação MEV específica do aplicativo que depende de reembolso. O McAMM leiloa o direito de ser o primeiro trader a interagir com o AMM em um bloco, permitindo assim que esse trader extraia uma possível arbitragem. Os recursos do leilão são então distribuídos entre os provedores de liquidez arbitrados. Se o leilão for eficiente, os recursos devem ser iguais ao valor da arbitragem extraída dos provedores de liquidez. Este projeto poderia levar à mesma eliminação LVR que a função que maximiza o AMM discutida acima, mesmo que a abordagem seja radicalmente diferente. Se isso será o caso na prática depende muito das implementações específicas do leilão.

Infraestrutura e Rebating MEV: MEV-Share.

Rebating does not have to be specific to an application. Flashbots, a company operating in the block construction space, has developed MEV-Share. Ele permite que os usuários escolham quais dados de transação compartilhar em um leilão de forma privada. Os licitantes oferecem o direito de colocar esta transação em um pacote e, assim, extrair MEV dele. O usuário pode receber o produto do leilão. Essa infraestrutura não é específica do aplicativo, pois as transações podem interagir com qualquer aplicativo.

Infraestrutura e Prevenção de MEV: Fluxo de Ordens Protegido em um Mundo em Busca de Lucro.

Finalmente, existem mecanismos infraestruturais que visam evitar a extração de MEV. Um exemplo é Fluxo de pedidos protegido em um mundo em busca de lucro (PROF).PROF depende de um produtor de bloco dentro de um Ambiente de Execução Confiável (TEE) que se compromete de forma confiável com uma regra de ordenação, por exemplo, primeiro a chegar, primeiro a ser servido. TEEs têm duas propriedades críticas que tornam o compromisso confiável, a saber:

• [ ] Integridade: o código e os dados dentro do TEE não podem ser modificados ou adulterados, seja durante a execução ou enquanto armazenados, por entidades externas como o sistema operacional, hipervisor ou atores maliciosos.
• [ ] Confidencialidade: os dados e cálculos dentro do TEE permanecem privados e inacessíveis a entidades não autorizadas, incluindo o sistema host, outros aplicativos ou invasores.

Qualquer usuário que envia sua transação para um produtor de bloco que se compromete a executar uma regra de ordenação sabe que o produtor de bloco no TEE o fará. Portanto, o PROF pode impedir certos tipos de extração de MEV, como front-running para qualquer aplicação, sem alterar as regras do protocolo Ethereum.

Diferentes técnicas de mitigação de MEV têm diferentes prós e contras. Técnicas de prevenção de MEV específicas de aplicação são difíceis de encontrar, pois exigem muito trabalho de pesquisa e implementação por aplicação. A prevenção de MEV de infraestrutura, por outro lado, requer muita sobrecarga. Por exemplo, algumas técnicas de prevenção de MEV de infraestrutura exigem a execução de hardware caro e muito desenvolvimento de negócios. Se o rebating é eficaz depende muito se o leilão é competitivo, o que depende de especificidades do leilão, como seu formato e quando ele ocorre.

Essas quatro técnicas de mitigação de MEV podem não ser coletivamente exaustivas nem totalmente excludentes. Observe também que as dimensões se assemelham a espectros e não binários, como mostra a Figura 1. Por exemplo, algumas técnicas de mitigação de MEV podem ser mais infra-estruturais do que outras. O campo se move muito rapidamente, o que torna qualquer categorização desafiadora. Finalmente, o espaço parece otimista, e muitos podem compartilhar a opinião de que o MEV como uma porcentagem do valor total facilitou irá encolher rapidamente.

A falta de mitigação MEV no protocolo

Essas técnicas de mitigação de MEV podem parecer insatisfatórias para alguns. Por que o Ethereum não pode ser a infraestrutura de protocolo que resolve holisticamente o MEV? Talvez alguns leitores sugiram o uso de uma regra de ordenação específica. Propostas para impor uma regra de ordenação específica no Ethereum, como primeiro a chegar, primeiro a ser servido, não ganharam amplo apoio. Acredito que existem duas razões fundamentais pelas quais o protocolo não conseguiu resolver de forma holística a carga que o MEV impõe aos usuários finais e aplicativos - ambas estão relacionadas à restrição de neutralidade credível do Ethereum.

Em primeiro lugar, Ethereum não pode obter uma ordem global transitiva que satisfaça a “justiça”. Ethereum hospeda uma variedade de aplicativos que podem se beneficiar de diferentes tipos de regras de ordenação. Embora a ordenação de primeiro a chegar, primeiro a ser atendido possa ajudar alguns aplicativos, ela pode ser inadequada para outros. De maneira geral, a ordenação justa é impossível de ser alcançada.inibir o crescimento de outrosPortanto, é difícil para o ecossistema concordar com o que é justo. Além disso, mesmo que o ecossistema concordasse com uma regra de ordenação justa, seria difícil obter uma regra de ordenação globalmente transitiva, uma vez que uma transação pode chegar a diferentes nós em momentos diferentes.

Essas inconsistências causam problemas nos protocolos de pedidos por ordem de chegada. Especificamente, mesmo que a ordem na qual nós individuais recebem transações seja transitiva, isso não significa que a ordem agregada também seja transitiva. As regras de ordenação por ordem de chegada podem ficar presas em ciclos para restaurar a transitividade e, às vezes, esses ciclos precisam ser resolvidos por uma regra arbitrária, como escolher uma ordem total em ordem alfabética. Isso pode significar que as transações para as quais o pedido por ordem de chegada é mais importante, como transações de arbitragem sensíveis ao tempo, não são ordenadas dessa maneira, mas arbitrariamente.

Figura 2: Slide mostrando os ciclos de Condorcet em que as regras de ordenação primeiro a chegar, primeiro a ser servido podem ficar presas. Slide retirado de uma apresentação sobre Themis por Mahimna Kelkar.

Além do fato de que as regras de ordem de chegada têm problemas teóricos, não está clarose são desejáveisem primeiro lugar. Essa regra de classificação beneficia aqueles com conexões mais rápidas. Se conexões rápidas forem valiosas o suficiente, isso poderá levar a uma corrida de latência, como vista emfinanças tradicionaiscom grandes investimentos em tecnologia de velocidade. A tecnologia de velocidade pode prejudicar a neutralidade credível nas blockchains, pois incentiva a centralização geográfica.

Visões inconsistentes sobre quando as transações chegam causam problemas para a regra de ordem de chegada e para todas as regras de ordem. As regras de ordem geralmente visam alcançar algumas propriedades econômicas. Por exemplo, a ordem de gás prioritária procura incluir essas transações na ordem de quanto valorizam ser incluídas primeiro. Geralmente, esses desideratas econômicos são cumpridos apenas se houver uma visão global de quais transações devem ser ordenadas. Como é difícil obter uma visão global transitiva a partir de visões locais transitivas, é difícil obter tal visão global. Em outras palavras, alguns validadores pensarão que uma transação deve ser ordenada dentro de um slot, e outros pensarão que deve estar em outro slot, degradando as propriedades econômicas que o ecossistema poderia esperar receber de uma regra de ordem fixa.

Em segundo lugar, o protocolo de consenso desconhece os jogos MEV jogados na camada de execução. Isso tornaria difícil projetar um esquema de rebating no protocolo, já que o protocolo atualmente não entenderia qual é o valor do MEV e para quem ele deveria ser rebatido. Por último, o protocolo deve manter-se credivelmente neutro. Não deveria estar numa posição em que teria de fazer uma escolha opinativa sobre a quem deveria abater o MEV, mesmo que pudesse, nem deveria escolher técnicas de prevenção do MEV que favoreçam aplicações específicas em detrimento de outras.

Um exemplo interessante que se aproxima de uma técnica de reembolso MEV em protocolo éImpostos MEV, proposto porDan RobinsoneDave White. Isso permite que qualquer aplicativo sobrecarregue a taxa de prioridade do protocolo definindo um parâmetro, digamos $k$. Qualquer usuário que interaja com o aplicativo deve pagar $k$ vezes a taxa de prioridade que pagou ao validador de consenso para o aplicativo. Você pode ver como esse sistema pode reembolsar os rendimentos do MEV para aplicativos de maneira generalizada. Por exemplo, se houver 10 ETH de MEV a serem extraídos de um aplicativo, com $k = 9$, sendo o primeiro a interagir com ele, um usuário pode pagar uma taxa de prioridade de 1 ETH para o validador e 9 ETH para o aplicativo, assumindo que as transações sejam ordenadas pela taxa de prioridade.

As taxas de MEV são uma direção promissora, mas, como afirmado por seus autores, deve ser explorado ainda mais para entender como funcionaria no Ethereum. Um aspecto desafiador pode ser que as taxas de MEV assumem que a taxa de prioridade é um sinal universal para a quantidade de MEV. Embora isso possa ser verdade se uma ordem de prioridade for aplicada, a própria ordem pode diminuir a quantidade total de MEV, assim como um leilão de primeira oferta de várias unidades pode ter uma receita menor do que um leilão combinatorial. Flashbots’SUAVEparece estar indo na direção oposta, o que permite preferências mais expressivas. SUAVE ainda não está ativo, mas tem como objetivo construir um construtor de blocos descentralizado que mescla pacotes de forma otimizada sem uma regra de ordenação específica.

As taxas de prioridade podem não se assemelhar bem à MEV quando os pesquisadores desejam expressar suas preferências de serem incluídos de forma mais complexa do que a taxa de prioridade unidimensional. Talvez um pesquisador queira ser incluído no bloco antes dos pacotes de outros pesquisadores concorrentes, mas não se importa com a posição absoluta dentro do bloco. Usar taxas de prioridade significaria que o pesquisador compete pela posição com todos os usuários, independentemente de sua relevância para esse pesquisador.

Existem outras formas de diminuir o MEV extraído dos usuários além de ordenar regras. Uma direção de pesquisa émempools criptografados. Isso significa que os usuários transmitem transações de forma criptografada. Somente após a inclusão a transação é descriptografada. Portanto, o produtor de bloco não conhece o conteúdo da transação, tornando impossível realizar transações de front-running com base nos dados agora protegidos.

Mempools criptografados estão ativos na Gnosis Chain, uma blockchain que tem uma arquitetura semelhante à Ethereum. Os participantes do ecossistema, especialmente Rede Shutter, visam trazer mempools criptografados para a mainnet Ethereum. Alguns fatores limitantes atuais são as suposições de confiança que são necessárias com técnicas de criptografia baseadas em criptografia de limiar, o estado das Funções de Atraso Verificáveis, e o problemas de disponibilidade de dados gratuitosrelacionado aos mempools criptografados.

Em resumo, o Ethereum não pode ser a infraestrutura que impede o MEV porque o ecossistema não conseguiu concordar com uma regra de ordem justa e porque é difícil alcançar uma ordem global transitiva com qualquer regra de ordem. Algumas propostas de regras de ordem, como o exemplo de impostos MEV dado acima e atualizações de protocolo, foram discutidas que poderiam facilitar uma ordem global transitiva que satisfaça a “justiça”. No entanto, atualmente não há um consenso claro de que isso é desejável. O Ethereum não pode ser a infraestrutura que reembolsa o MEV porque a camada de consenso não tem conhecimento do que acontece na camada de execução e o Ethereum não pode escolher entre aplicativos, pois deve permanecer neutro.

O que o protocolo faz?

O parágrafo anterior mostra o quão difícil é para o protocolo eliminar o fardo que o MEV impõe aos usuários. No entanto, muitos mecanismos de protocolo lidam com o MEV e um inteiro seção do roteiro de Vitalik é dedicado a isso. O que esses mecanismos fazem?

Esses mecanismos in-protocolo visam resolver um problema diferente das técnicas de mitigação discutidas anteriormente. Em vez de maximizar o valor facilitado pelo Ethereum ao minimizar o MEV extraído dos usuários, os mecanismos in-protocolo visam maximizar a neutralidade credível do Ethereum ao minimizar as externalidades negativas do MEV. O MEV não apenas diminui a utilidade daqueles extraídos, mas também distorce grandemente o comportamento do extrator, por exemplo, incentiva a centralização através de economias de escala e causa instabilidade de consenso.

As forças econômicas são um grande risco de centralização para o consenso do Ethereum e, consequentemente, para sua neutralidade confiável. Se houver economias de escala, espera-se que os pequenos agentes de consenso se fundam com os grandes agentes para se beneficiar. Se houver retornos à sofisticação, os validadores racionais podem se comportar de maneira diferente das especificações honestas. Economias de escala ou retornos à sofisticação para agentes de consenso são externalidades negativas do MEV.

O protocolo tem como objetivo evitar externalidades negativas desagregando os papéis que os agentes de consenso têm no Ethereum e isolando-os uns dos outros. Atualmente, o Ethereum atribui todos os seguintes papéis a um agente, mas, em princípio, esses são papéis separados. Os três papéis identificados até agora são os seguintes:

• [ ] Atestar informações necessárias para o consenso e criar blocos de consenso é o papel mais crítico no sistema de consenso Proof-of-Stake do Ethereum. Exemplos são atestar a cabeça da cadeia, atestar a oportunidadede mensagens e criando blocos de consenso quando necessário. As recompensas por esses papéis são bastante homogêneas entre os participantes.
• [ ] Propor a execução do bloco. Este papel garante a vivacidade da camada de execução. Pode consistir na submissão oportuna da carga de execução e na alocação eficiente dos direitos de construção da carga de execução. As recompensas para este papel dependem da tolerância ao risco e da velocidade do participante.
• Construindo o bloco de execução. Este papel decide a ordem das transações em uma carga de execução. Tem o maior potencial para extrair MEV do sistema, e claras economias de escala, altas barreiras de entrada e sofisticação estão associadas a este papel. As recompensas são, portanto, muito heterogêneas entre os participantes.

O ecossistema Ethereum tem como objetivo isolar esses três papéis para que os incentivos originados de um papel não afetem os incentivos daqueles que desempenham outro papel. Alguns papéis, como a ordenação de transações, podem ser mais centralizados, desde que a validação de blocos seja confiável e altamente descentralizada, e um conjunto descentralizado de participantes possa garantir a resistência à censura, como Vitalik afirmou em seu influentePostagem de Fim de Jogo.

Separação Propositor-Builder (PBS)visa separar os papéis de propor e construir a carga útil de execução. É uma filosofia de design que reconhece os diferentes papéis e facilita a terceirização do dever de construção de blocos do proponente para uma parte especializada. MEV-Boost é a atual instanciação fora do protocolo do PBS. Ele permite que todos os proponentes, independentemente da sofisticação, tenham acesso aos mesmos mercados de MEV. Concretamente, ele garante que o construtor receba o direito de construir o bloco e que o proponente receba seu pagamento por vender esse direito. Com o MEV-Boost, um proponente não está em vantagem ao investir em técnicas sofisticadas de extração de MEV, mas pode permanecer relativamente não sofisticado nessa área e desfrutar das mesmas recompensas que proponentes mais sofisticados.

Separação de Attester-Proposer (APS) é conceitualmente semelhante ao PBS. Também reconhece a diferença entre dois papéis: atestar e propor blocos de consenso e propor blocos de execução. A SAF está atualmente em fase de pesquisa e nenhuma versão fora do protocolo está no ar. Proponentes pode querer ser rápidoporque isso lhes permite enviar seu bloco mais tarde, o que significa que podem incluir mais transações. É vital para o protocolo de consenso não incentivar a latência, pois isso leva à centralização geográfica. APS é às vezes visto como a última linha de defesa para o protocolo Ethereum.

O PBS e o APS mostram como esses três papéis podem ser isolados. No entanto, implementar essas duas atualizações de protocolo também significa que os participantes que criam blocos seriam muito centralizados, o que é terrível para a resistência à censura. O Ethereum tem como objetivo superar esses problemas construindo válvulas unidirecionais entre esses papéis. O protocolo pode sobrecarregar o papel de atestar blocos com atestar quais transações estão pendentes na mempool. Um comitê de atestadores seria então responsável por criar uma lista de transações que o produtor de blocos deve incluir, caso contrário, seu bloco seria ignorado pelos atestadores. Esse tipo de mecanismo é chamado delistas de inclusão.

Essas válvulas desafiam a separação de funções. É muito difícil de projetarválvulas que utilizam significativamente as propriedades de um conjunto de participantes, por exemplo, restringindo outro conjunto de participantes, enquanto também garantem que esses participantes no outro extremo da válvula não afetem os participantes que os afetam. Como exemplo, o conjunto descentralizado de testemunhas seria responsável por criar uma lista de inclusão. Não queremos que o produtor de blocos nem os incentivos de centralização relacionados à produção de blocos afetem as testemunhas.

Figura 3: Divisão do trabalho pela Separação de Attester-Proposer (APS) e Separação de Proposer-Builder (PBS) com listas de inclusão e venda de direitos de construção como válvulas unidirecionais entre funções.

Nenhuma solução única para dois problemas separados

O objetivo principal dos mecanismos de MEV em protocolo difere fundamentalmente das técnicas de mitigação de MEV de aplicativos e infraestrutura. Técnicas de mitigação fora de protocolo geralmente visam diminuir o MEV por unidade de valor facilitada. Em contraste, as técnicas de mitigação em protocolo visam evitar externalidades negativas de MEV que centralizam os agentes de consenso do Ethereum. Técnicas específicas de mitigação de MEV podem contribuir para ambos os objetivos. O MEV-Boost, por exemplo, é tecnicamente fora do protocolo, mas seu único objetivo é evitar as externalidades negativas do MEV.

Além disso, as restrições nos dois problemas são diferentes. Os mecanismos no protocolo devem ser projetados levando em consideração os requisitos de hardware e um protocolo neutro. Em contraste, as restrições das técnicas de mitigação de MEV fora do protocolo dependem dos desejos dos aplicativos ou dos designers de infraestrutura, que podem se adequar a um caso de uso específico.

Uma vez que esses problemas têm objetivos e restrições diferentes, é intuitivo que nenhuma solução única possa abordar ambos. Além disso, pode haver uma dicotomia mais fundamental entre os dois problemas. Esta seção esboça um argumento para essa dicotomia, também apresentado em um artigo de Davide Crapis e eu.

Os designers de aplicativos desejam reduzir o MEV por unidade de valor, porque isso atrairia mais usuários e, assim, aumentaria o valor total que esses aplicativos facilitam. Se o MEV por unidade de valor diminuir, mas o valor total facilitado aumentar, a quantidade total de MEV poderia diminuir, mas também poderia aumentar. Os mecanismos MEV in-protocol se preocupam com a quantidade total de MEV que os agentes de consenso podem extrair. Mesmo que a quantidade total de MEV seja uma fração negligenciável do valor que o Ethereum facilita, não está claro que o protocolo não precise ainda isolar os diferentes papéis de consenso necessários para evitar a centralização nos participantes do consenso do Ethereum.

Como exemplo deste argumento, considere o caso de Reequilíbrio de Perdas (LVR), introduzido anteriormente como as perdas de arbitragem de latência que os provedores de liquidez em AMMs enfrentam porque suas cotações na cadeia permanecem desatualizadas entre os blocos em comparação com o mercado externo em atualização contínua. Em seu trabalho, Milionis et al. descobrem que o LVR acumulado ao longo de um slot é proporcional ao tempo do slot elevado à potência de 3/2.

À primeira vista, isso sugeriria que diminuir o tempo de slot também diminui o MEV. No entanto, LVR é a perda de arbitragem por unidade de liquidez. Além disso, Joel Hasbrouck, Thomas Rivera e Fahad Saleh.mostrouque as posições individuais de LP podem ser consideradas ativos investíveis. Os retornos esperados dos ativos geralmente são baseados em seu risco. Não está claro como o risco de uma posição de LP mudaria à medida que os tempos de slot diminuem, mas, para fins de argumentação, suponha que permaneça constante. Então, os retornos de uma posição de LP devem permanecer constantes, independentemente dos tempos de slot; portanto, se os custos por unidade de liquidez diminuírem, as receitas por unidade de liquidez também devem diminuir. Em AMMs, as receitas diminuiriam porque mais liquidez flui para a AMM. Mais liquidez significa que mais unidades de liquidez enfrentam LVR. Portanto, o efeito agregado é ambíguo. Portanto, não está claro como a quantidade total de MEV resultante do LVR mudaria se os tempos de slot mudassem, mesmo que o MEV por unidade de valor possa diminuir.

Além disso, a diminuição do LVR tornaria os AMMs lugares mais atraentes para negociar, porque há mais liquidez, o que significa que mais traders pagadores de taxas usam o AMM, levando a ainda mais liquidez. Além disso, a experiência do usuário se beneficia de tempos de slot mais curtos, e a quantidade total de MEV decorrente do LVR pode aumentar com os tempos de slot. Isso é problemático para o protocolo, mesmo que os usuários desfrutem de negociações mais eficientes.

Tabela 1: Impacto dos tempos de slot em LVR, quantidade de liquidez e quantidade total de MEV. Esta tabela mostra como o tempo de slot afeta o LVR por slot e o fator pelo qual a liquidez é multiplicada. Pressupõe que as receitas de taxas permaneçam constantes e o custo de oportunidade por slot seja zero. Os resultados são normalizados com os valores correspondentes ao tempo de slot de 12 segundos usado como referência.

A Tabela 1 mostra que a quantidade total de MEV originada da LVR pode permanecer a mesma mesmo se o tempo de slot diminuir. Os valores nesta tabela são gerados assumindo que as taxas são a única receita, a arbitragem de latência é o único custo para os provedores de liquidez e o custo de oportunidade por slot permanece constante em zero. Essas suposições são excessivamente simplistas. Portanto, esses números podem representar limites superiores para a liquidez aumentada por slot e, portanto, para a quantidade total de MEV.

É difícil dizer como essas previsões se manterão. O ecossistema sabe pouco sobre as motivações dos provedores de liquidez e as compensações de risco-recompensa e ainda menos sobre o comportamento dos traders de liquidez. Talvez os LPs considerem o risco das posições de LP de forma diferente, dependendo dos tempos de slot, o que poderia ajudar a prever o que acontece com a quantidade total de MEV à medida que os tempos de slot diminuem.

Potencialmente, este exemplo pode ser generalizado. Técnicas de mitigação de MEV fora do protocolo que visam minimizar o MEV por unidade de valor induzem simultaneamente mais valor que flui através do sistema; portanto, o impacto da mitigação de MEV no total de MEV é ambíguo. Portanto, acredito que o Ethereum não pode depender da mitigação de MEV fora do protocolo para evitar as externalidades negativas do MEV nos agentes de consenso.

Aviso Legal:

1. Este artigo é reproduzido a partir de [ Julian Ma], Todos os direitos autorais pertencem ao autor original [Julian Ma]. Se houver objeções a este reprint, entre em contato com oGate Learnequipe, e eles cuidarão disso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe de aprendizado da gate. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.