O protocolo Ethereum e o ecossistema mais amplo têm como objetivo melhorar continuamente o valor que o Ethereum pode fornecer. Um gargalo chave para melhorar o Ethereum em todo o ecossistema 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 num bloco pode extrair do sistema. Este post resume os métodos propostos para mitigar os efeitos negativos do MEV nas aplicações e no protocolo e investiga as direções futuras de investigação.

Este post está organizado da seguinte forma:

A primeira seção propõe uma categorização bidimensional das 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 impede ou rebate MEV.

Em terceiro lugar, exploramos o que o protocolo Ethereum faz para prevenir as externalidades negativas da 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 sistematizaçã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. Esse argumento é baseado em um papelporDavide Crapise eu.

Este post refere-se a técnicas de mitigação dentro e fora do protocolo. Com técnicas de mitigação de MEV no 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 no protocolo.

Mitigação de MEV fora do protocolo

MEV impõe alugueres aos utilizadores que interagem com uma blockchain. Para aumentar o valor que o Ethereum facilita, é intuitivo diminuir o aluguer que o MEV representa. O mandato das técnicas de mitigação do 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 a forma como a MEV é extraída em Automated Market Makers (AMMs) e, consequentemente, como ela pode ser mitigada. Muitas AMMs funcionam da seguinte forma:

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

Um AMM ajusta seus preços apenas em resposta a transações incluídas em novos blocos. Este ajuste discreto contrasta com as flutuações contínuas 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 um AMM, extraindo assim MEV.

Esta forma de MEV, conhecida como Perda versus Reequilíbrio (LVR)é um custo para os provedores de liquidez. Mantendo as taxas que acumulam para os provedores de liquidez constantes, a quantidade de liquidez fornecida diminui com a quantidade de LVR extraída do AMM. Menos liquidez significa que as negociações do usuário têm um maior impacto no preço, o que significa que é 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 do MEV para os usuários.

Existem muitas maneiras de diminuir o custo do MEV. A grosso modo, as técnicas de mitigação de MEV fora do protocolo são divididas ao longo de dois eixos:

• Técnicas de mitigação de MEV específicas de aplicativos ou infraestrutura compartilhada.
• Prevenir MEV ou devolver MEV.

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

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

Especificação de aplicativos e prevenção de MEV: a função que maximiza o 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 impede a exposição ao MEV. Um exemplo interessante é o função de maximização de AMMproposto porAndrea Canidio e Robin 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 LVR e o sanduíche, outra forma de MEV. A intuição é que todos os participantes negoceiam ao preço marginal do pool após o lote e que os arbitradores são incentivados a negociar até ao ponto em que este preço é igual ao preço do mercado externo. Este sistema é semelhante a um leilão frequente de lotes proposto pela Budish, Cramton, and Shim (2015)na literatura financeira tradicional. A propósito, é assim um excelente exemplo de sinergias entre finanças descentralizadas e tradicionais. As ideias de finanças tradicionais podem ser implementadas nas finanças descentralizadas; o Aprendizagens da implementaçãopode então ser usado para informar a finança tradicional.

MEV específico do aplicativo e Rebating: O MEV capturando 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 negociador a interagir com o AMM em um bloco, permitindo assim que esse negociador 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 de arbitragem extraído dos provedores de liquidez. Este projeto poderia levar à mesma eliminação do LVR que a função maximizando 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.

O abatimento não precisa ser específico para uma aplicação. A Flashbots, uma empresa que atua no espaço de construção de blocos, desenvolveuMEV-Partilhar. Permite aos utilizadores escolher quais os dados de transação a partilhar num leilão de forma privada. Os licitantes licitam pelo direito de colocar esta transação num pacote e, assim, extrair MEV dela. O utilizador pode receber os proventos do leilão. Esta infraestrutura não é específica da aplicação, uma vez que as transações podem interagir com qualquer aplicação.

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

Finalmente, existem mecanismos infraestruturais que visam impedir a extração de MEV. Um exemplo é Fluxo de Pedidos Protegido num Mundo em Busca de Lucro (PROF). O PROF depende de um produtor de blocos dentro de um Ambiente de Execução Confiável (TEE) que se compromete de forma credível com uma regra de ordenação, por exemplo, primeiro a chegar, primeiro a servir. Os ETE têm duas propriedades críticas que tornam o compromisso credí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 as computações dentro do TEE permanecem privados e inacessíveis a entidades não autorizadas, incluindo o sistema hospedeiro, outras aplicações ou atacantes.

