Este artigo é de "Prioridade é tudo que você precisa"
Autor original: Dan Robinson, Dave White
Compilado por: Odaily Planet Daily Como está seu marido?
A Paradigm publicou o artigo “Priority Is All You Need” no dia 4 de junho, que apresentou detalhadamente o novo mecanismo do imposto MEV.
O imposto MEV é um novo mecanismo que permite que os aplicativos capturem o MEV que geram, em vez de vazá-lo para os proponentes do bloco (veja a nota de rodapé no final do artigo para obter mais informações sobre os proponentes do bloco). Este mecanismo aproveita a priorização competitiva no processo de construção de blocos. Nesse método de classificação, as transações são organizadas em ordem decrescente de custo de prioridade e as transações com maior prioridade são empacotadas primeiro em blocos. O imposto MEV é implementado adicionando uma taxa adicional à taxa de prioridade da transação. Os aplicativos podem capturar a maior parte ou até mesmo todo o MEV definindo suas próprias taxas com base nas taxas de prioridade da transação. Isso significa que os aplicativos podem realizar seus próprios leilões personalizados de MEV sem a necessidade de qualquer infraestrutura fora da cadeia, participando de um único leilão compartilhado executado pelo proponente do bloco.
O nascimento do mecanismo fiscal MEV pode ter um impacto no ecossistema DeFi existente:
Mudando a forma como o MEV tradicional é distribuído: Tradicionalmente, o MEV flui principalmente para bloquear proponentes, e o imposto MEV permite que os aplicativos capturem esse valor e o redistribuam aos seus usuários ou o utilizem para outros fins.
Melhor receita de aplicativos e experiência do usuário: Os aplicativos podem aumentar suas receitas implementando o imposto MEV e, ao mesmo tempo, fornecer uma melhor experiência ao usuário, pois os usuários podem obter maior eficiência na execução de transações e melhores preços de transação.
Resolveu alguns problemas no DeFi: M, como otimizar o roteamento DEX, reduzir as perdas de AMM na arbitragem, reduzir o vazamento de MEV para usuários de carteira, etc. Ao introduzir impostos MEV, as aplicações podem melhorar os seus produtos e serviços, aumentando assim a eficiência e a sustentabilidade do ecossistema DeFi.
citação
Neste artigo apresentamos a taxa MEV, mecanismo que permite a qualquer aplicação capturar seu próprio MEV (Valor Máximo Extraível).
Este mecanismo está imediatamente disponível em cadeias OP Stack L2, como OP Mainnet, Base e Blast, uma vez que os proponentes de blocos nessas cadeias seguem um conjunto de regras que chamamos de priorização competitiva.
Para implementar o imposto MEV nessas cadeias, um contrato inteligente cobra uma taxa com base na taxa de prioridade da transação. Mostramos que se um aplicativo impor uma taxa de MEV de US$ 99 sobre cada US$ 1 de prioridade pago por um pesquisador, ele poderá capturar 99% do MEV competitivo dessa transação.
O imposto MEV é uma tecnologia simples que abre um vasto espaço de design. Você pode pensar nisso como permitir que qualquer aplicativo na cadeia execute seu próprio leilão MEV personalizado sem qualquer infraestrutura própria fora da cadeia, simplesmente conectando-se a um leilão compartilhado executado pelo proponente do bloco.
Mostramos como um imposto MEV pode ser usado para abordar três questões principais na pesquisa MEV:
Um roteador de exchange descentralizada (DEX) que otimiza os preços recebidos pelos exchanges
Formador de mercado automatizado (AMM) que minimiza as perdas incorridas pelos provedores de liquidez devido ao reequilíbrio (LVR)
Uma carteira que permite aos usuários capturar qualquer MEV de “reversão” gerado por suas transações
Mas há um problema. O imposto MEV só é eficaz se os proponentes do bloco aderirem estritamente às regras competitivas de priorização, incluindo ordenar as transações por taxa de prioridade, sem censura, olhares indiscretos ou atrasos. Se os proponentes do bloco se desviarem destas regras, poderão contornar o imposto MEV para capturar valor. Portanto, o imposto MEV atual depende da confiança nos sequenciadores L2 e pode não funcionar no Ethereum L1, porque na rede principal Ethereum, a construção de blocos é dominada principalmente por leilões competitivos de construtores para maximizar a renda das pessoas propostas.
No entanto, as capacidades e a flexibilidade do imposto MEV sugerem que a priorização pode ser a escolha certa para plataformas atualmente capazes de oferecer ordenação de prioridade. E a relativa simplicidade da priorização competitiva sugere que pode haver uma maneira viável de aplicá-la de maneira descentralizada, sem confiar em um único sequenciador. Esperamos que este artigo estimule novas pesquisas sobre esse assunto.
Pedido prioritário
Quando alguém envia uma transação na rede principal Ethereum ou L2, especifica uma taxa de prioridade que é paga ao proponente do bloco. Você pode imaginar isso sendo especificado por meio depriorityFeePerGas , um número multiplicado pelo gás usado na transação para obter builderPriorityFee, o valor total pago em ETH.
Não há nenhuma exigência no protocolo Ethereum de que as transações em um bloco sejam classificadas avidamente em ordem decrescente de prioridade FeePerGas. No entanto, esta é uma forma popular de construir blocos. Por exemplo, este é o algoritmo padrão usado pelo sequenciador da cadeia OP Stack e geth e reth . A priorização não apenas permite que os comerciantes expressem efetivamente a urgência de suas transações, mas também direciona naturalmente certos tipos de MEV para bloquear os proponentes.
Isto acontece porque a priorização transforma a competição por MEVs em leilões de gás priorizados. Quando há uma oportunidade de lucrar com a interação com a cadeia, como por meio de arbitragem entre um AMM e uma bolsa centralizada, os pesquisadores competem para serem os primeiros a aproveitar a oportunidade. Se a cadeia utilizar a priorização para determinar o empacotamento e a ordem das transações, os pesquisadores competirão estabelecendo taxas de alta prioridade em suas transações.
Num cenário competitivo em que os lucros sem risco são reduzidos a zero pela concorrência, o pesquisador vencedor deverá, em última instância, pagar o MEV integral como taxa prioritária. Portanto, se for possível obter um lucro de 100 ETH ao interagir com o contrato, a primeira transação que aproveitar a oportunidade definirá uma taxa de prioridade de 100 ETH. (Discutiremos algumas considerações sobre isso na seção Limitações).
Imposto MEV
Suponha que um contrato inteligente queira capturar o MEV em qualquer transação com a qual interaja. Há uma extensa literatura de pesquisa sobre várias maneiras específicas de aplicações pelas quais os contratos inteligentes tentam capturar seu próprio MEV.
Mas, na realidade, não precisamos necessariamente saber nada específico sobre a aplicação. Se soubermos que os blocos são construídos através de priorização competitiva, então temos um sinal unificado para a quantidade de MEV numa transação: a taxa de prioridade.
Propomos que os contratos inteligentes possam analisar a taxa de prioridade de uma transação e cobrar a sua própria taxa com base nela, o que é uma função crescente da taxa de prioridade. Por exemplo, o contrato pode exigir que a pessoa que o chama transfira applicationPriorityFee = 99 * proporPriorityFee ETH para o contrato.
Essa nova taxa é paga pelo pesquisador que enviou a transação, portanto afeta o comportamento desse pesquisador. Se uma oportunidade tiver um MEV de 100 ETH, a transação vencedora definirá agora apenas uma taxa de prioridade de 1 ETH, pois isso resultará em um pagamento total de 100 ETH (1 ETH para o proponente do bloco, 99 ETH para o contrato inteligente) . Qualquer taxa de prioridade mais alta tornará a transação não lucrativa; qualquer taxa de prioridade mais baixa resultará na perda da oportunidade por um concorrente que estabeleça uma taxa mais alta. Isso significa que o contrato inteligente captura 99% do MEV da transação.
Chamamos essa taxa adicional imposta pelo contrato inteligente de imposto MEV. O imposto MEV permite que os aplicativos sequestrem a priorização para seu próprio benefício, permitindo-lhes recapturar o MEV para os usuários, em vez de vazá-lo para bloquear os proponentes.
Se a taxa crescer rápido o suficiente em função de priorityFeePerGas , apenas um MEV insignificante será acumulado para o proponente. Como o preço do prioridadeFeePerGas é em wei (um bilionésimo de ETH), temos muita precisão para aproveitar. Por exemplo, desde que a sensibilidade fiscal do MEV seja alta o suficiente para que uma PrioridadeFeePerGas de 50.000 resulte em um imposto proibitivamente alto, então o valor total pago ao proponente será inferior a US$ 0,01.
No entanto, há uma advertência importante. Conforme discutido na secção Limitações, os impostos MEV só funcionam se os proponentes do bloco seguirem certas regras (que chamamos de “priorização competitiva”) e não se desviarem destas regras a fim de maximizar as suas próprias receitas. Aplicar essas regras sem confiança é uma questão em aberto.
Captura MEV para um único aplicativo
Em uma cadeia onde é garantido que os blocos serão construídos usando priorização competitiva, o imposto MEV pode ser usado para aliviar três problemas importantes com MEV: permitir que interfaces DEX melhorem a execução de negociações para exchanges, permitindo que AMMs reduzam perdas de arbitragem em seus LPs; carteiras para passar Venda os direitos aos usuários runback para reduzir o vazamento de MEV dos usuários.
Pesquisador de roteador DEX
Em protocolos de roteamento DEX baseados em intenção, como UniswapX e 1inch Fusion, um usuário (Alice) assina uma intenção de troca e os pesquisadores competem para rotear ou preencher essa intenção com o melhor preço.
A versão atual do UniswapX usa dois mecanismos para realizar esta competição: um leilão holandês, onde o preço limite de Alice muda ao longo do tempo até ser preenchido por um pesquisador, e um leilão inicial de solicitação de cotação (RFQ) fora da rede para definir o preço inicial para esse Leilão holandês .
Numa plataforma que garante priorização competitiva, o UniswapX pode substituí-las por um mecanismo: o imposto MEV. Funciona permitindo que os usuários assinem um pedido que pode ser atendido instantaneamente por qualquer pessoa, mas o preço de execução depende da taxa de prioridade da transação.
Por exemplo, se Alice tiver uma ordem UniswapX para vender 1 ETH, ela poderá definir o preço de execução da ordem como mínimoPreço + ($ 0,01 *priorityFeePerGas pode ser um valor fixo que ela espera ser significativamente menor que o preço atual). .
Os pesquisadores competirão para atender ao pedido de Alice enviando transações. Qualquer negociação com a taxa de prioridade mais alta e sem fallback preencherá a ordem, o que deve garantir que o trader obtenha o melhor preço que o pesquisador puder encontrar. (Algumas exceções a isso são discutidas na seção Limitações.)
Se o preço mais baixo de Alice for US$ 3.000 e o preço atual da ETH for US$ 3.500, a prioridade FeePerGas na transação vencedora será de aproximadamente 50.000. (Observe que em uma transação que custa 200.000 gás, isso resultaria no pagamento de apenas ~10 bilhões de wei (~$0,000035) ao proponente do bloco.
Isto tem algumas vantagens potenciais sobre os mecanismos existentes usados no UniswapX.
Os pedidos que utilizam o imposto MEV podem ser atendidos mais rapidamente e a preços melhores do que os pedidos em leilões holandeses. Conforme descrito neste artigo, os leilões holandeses em rede vazam algum valor para o MEV devido a mudanças de preço entre os blocos e podem exigir a conclusão de vários blocos. Por outro lado, os pedidos que utilizam um imposto MEV geralmente podem ser atendidos no próximo bloco enquanto capturam a grande maioria de seu MEV.
Ao contrário dos RFQs fora da rede, os leilões que usam impostos MEV para atender aos pedidos ocorrerão de forma atomizada quando as transações na rede forem executadas. Isso significa que o licitante vencedor tem a garantia de que o pedido só será atendido se a transação na rede for bem-sucedida. Isso pode tornar mais fácil para a liquidez on-chain (como AMM) competir com a liquidez off-chain, o que significa que o UniswapX pode servir como um roteador mais eficiente para subsistemas multi-pool (como Uniswap v4).
Formador de mercado automatizado (AMM)
Freqüentemente, os AMMs vazam valor devido aos arbitradores negociando a preços obsoletos no topo dos blocos, conforme discutido no artigo perda versus reequilíbrio. Podemos usar o imposto MEV para permitir que a AMM capture esses MEVs. Para simplificar, discutiremos como implementar isso em um AMM sem liquidez centralizada. (Se você estiver interessado em como resolver esse tipo de problema com liquidez centralizada, Sorella lançará uma solução em breve.)
Os AMMs podem capturar MEV cobrando uma taxa adicional com base na prioridade da transação, permitindo leiloar os direitos de priorizar transações em um bloco. Existem muitas maneiras de calcular e avaliar essa taxa. Discutiremos uma abordagem que é indiscutivelmente neutra - expressa em unidades de liquidez do pool sqrt(xy). As negociações vencedoras serão aquelas que mais aumentarem a liquidez do pool.
Ao executar a primeira transação no pool em um bloco, x_end * y_end > x_start * y_start o pool pode impor uma condição (como alguma constante):
x_end * y_end > (sqrt(x_start * y_start) + a*priorityFeePerGas)^ 2 Esta fórmula incentivará os traders de arbitragem a negociar com o preço real, após o qual o preço médio do pool deverá ser o preço real.
Após essa primeira transação, as transações podem funcionar como no Uniswap v2, utilizando taxas de câmbio fixas. Os comerciantes desinformados que desejam negociar sem pagar impostos adicionais sobre MEV definirão taxas de prioridade mais baixas.
Existem muitas outras maneiras de implementar o imposto MEV no AMM, que terão efeitos diferentes. Por exemplo, os impostos MEV podem ser expressos em tokens de entrada ou saída de uma exchange, podem afetar a porcentagem da taxa de exchange aplicada pelo pool ou podem determinar o preço mínimo para transações do usuário. Achamos que este é um espaço de design interessante que vale a pena explorar.
Leilões atrasados
A descrição acima mostra como certas aplicações podem ser projetadas para evitar vazamento de MEV. Mas e se uma carteira quiser ajudar seus usuários a capturar o MEV gerado em qualquer transação que interaja com qualquer aplicativo, mesmo que esses aplicativos não incluam impostos MEV?
Por exemplo, quando Alice faz uma grande negociação na AMM, ela às vezes cria uma oportunidade de arbitragem para que os "atrasados" tragam o preço de volta ao normal. Normalmente, essas oportunidades são vazadas para o MEV, em vez de serem propriedade de Alice.
MEV-Share e MEVBlocker são dois protocolos que permitem aos usuários capturar MEV de suas transações, mas dependem de sistemas complexos de leilão fora da cadeia. "The Orderflow Auction Design Space" descreve algumas outras soluções.
Quando o imposto MEV é combinado com uma carteira de contrato inteligente baseada em intenção, podemos construir um sistema alternativo para capturar o MEV de Alice. Suponha que Alice não crie uma transação para ser negociada no AMM, mas em vez disso assine uma intenção que qualquer pessoa possa enviar à carteira de contrato inteligente de Alice para que ela execute essa ação. A carteira de contrato inteligente de Alice cobra da pessoa que enviou a transação um imposto MEV, que é pago a Alice.
O pesquisador que enviou a intenção de Alice tem o direito exclusivo de segui-la porque pode fazê-lo atomicamente na mesma transação. Portanto, se a busca for altamente competitiva, todos os lucros obtidos com o rastreamento de Alice deverão ir para Alice por meio de seu imposto MEV.
É importante observar que este sistema pode não proteger totalmente os usuários contra ataques front-running, uma vez que o front-running pode evitar o pagamento de impostos MEV aos usuários. Esta questão (e algumas das suas possíveis mitigações) é discutida em detalhe na secção Limitações abaixo. Ainda assim, isto é pelo menos uma melhoria em relação a um sistema de pool de memória pública sem quaisquer mitigações.
Outros casos de uso
Além destes exemplos, outros usos potenciais para os impostos MEV incluem quase todos os cenários onde os leilões off-chain ou holandeses são atualmente usados, tais como:
Protocolos como o Oval funcionam capturando o valor extraível do oráculo (OEV) que eles criam.
Leilões de refinanciamento em protocolos de empréstimos hipotecários NFT como o Blend.
A liquidação do contrato de empréstimo perde menos valor do que um leilão holandês.
Captura MEV entre aplicativos
A solução acima foi projetada para capturar o MEV gerado ao interagir com um único aplicativo. No entanto, às vezes um pesquisador pode capturar mais valor interagindo com vários aplicativos na mesma transação.
Se apenas um desses aplicativos usar o imposto MEV, todos os MEV da transação deverão ser atribuídos ao aplicativo que usa o imposto MEV, independentemente do imposto MEV.
Mas e se a transação do pesquisador interagir com dois aplicativos que usam o imposto MEV? Por exemplo, se determinado MEV só puder ser capturado preenchendo uma ordem UniswapX tributada por MEV contra um AMM tributado por MEV.
Nesse caso, o valor relativo do excesso de MEV capturado por cada aplicação é determinado pelo imposto MEV definido por essas aplicações. Se o valor do imposto app_i como MEV for dado pela função tax_i(priority) , então a prioridade da transação vencedora pode ser determinada resolvendo a seguinte equação para prioridade: tax_ 1(priorityPerGas) + tax_ 2(priorityPerGas) = MEV total
(Tecnicamente, poderíamos adicionar um terceiro termo prioridadePerGas * gásUsado para contabilizar a taxa de prioridade paga ao proponente do bloco, mas iremos ignorar isso porque, conforme discutido no Apêndice A, em circunstâncias normais, prioridade O custo é provavelmente insignificante).
No caso simples de um imposto MEV linear em prioridadePerGas (então tax_ 1(priorityPerGas) = a_ 1 * prioridadePerGas ), você pode resolver para a parcela de MEV recebida por cada aplicação:
a_ 1 * prioridadePorGás + a_ 2 * prioridadePorGás = MEV
prioridadePorGás = MEV/(a_ 1 + a_ 2)
imposto_ 1(prioridadePorGás) =(a_ 1/(a_ 1+a_ 2))*MEV
imposto_ 2(prioridadePorGás) = (a_ 2/(a_ 1+a_ 2))*MEV
Uma aplicação enfrenta uma compensação ao definir seu próprio imposto MEV - uma taxa de imposto mais alta permite capturar uma parcela maior do MEV de aplicação cruzada à medida que ocorre, mas significa que pode perder algum MEV de aplicação cruzada se houver concorrentes. métodos de extração. Por exemplo, se houver um AMM que cobra imposto MEV em cada transação, então o pedido UniswapX de imposto MEV pode ser preenchido por um AMM diferente ou preenchedor fora da cadeia.
Em muitos casos, pode haver um equilíbrio em que duas aplicações concebem os seus impostos MEV para partilhar o MEV de uma forma que maximize o seu respetivo bem-estar. Por exemplo, um AMM fiscal MEV pode querer capturar valor de um único trader informado próximo ao topo do bloco, mas depois querer disponibilizá-lo para outros traders e aplicações (incluindo aqueles que usam o imposto MEV) com uma fluidez de taxa fixa mais baixa. Nesse caso, o AMM pode definir um imposto MEV relativamente baixo (por exemplo, US$ 0,00001 * prioridadeFeePerGas ) para que as transações de arbitragem (se houver) ocorram no início do bloco e, em seguida, nas transações subsequentes no bloco, nenhum imposto MEV será cobrado. Aplicativos como o UniswapX que desejam interagir com AMMs podem definir um imposto MEV mais alto (como $ 0,01 * prioridadeFeePerGas ) para garantir que suas transações sejam incluídas após o pool já ter arbitrado. Com esses impostos relativos, mesmo que haja apenas US$ 1 MEV e US$ 50.000 MEV na ordem UniswapX, o AMM acabará sendo arbitrado em primeiro lugar.
Acreditamos que este é um amplo espaço de design digno de pesquisas futuras.
limitação
O imposto MEV tem algumas complexidades e armadilhas. Acreditamos que estas são áreas interessantes para pesquisas futuras.
Incompatibilidade de incentivos
Os impostos MEV são incompatíveis com incentivos para proponentes de blocos monopolistas. Só funcionam se houver uma concorrência leal para a inclusão de transações, o que só acontece se os proponentes do bloco seguirem regras que chamamos de “priorização competitiva” em vez de maximizarem as suas próprias receitas. Recomendamos que essas regras incluam:
Priorização: As transações em um bloco devem ser classificadas em ordem decrescente de prioridadeFeePerGas.
Resistência à censura: Se o proponente do bloco receber a transação t 1 ao construir o bloco, e o bloco não estiver cheio ou contiver a transação t 2 e t 2.priorityFeePerGas < t 1.priorityFeePerGas, então o bloco deverá conter a transação t 1 .
Privacidade pré-transação: Os proponentes do bloco devem aceitar transações através de um endpoint privado e não podem compartilhar essas transações com ninguém antes de enviar o bloco, nem podem usar o conteúdo dessas transações para construir suas próprias transações.
Nenhum momento foi finalizado. Os proponentes do bloco devem definir um horário claro (blockTime) antes do qual aceitarão transações de qualquer pessoa, após o qual não aceitarão transações de ninguém.
Se um ou mais destes atributos forem violados, a eficácia do imposto MEV pode ser diminuída. Os proponentes do bloco que violam a resistência à censura podem aproveitar a oportunidade, excluindo transações concorrentes e submetendo uma transação de prioridade zero para evitar a maioria dos impostos MEV. Um proponente de bloco que viola a privacidade pré-transação pode roubar MEV de outras transações ou espiar suas taxas de prioridade para saber quão alta uma taxa de prioridade precisa ser definida para superar outras, enquanto um proponente que é capaz de enviar transações depois dos outros está tendo a liberdade de “finalmente decidir” se deve superar os outros cria um problema de seleção adversa que, em última análise, sufoca a concorrência.
Infelizmente, embora a primeira propriedade seja facilmente aplicada na camada de protocolo, impor as outras propriedades de maneira não confiável é um problema em aberto.
Na ausência de aplicação no nível do protocolo, um sequenciador comprometido com essas regras precisa ser confiável para não se desviar dessas regras se o proponente terceirizar a construção do bloco para um leilão competitivo de maximização de receita (como o MEV-Boost da rede principal Ethereum), bloquear pode não segui-los.
Esses problemas podem ser “resolvidos” por um único solicitante confiável que se comprometa a construir blocos usando priorização competitiva. Também pode ser resolvido com um mecanismo descentralizado usando alguma combinação de consenso, criptografia e/ou um ambiente de execução confiável, como Angstrom de Sorella, SUAVE de Flashbots, Leilões sem Líderes ou Multiplicidade.
bloco completo
Existem exceções ao funcionamento normal da taxa MEV quando um bloco está completamente cheio. Neste caso, o proponente do bloco poderá ter de excluir as transações de baixa prioridade, em vez de apenas incluí-las posteriormente no bloco. Como as transações que interagem com aplicativos que usam impostos MEV provavelmente terão taxas de prioridade muito baixas, esses aplicativos podem ser excluídos por aplicativos que não usam impostos MEV ou aplicativos que usam impostos MEV muito baixos. No entanto, em uma rede que usa um mecanismo como o EIP-1559 para definir uma taxa básica separada, deve ser raro que um bloco esteja completamente cheio. Além disso, dada a necessidade de atrasar algumas transações quando um bloco está cheio, atrasar transações que expressam menor urgência através da definição de um imposto MEV mais elevado pode ser um resultado razoável.
Transação de reversão
O imposto MEV depende essencialmente de leilões de bloco único, onde cada “licitação” é uma transação. Uma desvantagem desse tipo de leilão é que lances malsucedidos geralmente resultam na inclusão de transações de reversão na rede, pagando algumas taxas básicas e congestionando a cadeia.
Isto aliviaria este problema se o sequenciador pudesse excluir completamente as transações falhadas, embora isto fosse difícil de conseguir mesmo com um sequenciador centralizado. (Isso também não adere totalmente às propriedades de resistência à censura descritas 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 de disputa participam, permitindo assim que o sequenciador para pular o que sabe As transações subsequentes falharão.
Revelar a intenção do usuário
O imposto MEV só funciona se houver concorrência entre os pesquisadores, o que significa que a oportunidade precisa ser bem conhecida até certo ponto. Para aplicações como AMM, onde as oportunidades são visíveis na cadeia, isso deve acontecer naturalmente. Mas para aplicativos como roteamento baseado em intenção ou lances finais, isso significa que o aplicativo pode precisar compartilhar a intenção do usuário com o pesquisador.
Em alguns casos, a privacidade temporária perdida pela transmissão da intenção do utilizador antes de esta ser implementada pode vazar valor de uma forma que o imposto MEV não consegue recuperar.
Por exemplo, suponha que Alice queira comprar um token de baixa liquidez usando o protocolo de leilão descrito acima. Ela publica uma intenção assinada em sua carteira de contrato inteligente para comprar o token no AMM e define alguma tolerância a derrapagens. O pesquisador pode competir em negociações de alta prioridade para aumentar o preço desse token até sua tolerância à derrapagem, sem atender ao pedido do usuário. O vencedor Bob pode então satisfazer a intenção de Alice de forma não competitiva, incluindo e revertendo a intenção de Alice em uma transação de baixa prioridade, imprensando assim a transação de Alice e dando-lhe um preço pior enquanto escapa do imposto MEV. Problemas semelhantes podem surgir na compra de NFTs.
Observe que tal ataque é arriscado para Bob porque ele não pode garantir a atomicidade entre comprar o token e vendê-lo para Alice. O ingênuo Bob pode ser vítima da armadilha do "rasgo de sanduíche", na qual Alice publica a intenção de comprar um token sem valor de si mesma, fazendo com que Bob o compre na esperança de intercalar sua transação, mas Alice rescinde sua intenção antes que Bob possa terminar o sanduíche.
Os aplicativos também podem mitigar isso limitando o conjunto de pesquisadores com os quais compartilham intenções e monitorando seu comportamento, como é o caso de muitos leilões de fluxo de pedidos existentes.
Também é possível combinar impostos MEV com recursos de construção conscientes da privacidade, como aqueles previstos no design SUAVE dos Flashbots.
Finalmente, se Alice decidir que o custo de compartilhar suas intenções supera os benefícios da busca competitiva, ela mesma poderá construir uma transação e submetê-la diretamente ao bloco. Conforme mencionado acima, uma implementação ideal de priorização competitiva proporcionaria privacidade pré-transação aos proponentes de blocos.
Discussões e trabalhos preliminares
Leilão prioritário de gás. O artigo Flash Boys 2.0 examina algumas das dinâmicas de priorização em blockchains descentralizadas, cunhando o termo “valor extraível do minerador”. O artigo observa que os mineradores de Ethereum (quando a rede usava prova de trabalho) priorizaram as transações e que os arbitradores confiaram nesse comportamento para participar de um “leilão de gás prioritário”, onde licitaram primeiro pelo direito de serem incluídos em um bloco. ., o que resulta na acumulação da maior parte do MEV da arbitragem cambial descentralizada para os mineradores.
Primeiro a chegar, primeiro a ser servido. Algumas tentativas de mitigar o MEV por meio da ordenação de transações (como o sequenciador atual do Themis ou do Arbitrum One) concentram-se na aplicação de uma regra de ordenação diferente, primeiro a chegar, primeiro a ser servido (às vezes chamada de "ordenação justa"), onde os proponentes do bloco devem ordenar como vêem. transações por ordem de chegada.
A priorização adota uma abordagem diferente – as transações que chegam dentro de um determinado período de tempo são tratadas igualmente e classificadas pela prioridade declarada.
A “ordenação justa” é difícil de impor ou mesmo definir em um ambiente de rede real com vários validadores. Também pode levar a corridas de latência desnecessárias e spam, mesmo com um único sequenciador confiável. Finalmente, um imposto MEV poderá ser capaz de eliminar certos MEV do tipo “primeiro a chegar, primeiro a ser servido”, como a arbitragem de lucros resultantes de “saltos” discretos nos preços dos activos. As vantagens potenciais da priorização em relação à classificação por ordem de chegada estão relacionadas, em parte, às vantagens da troca em tempo discreto em relação à troca em tempo contínuo discutidas em Budish, Cramton, Shim (2015).
Além disso, embora a priorização pareça vazar valor para o MEV por padrão, esta postagem mostra como projetar aplicativos para recapturá-lo.
Compartilhamento de custos. Blast é Ethereum L2 e compartilha algumas taxas prioritárias e básicas com os contratos inteligentes acessados nas transações.
O imposto MEV permite algo semelhante (pelo menos para taxas prioritárias), mas pode ser implementado na camada de aplicação em qualquer cadeia utilizando priorização competitiva sem exigir apoio especial para partilha de taxas. Eles também permitem que os aplicativos definam seus próprios impostos como funções personalizadas de taxas prioritárias, proporcionando maior flexibilidade e melhorando potencialmente a composição de aplicativos compatíveis com MEV.
Soluções sem confiança. Este artigo concentra-se nas motivações para as plataformas usarem a priorização competitiva e nos métodos para aproveitar as plataformas de priorização competitiva, em vez de discutir como aplicá-la sem confiança.
Cada um dos outros atributos necessários para a priorização competitiva foi discutido extensivamente anteriormente. Por exemplo, em Fox, Pai, Resnick (2023), os autores discutem vulnerabilidades em leilões on-chain sem resistência à censura e descrevem o desenho de leilões resistentes à censura usando múltiplos proponentes simultâneos. No entanto, eles não recomendam uma sequência específica de transações.
Há outras pesquisas sobre a construção de mecanismos de construção de blocos minimizados pela confiança, incluindo SUAVE da Flashbots, Angstrom da Sorella, Leilões Leaderless, Timeboost descentralizado da Espresso e Offchain Labs e empacotamento de transações públicas forçadas de Péter Szilági.
para concluir
Esperamos que este artigo incentive L2 a considerar o uso de priorização (suportada por padrão na pilha OP) e motive os aplicativos a tentar impostos MEV, se houver suporte.
Esperamos também que inspire mais pesquisas sobre protocolos de priorização competitiva que minimizam a confiança em L1 e L2.
nota de rodapé
Neste artigo, usamos “proponente” para nos referirmos ao ator ou processo que determina quais transações estão incluídas em um bloco específico. No Ethereum L2, essa função geralmente é preenchida pelo “sequenciador”. No Ethereum L1, ele é preenchido por um validador Ethereum específico, chamado de proponente, embora os proponentes normalmente terceirizem a tarefa de construir blocos para leilões competitivos nos quais "retransmissores" e "construtores" participam. Os detalhes de como essas responsabilidades são divididas estão além do escopo deste artigo.
A taxa de prioridade por Gás não é especificada explicitamente na transação, mas pode ser calculada na transação. A transação especifica um preço do gás, mas o Ethereum também cobra uma taxa básica, que é retirada do preço do gás e destruída. No que diz respeito ao imposto MEV, o encargo base deve ser ignorado, pois está fora do controlo do concessionário. A taxa de prioridade por Gás (ou seja, o preço da parcela das taxas de transação que vai para o proponente do bloco) pode ser calculada no Solidity como prioridadeGasPrice = tx.gasprice - block.basefee .
Podemos simplesmente definir “MEV” para excluir quaisquer lucros do pesquisador e nos referir apenas ao valor que fluirá para o validador.
Observe que o proporPriorityFee não pode, na verdade, ser calculado como um múltiplo do valor total do gás prioritárioFeePerGas usado na transação (igual ao gás total usado na transação) durante o contrato, porque não há como saber quanto gás a transação acabará por usar . No entanto, isso geralmente não importa, pois tudo o que precisamos é de um limite superior. Para garantir a segurança, você pode multiplicar prioridadeFeePerGas por 30 milhões - este é o gás máximo atual em um bloco Ethereum. Superestimar este valor significará apenas que os impostos do MEV representam uma proporção maior do MEV.
Supondo que uma transação não possa exceder 30 milhões de Gas, uma prioridadeFeePerGas de 50.000 resultaria em um pagamento de gás de 1.500 gwei – aproximadamente US$ 0,006 a um preço de ETH de US$ 4.000.
Se PriorityFeePerGas for definido de forma que o lucro do arbitrador seja zero, então a negociação de arbitragem que maximiza o lucro deve corresponder à mesma negociação no AMM que maximiza a função.
A Arbitrum discutiu substituí-lo por uma forma de priorização chamada Timeboost, mas no momento em que este livro foi escrito, ela ainda não estava em produção.