Introdução

Neste post, apresentamos MEV impostos, um mecanismo que aplicativos arbitrários podem usar para capturar seus próprios MEV.

Esse mecanismo poderia ser usado hoje em OP Stack L2s como OP Mainnet, Base e Blast, porque os proponentes de blocos nessas cadeias seguem um conjunto de regras que chamamos de ordem de prioridade competitiva.

Para implementar um imposto MEV em uma dessas cadeias, um contrato inteligente cobra uma taxa que é uma função da taxa de prioridade da transação. Mostramos que, se um aplicativo cobrar dos buscadores um imposto MEV de (digamos) US$ 99 para cada US$ 1 de taxa de prioridade, ele pode capturar 99% do MEV competitivo para essa transação.

MEV impostos são uma técnica simples que abre um vasto espaço de design. Você pode pensar neles como permitindo que qualquer aplicativo na cadeia execute seu próprio leilão de MEV personalizado, sem precisar de nenhuma infraestrutura offchain própria, apenas conectando-se a um único leilão compartilhado executado pelo proponente do bloco.

Mostramos como MEV impostos poderiam ser usados para resolver três grandes problemas em MEV pesquisa:

• Roteadores exchange descentralizados (DEX) que otimizam o preço recebido pelo swapper
• Formadores de mercado automatizados (AMMs) que minimizam a perda vs-rebalanceamento (LVR) experimentada por provedores de liquidez
• Carteiras que permitem que seus usuários capturem qualquer MEV "backrunning" criado por suas transações

Mas há um porém. MEV impostos só funcionam se os proponentes de blocos seguirem estritamente as regras de ordem de prioridade competitiva, que incluem classificar as transações por taxa de prioridade sem censurar, espiar ou atrasar nenhuma. Se os proponentes do bloco se desviarem dessas regras, eles podem sonegar MEV impostos para capturar o valor para si mesmos. Hoje, portanto, MEV impostos dependem da confiança em sequenciadores L2, e provavelmente não funcionariam em Ethereum L1, onde a construção de blocos é dominada por um leilão de construtor competitivo que maximiza a receita para o proponente.

Ainda assim, o poder e a flexibilidade dos impostos MEV sugerem que o pedido prioritário pode ser a escolha certa para as plataformas que podem fornecê-lo hoje. E a relativa simplicidade da ordenação de prioridades competitivas sugere que pode haver uma maneira viável de aplicá-la de forma descentralizada, sem ter que confiar em um único sequenciador. Esperamos que este post motive mais trabalhos sobre esse problema.

Ordem de prioridade

Quando alguém envia uma transação em um Ethereum L1 ou L2, especifica uma taxa de prioridade, que paga ao proponente do bloco.1 Você pode imaginar que isso é especificado como priorityFeePerGas, um número que é multiplicado pelo gás usado na transação para obter builderPriorityFee — o pagamento total em ETH. 2

Não há nenhuma regra no Ethereum protocolo que as transações em um bloco devem ser ordenadas gananciosamente por prioridade descendenteFeePerGas. No entanto, essa é uma maneira popular de construir blocos — por exemplo, é o algoritmo padrão usado por sequenciadores de cadeias de pilha OP, bem como geth e reth. A ordenação de prioridades não apenas permite que os transatores expressem eficientemente a urgência de suas transações, mas também canaliza naturalmente certos tipos de MEV para o proponente do bloco.

Isso acontece porque a ordem de prioridade transforma a competição por MEV em um leilão gás priority. Quando há uma oportunidade de lucrar com a interação com a cadeia, como arbitrando um AMM contra um exchange centralizado, os buscadores competem para reivindicar essa oportunidade primeiro. Se a cadeia usa a ordem de prioridade para determinar a inclusão e o pedido de transações, os buscadores competem definindo taxas de alta prioridade em suas transações.

Em um cenário competitivo em que os lucros livres de risco são reduzidos a zero, o pesquisador vencedor deve acabar pagando o valor total de MEV em taxas de prioridade. 3 Portanto, se houver 100 ETH de lucro a serem obtidos ao interagir com um contrato, a primeira transação a reivindicá-lo estabelecerá uma taxa de prioridade de 100 ETH. (Discutimos algumas ressalvas a isso na seção Limitações).