Qualquer usuário que envie sua transação para um produtor de blocos que se compromete a executar uma regra de ordenação sabe que o produtor de blocos na TEE fará isso. Portanto, PROF pode impedir certos tipos de extração de MEV, como front-running para qualquer aplicativo, 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 para aplicações são difíceis de encontrar, pois exigem muito trabalho de pesquisa e implementação por aplicação. A prevenção de MEV infraestrutural, por outro lado, requer muita sobrecarga. Por exemplo, algumas técnicas de prevenção de MEV de infraestrutura requerem a execução de hardware caro e o desenvolvimento de muitos negócios. A eficácia da rebating depende muito da competitividade do leilão, o que depende das especificidades do leilão, como o seu formato e o momento em que se realiza.

Estas quatro técnicas de mitigação de MEV podem não ser coletivamente exaustivas nem totalmente mutuamente exclusivas. Note também que as dimensões se assemelham a espectros e não a binários, como mostrado na Figura 1. Por exemplo, algumas técnicas de mitigação de MEV podem ser mais infraestruturais do que outras. O campo move-se muito rapidamente, o que torna qualquer categorização desafiadora. Finalmente, o espaço parece otimista, e muitos podem partilhar a opinião de que o MEV como percentagem do valor total facilitadoirá encolher rapidamente.

A falta de mitigação do 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 particular no Ethereum, como atendimento por ordem de chegada, não obteve suporte generalizado. Acredito que existem duas razões fundamentais pelas quais o protocolo não conseguiu resolver de forma holística o ônus que o MEV impõe aos usuários finais e aplicativos - ambas estão relacionadas à restrição de neutralidade credível do Ethereum.

Primeiro, o Ethereum não pode obter uma ordenação global transitiva que satisfaça a “justiça”. O Ethereum hospeda uma variedade de aplicações que podem beneficiar de diferentes tipos de regras de ordenação. Embora a ordenação de primeiro a chegar, primeiro a ser servido possa ajudar algumas aplicações, inibir o crescimento de outros. Portanto, é difícil para o ecossistema concordar com o que é justo. Além disso, mesmo que o ecossistema concorde com uma regra de ordenação justa, é difícil obter uma regra de ordenação globalmente transitiva porque uma transação pode chegar a nós diferentes em momentos diferentes.

Essas inconsistências causam problemas nos protocolos de ordenação de primeiro a chegar, primeiro a ser atendido. Especificamente, mesmo que a ordem na qual os 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 de primeiro a chegar, primeiro a ser atendido 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 ordenação total alfabeticamente. Isso pode significar que transações para as quais a ordenação de primeiro a chegar, primeiro a ser atendido é mais importante, como transações de arbitragem sensíveis ao tempo, não são ordenadas dessa forma, mas de forma arbitrária.

Figura 2: Slide mostrando as regras de ordem primeiro a chegar, primeiro a ser atendido que podem ficar presas em ciclos de Condorcet. 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 ordenação beneficia aqueles com conexões mais rápidas. Se as conexões rápidas forem suficientemente valiosas, isso poderá levar a uma corrida de latência, como visto em finanças tradicionaiscom grandes investimentos em tecnologia de velocidade. A tecnologia de velocidade poderia 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 primeiro a chegar, primeiro a ser servido e para todas as outras regras de ordem. As regras de ordem geralmente têm como objetivo alcançar algumas propriedades econômicas. Por exemplo, a ordem de gás prioritária procura incluir as transações de acordo com o quanto elas valorizam serem incluídas primeiro. Geralmente, esses objetivos econômicos são alcançados 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 essa visão global. Em outras palavras, alguns validadores vão pensar que uma transação deve ser ordenada em um determinado slot, e outros pensarão que ela deve estar em outro slot, prejudicando as propriedades econômicas que o ecossistema poderia esperar de uma regra de ordem fixa.

