Introdução

Na busca contínua para melhorar o desempenho da blockchain para lidar com a adoção em massa, Monad se destaca como uma força pioneira na otimização do modelo da Máquina Virtual Ethereum (EVM) com uma série de aprimoramentos em baixo nível: I/O assíncrono, uma Trie Patricia otimizada, execução adiada e Controle de Concorrência Otimista para processamento paralelo [2]. Essas melhorias abordam efetivamente gargalos de execução e acesso ineficiente ao estado vistos em plataformas como Ethereum sem sacrificar a descentralização.

Neste post, exploramos possíveis implementações de uma robusta Miner Extractable Value Auction Infrastructure (MEVA) na Monad. Também descrevemos algumas lições transferíveis e valiosas de abordagens existentes, como Flashbots no Ethereum e Jito Network no Solana.

Queremos destacar algumas considerações-chave:

1. MEV é inerente a qualquer rede blockchain. Uma infraestrutura MEVA robusta é crucial para evitar um processo de produção de blocos confuso com externalidades negativas e incentivos desalinhados.
2. O design do MEVA está profundamente integrado com a mecânica subjacente da cadeia, especialmente seu estágio de consenso-execução. Melhorias futuras dependerão da evolução desses fatores e do desempenho da rede em diferentes níveis de estresse.
3. Tendências históricas na evolução da produção de blocos, conforme visto no Ethereum e Solana, podem informar o design do MEVA no Monad.
4. MEVA em blockchains de execução diferida de alto desempenho como Monad provavelmente exigirá estratégias de construção e busca de blocos probabilísticas, semelhantes à negociação de alta frequência, devido às suas restrições de tempo.

Ao abordar esses pontos, esperamos fornecer informações sobre os desafios e considerações envolvidos no projeto de uma infraestrutura MEVA adaptada à arquitetura única e aos requisitos de desempenho do Monad.

Paisagem MEV no Ethereum

MEVA sob o Consenso-Execução de Staging do Ethereum

No Ethereum, o consenso requer execução prévia. Quando os nós concordam com um bloco, estão concordando tanto com a lista de transações no bloco quanto com a raiz de Merkle que resume o estado pós-fato após a execução do bloco. Portanto, os líderes devem executar todas as transações no bloco proposto antes de propagar a proposta. Enquanto isso, os nós validadores precisam executar as transações antes de votar.

Figura 1: O Fluxo de Trabalho do Construtor em MEV-Boost sob a separação EL-CL.

A Figura 1 ilustra um fluxo de trabalho típico do construtor no MEV-Boost para PBS (Proposer-Builder Separation). Os construtores terminam de construir os blocos e os submetem a um relé, que encaminha os blocos para um cliente EL (Execution Layer) para simulação e verificações de validade.

Uma vez que a execução é um pré-requisito para o consenso, quando um construtor cria um bloco, ele precisa encaminhar o bloco construído para um cliente da Camada de Execução (EL) e simular o bloco para verificar sua validade. Além de seu papel necessário na preparação do consenso-execução, a etapa de simulação também traz benefícios tanto para os construtores quanto para os buscadores.

Perspectiva do construtor: Os construtores podem estimar com precisão o valor do bloco tanto para si mesmos quanto para os validadores, simulando cada transação. Eles também podem experimentar a reordenação de transações para minimizar os retornos e maximizar a extração de taxas de gás ou gorjetas de base tanto das transações da mempool quanto das transações do pacote. Sua estimativa precisa permite lances mais altos para os validadores.

Perspectiva do pesquisador: Como resultado da triagem dos construtores de pacotes potencialmente revertidos antes de serem registrados na cadeia, os pesquisadores também veem a execução garantida da estratégia, adicionando determinismo. Além disso, os pesquisadores também têm acesso ao estado de bloco 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 pacotes lucrativos. Enquanto isso, há indicações de mais negociações ou recursos off-protocolo oferecidos pelos construtores agora, o que permite que os pesquisadores obtenham informações de estado até mesmo para o bloco atual a ser construído, adicionando estratégias de backrun aos seus blocos a serem registrados.

