Block Assembly Marketplace (BAM)

Conclusiones prácticas

• Hoy, los líderes de Solana tienen autoridad exclusiva sobre el orden de las transacciones durante sus slots, lo que ofrece poca transparencia sobre cómo se construyen los bloques. BAM introduce una alternativa verificable y descentralizada que permite auditar la lógica de secuenciación.
• La red de BAM separa claramente las responsabilidades: los nodos de BAM gestionan el abastecimiento, la priorización y el filtrado de las transacciones de Solana, mientras que los validadores de BAM se encargan de la ejecución, el consenso y la gestión del estado. Este enfoque acerca a Solana a una arquitectura similar a Proposer-Builder Separation (PBS).
• El framework de plugins de BAM permite a los desarrolladores definir una lógica de ordenamiento personalizada e introducir nuevas primitivas de planificación. Esto habilita Application-Controlled Execution (ACE), con la que las aplicaciones pueden aplicar sus propias reglas de planificación de transacciones.
• Jito se ha comprometido a publicar eventualmente BAM como código abierto y a diseñarlo con la transparencia como principio central. Esto supone una mejora importante respecto al motor de bloques actual de Jito, que es de código cerrado y está operado por una única parte de confianza.
• Los nodos de BAM se ejecutarán en procesadores AMD compatibles con Secure Encrypted Virtualization mejorada con Secure Nested Paging (SEV-SNP). Gracias a la aceleración por hardware, SEV-SNP solo añade una sobrecarga del 2–5%, lo bastante baja para el procesamiento en tiempo real.
• El primer planificador implementado para los nodos de BAM realizará subastas periódicas dentro de los bloques en sus mempools. Dividirá el bloque en N slots y asignará los CU por igual entre cada subasta.
• Application-Controlled Execution (ACE) puede reducir la necesidad de rollups o extensiones de red para aplicar lógica personalizada, lo que ayuda a conservar más actividad en la red principal de Solana. También amplía considerablemente el espacio de diseño para nuevas aplicaciones que aprovechen el espacio de bloque programable.
• Jito planea destinar el 100% de las comisiones del protocolo, tanto del Block Engine como del próximo sistema BAM, a la tesorería de Jito DAO. Actualmente, Jito cobra una comisión del 6% sobre las propinas, dividida por igual entre Jito Labs y la DAO. En el segundo trimestre de 2025, la DAO obtuvo 22,391.31 SOL (~$4 millones) de estas comisiones mediante Tip Router.
• BAM se inspira en BuilderNet de Flashbots y adopta un enfoque similar de construcción de bloques dentro de entornos de ejecución de confianza. En la red principal de Ethereum, aproximadamente el 40% de los bloques ya se construyen en TEE.

Introducción

Block Assembly Marketplace (BAM) de Jito representa el rediseño más ambicioso hasta la fecha del proceso de construcción de bloques de Solana. Tras más de ocho meses de desarrollo, BAM surgió del deseo de ofrecer mayor privacidad, transparencia y ejecución determinista dentro de los slots en Solana para habilitar la próxima ola de aplicaciones avanzadas. El resultado es una canalización de transacciones reinventada que reemplaza el modelo actual de ordenamiento opaco dirigido por validadores por un sistema privado, programable y demostrablemente justo para secuenciar transacciones.

BAM introduce una mempool cifrada que se ejecuta dentro de entornos de ejecución de confianza (TEE), donde todas las transacciones permanecen confidenciales hasta su ejecución. Esta arquitectura orientada a preservar la privacidad busca reducir de forma considerable, o incluso eliminar, muchas de las formas más extractivas de MEV. Así, ofrece a los usuarios mayores garantías de ejecución y mejores precios. Los validadores pueden ofrecer una ejecución de mayor calidad, mientras que los desarrolladores y buscadores pueden construir directamente sobre una nueva capa programable de espacio de bloque.

BAM introduce lógica de Application-Controlled Execution (ACE) mediante un sistema de plugins. Esto habilita casos de uso como el emparejamiento con prioridad para makers en contratos perpetuos, actualizaciones de oráculos justo a tiempo, aplicación de órdenes con vigencia determinada y otras formas de enrutamiento y ejecución personalizados. Con un control detallado sobre el orden de las transacciones, los desarrolladores pueden crear primitivas financieras más sofisticadas y confiables en Solana, incluidos libros de órdenes con límite central, pools oscuros y capas de agregación.

De este modo, BAM aborda directamente muchas de las críticas históricas al modelo de producción de bloques de Solana: comportamiento opaco de los validadores, calidad de ejecución inconsistente y proliferación de mercados grises mediante mempools privadas y acuerdos fuera de banda. Hoy, los líderes de Solana tienen control unilateral sobre el orden de las transacciones durante sus slots, con poca visibilidad sobre cómo se ensamblan los bloques finales. BAM sustituye este modelo por una alternativa verificable y descentralizada que se integra sin problemas con el entorno de ejecución de alto rendimiento de Solana.

BAM se basa en precedentes reales y se inspira en BuilderNet de Flashbots. Adopta un enfoque similar de construcción de bloques dentro de entornos de ejecución de confianza. En la red principal de Ethereum, aproximadamente el 40% de los bloques ya se construyen en TEE, mientras que en Unichain (la L2 personalizada de Uniswap) esa cifra alcanza el 100%. BAM extiende este modelo a Solana con la ventaja de admitir de forma nativa la programabilidad a nivel de aplicación, la ejecución de baja latencia y una integración profunda con los clientes validadores de Jito, que hoy protegen más del 89% del stake total entre Jito-Agave y Jito-Firedancer.

Un aspecto crucial es que Jito se ha comprometido a publicar eventualmente BAM como código abierto y a diseñarlo con la transparencia como principio central. Esto supone una mejora importante respecto al motor de bloques actual de Jito, que es de código cerrado y está operado por una única parte de confianza. BAM genera certificaciones on-chain: pruebas firmadas criptográficamente que confirman exactamente qué código se ejecutó y cómo se ordenaron las transacciones. Así, cualquier observador puede verificar que la ejecución fue justa.

Descripción general de BAM

