Introdução

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

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

Para implementar um imposto MEV em uma dessas redes, um contrato inteligente cobra uma taxa que é uma função da taxa de prioridade da transação. Mostramos que se um aplicativo cobra dos pesquisadores um imposto MEV de (digamos) $99 para cada $1 de taxa de prioridade, ele 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. Você pode pensar nelas como permitindo que qualquer aplicativo na cadeia execute seu próprio leilão personalizado de MEV, sem precisar de nenhuma infraestrutura externa própria, apenas se conectando a um único leilão compartilhado realizado pelo proponente de bloco.

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

• Roteadores de trocas descentralizadas (DEX) que otimizam o preço recebido pelo trocador
• Automated market makers (AMMs) que minimizam a perda-vs-rebalanceamento (LVR) experienciada pelos provedores de liquidez
• Carteiras que permitem aos seus usuários capturar qualquer MEV de "backrunning" criado por suas transações

Mas há uma pegadinha. Os impostos MEV só funcionam se os proponentes de bloco seguirem estritamente as regras de ordenação prioritária competitiva, que incluem classificar transações por taxa de prioridade sem censura, espreitar ou atrasar qualquer. Se os proponentes do bloco se desviarem dessas regras, eles podem evitar impostos MEV para capturar o valor para si mesmos. Hoje, portanto, os impostos MEV dependem da confiança nos sequenciadores L2, e provavelmente não funcionariam no Ethereum L1, onde a construção de blocos é dominada por um.construtor competitivo leilãoque maximiza a receita para o proponente.

Ainda assim, o poder e a flexibilidade das taxas de MEV sugerem que a ordenação de prioridades pode ser a escolha certa para plataformas que podem fornecê-la hoje. E a simplicidade relativa da ordenação de prioridades 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 esta postagem motive mais trabalho sobre esse problema.

Pedido 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.1Você pode imaginar isso como 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á regra no protocolo Ethereum de que transações em um bloco devem ser ordenadas gananciosamente por prioridadeFeePerGas decrescente. No entanto, essa é uma maneira popular de construir blocos -- por exemplo, é o algoritmo padrão usado pelos sequenciadores de OP Stackcadeias, bem como geth e reth. Não apenas a ordem de prioridade permite que os transatores expressem eficientemente a urgência de suas transações, também canaliza naturalmente certos tipos de MEV para o proponente do bloco.

Isso acontece porque a ordenação de prioridade transforma a competição por MEV em um leilão de gás prioritárioQuando há uma oportunidade de lucrar interagindo com a cadeia, como arbitragem entre uma AMM e uma exchange centralizada, os buscadores competem para reivindicar essa oportunidade primeiro. Se a cadeia usa a ordem de prioridade para determinar a inclusão e a ordem das transações, os buscadores competem definindo taxas de prioridade altas 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 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. Há 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 verdade, não precisamos necessariamente saber nada sobre a aplicação. Se soubermos que o bloco está sendo construído através da ordenação 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 verificar 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 para o contrato.4

Esta nova taxa é paga pelo pesquisador que envia a transação, portanto afeta 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, pois 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 em perder a oportunidade para um concorrente que definiu uma taxa mais alta. Isso significa que o contrato inteligente capturou 99% do MEV na transação.

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

Se essa 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 o 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 resultasse em um imposto proibitivamente alto, então o pagamento total para o proponente seria inferior a $0.01.5

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

Captura de MEV de aplicação única

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 no MEV: permitir que interfaces DEX melhorem a execução de negociações para trocadores, permitir que AMMs reduzam as perdas de arbitragem para seus LPs, e permitir que carteiras reduzam o vazamento de MEV para seus usuários vendendo o direito de retroceder o usuário.

DEX routers

Em protocolos de roteamento DEX baseados em intenção como UniswapXe1inch Fusão, 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 da 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 de solicitação de cotação fora da cadeia (RFQ) para definir o preço inicial desse leilão holandês.

Em uma plataforma que garante a ordenação de prioridade competitiva, UniswapX poderia substituir esses por um único mecanismo: um imposto MEV. Isso poderia ser implementado fazendo com que o usuário 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 um pedido UniswapX para vender 1 ETH, ela poderia definir o preço de execução do pedido como minimumPrice + ($0.01 * priorityFeePerGas). minimumPrice poderia ser um valor fixo que ela espera que seja significativamente menor do que o 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 seria a escolhida para preencher o pedido, 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 for de $3.000 e o preço atual do ETH for de $3.500, a priorityFeePerGas na transação vencedora seria de cerca de 50.000. (Observe que em uma transação que custa 200.000 gas, isso resultará em um pagamento de apenas cerca de 10 bilhões de wei—cerca de $0.000035—para o proponente do bloco.)

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

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

