Anza, el equipo de desarrollo detrás del cliente validador Agave, ha presentado Constellation, la primera propuesta formal de Multiple Concurrent Proposers (MCP) para Solana. La idea es romper con el modelo tradicional de producción de bloques, en el que un único validador decide durante su turno qué transacciones incluir y en qué orden. Con Constellation, la red pasaría a contar con 16 proponentes simultáneos y 256 certificadores que limitan estructuralmente la capacidad de censura y las formas más dañinas de MEV (valor extraíble).
Dicho de otro modo, se busca democratizar el acceso al espacio de bloques. En la actualidad, el líder temporal tiene un monopolio peligroso: puede observar las transacciones antes que nadie, reordenarlas a su favor e incluso excluirlas por completo. Esto genera incentivos económicos perversos que, con el crecimiento de Solana, se traducen en extracción de valor a costa de los usuarios. Constellation aspira a eliminar esta ventana de abuso desde el propio protocolo.
Cómo funciona Constellation: proponentes, certificadores y pslices
La arquitectura de Constellation se apoya en dos nuevos roles: los proponentes y los certificadores. Cada 50 milisegundos, aproximadamente 16 proponentes reciben las transacciones entrantes y las ensamblan en fragmentos codificados —lo que el documento llama pslices— que distribuyen a los 256 certificadores. Estos certificadores emiten un registro criptográfico que vincula al líder con el conjunto de transacciones que ha visto. Si un número suficiente de certificadores ha dado fe de un pslice, el líder no puede excluir esa transacción sin producir un bloque inválido, que la red rechazaría por consenso.
Esto otorga lo que la propuesta denomina “resistencia selectiva a la censura”: en cada ciclo, o bien todas las transacciones competitivas en comisiones son incluidas, o no lo es ninguna. En esencia, se elimina la posibilidad de que un líder censure a discreción sin que el resto de la red se dé cuenta.
Sin embargo, Constellation deja sin resolver algunos problemas. Los ataques de reordenación basados en el contenido visible y los juegos de latencia temporal —en los que un actor adelanta transacciones porque ve el contenido antes que otros— siguen siendo posibles. De hecho, al hacer que las transacciones sean visibles para todos los proponentes, la superficie de ataque se amplía en lugar de reducirse. Los propios diseñadores reconocen que las “guerras de latencia” son, por ahora, “imposibles de castigar”.
Constellation no acepta el monopolio del líder y gestiona sus consecuencias; lo estructura para hacer imposible la forma más dañina de MEV.
Qué gana Solana con esta propuesta (y qué pierde)
La gran ventaja es una garantía de inclusión. Hoy, una transacción depende de que el líder la incluya en su bloque. Con MCP, los usuarios envían su transacción a varios proponentes y reciben una confirmación de que ha sido certificada. El líder se convierte en un mero ensamblador con escaso margen de maniobra. Además, las comisiones se reestructuran: la tasa de inclusión actual (similar a la base fee) y la tasa de ordenación (la priority fee) pasan a discurrir dentro del protocolo. El gran cambio económico es que los servicios de aterrizaje fuera de protocolo y los acuerdos de comisiones fuera de la cadena deberían volver a la red, devolviendo transparencia al mercado.
Por el contrario, la latencia de secuenciación aumenta. El ciclo de 50 ms, la ronda de certificadores y el ensamblaje añaden tiempo respecto a la entrega directa a la Transaction Processing Unit (TPU) del líder actual. Sin embargo, la latencia de inclusión se reduce: una transacción válida recibe una promesa de inclusión en un tiempo acotado, algo que hoy no existe. Para un validador que empaqueta transacciones rápidamente, el nuevo sistema puede resultar más lento; para uno que las retrasa, el rendimiento mejora.
Otro punto delicado es la selección de roles basada en la participación en staking. Esto significa que la concentración actual en pocos grandes validadores se traslada directamente a los nuevos roles, con un reparto de poder que puede no democratizar tanto como se pretende. Anza advierte que el impacto neto en cada validador individual no se podrá modelar hasta que llegue la propuesta técnica definitiva (la futura SIMD).
La apuesta a largo plazo: eliminar el MEV en lugar de gestionarlo
Constellation representa un cambio de filosofía. Frente al modelo de Proposer-Builder Separation (PBS) de Ethereum, que acepta el MEV como inevitable y lo redistribuye a través de subastas, Anza opta por hacerlo inviable desde el protocolo. Tal y como recoge el análisis de Helius, si el registro de certificación ya limita la discreción del líder, no queda nada que un constructor especializado pueda vender. Es una ruptura con la línea marcada por soluciones como Jito, cuyo motor de bloques funciona de manera análoga al MEV-Boost de Ethereum: subasta el orden de las transacciones y reparte los beneficios entre validadores y delegadores, sin eliminar la extracción de valor.
El verdadero interrogante son las pruebas de rendimiento. Las simulaciones en condiciones de red reales aún no existen, y el dato más importante que Anza puede ofrecer —las proyecciones de latencia comparativa para slots de 200 milisegundos bajo el protocolo actual y bajo Constellation— sigue ausente. Sin esa información, la comunidad debate sobre compensaciones que no puede cuantificar. Constellation está prevista para construirse sobre Alpenglow, el próximo gran hito del roadmap de Solana cuyo lanzamiento en la red principal se ha fijado para el tercer trimestre de 2026.
Si los números cuadran, Constellation podría ser la respuesta definitiva al problema de la censura y acercar a Solana al ideal de un mercado financiero justo y transparente definido por el código, no por la jurisdicción. Si no, el ecosistema habrá dado un paso adelante en su madurez técnica, marcando una senda propia frente a Ethereum, pero con el piloto automático de un riesgo de rendimiento que nadie puede aún descartar.
