Como conseguir um sequenciamento de transações justo com MEV modular?

Autor: Maven11

Compilador: Luffy, Foresight News

Nas duas primeiras partes desta série, nos concentramos nos problemas técnicos que surgem ao dividir a pilha e nas melhorias que precisam ser feitas no mundo modular. Cobrimos uma série de avanços de trabalho para resolver problemas que surgem naturalmente em configurações entre domínios. No entanto, na parte final da série, queremos nos concentrar mais na experiência do usuário. Queríamos ver como a modularização, a personalização e a especialização podem ajudar a criar aplicativos melhores. O capítulo final desta série analisará a criatividade e as possibilidades empolgantes e únicas na modularidade para os desenvolvedores criarem experiências de usuário Web2 com verificabilidade Web3.

A razão por trás da construção da modularidade não deve ser apenas para atender à narrativa ou apenas para ser modular, mas porque nos permite construir aplicativos melhores, mais eficientes e mais personalizáveis. Ao construir sistemas modulares e especializados, surgem várias características únicas. Algumas delas são óbvias, enquanto outras são menos óbvias. Portanto, nosso objetivo é fornecer uma visão geral dos recursos do sistema modular que você não conhecia, como escalabilidade.

Acreditamos que um dos recursos que a modularidade fornece aos desenvolvedores é a capacidade de criar aplicativos profissionais altamente personalizáveis que levam a uma melhor experiência para os usuários finais. Já discutimos anteriormente a capacidade de definir regras ou reordenar a ordem na qual as negociações são executadas.

Agrupamentos verificáveis (doravante referidos como VSRs) são uma das oportunidades interessantes oferecidas pela classificação controlada, especialmente para desenvolvedores interessados em construir sistemas de negociação "mais justos" em termos de execução. Obviamente, a relação entre perdas do Provedor de Liquidez e reequilíbrio (LVR) está além do escopo deste artigo, então evitaremos tocar muito nisso. Lembre-se de que as configurações que vamos explicar são principalmente para o AMM e não para o modelo de livro de pedidos. Além disso, o CLOB (e até mesmo o CEX) também se beneficiará muito ao aproveitar agrupamentos verificáveis que se ajustam às suas configurações específicas. Em uma configuração off-chain, há uma clara necessidade de algum conceito de conhecimento zero ou execução otimista apoiada pela segurança criptoeconômica.

O VSR é particularmente interessante quando consideramos o fato de que a maioria dos investidores de varejo ainda não adotou (ou é improvável) uma abordagem de conservação. A maioria das carteiras/DEXs também não implementa mempools privados, RPCs ou métodos semelhantes. A maioria das transações é enviada diretamente através do frontend (seja um agregador ou um frontend DEX). Como resultado, a menos que o aplicativo interfira diretamente com seus processos e a forma como os pedidos são processados, o usuário final pode experimentar uma execução menos do que satisfatória.

Quando pensamos em onde a cadeia de suprimentos de transação é encomendada, o papel do VSR torna-se óbvio. É onde os participantes profissionais classificam (ou incluem) transações, geralmente com base em algum leilão ou taxa base. Esse sequenciamento é muito importante porque determina quais negociações são executadas e quando. Essencialmente, a pessoa que tem a autoridade de triagem tem a capacidade de extrair o MEV, geralmente na forma de uma taxa de prioridade (ou gorjeta).

Como resultado, pode ser interessante escrever regras sobre como lidar com a classificação, a fim de fornecer uma execução de comércio mais justa (em uma configuração DEX) para o usuário final. No entanto, se você estiver construindo uma rede de uso geral, tente evitar seguir essas regras.

Além disso, existem alguns MEVs que são importantes, como arbitragem, liquidação, etc. Uma ideia é criar um canal "rodoviário" no topo do bloco, visando especificamente Arbitrageurs e liquidatários na Allowlist, que pagam taxas mais altas e compartilham uma parte da receita com o protocolo.

No artigo "Design of Trusted DEX Exchanges with Verifiable Collations", Matheus V., X. Ferreira e David C. Parkes propõem um modelo em que o sequenciador de um bloco está sujeito a uma série de restrições que executam agrupamentos (e essas restrições são verificáveis). Sem aderir às regras definidas, o observador pode gerar prova da falha (ou como as restrições são matematicamente verificáveis, você também pode imaginar um circuito ZK com essas restrições, que usa ZKP como prova de validade). A ideia principal é essencialmente fornecer uma garantia de preço de execução para o usuário final (trader). Esta garantia garante que a transação é executada tão bem quanto a única transação no bloco (obviamente, se assumirmos uma ordem de compra/venda/compra/venda com base no princípio de primeiro a chegar, primeiro a ser servido, há uma certa quantidade de atraso envolvida aqui). A ideia básica das propostas no artigo é que, se elas tiverem um desempenho a um preço melhor do que o preço disponível no topo do bloco, esses agrupamentos restringirão o construtor (em um cenário PBS) ou o sequenciador de incluir apenas transações na mesma direção (digamos vender/vender). Além disso, se houver uma situação em que você faz uma venda no final de uma série de compras, então a venda não será executada (por exemplo, comprar, comprar, comprar, vender), o que pode indicar que os pesquisadores (ou construtores/sequenciadores) estão usando essas compras para empurrar o preço a seu favor. Isso significa, essencialmente, que as regras do protocolo garantem que os usuários não serão usados para oferecer um preço melhor (ou seja, MEV) para outra pessoa, ou para fazer com que o preço caia devido a taxas prioritárias. Obviamente, a falha da regra aqui (no caso de vender mais do que comprar, e vice-versa) é que você pode obter um preço de cauda longa relativamente pobre.