En esencia, BAM es una red de secuenciación de transacciones. Los nodos de BAM gestionan el abastecimiento, la priorización y el filtrado de las transacciones de Solana, mientras que los validadores de BAM se centran en la ejecución, el consenso y la gestión del estado. Esta separación de responsabilidades conserva dentro del validador las funciones esenciales para la continuidad de la red, al tiempo que permite mayor flexibilidad y experimentación con la lógica de secuenciación en los nodos de BAM.

El nodo de BAM se compone de una unidad de procesamiento de transacciones (TPU) y un planificador de transacciones que funcionan dentro de un TEE. También ejecuta un servidor gRPC para permitir la comunicación con los validadores conectados. El cliente Jito-validator modificado incluye un ejecutor de tipo primero en entrar, primero en salir (FIFO), optimizado para la concurrencia y el paralelismo mediante bloqueos que tienen en cuenta las cuentas.

Cada nodo de BAM puede admitir varios validadores, aunque cada validador se conecta a un solo nodo de BAM a la vez. Actualmente, Jito opera siete motores de bloques. Con BAM, la red busca escalar de forma considerable y alcanzar entre 50 y más de 100 nodos de BAM distribuidos en todas las regiones geográficas principales para lograr mayor descentralización y redundancia. La comunicación entre el nodo de BAM y el validador se realiza mediante un stream gRPC bidireccional. Los resultados de ejecución se transmiten del validador al nodo de BAM para ofrecer información en tiempo real.

Todas las transacciones dentro de los nodos de BAM se cifran en entornos de ejecución de confianza (TEE) hasta el momento de su ejecución. Esto garantiza que el flujo de transacciones se mantenga privado hasta que se ejecute.

Para garantizar una ejecución justa, el orden de las transacciones se registra de forma verificable mediante certificaciones. Estas son pruebas criptográficas, firmadas y selladas con una marca de tiempo por los nodos de BAM, que confirman que se observaron eventos o condiciones específicos. El resultado es un registro de auditoría inmutable que permite a los observadores demostrar que las transacciones se ejecutaron en el orden correcto.

El registro de auditoría incluye las transacciones enviadas al validador y su secuencia. Por ejemplo, las transacciones A, B y C se enviaron al validador de Helius en este slot. El sistema ofrece herramientas de supervisión y análisis en tiempo real, lo que permite a los usuarios rastrear sus transacciones desde el envío hasta la ejecución. Los usuarios y las aplicaciones podrán verificar si el validador de BAM respetó el orden y saber exactamente qué código se ejecutó en el nodo de BAM.

Los nodos de BAM son visibles de forma transparente en la red, al igual que los repetidores existentes de Jito. Cuando un validador se conecta a BAM, anuncia la instancia de BAM mediante sus puertos TPU y de reenvío de TPU, que funcionan como puntos de entrada para recibir transacciones.

Los usuarios aún pueden enviar transacciones mediante sus clientes RPC habituales. Sin embargo, para mejorar la seguridad, tienen la opción de enviarlas directamente a las instancias de BAM. Esto evita que validadores maliciosos intercepten o vean los paquetes de transacciones.

Cuando una transacción entra en BAM, pasa por un proceso estándar de saneamiento que incluye deduplicación, verificación de firmas y comprobaciones de formato válido, blockhash, pagador de comisiones, nonce y Address Lookup Tables.

Una vez validadas, las transacciones entran en la mempool de BAM, donde participan en una subasta periódica frecuente. Cuando concluye una subasta, las transacciones se envían a los validadores. El software de BAM firma la secuencia completa de transacciones y la registra en una base de datos. Después, los validadores transmiten los resultados de ejecución mediante una API basada en la que propuso el planificador modular de Anza.

Con un entorno de planificación seguro y un mercado local de comisiones, los validadores ahora operan bajo un contrato de participación voluntaria mucho más sólido. Reciben una secuencia predefinida de transacciones que deben programar exactamente como se proporcionó. Esto elimina las oportunidades de insertar o reordenar transacciones con fines maliciosos.

Se están explorando varios mecanismos de aplicación para abordar cualquier caso de conducta indebida de los validadores, como ataques sándwich, según las pruebas del registro de auditoría. Aunque todavía no se han definido, las posibles respuestas incluyen:

• Eliminar al validador infractor de la red de BAM.
• Exigir garantías a los validadores en forma de bonos que podrían recortarse por conducta indebida, aunque esto podría elevar las barreras de entrada para nuevos validadores.
• Aplicar listas negras o grises para restringir o limitar parcialmente la participación de los infractores.

Comisiones

Jito Labs y Jito Foundation están redactando conjuntamente una Jito Improvement Proposal (JIP) que destinará a la tesorería de Jito DAO el 100% de las comisiones del protocolo recaudadas tanto por Block Engine como por el próximo sistema BAM. Se espera que esta propuesta se presente formalmente en las próximas semanas. Representa un cambio importante en el modelo económico de Jito y está sujeta a la aprobación de la DAO. Si se aprueba, reforzará el papel central de la DAO y de los titulares del token JTO en el ecosistema de Jito.

Actualmente, el protocolo de Jito cobra una comisión del 6% sobre las propinas, dividida por igual entre Jito Labs y la DAO. Solo en el segundo trimestre de 2025, la DAO obtuvo 22,391.31 SOL (~$4 millones) de estas comisiones mediante Tip Router. La otra fuente principal de ingresos de la DAO proviene de las comisiones de jitoSOL, que sumaron 13,223.73 SOL (~$2.38 millones) durante el mismo periodo.

Entornos de ejecución de confianza (TEE)

Un entorno de ejecución de confianza (TEE) es una arquitectura respaldada por hardware diseñada para garantizar la confidencialidad y la integridad tanto del cómputo como de la memoria. Los TEE, también conocidos como enclaves, aíslan la ejecución del código del sistema operativo, el kernel y el hipervisor del sistema anfitrión, normalmente mediante una separación a nivel de hardware. Este aislamiento reduce considerablemente la superficie de ataque y hace que sea extremadamente difícil, aunque no imposible, observar o manipular las operaciones del enclave.

