Autor original: APRIORI ⌘

Compilação original: Shenchao TechFlow

introduzir

No processo de melhoria do desempenho do blockchain para alcançar aplicações em grande escala, a Monad otimiza efetivamente o modelo Ethereum Virtual Machine (EVM). Essas melhorias resolvem gargalos de execução e problemas de acesso estatal ineficiente em plataformas como Ethereum, sem sacrificar a descentralização.

Este artigo explora a possibilidade de construir uma infraestrutura robusta de leilão de valor extraível de minerador (MEVA) em Monads, aproveitando a valiosa experiência de Flashbots em Ethereum e Jito Network em Solana.

Gostaríamos de destacar alguns pontos-chave:

  • MEV é uma propriedade inerente de qualquer rede blockchain. Uma infraestrutura MEVA robusta é fundamental para evitar externalidades negativas e desalinhamento de incentivos no processo de produção de blocos.

  • O design do MEVA está intimamente relacionado ao mecanismo subjacente do blockchain, especialmente à fase de execução do consenso. As melhorias futuras dependerão da evolução destes factores e do desempenho da rede sob diferentes tensões.

  • As tendências históricas na produção de blocos em Ethereum e Solana podem fornecer uma referência para o design de MEVA em Monads.

  • Em um blockchain de alto desempenho e execução atrasada como o Monad, o MEVA pode exigir construção de blocos probabilísticos e estratégias de busca semelhantes às negociações de alta frequência para lidar com restrições de tempo.

Ao explorar essas questões, esperamos fornecer insights sobre o projeto de infraestrutura MEVA que acomode as necessidades exclusivas de arquitetura e desempenho da Monad.

Histórico MEVA em Ethereum

MEVA na fase de execução de consenso Ethereum

No Ethereum, o consenso precisa ser executado primeiro. Quando os nós concordam com um bloco, eles concordam não apenas com a lista de transações no bloco, mas também com a raiz Merkle que é resumida após a execução do bloco. Portanto, o proponente deve executar todas as transações do bloco antes de propagar a proposta. Ao mesmo tempo, os nós de verificação também precisam executar essas transações antes de votar.

Figura 1: Fluxo de trabalho do construtor para separação proponente-construtor (PBS) no MEV-Boost

A Figura 1 mostra um fluxo de trabalho típico do construtor para separação proponente-construtor (PBS) no MEV-Boost. Após o construtor concluir a construção do bloco, ele o envia ao retransmissor, que encaminha o bloco ao cliente da camada de execução (EL) para simulação e verificação de validade.

Como a execução é um pré-requisito para o consenso, quando um construtor constrói um bloco, ele precisa encaminhar o bloco para o cliente da camada de execução (EL) e simular o bloco para verificar sua validade. Além de seu papel necessário na fase de execução do consenso, a fase de simulação também traz benefícios para construtores e pesquisadores.

Da perspectiva do construtor: Ao simular cada transação, os construtores podem estimar com precisão o valor do bloco para si próprios e para os validadores. Eles também podem tentar reordenar as transações para minimizar reversões e maximizar as taxas de gás ou dicas básicas extraídas do mempool e das transações agrupadas. Estimativas precisas permitem que eles façam lances mais altos para validadores.

Do ponto de vista do pesquisador: Como o construtor filtra as transações agrupadas que podem ser revertidas antes da transação ser colocada na cadeia, o pesquisador pode garantir a execução da estratégia, aumentando a certeza. Além disso, os pesquisadores podem acessar o status de bloqueio mais recente. Quando a camada de consenso (CL) propaga um novo bloco, os pesquisadores podem usar o estado desse bloco como ponto de partida para construir transações agrupadas lucrativas. Ao mesmo tempo, há sinais de que os construtores estão agora oferecendo mais transações ou recursos fora do protocolo que permitem aos pesquisadores obter informações sobre o status dos próximos blocos, a fim de adicionar estratégias de fallback aos próximos blocos.

