𝗧𝗼 𝗕𝗔𝗠 𝗼𝗿 𝗻𝗼𝘁 𝘁𝗼 𝗕𝗔𝗠 💥🤔 Seguindo o conselho do @0xMert, a equipe escreveu um blog refutando cada contra-argumento contra o BAM. Consulte o link abaixo. Vamos mergulhar nisso 🧵 ⬇️

"𝗕𝗔𝗠 𝗲́ 𝘂𝗺 𝘀𝗲𝗾𝘂𝗲𝗻𝗰𝗲𝗿 𝗰𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗮𝗱𝗼 𝗰𝗼𝗺 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝗼 𝗱𝗲 𝗯𝗹𝗼𝗰𝗸-𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Esta crítica argumenta que o BAM introduz um único sequencer que fará toda a programação de transações para a Solana. Mesmo que a infraestrutura seja distribuída, as regras de programação originam-se de um único sistema, que é controlado pela Jito. Os stakeholders temem que isso comprometa a diversidade natural de programadores da Solana, transformando-a em um sequencer centralizado, tornando-se um único ponto de falha e concentrando influência demais em um único programador e uma única parte. O BAM é projetado para que nenhuma entidade única possa controlar a ordenação das transações. O sistema descentralizará sua operação e governança da lógica de programação através de: • 𝗼𝗽𝗲𝗻 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗶𝗼𝗻: qualquer operador elegível pode participar e executar seu próprio Nó BAM. • 𝗴𝗹𝗼𝗯𝗮𝗹 𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲: os Nós BAM serão implantados em uma rede de operadores geograficamente diversificada. • 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲, 𝘃𝗲𝗿𝗶𝗳𝗶𝗮𝗯𝗹𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴: todo o código do BAM será de código aberto e auditável através de atestações criptográficas. Embora seja verdade que os Nós BAM são atualmente executados exclusivamente pela Jito, a partir do Q1 '26 a base de código será disponibilizada como código aberto e operadores independentes serão integrados.

“𝗖𝗼𝗺𝗼 𝗮 𝘂𝗺 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿, 𝗕𝗔𝗠 𝗺𝗲 𝘁𝗶𝗲 𝗮 𝘂𝗺 𝘀𝗼 𝗽𝗹𝗮𝗻𝗲𝗮𝗱𝗼𝗿” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Esta crítica diz que ao optar pelo BAM, um validador efetivamente entrega o controle sobre a ordenação das transações a um único planejador. Em vez de poder executar ou adotar diferentes planejadores, experimentar suas próprias estratégias ou alternar entre designs concorrentes, eles estão vinculados a um único sistema. Para permitir 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 opcional. • Os validadores podem voltar a usar 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 de desenvolvedores que beneficia toda a Solana.

"𝗕𝗔𝗠 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝘇𝗲𝘀 𝗦𝗼𝗹𝗮𝗻𝗮 𝗼𝗿𝗱𝗲𝗿𝗳𝗹𝗼𝘄." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Os intervenientes argumentam que agregar transações públicas em um único pipeline cria um ponto de estrangulamento central pelo qual todo o fluxo de ordens passa e dá vantagens a quem o controla. Mesmo que seja neutro inicialmente, 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 TPU do Solana. Não há distinção entre "transações BAM" e públicas. Os validadores recebem o mesmo fluxo público, apenas agendado através de uma camada verificável. Os validadores podem reverter instantaneamente para seu TPU nativo sem custos de troca, mantendo o fluxo de ordens público em vez de fragmentado em canais privados.

“𝗕𝗔𝗠 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲 𝗲𝘅𝘁𝗿𝗮 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝘃𝘀. 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿’𝘀 𝗻𝗮𝘁𝗶𝘃𝗲 𝗧𝗣𝗨.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Os intervenientes argumentam que uma das vantagens de desempenho da Solana vem do fluxo de transações diretamente para o TPU do líder com mínimas paradas. Qualquer camada de roteamento intermediária, mesmo uma 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 agendamento nativo do TPU. A BAM garante latência mínima através de uma presença global de mais 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 fixação de threads e isolamento de CPU, alcançando paridade de desempenho com a Agave. Com a migração iminente para o DoubleZero, esperamos superar os benchmarks de desempenho de bare metal.

“𝗕𝗔𝗠 𝗽𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗹𝗲𝘀𝘀 𝗿𝗲𝘄𝗮𝗿𝗱𝘀 𝘃𝘀. 𝗼𝘁𝗵𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁𝘀” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Os validadores expressaram preocupações de que a lógica de agendamento da BAM pode reduzir as gorjetas e as recompensas gerais em comparação com outros construtores de blocos ou oportunidades de agendamento. Além disso, os mercados de taxas de Plugin ainda não estão ativos, tornando o potencial teórico enquanto o lado negativo parece imediato. Priorizamos a maximização do lucro a longo prazo. As recompensas da BAM já são comparáveis às da Jito-Agave. As disparidades passadas foram impulsionadas por agendadores temporários e extrativos em outros lugares que estão sendo descontinuados. O rendimento futuro será impulsionado por Plugins e ACE, desbloqueando fluxos de taxas sustentáveis a partir de novas atividades econômicas em vez de jogos de curto prazo.