Los TEE se utilizan desde la década de 2000 en ámbitos como la gestión de derechos digitales, la protección de contenido y los sistemas de pago seguros. Hoy se usan ampliamente en dispositivos de consumo y servicios en la nube para gestionar datos y código confidenciales de forma segura. En smartphones y laptops, Secure Enclave de Apple y TrustZone de Android protegen datos biométricos, credenciales de pago y claves de cifrado. Consolas de videojuegos como PlayStation y Xbox usan procesadores AMD o basados en Pluton para evitar manipulaciones y piratería. En la nube, proveedores como Azure y Google Cloud utilizan AMD SEV-SNP, Intel TDX o AWS Nitro Enclaves para aislar cargas de trabajo y habilitar la computación confidencial. Las billeteras de criptomonedas como Ledger y Trezor usan elementos seguros para proteger las claves privadas, mientras que el nuevo teléfono Solana Seeker utiliza TEE con el mismo propósito.

Los TEE son el enfoque estándar basado en hardware para procesar datos privados y ofrecen una alternativa práctica a los métodos puramente criptográficos, como el cifrado totalmente homomórfico (FHE) y la computación multipartita segura (MPC). Aunque FHE y MPC ofrecen garantías teóricas sólidas, suelen ser poco prácticos en entornos reales debido a su alta complejidad y sobrecarga de rendimiento.

BAM se basa en dos propiedades fundamentales de los TEE:

Confidencialidad: El código y los datos dentro del TEE están cifrados y aislados del resto del sistema. Ni el sistema operativo, ni el hipervisor ni ningún software externo pueden acceder o inspeccionar lo que se ejecuta dentro del enclave.

Capacidad de certificación: Los TEE admiten certificaciones, un mecanismo que produce una prueba criptográfica del origen y el estado actual del enclave. Esto permite que terceros verifiquen que un TEE auténtico que ejecuta código de confianza produjo un resultado, en lugar de un entorno comprometido o emulado.

Implementación de TEE en BAM

BAM se ejecutará en procesadores AMD compatibles con Secure Encrypted Virtualization mejorada con Secure Nested Paging (SEV-SNP). A diferencia de los enfoques basados en enclaves más pequeños, SEV-SNP protege toda la aplicación BAM con una sobrecarga de rendimiento mínima. Esto lo hace ideal para sistemas de transacciones de alto rendimiento y baja latencia.

Gracias a la aceleración por hardware, SEV-SNP solo añade una sobrecarga del 2–5%, lo bastante baja para el procesamiento en tiempo real. Puede admitir aplicaciones complejas, con estado y conectadas en red, no solo cálculos aislados. La tecnología se ha probado en condiciones reales, con implementaciones en importantes proveedores de nube como Google Cloud, Azure y AWS, y cuenta con años de investigación en seguridad y experiencia operativa.

SEV-SNP, utilizado en BAM, ofrece varias garantías de seguridad clave. Cada instancia de TEE se ejecuta dentro de su propia máquina virtual aislada por hardware, con la memoria cifrada en tiempo de ejecución para garantizar un fuerte aislamiento a nivel de VM. BAM aprovecha una certificación basada en hardware que permite a cada TEE demostrar criptográficamente que ejecuta código auténtico y sin modificaciones. Esta cadena de certificación está anclada en las claves raíz de hardware de AMD, que se incorporan físicamente en la CPU durante la fabricación. Además, las claves TLS se generan con el generador interno de números aleatorios por hardware del procesador, lo que garantiza que nunca queden expuestas en memoria sin cifrar.

Cuando un cliente se conecta a BAM, recibe un certificado TLS que contiene el certificado de conexión estándar, un informe de certificación de AMD SEV-SNP y una prueba criptográfica de que la clave privada TLS se generó dentro del TEE certificado. Esta cadena de certificados está vinculada criptográficamente a la raíz de confianza de hardware de AMD. No puede falsificarse sin acceso a las claves raíz privadas de AMD, lo que elimina la necesidad de confiar en cualquier intermediario más allá del proceso de fabricación de chips de AMD.

Plugins

Hoy, las aplicaciones en Solana solo pueden influir en el orden de las transacciones mediante comisiones de prioridad o transacciones agrupadas con propinas asociadas. Con varios secuenciadores activos en clientes como Agave y Firedancer, no hay garantía de qué lógica de ordenamiento se aplicará. Esto deja a las aplicaciones con un control limitado sobre cómo se ordenan sus transacciones.

Los plugins resuelven este problema. 

Mediante el framework de plugins de BAM, los desarrolladores pueden implementar una lógica de ordenamiento personalizada e introducir nuevas primitivas de planificación. Los plugins habilitan Application-Controlled Execution (ACE), lo que permite a las aplicaciones definir políticas personalizadas de planificación de transacciones. Aunque ACE tiene muchas aplicaciones potenciales, el caso de uso más reconocido y discutido es priorizar las cancelaciones en los libros de órdenes. Este mecanismo reduce la selección adversa y permite spreads más estrechos.

Priorización de cancelaciones de makers en libros de órdenes

Hoy, los creadores de mercado de libros de órdenes on-chain en Solana operan en desventaja. Los creadores de mercado gestionan el riesgo actualizando o cancelando constantemente las cotizaciones obsoletas cuando cambia el precio justo. Cuando el precio de mercado cambia, deben cancelar las órdenes existentes antes de que los takers informados puedan aprovechar la oportunidad.  

Sin un control detallado sobre el orden de las transacciones, sus cotizaciones son vulnerables a un flujo tóxico que aprovecha sus precios obsoletos. Los creadores de mercado pueden sufrir pérdidas incluso cuando actúan con rapidez, porque la subasta de Jito prioriza las ofertas sobre la intención. En esencia, la parte que paga más se secuencia primero.

Esta dinámica obliga a los creadores de mercado a ampliar sus spreads para gestionar el riesgo. Esto reduce la liquidez general y empeora los precios para los usuarios. Estas operaciones tóxicas, en las que el taker obtiene ganancias de un precio obsoleto y la contraparte se arrepiente casi de inmediato, aportan poco a la experiencia del usuario, pero aumentan considerablemente la fricción para los creadores de mercado y los proveedores de liquidez.

Los plugins de BAM permiten aplicar políticas de "cancelar antes de tomar" a nivel de aplicación. Al ofrecer a los programas un control detallado sobre el orden de las transacciones, las aplicaciones pueden procesar las cancelaciones de los makers antes que las operaciones de los takers. Este sencillo cambio de política tiene implicaciones profundas:

• Reduce la selección adversa: Los makers ya no sufren pérdidas de forma habitual cuando el mercado cambia.
• Filtra el flujo tóxico: Aunque el volumen total puede disminuir debido a la reducción de operaciones tóxicas, la calidad del flujo y de la ejecución mejora.
• Permite spreads más estrechos: Al reducirse el riesgo, los makers pueden ofrecer cotizaciones más agresivas.
• Mejora la liquidez: Tanto los makers profesionales como los operadores minoristas tienen más confianza para ofrecer cotizaciones, lo que genera una liquidez más profunda.

Actualizaciones de oráculos justo a tiempo

Otro ejemplo de plugin específico para una aplicación es la implementación prevista por Pyth de actualizaciones de oráculos justo a tiempo. Como principal proveedor de oráculos de Solana, Pyth mantiene más de 1,700 feeds de precios individuales. Actualizarlos todos en cada bloque tendría un costo prohibitivo y sería ineficiente en términos de espacio de bloque.

Con BAM, Pyth puede actualizar feeds de precios específicos justo cuando se necesitan. Para ello, inserta la actualización del oráculo directamente antes de la transacción de un usuario dentro del mismo bloque. Esto reduce los riesgos asociados con datos de oráculos obsoletos, como liquidaciones ineficientes y manipulación de oráculos, lo que permite que las aplicaciones DeFi operen de forma más confiable y competitiva.

Más plugins

En última instancia, BAM busca ser una plataforma sin permisos donde los desarrolladores de aplicaciones puedan crear, probar e implementar plugins para controlar la secuenciación de sus transacciones. Se espera que aparezcan muchos más plugins y que los nodos de BAM lleguen a admitir cientos de extensiones personalizables. Aunque la mayoría de las aplicaciones seguirán utilizando el planificador predeterminado, aquellas que necesiten una lógica de secuenciación personalizada serán responsables de desarrollar y mantener sus propios plugins. 

Además, las aplicaciones podrán monetizar las funciones de los plugins mediante el cobro de comisiones, con la posibilidad de compartir una parte de los ingresos con los titulares de tokens de gobernanza o los validadores.

Posibles plugins de uso general

Los plugins no se limitan a una sola aplicación. Jito ya ha propuesto varios ejemplos de plugins de uso general y compatibles con varias aplicaciones que podrían desarrollarse para BAM:

Futuros de espacio de bloque: Permiten a los usuarios y las aplicaciones reservar o negociar el derecho a usar espacio de bloque en el futuro. Así, ofrecen acceso y precios predecibles incluso durante periodos de alta demanda en la red.

Vigencia de la orden (TIF): se refiere al periodo durante el cual una orden permanece activa antes de cancelarse automáticamente si no se ejecuta por completo. Por ejemplo, permite que una transacción de un libro de órdenes solo sea válida durante 20 milisegundos. Hoy es posible aplicar una versión rudimentaria en Solana usando deliberadamente blockhashes anteriores para garantizar que una transacción solo sea válida en los bloques más recientes.

Preconfirmaciones: Los usuarios pueden recibir una notificación cuando su transacción se envía a un validador, antes de que se ejecute y se propague por la red. Esto permite confirmar las transacciones antes con cierto grado de confianza.

Transacciones sin comisiones: permiten a los usuarios cubrir los costos de transacción con un token SPL, como stablecoins, en lugar de SOL. Esto abstrae los requisitos del token nativo y permite pagar comisiones de forma flexible.

Agregador de baja latencia y solicitud de cotización (RFQ): Los usuarios envían intenciones de operación directamente a BAM, donde un agregador ejecutado localmente identifica la ruta óptima.

Cancelación y reemplazo de transacciones: Los usuarios pueden enviar transacciones con marcadores especiales que les permiten cancelar, descartar o reemplazar transacciones enviadas anteriormente.

Despliegue

Durante la fase de lanzamiento, Jito Labs operará el conjunto inicial de nodos de BAM para garantizar la estabilidad, el rendimiento y la seguridad. Un grupo autorizado de los primeros validadores asociados, incluidos Helius, SOL Strategies, Triton One y Figment, ejecutará el cliente de BAM y protegerá un porcentaje alto de un solo dígito del stake total de la red poco después del lanzamiento. 

En paralelo, un grupo inicial de aplicaciones de Solana, incluidas Drift, Pyth y DFlow, comenzará a diseñar y probar la primera ola de plugins. Para el final de la fase de lanzamiento, se espera que BAM haya validado su funcionalidad principal y establecido las bases para una participación más amplia de operadores de nodos y validadores. 

Los validadores, desarrolladores de aplicaciones o buscadores interesados en participar en BAM pueden completar este formulario.

Un comité asesor del ecosistema, compuesto por actores destacados de la comunidad de validadores y desarrolladores de Solana, incluida Solana Foundation, asesorará a Jito Labs. Este comité ayudará a orientar la expansión de BAM, promover la descentralización y fomentar la innovación liderada por la comunidad.

Por ahora, el código de BAM sigue siendo cerrado, pero está previsto publicarlo como código abierto en un futuro cercano para permitir el desarrollo de plugins por parte de terceros. Una vez publicado, BAM aceptará contribuciones de la comunidad en varias áreas clave:

• Desarrollo de plugins: Crea plugins personalizados para ampliar las capacidades de BAM.
• Algoritmos de planificación: Diseña y aporta nuevas estrategias de ordenamiento de transacciones adaptadas a casos de uso específicos.
• Bibliotecas de integración: Desarrolla SDK en varios lenguajes de programación para simplificar la integración con BAM.
• Herramientas de análisis: Crea paneles y sistemas de supervisión que aprovechen los datos de certificación de BAM.
• Contribuciones de investigación: Propón e implementa enfoques novedosos para mitigar el MEV y optimizar el sistema.

Implicaciones