Ao contrário de um RFQ offchain, o leilão para preencher um pedido que usa impostos MEV aconteceria atomicamente com a execução da transação onchain. Isso significa que um licitante vencedor poderia ter a garantia de que só está comprometido em preencher o pedido se a transação onchain for bem-sucedida. Isso poderia facilitar a competição da liquidez onchain, como AMMs, com a liquidez offchain, o que significa que o UniswapX poderia servir como um roteador ainda mais eficaz para sistemas multi-pool como Uniswap v4.

AMMs

Normalmente, os AMMs vazam valor para os arbitrageurs 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 os AMMs capturem esse MEV. Para manter as coisas simples, discutiremos como isso poderia 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 estará publicando uma solução.)

Um AMM pode capturar MEV cobrando uma taxa extra como função da taxa de prioridade na transação, permitindo leiloar o direito de negociar primeiro no bloco. Existem muitas maneiras de calcular e denominar essa taxa. Vamos discutir uma maneira possivelmente neutra - denominando-a em unidades de liquidez do pool, sqrt(xy). A transação vencedora seria aquela que aumenta a liquidez do pool em maior quantidade.

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, a 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 médio no pool deve ser o preço real.6

Após essa primeira transação, as negociações poderiam funcionar como fazem 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 em um AMM que teriam diferentes efeitos. Por exemplo, os impostos MEV poderiam ser denominados na entrada ou saída do token da troca, poderiam afetar a porcentagem da taxa de troca aplicada pelo pool, ou poderiam 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 algumas 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 eles criam a partir de transações arbitrárias interagindo com qualquer aplicação, mesmo aquelas que não incorporam impostos MEV?

Por exemplo, quando Alice faz uma transação grande em um AMM, às vezes ela 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-ShareeMEVBlockersão dois protocolos que permitem aos usuários capturar MEV de suas transações, mas eles dependem de um sistema de leilão complexo fora da cadeia.O Espaço de Design de Leilão de Fluxo de Ordemdescreve algumas outras soluções.

Impostos MEV, quando combinados com uma carteira de contrato inteligente baseada em intenções, poderiam nos permitir 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 assina uma intenção que qualquer pessoa pode enviar para a carteira de contrato inteligente de Alice para fazê-la realizar essa ação. A carteira de contrato inteligente de Alice cobra de quem enviar 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, pois pode fazê-lo atomicamente na mesma transação. Como resultado, se a busca for competitiva, todo o lucro de retroceder Alice deve ser creditado a Alice por meio de seu imposto MEV.

Observe que este sistema pode não necessariamente proteger os usuários de ataques que envolvem a antecipação de transações do usuário, porque uma transação que antecipa uma transação do usuário pode ser capaz de evitar o pagamento de um imposto MEV para esse usuário. Esta questão (e algumas possíveis mitigação para ela) é discutida com mais detalhes na seção Limitações abaixo. No entanto, isso poderia ser pelo menos uma melhoria em sistemas que usam mempools públicos sem nenhuma mitigação.

Outros casos de uso

Além desses exemplos, outros usos potenciais de impostos de 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 Oval
• Leilões de refinanciamento em protocolos de empréstimo com garantia NFT como Mistura
• Protocolo de empréstimo de liquidação 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 um único aplicativo. Mas às vezes pode ser possível para um pesquisador capturar ainda mais valor ao interagir com vários aplicativos 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 usam 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 aplicativo é determinada pela forma como esses aplicativos definem seus impostos MEV. Se o valor app_i cobrado como imposto MEV é dado pela função tax_i(priority), 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 para considerar a taxa de prioridade paga ao propositor do bloco, mas vamos ignorar isso, uma vez que, como discutido no Apêndice A, provavelmente será negligenciável em 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 de MEV recebida por cada aplicativo:

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, um aplicativo enfrenta um dilema - impostos mais altos permitem que ele capture uma maior parcela de MEV entre aplicativos quando ocorre, mas significa que poderia perder algum MEV entre aplicativos se houver maneiras concorrentes de extraí-lo. Por exemplo, se houver um AMM que cobra um imposto MEV em cada negociação, então uma ordem UniswapX com imposto MEV pode ter mais chances de ser preenchida por um AMM diferente ou um preenchimento offchain.