No entanto, o crescimento do PBS levou a uma maior centralização da construção de blocos, semelhante ao que ocorre no comércio tradicional, onde as empresas competem por canais de rede de microondas dedicados para priorizar a execução de estratégias de arbitragem.

À medida que a rede amadurece, os produtos estão iterando

Exploraremos agora como o MEVA evoluiu à medida que o Ethereum evoluiu, conforme mostrado na Figura 2.

Figura 2: Visão cronológica do MEVA à medida que a rede Ethereum evolui

Era do Leilão Prioritário de Gás (PGA)

Conforme mostrado na Figura 3, os pesquisadores identificam oportunidades lucrativas de MEV e enviam transações de contratos inteligentes ao mempool público. Esta visibilidade pública leva a licitações públicas e leilões de preço único na cadeia, onde mesmo as transações fracassadas incorrem em taxas de gás.

Este período viu o surgimento de atividades MEV não estruturadas altamente competitivas e caras, como transações com pares idênticos (conta, anúncio) e ofertas crescentes, levando ao congestionamento da rede ou à instabilidade do consenso.

Figura 3: Diagrama simples de leilão de gás prioritário

Flashbots e EIP-1559 

Para resolver esses problemas, os Flashbots introduziram os retransmissores como casas de leilões intermediárias entre os pesquisadores e os produtores de blocos (mineradores na era PoW). Esta mudança transforma o mercado de MEV de um leilão de primeiro preço com licitação aberta para licitação selada. Conforme mostrado na Figura 4, os relés ajudam a evitar o aumento de licitações no mempool público e a estabelecer um processo de produção de blocos mais ordenado e seguro.

A estrutura de taxas do EIP-1559 também desempenha um papel aqui. Simplifica a licitação por meio de taxas básicas, mas não resolve o problema da ordem de transação dentro dos blocos, o que ainda impulsiona o MEV por meio de taxas prioritárias. Na verdade, muitos pesquisadores anteriormente faziam lances diretamente aos mineradores por meio de transferências de base de moedas. Eles acabaram tendo mais reclamações sobre as taxas da coinbase porque não conseguiam mais enviar transações agrupadas com gás 0.

Figura 4: MEVA com relés

Separação de Proponentes e Construtores (PBS)

Depois que a Ethereum concluiu sua fusão e mudou para Prova de Participação (PoS), a separação proponente-construtor (PBS) foi implementada para otimizar ainda mais a separação de funções no pipeline de produção de blocos. Conforme mencionado anteriormente, os retransmissores agora atuam como intermediários entre os construtores de blocos e os proponentes, responsáveis ​​por garantir a disponibilidade dos dados e a validade do bloco. Como os proponentes podem conectar vários construtores para diferentes transações privadas, os construtores devem competir pagando taxas aos proponentes. Essa dinâmica é ilustrada na Figura 5.

Figura 5: MEVA na era PBS

risco de concentração

Apesar destes avanços históricos, é importante destacar o crescente risco de concentração no mercado de construção. Durante o ano passado, os nove principais construtores capturaram consistentemente mais de 50% do mercado, demonstrando um elevado grau de concentração de mercado, como mostra a Figura 6. O atual estado de concentração é ainda mais pronunciado, com os três principais construtores cobrindo mais de 90% dos blocos.

Figura 6: Participação no mercado de construtoras, esta figura ilustra o alto grau de concentração predominante no mercado de construtoras (fonte da imagem)

Jito em Solana

Arquitetura do sistema Jito

Como MEVA padrão no Solana, o Jito foi criado para lidar com o alto comportamento de spam de transações do Solana devido aos baixos custos de transação. Desde que a taxa por uma transação falhada (aproximadamente 0,000005 SOL) não exceda o lucro esperado, o comportamento de spam é efetivamente incentivado.

De acordo com o relatório do Jito Labs de 2022, mais de 96% das tentativas de arbitragem e liquidação falharam naquele ano, e os blocos continham mais de 50% das transações relacionadas ao MEV. O relatório também afirmou que os bots de liquidação enviaram milhões de pacotes duplicados para a rede apenas para completar milhares de liquidações bem-sucedidas, resultando em uma taxa de falha superior a 99%.