Em segundo lugar, o protocolo de consenso não tem conhecimento dos jogos MEV realizados na camada de execução. Isso tornaria difícil projetar um esquema de reembolso no protocolo, pois o protocolo atualmente não entenderia o valor do MEV e para quem ele deveria ser reembolsado. Por fim, o protocolo deve permanecer neutral de forma crível. Não deve estar em uma posição em que precise fazer uma escolha com opinião sobre a quem reembolsar o MEV, mesmo que pudesse, nem deve escolher técnicas de prevenção do MEV que favoreçam aplicativos específicos em relação a outros.

Um exemplo interessante que se aproxima de uma técnica de reembolso de MEV no protocolo éImpostos MEV, proposto porDan RobinsoneDave White. Permite que qualquer aplicação sobrecarregue a taxa de prioridade no protocolo, definindo um parâmetro, digamos $k$. Qualquer usuário que interaja com a aplicação terá que pagar $k$ vezes a taxa de prioridade paga ao validador de consenso para a aplicação. Você pode ver como esse sistema pode reembolsar os lucros de MEV para as aplicações de maneira generalizada. Por exemplo, se houvesse 10 ETH de MEV a serem extraídos de uma aplicação, com $k = 9$, sendo o primeiro a interagir com ela, um usuário pode pagar uma taxa de prioridade de 1 ETH para o validador e 9 ETH para a aplicação, assumindo que as transações são ordenadas pela taxa de prioridade.

As taxas de MEV são uma direção promissora, mas, como afirmado pelos seus autores, deve ser mais explorada para entender como funcionaria no Ethereum. Um aspecto desafiador pode ser que as taxas de MEV pressupõem que a taxa de prioridade é um sinal universal para a quantidade de MEV. Embora isso possa ser verdade se uma ordem de prioridade for imposta, a própria ordenação pode diminuir a quantidade total de MEV, semelhante a como um leilão de primeira unidade de preço múltiplo pode ter uma receita menor do que um leilão combinatório. 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 prioritárias podem não refletir bem o MEV quando os pesquisadores desejam expressar suas preferências de serem incluídos de uma maneira mais complexa do que a taxa prioritária unidimensional. Talvez um pesquisador queira ser incluído no bloco antes de outros pacotes de pesquisa concorrentes, mas não se importa com a posição absoluta dentro do bloco. Usar taxas prioritárias 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 a MEV extraída dos utilizadores, além da ordenação de regras. Uma direção de pesquisa é mempools encriptadosIsto significa que os utilizadores difundem transações em forma encriptada. Apenas após a inclusão é que a transação é desencriptada. Assim, o produtor de blocos não conhece o conteúdo da transação, tornando impossível a realização de transações de front-run com base nos dados agora protegidos.

As mempools encriptadas estão ativas na Gnosis Chain, uma blockchain que possui uma arquitetura semelhante à do Ethereum. Os participantes do ecossistema, em especial Rede Shutterpretende trazer mempools criptografados para a mainnet do Ethereum. Alguns dos atuais fatores limitantes são as suposições de confiança 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 com mempools encriptados.

Em resumo, o Ethereum não pode ser a infraestrutura que previne MEV porque o ecossistema não foi capaz de concordar com uma regra de ordenação justa e porque é difícil alcançar uma ordenação global transitiva dada qualquer regra de ordenação. Alguns propostas de regras de ordenação, como o exemplo de impostos MEV dado acima e atualizações de protocolo, têm sido discutidas que poderiam facilitar uma ordenação global transitiva que satisfaz a 'justiça'. No entanto, atualmente não há um consenso claro sobre se isso é desejável. O Ethereum não pode ser a infraestrutura que rebates MEV porque a camada de consenso não está ciente do que acontece na camada de execução e o Ethereum não pode escolher entre aplicativos, uma vez que deve permanecer neutro.

O que faz o protocolo?

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

Estes mecanismos in-protocolo têm como objetivo resolver um problema diferente das técnicas de mitigação discutidas anteriormente. Em vez de maximizar o valor facilitado pelo Ethereum, minimizando o MEV extraído dos utilizadores, os mecanismos in-protocolo visam maximizar a neutralidade credível do Ethereum, minimizando as externalidades negativas do MEV. O MEV não só diminui a utilidade daqueles que são extraídos, como 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 representam um grande risco de centralização para o consenso do Ethereum e, transitivamente, para a sua neutralidade credível. Se houver economias de escala, é de se esperar que os agentes de consenso pequenos se fundam com agentes grandes para se beneficiar. Se houver retornos para a sofisticação, os validadores racionais podem agir de forma diferente das especificações honestas. As economias de escala ou os retornos para a sofisticação dos agentes de consenso são externalidades negativas de 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 único agente, mas, em princípio, eles 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 atempada 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. Esse papel decide a ordem das transações em uma carga de execução. Ele tem o maior potencial para extrair MEV do sistema, e economias de escala claras, altas barreiras à entrada e sofisticação estão associadas a esse 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 cumprem outro papel. Alguns papéis, como a ordenação de transações, podem ser mais centralizados, desde que a validação de blocos seja trustless e altamente descentralizada, e um conjunto descentralizado de participantes possa garantir resistência à censura, como Vitalik afirmou em seu influente Publicação de Endgame.