No entanto, o desenvolvimento do PBS tem visto um aumento na centralização na construção de blocos, espelhando a negociação tradicional em que as empresas competem por canais dedicados de rede de micro-ondas para obter prioridade na execução de estratégias de arbitragem.

Iteração do Produto à medida que a Rede Amadurece

Agora exploramos como MEV evoluiu à medida que o Ethereum progrediu, ilustrado cronologicamente na Figura 2.

Figura 2: Uma visão cronológica de como MEVA itera à medida que a Rede Ethereum avança. A figura é ligeiramente adaptada de [4].

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

Como mostrado na Figura 3, os pesquisadores identificaram oportunidades lucrativas de MEV e enviaram suas transações ativadas por smart contract para o mempool público. Essa visibilidade pública levou a um formato de leilão de primeiro preço e oferta aberta on-chain, onde até mesmo as transações falhadas incorreram em custos de gás.

Este período viu atividades de MEV não estruturadas, competitivas e custosas, como transações com o mesmo par (conta, nounce) e lances crescentes [6], contribuindo para a congestão da rede ou instabilidade de consenso.

Figura 3: Leilão Simples de Gás Prioritário. A figura foi levemente adaptada de [6].

Flashbots e EIP-1559

Para resolver esses problemas, o Flashbots introduziu relés, casas de leilão intermediárias entre os buscadores e os produtores de blocos (mineradores na era do PoW). Esta iniciativa transforma o mercado MEV de um leilão de primeiro preço de lance aberto para um leilão de lance fechado. A Figura 4 mostra como os relés ajudam a evitar a escalada de lances no mempool público e estabelecem um processo de produção de blocos mais ordenado e seguro.

A estrutura de taxas do EIP-1559 também desempenha um papel aqui [7]. Ele simplificou as ofertas, introduzindo preços parcialmente publicados por meio de taxas base, mas não abordou a ordem das transações dentro dos blocos, o que ainda gera MEV por meio de taxas de prioridade. Na realidade, muitos buscadores anteriormente estavam expressando ofertas diretamente aos mineradores por meio de transferência de coinbase. Eles acabaram tendo mais reclamações sobre as taxas da coinbase, porque não podiam mais enviar pacotes de 0 gas.

Figura 4: MEVA com Relays. A figura é ligeiramente adaptada de [6].

Separação Proposer-Builder (PBS)

Após a transição do Ethereum para o Proof of Stake (PoS) após a fusão, a Separação Proponente-Construtor (PBS) foi implementada para aperfeiçoar ainda mais a separação de funções no pipeline de produção de blocos. Como descrito anteriormente, os relés agora atuam como intermediários entre os construtores de blocos e os proponentes, atuando como custodiantes que garantem a disponibilidade de dados e a validade do bloco. Como um proponente pode se conectar a vários construtores para diferentes transações privadas, os construtores devem competir oferecendo pagamentos ao proponente. Essa dinâmica é ilustrada na Figura 5.

Figura 5: MEVA na era da PBS. Esta figura é ligeiramente adaptada de [6].

Riscos de Concentração

Apesar desses avanços históricos, é importante destacar as crescentes preocupações com os riscos de concentração no mercado de construção. No último ano, uma oligarquia dos 9 principais construtores manteve consistentemente >50% do mercado, apontando para um alto grau de concentração de mercado, como indicado na Figura 6. O estado da concentração é ainda mais pronunciado atualmente, com os três principais construtores cobrindo mais de >90% dos blocos.

Figura 6: Participação de mercado dos construtores. O gráfico indica a alta concentração prevalente no mercado de construtores. O gráfico é adotado de https://arxiv.org/pdf/2405.01329

Jito na Solana

Arquitetura do Jito

Como o MEVA canônico na Solana, Jito foi criado para lidar com a alta taxa de spam da Solana devido aos baixos custos de transação. As negociações de spam são efetivamente incentivadas, desde que o custo de uma transação fracassada (aproximadamente 0.000005 SOL) não exceda o lucro esperado.

Segundo um relatório da Jito Labs em 2022 [8], mais de 96% das tentativas de arbitragem e liquidação falharam naquele ano, com blocos contendo mais de 50% de transações relacionadas ao MEV. O relatório também destaca que os bots de liquidação inundaram a rede com milhões de pacotes duplicados apenas para realizar milhares de liquidações bem-sucedidas, resultando em uma taxa de falha superior a 99% [8].