BAM representa un punto de inflexión para Solana, con el potencial de impulsar una ola de innovación al abordar las preocupaciones sobre la explotación de MEV y el empaquetado eficiente de bloques. La secuenciación protegida por TEE y el framework de plugins de BAM podrían reducir el incentivo para que los equipos de aplicaciones creen extensiones de red, rollups o entornos con permisos de Solana para aplicar su propia lógica personalizada o imponer sus criterios sobre el espacio de bloques. Así, más actividad permanecería en la mainnet de Solana. Además, con los aumentos de los límites de cómputo por bloque y la demanda de programas de tokens y frameworks más eficientes que usen menos CU (por ejemplo, la creciente popularidad de Pinocchio y p-token), habrá más capacidad en la mainnet, lo que reducirá aún más el incentivo para que los desarrolladores creen soluciones personalizadas.

Las funciones de privacidad de BAM también deberían reducir significativamente la prevalencia de los ataques sándwich, ya que las transacciones permanecen ocultas hasta su ejecución. Esto limita la capacidad de los bots para adelantarse a los usuarios. Es probable que mejore la eficiencia de los DEX y que los usuarios obtengan precios más competitivos. Sin embargo, es poco probable que BAM elimine por completo el MEV. El MEV es, por naturaleza, un juego del gato y el ratón, y quienes ejecutan ataques sándwich se adaptarán, quizá mediante exploits sutiles en plugins o la manipulación de oráculos externos (es decir, oráculos que no tengan su propio plugin), ya que estos no forman parte del flujo cifrado. 

Reducir el MEV mediante BAM podría afectar negativamente los ingresos de Jito, como ocurrió con el cierre de su mempool en 2024, que redujo los ingresos a corto plazo, pero terminó beneficiando a la red. Las mejoras de BAM podrían compensarlo al impulsar un mayor volumen general de transacciones y más comisiones de plugins, lo que aumentaría los ingresos a largo plazo gracias a una mayor adopción. Sin embargo, la implementación exacta de BAM, su lanzamiento por fases y su economía plantean posibles riesgos de centralización y preguntas abiertas, que analizamos en las siguientes secciones. Aun así, estos riesgos y preguntas abiertas se contrarrestan con diversos beneficios, cada uno con sus propias implicaciones para la redistribución de MEV, PBS y el desarrollo de un cliente «nuevo».

Redistribución de MEV

BAM transforma radicalmente el panorama de MEV de Solana: pasa de una extracción sin control a un modelo de redistribución más estructurado. En las configuraciones tradicionales, el MEV suele extraer valor de los usuarios mediante transacciones anticipadas o spam. Los validadores o bots capturan ese valor con tácticas perjudiciales, como los ataques sándwich. Sin embargo, el mempool cifrado mediante TEE de BAM oculta las transacciones hasta su ejecución, lo que limita la visibilidad necesaria para el MEV negativo. En su lugar, el valor se internaliza mediante plugins y secuenciación personalizada. Esto permite que las aplicaciones, los desarrolladores y los buscadores capturen formas positivas de MEV que mejoran la eficiencia del ecosistema (por ejemplo, spreads de DeFi más ajustados y menos spam de oráculos).

Esta redistribución devuelve las ganancias de MEV a sus partes interesadas, ya que las comisiones de los plugins se comparten entre los operadores de nodos BAM, los validadores, quienes hacen staking y la DAO de Jito. Esto podría crear fuentes de ingresos sostenibles. Por ejemplo, un DEX podría tener un plugin que optimice el emparejamiento de órdenes y convierta el MEV potencialmente extraído por los validadores en comisiones generadas por la aplicación, que luego podrían redistribuirse entre los titulares de tokens. Este enfoque «protegido» de la actividad de los traders podría transformar el MEV de un juego de suma cero en uno que aumente la liquidez y atraiga capital institucional.

Sin embargo, la redistribución conlleva riesgos. Es importante tener en cuenta que BAM no elimina el MEV: lo reubica. Esta reubicación podría permitir que los primeros desarrolladores de plugins, los operadores de nodos BAM y las entidades vinculadas con Jito acumulen ganancias desproporcionadas. Aunque están limitados por certificaciones criptográficas, si surgen vulnerabilidades en los TEE (por ejemplo, ataques de canal lateral), el acceso privilegiado de los buscadores podría habilitar nuevos vectores sutiles de extracción y, en última instancia, debilitar las garantías de privacidad. Esto también abre la puerta a formas «protegidas» de backrunning, mediante las cuales los buscadores pueden implementar código para agregar transacciones después de la de un usuario (por ejemplo, para capturar el arbitraje de un swap que mueve el precio) sin revelar estrategias ni permitir transacciones anticipadas. Además, ante la ausencia de penalizaciones programáticas, los atacantes adaptativos podrían aplicar estrategias dañinas en torno a las certificaciones, que ocurren después de la ejecución y actualmente dependen del control de la comunidad.

En última instancia, aunque la redistribución de MEV posiciona a BAM como catalizador del objetivo principal de Solana (es decir, un NASDAQ descentralizado), su éxito depende de la adopción de modelos de comisiones equitativos y de una seguridad robusta para los TEE. Si se gestiona mal, podría fragmentar la red, erosionar la confianza de los usuarios y generar escrutinio sobre las actividades «protegidas», pero opacas, de los buscadores.

Separación entre proponente y constructor (PBS)

La mayoría de las blockchains están diseñadas para que la misma entidad proponga y construya los bloques. Esto le otorga un control monopólico sobre el orden y la inclusión de las transacciones dentro de los slots que tiene asignados. Esta situación beneficia a dichas entidades, que pueden censurar o manipular de otras formas los flujos de transacciones. Por ejemplo, podrían proponer y construir bloques con estrategias sofisticadas, aunque perjudiciales, para incluir transacciones en un orden específico y así maximizar el MEV.

La separación entre proponente y constructor (PBS) es un patrón de diseño que aborda este problema al separar la construcción de bloques de su propuesta. Con este diseño, los constructores de bloques crean listas ordenadas de transacciones y presentan ofertas por estos bloques. Los proponentes de bloques, normalmente validadores, aceptan y confirman el bloque con la oferta más alta. Así redistribuyen cualquier MEV mediante subastas o propinas sin tener que ejecutar por sí mismos estrategias sofisticadas de secuenciación. 