Em muitos casos, pode haver um equilíbrio em que duas aplicações projetam seus impostos MEV para compartilhar o MEV de uma maneira que maximize o bem-estar de cada uma. Por exemplo, um 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 aquelas que usam impostos MEV) com uma taxa fixa baixa. Nesse caso, o AMM provavelmente definirá um imposto MEV relativamente baixo (digamos, $0.00001 priorityFeePerGas), para que a transação de arbitragem (se houver) ocorra cedo no bloco e, em seguida, não cobre imposto MEV sobre transações subsequentes no bloco. Aplicativos como UniswapX que desejam interagir com a AMM podem definir um imposto MEV muito mais alto (digamos $0.01 taxaPrioritáriaPorGás), para garantir que suas transações sejam incluídas depois que o pool for arbitrado. Com esses impostos relativos, o AMM acabaria sendo arbitrado primeiro, mesmo que houvesse apenas $1 de MEV nele e $50,000 de MEV em uma ordem UniswapX.

Achamos que este é um amplo espaço de design que vale a pena estudar no futuro.

Limitações

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

Incentivo à incompatibilidade

Impostos MEV não são compatíveis com incentivos para um proponente de bloco monopolista. Eles só funcionam se houver competição justa para inclusão de transações, o que só pode acontecer se o proponente de bloco seguir regras que chamaremos de "ordem de prioridade competitiva", em vez de maximizar sua própria receita. De forma informal e 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 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 de bloco deve aceitar transações através de um ponto final privado e não deve compartilhar 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 de suas próprias transações.
• No last look. O proponente de bloco deve definir um tempo definido blockTime 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 viola a resistência à censura 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 o 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 ser aplicada na camada do protocolo, fazer cumprir as outras propriedades de forma confiável é um problema em aberto.

Na ausência de execução na camada do 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 Ethereum L1's GateMEV-Boost) , os blocos provavelmente não os seguirão.

Essas questões podem ser "resolvidas" com um único sequenciador confiável que se compromete a usar a ordenação de prioridade competitiva para a construção de blocos. Elas também podem ser resolvidas 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 à operação normal das taxas de 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 tardiamente no bloco. Uma vez que as transações que interagem com aplicações taxadas com MEV provavelmente terão taxas de prioridade extremamente baixas, é provável que essas aplicações sejam excluídas por aplicações que não usam taxas de MEV, ou por aquelas que têm taxas de MEV extremamente baixas. No entanto, em uma cadeia que utiliza 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 adiadas quando os blocos estão cheios, atrasar transações que expressam menor urgência ao definir taxas de MEV mais altas pode ser um resultado razoável.

Transações revertidas

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

