Introdução

Neste post, apresentamos impostos MEV, um mecanismo que aplicações arbitrárias podem usar para capturar seu próprio MEV.

Este mecanismo poderia ser usado hoje na OP Stack L2s como OP Mainnet, Base e Blast, porque os proponentes de bloco 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 uma aplicação cobrar dos buscadores um imposto MEV de (digamos) $99 para cada $1 de taxa de prioridade, ela pode capturar 99% do MEV competitivo para essa transação.

As taxas de MEV são uma técnica simples que abre um vasto espaço de design. Pode pensar nelas como permitindo que qualquer aplicação na cadeia execute o seu próprio leilão personalizado de MEV, sem necessitar de qualquer infraestrutura externa própria, apenas ao ligar-se a um único leilão partilhado executado pelo proponente de bloco.

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

• Roteadores de troca descentralizada (DEX) que otimizam o preço recebido pelo trocador
• Automated market makers (AMMs) que minimizam a perda-vs-rebalanceamento (LVR) vivenciada pelos provedores de liquidez
• Carteiras que permitem aos utilizadores capturar qualquer MEV de “backrunning” criado pelas suas transações

Mas há uma ressalva. Os impostos MEV só funcionam se os proponentes de bloco seguirem estritamente as regras de ordenação de prioridade competitiva, que incluem classificar transações por taxa de prioridade sem censurar, espiar ou atrasar qualquer. Se os proponentes de bloco se desviarem dessas regras, podem evitar os impostos MEV para capturar o valor para si próprios. Hoje, portanto, os impostos MEV dependem da confiança nos sequenciadores L2, e provavelmente não funcionariam de todo na Ethereum L1, onde a construção de blocos é dominada por um construtor de leilão competitivoque maximiza a receita para o proponente.

Ainda assim, o poder e a flexibilidade dos impostos MEV sugerem que a ordenação de prioridades pode ser a escolha certa para plataformas que a possam fornecer hoje. E a simplicidade relativa da ordenação de prioridades competitiva sugere que pode haver uma maneira viável de a aplicar de forma descentralizada, sem ter de confiar num único sequenciador. Esperamos que este post motive mais trabalho nesse problema.

Ordenação de prioridade

Quando alguém envia uma transação em um Ethereum L1 ou L2, eles especificam uma taxa de prioridade, que eles pagam ao proponente do bloco.1Pode imaginar que isto é especificado como priorityFeePerGas, um número que é multiplicado pelo gás utilizado na transação para obter builderPriorityFee—o pagamento total em ETH.2

Não existe nenhuma regra no protocolo Ethereum que as transações em um bloco devem ser ordenadas de forma gananciosa por prioridade decrescente por taxaPorGás. No entanto, essa é uma maneira popular de construir blocos—por exemplo, é o algoritmo padrão usado pelos sequenciadores de Pilha OPcadeias, bem como geth e reth. Não só a ordenação de prioridades permite que os transatores expressem eficientemente a urgência de suas transações, como também direciona naturalmente certos tipos de MEV para o proponente do bloco.

Isso acontece porque a ordenação por prioridade transforma a competição por MEV em um leilão de gás prioritárioQuando existe uma oportunidade de lucrar ao interagir com a cadeia, como arbitrar uma AMM contra uma troca centralizada, os pesquisadores competem para reivindicar essa oportunidade primeiro. Se a cadeia usa a ordenação por prioridade para determinar a inclusão e ordenação de transações, os pesquisadores competem definindo taxas de prioridade elevadas em suas transações.

Num cenário competitivo onde os lucros livres de risco são reduzidos a zero, o pesquisador vencedor deverá acabar por pagar o valor total do MEV em taxas de prioridade.3Portanto, se houver 100 ETH de lucro a ser obtido ao interagir com um contrato, a primeira transação para reivindicá-lo definirá uma taxa de prioridade de 100 ETH. (Discutimos algumas ressalvas sobre isso na seção Limitações).

impostos de MEV

Suponha que um contrato inteligente queira capturar o MEV de qualquer transação que interaja com ele. Existe uma vasta biblioteca de pesquisas sobre diferentes maneiras específicas de aplicação que os contratos inteligentes poderiam tentar capturar seu próprio MEV.

