BAM o no BAM 💥🤔 Siguiendo el consejo de @0xMert, el equipo escribió un blog en el que trabajaba todos los contraargumentos contra BAM. Consulta el enlace de abajo. Vamos 🧵 ⬇️ a profundizar

"BAM es un secuenciador centralizado con monopolio de construcción de bloques." Steelman: Esta crítica sostiene que BAM introduce un único secuenciador que hará toda la planificación de transacciones para Solana. Incluso si la infraestructura está distribuida, las reglas de planificación se originan en un solo sistema, que está controlado por Jito. Los interesados temen que esto socave la diversidad natural de planificadores de Solana, que podría comportarse como un secuenciador centralizado, convirtiéndose en un punto único de fallo y concentrando demasiada influencia en un solo planificador y una sola parte. BAM está diseñado para que ninguna entidad individual pueda controlar el orden de las transacciones. El sistema descentralizará su funcionamiento y gobernanza de la lógica de planificación mediante: • participación abierta: cualquier operador elegible puede participar y gestionar su propio nodo BAM. • cobertura global: Los nodos BAM se desplegarán en una red geográficamente diversa de operadores. • programación de código abierto y verificable: todo el código BAM será de código abierto y auditable mediante atestigos criptográficos. Aunque es cierto que los nodos BAM actualmente son gestionados exclusivamente por Jito, a partir del primer trimestre del 2026 la base de código será de código abierto y se incorporarán operadores independientes.

"Como validador, BAM me atan a un solo programador" Steelman: Esta crítica dice que al optar por BAM, un validador cede efectivamente el control sobre la orden de transacciones a un único planificador. En lugar de poder ejecutar o adoptar diferentes planificadores, experimentar con sus propias estrategias o cambiar entre diseños competidores, están atados a un solo sistema. Para habilitar los Mercados de Capital en Internet, Solana necesita reglas de ordenación deterministas y transparentes. La fragmentación perjudica a los usuarios. BAM hace esto posible con la construcción de bloques estandarizada y verificable que requieren las aplicaciones de alto rendimiento. Los hechos son: • BAM es estrictamente opt-in. • Los validadores pueden recurrir a clientes Agave, Jito-Solana o Firedancer • Pueden desconectarse del BAM en cualquier momento Los plugins BAM ofrecen una plataforma para la optimización e innovación de desarrolladores que beneficia a todo Solana.

"BAM monopoliza el flujo de pedidos de Solana." Steelman: Los interesados argumentan que agregar transacciones públicas en una sola tubería crea un punto de estrangulamiento central por el que pasa todo el flujo de órdenes y da ventajas a quien lo controle. Aunque inicialmente es neutral, el BAM controla el flujo de pedidos, lo que puede reforzar su posición competitiva y evitar que otras soluciones ganen terreno. BAM recoge transacciones utilizando el mecanismo estándar de TPU Solana. No hay distinción entre las "transacciones BAM" y las públicas. Los validadores reciben el mismo flujo público, solo que programado a través de una capa verificable. Los validadores pueden volver instantáneamente a su TPU nativa sin costes de cambio, manteniendo el flujo de órdenes público en lugar de fragmentado en canales privados.

"BAM introduce latencia extra vs. TPU nativo del validador." Steelman: Los interesados argumentan que una de las ventajas de rendimiento de Solana proviene de que las transacciones fluyen directamente al TPU del líder con saltos mínimos. Cualquier capa intermedia de enrutamiento, incluso una rápida, corre el riesgo de añadir latencia, jitter y nuevos puntos de fallo bajo carga, y podría debilitar la misión IBRL en comparación con la programación nativa de TPU. BAM garantiza una latencia mínima gracias a una huella global de 100+ nodos y co-ubicación estratégica, manteniendo los tiempos de ida y vuelta por debajo de 5 ms. Nuestra pila TEE está altamente ajustada usando thread pinning y aislamiento de CPU, logrando paridad de rendimiento con Agave. Con la próxima migración a DoubleZero, esperamos superar los indicadores de rendimiento bare metal.

