
O MEV pode parecer inofensivo no início. Caramba, poderia até aparecer como um impulsionador para a segurança da rede, mais incentivos para mineração ou validação, certo? Além das habituais recompensas em bloco e taxas de transação, agora há MEV em disputa. Mas a realidade está longe de ser inofensiva. Se não for controlada, a MEV pode se tornar uma potente força centralizadora. Aqui está uma história para ilustrar isso: Imagine que você acabou de tomar conhecimento deste jogo MEV e ouvir que os validadores estão arrecadando mais de 10% de APR por causa disso. Tentador, né? Você está dentro! Assim, você envia seus 32 ETH para o contrato de staking e inicia um nó validador. Mas espere um minuto... Você só está vendo um retorno de 4%. Quando chega a sua vez de propor um bloco, as transações simplesmente se alinham pelo preço do gás. Sem magia MEV. Você não está armado com os intrincados algoritmos e táticas para minerar esse ouro MEV. Sem o know-how, você fica preso ao padrão: ordenar transações pelo preço do gás.
Aqui é onde o puxão centralizador entra em ação. Mesmo que você seja um quant, seu computador simples, talvez um raspberry pi, não chega aos pés de seus supercomputadores executando jogadas de extração de MEV de próximo nível. O objetivo óbvio aqui é desligar seu validador e, em vez disso, enviar seu ETH para essas configurações super potentes que prometem uma parte do bolo do MEV. Avance rápido e você pode ver um punhado desses gigantes essencialmente executando a rede, um resultado centralizado verdadeiramente inquietante. Se é para onde as coisas estão indo, então os objetivos fundamentais do Ethereum falharam. Uma rede dominada por alguns poucos poderia muito bem ser um banco de dados centralizado nesse ponto.
Front-running envolve detectar uma transação no mempool que visa trocar o Token A pelo Token B. Um favorito então inicia programaticamente uma transação semelhante que oferece um preço de gás mais alto. Essa estratégia garante que a transação do favorito seja processada antes da original. Depois que a transação inicial é processada, o favorito pode imediatamente trocar o Token B de volta pelo Token A, terminando com uma quantidade maior de Token A do que começou. Essa tática às vezes é chamada de ataque sanduíche, pois a transação do usuário fica ensanduichada entre duas transações iniciadas pelo favorito. Como resultado, enquanto o favorito ganha lucro, o indivíduo por trás da transação original recebe menos do Token B. Enquanto ataques de sanduíche são comuns, existem várias estratégias que os indivíduos podem usar para extrair MEV de forma eficaz.

