Mercado de Montagem de Blocos (BAM)

Insights práticos

• Hoje, os líderes da Solana têm autoridade exclusiva sobre a ordenação de transações durante seus slots, oferecendo pouca transparência sobre como os blocos são construídos. O BAM introduz uma alternativa verificável e descentralizada que torna a lógica de sequenciamento auditável.
• A rede BAM separa claramente as responsabilidades: os nodes BAM gerenciam a origem, a priorização e a filtragem das transações da Solana, enquanto os validadores BAM cuidam da execução, do consenso e do gerenciamento de estado. Essa abordagem aproxima a Solana de uma arquitetura de Separação entre Proponente e Construtor (PBS).
• O framework de plugins do BAM permite que os desenvolvedores definam uma lógica de ordenação personalizada e introduzam novas primitivas de agendamento. Isso viabiliza a Execução Controlada pelo Aplicativo (ACE), na qual os aplicativos podem impor suas próprias regras de agendamento de transações.
• A Jito se comprometeu a tornar o BAM open source no futuro e a projetá-lo com a transparência como princípio central. Isso representa uma grande melhoria em relação ao atual Block Engine da Jito, que tem código fechado e é operado por uma única parte confiável.
• Os nodes BAM serão executados em processadores AMD, compatíveis com Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) aprimorado. Graças à aceleração por hardware, o SEV-SNP adiciona uma sobrecarga de apenas 2% a 5%, rápido o suficiente para processamento em tempo real.
• O primeiro agendador implementado para os nodes BAM realizará leilões intrabloco periódicos em seus mempools, subdividindo o bloco em N slots e distribuindo igualmente as CUs entre cada leilão.
• A Execução Controlada pelo Aplicativo (ACE) pode reduzir a necessidade de rollups ou extensões de rede para impor uma lógica personalizada, ajudando a manter mais atividades na mainnet da Solana. Ela também amplia significativamente o espaço de design para novos aplicativos que aproveitam blockspace programável.
• A Jito planeja direcionar 100% das taxas de protocolo do Block Engine e do futuro sistema BAM para o Tesouro da Jito DAO. Atualmente, a Jito cobra uma taxa de 6% sobre as gorjetas, dividida igualmente entre a Jito Labs e a DAO. No segundo trimestre de 2025, a DAO recebeu 22.391,31 SOL (~US$ 4 milhões) dessas taxas por meio do Tip Router.
• O BAM se inspira no BuilderNet da Flashbots, adotando uma abordagem semelhante de construção de blocos em ambientes de execução confiáveis. Na mainnet da Ethereum, aproximadamente 40% dos blocos já são construídos em TEEs.

Introdução

O Block Assembly Marketplace (BAM) da Jito representa a reformulação mais ambiciosa do processo de construção de blocos da Solana até hoje. Após oito meses de desenvolvimento, o BAM surgiu do desejo de oferecer mais privacidade, transparência e execução determinística dentro do slot na Solana, viabilizando a próxima geração de aplicativos avançados. O resultado é um pipeline de transações reinventado que substitui o atual modelo opaco de ordenação conduzida por validadores por um sistema privado, programável e comprovadamente justo para sequenciar transações.

O BAM introduz um mempool criptografado executado dentro de Ambientes de Execução Confiáveis (TEEs), onde todas as transações permanecem confidenciais até a execução. Essa arquitetura que preserva a privacidade visa reduzir significativamente, se não eliminar, muitas das formas mais exploratórias de MEV, oferecendo aos usuários garantias de execução mais sólidas e melhores preços. Os validadores passam a oferecer uma execução de maior qualidade, enquanto desenvolvedores e searchers podem criar diretamente sobre uma nova camada programável de blockspace.

O BAM introduz a lógica de execução controlada pelo aplicativo (ACE) por meio de um sistema de plugins. Isso viabiliza casos de uso como correspondência com prioridade para makers em contratos perpétuos, atualizações de oráculo just-in-time, aplicação do tempo de vigência de ordens e outras formas de roteamento e execução personalizados. Com controle granular sobre a ordenação das transações, os desenvolvedores podem criar primitivas financeiras mais sofisticadas e confiáveis na Solana, incluindo livros de ordens com limite central, dark pools e camadas de agregação.

Com isso, o BAM aborda diretamente muitas das críticas históricas ao modelo de produção de blocos da Solana: comportamento opaco dos validadores, qualidade de execução inconsistente e proliferação de mercados paralelos por meio de mempools privados e acordos externos. Hoje, os líderes da Solana têm controle unilateral sobre a ordenação das transações durante seus slots, com pouca visibilidade sobre como os blocos finais são montados. O BAM substitui esse modelo por uma alternativa verificável e descentralizada que continua se integrando de forma eficiente ao runtime de alto desempenho da Solana.

O BAM se baseia em precedentes reais e se inspira no BuilderNet da Flashbots, adotando uma abordagem semelhante de construção de blocos em ambientes de execução confiáveis. Na mainnet da Ethereum, aproximadamente 40% dos blocos já são construídos em TEEs, enquanto na Unichain (a L2 personalizada da Uniswap) esse número chega a 100%. O BAM estende esse modelo à Solana, com a vantagem do suporte nativo à programabilidade no nível do aplicativo, execução de baixa latência e integração profunda com os clientes validadores da Jito, que hoje protegem mais de 89% do stake total entre Jito-Agave e Jito-Firedancer.

Fundamentalmente, a Jito se comprometeu a tornar o BAM open source no futuro e a projetá-lo com a transparência como princípio central. Isso representa uma grande melhoria em relação ao atual Block Engine da Jito, que tem código fechado e é operado por uma única parte confiável. O BAM gera atestados on-chain — provas assinadas criptograficamente que confirmam exatamente qual código foi executado e como as transações foram ordenadas — permitindo que qualquer observador verifique a imparcialidade da execução.

Visão geral do BAM