PBS se implementa fuera del protocolo mediante MEV-Boost en Ethereum desde The Merge en 2022. MEV-Boost es un «sidecar» que se ejecuta junto con el software cliente de doble capa de un validador: la capa de ejecución y la capa de consenso. Los validadores que ejecutan MEV-Boost pueden conectarse a varios relays y aceptar bloques preconstruidos de los constructores de bloques. No ven el contenido del bloque antes de que se incluya en la blockchain, ya que solo reciben de los relays los montos de las recompensas y los encabezados de los bloques. Ten en cuenta que este diseño sigue en una fase activa de investigación, pues PBS aún espera su incorporación completa al protocolo (ePBS), que podría incluir funciones como listas de inclusión para reducir aún más la censura.

Con BAM, Solana avanza hacia un futuro similar a PBS, que separa la construcción de bloques (es decir, la secuenciación en nodos BAM protegidos mediante TEE) de la ejecución, que sigue siendo responsabilidad de los validadores. Esto podría democratizar las formas positivas de MEV para las aplicaciones y los buscadores mediante plugins. Sin embargo, también corre el riesgo de agravar la centralización del stake en Solana si la economía de los plugins favorece a los actores establecidos. Esto resulta evidente en Ethereum, donde tres constructores (es decir, Titan Builder, BuilderNet y Beaverbuild) ahora dominan más del ~90 % de todos los bloques, lo que genera problemas de confianza en los relays y barreras para los participantes más pequeños. 

Aunque MEV-Boost introdujo PBS en Ethereum, una comparación más justa en este caso es BuilderNet, una red descentralizada de construcción de bloques lanzada en noviembre de 2024 y operada por Flashbots, Beaverbuild y Nethermind. BuilderNet usa TEE para la construcción privada de bloques, lo que descentraliza el proceso entre varios operadores de nodos para neutralizar los acuerdos exclusivos de flujo de órdenes y reducir la centralización. Se centra en la creación de valor (es decir, compartir reembolsos de MEV con proveedores de flujo excedente, como usuarios, wallets y aplicaciones), en vez de competir por el flujo de órdenes (por ejemplo, luchar por acuerdos privados). BuilderNet todavía usa relays de MEV-Boost, pero no son estrictamente necesarios. Esto permite que ocurran interacciones directas entre constructores y proponentes dentro de los TEE. 

El lanzamiento gradual y con permisos de BAM debe priorizar comisiones equitativas y plugins de código abierto para evitar estos problemas de Ethereum. Esto es especialmente importante debido a sus dependencias de hardware (es decir, TEE frente a los relays de software de Ethereum), que introducen dependencia de proveedores y costos de mantenimiento. Solana espera evitar la competencia por el flujo de órdenes y pasar directamente a un sistema similar a BuilderNet, centrado en la creación de valor. 

En última instancia, este cambio en la construcción y propuesta de bloques reduce el papel de los validadores. Elimina la complejidad de la secuenciación, pero podría reducir su autonomía e ingresos si las comisiones no se comparten ampliamente. Lo analizamos con más detalle en la sección titulada El papel reducido de los validadores.

Arriba: comparación entre PBS de Ethereum y BAM de Solana

Surge un cliente «nuevo»

El cliente Jito-Agave replica fielmente la base de código principal de Agave y se diferencia principalmente por incorporar capacidades de MEV. El modelo «Agave más MEV» de Jito permitió que su cliente se integrara sin problemas con el ecosistema de validadores existente de Solana. Esto aumentó las recompensas y minimizó los cambios en la arquitectura principal. Como resultado, al momento de escribir este artículo, el cliente Jito-Agave lidera la red con una adopción del 79 % entre los validadores. Así, los validadores pueden confiar en la lógica fundamental de Agave mientras se benefician de las fuentes de ingresos adicionales de Jito.

BAM representa un cambio respecto al enfoque anterior de Jito, que consistía en replicar fielmente Agave. La introducción de una red dedicada de nodos BAM establece una nueva capa de infraestructura. Esta evolución transforma a Jito de una simple versión «mejorada de Agave» en un cliente más diferenciado, con su propio ecosistema programable para incorporar lógica específica de las aplicaciones.

Esta divergencia se hace evidente en las próximas vinculaciones del planificador de Agave, que Anza anunció en mayo. Las implementaciones de planificadores personalizados son cada vez más comunes a medida que madura el MEV en Solana. Aunque los planificadores personalizados pueden aumentar los ingresos de sus operadores, sus implementaciones actuales presentan varias desventajas. Entre ellas están la necesidad de ejecutar el binario de una versión diferente del validador, la dependencia de código cerrado y posibles problemas de disponibilidad. 

Las próximas vinculaciones del planificador de Anza introducen modularidad al permitir que los validadores se conecten a servicios externos de construcción de bloques sin modificar el binario principal del validador. Esto permite usar planificadores personalizados. El diseño promueve la transparencia, la seguridad y una gestión de DevOps más sencilla. Sin embargo, BAM elimina la necesidad de que los usuarios de Jito usen estas vinculaciones, ya que el planificador del nodo BAM gestiona la secuenciación en una etapa anterior. Esto evita las vinculaciones del planificador previstas por Agave y podría agilizar las operaciones, pero genera dudas sobre una posible fragmentación futura del ecosistema debido a su divergencia respecto a los esfuerzos de estandarización de Anza (por ejemplo, al complicar las integraciones con Firedancer).

Sin embargo, Jito posiciona a BAM como parte de un cliente unificado para validadores. Los validadores de BAM ejecutarán una versión actualizada del cliente Agave que integra el planificador de BAM y solo acepta transacciones de los nodos BAM en orden FIFO. Este diseño evita la fragmentación de clientes y mejora la resiliencia del sistema. Jito planea lanzar su cliente compatible con BAM antes del despliegue del planificador modular de Anza. Esta decisión destaca el doble impacto de BAM: fomenta la innovación y mejora la infraestructura de MEV de Solana, pero también corre el riesgo de consolidar aún más la posición de Jito como el cliente dominante para validadores.

También es posible que BAM use estas vinculaciones. Si BAM opera dentro del planificador modular, el soporte para Firedancer se vuelve trivial y surge una nueva pregunta: ¿Jito realmente necesita un cliente para validadores? Solo el tiempo lo dirá mientras esperamos la implementación del código abierto y el lanzamiento de BAM.