Visualizando o Ataque do Sanduíche: Como os Primeiros Lucram à Custa dos Outros
Durante o boom do ICO, Phil e uma equipe implantaram um robô que rendia cerca de um milhão de dólares anualmente. Após compartilhar sua metodologia na postagem do blog que mencionei anteriormente, surgiram vários robôs semelhantes, criando um cenário competitivo onde os robôs superariam os preços de gás uns dos outros para alcançar prioridade de transação. Isso levou Phil a implantar nós globalmente, capturando dados transacionais em tempo real. Essa pesquisa culminou em seu famoso Papel "Flash Boys 2.0", que mergulhou fundo nos desafios do MEV causados pelas exchanges descentralizadas.
Aqui está uma história divertida relacionada que Phil compartilhou quando ele foi um convidado no BerlindaQuando Hayden Adams, o fundador da UniSwap, compartilhou seu design para o que agora é a bolsa descentralizada mais popular em ethresear.ch. Phil imediatamente enviou mensagens com suas preocupações tanto para Vitalik quanto para Hayden. Phil acreditava que o design da UniSwap causaria uma quantidade significativa de MEV, tornando-se um alvo principal para exploração e colocando os usuários em risco de reordenamento de transações e ataques sandwich. Vitalik respondeu sugerindo que isso poderia ser visto apenas como um mecanismo de taxa adicional para usar a blockchain. Phil ficou tão irritado com essa resposta e pensou que entidades financeiras poderosas como o Goldman Sachs iriam entrar e devorar o almoço dos pequenos como no sistema financeiro atual. No entanto, com o tempo, Phil passou a adotar a perspectiva de Vitalik (todo o louvor ao senhor Vitalik).
Reconhecendo a importância e os desafios do espaço MEV, Phil co-fundou Flashbots, uma empresa focada em pesquisa e soluções na arena MEV. Flashbots percebeu que o MEV vai existir e Flashbots é missão de garantir que a existência do MEV não leve a um sistema onde ser uma pessoa má ou criar externalidades negativas seja melhor para você individualmente e seja mais lucrativo do que ser um bom ator. Um exemplo disso está no TradFi, as estratégias mais lucrativas frequentemente envolvem a exploração das margens do sistema. Além disso, Flashbots pensou que poderia haver uma maneira de aproveitar a energia do MEV para os usuários e subsidiar pessoas que seguram a rede e também subsidiar transações na rede para dar às pessoas preços melhores para dar às pessoas a execução que desejam nesses sistemas. Se projetado corretamente, o MEV poderia ser parte do que faz com que as criptomoedas superem os sistemas tradicionais.
Com o MEV GETH, os mineradores tinham um novo ponto final. Eles poderiam receber pacotes de transações otimizados para MEV dos buscadores. Cada pacote também conteria uma transação que fornecia aos mineradores uma taxa, incentivando-os a selecionar esse pacote específico. Naturalmente, os mineradores escolhiam o pacote que oferecia a maior taxa. Quando os buscadores competem por oportunidades de MEV na mempool pública, seus lances naturalmente aumentam devido a essa competição. Essa competição garante que os mineradores recebam a maior parte dos benefícios do MEV.
Vamos analisar isso com um exemplo: Imagine que Alice é uma pesquisadora e identifica uma oportunidade de arbitragem entre duas exchanges descentralizadas. Ela poderia lucrar 0.07 ETH comprando o Token X na UniSwap e imediatamente vendendo-o na SushiSwap por um preço mais alto. Então, ela cria um pacote de transações otimizado para a oportunidade MEV de 0.07 ETH e está disposta a pagar a um minerador 0.05 ETH para priorizar suas transações no próximo bloco. Bob, outro pesquisador, identifica a mesma oportunidade. Ele constrói um pacote semelhante, mas oferece um pagamento de 0.06 ETH aos mineradores pelo mesmo privilégio. Alice e Bob enviam seus pacotes de transações otimizadas para MEV aos mineradores. Do outro lado, um minerador recebe esses pacotes e precisa decidir qual incluir no próximo bloco. Naturalmente, o minerador escolhe o pacote de Bob devido à taxa mais alta oferecida, garantindo que o minerador obtenha o benefício máximo. É uma situação vantajosa para todos.
O minerador captura a maior parte da oportunidade de MEV, recebendo 0,06 ETH da oportunidade de 0,07 ETH. Enquanto isso, o pesquisador garante um lucro líquido de 0,01 ETH, que de outra forma não teriam sido capazes de obter. A essência do mecanismo MEV GETH é essa licitação competitiva. Alice e Bob competem entre si, oferecendo incentivos ao minerador, garantindo assim que o minerador capture uma parte significativa dos benefícios de MEV.
No entanto, se eles simplesmente abrirem um endpoint para qualquer um enviar os pacotes de mineradores, agentes mal-intencionados podem explorar essa abertura para sobrecarregar seu sistema, potencialmente lançando um ataque DOS. Para resolver essa vulnerabilidade, os Flashbots introduziram o Flashbots Relay. Esse relé tem um papel crucial de filtragem: ele avalia os pacotes de transações recebidos com base em sua lucratividade potencial para os mineradores, a validade das transações e a taxa oferecida. Apenas os pacotes ideais são então encaminhados aos mineradores. Esse método introduz um nível de centralização, pois o processo depende do Flashbots Relay para filtrar tráfego indesejável ou potencialmente prejudicial. Curiosamente, já existia um nível de PBS entre o operador do pool de mineração e seus trabalhadores. Normalmente, o operador construiu o corpo do bloco, incluindo os pacotes enviados dos relés, fez o hash do cabeçalho do bloco uma vez e o despachou para os trabalhadores para continuar o hashing e encontrar o nonce dourado.

