Introdução

Na busca contínua para melhorar o desempenho de blockchain para lidar com a adoção em massa, Monad destaca-se como uma força pioneira para otimizar o modelo Ethereum Virtual Machine (EVM) com uma série de aprimoramentos de baixo nível: I/O assíncrono, uma Patricia Trie otimizada, execução diferida e controle de concorrência otimista para processamento paralelo [2]. Essas melhorias enfrentam efetivamente gargalos de execução e acesso ineficiente ao estado visto em plataformas como Ethereum sem sacrificar a descentralização.

Neste post, exploramos possíveis implementações de uma infraestrutura de leilão de Valor Extratável de Mineradores (MEV) robusta no 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 sua execução de consenso. Aprimoramentos futuros dependerão da evolução desses fatores e do desempenho da rede em diferentes níveis de estresse.
3. As tendências históricas na evolução da produção de blocos, tal como visto na Ethereum e Solana, podem informar o design do MEVA no Monad.
4. MEVA em blockchains de execução diferida de alta performance como Monad provavelmente exigirá estratégias probabilísticas de construção e busca de blocos, semelhantes à negociação de alta frequência, devido às suas restrições de tempo.

Ao abordar estes pontos, esperamos fornecer uma visão geral dos desafios e considerações envolvidos no projeto de uma infraestrutura MEVA adaptada à arquitetura única e aos requisitos de desempenho do Monad.

Paisagem MEVA no Ethereum

MEVA sob o estadiamento de consenso-execução do Ethereum

No Ethereum, o consenso requer execução prévia. Quando os nós concordam com um bloco, estão a concordar tanto com a lista de transações no bloco quanto com a raiz de Merkle que resume o estado pós-facto após o bloco ter sido executado. Assim, os líderes devem executar todas as transações no bloco proposto antes de propagar a proposta. Entretanto, os nós de validação precisam de 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 a Separação Proposer-Builder (PBS). Os construtores terminam a construção dos blocos e enviam-nos para um relé, que encaminha os blocos para um cliente da Camada de Execução (EL) para simulação e verificações de validade.

Uma vez que a execução é um pré-requisito para o consenso, quando um construtor constrói um bloco, precisa encaminhar o bloco construído para um cliente da Camada de Execução (CE) 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.

Perspetiva do construtor: Os construtores podem estimar com precisão o valor do bloco tanto para si próprios como para os validadores, simulando cada transação. Também podem experimentar a reordenação de transações para minimizar as reversões e maximizar a extração de taxas de gás ou gorjetas de base tanto das transações da mempool como das transações do pacote. A sua estimativa precisa permite fazer licitações mais elevadas aos validadores.

Perspectiva do pesquisador: Como resultado da triagem dos construtores para eliminar conjuntos 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 mais recente do bloco. Quando a camada de consenso (CL) propaga um novo bloco, os pesquisadores podem usar o estado desse bloco como ponto de partida para construir conjuntos lucrativos. Enquanto isso, há indicações de mais negociações ou recursos fora do 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 para adicionar estratégias de retrocesso 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 na qual 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 o MEVA evoluiu à medida que o Ethereum progrediu, ilustrado cronologicamente na Figura 2.

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

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

Conforme mostrado na Figura 3, os pesquisadores identificaram oportunidades lucrativas de MEV e submeteram as suas transações habilitadas para contratos inteligentes ao mempool público. Esta visibilidade pública levou a um formato de leilão de primeira oferta aberta na cadeia, onde mesmo as transações falhadas incorreram em custos de gás.

Este período viu atividades MEV competitivas e dispendiosas e não estruturadas, 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 Simplificado de Gás Prioritário. A figura é ligeiramente adaptada de [6].

Flashbots e EIP-1559

Para resolver esses problemas, a Flashbots introduziu relays, casas de leilão intermediárias entre os pesquisadores e os produtores de blocos (mineradores na era PoW). Esta iniciativa transforma o mercado de MEV de um leilão de primeiro preço de oferta aberta para um leilão de lance selado. 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]. Simplificou o processo de licitação ao introduzir preços parcialmente divulgados por meio de taxas básicas, mas não abordou a ordem das transações dentro dos blocos, o que ainda impulsiona o MEV por meio de taxas prioritárias. Na realidade, muitos pesquisadores estavam anteriormente expressando lances diretamente aos mineradores por meio da transferência de coinbase. Acabaram tendo mais reclamações sobre as taxas da coinbase, porque não podiam mais enviar pacotes de 0-gas.

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