Se um sequenciador puder excluir transações falhadas completamente, isso poderia aliviar esse problema, embora possa ser difícil de implementar mesmo com um sequenciador centralizado. (Isso 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 elas 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 competição 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 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 buscadores.

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

Por exemplo, suponha que Alice queira comprar um token de baixa liquidez usando o protocolo de leilão de antecipação descrito acima. Ela publica uma intenção assinada para sua carteira de contrato inteligente comprar esse token em um AMM, definindo alguma tolerância de derrapagem. Os buscadores poderiam correr para empurrar o preço desse token até a tolerância de derrapagem 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-a e antecipando-a em uma transação de baixa prioridade, assim envolvendo a negociação de Alice e dando a ela um preço pior enquanto evita o imposto MEV dela. Um problema semelhante poderia acontecer com a compra de NFTs.

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

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

Também pode ser possível combinar impostos de MEV com recursos de construção conscientes de privacidade, como imaginado nos designs 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 poderia construir uma transação por si mesma e enviá-la diretamente para o bloco. Como discutido acima, uma implementação ideal da ordenação de prioridade competitiva forneceria privacidade pré-transação do proponente do bloco.

Discussão e trabalho anterior

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

Primeiro a chegar, primeiro a ser servido. Algumas tentativas de mitigação do MEV por meio de regras de ordenação de transações, como Themisousequenciador atual do Arbitrum One,7tenho focado em fazer cumprir uma regra de ordem diferente, primeiro a chegar, primeiro a ser servido (às vezes chamado de “ordem justa”) onde os proponentes de bloco devem ordenar 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 período dado de forma igual e ordenando-as pelo seu valor de prioridade declarado.

Primeiro a chegar, primeiro a ser servido é difícil de aplicar ou até 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. Por fim, impostos de MEV podem ser capazes de eliminar certos tipos de MEV que a ordem de primeiro a chegar, primeiro a ser servido não pode, como lucros de arbitragem de saltos descontínuos nos preços dos ativos. As vantagens potenciais da ordem de prioridade sobre a ordem de primeiro a chegar, primeiro a ser servido estão relacionadas de alguma forma às vantagens das trocas de tempo discreto em relação às trocas de tempo contínuo discutidas em Budish, Cramton, Shim (2015).

Enquanto isso, embora a ordenação por prioridade pareça vazar valor para o MEV por padrão, este post mostra como as aplicações podem ser projetadas para recapturá-lo.

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

Impostos MEV permitem algo semelhante (pelo menos para taxas prioritárias), mas podem ser implementados na camada de aplicativo em qualquer cadeia que use ordenação de prioridade competitiva, sem suporte especial para compartilhamento de taxas. Eles também permitem que aplicativos definam seus próprios impostos como funções personalizadas da taxa prioritária, oferecendo mais flexibilidade e potencialmente resultando em uma maior composição de aplicativos conscientes de MEV.

Soluções sem confiança. Esta postagem enfoca a motivação para as plataformas utilizarem a ordem de prioridade competitiva - e maneiras de aproveitar as plataformas que o fazem - em vez de discutir como aplicá-la sem confiança.

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

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

Conclusão

Esperamos que este post encoraje os L2s a considerar a utilização de ordenação prioritária (como é suportado por padrão na Pilha OP) e inspire aplicações a experimentar impostos MEV onde suportado.

Também esperamos que isso motive mais pesquisas em protocolos para ordenação de prioridade competitiva minimizada de confiança tanto no L1 quanto no L2. Se você estiver interessado em colaborar nesse problema e estiver lendo isso antes de quinta-feira, 6 de junho, ainda pode se candidatar a uma Bolsa TLDR para trabalhar em Sequenciadores L2 resistentes a MEVcom Dan. Ou sinta-se à vontade para entrar em contato comdan@paradigm.xyzedave@paradigm.xyzcom ideias!

Notas de rodapé

1. Nesta postagem, usamos o termo “proponente” para nos referirmos ao ator ou processo que determina quais transações são incluídas em um bloco específico. Nas soluções de escalonamento de camada 2 da Ethereum, esse papel é tipicamente desempenhado por um “sequenciador”. Na Ethereum L1, é desempenhado por um validador específico da Ethereum 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 desta postagem.↩
2. A taxa de prioridade por gás não é especificada explicitamente na transação, mas pode ser calculada nela. A transação especifica um preço de gás, mas o Ethereum também cobra uma taxa base, que é deduzida do preço do gás e queimada. A taxa base deve ser ignorada para fins de impostos de MEV, 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 referir-se ao valor que iria para o validador.↩
4. Observe que proposerPriorityFee — igual a priorityFeePerGas vezes o total de gás utilizado na transação — não pode ser realmente calculado durante o contrato, já que não há maneira de saber quanto gás a transação acabará utilizando. No entanto, isso geralmente não importará, já que tudo o que precisamos é de um limite superior para ele. Para garantir, você poderia multiplicar priorityFeePerGas por 30 milhões — o máximo atual de gás em um bloco Ethereum. Superestimar esse valor simplesmente significará que o imposto MEV captura uma porcentagem ainda maior de MEV.↩
5. Supondo que uma transação não possa ter mais do que 30 milhões de gas, 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 para que o lucro do arbitrador seja zero, o comércio de arbitragem que maximiza o lucro deve corresponder ao mesmo comércio no AMM de maximização de função. Provar isso é deixado como um exercício para o leitor. ↩
7. Arbitrum has discutidosubstituindo isso por uma forma de ordenação de prioridade chamada Timeboost, mas isso ainda não foi colocado em produção até a data desta escrita.

Disclaimer：

1. Este artigo é reproduzido a partir de [paradigma], Todos os direitos autorais pertencem ao autor original [Dan Robinson, Dave White]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles lidarão com isso prontamente.
2. Aviso de Responsabilidade: As visões e opiniões expressas neste artigo são exclusivamente do autor e não constituem nenhum conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.