Visão geral do MEV GETH: A jornada da pesquisa para a inclusão do pacote de transações no bloco do minerador
MEV GETH estava sendo usado por quase todos os grupos de mineração, mas com a transição do Ethereum para PoS, o sistema exigia modificações. PoS foi projetado para acomodar validadores individuais operando em dispositivos de baixo recurso como um Raspberry Pi. PoS foi projetado com o objetivo de garantir uma paisagem equilibrada: quer você seja um validador individual ou faça parte de um pool de validação substancial, não haveria vantagem inerente no processo de validação para nenhum participante. Antes da transição para PoS, alguns grupos de mineração dominavam a taxa de hash. Isso permitia uma relação de confiança entre esses grupos e o Flashbots Relay. Quaisquer ações desonestas, como um grupo de mineração roubando MEV de um pesquisador, poderiam comprometer essa relação. Digamos que um minerador recebesse um pacote com um ataque de sanduíche de um pesquisador. Se o minerador adicionalmente sanduichasse o pesquisador com suas próprias transações, isso traria ganhos a curto prazo, mas romperia os laços com o Flashbots, custando-lhes ganhos futuros de MEV porque perderiam o acesso ao Flashbots Relay.
Em resposta a este novo vetor de ataque, a Flashbots lançou o MEV Boost, um sistema projetado para um ambiente com validadores individuais.
A Mecânica do Impulso de MEV:

O processo de impulso do MEV
Esta configuração introduz problemas de confiança:
Construtor-Relay Trust: Os construtores precisam confiar que os relays não irão roubar seu MEV. Considere um cenário em que um relay, após receber um bloco de um construtor, troca o endereço do construtor em uma transação de sandwich pelo seu próprio. Em seguida, eles passam o cabeçalho manipulado para o proponente.- Confiança no Proposer-Relay: Por outro lado, os proponentes devem confiar que os cabeçalhos de bloco que assinam são válidos. Propor um bloco inválido resultaria na perda das recompensas do bloco, já que a rede rejeitaria tal bloco.Projetos de design da PBS enfrentam um desafio recorrente: enquanto as interações entre o proponente e os atores de ordenação de transações são dadas, há uma clara necessidade de um mecanismo onde:
Os proponentes podem se comprometer com um bloco do construtor sem saber o seu conteúdo, mas permanecem seguros quanto à validade do bloco.- Os construtores podem enviar com segurança seu bloco ao proponente, confiantes de que seu MEV não será roubado.
MEV Aumenta suposições de confiança
Antes de mergulhar mais fundo no MEV Boost, é essencial entender a maneira padrão como o Ethereum cria blocos sem o uso do MEV Boost. Esta configuração depende da colaboração entre um Cliente de Execução de validadores e um Cliente de Consenso. Quando uma transação é recebida pelo Cliente de Execução, ele verifica o formato, a adiciona à sua mempool, mas não a processa. Simultaneamente, o Cliente de Consenso lida com o consenso de PoS, escolhendo um validador para criar o próximo bloco. O Cliente de Execução do validador selecionado então organiza as transações por preço de gás em um novo bloco, que é então encaminhado para o Cliente de Consenso e apresentado à rede. Outros validadores atestam a precisão do bloco e, uma vez verificado, ele se torna o elo mais recente da cadeia.
Esse processo muda se o validador optar por usar o MEV Boost. Validadores que integram o MEV Boost o fazem com seu cliente de consenso. Quando estão prontos para propor um bloco, eles não mais dependem de seu Cliente de Execução e, em vez disso, se conectam a uma rede de relays. Os validadores podem escolher a quais relays se conectar.
MEV Boost é opcional, mas 95% dos validadores estão utilizando. Essencialmente, quase todos os validadores, exceto aqueles administrados por Vitalik, estão delegando a construção de blocos para um terceiro. Essa delegação indica que uma função central do protocolo Ethereum, a construção de blocos, agora é realizada principalmente fora do próprio sistema Ethereum. Um jogador chave nessa configuração é o relé e seu papel contrasta um pouco com os princípios fundamentais do Ethereum. Atualmente, existem cerca de 9 relés ativos, mas apenas 6 deles têm mais de 9% de participação nos blocos transmitidos.

Desagregação dos principais relés e construtores por participação de mercado nos últimos 7 dias. Fonte: https://www.relayscan.io/
A confiança se torna um problema, uma vez que a relação entre os relays e o construtor e o relay e o validador não é sem confiança. Também há uma preocupação sobre resistência à censura. Os relays, durante seus leilões, têm a discricionariedade de determinar a validade dos blocos. Essa discricionariedade permite que eles excluam blocos com transações vinculadas a endereços sancionados. Um exemplo disso é quando as sanções do Tornado Cash da OFAC aconteceram, alguns relays exerceram esse poder. Dados recentes mostram que 38% dos blocos na semana passada seguiram as diretrizes da OFAC devido à censura imposta por tais relays.