MEV impostos

Suponha que um contrato inteligente queira capturar o MEV de qualquer transação que interaja com ele. Há uma vasta biblioteca de pesquisa sobre diferentes maneiras específicas de aplicativos que contratos inteligentes poderiam tentar capturar suas próprias MEV.

Mas, na verdade, não precisamos necessariamente saber nada sobre o aplicativo. Se sabemos que o bloco está sendo construído por meio de ordem de prioridade competitiva, então temos um sinal universal para a quantidade de MEV na transação: a taxa de prioridade.

Propomos que o contrato inteligente possa olhar para a taxa de prioridade da transação e cobrar sua própria taxa como uma função crescente dela. Por exemplo, o contrato pode exigir que quem o chama transfira applicationPriorityFee = 99 * proposerPriorityFee em ETH ao contrato. 4

Essa nova taxa é paga pelo buscador que envia a transação, portanto, afeta o comportamento desse buscador. Se houver 100 MEV em uma oportunidade, a transação vencedora agora definirá apenas uma taxa de prioridade de 1 ETH, já que isso resultará em um pagamento total de 100 ETH (1 ETH ao proponente do bloco e 99 ETH ao contrato inteligente). Qualquer taxa de prioridade mais alta tornaria a transação não lucrativa; Qualquer taxa de prioridade mais baixa resultaria na perda da oportunidade para um concorrente que estabelecesse uma taxa mais alta. Isso significa que o contrato inteligente capturou 99% dos MEV na transação.

Chamamos essa taxa extra imposta pelo contrato inteligente de imposto MEV. MEV impostos permitem que um aplicativo sequestre o pedido de prioridade para seu próprio benefício, permitindo que ele recapture MEV para seus usuários em vez de vazá-lo para o proponente do bloqueio.

Se esta taxa aumentar suficientemente rapidamente em função da prioridadeFeePerGas, então apenas uma quantidade insignificante de MEV será acumulada para o proponente. Como o priorityFeePerGas é denominado em nós (um bilionésimo de bilionésimo de um ETH), temos muita precisão para trabalhar. Por exemplo, longo que o imposto MEV seja suficientemente sensível para que uma prioridade de 50.000 resulte em um imposto proibitivamente alto, o pagamento total ao proponente seria inferior a US$ 0,01. 5

No entanto, há uma ressalva importante. Conforme discutido na seção Limitações, os impostos MEV só funcionam se os proponentes de blocos seguirem certas regras – o que chamamos de "ordem de prioridade competitiva" – em vez de se desviarem dessas regras em ordem para maximizar sua própria receita. Aplicar essas regras de forma não confiável é um problema em aberto.

Captura de MEV de aplicativo único

Aqui esboçamos como, em uma cadeia que é garantida para usar a ordem de prioridade competitiva para a construção de blocos, os impostos MEV poderiam ser usados para mitigar três problemas importantes na MEV: permitir que as interfaces de DEX melhorem a execução de negociação para swappers, permitir que as AMMs reduzam as perdas de arbitragem para seus LPs e permitir que as carteiras reduzam o vazamento de MEV para seus usuários vendendo o direito de backrun do usuário.

DEX roteadores

Em protocolos de roteamento de DEX baseados em intenção, como UniswapX e 1inch Fusion, um usuário (Alice) assina uma intenção de troca, e os buscadores competem para rotear ou preencher essa intenção pelo melhor preço possível para Alice.

As versões atuais do UniswapX usam dois mecanismos para executar essa competição: um leilão holandês onde o preço limite de Alice muda ao longo do tempo até que um pesquisador o preencha, e um leilão inicial offchain request-for-quote (RFQ) para definir o preço inicial desse leilão holandês.