Em sua essência, o BAM é uma rede de sequenciamento de transações. Os nodes BAM lidam com a origem, a priorização e a filtragem das transações da Solana, enquanto os validadores BAM se concentram na execução, no consenso e no gerenciamento de estado. Essa separação de responsabilidades preserva no validador as funções essenciais para a disponibilidade da rede, ao mesmo tempo que permite maior flexibilidade e experimentação com a lógica de sequenciamento nos nodes BAM.

O próprio node BAM inclui uma unidade de processamento de transações (TPU) e um agendador de transações, operando dentro de um TEE. Ele também executa um servidor gRPC para permitir a comunicação com os validadores conectados. O cliente Jito-validator modificado conta com um executor FIFO (first-in-first-out), otimizado para concorrência e paralelismo por meio de bloqueios que consideram as contas.

Cada node BAM pode atender a vários validadores, embora cada validador se conecte a apenas um node BAM por vez. Atualmente, a Jito opera sete Block Engines. Com o BAM, a rede pretende crescer significativamente, visando de 50 a mais de 100 nodes BAM distribuídos por todas as principais regiões geográficas para aumentar a descentralização e a redundância. A comunicação entre o node BAM e o validador ocorre por meio de um stream gRPC bidirecional, e os resultados da execução são transmitidos de volta do validador ao node BAM para fornecer feedback em tempo real.

Todas as transações nos nodes BAM são criptografadas dentro de Ambientes de Execução Confiáveis (TEEs) até o momento da execução, garantindo que o fluxo de transações permaneça privado até ser executado.

Para garantir uma execução justa, a ordenação das transações é registrada de forma verificável por meio de atestados. Eles são provas criptográficas, assinadas e registradas com data e hora pelos nodes BAM, que confirmam a observação de eventos ou condições específicos. O resultado é uma trilha de auditoria imutável, permitindo que os observadores comprovem que as transações foram executadas na ordem correta.

A trilha de auditoria inclui as transações encaminhadas ao validador e seu sequenciamento. Por exemplo, as transações A, B e C foram enviadas ao validador da Helius neste slot. O sistema oferece ferramentas de monitoramento e análise em tempo real, permitindo que os usuários acompanhem suas transações desde o envio até a execução. Usuários e aplicativos poderão verificar se o validador BAM cumpriu a ordenação e saber exatamente qual código foi executado no node BAM.

Os nodes BAM ficam visíveis de forma transparente na rede, assim como os relayers atuais da Jito. Quando um validador se conecta ao BAM, ele anuncia a instância BAM por meio de suas portas TPU e TPU forward, que funcionam como pontos de entrada para receber transações.

Os usuários ainda podem enviar transações pelos clientes RPC que já utilizam. No entanto, para aumentar a segurança, eles podem enviar transações diretamente às instâncias BAM, impedindo que validadores mal-intencionados interceptem ou visualizem os pacotes de transação.

Quando uma transação entra no BAM, ela passa por um processo padrão de sanitização que inclui desduplicação, verificação de assinatura e validações de formato, blockhash, pagador da taxa, nonce e Address Lookup Tables.

Depois de validadas, as transações entram no mempool do BAM, onde participam de leilões periódicos frequentes. Após o encerramento de um leilão, as transações são enviadas aos validadores. A sequência completa de transações é assinada pelo software BAM e registrada em um banco de dados. Em seguida, os validadores transmitem de volta os resultados da execução por uma API baseada na solução proposta pelo agendador modular da Anza.

Com um ambiente de agendamento seguro e um mercado local de taxas, os validadores passam a operar sob um contrato de adesão muito mais robusto. Eles recebem uma sequência predefinida de transações que precisa ser agendada exatamente como fornecida, eliminando oportunidades de inserir ou reordenar transações para fins maliciosos.

Diversos mecanismos de fiscalização estão sendo considerados para lidar com eventuais condutas indevidas de validadores, como ataques de sandwich, com base nas evidências da trilha de auditoria. Embora ainda não tenham sido definidos, as possíveis respostas incluem:

• Remover o validador infrator da rede BAM.
• Exigir garantias dos validadores na forma de bonds, que poderiam sofrer slashing em caso de má conduta (embora isso possa elevar as barreiras de entrada para novos validadores).
• Aplicar listas negras ou cinzas para restringir ou limitar parcialmente a participação dos infratores.

Taxas

A Jito Labs e a Jito Foundation estão elaborando em conjunto uma Jito Improvement Proposal (JIP) que direcionará 100% das taxas de protocolo arrecadadas pelo Block Engine e pelo futuro sistema BAM para o Tesouro da Jito DAO. Essa proposta, que deverá ser apresentada formalmente nas próximas semanas, representa uma mudança significativa no modelo econômico da Jito e está sujeita à aprovação da DAO. Se aprovada, reforçará o papel central da DAO e dos detentores do token JTO no ecossistema da Jito.

Atualmente, o protocolo da Jito cobra uma taxa de 6% sobre as gorjetas, dividida igualmente entre a Jito Labs e a DAO. Somente no segundo trimestre de 2025, a DAO recebeu 22.391,31 SOL (~US$ 4 milhões) dessas taxas por meio do Tip Router. A outra principal fonte de receita da DAO vem das taxas do jitoSOL, que totalizaram 13.223,73 SOL (~US$ 2,38 milhões) no mesmo período.

Ambientes de Execução Confiáveis (TEEs)

Um Ambiente de Execução Confiável (TEE) é uma arquitetura respaldada por hardware e projetada para garantir a confidencialidade e a integridade tanto da computação quanto da memória. Também conhecidos como enclaves, os TEEs isolam a execução do código do sistema operacional, do kernel e do hypervisor do sistema host, normalmente por meio de separação no nível do hardware. Esse isolamento reduz significativamente a superfície de ataque, tornando extremamente difícil, embora não impossível, observar ou adulterar as operações do enclave.