Vale ressaltar que, como o MEV Boost é um software externo desenvolvido por uma empresa (Flashbots), ele não é tão rigorosamente testado quanto o software dentro do protocolo. Isso ficou evidente com o cliente Prism após a atualização Shapella: um bug de integração com o MEV Boost causou problemas com a assinatura do proponente, levando a slots perdidos e penalidades. O objetivo de integrar esse processo ao protocolo Ethereum é enfrentar esses desafios, garantindo que, mesmo se um acordo entre o proponente e o construtor se desfizer, o proponente permaneça reembolsado. Portanto, se um construtor fornecer um bloco defeituoso, o proponente ainda recebe o lance completo, deixando o construtor arcar com as consequências. Embora os detalhes dessa integração, referida como ePBS (separação de proponente-construtor consagrada), ainda estejam sendo pesquisados e possivelmente a alguns anos de realização, já existem muitas ideias diferentes de como ela poderia ser.
Agora, para os designs ePBS. O modelo mais favorecido abrange dois slots. Primeiro, há uma fase de licitação, onde os construtores enviam suas ofertas para os validadores. Então, o Slot 1 começa com o proponente escolhendo uma oferta e comprometendo-se com ela publicando um bloco que se compromete com a oferta do construtor. Um grupo de atestadores então emite seu voto a favor deste bloco, garantindo seu lugar na cadeia. No Slot 2, os construtores veem a oferta que foi comprometida no bloco comprometido do proponente e as atestações sobre ela. Reconhecendo o compromisso irreversível do proponente, o construtor cuja oferta foi selecionada lança seu bloco e tem a garantia de que seu MEV não pode ser roubado. Finalmente, os atestadores validam este novo bloco.

Projeto ePBS de “dois slots”
Um modelo recém-lançado é semelhante à abordagem de dois slots, mas introduz um comitê de pontualidade de carga útil. Primeiro, uma proposta do construtor é selecionada e comprometida pelo proponente, e então o comitê de validadores dá sua atestação. Posteriormente, o construtor revela a carga útil do bloco (suas transações), e o comitê de pontualidade de carga útil confirma que a carga útil foi fornecida a tempo e sua validade. As outras diferenças entre esses dois métodos residem nos detalhes das operações de Prova de Participação do Ethereum, mas isso está além do escopo deste post.

Design ePBS com um Comitê de Oportunidade de Carga Útil
Outro design gira em torno do conceito de um leilão de slot. Aqui, os construtores, durante sua oferta, comprometem-se com um slot na época sem especificar o bloco. Eles essencialmente se comprometem a criar um bloco durante seu slot alocado, oferecendo um certo preço para fazê-lo. Isso oferece adaptabilidade, especialmente para o MEV de domínio cruzado, que requer ação em tempo real.
Até agora, todos os designs de ePBS concedem ao construtor controle total sobre as transações do bloco. Uma solução alternativa potencial é o uso de uma lista de inclusão. Essa lista, enviada pelo proponente ao construtor, idealmente todas as transações atualmente na mempool ou não precisam estar, contém transações que devem fazer parte do bloco do construtor se houver espaço. Se o bloco do construtor estiver cheio, eles devem indicar isso, confirmando que reconheceram a lista. Tal método fortalece a resistência à censura da rede. Se um construtor deseja censurar uma transação, isso se tornará difícil e custoso ao longo do tempo. Devido ao EIP 1559, blocos consecutivamente preenchidos farão com que a taxa base aumente exponencialmente. Portanto, se um construtor censurar continuamente uma transação enchendo um bloco com transações fictícias, os custos crescentes tornam isso inviável com o tempo.
Pode haver casos em que o proponente deseja ter alguma influência na criação do bloco. Outra característica do ePBS pode envolver o proponente fazendo uma seção do bloco (seja o início ou o final) e delegando o restante a um construtor. Todos esses projetos e recursos não são mutuamente exclusivos, é mais sobre equilibrar seus benefícios e desvantagens.

Reenvio Otimista V1
Levando a retransmissão otimista um passo adiante para V2, podemos eliminar a necessidade do relay de baixar o bloco, reduzindo mais 50 a 100 milissegundos de latência. As mesmas garantias se aplicam: se um bloco nunca é baixado, o colateral do construtor é pago.