Para uma plataforma geral de Smart Contract, é quase impossível construir essas regras como puramente on-chain, porque você não tem controle sobre a execução e ordenação. Ao mesmo tempo, você está competindo com muitos outros, então tentar forçar aqueles que estão no topo do bloco a pagar uma taxa de prioridade seria desnecessariamente caro. Uma das características da configuração modular é que ela permite que os desenvolvedores de aplicativos personalizem como seu ambiente de execução deve se comportar. Seja agrupamento, uso de uma máquina virtual diferente ou fazer alterações personalizadas em uma máquina virtual existente, como adicionar um novo Código de Operação ou alterar o limite de gás, isso realmente depende do desenvolvedor, dependendo do produto.

No caso de um rollup usando disponibilidade de dados, camadas de consenso e camadas de liquidação de liquidez, as configurações possíveis são as seguintes:

Outra ideia possível é o fracionamento de transações. Imagine um pool de transações, como executar transações de ordens grandes (que causam muita derrapagem) e se essa transação for executada em blocos consecutivos (ou no final do bloco se for compatível com VSR), isso é justo para o usuário final?

Se o usuário final estiver preocupado com a latência, esse usuário pode não querer que seu pedido seja dividido. No entanto, isso é menos comum, e a otimização para a divisão de negociação de ordens maiores pode resultar em uma execução mais eficiente para a grande maioria dos usuários. De qualquer forma, uma preocupação é que os pesquisadores MEV podem tomar conhecimento dessas negociações sequenciais e tentar posicionar suas negociações antes ou depois desses traders. No entanto, devido a transações fracionadas em pequena escala em uma série de blocos, o valor total do MEV extraído pode ser muito menor.

Outra ideia interessante que mencionamos anteriormente no post é usar leilões em massa frequentes (FBA), defendidos pelo lendário Eric Budish e seus colegas, para processar transações de forma a leilão em massa, em vez de uma forma serial. Isso é para ajudar a identificar a demanda sobreposta (CoW) e integrar oportunidades de arbitragem no design do mecanismo de mercado. Isso também ajuda a "combater" jogos adiados em compilações contínuas de Bloco (ou batalhas de custo prioritário em Bloco serial). Obrigado a Michael Jordan (DBA) por trazer este artigo à nossa atenção e por seu trabalho na mitigação da latência Roast. Implementá-lo como parte da seleção e agrupamento de forks do Rollup também é uma configuração interessante que os desenvolvedores podem usar, e vimos sua tração significativa no ano passado, especialmente para Penumbra e CoWSwap. Uma configuração possível ficaria assim:

Nesta configuração, não há uma guerra de taxas de gás por ordem de chegada, primeiro a ser servida ou prioritária, mas sim um Bloco para terminar o leilão em massa no tempo entre cada Bloco com base em pedidos cumulativos.

Em geral, onde a maioria das transações mudou para um mundo "on-chain" não custodial, o FBA pode ser uma das maneiras mais eficientes de descoberta de preços "reais", dependendo do tempo de bloqueio. Alavancar o FBA também significa que, uma vez que todos os pedidos em massa são em massa e não serão revelados até que o leilão termine (supondo que haja algumas configurações de criptografia), haverá uma redução significativa nas negociações front-running. Os preços de liquidação são a chave aqui, pois não há sentido em reordenar as transações.

Também é importante notar que, em 2018, designs como os que acabamos de abordar foram discutidos nos fóruns Ethresear.ch (veja aqui). No post, eles mencionam dois artigos que fornecem um mecanismo de leilão em massa no Plasma (um pouco como uma prequela dos Rollups modernos), onde cada lote aceita ordens para comprar tokens ERC20 adicionais a um determinado preço limite máximo. Essas ordens são coletadas em determinados intervalos e fornecem um preço de liquidação uniforme para todos os pares de negociação de tokens. A ideia geral por trás desse modelo é que ele ajudará a eliminar o fenômeno de front-running que é comum em AMMs populares.