Mas, na realidade, não é necessário saber nada sobre a aplicação. Se soubermos que o bloco está a ser construído através da ordenação competitiva de prioridades, então temos um sinal universal para a quantidade de MEV na transação: a taxa de prioridade.

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

Esta nova taxa é paga pelo pesquisador que envia a transação, afetando assim o comportamento desse pesquisador. 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 alta tornaria a transação não lucrativa; qualquer taxa de prioridade mais baixa resultaria na perda da oportunidade para um concorrente que definiu uma taxa mais alta. Isso significa que o contrato inteligente capturou 99% do MEV na transação.

Chamamos a esta taxa extra imposta pelo contrato inteligente de um imposto MEV. Os impostos MEV permitem que uma aplicação seque a ordem de prioridade para seu próprio benefício, permitindo-lhe recapturar o MEV para seus utilizadores em vez de o deixar escapar para o proponente do bloco.

Se esta taxa aumentar suficientemente rápido como função de priorityFeePerGas, então apenas uma quantidade negligenciável de MEV será acumulada para o proponente. Uma vez que priorityFeePerGas é denominado em wei (um bilionésimo de um bilionésimo de um ETH), temos muita precisão para trabalhar. Por exemplo, desde que o imposto MEV seja suficientemente sensível para que um priorityFeePerGas de 50.000 resulte em um imposto proibitivamente alto, então o pagamento total ao proponente seria inferior a $0.01.5

No entanto, há uma ressalva importante. Como discutido na secção de Limitações, os impostos MEV só funcionam se os proponentes de blocos seguirem certas regras - o que chamamos de 'ordenação de prioridade competitiva' - em vez de se desviarem dessas regras para maximizar a sua própria receita. Fazer cumprir estas regras de forma confiável é um problema em aberto.

Captura de MEV de aplicação única

Aqui esboçamos como, numa cadeia que tem garantia de utilizar a ordenação de prioridade competitiva para a construção de blocos, os impostos MEV poderiam ser usados para mitigar três problemas importantes no MEV: permitindo que interfaces DEX melhorem a execução comercial para trocadores, permitindo que as AMMs reduzam as perdas de arbitragem para seus LPs e permitindo que carteiras reduzam a fuga de MEV para seus usuários vendendo o direito de retroceder o usuário.

roteadores DEX

Em protocolos de roteamento DEX baseados em intenções como UniswapXe1inch Fusão, um usuário (Alice) assina uma intenção de troca, e os pesquisadores competem para encaminhar ou preencher essa intenção pelo melhor preço possível para Alice.

As versões atuais do UniswapX utilizam 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 fora da cadeia de solicitação de cotação (RFQ) para definir o preço inicial desse leilão holandês.

Numa plataforma que garante a ordenação prioritária competitiva, o UniswapX poderia substituir esses por um único mecanismo: um imposto MEV. Poderia implementar isso fazendo com que o utilizador assine uma ordem que pode ser preenchida 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 uma ordem UniswapX para vender 1 ETH, ela poderia definir o preço de execução da ordem como minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice poderia ser um valor fixo que ela espera que seja significativamente inferior ao preço atual.

Os pesquisadores competiriam para preencher o pedido de Alice, enviando transações. Qualquer transação com a taxa de prioridade mais alta e que não reverta conseguiria preencher o pedido, o que deveria 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 for de $3,000 e o preço atual do ETH for de $3,500, o priorityFeePerGas na transação vencedora seria cerca de 50,000. (Observe que numa transação que custa 200,000 gas, isso resultará num pagamento de apenas cerca de 10 bilhões de wei - cerca de $0.000035 - para o proponente do bloco).

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

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

Ao contrário de um RFQ offchain, o leilão para preencher uma ordem que utiliza impostos MEV aconteceria atomicamente com a execução da transação onchain. Isso significa que um licitante vencedor poderia garantir que só se comprometem a preencher a ordem se a sua transação onchain tiver sucesso. Isso poderia facilitar a concorrência da liquidez onchain, como AMMs, com a liquidez offchain, significando que a UniswapX poderia servir como um roteador ainda mais eficaz para sistemas multipool como Uniswap v4.

AMMs

Normalmente, as AMMs vazam valor para os arbitragistas que negociam contra preços desatualizados no topo do bloco, como discutido no perda-vs-rebalanceamento papéis. Podemos usar impostos MEV para fazer com que AMMs capturem esse MEV. Para manter as coisas simples, vamos discutir como isso pode funcionar em um AMM sem liquidez concentrada. (Se você estiver interessado em como esse tipo de problema poderia ser resolvido com liquidez concentrada, Sorellaem breve publicará uma solução.)