Preguntas abiertas

El papel reducido de los validadores

El diseño de BAM transforma radicalmente el panorama de validadores de Solana al transferir la secuenciación de transacciones a una red separada de nodos BAM protegidos mediante TEE. Esto deja a los validadores como principales responsables de la ejecución, el consenso y la gestión del estado. Esta separación beneficia a las aplicaciones porque permite la secuenciación personalizada y la posibilidad de compartir ingresos con los titulares de tokens. También beneficia a los usuarios al reducir el MEV negativo y ofrecer precios más favorables. Sin embargo, plantea dudas sobre la reducción de la autonomía y los incentivos económicos de los validadores.

Cuando producen bloques como líderes, los validadores actualmente tienen plena libertad para ordenar las transacciones. Esto les permite ejecutar planificadores personalizados y optimizar sus bloques como prefieran. BAM les quita esta responsabilidad. Ahora los validadores reciben transacciones presecenciadas que deben ejecutar en estricto orden FIFO, lo que elimina su autonomía sobre la construcción de bloques. En el extremo de este escenario, si todas las transacciones pasan por BAM, los validadores se convierten en simples «sellos de aprobación», lo que pone en duda la necesidad misma de contar con validadores descentralizados. 

Sin embargo, existen factores que contrarrestan este efecto. En particular, las comisiones de los plugins crean nuevas fuentes de ingresos que se comparten con los validadores y quienes hacen staking. El cliente unificado y los mecanismos de respaldo automatizados de BAM alinean los intereses individuales con la salud de la red y mejoran su resiliencia general. El lanzamiento gradual y opcional también preserva la capacidad de elegir, mientras que la publicación del código a largo plazo permite que los validadores participen en el desarrollo de BAM. Esto fomenta mejoras impulsadas por la comunidad y preserva parte de su autonomía.  Los validadores también podrán proponer mejoras al planificador de BAM, lo que podría permitirles capturar comisiones de volúmenes más altos. Además, la idea de que los validadores serán simples sellos de aprobación probablemente sea una exageración, ya que todavía desempeñan un papel clave en el consenso y la elección de bifurcaciones. La verdadera pregunta es: ¿cuánta autonomía perderán realmente los validadores? ¿Podría BAM permitir que se concentren más en la disponibilidad y la integridad del estado?

Aún quedan varias preguntas:

• Si los nodos BAM gestionan la secuenciación y la extracción de MEV, ¿cómo compiten los validadores más allá del hardware y el tiempo de actividad? 
• En un escenario de alta adopción, ¿el enfoque exclusivo de los validadores en la ejecución reducirá la descentralización general de Solana? De ser así, ¿qué métricas podrían medir esa reducción?
• Si BAM lleva a los validadores a buscar vías más dañinas para generar ingresos, ¿qué mecanismos de protección, además de las certificaciones, pueden impedirlo sin reducir aún más los incentivos?
• ¿Las vulnerabilidades de los TEE o los exploits en plugins podrían provocar penalizaciones injustas para los validadores? 
• A partir de la experiencia de Ethereum con PBS, ¿qué puede hacer Solana para contrarrestar la reducción de la autonomía de los validadores?

Operadores de nodos maliciosos

La arquitectura de BAM introduce nuevos supuestos de confianza respecto a los validadores. Es decir, se asume que no actuarán de forma maliciosa al interactuar con los nodos BAM, por ejemplo, alterando transacciones presecenciadas o filtrando datos. En su lanzamiento, BAM dependerá de un conjunto de operadores con permisos debido a las limitaciones de los TEE. A este conjunto con permisos se le confiará la ejecución de un cliente Jito-Solana actualizado y el procesamiento fiel de las transacciones reenviadas. Estos validadores deben confiar en que los nodos BAM no manipulen el ingreso de datos. Esto crea una confianza de doble capa (es decir, nodos BAM antes del TEE y validadores después del TEE), lo que aumenta el riesgo en una configuración con permisos. La pregunta fundamental es: ¿qué impide que los operadores de nodos BAM inspeccionen las transacciones antes de que lleguen al TEE? La respuesta es el cifrado QUIC para nodos verificados: incorporarán la certificación en el certificado QUIC. Otra forma de verificar si los nodos BAM son honestos consiste en comparar sus hashes con el repositorio de código abierto de BAM para comprobar si un nodo BAM determinado ejecuta el software que afirma ejecutar. Siempre que nadie haya vulnerado el TEE, los certificados QUIC para la TPU se generarán dentro del TEE. Por lo tanto, todo el tráfico entrante y saliente estará cifrado.

Sin embargo, la censura y la manipulación selectiva de paquetes de transacciones en los puntos de entrada y salida de la red son preocupaciones importantes. Los operadores maliciosos mantienen una capacidad significativa de censura, aunque no puedan ver los detalles cifrados de las transacciones. Podrían identificar tipos de protocolos mediante firmas TLS, filtrar según los endpoints de conexión, realizar análisis temporales para identificar ciertos patrones y bloquear todos los datos cifrados que coincidan con determinadas características. Por lo tanto, el operador malicioso quizá no conozca las transacciones exactas que se transmiten, pero aun así puede descartar paquetes según los metadatos y determinados patrones de tráfico. Para mitigar este riesgo, se podría mejorar la transparencia mediante las capacidades de filtrado de paquetes y marcado de tiempo de DoubleZero. En última instancia, mitigar los ataques de censura de red es una razón válida para realizar un lanzamiento con permisos.

También existen nuevos supuestos de confianza relacionados con el acceso físico, ya que casi siempre representa una falla de seguridad, y los TEE no son la excepción. Aunque los TEE ofrecen sólidas garantías de seguridad, pueden verse comprometidos si un atacante obtiene acceso físico al servidor. Las alianzas exclusivas con proveedores que cumplan con SOC 2 ayudarán a mitigar este riesgo al garantizar una seguridad robusta y por capas en el centro de datos.

Aún quedan varias preguntas:

• Si un operador malicioso censura paquetes o filtra datos, ¿cómo se aplicarán las sanciones?
• Durante la fase con permisos, ¿cómo evitará la selección de operadores la colusión y qué métricas pueden usarse para medir el progreso hacia la descentralización? 