"BAM produce menos recompensas frente a otros clientes" Steelman: Los validadores han expresado preocupaciones de que la lógica de programación de BAM podría reducir las propinas y las recompensas generales frente a otras oportunidades de blockbuilder o programación. Además, los mercados de comisiones de Plugin aún no están activos, lo que hace que el potencial alcista sea teórico mientras que la baja parece inmediata. Priorizamos la maximización de beneficios a largo plazo. Las recompensas de BAM ya son comparables a las de Jito-Agave. Las disparidades pasadas fueron impulsadas por programadores temporales y extractivos en otros lugares que están siendo obsoletos. El rendimiento futuro estará impulsado por los Plugins y ACE, desbloqueando flujos sostenibles de tarifas derivadas de la nueva actividad económica neta en lugar de juegos a corto plazo.

"Como validador, necesito dar a mis stakers el mayor rendimiento." Steelman: Los stakers suelen elegir validadores basándose estrictamente en recompensas. Incluso una pequeña disminución de las propinas o una variación en los ingresos a lo largo de una época puede hacer que la participación delegada fluya hacia otro lado. Los validadores temen que adoptar el BAM pronto pueda ponerles en desventaja competitiva si sus compañeros retrasan la adopción. Entendemos que los validadores deben maximizar el rendimiento para sí mismos y sus stakers, pero también deben considerar los efectos de segundo orden de sus acciones. El hacking de rendimientos a corto plazo (sandwiching, slot-lagging) degrada la calidad general de la ejecución y aleja la liquidez. El único camino sostenible hacia un mayor rendimiento es una actividad onchain más profunda, que solo puede ser posible con mejores aplicaciones, mayor liquidez y spreads más ajustados.

"La ejecución controlada por la aplicación (ACE) no es importante." Steelman: Los interesados argumentan que las aplicaciones de Solana ya funcionan bien bajo los mecanismos de inclusión de Tarifas Prioritarias y Consejos. Introducir ACE puede aumentar la complejidad y crear garantías de ejecución desiguales entre aplicaciones sofisticadas y desarrolladores más pequeños. Les preocupa que permitir que las aplicaciones definan la lógica de ordenación pueda llevar a que BAM privilegie a ciertos actores. Las aplicaciones sofisticadas necesitan garantías como prioridad de cancelación o prioridad de liquidación para funcionar de forma segura. Hyperliquid hace entre 10 y 15 veces el volumen de sospechosos de Solana precisamente por su conjunto de validadores autorizados que impone un orden estricto. Sin ACE, estas apps migrarán a L1 o L2 personalizadas para obtener esas garantías.

"El pedido FIFO es la lógica de ordenación de transacciones más justa" Steelman: Los interesados argumentan que el simple pedido FIFO (primero en entrar, primero en salir) es la forma más justa y neutral de programar transacciones en Solana. Refleja la prioridad temporal de los mercados tradicionales, es fácil de entender para los usuarios ("si mi tx llega primero, se ejecuta primero") y evita la dinámica de "pay-to-win" de la mayoría de las blockchains. Aunque FIFO parece más justo al procesar las transacciones en el orden en que se reciben, anima a los usuarios a hacer spam en la red para asegurar una posición favorable, lo que provoca congestión y carreras de latencia que consumen dinero. Esto se rompe cuando la demanda de la red es alta, causando retrasos impredecibles para todos los usuarios a medida que las colas se alargan. El enfoque único de FIFO no satisface las necesidades de las aplicaciones que requieren un orden específico de transacciones para funcionar de forma óptima.

"¿No son vulnerables los Entornos de Ejecución Confiable (TEEs) de BAM a ataques?" Steelman: Los TEE tienen un historial de vulnerabilidades en canales laterales, errores de firmware y riesgos en la cadena de suministro. Los interesados argumentan que depender de los TEEs para la planificación por bloques podría introducir modos de fallo correlacionados: si un exploit de hardware afecta a SEV-SNP, EL BAM como red podría verse comprometido. También argumentan que los TEEs trasladan la confianza hacia los proveedores de hardware y centros de datos. BAM funciona en AMD SEV-SNP con atestiguaciones criptográficas en centros de datos seguros y conformes (ISO 27001/SOC 2). Incluso en un peor caso de compromiso de hardware, las claves validadoras permanecen seguras y el historial de la cadena no puede reescribirse, solo se ve afectada la privacidad de orden en ese nodo específico. Los validadores verifican el "TCB medido" y pueden rechazar un firmware defectuoso mediante atestado.

@0xmert El futuro de la construcción de bloques está pasando de una programación fragmentada a un mercado transparente y verificable. BAM es la solución. ¡Miles de millones deben BAM! 💥