Um AMM pode capturar MEV cobrando uma taxa extra como uma função da taxa de prioridade na transação, permitindo-lhe leiloar o direito de negociar primeiro no bloco. Existem muitas maneiras de calcular e denominar essa taxa. Vamos discutir uma forma, provavelmente neutra, de denominá-la em unidades de liquidez da pool, sqrt(xy). A transação vencedora seria aquela que aumenta a liquidez da pool ao máximo.

Ao executar a primeira transação em um pool em um bloco, em vez de impor a condição x_endy_end > x_starty_start, o pool poderia impor a condição (com a como uma constante):

x_endy_end > (sqrt(x_starty_start) + a*priorityFeePerGas)^2

Esta fórmula incentivaria o trader de arbitragem a negociar pelo preço real e, após essa negociação, o preço intermediário na pool deveria ser o preço real.6

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

Existem muitas outras maneiras de implementar impostos MEV numa AMM que teriam efeitos diferentes. Por exemplo, os impostos MEV poderiam ser denominados na moeda de entrada ou saída da troca, poderiam afetar a percentagem da taxa de troca aplicada pela pool, ou poderiam determinar o preço mínimo da troca do utilizador. Achamos que este é um espaço de design interessante para explorar.

Leilões de retrocesso

As descrições acima mostram como certas aplicações poderiam ser projetadas para evitar vazamentos de MEV. No entanto, e se uma carteira quiser tentar ajudar seus usuários a capturar o MEV que criam a partir de transações arbitrárias interagindo com qualquer aplicação, mesmo aquelas que não incorporam taxas de MEV?

Por exemplo, quando Alice faz uma transação grande em um AMM, às vezes cria uma oportunidade de arbitragem para os "backrunners" moverem o preço de volta. Normalmente, isso vaza para o MEV, em vez de ir para Alice.

MEV-ShareeMEVBlockersão dois protocolos que permitem aos utilizadores capturar o MEV das suas transações, mas dependem de um sistema complexo de leilões fora da cadeia.O Espaço de Design de Leilão de Fluxo de Ordensdescreve algumas outras soluções.

Impostos MEV, quando combinados com uma carteira inteligente baseada em intenções, poderiam permitir-nos construir um sistema alternativo para capturar o MEV de backrunning para Alice. Suponha que, em vez de criar uma transação que negocia na AMM, Alice assine uma intenção que qualquer pessoa possa submeter à carteira inteligente de Alice para fazer com que ela execute essa ação. A carteira inteligente de Alice cobra quem submete essa transação um imposto MEV, que é pago a Alice.

O pesquisador que submeter 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 retroceder Alice deve reverter para Alice através do seu imposto de MEV.

Note que este sistema pode não necessariamente proteger os utilizadores de ataques que envolvem a antecipação de transações do utilizador, porque uma transação que antecipa a transação de um utilizador pode ser capaz de evitar pagar um imposto de MEV a esse utilizador. Esta questão (e algumas possíveis mitigations para ela) é discutida com mais detalhes na secção de Limitações abaixo. No entanto, isso poderia pelo menos ser uma melhoria em sistemas que utilizam mempools públicos sem quaisquer mitigations.

Outros casos de uso

Para além destes exemplos, outros usos potenciais de impostos MEV poderiam incluir quase tudo o que atualmente utiliza uma offchain ou leilão holandês, como:

• Protocolos para oráculos capturarem o valor extraível do oráculo que criam, como Oval
• Leilões de refinanciamento em protocolos de empréstimos garantidos por NFT como Misturar
• Protocolos de liquidação de empréstimos que vazar menos valordo que leilões holandeses

Captura de MEV entre aplicações

As soluções acima são projetadas para capturar o MEV ao interagir com uma única aplicação. Mas às vezes pode ser possível para um pesquisador capturar ainda mais valor ao interagir com várias aplicações na mesma transação.

Se apenas uma dessas aplicações tiver um imposto MEV, então todo o MEV da transação deve ir para a aplicação com o imposto MEV, independentemente de quão alto ou baixo esse imposto MEV seja.