Em uma plataforma que garante pedidos de prioridade competitivos, a UniswapX poderia substituí-los por um único mecanismo: um imposto MEV. Ele poderia implementar isso fazendo com que o usuário assinasse um ordem que pode ser preenchido imediatamente por qualquer pessoa, mas com um preço de execução que é definido como uma função da prioridade da transação.

Por exemplo, se Alice tiver um ordem UniswapX para vender 1 ETH, ela poderia definir o preço de execução do ordem como mínimoPreço + ($0,01 * priorityFeePerGas).

Os buscadores competiriam para preencher o ordem de Alice enviando transações. Qualquer transação que tenha a taxa de prioridade mais alta e não reverta preencheria o ordem, o que deve garantir que o swapper obtenha o melhor preço que os buscadores podem encontrar. (Algumas exceções a isso são discutidas na seção Limitações.)

Se o preço mínimo de Alice for de US$ 3.000 e o preço atual de ETH for de US$ 3.500, a prioridade na transação vencedora seria de cerca de 50.000. (Observe que, em uma transação que custa 200.000 gás, isso resultará em um pagamento de apenas cerca de 10 bilhões de nós – cerca de US$ 0,000035 – ao proponente do bloco.)

Isso tem alguns benefícios potenciais sobre os mecanismos existentes usados no UniswapX.

As encomendas que utilizam impostos MEV poderiam ser concluídas mais rapidamente e a um preço melhor do que as encomendas que utilizam leilões holandeses. Como discutido em este artigo, os leilões holandeses onchain vazam algum valor para MEV devido a movimentos de preços entre blocos, e podem levar muitos blocos para serem concluídos. Em contraste, os pedidos que usam impostos MEV normalmente podem ser concluídos no próximo bloco, capturando a grande maioria de seus MEV.

Ao contrário de uma RFQ offchain, o leilão para preencher um ordem que usa impostos MEV aconteceria atomicamente com a execução da transação onchain. Isso significa que um licitante vencedor pode ter a garantia de que só está comprometido a preencher o ordem se sua transação onchain for bem-sucedida. Isso poderia tornar mais fácil para a liquidez onchain, como AMMs, competir com a liquidez offchain, o que significa que o UniswapX poderia servir como um roteador ainda mais eficaz para sistemas multipool como o Uniswap v4.

AMMs

Normalmente, as AMMs vazam valor para arbitradores que negociam contra preços obsoletos no topo do bloco, conforme discutido nos papéis loss-vs-rebalancing . Podemos usar MEV impostos para que as AMMs capturem esse MEV. Para simplificar, discutiremos como isso pode funcionar em um AMM sem liquidez concentrada. (Se você está interessado em como esse tipo de problema poderia ser resolvido com liquidez concentrada, Sorella em breve publicará uma solução.)

Um AMM pode capturar MEV cobrando uma taxa extra em função da taxa de prioridade na transação, permitindo que leiloe o direito de negociar primeiro no bloco. Há muitas maneiras de calcular e denominar essa taxa. Discutiremos um indiscutivelmente neutro – denominando-o em unidades de liquidez do pool, sqrt(xy). A transação vencedora seria a que mais aumenta a liquidez do pool.

Ao executar a primeira transação em um pool em um bloco, em vez de impor a condição x_end y_end > x_start y_start, o pool poderia impor a condição (com uma constante):

x_end y_end > (sqrt(x_start y_start) + a*priorityFeePerGas)^2

Essa fórmula incentivaria o trader de arbitragem a negociar até o preço real e, após essa negociação, o preço médio no pool deveria ser o preço verdadeiro. 6

Após essa primeira transação, as negociações poderiam funcionar como no Uniswap v2, com taxas de swap fixas. Transações desinformadas que desejam negociar no pool sem pagar um imposto de MEV extra estabeleceriam uma taxa de prioridade baixa.

Há muitas outras maneiras de implementar impostos MEV sobre um AMM que teriam efeitos diferentes. Por exemplo, MEV impostos podem ser denominados no token de entrada ou saída do swap, podem afetar a porcentagem da taxa de swap aplicada pelo pool ou podem determinar o preço mínimo da negociação do usuário. Achamos que este é um espaço de design interessante para explorar.