Figura 7: MEVA de Jito em Solana

A gravidade do problema de externalidade do MEV em Solana levou Jito a desenvolver uma camada MEVA projetada para trazer ordem e segurança ao processo de produção de blocos. Vamos revisar a arquitetura MEVA original proposta por Jito, mostrada na Figura 7.

Jito possui os seguintes componentes:

Relayer - atua como um proxy para receber transações e encaminhá-las para o mecanismo de bloco (ou cadeia de suprimentos MEVA) e validadores.

Block Engine - recebe transações de retransmissores, coordena buscadores, aceita pacotes, realiza simulações de pacotes e encaminha as melhores transações e pacotes aos validadores para processamento. É importante notar que Jito realiza leilões de blocos parciais para inclusão em pacotes, em vez de leilões de blocos completos, e historicamente processou mais de 80% dos pacotes em dois slots.

Pool de pseudomemória - cria uma janela de tempo de operação de aproximadamente 200 milissegundos através do cliente Jito-Solana, disparando um leilão discretizado do fluxo de ordens. Jito fechou este mempool em 9 de março de 2024.

As escolhas de design de Jito

Vamos explorar os componentes específicos do design do sistema Jito e considerar como essas escolhas de design resultam do processo de produção de blocos de Solana.

Jito suporta apenas leilões de blocos parciais, em vez de construções de blocos completos, provavelmente devido à falta de agendamento global no modelo de execução multithread de Solana. Especificamente, a Figura 8 mostra threads paralelos executando transações, com cada thread mantendo sua própria fila de transações aguardando para serem executadas. As transações são atribuídas aleatoriamente a threads e ordenadas localmente por taxa de prioridade e tempo. Sem a ordenação global do lado do agendador (antes da atualização 1.18.x), as transações de Solana experimentariam inerentemente o não-determinismo devido à sobrecarga do agendador. Portanto, no MEVA, um pesquisador ou verificador não pode determinar com segurança o estado atual.

Figura 8: Modelo de execução multithread do cliente Solana. Observe que a fase de empacotamento do MEVA é anexada à fila multithread como um thread separado

Do ponto de vista da engenharia, executar o mecanismo de bloco do Jito em paralelo como um thread adicional se adapta bem à arquitetura multithread do Solana. Embora o leilão de pacotes garanta pedidos prioritários baseados em taxas dentro do thread do mecanismo de bloco Jito, não há garantia de que os pacotes sempre terão precedência global sobre as transações do usuário.

Para resolver este problema, Jito pré-aloca uma parte do espaço do bloco para o encadeamento do pacote para garantir que o pacote tenha espaço no bloco. Embora a incerteza permaneça, esta abordagem aumenta a probabilidade de execução bem-sucedida da estratégia. Isso também incentiva os pesquisadores a participarem do leilão, em vez de enviar spam para a rede com transações. Ao reservar espaço de bloco para agrupamento, Jito consegue encontrar um equilíbrio entre promover leilões ordenados e mitigar os efeitos caóticos do spam de transações.

Remover pool de pseudomemória

A ampla adoção do Jito produziu resultados positivos na mitigação de problemas de spam no Solana. De acordo com a pesquisa p2p e os dados mostrados na Figura 9, a produtividade relativa do bloco aumenta significativamente após a adoção do cliente Jito. Isso mostra que o processamento de transações se tornou mais eficiente graças ao mecanismo de bloco otimizado introduzido pela Jito em 2023.

Figura 9: Evidência de que o Jito mitiga efetivamente o problema de spam em Solana. Este diagrama foi retirado de um estudo conduzido pela equipe p2p

Embora tenham sido feitos progressos significativos, muitos desafios permanecem. Como os pacotes Jito preenchem apenas parcialmente os blocos, as transações induzidas por MEV ainda podem ignorar o canal de leilão Jito. Parte da evidência pode ser encontrada no Dune Dashboard na Figura 10, que mostra que desde 2024, a rede ainda enfrenta uma média de mais de 50% de falhas nas transações devido a transações de spam de bot.