Mas e se a transação de um pesquisador interagir com duas aplicações que usem impostos MEV? Por exemplo, e se houver algum MEV que só possa ser capturado preenchendo uma das ordens UniswapX taxadas com MEV descritas acima contra um AMM taxado com MEV?

Nesse caso, a quantidade relativa de MEV em excesso capturada por cada aplicação é determinada pela forma como essas aplicações definem seus impostos MEV. Se o valor que a aplicação app_i cobra como imposto MEV é dado pela função tax_i(priority), então a prioridade da transação vencedora pode ser determinada ao resolver a prioridade nesta equação:

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

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

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

a_1 prioridadePorGas + a_2priorityPerGas = MEV

prioridadePorGas = 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, uma aplicação enfrenta um dilema - impostos mais altos permitem capturar uma maior parte do MEV entre aplicações quando ocorre, mas significa que poderá perder algum MEV entre aplicações se houver maneiras concorrentes de extrair. Por exemplo, se houver um AMM que cobra um imposto MEV em cada negociação, então uma ordem UniswapX com imposto MEV pode ser mais provável de ser preenchida 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 para compartilhar o MEV de uma forma que maximize o bem-estar de cada uma. Por exemplo, uma AMM com imposto MEV provavelmente gostaria de capturar valor de um único trader informado perto do topo do bloco, mas então gostaria de fornecer liquidez a outros traders e aplicações (incluindo aqueles que usam impostos MEV) com uma taxa fixa baixa. Nesse caso, a AMM provavelmente definirá um imposto MEV relativamente baixo (digamos, $0.00001priorityFeePerGas), para que a transação de arbitragem (se houver) ocorra cedo no bloco e, em seguida, não cobre imposto MEV em transações subsequentes no bloco. Aplicações como UniswapX que desejam interagir com o AMM podem definir um imposto MEV muito mais alto (digamos $0.01 priorityFeePerGas), para garantir que suas transações sejam incluídas após a arbitragem da pool. Com esses impostos relativos, a AMM acabaria sendo arbitrária primeiro, mesmo que houvesse apenas $1 de MEV nela e $50.000 de MEV em uma ordem UniswapX.

Achamos que este é um amplo espaço de design que merece ser estudado no futuro.

Limitações

As taxas de MEV têm algumas complicações e inconvenientes. Achamos que cada uma delas é uma área interessante para pesquisa futura.

Incentivo à incompatibilidade

Os impostos MEV não são compatíveis com incentivos para um proponente de bloco monopolista. Eles só funcionam se houver uma competição justa para inclusão de transações, o que só pode acontecer se o proponente de bloco seguir regras que chamaremos de “ordenação de prioridade competitiva”, em vez de maximizar sua própria receita. Informalmente e de forma não exaustiva, sugerimos que essas regras devem incluir:

• Ordenação de prioridade. As transações dentro de um bloco devem ser ordenadas em ordem decrescente de priorityFeePerGas.
• Resistência à censura. Se o proponente de bloco recebe uma transação t1 durante o bloco, e o bloco não está cheio ou inclui 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 de bloco deve aceitar transações através de um endpoint privado e não deve partilhar tais transações com mais ninguém antes de se comprometer com o bloco, ou usar o conteúdo dessas transações como entrada na construção das suas próprias transações.
• Sem última análise. O proponente de bloco deve definir um tempo definitivo blockTime antes do qual aceitam transações de qualquer pessoa e após o qual 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 resistência à censura 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, embora a primeira propriedade seja fácil de aplicar na camada do protocolo, aplicar as outras propriedades de forma confiável é um problema em aberto.

Na ausência de execução a nível do protocolo, um único sequenciador que se compromete com estas regras precisa de ser confiável para não se desviar delas e, se os proponentes externalizarem a construção de blocos para um leilão competitivo de maximização de receita (como o Ethereum L1’sMEV-Boost) Os blocos provavelmente não os seguirão.

Estes problemas podem ser “resolvidos” com um único sequenciador confiável que se compromete a usar a ordenação 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 da Sorella, o SUAVE da Flashbots, Leilões sem líder, ou Multiplicidade.

Blocos cheios

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

Transações revertidas

Os impostos MEV dependem efetivamente de leilões de bloco único nos quais cada "licitação" é uma transação. Uma desvantagem desses leilões é que as licitações perdedoras geralmente resultarão em transações revertidas sendo incluídas onchain, pagando alguma taxa base e congestionando a cadeia.

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