Os TEEs são usados desde os anos 2000 em áreas como gerenciamento de direitos digitais, proteção de conteúdo e sistemas seguros de pagamento. Hoje, são amplamente utilizados em dispositivos de consumo e serviços de nuvem para processar dados e códigos confidenciais com segurança. Em smartphones e laptops, o Secure Enclave da Apple e o TrustZone do Android protegem dados biométricos, credenciais de pagamento e chaves de criptografia. Consoles como PlayStation e Xbox usam processadores baseados em AMD ou Pluton para impedir adulterações e pirataria. Na nuvem, provedores como Azure e Google Cloud usam AMD SEV-SNP, Intel TDX ou AWS Nitro Enclaves para isolar workloads e viabilizar computação confidencial. Carteiras de cripto como Ledger e Trezor usam elementos seguros para proteger chaves privadas, enquanto o novo celular Solana Seeker utiliza TEEs para a mesma finalidade.

Os TEEs são a abordagem padrão baseada em hardware para processar dados privados, oferecendo uma alternativa prática a métodos puramente criptográficos, como a criptografia totalmente homomórfica (FHE) e a computação multipartidária segura (MPC). Embora FHE e MPC ofereçam sólidas garantias teóricas, muitas vezes são inviáveis em ambientes reais devido à alta complexidade e à sobrecarga de desempenho.

O BAM depende de duas propriedades fundamentais dos TEEs:

Confidencialidade: o código e os dados dentro do TEE são criptografados e isolados do restante do sistema. Nem o sistema operacional, nem o hypervisor, nem qualquer software externo podem acessar ou inspecionar o que é executado no enclave.

Atestabilidade: os TEEs são compatíveis com atestados, um mecanismo que produz uma prova criptográfica da origem e do estado atual do enclave. Isso permite que terceiros verifiquem se um resultado foi produzido por um TEE genuíno executando código confiável, e não por um ambiente comprometido ou emulado.

Implementação de TEE no BAM

O BAM será executado em processadores AMD, compatíveis com Secure Encrypted Virtualization with Secure Nested Paging (SEV-SNP) aprimorado. Ao contrário de abordagens baseadas em enclaves menores, o SEV-SNP protege todo o aplicativo BAM com sobrecarga mínima de desempenho, tornando-o adequado para sistemas de transações com alto throughput e baixa latência.

Graças à aceleração por hardware, o SEV-SNP adiciona uma sobrecarga de apenas 2% a 5%, rápido o suficiente para processamento em tempo real. Ele pode atender a aplicativos de rede complexos e com estado, não apenas a computações isoladas. A tecnologia foi amplamente testada, com implantações nos principais provedores de nuvem, incluindo Google Cloud, Azure e AWS, e conta com anos de pesquisa em segurança e experiência operacional.

O SEV-SNP usado no BAM oferece várias garantias de segurança essenciais. Cada instância TEE é executada em sua própria máquina virtual isolada por hardware, com a memória criptografada em runtime para garantir um forte isolamento no nível da VM. O BAM utiliza atestados ancorados em hardware, permitindo que cada TEE comprove criptograficamente que está executando um código genuíno e não modificado. Essa cadeia de atestados é ancorada nas chaves-raiz de hardware da AMD, integradas fisicamente à CPU durante a fabricação. Além disso, as chaves TLS são geradas com o gerador interno de números aleatórios do processador, garantindo que nunca sejam expostas em memória não criptografada.

Quando um cliente se conecta ao BAM, ele recebe um certificado TLS contendo o certificado padrão de conexão, um relatório de atestado AMD SEV-SNP e uma prova criptográfica de que a chave privada TLS foi gerada dentro do TEE atestado. Essa cadeia de certificados é vinculada criptograficamente à raiz de confiança de hardware da AMD. Ela não pode ser falsificada sem acesso às chaves-raiz privadas da AMD, eliminando a necessidade de confiar em qualquer intermediário além do processo de fabricação dos chips da AMD.

Plugins

Hoje, os aplicativos na Solana só conseguem influenciar a ordenação das transações por meio de taxas de prioridade ou transações agrupadas com gorjetas associadas. Com vários sequenciadores atuando em clientes como Agave e Firedancer, não há garantia de qual lógica de ordenação será aplicada, deixando os aplicativos com controle limitado sobre como suas transações são ordenadas.

Os plugins resolvem isso.

Com o framework de plugins do BAM, os desenvolvedores podem implementar uma lógica de ordenação personalizada e introduzir novas primitivas de agendamento. Eles viabilizam a Execução Controlada pelo Aplicativo (ACE), permitindo que os aplicativos definam políticas personalizadas de agendamento de transações. Embora a ACE tenha muitas aplicações potenciais, o caso de uso mais reconhecido e discutido é priorizar cancelamentos no livro de ordens — um mecanismo que reduz a seleção adversa e permite spreads menores.

Priorização de cancelamentos dos makers no livro de ordens

Hoje, os market makers de livros de ordens on-chain na Solana operam em desvantagem. Os market makers gerenciam o risco atualizando ou cancelando constantemente cotações desatualizadas quando o preço justo muda. Quando o preço de mercado varia, eles precisam cancelar as ordens existentes antes que takers informados aproveitem a oportunidade.

Sem controle granular sobre a ordenação das transações, suas cotações ficam vulneráveis a um fluxo tóxico que explora preços desatualizados. Os market makers podem sair perdendo mesmo quando agem rapidamente, pois o leilão da Jito prioriza lances em vez de intenções. Em essência, a parte que paga mais é sequenciada primeiro.

Essa dinâmica força os market makers a ampliar seus spreads para gerenciar o risco, reduzindo a liquidez geral e resultando em preços piores para os usuários. Essas negociações tóxicas, nas quais o taker lucra com um preço desatualizado e a contraparte se arrepende da negociação quase imediatamente após sua realização, pouco acrescentam à experiência do usuário, mas aumentam substancialmente o atrito para market makers e provedores de liquidez.

Os plugins do BAM permitem aplicar políticas de "cancelar antes de executar" no nível do aplicativo. Ao oferecer aos programas controle granular sobre a ordenação das transações, os aplicativos podem optar por processar os cancelamentos dos makers antes das negociações dos takers. Essa simples mudança de política tem implicações profundas:

• Reduz a seleção adversa: os makers deixam de ser explorados rotineiramente quando o mercado se move.
• Filtra o fluxo tóxico: embora o volume geral possa cair devido à redução das negociações tóxicas, a qualidade do fluxo e da execução melhora.
• Permite spreads menores: com menos risco, os makers podem fazer cotações mais agressivas.
• Melhora a liquidez: tanto os makers profissionais quanto os traders de varejo ficam mais confiantes para fornecer cotações, resultando em maior liquidez.

Atualizações de oráculo just-in-time

Outro exemplo de plugin específico para um aplicativo é a implementação planejada pela Pyth de atualizações de oráculo just-in-time. Como principal provedora de oráculos da Solana, a Pyth mantém mais de 1.700 feeds de preços individuais. Atualizar todos eles a cada bloco seria proibitivamente caro e ineficiente em termos de blockspace.

Com o BAM, a Pyth pode atualizar feeds de preços específicos exatamente quando necessário, inserindo a atualização do oráculo imediatamente antes da transação de um usuário no mesmo bloco. Isso reduz os riscos associados a dados de oráculo desatualizados, como liquidações ineficientes e manipulação de oráculos, permitindo que aplicativos DeFi operem de forma mais confiável e competitiva.

Outros plugins

Em última análise, o BAM pretende ser uma plataforma sem necessidade de permissão na qual desenvolvedores de aplicativos possam criar, testar e implantar plugins para controlar o sequenciamento de suas transações. Muitos outros plugins devem surgir, e os nodes BAM poderão futuramente oferecer suporte a centenas de extensões personalizáveis. Embora a maioria dos aplicativos continue operando com o agendador padrão, aqueles que exigirem lógica de sequenciamento personalizada serão responsáveis por desenvolver e manter seus próprios plugins.

Além disso, os aplicativos poderão monetizar as funcionalidades dos plugins cobrando taxas, com a possibilidade de compartilhar parte da receita com detentores de tokens de governança ou validadores.

Possíveis plugins de uso geral

Os plugins não se limitam a um único aplicativo. A Jito já propôs vários exemplos de plugins de uso geral e compatíveis com diferentes aplicativos que poderiam ser desenvolvidos para o BAM:

Futuros de blockspace: permitem que usuários e aplicativos reservem ou negociem o direito de usar blockspace no futuro, oferecendo acesso e preços previsíveis mesmo durante períodos de alta demanda da rede.

Tempo em vigor (TIF): refere-se ao período durante o qual uma ordem permanece ativa antes de ser cancelada automaticamente caso não seja totalmente executada. Por exemplo, uma transação do livro de ordens pode ser válida por apenas 20 milissegundos. Uma versão rudimentar disso já é possível na Solana usando deliberadamente blockhashes mais antigos para garantir que uma transação seja válida apenas para os blocos mais recentes.

Pré-confirmações: os usuários podem ser notificados quando sua transação é encaminhada a um validador, antes de ser executada e propagada pela rede. Isso permite confirmar transações mais cedo, com algum nível de confiança.

Transações sem taxas: permitem que os usuários cubram os custos das transações usando um token SPL (por exemplo, stablecoins) em vez de SOL, abstraindo a exigência do token nativo e possibilitando pagamentos flexíveis de taxas.

Agregador de baixa latência e solicitação de cotação (RFQ): os usuários enviam suas intenções de negociação diretamente ao BAM, onde um agregador executado localmente identifica a melhor rota.

Cancelamento e substituição de transações: os usuários podem enviar transações com marcadores especiais que permitem cancelar, descartar ou substituir transações enviadas anteriormente.

Implementação

Durante a fase de lançamento, a Jito Labs operará o conjunto inicial de nodes BAM para garantir estabilidade, desempenho e segurança. Um grupo autorizado de parceiros validadores iniciais, incluindo Helius, SOL Strategies, Triton One e Figment, executará o cliente BAM, protegendo uma porcentagem elevada de um dígito do stake total da rede pouco depois do lançamento.

Paralelamente, um grupo inicial de aplicativos da Solana, incluindo Drift, Pyth e DFlow, começará a projetar e testar a primeira leva de plugins. Até o fim da fase de lançamento, espera-se que o BAM tenha validado suas principais funcionalidades e estabelecido as bases para uma participação mais ampla de operadores de nodes e validadores.

Validadores, desenvolvedores de aplicativos ou searchers interessados em participar do BAM podem preencher este formulário.

Um Comitê Consultivo do Ecossistema, composto por partes interessadas de destaque da comunidade de validadores e desenvolvedores da Solana, incluindo a Solana Foundation, prestará consultoria à Jito Labs. Esse comitê ajudará a orientar a expansão do BAM, promover a descentralização e incentivar a inovação liderada pela comunidade.

No momento, o código do BAM permanece fechado, com planos de abri-lo em breve para viabilizar o desenvolvimento de plugins por terceiros. Depois de se tornar open source, o BAM receberá contribuições da comunidade em várias áreas importantes:

• Desenvolvimento de plugins: crie plugins personalizados para ampliar os recursos do BAM.
• Algoritmos de agendamento: projete e contribua com novas estratégias de ordenação de transações adaptadas a casos de uso específicos.
• Bibliotecas de integração: desenvolva SDKs em várias linguagens de programação para simplificar a integração com o BAM.
• Ferramentas de análise: crie dashboards e sistemas de monitoramento que aproveitem os dados de atestados do BAM.
• Contribuições de pesquisa: proponha e implemente novas abordagens para mitigação de MEV e otimização do sistema.

Implicações

O BAM representa um ponto de inflexão para a Solana, com potencial para desencadear uma onda de inovação ao abordar preocupações relacionadas à exploração de MEV e ao empacotamento eficiente de blocos. O sequenciamento protegido por TEE e a estrutura de plugins do BAM podem reduzir o incentivo para que equipes de aplicações criem extensões de rede, rollups ou Ambientes Permissionados da Solana para aplicar lógica personalizada ou um espaço de bloco com regras próprias, mantendo assim mais atividades na mainnet da Solana. Além disso, com os aumentos nos limites de computação por bloco e a demanda por programas de tokens e estruturas mais eficientes que usem menos CUs (por exemplo, a crescente popularidade do Pinocchio e do p-token), haverá mais capacidade na mainnet, reduzindo ainda mais o incentivo para que desenvolvedores criem soluções personalizadas.

