𝗧𝗼 𝗕𝗔𝗠 𝗼𝗿 𝗻𝗼𝘁 𝘁𝗼 𝗕𝗔𝗠 💥🤔 Siguiendo el consejo de @0xMert, el equipo escribió un blog refutando cada contraargumento en contra de BAM. Consulta el enlace a continuación. Vamos a profundizar en ello 🧵 ⬇️

"𝗕𝗔𝗠 𝗲𝘀 𝘂𝗻 𝘀𝗲𝗾𝘂𝗲𝗻𝗰𝗲𝗿 𝗰𝗲𝗻𝘁𝗿𝗮𝗹𝗶𝘇𝗮𝗱𝗼 𝗰𝗼𝗻 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝗼 𝗱𝗲 𝗯𝗹𝗼𝗰𝗸-𝗯𝘂𝗶𝗹𝗱𝗶𝗻𝗴." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Esta crítica argumenta que BAM introduce un único secuenciador que se encargará de toda la programación de transacciones para Solana. Incluso si la infraestructura es distribuida, las reglas de programación provienen de un solo sistema, que está controlado por Jito. Los interesados temen que esto socave la diversidad natural de programadores de Solana en uno que podría comportarse como un secuenciador centralizado, convirtiéndose en un único punto de fallo y concentrando demasiada influencia en un solo programador y una sola parte. BAM está diseñado para que ninguna entidad única pueda controlar el orden de las transacciones. El sistema descentralizará su operación y gobernanza de la lógica de programación a través de: • 𝗼𝗽𝗲𝗻 𝗽𝗮𝗿𝘁𝗶𝗰𝗶𝗽𝗮𝘁𝗶𝗼𝗻: cualquier operador elegible puede participar y ejecutar su propio Nodo BAM. • 𝗴𝗹𝗼𝗯𝗮𝗹 𝗰𝗼𝘃𝗲𝗿𝗮𝗴𝗲: los Nodos BAM se desplegarán a través de una red de operadores geográficamente diversa. • 𝗼𝗽𝗲𝗻-𝘀𝗼𝘂𝗿𝗰𝗲, 𝘃𝗲𝗿𝗶𝗳𝗶𝗮𝗯𝗹𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗶𝗻𝗴: todo el código de BAM será de código abierto y auditable a través de atestaciones criptográficas. Si bien es cierto que los Nodos BAM son actualmente gestionados únicamente por Jito, a partir del primer trimestre de '26, la base de código será de código abierto y se incorporarán operadores independientes.

“𝗖𝗼𝗺𝗼 𝗮 𝗹𝗮𝗱𝗼𝗿, 𝗕𝗔𝗠 𝗺𝗲 𝗮𝗻𝘁𝗲𝗿𝗼 𝘁𝗼𝗱𝗼 𝗮 𝘂𝗻 𝗼𝗻𝗹𝘆 𝗼𝗻𝗲 𝘀𝗰𝗵𝗲𝗱𝘂𝗹𝗲𝗿” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Esta crítica dice que al optar por BAM, un validador efectivamente entrega el control sobre el orden de las transacciones a un único programador. En lugar de poder ejecutar o adoptar diferentes programadores, experimentar con sus propias estrategias o cambiar entre diseños competidores, están atados a un solo sistema. Para habilitar los Mercados de Capitales de Internet, Solana necesita reglas de ordenamiento deterministas y transparentes. La fragmentación perjudica a los usuarios. BAM hace esto posible con la construcción de bloques estandarizada y verificable requerida por aplicaciones de alto rendimiento. Los hechos son: • BAM es estrictamente opcional. • Los validadores pueden volver a Agave, Jito-Solana o clientes de Firedancer. • Pueden desconectarse de BAM en cualquier momento. Los complementos de BAM ofrecen una plataforma para la optimización y la innovación de desarrolladores que beneficia a toda Solana.

"𝗕𝗔𝗠 𝗺𝗼𝗻𝗼𝗽𝗼𝗹𝗶𝘇𝗲𝘀 𝗦𝗼𝗹𝗮𝗻𝗮 𝗼𝗿𝗱𝗲𝗿𝗳𝗹𝗼𝘄." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Los interesados argumentan que agregar transacciones públicas en un solo canal crea un punto de estrangulamiento central a través del cual pasa todo el flujo de órdenes y otorga ventajas a quien lo controla. Incluso si es neutral inicialmente, BAM controla el flujo de órdenes, lo que puede reforzar su posición competitiva y evitar que otras soluciones ganen tracción. BAM recopila transacciones utilizando el mecanismo estándar de TPU de Solana. No hay distinción entre "transacciones BAM" y las públicas. Los validadores reciben el mismo flujo público, solo programado a través de una capa verificable. Los validadores pueden volver a su TPU nativo instantáneamente sin costos de cambio, manteniendo el flujo de órdenes público en lugar de fragmentado en canales privados.

“𝗕𝗔𝗠 𝗶𝗻𝘁𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗲𝘅𝘁𝗿𝗮 𝗹𝗮𝘁𝗲𝗻𝗰𝘆 𝘃𝘀. 𝘃𝗮𝗹𝗶𝗱𝗮𝘁𝗼𝗿’𝘀 𝗻𝗮𝘁𝗶𝘃𝗲 𝗧𝗣𝗨.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Los interesados argumentan que una de las ventajas de rendimiento de Solana proviene de que las transacciones fluyen directamente hacia el TPU del líder con saltos mínimos. Cualquier capa de enrutamiento intermedia, 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 de IBRL en comparación con la programación nativa de TPU. BAM asegura una latencia mínima a través de una huella global de más de 100 nodos y una co-localización estratégica, manteniendo los tiempos de ida y vuelta por debajo de 5 ms. Nuestra pila TEE está altamente ajustada utilizando fijación de hilos y aislamiento de CPU, logrando paridad de rendimiento con Agave. Con la próxima migración a DoubleZero, esperamos superar los puntos de referencia de rendimiento de metal desnudo.