Separação de Propositor-Construtor (PBS)

Após a transição do Ethereum para o Proof of Stake (PoS) após o merge, a Separation of Proposer-Builder (PBS) foi implementada para refinar ainda mais a separação de papéis 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 guardiões que garantem a disponibilidade de dados e a validade do bloco. Como um proponente pode se conectar a vários construtores para transações privadas diferentes, os construtores devem competir oferecendo pagamentos ao proponente. Essa dinâmica é ilustrada na Figura 5.

Figura 5: MEVA na Era do 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 ano passado, uma oligarquia dos 9 principais construtores manteve consistentemente >50% do mercado, apontando para um alto grau de concentração de mercado, conforme 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 da Jito

Como o MEVA canônico na Solana, Jito foi criado para lidar com a alta taxa de spam na 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 mal sucedida (aproximadamente 0,000005 SOL) não exceda o lucro esperado.

De acordo com 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 robôs de liquidação inundaram a rede com milhões de pacotes duplicados apenas para realizar algumas milhares de liquidações bem-sucedidas, resultando em uma taxa de falha superior a 99% [8].

Figura 7: Uma visão geral do MEVA da Jito na Solana.

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

O Jito tem os seguintes componentes:

Relé - atua como um proxy para receber transações e encaminhá-las tanto para a Block Engine (ou a cadeia de suprimentos MEVA) quanto para validadores.

Block Engine - ingere transações do relayer, coordena com searchers, aceita bundles, realiza simulações de bundles e encaminha as melhores transações e bundles para o validador para processamento. Notavelmente, Jito realiza um leilão de bloco parcial para inclusão de bundles em vez de um leilão de bloco completo, processando historicamente mais de 80% dos bundles dentro de 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 desativou este 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 da Solana.

Jito suporta apenas leilões de blocos parciais em vez de construção de blocos completos, provavelmente devido ao modelo de execução multi-threaded da Solana, que carece de agendamento global. Especificamente, a Figura 8 mostra threads paralelas que executam transações, cada uma mantendo sua própria fila de transações à espera de 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 (anterior à atualização 1.18.x), as transações da Solana experimentam inerentemente não-determinismo devido à oscilação 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 multi-threaded para o Cliente Solana. Note que o Estágio de Pacote do MEVA é anexado como um thread separado dentro da fila multi-threaded.

Do ponto de vista da engenharia, integrar a alimentação do motor de bloco do Jito como um thread adicional paralelo aos existentes se encaixa bem com a arquitetura multi-threaded do Solana. Embora os leilões de pacotes garantam pedidos baseados em taxas de prioridade dentro do thread do mecanismo de bloco 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 buscadores a participarem do leilão em vez de enviar spam à rede. Ao reservar espaço no bloco para pacotes, o Jito é capaz de equilibrar, promovendo leilões ordenados e mitigando os efeitos caóticos do spam de transações.

Remover o Pseudo-Mempool

A adoção generalizada do Jito tem produzido resultados positivos na mitigação do problema de spam no Solana. Pesquisas realizadas por p2p [12] e dados mostrados na Figura 9 revelam uma melhoria estatisticamente significativa na taxa de produção de blocos após a adoção do cliente Jito. Isso indica que o processamento de transações se tornou mais eficiente, graças ao mecanismo 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 bundles Jito preenchem apenas parcialmente os blocos, as transações que induzem MEV ainda podem contornar o canal de leilão Jito. Esse problema é pelo menos parcialmente evidenciado pelo Painel Dune na Figura 10 [13], que mostra que a rede ainda registra uma média de mais de 50% de transações falhadas devido a spam de bots desde 2024.

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