Os recursos de privacidade do BAM também devem reduzir significativamente a prevalência de ataques sanduíche, pois as transações permanecem ocultas até a execução, limitando a capacidade dos bots de antecipar as operações dos usuários. Isso provavelmente aumentará a eficiência das DEXs e proporcionará preços mais competitivos aos usuários. No entanto, é improvável que o BAM elimine totalmente o MEV. O MEV é, por natureza, um jogo de gato e rato, e os operadores de ataques sanduíche se adaptarão, talvez por meio de explorações sutis de plugins ou da manipulação de oráculos externos (ou seja, oráculos que não têm um plugin próprio), já que eles não fazem parte do pipeline criptografado. 

A redução do MEV por meio do BAM pode afetar negativamente a receita da Jito, repetindo o que ocorreu com o encerramento de seu mempool em 2024, que reduziu os ganhos no curto prazo, mas acabou beneficiando a rede. As melhorias do BAM podem compensar isso ao impulsionar o volume geral de transações e as taxas de plugins, aumentando a receita de longo prazo por meio de melhores índices de adoção. No entanto, a implementação exata do BAM, sua implantação em fases e sua economia apresentam possíveis riscos de centralização e questões em aberto, que exploramos nas seções seguintes. Ainda assim, esses riscos e questões em aberto são contrapostos por diversos benefícios, cada um com suas próprias implicações para a redistribuição de MEV, PBS e o desenvolvimento de um “novo” cliente.

Redistribuição de MEV

O BAM reformula radicalmente o cenário de MEV da Solana, substituindo a extração sem controle por um modelo de redistribuição mais estruturado. Nas configurações tradicionais, o MEV costuma drenar valor dos usuários por meio de frontrunning ou spam, enquanto validadores ou bots capturam valor com táticas prejudiciais, como ataques sanduíche. No entanto, o mempool do BAM criptografado por TEE oculta as transações até a execução, limitando a visibilidade necessária para o MEV negativo. Em vez disso, o valor é internalizado por meio de plugins e sequenciamento personalizado. Isso, por sua vez, permite que aplicações, desenvolvedores e buscadores capturem formas positivas de MEV que aumentam a eficiência do ecossistema (por exemplo, spreads de DeFi mais estreitos e menos spam de oráculos).

Essa redistribuição direciona os lucros de MEV de volta às partes interessadas, pois as taxas de plugins são compartilhadas entre operadores de nós BAM, validadores, stakers e a DAO da Jito. Isso pode criar fluxos de receita sustentáveis. Por exemplo, uma DEX poderia ter um plugin que otimizasse o pareamento de ordens e convertesse o potencial MEV extraído por validadores em taxas geradas pela aplicação, que poderiam ser redistribuídas aos detentores de tokens. Essa abordagem “protegida” para as atividades dos traders poderia transformar o MEV de um jogo de soma zero em um mecanismo que aprofunda a liquidez e atrai capital institucional.

No entanto, a redistribuição traz riscos. O ponto importante é que o BAM não elimina o MEV — ele o realoca. Essa realocação pode permitir que os primeiros autores de plugins, operadores de nós BAM e entidades alinhadas à Jito acumulem ganhos desproporcionais. Apesar das restrições impostas por atestados criptográficos, se surgirem vulnerabilidades em TEEs (por exemplo, ataques de canal lateral), o acesso privilegiado de buscadores poderá viabilizar novos e sutis vetores de extração, comprometendo as garantias de privacidade. Isso também abre espaço para formas “protegidas” de backrunning, nas quais buscadores podem implantar código para acrescentar transações após a de um usuário (por exemplo, para capturar arbitragem de um swap que move o preço), sem expor estratégias nem viabilizar frontrunning. Além disso, na ausência de slashing programático, invasores adaptativos podem adotar estratégias prejudiciais relacionadas aos atestados, que ocorrem após a execução e atualmente dependem da fiscalização da comunidade.

Em última análise, embora a redistribuição de MEV posicione o BAM como um catalisador para o principal objetivo da Solana (ou seja, uma NASDAQ descentralizada), seu sucesso depende da adoção de modelos de taxas equitativos e de uma segurança robusta para TEEs. Se for mal administrado, ele poderá fragmentar a rede, enfraquecer a confiança dos usuários e atrair questionamentos sobre atividades de buscadores que são “protegidas”, porém opacas.

Separação entre Proponente e Construtor (PBS)

A maioria das blockchains é projetada para que a mesma entidade proponha e construa blocos, o que lhe concede controle monopolista sobre a ordenação e a inclusão de transações nos slots designados. Isso favorece essas entidades, que podem censurar ou manipular de outras formas os fluxos de transações. Por exemplo, elas podem propor e construir blocos usando estratégias sofisticadas, embora prejudiciais, para incluir transações em uma ordem específica e, assim, maximizar o MEV.

A Separação entre Proponente e Construtor (PBS) é um padrão de design que resolve esse problema ao separar a construção da proposição de blocos. Nesse modelo, os construtores de blocos criam listas ordenadas de transações e enviam ofertas por esses blocos. Os proponentes de blocos, geralmente validadores, aceitam e confirmam o bloco com a maior oferta, redistribuindo qualquer MEV por meio de leilões ou gorjetas sem precisar executar por conta própria estratégias sofisticadas de sequenciamento. 