Figura 10: Painel Dune de atividade de spam de bot em Solana desde maio de 2022 (consulte Dune para obter detalhes)

Em 9 de março de 2024, Jito decidiu suspender seu principal pool de memória. A decisão deveu-se ao crescimento das transações de memecoin e ao consequente aumento de ataques sanduíche (onde os pesquisadores colocam as transações antes e depois da transação alvo), impactando, em última análise, a experiência do usuário. Semelhante ao canal de fluxo de pedidos privados MEVA no Ethereum, o fechamento do mempool público pode facilitar o crescimento do fluxo de pedidos privados por meio da cooperação com serviços front-end, como provedores de carteira e bots do Telegram. Os pesquisadores podem firmar parceria diretamente com um validador para obter direitos prioritários de execução, inclusão ou exclusão.

Na verdade, a Figura 11 mostra os lucros do bot sanduíche por hora para o maior pesquisador privado de mempool depois que o mempool foi fechado.

Maior pesquisador de mempool privado:

3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81

(Nota do tradutor: O robô sanduíche é uma ferramenta comum de ataque frontal, usada principalmente para obter lucros em transações blockchain).

Figura 11: Lucro do Sandwich Bot por hora usando mempool privado para o pesquisador “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”

A decisão de Jito de encerrar o mempool demonstra o compromisso da equipe em resolver problemas fundamentais no ecossistema Solana. Além de iterar no MEVA ou ajustar o mecanismo de taxa de gás de Solana, Jito ajuda o protocolo a reduzir o risco de ataque por meio de opções de design de produto de UI, como limitar parâmetros de deslizamento padrão. Seja através de ajustes na estrutura de taxas que tornam as transações de spam mais caras, ou através de modificações no protocolo de comunicação, a infraestrutura da Jito continuará a desempenhar um papel crítico na manutenção da saúde e estabilidade da rede Solana.

Projeto MEVA no Monad

Atraso na execução e seu impacto no MEVA

Ao contrário do Ethereum, onde chegar a um acordo sobre um bloco requer uma lista de transações (com ordem) e uma raiz Merkle resumindo todo o estado pós-evento, o Monads separa a execução anterior do consenso. O protocolo do nó só precisa resolver o problema de pedido oficial. Conforme mostrado na Figura 12, cada nó executa independentemente as transações no bloco N ao começar a chegar ao consenso no bloco N+1. Este arranjo permite um orçamento de gás que corresponde ao tempo total do bloco, uma vez que a execução só precisa acompanhar o consenso. Como o nó líder não é obrigado a calcular a raiz do estado de facto, a execução pode utilizar todo o período de consenso para processar o próximo bloco.

Figura 12: Monad atrasou a execução em comparação com a fase de consenso de execução do Ethereum. As janelas de tempo operacional também são mostradas a partir de uma perspectiva de design MEVA

Definimos a janela de tempo operacional como o período de tempo que permite à MEVA concluir uma proposta de construção de blocos no Monad que seja viável e lucrativa em comparação com o método padrão de construção de blocos. O modelo de execução atrasada tem duas consequências diretas:

  • Quando o MEVA é construído para o enésimo bloco dentro da janela de tempo de operação, os validadores estão simultaneamente alcançando um consenso na lista de transações para o enésimo bloco enquanto tentam completar a execução do N-1º bloco. Portanto, dentro da enésima janela de tempo de operação, o possível estado disponível ainda está no N-2º. Isto significa que sob esta arquitetura de execução atrasada, não há garantia de que o relé ou construtor tenha o "estado mais recente". Portanto, é impossível simular o último bloco até que o próximo bloco seja gerado, levando à incerteza.

  • Dado o tempo de bloqueio de 1 segundo do Monad, a janela de tempo de operação do MEVA é extremamente limitada. Isso significa que os construtores podem não ter tempo suficiente para simular transações e agrupar blocos completos em sequência, como normalmente é feito no Ethereum. Muitas variáveis ​​podem afetar o tempo necessário para realizar uma simulação de negociação no EVM. No entanto, supondo que a simulação de uma transação leve de 10 ^ 1 a 10 ^ 2 microssegundos (uma estimativa aproximada) e que o Monad tenha como meta 10 ^ 4 transações por segundo, a simulação de um bloco completo apenas dentro da janela de tempo de operação pode levar cerca de 1 segundo . Dado o tempo de bloco de 1 segundo do Monad, será um desafio para um construtor ou relé concluir múltiplas simulações de blocos completos para otimizar os blocos de construção.