Figura 7: Uma visão aérea do MEVA da Jito na Solana.

A gravidade das externalidades de MEV na Solana levou Jito a desenvolver uma camada de MEVA com o objetivo de trazer ordem e determinismo ao processo de produção de blocos. Vamos revisar a arquitetura original de MEVA proposta por Jito, conforme ilustrado na Figura 7.

Jito tem os seguintes componentes:

Relay - atua como um proxy para receber transações e encaminhá-las tanto para o Motor de Bloco (ou a cadeia de suprimentos MEVA) quanto para os validadores.

Block Engine - recebe transações do relayer, coordena com os searchers, aceita bundles, realiza simulações de bundles e encaminha as melhores transações e bundles para o validador processar. Notavelmente, o Jito realiza um leilão parcial de bloco para inclusão de bundles em vez de um leilão completo de bloco, processando historicamente mais de 80% dos bundles em dois slots [9].

Pseudo Mempool - cria uma janela de tempo operacional de aproximadamente 200 milissegundos através do cliente Jito-Solana, induzindo um leilão discretizado para o fluxo de pedidos [10]. Jito encerrou esse mempool em 9 de março de 2024.

Escolhas de Design do Jito

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

Jito suporta apenas leilões parciais de blocos em vez de construção completa de blocos, provavelmente devido ao modelo de execução multi-threaded da Solana, que não possui agendamento global. Especificamente, a Figura 8 mostra threads paralelos que executam transações, cada uma mantendo sua própria fila de transações aguardando execução. As transações são atribuídas aleatoriamente às threads e ordenadas localmente por taxa de prioridade e tempo. Sem ordenação global no lado do agendador (antes da atualização 1.18.x), as transações da Solana experimentam intrinsecamente não determinismo do jitter do agendador [11]. Consequentemente, no MEVA, os pesquisadores ou validadores não podem determinar com confiabilidade o estado atual.

Figura 8: O modelo de execução com várias threads para o Cliente Solana. Observe que a Etapa de Conjunto do MEVA é anexada como uma thread separada na fila multithreaded.

Do ponto de vista da engenharia, integrar o feed do motor de bloco da Jito como um thread adicional em paralelo aos existentes se encaixa bem com a arquitetura multi-thread da Solana. Enquanto os leilões de pacotes garantem a ordenação com base em taxa de prioridade dentro do thread do motor de bloco da Jito, não há garantia de que os pacotes sempre serão colocados antes das transações do usuário globalmente.

Para resolver isso, o Jito pré-aloca parte do espaço do bloco para a thread do pacote, garantindo pacotes com espaço no bloco. Embora o indeterminismo permaneça, essa abordagem aumenta a probabilidade de execução bem-sucedida da estratégia. Também incentiva os pesquisadores a participarem do leilão em vez de inundar a rede. Ao reservar espaço de bloco para pacotes, o Jito consegue encontrar um equilíbrio, promovendo leilões ordenados e mitigando os efeitos caóticos do spam de transações.

Removendo o Pseudo-Mempool

A ampla adoção do Jito tem produzido resultados positivos na mitigação do problema de spam na Solana. Pesquisas realizadas pela p2p [12] e dados mostrados na Figura 9 revelam uma melhoria estatisticamente significativa na taxa de produção de blocos relativa após a adoção do cliente Jito. Isso indica que o processamento de transações se tornou mais eficiente, graças ao motor de bloco otimizado do Jito introduzido em 2023.

Figura 9: Evidência da eficácia do Jito na mitigação do problema de spam no Solana. O gráfico é extraído de um artigo de pesquisa em [12] conduzido pela equipe p2p.

Embora tenham sido feitos progressos significativos, muitos desafios ainda permanecem. Como os pacotes Jito preenchem apenas parcialmente os blocos, as transações que induzem MEV ainda podem contornar o canal de leilão Jito. Este problema é pelo menos parcialmente evidenciado pelo Painel Dune na Figura 10 [13], que mostra que a rede ainda enfrenta uma média de mais de 50% de transações falhadas devido a spam de bots desde 2024.