A PBS é implementada fora do protocolo por meio do MEV-Boost na Ethereum desde o The Merge, em 2022. O MEV-Boost é um “sidecar” executado junto ao software cliente de camada de execução e camada de consenso de um validador. Os validadores que executam o MEV-Boost podem se conectar a vários relays e aceitar blocos pré-construídos de construtores de blocos. Eles não veem o conteúdo do bloco antes de sua inclusão on-chain, pois recebem dos relays apenas os valores das recompensas e os cabeçalhos dos blocos. Vale observar que esse modelo ainda está em uma fase ativa de pesquisa, pois a PBS aguarda sua incorporação completa ao protocolo (ePBS), que pode incluir recursos como listas de inclusão para mitigar ainda mais a censura.

Com o BAM, a Solana avança em direção a um futuro semelhante à PBS, separando a construção de blocos (ou seja, o sequenciamento em nós BAM protegidos por TEE) da execução, que continua sob responsabilidade dos validadores. Isso pode democratizar formas positivas de MEV para aplicações e buscadores por meio de plugins. No entanto, também corre o risco de agravar a centralização de stake na Solana caso a economia dos plugins favoreça os participantes estabelecidos. Isso fica evidente na Ethereum, onde três construtores (ou seja, Titan Builder, BuilderNet e Beaverbuild) agora dominam mais de ~90% de todos os blocos, criando problemas de confiança nos relays e barreiras para participantes menores. 

Embora o MEV-Boost tenha introduzido a PBS na Ethereum, uma comparação mais justa neste caso é com a BuilderNet, uma rede descentralizada de construção de blocos lançada em novembro de 2024 e operada pela Flashbots, Beaverbuild e Nethermind. A BuilderNet usa TEEs para a construção privada de blocos, descentralizando o processo entre vários operadores de nós para neutralizar acordos exclusivos de fluxo de ordens e reduzir a centralização. Ela se concentra na criação de valor (ou seja, no compartilhamento de reembolsos de MEV com provedores de fluxo, como usuários, carteiras e aplicações), e não em disputas por fluxo de ordens (por exemplo, a competição por acordos privados). A BuilderNet ainda usa relays do MEV-Boost, mas eles não são estritamente necessários, o que significa que interações diretas entre construtores e proponentes podem ocorrer em TEEs. 

A implantação permissionada e em fases do BAM deve priorizar taxas equitativas e plugins de código aberto para mitigar essas armadilhas da Ethereum, especialmente devido às suas dependências de hardware (ou seja, TEEs em comparação com os relays de software da Ethereum), que introduzem aspectos de dependência de fornecedor e custos de manutenção. A Solana espera evitar as disputas por fluxo de ordens e avançar diretamente para um sistema semelhante à BuilderNet, com foco na criação de valor. 

Em última análise, essa mudança na construção e proposição de blocos reduz a função dos validadores, transferindo a complexidade do sequenciamento, mas potencialmente diminuindo sua autonomia e receita caso as taxas não sejam amplamente compartilhadas. Exploramos isso com mais detalhes na seção intitulada A Função Reduzida dos Validadores.

Acima: comparação entre a PBS da Ethereum e o BAM da Solana

Surge um “Novo” Cliente

O cliente Jito-Agave espelha de perto a base de código principal do Agave, diferenciando-se principalmente pela adição de recursos de MEV. O modelo “Agave mais MEV” da Jito permitiu que seu cliente se integrasse sem dificuldades ao ecossistema de validadores existente da Solana, aumentando as recompensas e minimizando as mudanças na arquitetura principal. Como resultado, no momento da redação, o cliente Jito-Agave lidera a rede com uma participação de 79% na adoção por validadores. Assim, os validadores podem contar com a lógica fundamental do Agave e, ao mesmo tempo, aproveitar os fluxos de receita adicionais da Jito.

O BAM representa um afastamento da abordagem anterior da Jito de espelhar de perto o Agave. A introdução de uma rede dedicada de nós BAM estabelece uma nova camada de infraestrutura. Essa evolução transforma a Jito de um simples “Agave aprimorado” em um cliente mais distinto, com seu próprio ecossistema programável para incorporar lógica específica de aplicações.

Essa divergência fica evidente nas próximas vinculações de scheduler do Agave, anunciadas pela Anza em maio. Implementações personalizadas de schedulers estão se tornando cada vez mais comuns à medida que o MEV amadurece na Solana. Embora schedulers personalizados possam aumentar a receita de seus operadores, as implementações atuais têm várias desvantagens, incluindo a necessidade de executar um binário de uma versão diferente do validador, a dependência de código fechado e possíveis preocupações com a disponibilidade. 

As próximas vinculações de scheduler da Anza introduzem modularidade ao permitir que validadores se conectem a serviços externos de construção de blocos sem alterar o binário principal do validador, viabilizando o suporte a schedulers personalizados. Esse design promove transparência, segurança e operações de DevOps mais simples. No entanto, o BAM elimina a necessidade de os usuários da Jito utilizarem essas vinculações, pois o sequenciamento é processado em uma etapa anterior pelo scheduler do nó BAM. Isso contorna as vinculações de scheduler planejadas para o Agave, o que pode simplificar as operações, mas levanta dúvidas sobre uma possível fragmentação futura do ecossistema devido à divergência em relação aos esforços de padronização da Anza (por exemplo, ao complicar integrações com o Firedancer).

A Jito, porém, posiciona o BAM como parte de um cliente de validador unificado. Os validadores do BAM executarão uma versão atualizada do cliente Agave que integra o scheduler do BAM e aceita apenas transações de nós BAM em ordem FIFO. Esse design evita a fragmentação de clientes e, ao mesmo tempo, aumenta a resiliência do sistema. A Jito planeja lançar seu cliente compatível com o BAM antes da implantação do scheduler modular da Anza. Essa iniciativa destaca o duplo impacto do BAM: ele promove a inovação e aprimora a infraestrutura de MEV da Solana, mas também corre o risco de consolidar ainda mais a posição da Jito como cliente de validador dominante.

Também é possível que o BAM use essas vinculações. Se o BAM operar dentro do scheduler modular, o suporte ao Firedancer se tornará trivial e surgirá uma nova questão: a Jito realmente precisa de um cliente de validador? Só o tempo dirá, enquanto aguardamos a implementação do código aberto e a implantação do BAM.