Construtor probabilístico vs. estratégias de pesquisa

Dadas essas limitações, é impraticável concluir uma simulação de bloco completo dentro da janela de tempo operacional e simular em relação ao estado mais recente. Como os construtores agora não têm tempo nem o status mais recente para saber a dica exata de cada transação, eles devem inferir a dica do buscador com base na probabilidade de reversão da transação, confiando na reputação ou (provavelmente melhor) visando a simulação de status N-2. . Isso torna a avaliação do bloco menos certa.

Devido à falta de garantias teóricas contra a reversão de transações, os pesquisadores enfrentam maior incerteza de execução quando os validadores aceitam um bloco construído por um construtor. Isso contrasta com o Ethereum, onde os pesquisadores competem em canais dedicados de fluxo de pedidos privados para construtores, executando estratégias relativamente determinísticas. Nessa configuração de probabilidade relativa no Monads, os pesquisadores agora enfrentam um risco maior de reversão do pacote, resultando em um perfil PnL de execução mais incerto. Isto é semelhante aos traders de alta frequência que executam negociações com base em sinais probabilísticos e obtêm retornos esperados ligeiramente mais elevados ao longo do tempo.

Figura 13: Um diagrama de espectro conceitual ilustrando diferentes paradigmas de projeto MEVA, classificados de acordo com a extensão em que os blocos propostos são inspecionados ou simulados

Conforme mostrado na Figura 13, a extensão da verificação prévia de agrupamento/bloco por parte do construtor cria um espectro de incerteza em termos de preço ou avaliação dos blocos propostos. Em uma extremidade está um modelo PBS estilo Ethereum com preços precisos, onde os construtores devem usar clientes da camada de execução (EL) para simular transações em blocos propostos. Eles devem navegar por um amplo portfólio de pacotes enviados. Na outra extremidade está o modelo construtor otimista [16], com verificação assíncrona de blocos. Neste modelo, os construtores ignoram o tempo necessário para qualquer simulação dentro da janela de tempo operacional e sacam as gorjetas mostradas aos validadores ou relés depositando garantias (que podem ser reduzidas). A abordagem de verificação probabilística ou simulação parcial proposta aqui no Monads fica em algum lugar no meio, aumentando a probabilidade de o pesquisador executar a estratégia com sucesso, apesar de alguma incerteza.

Por exemplo, o formador de mercado de uma carteira de pedidos em cadeia DEX pode pré-mover suas posições via MEVA após a detecção de grandes movimentos unidirecionais de preços para evitar seleção adversa. Esta estratégia probabilística permite-lhes agir rapidamente, mesmo sem as informações de estado mais recentes, equilibrando risco e recompensa num ambiente de negociação dinâmico.

Conclusão

MEVA desempenha um papel fundamental na otimização da produção de blocos, mitigando influências externas e melhorando a estabilidade do sistema. O desenvolvimento contínuo da estrutura MEVA, como Jito em Solana e várias implementações em Ethereum, facilitou enormemente a resolução de problemas de escalabilidade e incentivos mais alinhados para os participantes da rede.

Monad é uma rede promissora em sua infância que oferece à comunidade uma oportunidade única de projetar o melhor MEVA possível. Dada a separação única entre execução e consenso da Monad, convidamos pesquisadores, desenvolvedores e validadores para colaborar e compartilhar insights. Esta colaboração ajudará a criar um processo de produção de blocos robusto e eficiente, ajudando a Monad a cumprir sua promessa como uma rede blockchain de alto rendimento.