Backrunning auctions

As descrições acima mostram como certos aplicativos podem ser projetados para evitar o vazamento de MEV. No entanto, e se uma carteira quiser tentar ajudar seus usuários a capturar o MEV que eles criam a partir de transações arbitrárias interagindo com qualquer aplicativo, mesmo aqueles que não incorporam impostos MEV?

Por exemplo, quando Alice faz uma grande transação em um AMM, ela às vezes cria uma oportunidade de arbitragem para "backrunners" moverem o preço de volta. Isso normalmente é vazado para MEV, em vez de ir para Alice.

MEV-Share e MEVBlocker são dois protocolos que permitem aos usuários capturar MEV de suas transações, mas dependem de um complexo sistema de leilões offchain. O Orderflow Auction Design Space descreve algumas outras soluções.

MEV impostos, quando combinados com uma carteira de contrato inteligente baseada em intenção, podem nos permitir construir um sistema alternativo para capturar MEV de backrunning para Alice. Suponha que, em vez de criar uma transação que seja negociada no AMM, Alice assine uma intenção que qualquer pessoa pode enviar para a carteira de contrato inteligente de Alice para fazer com que ela tome essa ação. A carteira de contrato inteligente de Alice cobra de quem envia essa transação um imposto MEV, que é pago a Alice.

O buscador que apresentar a intenção de Alice terá o direito exclusivo de recuá-la, já que poderá fazê-lo na mesma transação. Como resultado, se a busca for competitiva, todo o lucro do backrunning Alice deve ser revertido para Alice por meio de seu imposto MEV.

Observe que esse sistema pode não necessariamente proteger os usuários contra ataques que envolvam transações de usuário frontrunning, porque uma transação que executa front-run um usuário pode ser capaz de evitar o pagamento de um imposto MEV para esse usuário. Esse problema (e algumas possíveis atenuações para ele) é discutido com mais detalhes na seção Limitações abaixo. No entanto, isso poderia pelo menos ser uma melhoria nos sistemas que usam mempools públicos sem quaisquer mitigações.

Outros casos de uso

Além desses exemplos, outros usos potenciais de impostos MEV podem incluir quase tudo o que atualmente usa um leilão offchain ou holandês, como:

• Protocolos para oráculos capturarem o valor extraível do oráculo que eles criam, como Oval
• Refinanciamento leilões em protocolos de empréstimo com garantia NFT como Blend
• Lending protocolo liquidações que vazam menos valor superior aos leilões holandeses

Cross-application MEV capture

As soluções acima são projetadas para capturar o MEV da interação com um único aplicativo. Mas, às vezes, pode ser possível para um pesquisador capturar ainda mais valor interagindo com vários aplicativos na mesma transação.

Se apenas um desses aplicativos tiver um imposto MEV, todos os MEV da transação devem ir para o aplicativo com o imposto MEV, independentemente de quão alto ou baixo seja esse imposto MEV.

Mas e se a transação de um buscador interagir com dois aplicativos que usam impostos MEV? Por exemplo, e se houver algum MEV que só pode ser capturado preenchendo uma das ordens UniswapX MEV tributadas descritas acima contra um AMM tributado por MEV?

Nesse caso, a quantidade relativa de excesso de MEV capturada por cada aplicativo é determinada pela forma como esses aplicativos definem seus impostos MEV. Se o valor app_i cobra como imposto MEV é dado pela função tax_i(prioridade), então a prioridade da transação vencedora pode ser determinada resolvendo por prioridade nesta equação:

tax_1(priorityPerGas) + tax_2(priorityPerGas) = total MEV

(Tecnicamente, poderíamos adicionar um terceiro termo para priorityPerGas * gasUsed to conta para a taxa de prioridade paga ao proponente do bloco, mas vamos ignorar isso, uma vez que, como discutido no Apêndice A, provavelmente será insignificante em condições normais.)

No caso simples de MEV impostos que são lineares em priorityPerGas (então tax_1(priorityPerGas) = a_1 * priorityPerGas), você pode resolver para a parcela de MEV recebida por cada aplicação:

a_1 prioridadePerGas + a_2 prioridadePerGas = MEV

prioridadePerGas = MEV/(a_1 + a_2)

tax_1(priorityPerGas) = (a_1/(a_1+a_2))*MEV

tax_2(priorityPerGas) = (a_2/(a_1+a_2))*MEV

Ao definir seu próprio imposto MEV, um aplicativo enfrenta uma compensação — impostos mais altos permitem que ele capture uma parcela maior de MEV entre aplicativos quando ele ocorre, mas significa que ele pode perder alguns MEV entre aplicativos se houver maneiras concorrentes de extraí-lo. Por exemplo, se houver um AMM que cobra um imposto MEV sobre cada negociação, então um ordem UniswapX de imposto MEV pode ser mais provável de ser preenchido por um AMM diferente ou um preenchedor offchain.

Em muitos casos, pode haver um equilíbrio em que dois aplicativos projetam seus MEV impostos em ordem de compartilhar MEV de forma a maximizar cada um de seus bem-estar. Por exemplo, um AMM de impostos MEV provavelmente gostaria de capturar valor de um único comerciante informado perto do topo do bloco, mas depois gostaria de fornecer liquidez a outros comerciantes e aplicativos (incluindo aqueles que usam impostos MEV) com uma taxa fixa baixa. Nesse caso, é provável que o AMM defina um imposto de MEV relativamente baixo (digamos, $0,00001 priorityFeePerGas), de modo que a transação de arbitragem (se houver) aconteça no início do bloco e, em seguida, não cobrará imposto MEV sobre transações subsequentes no bloco. Aplicativos como o UniswapX que desejam interagir com o AMM podem definir um imposto de MEV muito mais alto (digamos $0.01 priorityFeePerGas), para garantir que suas transações sejam incluídas depois que o pool já estiver arbitrado. Com esses impostos relativos, o AMM acabaria ficando em primeiro lugar, mesmo que houvesse apenas US$ 1 de MEV e US$ 50.000 de MEV em um ordem UniswapX.

Achamos que este é um amplo espaço de design digno de estudo futuro.

Limitações

MEV impostos têm algumas complicações e desvantagens. Achamos que cada uma delas é uma área interessante para pesquisas futuras.

Incompatibilidade de incentivos

MEV impostos não são compatíveis com incentivos para um proponente de bloco monopolista. Eles só funcionam se houver concorrência justa para a inclusão de transações, o que só pode acontecer se o proponente do bloco seguir regras que chamaremos de "ordem de prioridade competitiva", em vez de maximizar sua própria receita. Informalmente e de forma não exaustiva, sugerimos que essas regras incluam:

• Ordem de prioridade. As transações dentro de um bloco devem ser ordenadas em ordem decrescente de priorityFeePerGas.
• Censura-resistência. Se o proponente do bloco receber uma transação t1 durante o bloco, e o bloco não estiver cheio ou incluir alguma transação t2 tal que t2.priorityFeePerGas < t1.priorityFeePerGas, então o bloco deve incluir a transação t1.
• Privacidade pré-transação. O proponente do bloco deve aceitar transações por meio de um endpoint privado e não deve compartilhar tais transações com ninguém antes de se comprometer com o bloco, ou usar o conteúdo dessas transações como uma entrada na construção de suas próprias transações.
• Nenhum último olhar. O proponente do bloco deve definir um bloqueio de tempo definido antes do qual eles aceitam transações de qualquer pessoa, e após o qual eles não aceitam transações de ninguém.

Se um ou mais desses imóveis forem violados, isso pode enfraquecer a eficácia de MEV impostos. Um proponente de bloco que viola a censura resistência pode evitar a maioria dos impostos MEV excluindo transações concorrentes e enviando uma transação de prioridade zero que aproveita a oportunidade para si. Um proponente de bloco que viola a privacidade pré-transação pode roubar MEV de outras transações ou espiar suas taxas de prioridade para saber exatamente o quão alto ele precisa definir o seu, enquanto um que é capaz de enviar transações mais tarde do que qualquer outra pessoa teria uma "última olhada" livre sobre se deve superar os outros por uma oportunidade, qualquer um dos quais poderia criar problemas de seleção adversos que, em última análise, desencorajam a concorrência.

