Resumen Técnico: Boost+: Construcción de Bloques Equitativa y con Compatibilidad de Incentivos

1. Planteamiento del Problema

La escasez de espacio de bloque en las blockchains descentralizadas, particularmente en Ethereum, requiere una asignación eficiente mediante la construcción de bloques. Si bien el Valor Extraíble Máximo (MEV) impulsa la competencia, el ecosistema actual, centrado en MEV-Boost, se ha vuelto altamente centralizado debido a la integración. La integración ocurre cuando los searchers (intermediarios que generan transacciones rentables) dirigen exclusivamente sus flujos de órdenes hacia un único builder. Esta práctica crea una ventaja injusta, distorsiona la competencia, reduce la eficiencia del espacio de bloque al excluir transacciones compatibles de los builders no integrados y oscurece los flujos de MEV a través de pagos fuera de la cadena (off-chain) opacos.

El desafío central es diseñar un sistema que simultáneamente:

1. Elimine los incentivos para la integración (garantizando el acceso igualitario a los flujos de órdenes).
2. Garantice la compatibilidad de incentivos (haciendo que el reporte veraz sea una estrategia dominante tanto para searchers como para builders).
3. Mantenga la eficiencia económica (construyendo bloques que maximicen el bienestar social).
4. Permanezca computacionalmente factible dentro de las estrictas restricciones de tiempo de la producción de bloques (por ejemplo, ranuras de 12 segundos).

Propuestas existentes como BuilderNet no logran proporcionar garantías sólidas de compatibilidad de incentivos porque no gobiernan explícitamente la interacción entre searchers y builders ni imponen reglas sobre cómo se procesan los flujos de órdenes.

2. Metodología: El Marco de Trabajo Boost+ y el Mecanismo MBoost+

Los autores proponen Boost+, un sistema que desacopla la recolección de transacciones de la ejecución de algoritmos, ejecutándose dentro de un Entorno de Ejecución Confiable (TEE) para asegurar la confidencialidad e integridad. El sistema modela explícitamente tres actores: Proposers, Builders y Searchers.

El Mecanismo MBoost+

El núcleo de Boost+ es el mecanismo MBoost+, que opera en dos etapas para determinar el bloque final y la asignación de valor:

1. Separación Libre de Conflictos: El mecanismo primero identifica paquetes libres de conflictos (conflict-free bundles) (transacciones que no leen/escriben en los espacios de almacenamiento tocados por otros). Estos se separan del conjunto principal y se anexan al bloque ganador final independientemente del resultado, asegurando que siempre se incluyan con un pago neto de cero (el reembolso es igual a la puja).
2. Ejecución de Dos Fases:
   • Fase 1 (Algoritmo por Defecto): Un algoritmo por defecto (diseñado por el sistema) procesa los paquetes restantes para generar un "bloque por defecto" ($o^*$) y computar los contrafactuales de los bloques ($o_{-i}$) para cada paquete para determinar los reembolsos. Esta fase establece una base para el bienestar y los reembolsos.
   • Fase 2 (Algoritmos de Builders): Los builders presentan sus propios algoritmos de construcción de bloques. El mecanismo los ejecuta sobre el mismo conjunto de paquetes para generar bloques candidatos.
3. Selección de Ganador y Pago:
   • Si el algoritmo por defecto gana: El mecanismo utiliza el bloque por defecto. Los searchers pagan sus pujas, reciben reembolsos calculados mediante una fórmula de estilo Vickrey–Clarke–Groves (VCG) basada en los contrafactuales del algoritmo por defecto, y el proposer recibe el excedente. Los builders no reciben nada.
   • Si un builder gana: El builder ganador paga su puja al mecanismo. El mecanismo reembolsa a los searchers basándose en los contrafactuales del algoritmo por defecto (no de los del ganador), asegurando que los searchers no sean penalizados por el algoritmo específico del ganador. El builder ganador recibe un excedente igual a su puja menos la segunda puja más alta (o la puja por defecto), operando efectivamente como una subasta de segundo precio entre builders.

Garantías Teóricas

• Builder-DSIC: La puja veraz es una estrategia dominante para los builders, ya que participan en una subasta de segundo precio con un precio de reserva establecido por el algoritmo por defecto.
• Searcher-DSIC (Dominancia del Algoritmo por Defecto): Si el algoritmo por defecto supera a todos los builders, la puja veraz es una estrategia dominante para los searchers.
• Searcher-DSIC (Libre de Conflictos): Para los paquetes libres de conflictos, la puja veraz es una estrategia dominante en todos los escenarios, incluso si un builder gana.
• Resistencia a la Integración: Para los paquetes libres de conflictos, la estrategia de "participar y pujar verazmente" domina débilmente cualquier estrategia que implique la integración con un builder. La integración no ofrece ninguna ganancia de utilidad conjunta y puede reducirla.

El Algoritmo por Defecto

Para asegurar que el mecanismo sea computacionalmente factible, los autores proponen un algoritmo por defecto concreto basado en el análisis empírico de las transacciones de Ethereum:

• Agrupación de Conflictos: Las transacciones se agrupan según los conflictos de lectura/escritura de almacenamiento.
• Resolución Híbrida:
  • Para grupos de conflicto pequeños (tamaño $< k_{cutoff}$), el algoritmo realiza una enumeración exhaustiva para encontrar el subconjunto óptimo.
  • Para grupos grandes, aplica optimizaciones estructurales (por ejemplo, si los conflictos son puramente transferencias de ERC-20, el orden es irrelevante; si es un escenario de "sandwich", solo un paquete puede ganar).
  • Si no aplica ninguna simplificación, selecciona determinísticamente un subconjunto de transacciones para que la permutación sea factible.
• Propiedades: El conjunto de bloques candidatos considerado por este algoritmo es independiente de las pujas, un requisito crítico para mantener la compatibilidad de incentivos de tipo VCG.

3. Contribuciones Clave

1. Arquitectura Boost+: Un nuevo sistema de construcción de bloques que gobierna explícitamente las interacciones entre searcher y builder, separando la recolección de transacciones del ordenamiento para asegurar el acceso igualitario.
2. Mecanismo MBoost+: Un mecanismo que logra la compatibilidad de incentivos para builders y searchers (bajo condiciones específicas) mientras recompensa la innovación algorítmica. Logra desacoplar con éxito el mecanismo VCG "perfecto" (que es computacionalmente inviable) de la necesidad práctica de la participación de los builders.
3. Resistencia a la Integración en Conflictos Libres: Prueba teórica de que para los paquetes libres de conflictos, la no integración combinada con la puja veraz es una estrategia dominante, neutralizando efectivamente el principal motor de la centralización para una clase significativa de transacciones.
4. Algoritmo por Defecto Informado Empíricamente: Una implementación concreta de un algoritmo por defecto que satisface las propiedades teóricas necesarias. La evaluación muestra que construye el bloque óptimo en el 53.2% de los casos.

4. Resultados y Evaluación

• Optimicidad: Utilizando un conjunto de datos de 10,000 bloques de Ethereum (2.9M de transacciones públicas, 56M de paquetes privados), el algoritmo por defecto produjo el bloque de mayor valor en el 53.2% de los casos.
• Brecha de Eficiencia: En los casos no óptimos, la diferencia absoluta mediana en el valor del bloque fue de 0.0033 ETH, con una diferencia relativa mediana del 8.6%. La brecha de rendimiento se amplía para bloques con alto MEV (valor > 1 ETH), donde el algoritmo por defecto alcanza la optimicidad en solo ~5% de los casos, debido principalmente a la dificultad de manejar grandes grupos de conflicto sin una búsqueda exhaustiva.
• Tiempo de Ejecución: El algoritmo por defecto aprovecha eficazmente el multiprocesamiento (multi-threading). Con 50 hilos, su tiempo de ejecución se acerca al de los algoritmos de construcción de bloques paralelos, lo que lo hace viable para las ranuras de 12 segundos.
• Análisis de Conflictos: El estudio empírico reveló que en la mayoría de los bloques, los grupos de conflicto son pequeños (a menudo de tamaño 1), y los grupos de conflicto grandes (tamaño $\ge 8$) son raros (ocurriendo en < 4 grupos por bloque en la mayoría de los casos), validando la viabilidad del enfoque híbrido.

5. Significado y Reivindicaciones

El artículo afirma que Boost+ ofrece una solución con principios para la centralización e ineficiencia del ecosistema MEV actual. Al modelar explícitamente la interacción entre searcher y builder y aplicar un algoritmo por defecto con conjuntos de candidatos independientes de las pujas, el sistema:

• Restaura la Competencia: Elimina la ventaja estructural de la integración para las transacciones libres de conflictos.
• Incentiva la Innovación: Recompensa a los builders que desarrollan algoritmos superiores sin comprometer la compatibilidad de incentivos de los searchers.
• Equilibra Teoría y Práctica: Reconoce que lograr una eficiencia "perfecta" (maximizar el bienestar social) junto con una compatibilidad de incentivos "perfecta" es computacionalmente intratable (NP-duro). En su lugar, Boost+ ofrece una solución práctica "suficientemente buena" que es demostrablemente compatible de incentivos para los builders y para los searchers en los escenarios más críticos (libres de conflictos y dominancia del algoritmo por defecto).

Los autores concluyen que, mientras que un mecanismo "perfecto" (solo VCG) es teóricamente limpio pero prácticamente ineficiente, y un mercado de solo builders reintroduce riesgos de integración, Boost+ establece un equilibrio necesario. Utiliza un algoritmo por defecto para anclar la compatibilidad de incentivos y la eficiencia, permitiendo al mismo tiempo la participación de los builders para elevar el bienestar, siempre que el sistema pueda gestionar la complejidad resultante. El artículo señala que se necesita más trabajo para abordar los ataques Sybil y para mejorar el manejo de los grandes grupos de conflicto para aumentar la tasa de optimicidad más allá del 53.2%.