Figura 10: Um painel Dune (https://dune.com/queries/3537204/5951285ilustrando as atividades de spam de bot na Solana desde maio de 2022.

Em 9 de março de 2024, a Jito tomou a decisão de suspender sua mempool principal. Essa decisão foi motivada pelo crescimento das transações de memecoin e um aumento correspondente nos ataques de sandwich (um tipo de front-running onde os buscadores colocam transações antes e depois da transação alvo), o que acabou degradando a experiência do usuário. Semelhante às tendências observadas no Ethereum com canais de fluxo de pedidos privados em MEVA, desligar a mempool pública pode incentivar o crescimento do fluxo de pedidos privados por meio de parcerias com serviços de front-end, como provedores de carteira e bots do Telegram. Os buscadores podem formar parcerias diretamente com validadores para execução, inclusão e exclusão preferenciais. Na verdade, evidências disso podem ser vistas na Figura 11, que ilustra o perfil de lucro horário do bot de sandwich para o maior buscador de mempool privada (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) após o desligamento da mempool.

Figura 11: O lucro por hora para o Bot de Sanduíche com Mempool Privado para o Pesquisador “3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81”.

A decisão da Jito de fechar o mempool destaca o forte compromisso da equipe em lidar com questões fundamentais dentro do ecossistema Solana. Além de iterar sobre o MEVA ou ajustar o mecanismo de taxa de gás do Solana, a Jito também ajuda a educar protocolos sobre a mitigação de vetores de ataque por meio das escolhas de design de produto de UI, como limitar os parâmetros de derrapagem padrão. Seja por meio de ajustes na estrutura de taxas que tornem o spam mais caro ou por meio da modificação de protocolos de comunicação, a infraestrutura da Jito continuará sendo essencial para manter a saúde e a estabilidade da rede Solana.

Design MEVA no Monad

Execução Diferida e Implicações no MEVA

Ao contrário do Ethereum, onde concordar com um bloco requer tanto a lista de transações (com ordenação) quanto a raiz de Merkle que resume todos os estados pós-facto, o Monad desacopla a execução anterior do consenso. O acordo do nó só requer estabelecer a ordenação oficial. Como ilustrado na Figura 12, cada nó executa as transações no bloco N de forma independente enquanto inicia o consenso no bloco N+1. Este arranjo permite um orçamento de gás correspondente ao tempo total do bloco, uma vez que a execução só precisa acompanhar o consenso. [15] Sem a necessidade de o nó líder calcular a raiz de estado de facto, a execução pode utilizar todo o período de consenso para o próximo bloco.

Figura 12: Execução Diferida de Monad comparada à execução em etapas de Consenso de Execução do Ethereum. A Janela de Tempo Operacional também é ilustrada a partir da perspectiva de design do MEVA.

Definimos a Janela de Tempo Operacional como o prazo permitido para que o MEVA na Monad conclua uma proposta de construção de blocos que seja viável e lucrativa em comparação com o método padrão de construção de blocos. Há duas consequências imediatas do modelo de execução diferida:

1. Quando o MEVA constrói para o enésimo bloco dentro da janela de tempo operacional, os validadores estão concordando simultaneamente com a lista de transações para o enésimo bloco enquanto tentam completar a execução para o bloco en-1. Portanto, dentro da janela de tempo operacional em N, é muito possível que o estado disponível ainda esteja em N-2. Isso significa que não há um “estado mais recente” garantido para o relé ou para o construtor sob esta arquitetura de execução diferida. Assim, é impossível simular o bloco mais recente antes que o próximo seja produzido, resultando em indeterminismo.
2. Dado o tempo de bloco de 1 segundo do Monad, a janela de tempo operacional para MEVA é extremamente limitada. Isso significa que os construtores podem não ter tempo suficiente para simular sequencialmente blocos completos de transações e conjuntos, como geralmente fazem no Ethereum. Muitas variáveis podem afetar o tempo necessário para a simulação de transações no EVM. No entanto, supondo que a simulação de uma transação leva entre 10^1 a 10^2 microssegundos (uma estimativa aproximada), e com a meta do Monad de 10^4 transações por segundo, poderia levar aproximadamente 1 segundo inteiro apenas para simular o bloco completo dentro da janela de tempo operacional. Considerando o tempo de bloco de 1 segundo do Monad, seria desafiador para os construtores ou relés completar múltiplas simulações de blocos completos para otimizar o bloco construído.

Estratégia de Construtor e Pesquisador Probabilístico

Dadas as restrições, completar uma simulação completa de bloco dentro da janela de tempo operacional e simular contra o estado mais recente é impraticável. Como os construtores agora não têm tanto tempo quanto o estado mais recente para saber a dica exata de cada transação, eles devem inferir a dica do pesquisador com base na probabilidade de reversão da transação, confiando na reputação ou simulando contra (possivelmente no máximo) o estado N-2. Isso torna a valoração do bloco menos determinística.

Os pesquisadores enfrentam uma maior incerteza de execução devido à falta de garantia teórica contra reversões de transações uma vez que o validador aceita o bloco construído pelo construtor. Isso contrasta com o Ethereum, onde os pesquisadores competem por canais dedicados de ordens privadas para construtores para execuções de estratégias relativamente determinísticas. Neste ambiente relativamente probabilístico em Monad, os pesquisadores agora enfrentam um risco maior de reversão de bundles on-chain, levando a um perfil de PnL de execução mais incerto. Isso reflete os traders de alta frequência que executam sinais probabilísticos com retornos esperados ligeiramente positivos ao longo do tempo.

Figura 13: Um diagrama de espectro conceitual ilustrando diferentes paradigmas de design MEVA categorizados pelo grau de verificação ou simulação de bloco proposto.

Conforme mostrado na Figura 13, o grau de verificação prévia do pacote / bloco no lado do construtor cria um espectro de incerteza em relação ao preço ou valoração do bloco proposto. Em uma extremidade está o modelo PBS estilo Ethereum com preços precisos, onde os construtores devem usar o Cliente da Camada de Execução (EL) para simular transações no bloco proposto. Eles têm que navegar por uma ampla gama de combinatoriais entre os pacotes enviados. Na outra extremidade está o Modelo de Construtor Otimista [16] com verificação assíncrona de bloco. Neste modelo, os construtores contornam o tempo necessário para qualquer simulação durante a janela de tempo operacional e honram as dicas mostradas aos validadores ou ao relay depositando garantias sujeitas a penalizações. A abordagem de verificação probabilística ou simulação parcial proposta aqui em Monad fica no meio, aumentando a probabilidade de execução bem-sucedida da estratégia para os pesquisadores, apesar de algum indeterminismo.

Por exemplo, um market maker em um DEX de livro de ordens onchain pode pagar para pré-mover suas posições via o MEVA quando identificarem um movimento de preço unidirecional importante para evitar a seleção adversa. Essa estratégia probabilística permite que eles ajam rapidamente, mesmo sem as informações mais recentes do estado, equilibrando o risco e a recompensa em um ambiente de negociação dinâmico.

Considerações Finais

O MEVA desempenha um papel crucial na otimização da produção de blocos, mitigando externalidades e melhorando a estabilidade geral do sistema. A evolução contínua dos frameworks MEVA, exemplificada por Jito no Solana e várias implementações no Ethereum, é imensamente útil para enfrentar os desafios de escalabilidade e alinhar os incentivos dos participantes da rede.

Monad é uma rede promissora em sua infância, apresentando uma oportunidade única para a comunidade moldar o design MEVA ideal. Considerando a exclusiva execução-consenso de Monad, convidamos pesquisadores, desenvolvedores e validadores a colaborar e compartilhar insights. Essa colaboração será instrumental na criação de um processo de produção de blocos robusto e eficiente, permitindo que Monad alcance seu potencial como uma rede blockchain de alta capacidade.

Disclaimer:

1. Este artigo é republicado a partir de [0xapr]. Todos os direitos autorais pertencem ao autor original [ APRIORI ⌘]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles irão lidar com isso prontamente.
2. Aviso de Responsabilidade: As 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 do Gate Learn. A menos que mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.