Questões em Aberto

A Função Reduzida dos Validadores

O design do BAM altera radicalmente o cenário de validadores da Solana ao transferir o sequenciamento de transações para uma rede separada de nós BAM protegidos por TEE. Isso deixa os validadores responsáveis principalmente pela execução, pelo consenso e pelo gerenciamento de estado. Essa separação beneficia as aplicações, pois permite sequenciamento personalizado e possibilidades de compartilhamento de receita com detentores de tokens. Ela também beneficia os usuários ao reduzir o MEV negativo e oferecer preços mais favoráveis. No entanto, levanta dúvidas sobre a redução da autonomia e dos incentivos econômicos dos validadores.

Ao produzir blocos como líder, os validadores atualmente têm total liberdade sobre a ordenação das transações, podendo executar schedulers personalizados para otimizar seus blocos como considerarem adequado. O BAM retira essa responsabilidade dos validadores. Agora, os validadores recebem transações pré-sequenciadas para executar em ordem FIFO estrita, perdendo sua autonomia sobre a construção de blocos. No extremo desse cenário, se todas as transações passarem pelo BAM, os validadores se tornarão meros “carimbadores”, o que coloca em dúvida a própria necessidade de validadores descentralizados. 

No entanto, existem fatores compensatórios. Em especial, as taxas de plugins oferecem novos fluxos de receita compartilhados com validadores e stakers. O cliente unificado e os fallbacks automatizados do BAM alinham o interesse próprio à integridade da rede, aumentando a resiliência geral. A implantação opcional e em fases também preserva a liberdade de escolha, e a abertura do código no longo prazo permite que os validadores participem do desenvolvimento do BAM, promovendo melhorias conduzidas pela comunidade e preservando aspectos de sua autonomia.  Os validadores também poderão propor melhorias ao scheduler do BAM, o que pode abrir caminho para a captura de taxas provenientes de volumes maiores. Além disso, a ideia de validadores como meros carimbadores provavelmente é exagerada, pois eles ainda desempenham uma função essencial no consenso e na escolha de forks. A verdadeira questão é: quanta autonomia os validadores realmente perderão? O BAM poderia, na verdade, permitir que os validadores se concentrassem mais em disponibilidade e integridade de estado?

Várias questões permanecem em aberto:

• Como os validadores competirão para além de hardware e disponibilidade se os nós BAM cuidarem do sequenciamento e da extração de MEV? 
• Em um cenário de alta adoção, o foco exclusivo dos validadores na execução reduzirá a descentralização geral da Solana? Em caso afirmativo, quais métricas poderiam medir essa redução?
• Se o BAM levar os validadores a buscar meios mais nocivos de obter receita, quais salvaguardas, além dos atestados, poderão impedir isso sem reduzir ainda mais os incentivos?
• Vulnerabilidades em TEEs ou explorações de plugins poderiam fazer com que validadores fossem penalizados injustamente? 
• Com base na experiência da Ethereum com a PBS, o que a Solana pode fazer para neutralizar a redução da autonomia dos validadores?

Operadores de Nós Mal-intencionados

A arquitetura do BAM introduz novas premissas de confiança relacionadas aos validadores. Ou seja, pressupõe-se que os validadores não agirão de forma mal-intencionada ao interagir com nós BAM, por exemplo, adulterando transações pré-sequenciadas ou vazando dados. No lançamento, o BAM dependerá de um conjunto permissionado de operadores devido às limitações das TEEs. Esse conjunto permissionado será encarregado de executar um cliente Jito-Solana atualizado e processar fielmente as transações encaminhadas. Esses validadores precisam confiar que os nós BAM não manipularão o tráfego de entrada, criando uma confiança em duas camadas (ou seja, nós BAM antes da TEE e validadores depois da TEE), o que aumenta o risco em uma configuração permissionada. A pergunta essencial é: o que impede os operadores de nós BAM de examinar as transações antes que elas cheguem à TEE? A resposta é a criptografia QUIC para nós verificados — eles incorporarão o atestado ao certificado QUIC. Outra forma de verificar se os nós BAM são honestos é comparar seus hashes com o repositório de código aberto do BAM para conferir se determinado nó BAM está executando o software que afirma executar. Supondo que ninguém tenha comprometido a TEE, os certificados QUIC da TPU serão gerados dentro da TEE. Assim, todo o tráfego de entrada e saída será criptografado.

No entanto, a censura e a manipulação seletiva de pacotes de transações nos pontos de entrada e saída da rede são preocupações importantes. Operadores mal-intencionados mantêm capacidades significativas de censura, apesar de não conseguirem visualizar os detalhes criptografados das transações. Eles podem identificar tipos de protocolo por meio de assinaturas TLS, filtrar com base nos endpoints de conexão, realizar análises temporais para identificar determinados padrões e bloquear todos os dados criptografados que correspondam a certas características. Portanto, o operador mal-intencionado pode não conhecer as transações exatas que estão sendo transmitidas, mas ainda pode descartar pacotes com base em metadados e determinados padrões de tráfego. Para mitigar isso, é possível obter mais transparência incorporando os recursos de filtragem de pacotes e registro de timestamps da DoubleZero. Em última análise, mitigar ataques de censura à rede é uma justificativa válida para uma implantação permissionada.

Também há novas premissas de confiança relacionadas ao acesso físico, que quase sempre representa uma falha de segurança, e as TEEs não são exceção. Embora as TEEs ofereçam fortes garantias de segurança, elas ainda podem ser comprometidas se um invasor obtiver acesso físico ao servidor. Parcerias exclusivas com provedores em conformidade com a SOC 2 ajudarão a mitigar esse risco, garantindo uma segurança robusta e em camadas no nível do data center.

Várias questões permanecem em aberto:

• Se um operador mal-intencionado censurar pacotes ou vazar dados, como as regras serão aplicadas?
• Durante a fase permissionada, como a seleção de operadores evitará conluios e quais métricas poderão ser usadas para medir o avanço rumo à descentralização? 