“𝗖𝗼𝗺𝗼 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿, 𝗲𝘂 𝗽𝗿𝗲𝗰𝗶𝘀𝗼 𝗱𝗮𝗿 𝗮𝗼𝘀 𝗺𝗲𝘀 𝘀𝘁𝗮𝗸𝗲𝗿𝘀 𝗼 𝗺𝗮𝗶𝗼𝗿 𝗿𝗲𝗻𝗱𝗶𝗺𝗲𝗻𝘁𝗼.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Os stakers muitas vezes escolhem validadores com base estritamente nas recompensas. Mesmo uma pequena diminuição nas gorjetas ou variação nos ganhos ao longo de um único epoch pode fazer com que o stake delegado flua para outro lugar. Os validadores temem que adotar o BAM cedo possa colocá-los em desvantagem competitiva se os pares atrasarem a adoção. Entendemos que os validadores devem maximizar o rendimento para si mesmos e para seus stakers, mas também devem considerar os efeitos de segunda ordem de suas ações. A manipulação de rendimento a 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 possibilitada por melhores aplicações, liquidez mais profunda e spreads mais apertados.

"𝗔𝗽𝗽𝗹𝗶𝗰𝗮𝘁𝗶𝗼𝗻-𝗖𝗼𝗻𝘁𝗿𝗼𝗹𝗹𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 (𝗔𝗖𝗘) 𝗻𝗼 𝗲́ 𝗻𝗼𝘁 𝗶𝗺𝗽𝗼𝗿𝘁𝗮𝗻𝘁." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Os stakeholders argumentam que as aplicações Solana já funcionam bem sob os mecanismos de inclusão de Taxas de Prioridade e Dicas. A introdução do ACE pode aumentar a complexidade e criar garantias de execução desiguais entre aplicações sofisticadas e desenvolvedores menores. Eles se preocupam que permitir que as aplicações definam a lógica de ordenação possa levar a um privilégio de BAM para certos atores. Aplicações sofisticadas precisam de garantias como prioridade de cancelamento ou prioridade de liquidação para funcionar com segurança. A Hyperliquid realiza de 10 a 15 vezes o volume dos perps da Solana especificamente por causa do seu conjunto de validadores com permissão que impõe uma ordenação rigorosa. Sem o ACE, essas aplicações migrarão para L1s ou L2s personalizados para obter essas garantias.

“𝗙𝗜𝗙𝗢 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗳𝗮𝗶𝗿𝗲𝘀𝘁 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗹𝗼𝗴𝗶𝗰” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Os interessados argumentam que a simples ordenação FIFO (primeiro a entrar, primeiro a sair) é a forma mais justa e neutra de agendar transações na Solana. Reflete a prioridade temporal dos mercados tradicionais, é fácil de entender para os usuários (“se a minha tx chega primeiro, ela é executada primeiro”) e evita a dinâmica de “pagar para ganhar” da maioria das blockchains. Embora o FIFO pareça ser o mais justo ao processar transações na ordem em que são recebidas, ele incentiva os usuários a sobrecarregar a rede para garantir uma posição favorável, levando a congestionamentos e corridas de latência que queimam dinheiro. Isso se desmorona quando a demanda da rede é alta, causando atrasos imprevisíveis para todos os usuários à medida que as filas se alongam. A abordagem de tamanho único do FIFO falha em atender às necessidades de aplicativos que requerem uma ordenação específica de transações para funcionar de forma otimizada.

"𝗔𝗿𝗲𝗻'𝘁 𝗕𝗔𝗠'𝘀 𝗧𝗿𝘂𝘀𝘁𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 (𝗧𝗘𝗘𝘀) 𝘃𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗹𝗲 𝘁𝗼 𝗮𝘁𝘁𝗮𝗰𝗸𝘀?" 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Os TEEs têm um histórico de vulnerabilidades de canal lateral, bugs de firmware e riscos na cadeia de suprimentos. As partes interessadas argumentam que confiar nos TEEs para o agendamento de blocos poderia introduzir modos de falha correlacionados: se uma exploração de hardware afetar o SEV-SNP, o BAM como rede poderia ser comprometido. Eles também argumentam que os TEEs transferem a confiança para os fornecedores de hardware e provedores de data centers. O BAM opera com AMD SEV-SNP com atestações criptográficas em data centers seguros e em conformidade (ISO 27001/SOC 2). Mesmo em um comprometimento de hardware no pior cenário, as chaves dos validadores permanecem seguras e a história da cadeia não pode ser reescrita, apenas a privacidade da ordenação naquele nó específico é afetada. Os validadores verificam o "TCB medido" e podem rejeitar firmware ruim por meio de atestação.

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