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 Rede principal, 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 de MEV em uma dessas cadeias, um contrato inteligente cobra uma taxa que é função da taxa de prioridade da transação. Mostramos que, se um aplicativo cobrar dos pesquisadores um imposto de 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 os impostos MEV poderiam ser usados para resolver três grandes problemas em MEV pesquisa:

• Roteadores de exchange (DEX) descentralizados que otimizam o preço recebido pelo swapper
• Criadores de mercado automatizados (AMMs) que minimizam a perda versus reequilíbrio (LVR) experimentado pelos provedores
• de liquidez Carteiras que permitem que seus usuários capturem qualquer MEV de "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 fugir MEV impostos para capturar o valor para si mesmos. Hoje, portanto, MEV impostos dependem de sequenciadores L2 confiáveis, e provavelmente não funcionariam em nada 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 ordem de prioridade competitiva 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 trabalho sobre esse problema.

Encomenda prioritária

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 prioritária não só permite que os transatores expressem eficientemente a urgência das suas transações, como também canaliza naturalmente certos tipos de MEV para o proponente do bloco.

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

Em um cenário competitivo onde os lucros livres de risco são reduzidos a zero, o pesquisador vencedor deve acabar pagando o valor total de MEV em taxas prioritárias. 3 Portanto, se houver 100 ETH de lucro a serem obtidos com a interação 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 pesquisas sobre diferentes maneiras específicas de aplicação 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 através de pedidos de prioridade competitivos, 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 alguma função crescente dela. Por exemplo, o contrato pode exigir que quem o chama transfira applicationPriorityFee = 99 * proposerPriorityFee em ETH ao contrato. 4

Esta nova taxa é paga pelo pesquisador que envia a transação, por isso afeta o comportamento desse buscador. Se houver 100 MEV em uma oportunidade, a transação vencedora agora só definirá uma taxa de prioridade de 1 ETH, uma vez que isso resultará em um pagamento total de 100 ETH (1 ETH para o proponente do bloco e 99 ETH para o contrato inteligente). Qualquer taxa de prioridade mais elevada tornaria a transação não rentável; Qualquer taxa de prioridade mais baixa resultaria na perda da oportunidade para um concorrente que fixasse uma taxa mais elevada. 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 pedidos prioritários para seu próprio benefício, permitindo que ele recapture MEV para seus usuários, em vez de vazá-lo para o proponente do bloco.

Se esta taxa aumentar suficientemente rápido em função da prioridadeFeePerGas, apenas uma quantidade insignificante de MEV será acumulada para o proponente. Como priorityFeePerGas é denominado em wei (um bilionésimo de bilionésimo de um ETH), temos muita precisão para trabalhar. Por exemplo, longo como o imposto MEV é suficientemente sensível para que uma prioridadeFeePerGas de 50.000 resulte em um imposto proibitivamente alto, então 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 a ordem de maximizar suas próprias receitas. A aplicação destas regras de uma forma sem confiança é um problema em aberto.

Captura de MEV de aplicativo único

Aqui esboçamos como, em uma cadeia que tem a garantia de usar pedidos prioritários competitivos para a construção de blocos, os impostos MEV poderiam ser usados para mitigar três problemas importantes em MEV: permitir que as interfaces de DEX melhorem a execução de transações para swappers, permitir que os AMMs reduzam as perdas de arbitragem para seus LPs e permitir que as carteiras reduzam MEV vazamento para seus usuários vendendo o direito de backrun do usuário.

DEX routers

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

As versões atuais do UniswapX usam dois mecanismos para executar essa concorrência: 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.

Numa plataforma que garante ordens prioritárias competitivas, a UniswapX poderia substituí-las 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 em função da prioridade da transação.

Por exemplo, se Alice tem um ordem UniswapX para vender 1 ETH, ela pode definir o preço de execução do ordem como mínimoPreço + ($0,01 * priorityFeePerGas). preço mínimo pode ser algum valor fixo que ela espera ser significativamente menor do que o preço atual.

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

