BAM ou não BAM 💥🤔 Seguindo o conselho de @0xMert, a equipe escreveu um blog com todos os contra-argumentos contra o BAM. Consulte o link abaixo. Vamos mergulhar nisso 🧵 ⬇️

"O BAM é um sequenciador centralizado com monopólio de construção de blocos." Steelman: Esta crítica argumenta que o BAM introduz um único sequenciador que fará todo o escalonamento de transações para Solana. Mesmo que a infraestrutura seja distribuída, as regras de agendamento se originam de um único sistema, que é controlado pelo Jito. As partes interessadas temem que isso prejudique a diversidade natural de agendadores de Solana, que pode se comportar como um sequenciador centralizado, tornando-se um único ponto de falha e concentrando influência demais em um agendador e uma parte. O BAM foi projetado para que nenhuma entidade isolada possa controlar a ordem das transações. O sistema descentralizará sua operação e governança da lógica de agendamento por meio de: • participação aberta: qualquer operador elegível pode participar e administrar seu próprio BAM Node. • cobertura global: Os Nós BAM serão implantados em uma rede geograficamente diversificada de operadores. • escalonamento de código aberto e verificável: todo o código BAM será de código aberto e passará a ser auditado por meio de atestados criptográficos. Embora seja verdade que os Nós BAM atualmente são operados exclusivamente pela Jito, a partir do primeiro trimestre de 2026 a base de código será aberta e operadores independentes serão incorporados.

"Como validador, BAM me amarra a apenas um agendador" Steelman: Esta crítica diz que, ao optar pelo BAM, um validador efetivamente entrega o controle sobre a ordem de transações para um único agendador. Em vez de poderem rodar ou adotar diferentes escalonadores, experimentar suas próprias estratégias ou alternar entre designs concorrentes, eles estão presos a um único sistema. Para viabilizar os Mercados de Capital da Internet, a Solana precisa de regras de ordenação determinísticas e transparentes. A fragmentação prejudica os usuários. O BAM torna isso possível com a construção de blocos padronizada e verificável exigida por aplicativos de alto desempenho. Os fatos são: • O BAM é estritamente opt-in. • Validadores podem recorrer a clientes Agave, Jito-Solana ou Firedancer • Eles podem se desconectar do BAM a qualquer momento Os plugins BAM oferecem uma plataforma para otimização e inovação para desenvolvedores que beneficia toda a Solana.

"BAM monopoliza o fluxo de pedidos da Solana." Steelman: Os interessados argumentam que agregar transações públicas em um único pipeline cria um ponto de trânsito central pelo qual todo fluxo de ordens passa e dá vantagens a quem o controla. Mesmo que inicialmente neutro, o BAM controla o fluxo de ordens, o que pode reforçar sua posição competitiva e impedir que outras soluções ganhem tração. O BAM coleta transações usando o mecanismo padrão de TPU Solana. Não há distinção entre "transações BAM" e transações públicas. Validadores recebem o mesmo fluxo público, só que agendado por uma camada verificável. Validadores podem reverter instantaneamente para sua TPU nativa sem custos de comutação, mantendo o fluxo de ordens público em vez de fragmentado em canais privados.

"BAM introduz latência extra vs. TPU nativa do validador." Steelman: Os stakeholders argumentam que uma das vantagens de desempenho da Solana vem das transações que fluem diretamente para a TPU do líder com saltos mínimos. Qualquer camada intermediária de roteamento, mesmo rápida, corre o risco de adicionar latência, jitter e novos pontos de falha sob carga, e pode enfraquecer a missão do IBRL em comparação com o escalonamento nativo da TPU. O BAM garante latência mínima por meio de uma presença global de 100+ nós e co-localização estratégica, mantendo os tempos de ida e volta abaixo de 5ms. Nossa pilha TEE é altamente ajustada usando thread pinning e isolamento de CPU, alcançando paridade de desempenho com o Agave. Com a próxima migração para o DoubleZero, esperamos superar os parâmetros de desempenho do bare metal.