“𝗕𝗔𝗠 𝗽𝗿𝗼𝗱𝘂𝗰𝗲𝘀 𝗹𝗲𝘀𝘀 𝗿𝗲𝘄𝗮𝗿𝗱𝘀 𝘃𝘀. 𝗼𝘁𝗵𝗲𝗿 𝗰𝗹𝗶𝗲𝗻𝘁𝘀” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Los validadores han expresado su preocupación de que la lógica de programación de BAM podría reducir las propinas y las recompensas generales en comparación con otros constructores de bloques u oportunidades de programación. Además, los mercados de tarifas de Plugin aún no están activos, lo que hace que el potencial sea teórico mientras que el riesgo parece inmediato. 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 descontinuados. El rendimiento futuro será impulsado por Plugins y ACE, desbloqueando flujos de tarifas sostenibles a partir de nueva actividad económica en lugar de juegos a corto plazo.

“𝗖𝗼𝗺𝗼 𝗮 𝗹𝗮𝗱𝗼𝗿, 𝗻𝗲𝗰𝗲𝘀𝗶𝘁𝗼 𝗱𝗮𝗿 𝗮 𝗺𝗶𝘀 𝘀𝘁𝗮𝗸𝗲𝗿𝘀 𝗲𝗹 𝘁𝗮𝘀𝗮 𝗺𝗮́𝘀 𝗵𝗶𝗴𝗵𝗮.” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Los stakers a menudo eligen a los validadores basándose estrictamente en las recompensas. Incluso una pequeña disminución en las propinas o la variación en las ganancias a lo largo de un epoch puede hacer que el stake delegado fluya hacia otro lugar. Los validadores temen que adoptar BAM temprano podría ponerlos en desventaja competitiva si sus pares retrasan la adopción. Entendemos que los validadores deben maximizar el rendimiento para ellos mismos y sus stakers, pero también deben considerar los efectos de segundo orden de sus acciones. El hacking de rendimiento a corto plazo (sandwiching, slot-lagging) degrada la calidad de ejecución general y aleja la liquidez. El único camino sostenible hacia un mayor rendimiento es una actividad onchain más profunda, que solo puede ser habilitada por mejores aplicaciones, mayor liquidez y márgenes más ajustados.

"La Ejecución Controlada por Aplicaciones (ACE) no es importante." 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Los interesados argumentan que las aplicaciones de Solana ya funcionan bien bajo los mecanismos de inclusión de Tarifas Prioritarias y Propinas. 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 ordenamiento podría 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 manera segura. Hyperliquid realiza de 10 a 15 veces el volumen de los futuros de Solana específicamente debido a su conjunto de validadores con permisos que impone un orden estricto. Sin ACE, estas aplicaciones migrarán a L1s o L2s personalizados para obtener esas garantías.

“𝗙𝗜𝗙𝗢 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗳𝗮𝗶𝗿𝗲𝘀𝘁 𝘁𝗿𝗮𝗻𝘀𝗮𝗰𝘁𝗶𝗼𝗻 𝗼𝗿𝗱𝗲𝗿𝗶𝗻𝗴 𝗹𝗼𝗴𝗶𝗰” 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Los interesados argumentan que el simple ordenamiento 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 “pagar para ganar” de la mayoría de las cadenas de bloques. Si bien FIFO parece ser el más justo al procesar las transacciones en el orden en que se reciben, fomenta que los usuarios saturen la red para asegurar una posición favorable, lo que lleva a la congestión y a carreras de latencia que queman dinero. Esto se descompone cuando la demanda de la red es alta, causando retrasos impredecibles para todos los usuarios a medida que las colas se alargan. El enfoque de talla única de FIFO no satisface las necesidades de las aplicaciones que requieren un orden específico de transacciones para funcionar de manera óptima.

"¿𝗔𝗿𝗲𝗻'𝘁 𝗕𝗔𝗠'𝘀 𝗧𝗿𝘂𝘀𝘁𝗲𝗱 𝗘𝘅𝗲𝗰𝘂𝘁𝗶𝗼𝗻 𝗘𝗻𝘃𝗶𝗿𝗼𝗻𝗺𝗲𝗻𝘁𝘀 (𝗧𝗘𝗘𝘀) 𝘃𝘂𝗹𝗻𝗲𝗿𝗮𝗯𝗹𝗲 𝘁𝗼 𝗮𝘁𝘁𝗮𝗰𝗸𝘀?" 𝘚𝘵𝘦𝘦𝘭𝘮𝘢𝘯: Los TEEs tienen un historial de vulnerabilidades de canal lateral, errores de firmware y riesgos en la cadena de suministro. Los interesados argumentan que confiar en los TEEs para la programación de bloques podría introducir modos de fallo correlacionados: si un exploit de hardware afecta a SEV-SNP, BAM como red podría verse comprometida. También argumentan que los TEEs trasladan la confianza a los proveedores de hardware y centros de datos. BAM funciona en AMD SEV-SNP con atestaciones criptográficas en centros de datos seguros y conformes (ISO 27001/SOC 2). Incluso en un compromiso de hardware en el peor de los casos, las claves de los validadores permanecen seguras y la historia de la cadena no puede ser reescrita, solo se ve afectada la privacidad del orden en ese nodo específico. Los validadores verifican el "TCB medido" y pueden rechazar firmware defectuoso a través de la atestación.

@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! 💥