Vazamento de intenções do usuário

Impostos MEV só funcionam se houver concorrência entre os pesquisadores, 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 aplicações como roteamento baseado em intenção ou leilões de backrunning, isso significa que a aplicação pode precisar compartilhar a intenção do usuário com os pesquisadores.

Em alguns casos, a perda temporária de privacidade ao divulgar a intenção do usuário antes de ser cumprida pode vazar valor de uma forma que não pode ser recuperada por um imposto MEV.

Por exemplo, suponha que Alice queira comprar um token de baixa liquidez usando o protocolo de leilão de retrocesso descrito acima. Ela publica uma intenção assinada para a sua carteira de contrato inteligente comprar esse token em uma AMM, definindo alguma tolerância de deslizamento. Os pesquisadores poderiam correr para empurrar o preço desse token para a tolerância de deslizamento dela em uma transação de alta prioridade, sem preencher a ordem do usuário. O vencedor, Bob, poderia então preencher a intenção de Alice de forma não competitiva, incluindo e retrocedendo-a em uma transação de baixa prioridade, assim envolvendo a negociação de Alice e dando-lhe um preço pior enquanto evita o seu imposto MEV. Um problema semelhante poderia acontecer com compras de NFTs.

Note-se que tal ataque seria arriscado para Bob, uma vez que ele não seria capaz de garantir a atomicidade entre a compra do token e a sua venda a Alice. Um Bob ingênuo poderia cair vítima de uma armadilha de “ripagem de sanduíche” na qual Alice publica a intenção de comprar um token sem valor dela mesma, fazendo com que Bob o compre antecipando-se a intercalar a sua troca, mas Alice revoga a sua intenção antes que Bob consiga completar a sanduíche.

As aplicações também podem ser capazes de mitigar isso limitando o conjunto de pesquisadores com os quais compartilham intenções e monitorizando seu comportamento, tal como muitos leilões de fluxo de ordens existentes fazem.

Também pode ser possível combinar impostos de MEV com funcionalidades de construção conscientes da privacidade como previsto nos designs da Flashbots para SUAVE.

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

Discussão e trabalhos anteriores

Leilões de gás prioritários. Algumas das dinâmicas de ordenação prioritária em blockchains descentralizados foram estudadas no Flash Boys 2.0paper, que cunhou o termo “valor extraível pelo minerador.” Esse artigo observou que os mineradores de Ethereum (quando essa rede usava prova de trabalho) já estavam ordenando transações por prioridade, e que os arbitragistas estavam contando com esse comportamento para participar de “leilões de gás prioritário” nos quais eles licitavam pelo direito de serem incluídos primeiro em um bloco, o que levou grande parte do MEV da arbitragem em exchanges descentralizadas a acumular-se para os mineradores.

Primeiro a chegar, primeiro a ser servido. Algumas tentativas de mitigação de MEV através de regras de ordenação de transações, como Themisousequenciador atual do Arbitrum One,7tenho-me concentrado em fazer cumprir uma regra de ordenação diferente, primeiro a chegar, primeiro a ser servido (às vezes chamado de "ordem justa"), onde os proponentes de blocos devem ordenar as transações na ordem em que as veem.

A ordem de prioridade adota uma abordagem diferente, tratando as transações que chegam dentro de um determinado período de forma igual e ordenando-as pelo seu nível de prioridade declarado.

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 pode, como lucros de arbitragem de "saltos" descontínuos nos preços dos ativos. As vantagens potenciais da encomenda prioritária em relação à encomenda por 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).

Entretanto, embora a ordenação prioritária pareça vazar valor para MEV por padrão, esta postagem mostra como as aplicações podem ser projetadas para recapturá-lo.

Partilha de taxas. Blast, uma Ethereum L2,açõesuma parte tanto das taxas prioritárias quanto das taxas base com os contratos inteligentes acedidos numa transação.

As taxas de MEV permitem algo semelhante (pelo menos para taxas de prioridade), mas podem ser implementadas na camada de aplicação em qualquer cadeia que utilize uma ordenação de prioridade competitiva, sem suporte especial para partilha de taxas. Permitem também que as aplicações definam as suas próprias taxas como funções personalizadas da taxa de prioridade, proporcionando mais flexibilidade e potencialmente resultando numa maior composição de aplicações conscientes de MEV.