"O BAM produz menos recompensas comparado a outros clientes" Steelman: Validadores expressaram preocupações de que a lógica de agendamento do BAM possa reduzir gorjetas e recompensas gerais em comparação com outras oportunidades de blockbuilder ou agendamento. Além disso, os mercados de taxas de Plugin ainda não estão ativos, tornando o potencial de alta teórico, enquanto a queda parece imediata. Priorizamos a maximização do lucro a longo prazo. As recompensas do BAM já são comparáveis às do Jito-Agave. Disparidades passadas foram impulsionadas por agendadores temporários e extrativos em outros lugares que estão sendo obsoletos. O rendimento futuro será impulsionado por Plugins e ACE, desbloqueando fluxos sustentáveis de taxas a partir de nova atividade econômica líquida, em vez de jogos de curto prazo.

"Como validador, preciso dar aos meus stakers o maior rendimento possível." Steelman: Stakers frequentemente escolhem validadores com base estritamente em recompensas. Mesmo uma pequena queda nas gorjetas ou variação nos ganhos ao longo de uma época pode fazer com que a participação delegada flua para outros lugares. Os validadores temem que adotar o BAM cedo possa colocá-los em desvantagem competitiva caso os pares atrasem a adoção. Entendemos que os validadores devem maximizar o rendimento para si mesmos e seus stakers, mas também devem considerar os efeitos de segunda ordem de suas ações. O hacking de rendimento de curto prazo (sandwiching, slot-lagging) degrada a qualidade geral da execução e afasta a liquidez. O único caminho sustentável para um rendimento mais alto é uma atividade onchain mais profunda, que só pode ser viabilizada por aplicações melhores, maior liquidez e spreads mais apertados.

"Execução Controlada por Aplicação (ACE) não é importante." Steelman: Os interessados argumentam que as aplicações Solana já funcionam bem sob os mecanismos de inclusão de Taxas Prioritárias e Gorjetas. A introdução do ACE pode aumentar a complexidade e criar garantias de execução desigual entre aplicativos sofisticados e desenvolvedores menores. Eles temem que permitir que aplicações definam lógica de ordenação possa levar ao BAM privilegiando certos atores. Aplicativos sofisticados precisam de garantias como prioridade de cancelamento ou prioridade de liquidação para funcionar com segurança. Hyperliquid faz de 10 a 15 vezes o volume de perpetradores do Solana, justamente por causa do seu conjunto de validadores autorizados que impõe ordens rigorosas. Sem o ACE, esses apps migram para L1s ou L2s personalizados para garantir essas garantias.

"A ordenação FIFO é a lógica de ordenação de transações mais justa" Steelman: Os interessados argumentam que o simples pedido FIFO (primeiro a entrar, primeiro a sair) é a forma mais justa e neutra de agendar transações em Solana. Ele reflete a prioridade de tempo dos mercados tradicionais, é fácil de entender para os usuários ("se meu certificado chegar primeiro, ele executa primeiro") e evita a dinâmica "pay-to-win" da maioria das blockchains. Embora o FIFO pareça mais justo ao processar as transações na ordem em que são recebidas, ele incentiva os usuários a spammarem a rede para garantir uma posição favorável, levando a congestionamentos e corridas de latência que queimam dinheiro. Isso quebra quando a demanda da rede é alta, causando atrasos imprevisíveis para todos os usuários à medida que as filas se alongam. A abordagem única do FIFO não atende às necessidades de aplicativos que exigem ordens específicas de transações para funcionar de forma ideal.

"Os Ambientes de Execução Confiável (TEEs) do BAM não são vulneráveis a ataques?" Steelman: Os TEEs têm histórico de vulnerabilidades em canais laterais, bugs de firmware e riscos na cadeia de suprimentos. Os interessados argumentam que depender dos TEEs para o escalonamento de blocos pode introduzir modos de falha correlacionados: se um exploit de hardware afetar o SEV-SNP, O BAM como rede pode ser comprometido. Eles também argumentam que os TEEs transferem a confiança para fornecedores de hardware e provedores de data centers. O BAM roda em AMD SEV-SNP com atestados criptográficos em data centers seguros e compatíveis (ISO 27001/SOC 2). Mesmo em um comprometimento de hardware no pior dos casos, as chaves validadoras permanecem seguras e o histórico da cadeia não pode ser reescrito, apenas a privacidade de ordenação naquele nó específico é afetada. Validadores verificam o "TCB medido" e podem rejeitar firmware ruim via atestado.

@0xmert O futuro da construção de blocos está passando de uma programação fragmentada para um mercado transparente e verificável. BAM é a solução. Bilhões têm que BAM! 💥