Em 9 de março de 2024, Jito tomou a decisão de suspender sua mempool principal. Esta decisão foi motivada pelo crescimento nas transações de memecoin e por um aumento correspondente nos ataques de sanduíche (um tipo de front-running em que 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 preferencial, inclusão e exclusão. Na verdade, evidências disso podem ser vistas na Figura 11, que ilustra o perfil de lucro horário do bot de sanduíche para o maior buscador de mempool privado (3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81) após o desligamento da mempool.

Figura 11: O lucro por hora para o Sandwich Bot com Private Mempool para o Searcher "3pe8gpNEGAYjVvMHqGG1MVeoiceDhmQBFwrHPJ2pAF81".

A decisão da Jito de fechar o mempool sublinha o forte compromisso da equipa em lidar com questões fundamentais dentro do ecossistema Solana. Além de iterar sobre MEVA ou ajustar o mecanismo de taxas de gás da Solana, Jito também ajuda a educar os protocolos sobre a mitigação de vetores de ataque através de escolhas de design de produto de UI, como a limitação dos parâmetros de deslize padrão. Quer seja através de ajustes na estrutura de taxas que tornem o envio de spam mais caro ou através da modificação dos protocolos de comunicação, a infraestrutura da Jito continuará a ser essencial para manter a saúde e estabilidade da rede Solana.

Design MEVA em Monad

Execução Diferida & Implicações sobre 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 resumindo todos os estados pós fato, o Monad desvincula 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 sobre o 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 do estado de fato, a execução pode utilizar todo o período de consenso para o próximo bloco.

Figura 12: Execução Diferida de Monad comparando com o estadiamento de Execução-Consensus do Ethereum. A Janela de Tempo Operacional também é ilustrada a partir da perspetiva de design MEV.

Definimos a Janela de Tempo Operacional como o período de tempo permitido para o MEVA no Monad completar uma proposta de construção de bloco que seja tanto viável quanto lucrativa em comparação com o método padrão de construção de bloco. Existem duas consequências imediatas do modelo de execução adiada:

1. Quando o MEVA constrói para o Nth bloco dentro da janela de tempo operacional, os validadores estão concordando simultaneamente com a lista de transações para o N-ésimo bloco enquanto tentam completar a execução para o bloco N-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 relay ou o construtor sob esta arquitetura de execução diferida. Portanto, é 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 o MEVA é extremamente limitada. Isso significa que os construtores podem não ter tempo suficiente para simular sequencialmente blocos completos de transações e bundles como normalmente fazem no Ethereum. Muitas variáveis podem afetar o tempo necessário para simulação de transações no EVM. No entanto, assumindo que simular 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 relays completarem múltiplas simulações de blocos completos para otimizar o bloco construído.

Estratégia de Construtor Probabilístico & Pesquisador

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

Os pesquisadores enfrentam 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 fluxo de pedidos privados para construtores para execuções de estratégia relativamente determinísticas. Neste ambiente relativamente probabilístico em Monad, os pesquisadores agora enfrentam um risco maior de reversões 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 espectral conceptual que ilustra 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 feixe/bloco no lado do construtor cria um espectro de incerteza em relação ao preço ou avaliaçã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 feixes submetidos. Na outra extremidade está o Modelo de Construtor Otimista [16] com verificação de bloco assíncrona. 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 garantia sujeita a punição. A abordagem de verificação probabilística ou simulação parcial proposta aqui no 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 criador de mercado em um livro de ordens onchain DEX pode pagar para pré-mover suas posições através do MEVA quando detetar um grande movimento de preço unidirecional para evitar uma seleção adversa. Esta estratégia probabilística permite-lhes agir rapidamente, mesmo sem as informações estatais mais recentes, equilibrando risco e recompensa num ambiente de negociação dinâmico.

Considerações finais

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

Monad é uma rede promissora em seus primeiros estágios, apresentando uma oportunidade única para a comunidade moldar o design ideal do MEVA. Considerando o estágio único de execução e consenso do Monad, convidamos pesquisadores, desenvolvedores e validadores a colaborar e compartilhar insights. Essa colaboração será fundamental para criar um processo de produção de blocos robusto e eficiente, permitindo que o Monad alcance seu potencial como uma rede blockchain de alta capacidade.

Aviso Legal:

1. Este artigo é reproduzido a partir de [0xapr]. Todos os direitos autorais pertencem ao autor original [APRIORI ⌘]. Se houver objeções a esta reimpressão, contacte o Gate Learnequipa, e eles vão tratar disso prontamente.
2. Aviso de Responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipe Gate Learn. A menos que seja mencionado, copiar, distribuir ou plagiar os artigos traduzidos é proibido.