Soluções sem confiança. Esta publicação foca na motivação para plataformas usarem a ordenação de prioridade competitiva - e maneiras de tirar proveito das plataformas que o fazem - em vez de discutir como aplicá-lo sem confiança.

Houve uma significativa discussão prévia de cada uma das outras propriedades necessárias para a ordenação prioritária 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 design para um leilão resistente à censura usando vários proponentes simultâneos. No entanto, eles não sugerem uma ordenação específica para transações.

Houve outras pesquisas sobre a construção de mecanismos para a construção de blocos minimizados de confiança, incluindo a Flashbots’sELEGANTE, SorellaAngstrom do Leilões sem líder, Espresso e Offchain Labs’@espressosys/espresso-systems-and-offchain-labs-release-r-d-roadmap-for-decentralized-timeboost-5d0007dff66d">decentralized Timeboost, and inclusão obrigatória de transações públicaspor Péter Szilági.

Conclusão

Esperamos que esta publicação encoraje os L2s a considerar a utilização de encomendas prioritárias (como é suportado por omissão no OP Stack) e inspire as aplicações a experimentar impostos MEV onde for suportado.

Esperamos também que isso motive mais investigação sobre protocolos para ordenação de prioridades competitivas com minimização de confiança tanto em L1 quanto em L2. Se estiver interessado em colaborar nesse problema e estiver a ler isto antes de quinta-feira, 6 de junho, ainda pode candidatar-se a uma Bolsa TLDR para trabalhar emSequenciadores L2 resistentes a MEVcom o Dan. Ou sinta-se à vontade para entrar em contato comdan@paradigm.xyzedave@paradigm.xyzcom ideias!

Notas de rodapé

1. Neste post, usamos “proponente” para nos referirmos ao ator ou processo que determina quais transações são incluídas num bloco específico. Nas camadas 2 da Ethereum, este papel é normalmente desempenhado por um “sequenciador”. Na camada 1 da Ethereum, é desempenhado por um validador específico da Ethereum chamado proponente, embora frequentemente o proponente subcontrate a tarefa de construir o bloco a um leilão competitivo no qual “relayers” e “builders” participam. Os detalhes de como essas responsabilidades são divididas estão fora do âmbito deste post.↩
2. A taxa de prioridade por gas não é realmente especificada explicitamente na transação, mas pode ser calculada nela. A transação especifica um preço por gas, mas o Ethereum também cobra uma taxa base, que é retirada do preço por gas e queimada. A taxa base deve ser ignorada para efeitos de impostos MEV, uma vez que não está sob controle do transator. A taxa de prioridade por gas - o preço pela 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 referir apenas o valor que seria destinado ao validador.↩
4. Note que a proposerPriorityFee—igual ao priorityFeePerGas vezes o total de gás utilizado na transação—não pode realmente ser calculada durante o contrato, uma vez que não há forma de saber quanto gás a transação acabará por utilizar. No entanto, isto geralmente não importará, uma vez que tudo o que precisamos é de um limite superior para isso. Para estar seguro, poderia multiplicar o priorityFeePerGas por 30 milhões—o máximo atual de gás num bloco Ethereum. Sobreestimar este valor significará simplesmente que o imposto MEV captura uma percentagem ainda maior de MEV.↩
5. Supondo que uma transação não possa ter mais de 30 milhões de gás, uma priorityFeePerGas de 50.000 resultaria em um pagamento de gás de 1500 gwei—cerca de $0.006 a um preço do ETH de $4000.↩
6. No caso em que priorityFeePerGas é definido de forma a que o lucro do arbitragem seja zero, o comércio de arbitragem maximizador de lucro deve corresponder ao mesmo comércio no maximização de função AMM. Provar isso é deixado como um exercício para o leitor. ↩
7. Arbitrum tem discutidosubstituindo isso por uma forma de ordenação de prioridade chamada Timeboost, mas isso ainda não foi colocado em produção até o momento desta escrita.

Aviso legal：

1. Este artigo foi republicado de [paradigma], Todos os direitos de autor pertencem ao autor original [Dan Robinson, Dave White]. Se houver objeções a esta reimpressão, por favor contacte o Gate Learnequipa e eles tratarão disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente as do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.