Infelizmente, embora a primeira propriedade seja fácil de impor no camada de protocolo, impor as outras propriedades sem confiança é um problema em aberto.

Na ausência de aplicação no camada de protocolo, um único sequenciador que se compromete com essas regras precisa ser confiável para não se desviar delas, e se os proponentes terceirizarem a construção de blocos para um leilão competitivo de maximização de receita (como o Leilões sem líderes ou Multiplicidade.

Blocos completos

Uma exceção ao funcionamento normal das taxas de MEV acontece quando os blocos estão completamente cheios. Nesse caso, os proponentes do bloco podem ter que deixar de fora as transações de prioridade mais baixa, em vez de simplesmente incluí-las no final do bloco. Como as transações que interagem com aplicativos tributados pelo MEV provavelmente terão taxas de prioridade extremamente baixas, esses aplicativos provavelmente serão excluídos por aplicativos que não usam impostos MEV ou que têm impostos MEV extremamente baixos. No entanto, em uma cadeia que usa um mecanismo semelhante ao EIP-1559 para definir uma taxa básica separada, deve ser relativamente raro que os blocos estejam completamente cheios. Além disso, dado que algumas transações precisam ser adiadas quando os blocos estão cheios, atrasar transações que expressam menor urgência, definindo impostos MEV mais altos pode ser um resultado razoável.

As transações MEV impostos revertidos

dependem efetivamente de leilões de bloco único em que cada "lance" é uma transação. Uma desvantagem desses leilões é que a perda de lances geralmente resultará em transações revertidas sendo incluídas onchain, pagando alguma taxa básica e congestionando a cadeia.

Se um sequenciador puder excluir totalmente transações com falha, isso aliviaria esse problema, embora isso possa ser difícil de implementar, mesmo com um sequenciador centralizado. (Também não obedeceria estritamente à propriedade resistência censura descrita acima, embora essa definição pudesse ser ajustada.) Um sequenciador mais sofisticado pode ser capaz de otimizar esse processo, permitindo que as transações especifiquem em quais leilões contenciosos estão participando, dando ao sequenciador informações suficientes para ignorar transações subsequentes que ele sabe que falhariam.

O vazamento de intenções de usuário

MEV impostos só funciona se houver competição entre os buscadores, o que significa que a oportunidade precisa ser amplamente conhecida. Para aplicações como AMMs, onde a oportunidade é visível onchain, isso deve acontecer naturalmente. Mas para aplicativos como roteamento baseado em intenção ou leilões de backrunning, isso significa que o aplicativo pode precisar compartilhar a intenção do usuário com os buscadores.

Em alguns casos, a privacidade temporária perdida ao transmitir a intenção do usuário antes que ela seja cumprida pode vazar valor de uma forma que não pode ser recapturada por um imposto MEV

Por exemplo, suponha que Alice queira comprar um token de baixa liquidez usando a protocolo de leilão de backrunning descrita acima. Ela publica uma intenção assinada para sua carteira de contrato inteligente para comprar esse token em um AMM, definindo alguma tolerância de derrapagem. Os buscadores poderiam correr para empurrar o preço desse token para sua tolerância de deslizamento em uma transação de alta prioridade, sem preencher o ordem do usuário. O vencedor, Bob, poderia então preencher de forma não competitiva a intenção de Alice ao incluí-la e recuá-la em uma transação de baixa prioridade, prejudicando assim o comércio de Alice e dando-lhe um preço pior enquanto fugia de seu imposto MEV. Um problema semelhante pode acontecer com as compras de NFTs.

Note que tal ataque seria arriscado para Bob, já que ele não seria capaz de garantir atomicidade entre comprar o token e vendê-lo para Alice. Um Bob ingênuo poderia cair vítima de um armadilha de "sanduíche rasgando" em que Alice publica uma intenção de comprar um token inútil de si mesma, fazendo com que Bob o compre em antecipação ao sanduíche de seu comércio, mas Alice revoga sua intenção antes que Bob seja capaz de completar o sanduíche.

Os aplicativos também podem ser capazes de mitigar isso limitando o conjunto de buscadores com os quais compartilham intenções e monitorando seu comportamento, como muitos leilões de fluxo de pedidos existentes fazem.

Também pode ser possível combinar impostos MEV com recursos de construtor sensíveis à privacidade, como previsto nos projetos dos Flashbots para SUAVE.

Finalmente, nos casos em que Alice decide que os custos de compartilhar sua intenção superam o benefício da busca competitiva, ela poderia construir uma transação sozinha e submetê-la diretamente ao bloco. Como discutido acima, uma implementação ideal de ordem de prioridade competitiva forneceria privacidade pré-transação do proponente do bloco.

Discussão e trabalho prévio

Prioridade gás leilões. Algumas das dinâmicas de ordenação de prioridades em blockchains descentralizadas foram estudadas no artigo Flash Boys 2.0, que cunhou o termo "miner extractable value". Esse artigo observou que Ethereum mineradores (quando essa rede usava prova de trabalho) já estavam ordenando transações por prioridade, e que os arbitradores estavam confiando nesse comportamento para participar de "leilões de gás prioritários" nos quais eles licitavam pelo direito de serem incluídos primeiro em um bloco, o que levou a grande parte da MEV de arbitragem de exchange descentralizada acumulada para mineradores.

Quem antes nasce antes pasce. Algumas tentativas de mitigação de MEV por meio de regras de ordenação de transações, como Themis ou Arbitrum One's current sequencer,7 têm se concentrado em aplicar uma regra de ordenação diferente, primeiro a chegar, primeiro a ser servido (às vezes chamado de "ordem justa") onde os proponentes de bloco devem ordem transações no ordem em que as veem.

O pedido prioritário adota uma abordagem diferente: tratar igualmente as transações que chegam dentro de um determinado período e, em vez disso, ordená-las por sua prioridade declarada.

Primeiro a chegar, primeiro a ser atendido é difícil de impor ou mesmo definir em um ambiente de rede real com mais de um validador. Isso também pode resultar em corridas de latência desperdício e spam, mesmo com um único sequenciador confiável. Finalmente, MEV impostos podem ser capazes de eliminar certos tipos de MEV que os pedidos por ordem de chegada não podem, como os lucros de arbitragem de "saltos" descontínuos nos preços dos ativos. As vantagens potenciais do pedido prioritário sobre o pedido por ordem de chegada estão de certa forma relacionadas às vantagens do tempo discreto sobre as trocas de tempo contínuo discutidas em Budish, Cramton, Shim (2015).

Enquanto isso, enquanto a ordenação de prioridade parece vazar valor para MEV por padrão, este post mostra como os aplicativos podem ser projetados para recapturá-lo.

Compartilhamento de taxas. A Blast, uma Ethereum L2, compartilha uma parte das taxas de prioridade e base com o contratos inteligentes acessado em uma transação.

MEV impostos permitem algo semelhante (pelo menos para taxas de prioridade), mas podem ser implementados na camada de aplicação em qualquer cadeia que use ordem de prioridade competitiva, sem apoiar especial para compartilhamento de taxas. Eles também permitem que os aplicativos definam seus próprios impostos como funções personalizadas de taxa de prioridade, fornecendo mais flexibilidade e potencialmente resultando em maior capacidade de composição de aplicativos com reconhecimento de MEV.

Sem confiança soluções. Este post se concentra na motivação para as plataformas usarem a ordem de prioridade competitiva — e maneiras de tirar proveito das plataformas que o fazem — em vez de discutir como aplicá-la sem confiança.

Houve uma discussão prévia significativa de cada uma das outras propriedades necessárias para a ordem de prioridade competitiva. Por exemplo, em Fox, Pai, Resnick (2023), os autores discutem vulnerabilidades em leilões onchain na ausência de resistência à censura e descrevem um projeto para um leilão resistente à censura usando vários proponentes simultâneos. No entanto, eles não sugerem uma ordem específica para as transações.

Houve outras pesquisas sobre a construção de mecanismos para a construção de blocos minimizados pela confiança, incluindo SUAVESorella's Angstrom, Leaderless Auctions, Espresso e Offchain Labs' @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">timeboost descentralizado e inclusão obrigatória de transações públicas por Péter Szilági.

Conclusão

Esperamos que este post encoraje os L2s a considerar o uso de ordem de prioridade (como é suportado por padrão no OP Stack) e inspire os aplicativos a experimentar MEV impostos onde houver suporte.

Esperamos também que isso motive novas pesquisas sobre protocolos para ordenação de prioridade competitiva minimizada pela confiança em L1 e L2. Se você estiver interessado em colaborar com esse problema e estiver lendo isso antes de quinta-feira, 6 de junho, você ainda pode se inscrever para uma bolsa TLDR para trabalhar em sequenciadores L2 resistentes a MEV com Dan. Ou sinta-se à vontade para entrar em contato com dan@paradigm.xyz e dave@paradigm.xyz com ideias!

Notas

de rodapé
1. Neste post, usamos "proponente" para nos referir ao ator ou processo que determina quais transações estão incluídas em um determinado bloco. Em Ethereum L2s, essa função é normalmente preenchida por um "sequenciador". Em Ethereum L1, ele é preenchido por um validador Ethereum específico chamado proponente, embora muitas vezes o proponente terceirize a tarefa de construir o bloco para um leilão competitivo no qual "relayers" e "builders" participam. Os detalhes de como essas responsabilidades são divididas estão fora do escopo deste post. ↩
2. A taxa de prioridade por gás não é especificada explicitamente na transação, mas pode ser computada nela. A transação especifica um preço do gás, mas Ethereum também cobra uma taxa base, que é retirada do preço do gás e queimada. A taxa base deve ser ignorada para fins de MEV impostos, uma vez que não está sob o controle do transator. A taxa de prioridade por gás — o preço da parte da taxa de transação que vai para o proponente do bloco — pode ser calculada em Solidity como priorityGasPrice = tx.gasprice - block.basefee. ↩
3. Alternativamente, poderíamos simplesmente definir "MEV" para excluir qualquer lucro do pesquisador e apenas se referir ao valor que iria para o validador. ↩
4. Observe que proposerPriorityFee — igual a priorityFeePerGas vezes o total gás usado na transação — não pode ser calculado durante o contrato, já que não há como saber quanto gás a transação acabará usando. No entanto, isso geralmente não importa, já que tudo o que precisamos é de um limite superior para isso. Por segurança, você pode multiplicar o FeePerGas por 30 milhões — o gás máximo atual em um bloco Ethereum. Superestimar esse valor significará simplesmente que o imposto MEV captura um percentual ainda maior de MEV. ↩
5. Supondo que uma transação não possa ser superior a 30 milhões de gás, uma prioridade de 50.000 resultaria em um pagamento gás de 1500 rede — cerca de US$ 0,006 a um preço ETH de US$ 4.000. ↩
6. No caso em que priorityFeePerGas é definido de modo que o lucro do árbitro seja zero, a negociação de arbitragem maximizadora de lucro deve corresponder à mesma negociação no AMM maximizador de função. Provar isso fica como um exercício para o leitor. ↩
7. Arbitrum discutiu a substituição disso por uma forma de ordenação de prioridade chamada Timeboost, mas que não foi colocada em produção até o momento em que este artigo foi escrito. ↩

Isenção de responsabilidade:

1. Este artigo foi reproduzido de [paradigm]. Todos os direitos autorais pertencem ao autor original [Dan Robinson & Dave White]. Se houver objeções a essa reimpressão, entre em contato com a equipe Gate Learn e eles lidarão com isso prontamente.

2. Isenção de responsabilidade: Os pontos de vista e opiniões expressos 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 do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.