Componibilidad e interacción entre plugins

Una de las preguntas abiertas más importantes para BAM es cómo interactuarán los plugins entre sí en la práctica. Una sola transacción podría depender de varios plugins simultáneamente. Por ejemplo, podría usar un plugin de oráculo para actualizar precios justo a tiempo, un plugin de DEX para determinar las rutas óptimas de swap y un plugin de tokens para gestionar comportamientos específicos de los tokens SPL. Es fundamental garantizar que estos componentes funcionen juntos de manera predecible y segura.

Es posible que los plugins deban obtener datos externos para funcionar de manera eficaz. Sin embargo, esto crea una posible superficie de ataque, ya que los plugins maliciosos podrían abusar de las llamadas externas para filtrar información confidencial sobre las transacciones. Es esencial definir límites estrictos sobre lo que los plugins pueden consultar y compartir para mantener la confianza en el sistema.

Otra capa de complejidad surge de la interacción entre la lógica de los plugins a nivel de aplicación y los mecanismos de comisiones de Solana. ¿Cómo interactúan el orden de ejecución de los plugins, las propinas de Jito y las comisiones de prioridad cuando varios plugins compiten por influir en la construcción de bloques? Estas dinámicas económicas deben definirse con claridad y aplicarse de forma transparente para evitar manipulaciones o abusos imprevistos.

Para gestionar estos riesgos, se espera que el lanzamiento de los plugins de BAM comience en un entorno con permisos. Esto permite experimentar y auditar el comportamiento de los plugins durante las primeras etapas antes de avanzar gradualmente hacia un modelo sin permisos.

Confianza y responsabilidad de los TEE

La dependencia de los TEE introduce nuevos supuestos de confianza, ya que usa un enclave de hardware especial en vez de crear un sistema sin necesidad de confianza que garantice un cómputo verificable. Depender de un único proveedor de hardware, como Intel o AMD, introduce riesgos de monocultivo: un retiro de firmware o un exploit podría detener BAM y quizá provocar una interrupción en toda la red, según su nivel de adopción. Si estas vulnerabilidades no pueden corregirse mediante actualizaciones de firmware, microcódigo o BIOS, reemplazar el hardware lleva tiempo e impone un gasto de capital recurrente a los operadores de nodos BAM, lo que agrava aún más el impacto de una posible interrupción. 

Estas preocupaciones se basan en vulnerabilidades históricas que han demostrado que los TEE pueden fallar y exponer datos cifrados. Por ejemplo, Software Guard Extensions (SGX) de Intel ha sufrido numerosos problemas que afectaron a distintas blockchains. En agosto de 2022, Secret Network era vulnerable a las vulnerabilidades xAPIC y MMIO. En conjunto, estas vulnerabilidades podían usarse para extraer la semilla de consenso, una clave maestra para descifrar las transacciones privadas ejecutadas en la red. 

Muchos otros problemas llevaron finalmente a Intel a retirar SGX de los procesadores Intel Core de 11.ª y 12.ª generación. Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) de AMD también tiene varias vulnerabilidades divulgadas. En particular, en febrero se reveló CVE-2024-56161, una vulnerabilidad que permitía inyectar microcódigo malicioso con acceso de administrador. 

Las actualizaciones para mitigar vulnerabilidades no siempre son compatibles con versiones anteriores y pueden requerir mejoras físicas. Por ejemplo, la divulgación de CVE02020-12967 y CVE-2021-26311 reveló la posibilidad de ejecutar código arbitrario dentro de máquinas virtuales invitadas en equipos con AMD Secure Encrypted Virtualization-Encrypted State (SEV-ES), la implementación de TEE de la generación anterior de la empresa. AMD no lanzó firmware actualizado para abordar estas vulnerabilidades y proporcionó una mitigación mediante la función SEV-SNP, que solo era compatible con procesadores AMD EPYC de 3.ª generación (es decir, «Milan»). 

La infraestructura TEE de BAM se basa en la arquitectura SEV-SNP de última generación, que incluye las protecciones de hardware necesarias para evitar estos exploits conocidos. También cabe señalar que, si se descubre una vulnerabilidad de día cero, la red podría seguir funcionando, ya que los validadores de Jito pueden recurrir automáticamente a su propia TPU cuando se desconectan de un nodo BAM. Este mecanismo de conmutación por error garantiza que los validadores sigan funcionando mientras se aplican los parches de seguridad.

Aún quedan varias preguntas:

• Dado el historial de exploits, ¿cómo afecta a la confianza a largo plazo la dependencia de BAM de los proveedores de hardware? ¿Pueden usarse alternativas como los entornos de ejecución de confianza cero (ZTEE) para reducir esta dependencia?
• ¿Quién asume la responsabilidad por las pérdidas financieras si se filtran datos de transacciones privadas desde un TEE comprometido?
• ¿Cómo se recuperaría la confianza si fallan los TEE? ¿Podría ofrecerse una alternativa?

Conclusión

En última instancia, los validadores tienen la libertad de ejecutar el software que prefieran. Como empresas con fines de lucro que operan en un mercado muy competitivo, sus decisiones dependen de los posibles rendimientos tanto para ellos como para sus delegadores, quienes pueden trasladar su stake a donde los rendimientos sean más altos. La adopción generalizada del Jito-client refleja esta dinámica. Su éxito se debe, en gran medida, a su capacidad de generar ingresos adicionales tanto para los operadores como para los delegadores. La adopción de BAM dependerá de una dinámica similar. Si ejecutar BAM resulta consistentemente más rentable que mantener el statu quo, los validadores lo adoptarán. De lo contrario, podrían dudar en cambiar, incluso si BAM logra aportar beneficios importantes a otras partes interesadas.

Dado que BAM se anunció hace poco, aún quedan muchas preguntas sin respuesta sobre su diseño y funcionamiento. Esperamos conocer más detalles y documentación, y ver más debates de la comunidad en los próximos meses sobre este emocionante avance.

Recursos adicionales

• Presentamos BAM: el futuro de la construcción de bloques en Solana - Jito
• Serie de pizarras sobre BAM - Jito Learn
• Jito BAM y el futuro de Solana - 0xResearch