Componibilidade e Interação entre Plugins

Uma das questões em aberto mais importantes para o BAM é como os plugins interagirão entre si na prática. Uma única transação pode depender simultaneamente de vários plugins, por exemplo, usando um plugin de oráculo para atualizações de preço just-in-time, um plugin de DEX para determinar as rotas ideais de swap e um plugin de token para lidar com comportamentos específicos de tokens SPL. É essencial garantir que esses componentes funcionem em conjunto de maneira previsível e segura.

Os plugins talvez precisem buscar dados externos para funcionar de modo eficaz. No entanto, isso cria uma possível superfície de ataque, pois plugins mal-intencionados podem abusar de chamadas externas para vazar informações confidenciais das transações. Definir limites rigorosos para o que os plugins podem acessar e compartilhar é essencial para manter a confiança no sistema.

Outra camada de complexidade vem da interação entre a lógica dos plugins no nível da aplicação e os mecanismos de taxas da Solana. Como a ordem de execução dos plugins, as gorjetas da Jito e as taxas de prioridade interagem quando vários plugins competem para influenciar a construção de blocos? Essa dinâmica econômica precisa ser claramente definida e aplicada com transparência para evitar manipulações ou abusos não intencionais.

Para gerenciar esses riscos, espera-se que a implantação dos plugins do BAM comece em um ambiente permissionado. Isso permite experimentar e auditar o comportamento dos plugins nos estágios iniciais antes de avançar gradualmente para um modelo sem necessidade de permissão.

Confiança e Responsabilidade em TEEs

A dependência de TEEs introduz novas premissas de confiança, pois utiliza um enclave de hardware especial em vez de criar um sistema trustless para garantir computação verificável. A dependência de um único fornecedor de hardware, como Intel ou AMD, introduz riscos de monocultura: um recall de firmware ou uma exploração pode interromper o BAM e possivelmente causar indisponibilidade em toda a rede, dependendo de seu nível de adoção. Se essas vulnerabilidades não puderem ser corrigidas com atualizações de firmware, microcódigo ou BIOS, a substituição do hardware levará tempo e imporá despesas de capital recorrentes aos operadores de nós BAM, agravando ainda mais o impacto de possíveis períodos de indisponibilidade. 

Essas preocupações se baseiam em vulnerabilidades históricas que demonstraram que TEEs podem falhar e expor dados criptografados. Por exemplo, as Software Guard Extensions (SGX) da Intel foram afetadas por diversos problemas que impactaram blockchains. Em agosto de 2022, a Secret Network ficou vulnerável às falhas xAPIC e MMIO. Juntas, essas vulnerabilidades podiam ser usadas para extrair a seed de consenso — uma chave mestra de descriptografia para transações privadas executadas na rede. 

Diversos outros problemas acabaram levando a Intel a descontinuar o SGX nos processadores Intel Core de 11ª e 12ª gerações. O Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) da AMD também tem várias vulnerabilidades divulgadas. Em especial, em fevereiro, foi divulgada a CVE-2024-56161, uma vulnerabilidade que permitia a injeção de microcódigo mal-intencionado com acesso de administrador. 

As atualizações para mitigar vulnerabilidades nem sempre são retrocompatíveis e podem exigir upgrades físicos. Por exemplo, a divulgação da CVE02020-12967 e da CVE-2021-26311 revelou a possibilidade de execução arbitrária de código em máquinas virtuais convidadas executadas em máquinas AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), a implementação de TEE da geração anterior da empresa. A AMD não lançou um firmware atualizado para corrigir essas vulnerabilidades e forneceu uma mitigação no recurso SEV-SNP, compatível apenas com processadores AMD EPYC de 3ª geração (ou seja, “Milan”). 

A infraestrutura de TEE do BAM é baseada na arquitetura SEV-SNP de última geração, que inclui as proteções em nível de hardware necessárias para evitar essas explorações conhecidas. Também vale observar que, caso uma vulnerabilidade zero-day seja descoberta, a rede poderá continuar operando, pois os Jito-Validators podem voltar automaticamente para sua própria TPU ao serem desconectados de um nó BAM. Esse mecanismo de failover garante que os validadores continuem operando enquanto as correções de segurança são aplicadas.

Várias questões permanecem em aberto:

• Como a dependência do BAM em fornecedores de hardware afeta a confiança de longo prazo, considerando as explorações anteriores? Alternativas como os Ambientes de Execução Zero Trust (ZTEEs) podem ser usadas para reduzir essa dependência?
• Quem será responsabilizado pelas perdas financeiras se dados de transações privadas vazarem de uma TEE comprometida?
• Como a confiança seria restaurada se ocorressem falhas em TEEs? Seria possível oferecer uma alternativa?

Conclusão

Em última análise, os validadores têm liberdade para executar o software que escolherem. Como empresas orientadas ao lucro que operam em um mercado altamente competitivo, suas decisões são influenciadas pelos possíveis retornos para si próprios e para seus delegadores, que podem transferir seu stake para onde os rendimentos forem maiores. A ampla adoção do Jito-client reflete essa dinâmica, e seu sucesso se deve, em grande parte, à capacidade de gerar receita adicional tanto para operadores quanto para delegadores. A adoção do BAM dependerá de uma dinâmica semelhante. Se executar o BAM for consistentemente mais lucrativo do que manter o status quo, os validadores irão adotá-lo. Caso contrário, poderão hesitar em fazer a mudança, mesmo que o BAM consiga oferecer benefícios substanciais a outras partes interessadas.

Como o BAM foi anunciado há pouco tempo, muitas dúvidas sobre seu design e sua operação ainda não foram respondidas. Aguardamos mais detalhes, documentação e discussões com a comunidade nos próximos meses sobre esse desenvolvimento tão promissor.

Recursos adicionais

• Apresentando o BAM: o futuro da construção de blocos na Solana - Jito
• Série do BAM no quadro branco - Jito Learn
• Jito BAM e o futuro da Solana - 0xResearch