Se o preço mínimo de Alice é de US $ 3.000 e o preço atual de ETH é de US $ 3.500, a prioridade FeePerGas 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 wei – cerca de US$ 0,000035 – ao proponente do bloco.)

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

As encomendas que utilizam impostos MEV podem 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 bloco seguinte, 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. Isto significa que um licitante vencedor pode ter a garantia de que só está empenhado em preencher o ordem se a 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 multi-pool como o Uniswap v4.

AMMs

Normalmente, os AMMs vazam valor para arbitradores que negociam contra preços obsoletos no topo do bloco, conforme discutido nos loss-vs-rebalancing papers. Podemos usar MEV impostos para que os 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 publicará em breve uma solução.)

Um AMM pode capturar MEV cobrando uma taxa extra em função da taxa de prioridade na transação, permitindo que ele leiloe o direito de negociar primeiro no bloco. Existem muitas maneiras de calcular e denominar essa taxa. Discutiremos uma indiscutivelmente neutra — denominando-a em unidades de liquidez do pool, sqrt(xy). A transação vencedora seria a que mais aumentasse 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 pode impor a condição (com uma constante):

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

Esta fórmula incentivaria o trader de arbitragem a negociar com o preço real e, após essa negociação, o preço médio no pool deve 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 não informadas que desejam negociar no pool sem pagar um imposto MEV extra estabeleceriam uma taxa de baixa prioridade.

Existem muitas outras formas de aplicar impostos MEV sobre uma 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.

Leilões de backrunning

As descrições acima mostram como certos aplicativos podem ser projetados para evitar vazamentos de MEV. No entanto, e se uma carteira quiser tentar ajudar seus usuários a capturar as MEV que criam a partir de transações arbitrárias interagindo com qualquer aplicativo, mesmo aquelas 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" para mover 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ão 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, poderiam 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 assina uma intenção de que qualquer pessoa pode enviar à carteira de contrato inteligente de Alice para fazer com que ela tome essa ação. A carteira de contratos inteligentes de Alice cobra de quem envia essa transação um imposto MEV, que é pago a Alice.

O pesquisador que enviar a intenção de Alice terá o direito exclusivo de retrocedê-la, uma vez que pode fazê-lo atomicamente na mesma transação. Como resultado, se a pesquisa for competitiva, todo o lucro de backrunning Alice deve reverter para Alice através de seu imposto de 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 frontrun um usuário pode ser capaz de evitar o pagamento de um imposto MEV a esse usuário. Esse problema (e algumas possíveis mitigações para ele) é discutido com mais detalhes na seção Limitações abaixo. No entanto, isso poderia pelo menos ser uma melhoria em sistemas que usam mempools públicos sem quaisquer mitigações.

Outros casos de uso

Além desses exemplos, outros usos potenciais de impostos MEV poderiam 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 criam, como Leilões de refinanciamento oval
• em protocolos de empréstimo com garantia NFT como Blend
• Lending protocolo liquidações que vazam menos valor do que os leilões holandeses

Captura de MEV entre aplicativos

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 MEV esse imposto.

Mas e se a transação de um pesquisador 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 acima contra um AMM tributado pelo MEV?

Nesse caso, o montante relativo de excedentes MEV capturado por cada pedido é determinado pela forma como esses pedidos fixam os seus impostos MEV. Se o valor app_i cobra como um imposto MEV é dado pela função tax_i(prioridade), então a prioridade da transação vencedora pode ser determinada resolvendo a prioridade nesta equação:

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