Outra coisa importante a notar é que, nessas configurações, o sequenciador pode precisar de alguns incentivos para aplicar (e impor) as regras acima. Isso muitas vezes é negligenciado, mas grande parte da infraestrutura da rede Blockchain é administrada por empresas especializadas, cujo custo é bastante diferente do do participante doméstico médio. Em geral, os incentivos são uma parte importante da implementação da infraestrutura de segurança. Sequenciadores e construtores também são mais propensos a fazer um esforço maior quando os incentivos estão alinhados com as regras aplicadas. Isso significa que essas configurações também devem ter um mercado ativo. Claramente, este tipo de mercado está se tornando mais centralizado, pois o custo de capital para especialização pode ser alto. Como resultado, os Satoshi (e os mais ricos) provavelmente se consolidarão e se especializarão para capturar o máximo de valor possível. Aqui, o fluxo de ordem de exclusividade pode ser uma flecha no joelho para alguns participantes, levando a um aumento na centralização. Uma taxa de referência geral pode ser suficiente, mas não empurra os participantes do ranking para a especialização. Como resultado, você pode querer introduzir alguns conceitos que fazem os comerciantes felizes com os resultados através de incentivos que são adaptados à sua situação particular.

Isso é claro para a maioria das pessoas, mas ainda precisa ser mencionado ao discutir a ordenação dos níveis do Rollup. Se você puder controlar o pedido, será mais fácil "extrair" o valor do protocolo. Isso ocorre porque você controla o poder de reordenar transações, que geralmente é baseado em taxas de prioridade (configurações MEV-boost-esque) na maioria dos L1s. Ele fornece taxas prioritárias pagas por participantes complexos que extraem valor on-chain. Estes participantes estão geralmente dispostos a pagar um montante considerável (até que já não seja capaz de fornecer valor). No entanto, a maioria dos rollups atuais são principalmente por ordem de chegada. A maioria das extrações de MEV são realizadas através de guerras atrasadas, o que coloca séria pressão sobre a infraestrutura do Rollup. Como resultado do acima, é provável que vejamos mais e mais rollups começando a implementar uma estrutura de classificação com o conceito de taxas prioritárias (por exemplo, o mecanismo de aumento de tempo da Arbitrum).

Outro exemplo que gostamos é o Uniswap. Atualmente, o Uniswap como protocolo "cria" muitas ineficiências. Estas ineficiências são exploradas pelos participantes que procuram extrair MEV (Arbitragem à custa dos Fornecedores de Liquidez). Ao mesmo tempo, esses participantes pagam muitas taxas para extrair valor, mas nenhum desse valor cai nas mãos do protocolo Uniswap ou de seus detentores de tokens. Em vez disso, uma parte significativa desse valor extraído é paga uma taxa de prioridade aos proponentes do Ethereum (validadores) via MEV-Boost para ganhar o direito de ser incluído em um bloco que permite capturar valor em algum momento. Como resultado, embora existam muitas oportunidades de MEV para fluxos de ordens Uniswap, nenhuma delas foi capturada pela Uniswap.

Se o Uniswap for capaz de controlar os pedidos dentro do protocolo (e a capacidade de extrair taxas de prioridade dos pesquisadores), ele pode ser comercializado e pode até pagar alguns desses lucros aos detentores de tokens, provedores de liquidez ou outros. Com as mudanças no Uniswap (por exemplo, UniswapX, etc.) passando para a execução off-chain (e Ethereum como uma camada de liquidação), este mecanismo parece cada vez mais provável.

Se assumirmos um rollup com um mecanismo PBS parcial, o fluxo de pedidos e o processo de comercialização podem ter esta aparência:

Como resultado, a comercialização de sequenciadores e proponentes de rollup pode seguir a seguinte fórmula:

Emissão (PoS) + Receita de Taxa (+prioridade) - O custo de DA, pub estatal, armazenamento

Uma boa maneira de ver quanto valor está sendo retirado atualmente no Ethereum (especialmente Arbitragem) pode ser encontrada em Mevboost.pics, que dá uma boa visão geral de quanto valor pode realmente ser extraído de ineficiências.

Além disso, separar a guerra de gás de taxa prioritária da estrutura off-chain pode ajudar a conter interrupções na cadeia de suprimentos, isolando a extração de MEV no ambiente de execução. No entanto, considerando que, se a eleição do líder ocorrer no Rollup, a maioria do MEV será desenhada no Rollup, isso deixa pouco espaço para a estrutura subjacente, a menos que a camada DA seja incluída, as taxas prioritárias da camada de Liquidação vêm da consolidação de liquidez ou de outras economias de escala.

Para clarificar, muitas destas estruturas podem funcionar como estruturas puramente fora da cadeia, sem necessidade de pontes de verificação ou garantias de segurança sólidas. No entanto, há algumas compensações que têm de ser feitas lá. Estamos começando a ver mais dessas coisas aparecendo, tanto existentes quanto invisíveis. Uma coisa que quero salientar é que modularidade não significa necessariamente rollups.

O agrupamento acima representa um exemplo em que o ajuste fino da infraestrutura pode melhorar drasticamente o aplicativo criado sobre ele.