Transmissão otimista V2
Por fim, o jogo final para a Revoada Otimista começa a se parecer muito com o modelo de comitê de pontualidade de carga que mencionei anteriormente. Eis a sequência: Os construtores enviam seus lances em uma camada peer to peer. O proponente aceita um lance e segue com um cabeçalho assinado. Em seguida, o construtor lança o bloco. Nesta fase, o trabalho exclusivo do relé é supervisionar o mempool da camada peer to peer, basicamente cronometrando quando diferentes atividades ocorrem. O papel do relé torna-se super leve, ele só precisa manter controle sobre o mempool. Isso faz com que o relé opere de maneira muito semelhante ao comitê de pontualidade de carga. Todos esses passos contribuem para um futuro em que o relé é substituído pelo comitê de pontualidade de carga, otimizando todo o protocolo.

O designer Danksharding do pesquisador da Ethereum Dankrad Feist sugere que esses construtores altamente intensivos em recursos podem construir um único grande bloco que contém todos os dados. Esses dados são então segmentados e confirmados por múltiplos compromissos KZG. A construção deste bloco requer recursos consideráveis, mas validá-los é relativamente barato. Validadores leves podem então aplicar Amostragem de Disponibilidade de Dados para inspecionar uma pequena seção do bloco e estar quase certos da acessibilidade de todo o conjunto de dados, proporcionando um aumento adicional de cerca de 16 vezes na taxa de transferência de dados do Proto-Danksharding. As complexidades do Danksharding são complicadas e não são abordadas aqui, mas o ponto-chave é que esses construtores avançados podem ser designados para desempenhar papéis adicionais para aprimorar ainda mais a rede.
Outra ideia para aproveitar os construtores é a realização potencial de rollups baseados. Há alguns anos, Vitalik discutiu modelos de sequenciamento de rollup, cunhando o termo Total Anarchy para um deles, no qual qualquer pessoa pode publicar um bloco de rollup e a primeira sequência que atinge a cadeia é o bloco oficial. Esta abordagem teve muitas desvantagens, como spam onchain e ambiguidade sobre a sequência vencedora. No entanto, o artigo recente de Justin Drake sobre rollups baseadosdestacou uma estratégia mais eficiente aproveitando os construtores. Neste modelo, o construtor na camada um funciona como o sequenciador rollup, selecionando a sequência ótima para incluir onchain. Isso garante que apenas as sequências ótimas sejam incorporadas.
Além dos rollups, a introdução de construtores poderosos pode estimular outras estruturas inovadoras, como clientes sem estado. Eles capacitam os nós a operar como de costume, mas sem o ônus de preservar estados desatualizados. Isso permite que os nós sejam mais leves e dependam da capacidade do construtor de gerar provas criptográficas específicas.
Imagine que Alice é uma proponente na rede Ethereum. Com PEPC, Alice tem a flexibilidade de fazer um compromisso específico para o próximo bloco. Ela poderia se comprometer a que seu bloco contenha pelo menos três transações referentes a um contrato inteligente específico, e ela está disposta a alocar 70% do gás do bloco para essas transações. Ela comunica esse compromisso, e ele se torna parte das condições de validade de seu bloco. Agora, Bob, um construtor, vê o compromisso de Alice. Ele agrupa um conjunto de transações que atendem aos critérios de Alice e o envia para ela. Se o bloco de Alice, depois de construído, estiver alinhado com seu compromisso (ou seja, contém as transações especificadas que consomem o gás designado), então o bloco é considerado válido e pode ser adicionado à blockchain. Caso contrário, o bloco de Alice não será aceito, garantindo que ela cumpra seus compromissos declarados.
Uma diferença chave entre ePBS e PEPC reside na natureza dos compromissos. No ePBS, os proponentes e Construtores seguem um procedimento fixo e uniforme. É uma espécie de abordagem universal. Um proponente se compromete com um hash de bloco específico e o construtor então produz um payload correspondente. No entanto, o PEPC introduz variedade. Cada proponente pode definir condições únicas, oferecendo muito mais flexibilidade. É crucial notar que a existência do PEPC depende do ePBS, eles se complementam. Os detalhes exatos do funcionamento do PEPC ainda estão em discussão e pesquisa.