(Tecnicamente, poderíamos adicionar um terceiro termo para priorityPerGas * gasUsed to conta for the priority fee paid to the block proponente, 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 (assim tax_1(priorityPerGas) = a_1 * priorityPerGas), você pode resolver para a parcela de MEV recebida por cada aplicação:

a_1 priorityPerGas + a_2 priorityPerGas = MEV

priorityPerGas = 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 de aplicação cruzada quando ocorre, mas significa que ele pode perder algum MEV de aplicação cruzada 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 MEV impostos 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 duas aplicações projetam seus impostos MEV 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 cobre nenhum imposto MEV sobre as 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 prioridade de US$ 0,01FeePerGas), para garantir que suas transações sejam incluídas depois que o pool já estiver arbitrado. Com esses impostos relativos, o AMM acabaria sendo o primeiro mesmo que houvesse apenas US$ 1 de MEV e US$ 50.000 de MEV em um ordem UniswapX.

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

Limitações

MEV impostos têm algumas complicações e desvantagens. Pensamos que cada uma destas é uma área interessante para investigação futura.

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 leal para a inclusão de transações, o que só pode acontecer se o proponente do bloco seguir regras que chamaremos de "ordem prioritária competitiva", em vez de maximizar sua própria receita. Informalmente e de forma não exaustiva, sugerimos que estas regras incluam:

• Ordenação prioritária. As transações dentro de um bloco devem ser ordenadas em ordem decrescente de prioridadeFeePerGas.
• 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 através de um ponto final 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.
• Não há último olhar. O proponente do bloco deve definir um tempo de bloqueio 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 uma ou mais dessas propriedades forem violadas, isso pode enfraquecer a eficácia dos impostos MEV. Um proponente de bloco que viole a censura resistência pode evitar a maioria dos impostos MEV excluindo transações concorrentes e enviando uma transação de prioridade zero que aproveite a oportunidade para si. Um proponente de bloqueio que viole a privacidade pré-transação pode roubar MEV de outras transações ou espiar suas taxas de prioridade para saber exatamente o quanto precisa definir o seu, enquanto um que é capaz de enviar transações mais tarde do que qualquer outra pessoa teria uma "última olhada" gratuita 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, enquanto a primeira propriedade seria fácil de aplicar no camada de protocolo, fazer cumprir 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 comprometa 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 Ethereum L1 MEV-Boost), os blocos provavelmente não as seguirão.

Esses problemas podem ser "resolvidos" com um único sequenciador confiável que se compromete a usar a ordem de prioridade competitiva para a construção de blocos. Eles também podem ser resolvidos com um mecanismo descentralizado usando alguma combinação de consenso, criptografia e/ou ambientes de execução confiáveis, como o Angstrom de Sorella, o SUAVE da Flashbots, Leaderless Auctions, ou Multiplicity.

Blocos completos

Uma exceção ao funcionamento normal dos impostos 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 tardiamente no bloco. Como as transações que interagem com aplicativos tributados por 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 aqueles que têm impostos de 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 estabelecendo 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á na inclusão de transações revertidas onchain, no pagamento de alguma taxa básica e congestionando a cadeia.

Se um sequenciador puder excluir totalmente as 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.

Vazamento de intenções de usuário

MEV impostos só funcionam se houver concorrência entre os buscadores, o que significa que a oportunidade precisa ser um pouco 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 pesquisadores.

Em alguns casos, a privacidade temporária perdida pela transmissão da 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 de MEV.

Por exemplo, suponha que Alice queira comprar um token de baixa liquidez usando o leilão de backrunning protocolo descrito acima. Ela publica uma intenção assinada para sua carteira de contrato inteligente para comprar esse token em um AMM, estabelecendo alguma tolerância de deslizamento. Os pesquisadores poderiam correr para empurrar o preço desse token para sua tolerância de deslizamento em uma transação de alta prioridade, sem preencher a 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 apoiá-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 a 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 sem valor 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 pesquisadores com os quais compartilham intenções e monitorando seu comportamento, como fazem muitos leilões de fluxo de pedidos existentes.