Separação de Proponente-Construtor (PBS)visa separar os papéis de proposição e construção da carga útil de execução. É uma filosofia de design que reconhece os diferentes papéis e facilita a terceirização da obrigação de construção de blocos do proponente para um partido especializado. MEV-Boost é a instantaneização atual fora do protocolo de PBS. Ele permite que todos os proponentes, independentemente da sofisticação, tenham acesso aos mesmos mercados 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 é beneficiado investindo em técnicas sofisticadas de extração de MEV, mas pode permanecer relativamente pouco sofisticado nessa área e desfrutar das mesmas recompensas que os proponentes mais sofisticados.

Separação Attester-Proposer (APS)é conceptualmente semelhante ao PBS. Também reconhece a diferença entre dois papéis: atestar & propor blocos de consenso e propor blocos de execução. APS está atualmente na fase de pesquisa e nenhuma versão fora do protocolo está ativa. Proponentes pode querer ser rápidoporque permite que eles enviem seu bloco mais tarde, o que significa que eles 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 do protocolo Ethereum.

A PBS e a 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 no 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.

Estas válvulas desafiam a separação de papéis. É muito difícil de projetarválvulas que utilizam significativamente as propriedades de um conjunto de participantes, por exemplo, restringindo outro conjunto de participantes, ao mesmo tempo em que garantem que esses participantes no outro extremo da válvula não afetem os participantes que os afetam. Como exemplo, o conjunto descentralizado de atestadores seria responsável por criar uma lista de inclusão. Não queremos que o produtor de blocos nem os incentivos centralizadores relacionados à produção de blocos afetem os atestadores.

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 os papéis.

Não há uma única solução para dois problemas separados

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

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

Uma vez que estes 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 secção esboça um argumento para esta dicotomia, também apresentada em um artigo de Davide Crapis e eu.

Os designers de aplicativos desejam reduzir o MEV por unidade de valor, porque ao fazer isso atrairiam mais usuários e, assim, aumentariam 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. Mecanismos de MEV no protocolo 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 um exemplo deste argumento, considere o caso dePerda versus Reequilíbrio(LVR), introduzido anteriormente como as perdas de arbitragem de latência que os provedores de liquidez em AMMs enfrentam porque suas cotações on-chain ficam obsoletas entre os blocos em comparação com o mercado externo em constante atualização. Em seu trabalho, Milionis et al. descobrem que o LVR acumulado ao longo de um slot é proporcional ao tempo do slot elevado a 3/2.

À primeira vista, isso sugeriria que a diminuição do tempo da slot também diminui o MEV. No entanto, o LVR é as perdas 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 são tipicamente 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 argumento, suponha que ele 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 o 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 decorrente 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 atrativos 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 no LVR, na quantidade de liquidez e na 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 das taxas permaneçam constantes e que o custo de oportunidade por slot seja zero. Os resultados são normalizados com os valores correspondentes ao tempo de slot de 12 segundos usados como referência.

A Tabela 1 mostra que o montante total de MEV originado de LVR pode permanecer o mesmo 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 fornecedores 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, assim, para o montante 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 e recompensa.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 valor total de MEV é ambíguo. Portanto, acredito que o Ethereum não pode confiar na mitigação de MEV fora do protocolo para prevenir as externalidades negativas do MEV nos agentes de consenso.

Aviso legal:

1. Este artigo é republicado a partir de [Julian Ma], Todos os direitos autorais pertencem ao autor original [Julian Ma]. Se houver objeções a esta reimpressão, por favor entre em contato com oGate Learnequipa, e eles tratarão do assunto 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 equipa Learn da gate. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.