Também pode ser possível combinar impostos MEV com recursos de construção conscientes da privacidade, como previsto nos projetos da 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 mesma pode construir uma transação e enviá-la diretamente para o bloco. Como discutido acima, uma implementação ideal de ordem prioritária competitiva proporcionaria 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 prioridade 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 licitavam pelo direito de serem incluídos primeiro em um bloco, o que levou a grande parte do MEV de arbitragem de exchange descentralizada acumulando para mineradores.

Primeiro a chegar, primeiro a ser servido. Algumas tentativas de MEV mitigação por meio de regras de ordenação de transações, como Themis ou O sequenciador atual do Arbitrum One,7 se concentraram na aplicação de uma regra de ordenação diferente, primeiro a chegar, primeiro a ser servida (às vezes chamada de "ordem justa"), onde os proponentes de bloco devem ordem transações no ordem em que as vêem.

A ordem de prioridade adota uma abordagem diferente: tratar as transações que chegam dentro de um determinado período de forma igual e, em vez disso, ordená-las pela prioridade declarada.

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

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

Repartição de taxas. Blast, um 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 prioritárias), mas podem ser implementados na camada de aplicação em qualquer cadeia que use pedidos de prioridade competitivos, sem suporte especiais 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 sobre 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, não sugerem uma ordenação 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 a Sorella's Angstrom, Leaderless Auctions, Espresso and Offchain Labs' da Flashbots. @espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">descentralizada Timeboost e Conclusão

Esperamos que este post incentive os L2s a considerar o uso de pedidos prioritários (como é suportado por padrão no OP Stack) e inspire os aplicativos a experimentar MEV impostos quando suportados.

Também esperamos que isso motive mais pesquisas sobre protocolos para pedidos de prioridade competitiva minimizados de confiança em L1 e L2. Se você está interessado em colaborar nesse problema, e está lendo isso antes de quinta-feira, 6 de junho, você ainda pode se candidatar a uma bolsa TLDR para trabalhar em sequenciadores L2 resistentes a < href="https://www.tldresear.ch/tldr/tldr-request-for-papers/mev-resistant-l2-sequencers">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 são incluídas em um determinado bloco. Em Ethereum L2s, esse papel é tipicamente preenchido por um "sequenciador". No Ethereum L1, ele é preenchido por um validador de Ethereum específico chamado proponente, embora muitas vezes o proponente terceirize a tarefa de construir o bloco para um leilão competitivo no qual "retransmissores" e "construtores" 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 é realmente especificada explicitamente na transação, mas pode ser calculada nela. A transação especifica um preço do gás, mas Ethereum também cobra uma taxa básica, que é retirada do preço do gás e queimada. A taxa base deve ser ignorada para efeitos de impostos MEV, uma vez que não está sob o controlo 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 no Solidity como priorityGasPrice = tx.gasprice - block.basefee. ↩
3. Alternativamente, poderíamos simplesmente definir "MEV" para excluir qualquer lucro do pesquisador e apenas referir o 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, pois não há como saber quanto gás transação acabará usando. No entanto, isso geralmente não importa, já que tudo o que precisamos é de um limite superior para isso. Para estar seguro, você pode multiplicar priorityFeePerGas por 30 milhões — o gás máximo atual em um bloco Ethereum. Sobrestimar este valor significará simplesmente que o imposto MEV captura uma percentagem ainda maior de MEV. ↩
5. Supondo que uma transação não pode ser superior a 30 milhões de gás, uma prioridadeFeePerGas de 50.000 resultaria em um pagamento gás de 1500 gwei - cerca de US $ 0,006 a um preço ETH de US $ 4000. ↩
6. No caso em que priorityFeePerGas é definido de modo que o lucro do arbitrador seja zero, a negociação de arbitragem de maximização de lucro deve corresponder à mesma negociação no AMM de maximização de função function-maximizing. Provar isso fica como um exercício para o leitor. ↩
7. A Arbitrum discutiu a substituição disso por uma forma de ordenação prioritária chamada Timeboost, mas isso não foi colocado em produção até o momento em que este artigo foi escrito. ↩

Declaração de exoneração de responsabilidade:

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

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.