Constellation: una propuesta de MCP en Solana

Conclusiones prácticas

• Constellation es la primera propuesta formal a nivel de protocolo para implementar múltiples proponentes concurrentes (MCP) a escala en una blockchain en producción.
• Constellation introduce dos roles nuevos (es decir, proponentes y atestadores) que limitan la discreción del líder sobre la construcción de bloques. Aproximadamente 16 proponentes operan de forma concurrente en ciclos de 50 ms y agrupan transacciones en pslices con codificación de borrado que se distribuyen a 256 atestadores. El registro de atestación vincula criptográficamente al líder con el conjunto de transacciones que incluye. Si una cantidad suficiente de atestadores certifica un pslice, el líder no puede excluir la transacción sin producir un bloque no válido que la red rechazará.
• Constellation ofrece resistencia selectiva a la censura: en cada ciclo, se incluyen todas las transacciones con comisiones competitivas o no se incluye ninguna.
• Los ataques de ordenamiento con contenido visible y de manipulación temporal siguen sin resolverse. Con Constellation, las transacciones son visibles para todos los proponentes que las reciben al momento de su envío. Debido a la arquitectura multiproponente de MCP, esto podría ampliar estas superficies de ataque en lugar de reducirlas. El diseño actual reconoce que no es posible penalizar las estrategias de latencia basadas en el tiempo.
• Constellation reestructura las comisiones existentes: la comisión de inclusión corresponde a la comisión base actual y la comisión de ordenamiento corresponde a la comisión de prioridad existente. El cambio económico más importante es que la actividad que hoy fluye por servicios de inclusión externos al protocolo y acuerdos de comisiones fuera de la cadena debería volver al protocolo. La selección de roles ponderada por stake mantiene las dinámicas de concentración existentes, y el impacto neto sobre cada validador no podrá modelarse hasta que se publique el futuro SIMD de Constellation.
• MCP aumenta la latencia de secuenciación, pero reduce la latencia de inclusión. La ronda de atestadores, la ventana de ciclo de 50 ms y el ensamblaje por lotes añaden tiempo frente a la ruta actual de envío directo a la TPU. Hoy, la latencia es mayor para los validadores que empaquetan de inmediato las transacciones de la TPU y menor para quienes las retrasan. Con Constellation, las transacciones válidas cuentan con una garantía de inclusión acotada y aplicada por el protocolo.
• Constellation es explícitamente incompatible con los modelos de separación entre proponente y constructor (PBS). Una vez que el registro de atestación limita la discreción del líder, no queda nada que un constructor especializado pueda vender. Este enfoque representa una filosofía esencialmente distinta de la estrategia actual de Ethereum frente al MEV.
• Aún no existen pruebas de rendimiento empíricas bajo condiciones de red realistas. El dato más importante que Anza puede proporcionar son proyecciones comparativas de latencia para slots de 200 ms con el protocolo actual frente a slots de 200 ms con Constellation. Hasta que estos datos estén disponibles, la comunidad seguirá debatiendo concesiones que no puede cuantificar.
• Constellation se construye sobre Alpenglow, cuyo lanzamiento en mainnet está previsto para el tercer trimestre de 2026.

Introducción

Pese a la sorprendente ausencia de plantas de agave, Brennan Watt, CEO de Anza, viajó al desierto de California para presentar Constellation, una propuesta para incorporar múltiples proponentes concurrentes (MCP) a Solana. Es la actualización estructuralmente más ambiciosa y, posiblemente, la propuesta de MCP a nivel de protocolo más importante que una blockchain en producción haya presentado hasta ahora. Busca resolver el monopolio temporal del líder sobre el ordenamiento de transacciones y el valor extraíble que genera. Constellation democratiza el espacio de bloques en Solana.

Este artículo presenta un análisis crítico de Constellation: qué resuelve, qué pospone de forma consciente y qué sigue realmente sin resolverse. Presentamos un marco de tres capas para evaluar la resistencia a la censura, comparamos Constellation con el panorama actual de MCP y analizamos si las concesiones que introduce son compatibles con la identidad de rendimiento que Solana ha construido.

Se asume que ya conoces Alpenglow.

El problema que resuelve Constellation

Las transacciones son el motor de Solana. Se agrupan y se registran permanentemente en la red como bloques. Sin embargo, el proceso para decidir qué transacciones entran en esos bloques y en qué orden no es neutral.

El monopolio del líder sobre la producción de bloques

La producción de bloques rota según un calendario de líderes, en el que un validador a la vez es responsable de producir bloques durante una ventana determinada.

Durante este periodo, las transacciones se reenvían directamente a la unidad de procesamiento de transacciones (TPU) del líder, donde el líder suele recibirlas antes que los demás.

El líder ocupa una posición de poder excepcional. Es decir, puede observar las transacciones entrantes antes de que sean visibles públicamente.

El líder puede decidir no incluir algunas transacciones, reordenarlas de manera arbitraria o introducir las suyas.

Esta es una característica estructural del funcionamiento actual del consenso con un solo líder y está presente, en distintos grados, en prácticamente todas las blockchains de prueba de participación en producción.

La ausencia de un mempool público en Solana acentúa esta asimetría en lugar de reducirla. El mempool público de Ethereum ofrece a los participantes cierta visibilidad sobre las transacciones pendientes, lo que genera una especie de igualdad de condiciones entre los actores sofisticados que compiten por aprovechar el ordenamiento de transacciones.

En Solana, la ventaja informativa del líder es más difícil de disputar debido a la naturaleza del reenvío de transacciones.

Valor máximo extraíble (MEV)

En condiciones normales y con validadores honestos, este poder se aprovecha muy poco. Sin embargo, los validadores son actores económicos racionales. A medida que Solana madura y la actividad financiera sigue creciendo, también aumenta la ganancia disponible por explotar el monopolio temporal del líder. Un validador que decide no aprovechar esta posición simplemente está dejando dinero sobre la mesa. Los nodos que se comportan correctamente quedan en desventaja económica, lo que los incentiva a deteriorar la calidad del mismo sistema en el que participan.

Esta ganancia extraíble se conoce como valor máximo extraíble (MEV), un término formalizado por primera vez por Daian et al. en Flash Boys 2.0 como valor extraíble por mineros, antes de aplicarse a redes de prueba de participación. Abarca desde el arbitraje y el frontrunning hasta los ataques sándwich, la censura selectiva y cualquier estrategia que aproveche la ventaja informativa y posicional del líder frente a los usuarios cuyas transacciones procesa.

La principal respuesta de la industria al MEV ha sido el modelo de separación entre proponente y constructor (PBS), implementado en Ethereum mediante MEV-Boost. Con PBS, constructores especializados compiten para crear bloques que maximicen el valor extraíble, y los proponentes simplemente seleccionan el bloque más rentable para su producción. Es un replanteamiento pragmático del problema que busca democratizar el acceso al MEV y redistribuir sus beneficios entre el conjunto de validadores, en lugar de concentrarlos en los actores más sofisticados, porque este modelo asume que la extracción de MEV es inevitable.

El problema de este planteamiento es que PBS no reduce el daño a los usuarios: la extracción sigue ocurriendo; solo cambian los beneficiarios. PBS aborda algunos de los efectos negativos del MEV para los nodos de la red, pero no reduce el daño a sus usuarios.

Solana tiene su propia relación cambiante con el MEV. La combinación de tiempos de bloque rápidos, el envío directo a la TPU y un conjunto competitivo de validadores ha generado un panorama de MEV particular, caracterizado por spam, subastas de comisiones de prioridad y reordenamiento de transacciones a nivel del validador. El motor de bloques de Jito puede considerarse parcialmente análogo a MEV-Boost, ya que proporciona un mecanismo de subasta fuera de la cadena en el que los buscadores ofertan por el ordenamiento de transacciones y los ingresos se comparten entre validadores y participantes de staking. Es decir, al igual que PBS, Jito administra y redistribuye el MEV de forma más democrática en vez de eliminarlo por completo.

Constellation busca solucionar esto. En lugar de aceptar el monopolio del líder y gestionar sus consecuencias, intenta contenerlo estructuralmente para impedir por diseño las formas más perjudiciales de MEV. El documento técnico de Constellation presenta esta ambición como la «infraestructura de los mercados de capitales de Internet, un espacio universal para la actividad económica en el que los usuarios pueden confiar en que la estructura del mercado es justa».

Los mercados financieros tradicionales intentan imponer protecciones similares mediante regulación y supervisión jurisdiccional. Estas protecciones son reactivas y desiguales, y han demostrado repetidamente ser insuficientes. Constellation busca imponer la equidad a nivel del protocolo para que no pueda eludirse ni aplicarse de forma selectiva. Para lograrlo, Constellation propone implementar múltiples proponentes concurrentes (MCP) en Solana.

Múltiples proponentes concurrentes

En una blockchain tradicional con un solo líder, un validador es responsable de producir cada bloque. Este validador (es decir, el líder) mantiene temporalmente el control exclusivo sobre la inclusión y el ordenamiento de transacciones. Mientras este validador está autorizado para producir bloques, los demás participantes de la red son observadores pasivos durante esa ventana. En última instancia, el líder decide qué transacciones se incluyen y en qué orden.

Este diseño resulta atractivo por su sencillez. Tener un solo validador a cargo de la producción de bloques elimina la sobrecarga de coordinación, las propuestas en conflicto que deban resolverse y ofrece un modelo claro de responsabilidad. Sin embargo, también crea un único punto de explotación. El monopolio temporal del líder es la causa raíz del MEV, y todas las mitigaciones importantes hasta ahora han aceptado esta estructura y buscan gestionar sus consecuencias.

Los múltiples proponentes concurrentes (MCP) son una clase de diseño de protocolo que rompe este monopolio a nivel estructural. En lugar de rotar hacia un solo líder con derechos exclusivos sobre la producción de bloques, MCP permite que varios nodos propongan transacciones simultáneamente. Ningún proponente controla el conjunto completo de transacciones. En cambio, sus propuestas se combinan, por lo general mediante un rol de ensamblador restringido, de acuerdo con las reglas del protocolo.

Un usuario que envía una transacción a varios proponentes al mismo tiempo ya no depende de un solo nodo, pues ahora tiene múltiples rutas independientes para lograr la inclusión. Un líder que intenta excluir su transacción debe afrontar el hecho de que otros proponentes ya la vieron y los atestadores ya la certificaron. Un solo líder ensambla el bloque final, pero su discreción está estrictamente limitada.

La principal concesión de MCP es la complejidad de coordinación. Permitir que varios nodos propongan transacciones simultáneamente plantea preguntas que los diseños con un solo líder evitan por completo. ¿Cómo se resuelven las transacciones en conflicto cuando dos proponentes incluyen la misma transacción? ¿Cómo se determina el orden entre propuestas? ¿Cómo se evita que un proponente sofisticado manipule las reglas de combinación? Esto añade una complejidad considerable al protocolo: los equipos deben afrontar desafíos de coordinación relacionados con nuevos roles de nodos, lógica de programación, supuestos criptográficos y modos de fallo, y todo ello requiere pruebas rigurosas.

Conviene ser precisos, porque MCP se usa de forma imprecisa en toda la industria para referirse a distintos diseños con propiedades considerablemente diferentes. En su nivel más básico, MCP ofrece resistencia probabilística a la censura: una transacción enviada a varios proponentes es más difícil de censurar, ya que hacerlo exige coordinación entre múltiples nodos. En un nivel superior, MCP puede ofrecer resistencia estructural a la censura: se vuelve matemáticamente imposible que el líder produzca un bloque que censure una transacción certificada por un cuórum suficiente. Esto es lo que busca Constellation, y la diferencia es crucial para las aplicaciones financieras que requieren garantías firmes.

Constellation: cómo funciona

Constellation es un protocolo para implementar MCP en Solana. Complementa a Alpenglow: Alpenglow gestiona el consenso (es decir, seguridad, vivacidad y finalidad), mientras que Constellation gestiona la estructura del mercado: quién puede proponer transacciones, cómo se reconocen esas propuestas y qué puede hacer el líder con ellas. Constellation produce la carga útil que Alpenglow finaliza.

Arquitectura

Constellation introduce dos roles nuevos en la pila de protocolos de Solana, cada uno con una responsabilidad distinta, y modifica los roles de los líderes y validadores.

Los proponentes son el punto de entrada de las transacciones. En todo momento hay aproximadamente 16 proponentes activos de forma concurrente, seleccionados aleatoriamente según su stake y rotados cada 32 ciclos (es decir, cada ~1.6 segundos). Los usuarios envían sus transacciones directamente a uno o más proponentes de su elección. Cada proponente puede aceptar o rechazar cualquier transacción, con la condición de que las transacciones aceptadas sean válidas. En esta etapa no hay ninguna regla del protocolo que imponga la inclusión de transacciones; la garantía de resistencia a la censura aparece más adelante en el flujo. Cada proponente opera en un ciclo de 50 milisegundos. Dentro de cada ciclo, el proponente agrupa las transacciones aceptadas en una estructura llamada pslice. El prefijo «p» es mudo y solo se usa para diferenciarla de los slices de Alpenglow. El pslice se divide mediante codificación de borrado en 256 fragmentos más pequeños, llamados pshreds, y se distribuye un pshred a cada uno de los 256 atestadores activos. La codificación de borrado utiliza un umbral de recuperación de 64, lo que significa que cualquier conjunto de 64 de los 256 pshreds basta para reconstruir el pslice completo. Cada pshred contiene un compromiso de hash criptográfico con la lista completa de transacciones. Esto garantiza que el líder no pueda sustituir transacciones ni alterar el orden dentro de un pslice después de que los atestadores lo hayan aprobado.

Los atestadores reciben pshreds de un proponente y los reenvían de inmediato a los siguientes ~2 líderes para contemplar posibles fallos o ausencias. También registran el hash de compromiso del pslice recibido. Al final de cada ciclo, el atestador firma una atestación: una declaración criptográficamente vinculante que enumera todos los hashes de compromiso de pslices que observó durante ese ciclo. Esta atestación se envía al líder y funciona como el registro probatorio que limita las transacciones que el líder puede incluir. El registro está firmado y ponderado por stake, por lo que no puede falsificarse ni ignorarse silenciosamente.

El líder de Constellation es el mismo que el de Alpenglow: el nodo responsable de producir el bloque final que entra en consenso. La diferencia con Constellation es que el registro de atestación limita estrictamente la discreción del líder. Constellation aplica dos umbrales distintos. Para que la atestación agregada sea válida, debe participar al menos el 60 % de los atestadores. Si no se alcanza este umbral, se omite todo el bloque. Dentro de ese grupo, el líder debe incluir cualquier pslice certificado por al menos el 40 % de los atestadores. Si no lo hace, produce un bloque no válido que la red rechazará. Este diseño de dos umbrales separa la validez a nivel de bloque de la inclusión por proponente. Es decir, el líder puede producir un bloque válido aunque los datos de algunos proponentes no hayan llegado a suficientes atestadores, pero no puede excluir selectivamente a los proponentes cuyos datos sí lo hicieron. Una vez que el líder compila todos los pslices certificados en un lote, transmite ese lote a los validadores mediante Rotor de Alpenglow.

Los validadores reciben lotes del líder mediante Rotor y los ejecutan en cadena de procesamiento a medida que llegan. Una vez recibido el bloque completo, los validadores lo comparan con el registro de atestación para confirmar que cada pslice certificado tenga su envío correspondiente en el bloque. Solo si supera todas las verificaciones, el validador vota para finalizarlo. Si las verificaciones fallan, los validadores votan para omitir toda la ventana del líder mediante la llamada TrySkipWindow.

Ciclos y bloques

Un ciclo es la unidad de tiempo fundamental de Constellation. Es una ventana de 50 milisegundos derivada del tiempo de reloj UTC al dividir la marca de tiempo Unix en nanosegundos entre 50,000,000. Es importante destacar que los ciclos no están alineados con los slots de Alpenglow. Un slot contiene varios ciclos, y los lotes producidos durante esos ciclos constituyen la carga útil del bloque del líder. Esta distinción importa porque el ciclo de 50 ms es el intervalo económico (es decir, la ventana durante la cual se aplica la resistencia a la censura), mientras que el slot sigue siendo la unidad de consenso de Alpenglow.

El documento técnico especifica una tolerancia para la desviación de reloj entre proponentes y atestadores, y ajusta la ventana de atestación en consecuencia. Para ilustrar por qué esto importa, supongamos que el reloj de un proponente está 5 ms adelantado respecto al conjunto de atestadores. Los pshreds de este proponente podrían llegar a los atestadores antes de lo previsto con relación al límite del ciclo, lo que daría a las transacciones de ese pslice una ventana ligeramente mayor para acumular atestaciones. Por el contrario, un proponente cuyo reloj esté atrasado podría descubrir que sus pshreds llegan tan tarde que quedan completamente fuera de la ventana de atestación, aunque los haya enviado «a tiempo». En entornos de centros de datos que usan herramientas como chrony o receptores GPS, la sincronización de relojes es habitual y la desviación suele ser inferior a un milisegundo, muy dentro de los límites de tolerancia de Constellation. La preocupación es que Constellation introduce una variable nueva que no existía en el modelo de tiempo puramente lógico de Alpenglow y para la cual el futuro SIMD de Constellation debería especificar límites de monitoreo.

Cuando Constellation se acerca al final de una época, los proponentes y atestadores pueden no tener claro por un breve periodo si la siguiente época ya comenzó. Durante esta ventana, Constellation opera en ambas épocas de forma concurrente, con dos conjuntos de proponentes y atestadores activos al mismo tiempo. El consenso de Alpenglow resuelve de forma natural qué ciclos pertenecen a cada época.

Ciclo de vida y comisiones de las transacciones

Una transacción debe atravesar cuatro controles antes de ejecutarse:

• Un proponente debe aceptarla e incluirla en un pslice.
• Ese pslice debe acumular suficientes atestaciones para incluirse en el lote del líder.
• La transacción debe tener una oferta lo bastante alta para ser seleccionada para ejecución dentro del límite de cómputo del lote.
• El consenso de Alpenglow debe confirmar el bloque que contiene el lote.

Cada transacción incluye una oferta (es decir, la comisión de ejecución por unidad de cómputo) que determina su posición dentro del mismo lote. Las ofertas más altas se ejecutan primero.

Constellation divide el costo de una transacción en dos comisiones diferentes:

• Una comisión de inclusión.
• Una comisión de ordenamiento.

La comisión de inclusión es un cargo fijo y pequeño basado en el tamaño de la transacción y su número de firmas. Se paga al proponente que incluyó la transacción en su pslice y se cobra desde el momento en que la transacción cruza el umbral de atestación, sin importar si finalmente se ejecuta. Es análoga a la comisión base del sistema actual de Solana, pero con una salvedad importante: si un usuario envía la misma transacción a tres proponentes para obtener redundancia, paga tres veces la comisión de inclusión (es decir, una por proponente), ya que cada proponente realizó de forma independiente el trabajo de incluirla. Por lo tanto, si un usuario envía la misma transacción a n proponentes distintos para obtener redundancia, paga n veces la comisión de inclusión.

La comisión de ordenamiento es el componente más grande y se basa en la prioridad. Equivale al total de unidades de cómputo de la transacción multiplicado por su oferta. Se cobra solo una vez porque la transacción solo puede ejecutarse una vez, sin importar cuántos proponentes la incluyan. Por ejemplo, una transacción que solicita 200,000 unidades de cómputo con una oferta de 0.00001 SOL por unidad de cómputo paga una comisión de ordenamiento de 2 SOL. Si esa misma transacción se envía a cuatro proponentes para obtener redundancia, el usuario paga cuatro comisiones de inclusión más una sola comisión de ordenamiento de 2 SOL. La comisión de ordenamiento vuelve al ecosistema en proporción al stake de los nodos. El documento técnico deja el diseño de este mecanismo para su futuro SIMD.

Cada cuenta que paga comisiones debe mantener un saldo de reserva mínimo de aproximadamente 0.001 SOL para evitar la manipulación de comisiones entre proponentes concurrentes. Esto garantiza que las comisiones de inclusión siempre puedan pagarse, incluso cuando varios proponentes incluyen al mismo tiempo transacciones que afectan a la misma cuenta.

Constellation y Alpenglow

Alpenglow es el protocolo de consenso de Solana. Determina qué bloques son válidos, el orden en que se finalizan y cómo se recupera la red de los fallos. Sus componentes Votor y Rotor reemplazan a Tower BFT y la propagación de votos basada en gossip, lo que reduce considerablemente el tiempo de finalidad. Alpenglow no define quién propone las transacciones ni cómo se determina su orden dentro de un bloque.

Constellation es una capa de estructura de mercado que limita lo que el líder de Alpenglow puede hacer con los bloques que ensambla. Define quién propone transacciones y cómo se determina el orden dentro de cada bloque. Los lotes que produce Constellation se convierten en la carga útil de los bloques de Alpenglow. Votor de Alpenglow certifica entonces esos bloques según sus reglas de votación predefinidas. Ambos protocolos se combinan de manera que Alpenglow proporciona seguridad y vivacidad, mientras que Constellation ofrece equidad en el ordenamiento.

Esta capacidad de composición también permite que Constellation herede los supuestos de seguridad de Alpenglow sin debilitarlos. Constellation no modifica las garantías de Alpenglow. En cambio, introduce nuevas garantías y supuestos para los nuevos roles de proponente y atestador, además de la sincronización con el reloj UTC en su nuevo modelo temporal basado en ciclos.

Constellation es la primera propuesta formal a nivel de protocolo para implementar MCP en una blockchain escalable y en producción. Es una incorporación importante para introducir resistencia a la censura en Solana: el siguiente capítulo de la hoja de ruta del protocolo que Alpenglow hace posible.

Lo que realmente requiere la resistencia a la censura

Históricamente, la literatura sobre MEV ha abordado el problema desde varias perspectivas distintas que, en conjunto, trazan una visión más unificada de lo que cualquier propuesta de resistencia a la censura realmente debe resolver. A partir de la taxonomía fundamental de ataques de frontrunning de Eskandari et al., el marco formal de dos propiedades para protocolos MCP de Garimidi et al. y el análisis de Landers y Marsh sobre los canales de MEV específicos de MCP, proponemos organizar la superficie de ataque en tres capas distintas, cada una de las cuales requiere un tipo diferente de solución. Este marco es nuestra propia síntesis y lo presentamos aquí para evaluar el diseño de Constellation.

Capa 1: censura dura

La censura dura se refiere a la capacidad de un líder o proponente para negarse a incluir una transacción que ha identificado. Es la forma más evidente de manipulación y Constellation la resuelve de manera estructural. Con Constellation, es criptográficamente imposible que un líder produzca un bloque válido que excluya una transacción competitiva en comisiones y atestiguada por un cuórum suficiente de atestadores. Esto no requiere slashing, ya que la aplicación de las reglas es arquitectónica.

Capa 2: ordenamiento con contenido visible

La segunda capa es más difícil de abordar. Aunque los proponentes no pueden censurar directamente, todavía pueden observar el contenido de una transacción antes del ordenamiento final e intentar aprovechar esa visibilidad (por ejemplo, mediante un ataque sándwich contra una operación grande). Esto es lo que Garimidi et al. formalizan como la propiedad de ocultamiento: un adversario no debe poder ver el contenido de las transacciones antes de que se confirmen. Constellation implementa un ocultamiento parcial. Es decir, una transacción solo es visible para el proponente que la recibe, no para todos los proponentes, y el líder solo ve su contenido una vez que ha vencido el plazo del ciclo. Esto es mejor que la visibilidad total, pero no satisface por completo la propiedad de ocultamiento de Garimidi et al., que exige que el contenido de una transacción permanezca invisible para todas las partes antes de la confirmación. El proponente receptor todavía puede observar y explotar el contenido de las transacciones que recibe.

La preocupación más profunda respecto a Constellation es que MCP con envío público de transacciones puede amplificar la explotación del contenido visible. Esto introduce un sistema en el que cada proponente observa las transacciones que recibe y puede aprovechar esa visibilidad dentro de su propio pslice. La superficie de ataque difiere de la del modelo de líder único, ya que varias entidades pueden ver cada una un subconjunto. Un usuario que envía a un solo proponente expone su transacción únicamente a ese proponente. Sin embargo, un usuario que envía a varios proponentes para obtener redundancia amplía su exposición de forma proporcional. Landers y Marsh formalizan esta dinámica: la producción simultánea de bloques crea juegos temporales, oportunidades de duplicación en el mismo tick y la ausencia estructural de un único punto de control del constructor que actualmente limita la cantidad de intentos de extracción que pueden ejecutarse por transacción víctima. Descentralizar el conjunto de proponentes sin abordar la visibilidad del contenido multiplica la superficie de ataque de MEV en lugar de reducirla.

El análisis de Landers y Marsh sobre los canales de MEV específicos de MCP supone una visibilidad del contenido más amplia que la que ofrece Constellation. Con el ocultamiento parcial de Constellation, la amplificación de la explotación del contenido visible depende de la estrategia de envío del usuario y no es una consecuencia arquitectónica inevitable. Un usuario que envía a un solo proponente de confianza tiene un perfil de exposición del contenido similar al del modelo actual de líder único. La desventaja es que enviar a un solo proponente sacrifica la redundancia de la que depende la resistencia a la censura. 

Capa 3: manipulación temporal y de latencia

La capa más sutil y difícil de sancionar se relaciona con la manipulación temporal y de latencia. Con Constellation, un proponente puede retrasar el reenvío de pshreds a los atestadores apenas lo suficiente para que la transacción de un competidor quede fuera de la ventana de atestación, o aprovechar la desviación de los relojes UTC para manipular qué transacciones acumulan suficientes atestaciones. El whitepaper de Constellation reconoce directamente esta brecha: la entrega tardía de mensajes “no puede sancionarse”, ya que no se distingue de un retraso genuino de la red. Esta es la capa en la que el slashing podría cobrar relevancia y la principal pregunta abierta que deberá abordar el futuro SIMD de Constellation. 

Una suposición fundamental del diseño de Constellation es que la relación entre proponente y usuario no es anónima: es una interacción repetida en la que la confianza puede medirse y la reputación importa. Con aproximadamente 16 proponentes activos en cualquier momento, un usuario que reciba sistemáticamente un trato deficiente de uno de ellos puede comenzar a enviar sus transacciones a uno de los otros 15. Aunque esto no crea ningún artefacto onchain que pueda usarse para sancionar directamente a un actor malicioso, sí genera consecuencias económicas para los proponentes que aprovechan su posición. Sigue abierta la pregunta de si esta presión reputacional bastará para disuadir la manipulación temporal frente a una solución como el slashing. La respuesta probablemente dependerá de cuán transparente se vuelva para los usuarios el comportamiento de los proponentes con el tiempo. 

Impacto en validadores y usuarios

Validadores

Constellation redistribuye las oportunidades de MEV entre los validadores en lugar de eliminarlas por completo. La fuente de ingresos más evidente y directamente extraíble disponible para los líderes actuales (es decir, la censura dura) es imposible por diseño. Sin embargo, la reemplaza un conjunto de canales temporales más sutiles y difíciles de sancionar que favorecen a los validadores con ventajas de latencia, sincronización precisa del reloj y la sofisticación necesaria para aprovechar sistemáticamente las ventanas de reenvío de pshreds. El efecto neto es un cambio en la forma en que los validadores extraen valor, en lugar de una reducción de la superficie total de extracción. La única salvedad es que extraerlo se vuelve mucho más difícil.

Constellation no introduce nuevos flujos de comisiones fundamentales, sino que reestructura los existentes. La comisión de inclusión es análoga a la comisión base actual, y la comisión de ordenamiento corresponde a la comisión de prioridad existente. Se espera que los repartos sean similares a los ingresos actuales de los validadores. La diferencia es principalmente operativa. Es decir, los buenos operadores deberían obtener más comisiones de inclusión como proponentes, lo que crea un gradiente basado en el rendimiento dentro de la economía existente en lugar de una categoría de ingresos independiente. En el diseño actual, el rol de atestador no recibe una compensación separada. La justificación es que, al igual que la participación actual en Turbine, se espera que se desempeñe porque genera un beneficio neto para la red. El cambio económico más importante corresponde a la actividad que hoy fluye mediante servicios de aterrizaje fuera del protocolo, subastas basadas en el mercado y acuerdos de comisiones offchain, la cual debería volver al protocolo para beneficiar más directamente a los validadores. Sin embargo, hasta que el SIMD especifique los mecanismos exactos, el impacto económico neto sobre cada validador seguirá siendo una pregunta abierta, especialmente para los más pequeños, donde la selección ponderada por stake reduce la frecuencia como proponente y la sobrecarga de infraestructura eleva el costo mínimo.

Los proponentes y atestadores se seleccionan según el peso del stake, lo que significa que las mismas dinámicas de concentración que determinan la economía de los validadores también definen la participación en estos roles. Si un pequeño número de validadores con alto stake domina la selección de proponentes, la garantía de resistencia a la censura permanece formalmente intacta, pero la diversidad práctica del conjunto de proponentes se reduce, aunque todavía sería una mejora respecto a lo que Solana tiene hoy (es decir, elegir 1 de n frente a elegir 16 de n). La suposición de independencia comienza a debilitarse en la práctica, aunque se mantenga en teoría. Es una preocupación que vale la pena señalar ante la aparición de ofertas de Validator-as-a-Service (VaaS), ya que una sola entidad podría operar varios validadores con un stake elevado. Que el SIMD introduzca mecanismos contra la concentración o incentivos para la selección de proponentes es una cuestión de diseño con implicaciones directas para la solidez de las garantías que anuncia Constellation. 

Usuarios

Para los usuarios, una transacción competitiva en comisiones que se envíe a una cantidad suficiente de proponentes queda protegida, por primera vez, mediante una garantía firme del protocolo contra la exclusión selectiva. Ahora pueden crearse aplicaciones financieras con garantías que simplemente no existían antes, lo que cambia aquello que solo es posible en Solana. 

Los usuarios de alta frecuencia y sensibles al precio ahora deben enviar transacciones a varios proponentes para obtener redundancia. La preocupación es que descentralizar el conjunto de proponentes sin abordar la visibilidad del contenido puede aumentar la exposición a ataques sándwich: cada proponente puede observar y actuar sobre las transacciones que recibe, por lo que los usuarios que las envían a varios proponentes para obtener redundancia aumentan proporcionalmente la cantidad de partes que ven su contenido. Esto elimina de manera inherente el punto de control del líder único y difunde la intención de la transacción a un conjunto más amplio de posibles adversarios. En la práctica, los usuarios más sofisticados deberán desarrollar nuevas estrategias de envío que equilibren redundancia y exposición. Probablemente implicarán seleccionar proponentes según su reputación o stake, por ejemplo, en lugar de usar estrategias amplias de envío múltiple.

Para los creadores de mercado en particular, la garantía de inclusión de Constellation elimina el riesgo adversarial de que la infraestructura determine la calidad de ejecución. Lo que queda es pura asimetría de información, el mismo perfil de riesgo que afrontan hoy los creadores de mercado en los mejores mercados tradicionales. Esta convergencia es lo que hace que el argumento a favor de reducir la latencia de inclusión sea concreto en lugar de aspiracional. Analizamos esta convergencia con más detalle en nuestra sección “Preguntas abiertas”.

Es probable que el cambio neto en la experiencia percibida por el usuario promedio sea marginal, pero la garantía de inclusión representa una mejora importante en confiabilidad. A la espera de futuros benchmarks, el impacto neto sobre la latencia de secuencia sigue siendo una pregunta empírica abierta.

Panorama: cómo se compara Constellation

Sei Giga

Sei Giga es el equivalente más cercano a Constellation en el panorama actual de MCP. Es decir, una blockchain lista para producción que adopta MCP como una prioridad arquitectónica principal y no como un objetivo de investigación futuro. Compararlas resulta instructivo porque toman decisiones diferentes en la misma capa.

La base de consenso de Giga se llama Autobahn, un protocolo BFT multiproponente en el que cada validador opera en paralelo su propio “carril” continuo de propuestas. En lugar de depender de un solo líder, cada nodo difunde continuamente su propio flujo de propuestas de datos en carriles independientes, y la capa de consenso confirma periódicamente un “corte de puntas”, una instantánea compacta que agrega las propuestas más recientes de cada carril. Esto difiere arquitectónicamente del modelo de Constellation, donde aproximadamente 16 proponentes seleccionados operan en un ciclo fijo de 50 ms. El modelo basado en carriles de Autobahn permite que cualquier validador mantenga un carril continuo de propuestas en vez de ser seleccionado de un subconjunto rotativo ponderado por stake. Así amplía drásticamente la participación en la producción de bloques.

La diferencia más importante se relaciona con el ordenamiento con contenido visible. Autobahn permite la ejecución asíncrona al desacoplar el ordenamiento de transacciones de su ejecución, una decisión de diseño que Constellation aplaza. Como explicamos en la siguiente sección, la ejecución asíncrona reduce la superficie de ataque del ordenamiento con contenido visible porque impide que los proponentes simulen los resultados de ejecución contra un estado final conocido al momento de ordenar.

Giga ofrece resistencia probabilística a la censura, mientras que Constellation proporciona garantías estructurales. Giga se basa en la idea de que es más difícil censurar una transacción enviada a varios proponentes, ya que cada uno opera con información incompleta y censurar puede dejar de ser útil si otro proponente incluye la transacción en el mismo tick. En comparación, un líder que excluye una transacción con suficientes atestaciones produce un bloque no válido en Constellation. La resistencia probabilística eleva el costo de la censura, mientras que la resistencia estructural la hace criptográficamente imposible. Para las aplicaciones financieras que ambos protocolos intentan habilitar, la diferencia importa. 

Vale la pena hablar con franqueza sobre la diferencia de ambición entre ambos diseños. Constellation es una especificación de protocolo que demuestra propiedades de corrección, define condiciones de falla, especifica umbrales de cuórum y está destinada a presentarse como propuesta formal para una red escalable en producción con miles de millones en valor en stake. El whitepaper de Sei Giga tiene un enfoque diferente: se orienta a afirmaciones sobre throughput y compatibilidad con EVM, y trata MEV y la resistencia a la censura como beneficios emergentes de la arquitectura multiproponente, no como garantías especificadas formalmente. La ejecución asíncrona avanza en la dirección correcta, pero Giga no proporciona el mismo nivel de garantías formales sobre restricciones de ordenamiento, cuórums de atestadores o condiciones de falla que Constellation. Esto no es una crítica a las decisiones de secuenciación de Giga, sino un reflejo de contextos diferentes. Constellation se propone para la blockchain en producción con el mayor throughput del mundo, lo que exige y proporciona un estándar de especificación correspondientemente superior.

El ideal académico

El referente teórico para el diseño de MCP es Multiple Concurrent Proposers: Why and How (2025), de Garimidi y Neu, de a16z Crypto Research, y Max Resnick, de Anza. El artículo propone un protocolo MCP que ofrece dos propiedades que, según sus autores, debe satisfacer cualquier diseño resistente a la censura: resistencia a la censura selectiva y ocultamiento. La primera garantiza que un adversario no pueda retrasar transacciones de forma selectiva, mientras que la segunda garantiza que su contenido permanezca invisible antes de la confirmación. Es el único diseño MCP de la literatura actual que logra formalmente ambas propiedades a la vez.

El mecanismo que permite el ocultamiento es HECC, o Hiding Erasure-Correcting Code. Está parametrizado de modo que cualquier conjunto de T shreds no revele información sobre el lote de transacciones subyacente, mientras que K + T shreds permitan reconstruirlo por completo. El detalle fundamental es que los relays solo difunden los shreds almacenados después de que el consenso confirma qué lotes se incluyen. Esto evita cualquier observación del contenido de las transacciones antes de la confirmación y elimina por completo la superficie de ataque del ordenamiento con contenido visible mediante una garantía basada en teoría de la información. 

Según el marco desarrollado antes, este diseño de protocolo es el único que aborda la Capa 1 con resistencia estructural a la censura y la Capa 2 con ocultamiento, además de acotar la Capa 3 gracias a las garantías de resistencia a la censura que proporciona el ocultamiento. Ni Constellation ni Giga lo consiguen por completo.

Lo que hace especialmente interesante esta comparación es que Resnick, coautor del ideal teórico, también es coautor de Constellation, un protocolo que se aparta de él deliberadamente. Esto refleja la decisión consciente de que el diseño completo basado en HECC todavía no puede implementarse en una red en producción a la escala de Solana y que resolver primero la resistencia estructural a la censura es más urgente. El artículo sirve como estrella polar de Constellation: una especificación formal de aquello hacia lo que avanza el protocolo, aunque no pueda ofrecerlo todo de una vez. 

Ethereum Braid

Braid es la principal propuesta de MCP de Ethereum. Max Resnick la presentó y actualmente se considera como parte de la hoja de ruta Scourge de Ethereum junto con el diseño competidor de listas de inclusión FOCIL. Su inclusión aquí responde menos a una comparación técnica y más al contexto: toda la industria intenta resolver los mismos problemas estructurales, pero desde puntos de partida diferentes.

Braid implementa MCP al permitir que varios proponentes construyan bloques simultáneamente en cadenas paralelas dentro del mismo slot. La capa de ejecución agrega, deduplica y ordena las transacciones según reglas predeterminadas. No introduce roles adicionales en el protocolo. La diferencia más importante es que la seguridad de Braid depende en gran medida de mempools cifrados, por lo que el ocultamiento es un requisito previo y no algo que se aplaza. Braid sigue siendo una propuesta de investigación no implementada, y la comunidad de Ethereum aún no alcanza un consenso sobre si adoptarla en lugar de FOCIL.

En última instancia, Braid confirma que el argumento estructural a favor de MCP trasciende cualquier cadena individual. También vale la pena señalar que Resnick ha trabajado en tres de las cuatro propuestas de esta sección. Quizá sea la señal más clara de que Constellation es el producto de una reflexión sostenida, rigurosa en lo académico y aplicada en distintos contextos sobre un problema que se ha resistido a soluciones sencillas.

Una nota sobre PBS

Vale la pena mencionar Proposer-Builder Separation (PBS) como contrapunto, no como un diseño comparable. Mientras que todas las propuestas de esta sección intentan limitar estructuralmente el monopolio temporal del líder, PBS lo acepta y optimiza el sistema a su alrededor para redistribuir los ingresos de MEV. Constellation es explícitamente incompatible con PBS: una vez que el registro de atestaciones limita la discreción del líder, no queda nada que un constructor especializado pueda vender. El hecho de que PBS se haya convertido en la principal mitigación de MEV en Ethereum, pese a no hacer nada para reducir el daño a los usuarios, es precisamente el modo de falla que MCP busca evitar.

El precedente fuera del protocolo

Antes del lanzamiento de Constellation, el ecosistema de Solana ya aproxima ciertos aspectos de MCP fuera del protocolo. Harmonic, por ejemplo, es una capa abierta de agregación para la construcción de bloques que recopila y evalúa continuamente propuestas de bloques de varios constructores independientes y las presenta a los validadores para que elijan entre ellas competitivamente en tiempo real. No es MCP en el sentido formal, ya que no existen resistencia a la censura impuesta por el protocolo, cuórum de atestación ni restricciones criptográficas sobre la discreción del líder. Sin embargo, los validadores que ejecutan Harmonic ya eligen entre varias propuestas de bloques simultáneas, la mecánica central que MCP busca consagrar. Junto con BAM, ambos representan el intento del ecosistema por resolver problemas de estructura de mercado sin esperar que el protocolo los haga cumplir. Estos sistemas fuera del protocolo demuestran que la demanda de propiedades similares a MCP es tan real que los constructores no esperan el lanzamiento de Constellation.

Preguntas abiertas

El whitepaper de Constellation es una especificación de protocolo. Demuestra propiedades de corrección bajo los supuestos establecidos y aplaza correctamente todo lo demás, algo apropiado para una propuesta v0.9. Lo que sigue no es una lista de fallas de Constellation, sino un mapa de lo que su futuro SIMD y sus próximas iteraciones deberán abordar para llevar MCP eficazmente a Solana. 

Estas preguntas no tienen el mismo nivel de dificultad. Algunas corresponden al trabajo de especificación: decisiones de diseño que Anza puede y debe resolver mediante el proceso habitual de SIMD. Otras son problemas realmente abiertos que la comunidad general de investigación sobre MCP todavía no ha resuelto, pero que debemos tener presentes mientras abrimos camino para convertirnos en la primera blockchain a escala que implemente MCP. Ningún SIMD puede resolver por sí solo estos problemas. La distinción importa porque confundirlos corre el riesgo de exagerar las brechas de Constellation o subestimar cuánto trabajo queda por hacer.

El trabajo más directo del SIMD incluye:

• Distribución de comisiones: se describe cómo se reparten las comisiones de prioridad entre proponentes, atestadores y el conjunto general de validadores, pero no se detalla por completo. El whitepaper indica que las comisiones de prioridad regresan al ecosistema en proporción al stake, pero no define el mecanismo exacto de distribución entre proponentes, atestadores y validadores.
• Estructura de recompensas para validadores: cómo se compensa a los proponentes en relación con las recompensas actuales de los validadores y si la eliminación de las comisiones por transacciones de voto con Alpenglow cambia el cálculo para los validadores más pequeños.
• Secuencia de implementación: Constellation depende de Alpenglow, cuyo lanzamiento está previsto para el tercer trimestre de 2026. El SIMD debe especificar explícitamente la dependencia y abordar lo que ocurrirá durante el periodo de transición desde Alpenglow estándar hasta Constellation+Alpenglow. ¿Hay algún SIMD previo que deba llegar primero a mainnet?
• Gobernanza de los parámetros de roles: la cantidad de proponentes (p ≈ 16), la cantidad de atestadores (q ≈ 256), la duración del ciclo (△cycle = 50ms) y otros parámetros de la Tabla 1 del whitepaper de Constellation se presentan solo como sugerencias. El SIMD debe especificar cómo definir, gobernar y, potencialmente, modificar estos parámetros con el tiempo.

Las preguntas más difíciles (por ejemplo, ejecución asíncrona, slashing y privacidad en la capa de envío) se abordan en las siguientes subsecciones. Son preguntas en las que trabaja activamente la comunidad de investigación sobre MCP y que debemos considerar, ya que las decisiones de diseño de Constellation pueden ampliar o reducir el camino hacia determinadas soluciones futuras.

Ejecución asíncrona

Con la ejecución síncrona, un proponente que recibe una transacción en texto plano, o que puede decodificarla pronto bajo un modelo de envío ingenuo, conoce su contenido y puede simular el resultado. Puede ejecutar la transacción contra el estado actual para calcular exactamente cuál será el resultado de la ejecución, incluidos los precios de swaps, los cambios en saldos de cuentas y las oportunidades de arbitraje posteriores. Esto es lo que da precisión mecánica a los ataques sándwich. Los atacantes pueden ver swaps grandes y calcular cuánto necesitan para hacer frontrunning y maximizar sus ganancias.

La ejecución asíncrona elimina la segunda mitad de esa ventaja, pero solo cuando se combina con MCP. Si el consenso confirma el orden de las transacciones antes de ejecutarlas, un proponente que puede ver su contenido no puede simular los resultados de ejecución contra un estado final conocido, porque ese estado no existe al momento de ordenar. La ventaja informativa se reduce efectivamente de “sé qué hace esta transacción y en qué orden se ejecuta” a “sé cuál es esta transacción, pero no qué hará con respecto al conjunto ordenado final”. Este beneficio depende de que el proponente no controle el ordenamiento final. En un modelo de líder único, la ejecución asíncrona por sí sola no brinda esta protección, ya que el líder conserva total discreción sobre el ordenamiento y puede colocar ventajosamente sus propias transacciones sin importar cuándo ocurra la ejecución. La combinación de un ordenamiento limitado y una ejecución diferida es lo que reduce la superficie de ataque.

Ten en cuenta que la ejecución asíncrona no cierra por completo la Capa 2. Un proponente sofisticado todavía puede realizar inferencias categóricas. Por ejemplo, todavía puede ver que una transacción interactúa con un pool de liquidez específico e inferir la dirección probable sin conocer el resultado exacto. Esto eleva considerablemente la dificultad de las formas de explotación más mecánicas y rentables, y representa el camino arquitectónico más claro para reducir la Capa 2 sin exigir ocultamiento criptográfico en la capa de consenso. Cabe destacar que Sei Giga eligió este enfoque y adoptó la ejecución asíncrona como prioridad arquitectónica principal junto con MCP.

Esto plantea una pregunta natural que vale la pena considerar: ¿por qué no se adoptó primero la ejecución asíncrona? Esta reduce la Capa 2 y, en principio, podría haberse implementado como un cambio acotado en la capa de ejecución sin introducir la complejidad adicional de protocolo de MCP (es decir, nuevos roles de nodos, requisitos de sincronización de relojes UTC, un diseño de slashing sin resolver y el doble de sobrecarga de shredding). 

El argumento más sólido a favor de esta secuencia es que la ejecución asíncrona y MCP resuelven problemas diferentes. MCP proporciona restricciones estructurales de ordenamiento que la ejecución asíncrona por sí sola no puede ofrecer: un validador que no puede simular los resultados de ejecución, pero sí ver el contenido de la transacción, todavía puede ejercer discreción sobre el ordenamiento dentro de la ventana permitida por el protocolo. El argumento para adoptar primero MCP es que limita estructuralmente la Capa 1, la amenaza más evidente e inmediata en términos económicos. Adaptar la ejecución asíncrona al modelo actual de ejecución síncrona de Solana, dadas sus suposiciones de componibilidad y su arquitectura de programas, es un problema de ingeniería más difícil que incorporarla desde cero en una cadena nueva. Sei Giga tiene el lujo de diseñar para ejecución asíncrona desde el primer día; Solana no. Esta asimetría práctica puede importar tanto como el argumento de prioridad teórica para explicar por qué MCP se abordó primero. La arquitectura de Alpenglow también hace que MCP sea más viable de lo que habría sido con Tower BFT, como analizamos en la siguiente subsección sobre la complejidad del protocolo.

Que esta secuencia sea correcta es una pregunta abierta razonable. Constellation deja intacta la Capa 2, algo problemático dados los nuevos vectores de ataque que MCP introduce en la Capa 3. A su vez, esto puede hacer que los ataques de la Capa 2 sean más rentables, porque ambas superficies de ataque se complementan. Por ejemplo, un proponente que puede ver una transacción grande en un DEX puede retrasar sus pshreds para sacarla de la ventana del lote actual mientras hace frontrunning con su propia transacción en esa misma ventana. La visibilidad de la Capa 2 y los juegos temporales de la Capa 3 son armas integrales dentro de la misma superficie de ataque y se volverán más sofisticados a medida que Solana madure.

Slashing

La aplicación criptográfica funciona bien cuando el comportamiento indebido de un actor produce un artefacto verificable (por ejemplo, firmas contradictorias, verificaciones de validez fallidas o compromisos malformados que pueden demostrarse). Constellation resuelve con tanta claridad las preocupaciones de resistencia a la censura de la Capa 1 porque un líder que excluye una transacción atestiguada produce un bloque no válido, y esa invalidez puede demostrarse matemáticamente. Los juegos temporales y la manipulación de latencia no producen ningún artefacto de este tipo. La dificultad es que esta clase de conducta indebida no se distingue de un retraso legítimo de la red cuando se observan actos individuales. La conducta indebida existe como una ausencia y no puede demostrarse criptográficamente. La única herramienta disponible es la disuasión económica, que requiere slashing. 

El desafío del slashing es que tradicionalmente exige una infracción demostrable. Los mecanismos de testigos de fallas de Constellation permiten identificar y excluir a un proponente que firma dos pshreds contradictorios. Sin embargo, la manipulación estratégica de la latencia no produce ningún testigo de falla. No hay equivocación, firma doble ni huella onchain. Un proponente que se limita a retrasar sistemática y selectivamente unos pocos milisegundos el reenvío de pshreds no deja nada que pueda sancionarse con slashing. 

Si los pshreds de un proponente llegan sistemáticamente a los atestadores durante los últimos milisegundos de la ventana del ciclo —a lo largo de muchos ciclos y para transacciones que resultan competir con los propios envíos del proponente—, un mecanismo de slashing bien especificado podría tratar este patrón como evidencia de manipulación sistemática sin que exista un solo acto cuya malicia pueda demostrarse. El slashing tradicional no puede abordar esto directamente. En su forma canónica, exige una prueba inequívoca y autocontenida, y tal prueba no existe para un proponente que simplemente retrasó el reenvío unos milisegundos. Lo que cambia es el patrón.

Aquí, las finanzas tradicionales pueden ofrecer una lección útil a las finanzas descentralizadas sobre el enfoque de los reguladores ante la manipulación basada en latencia. Por ejemplo, la aplicación de sanciones contra el spoofing bajo la Ley Dodd-Frank se basa en detectar patrones estadísticos (por ejemplo, proporciones entre cancelaciones y ejecuciones, distribuciones temporales de cancelaciones y correlaciones con el impacto sobre el precio) en lugar de demostrar la intención de una orden individual. No puede demostrarse que una instancia aislada sea intencional. Sin embargo, el patrón sí. Se aplica la misma lógica porque la regularidad estadística es objetiva, aunque los actos individuales no lo sean. Además, el incentivo económico para manipular está tan presente en conjuntos de proponentes sin permisos como entre los operadores de alta frecuencia de las finanzas tradicionales. La analogía falla en la forma de aplicar las sanciones. Dodd-Frank depende de un regulador con poder de citación, mientras que un contexto trustless requiere incorporar los mecanismos de detección y sanción en el propio protocolo.

Proponemos adaptar los nodos fisherman como posible mecanismo para abordar esta brecha. Presentados originalmente en la investigación de Vitalik sobre disponibilidad de datos, los nodos fisherman podrían adaptarse como una clase de observadores que supervisan datos de atestación durante muchos ciclos y envían pruebas estadísticas de fraude a un protocolo de arbitraje incorporado. Una llegada tardía individual es subjetiva. Sin embargo, el patrón calculado de forma determinista a lo largo de n ciclos es objetivo. Es la misma idea en la que se basan las pruebas de fraude de los rollups optimistas, pero aplicada al comportamiento temporal en vez de a las transiciones de estado. Además, un protocolo de arbitraje incorporado para pruebas estadísticas de fraude no es categóricamente distinto de las nuevas herramientas de gobernanza que están en desarrollo y permitirían que quienes hacen staking revoquen los votos de su validador en futuras propuestas de gobernanza. Si Solana está dispuesta a contar con infraestructura para que quienes hacen staking revoquen votos, las bases técnicas de un sistema de arbitraje basado en nodos fisherman pueden estar más cerca de lo que parecen.

Esta exploración de nodos fisherman representa una dirección más creíble que extender el slashing canónico para cubrir actos que no dejan una huella onchain individual, y es una opción que el desarrollo actual de infraestructura de gobernanza del protocolo quizá ya pueda respaldar. Dicho esto, cualquier especificación concreta tendría que abordar tres limitaciones. Primero, realizar un análisis estadístico de los datos temporales de atestación durante miles de ciclos no es trivial y podría elevar fácilmente los requisitos de hardware de los validadores. Esto aumenta los costos operativos y la posibilidad de que el rol de detección de fraude se concentre en un grupo selecto de actores sofisticados. Segundo, cualquier especificación de umbrales debe ser lo bastante sólida como para distinguir la variación genuina de la red de la manipulación estratégica, sin ser tan conservadora que produzca falsos positivos. Tercero, el propio protocolo de arbitraje introduce una nueva superficie de ataque mediante la cual podría manipularse este nuevo sistema basado en nodos fisherman a través de informes coordinados. El diseño de cualquier protocolo de arbitraje tendría que contemplarlo, posiblemente mediante mecanismos de incentivos que hagan viable la operación de nodos fisherman para participantes más pequeños o esquemas de agregación que distribuyan el cómputo entre el conjunto de nodos fisherman.

La pregunta de investigación concreta que planteamos es esta: ¿puede especificarse un marco de pruebas estadísticas de fraude —que defina parámetros de umbral, considere la variación de la red y establezca cómo escalan las sanciones— y que sea, al mismo tiempo, lo bastante sólido para disuadir la manipulación sistémica de la latencia, lo bastante conservador para evitar sancionar variaciones legítimas y lo bastante simple para resistir la manipulación adversarial de operadores sofisticados? Este es uno de los problemas abiertos con mayor exigencia técnica de la literatura sobre MCP, y la comunidad de investigación general todavía no lo resuelve.

Ocultamiento

El slashing no es la única solución para los juegos de manipulación temporal y de latencia. El ocultamiento aborda tanto el ordenamiento con contenido visible como la manipulación temporal y de latencia, problemas que ni la ejecución asíncrona ni el slashing pueden resolver por sí solos. Constellation implementa un ocultamiento parcial (es decir, el contenido de la transacción solo es visible para los proponentes receptores y para el líder después del plazo del ciclo), pero no logra la propiedad de ocultamiento completa. La superficie de ataque aumenta según la cantidad de proponentes a los que el usuario decide enviar su transacción. Aunque este ocultamiento parcial reduce la superficie de ataque frente a una visibilidad total, no la elimina. El ocultamiento total, en el que ninguna parte observa el contenido de una transacción antes de su confirmación, sigue siendo un problema abierto para Constellation.

El ideal teórico es el enfoque descrito por Garimidi et al., que usa Hiding Erasure-Correcting Code (HECC) como primitiva. A diferencia del Reed-Solomon estándar de Constellation, HECC ofrece una garantía basada en teoría de la información de que un adversario que recopile menos shreds que el umbral no descubrirá nada sobre el contenido de las transacciones. Constellation decidió continuar con la codificación de borrado que ya está activa en Solana mediante Turbine.

El desarrollo reciente más relevante es Block Assembly Marketplace (BAM) de Jito, que usa Trusted Execution Environments (TEEs) para crear un mempool cifrado donde las transacciones permanecen privadas hasta su ejecución. BAM demuestra que existe una demanda material creciente de privacidad del contenido en Solana. Sin embargo, el ocultamiento basado en TEE tiene limitaciones, ya que traslada los supuestos de confianza a los fabricantes de hardware. Es una restricción importante para un protocolo que aspira a operar sin confianza. Debe explorarse a fondo un camino en el que el cifrado por umbral ofrezca una alternativa con fundamentos más sólidos.

BAM es importante porque representa un intento fuera del protocolo de resolver el problema de visibilidad del contenido que Constellation aplaza. Jito está en posición operativa de proporcionar privacidad de transacciones a escala mediante BAM incluso antes del lanzamiento de Constellation. Esto plantea la pregunta de si el ocultamiento en el protocolo sigue siendo urgente cuando una solución en la capa de aplicaciones ya puede proporcionarlo. La respuesta depende por completo de los supuestos de confianza y de si los fabricantes de hardware son “suficientemente” confiables frente a lo que el protocolo podría garantizar en teoría. Aun así, esto no puede considerarse una solución permanente. El camino probable es que BAM ofrezca privacidad a corto plazo, mientras que futuras iteraciones de Constellation exploren el cifrado por umbral como alternativa a largo plazo.

Para un protocolo que aspira a ser la infraestructura de los Mercados de Capital de Internet, el ocultamiento parcial es un avance importante, pero no el destino final. La brecha restante es la diferencia entre una estructura de mercado justa y una que simplemente sea menos injusta que la existente hoy. 

Complejidad del protocolo

Constellation es la actualización estructuralmente más ambiciosa propuesta para Solana desde su creación. Introduce tres nuevos roles de nodos, un nuevo modelo temporal que depende de la sincronización del reloj UTC, nuevas pasadas de codificación de borrado, nuevos tipos de mensajes y nuevos modos de falla. Todo esto se superpone a Alpenglow, que todavía no está activo en mainnet. La pregunta de si este es el momento adecuado para asumir tal complejidad es seria y merece más que simple optimismo.

En el pasado, Solana adquirió una reputación notoria por las diversas interrupciones que afectaron a la red durante 2021 y 2022. Estas interrupciones comparten un tema: fueron causadas por la dificultad inherente de razonar sobre casos límite en un protocolo nuevo de alto throughput bajo condiciones de carga reales. Los más de dos años de actividad ininterrumpida que la red ha logrado desde entonces son un verdadero hito, forjado en el doloroso proceso de iteración. Ese historial permite confiar en la madurez de Solana. 

Ahora, cualquier cambio en el protocolo de la magnitud de Constellation exige implementarlo simultáneamente en Agave y Firedancer. Esto requiere que dos equipos de desarrollo independientes se coordinen en cuanto a semántica del protocolo, casos límite y supuestos temporales que son nuevos para ambos. La complejidad de lograrlo solo para Alpenglow ya es considerable, y Constellation no hará más que aumentarla. Este no es un argumento para no avanzar. Más bien, es un argumento para que el futuro SIMD de Constellation incluya un plan claro de implementación con varios clientes.

Las instituciones financieras están comenzando a operar onchain. Las consecuencias de una interrupción importante son materialmente mayores que en 2021, tanto en términos de daño reputacional como económico. Como comunidad, debemos ser honestos sobre la complejidad que introduce Constellation. El futuro SIMD debe abordarse con el rigor que merece un sistema financiero global. 

Naturalmente, surge la pregunta de por qué ahora. ¿Realmente queremos asumir el riesgo de una actualización de este tipo? ¿No podríamos implementar mejoras incrementales con el tiempo para suavizar el cambio? Las exploraciones antes mencionadas sobre ejecución asíncrona y slashing, por ejemplo, sugieren que existe una alternativa incremental. Es posible una versión de la hoja de ruta de Constellation en la que el ecosistema se beneficie de implementaciones graduales de varias actualizaciones complementarias. Considerar esto prudente o contrario a la aceleración es tanto una cuestión de valores como una cuestión técnica, y es razonable tener opiniones distintas. Estamos construyendo tanto un sistema de significado como un sistema para las finanzas.

Esto ya ocurre en la práctica. Anza confirmó que los slots de 200ms y las ventanas de líder de dos slots se lanzarán antes que Constellation. Esto significa que Solana verá mejoras importantes de rendimiento que abordarán algunas de las preocupaciones sobre latencia de secuencia planteadas por la comunidad, las cuales analizaremos en la siguiente sección, sin requerir toda la complejidad de MCP. Si los slots de 200ms acercan suficientemente la ruta de confirmación de Solana a la sobrecarga prevista de Constellation como para que el costo marginal de MCP sea pequeño, el argumento político será mucho más fácil de presentar. Sin embargo, si los participantes dominantes del trading consideran que 200ms es “suficientemente bueno”, la urgencia de Constellation disminuirá. Las proyecciones comparativas de latencia que muestren slots de 200ms frente a slots de 200ms con Constellation pueden ayudar a la comunidad a evaluar el costo incremental frente a la garantía incremental. Por supuesto, tendremos que esperar al futuro SIMD de Constellation y a la implementación propuesta.

El argumento más sólido para avanzar es la oportunidad que crea Alpenglow. Constellation hereda el modelo de seguridad de Alpenglow, usa Rotor como capa de difusión de datos y se beneficia de la eliminación de la complejidad de Tower BFT. El costo marginal de añadir MCP sobre Alpenglow es menor que el costo de empezar desde cero con un futuro diseño de consenso. Esperar no es gratis, dadas las exploraciones de nuestros competidores para llevar MCP onchain y el hecho de que aplazar la resistencia a la censura hasta un futuro ciclo de actualización traerá inevitablemente su propia complejidad y obstáculos políticos.

Si no es ahora, ¿cuándo?

La complejidad está justificada, pero esa justificación debe ganarse mediante una especificación rigurosa, implementaciones graduales y la validación empírica de las afirmaciones sobre latencia y ancho de banda que la comunidad debate actualmente solo con base en la teoría. 

¿Constellation está alineado con IBRL?

Latencia de secuencia frente a latencia de inclusión

La reacción inicial de la comunidad de Solana ante Constellation ha sido polarizante, por decir lo menos. Esta reacción ha puesto sobre la mesa un debate importante que merece una respuesta precisa, no diplomática. La formulación más contundente apareció en el tuit de Cavey, donde afirma que “MCP e IBRL son fundamentalmente incompatibles”. Sostiene que MCP reduce de manera directa e incuestionable el ancho de banda y aumenta la latencia en un intento por mejorar la estructura del mercado. La respuesta de Toly fue igual de directa: “Estás equivocado. No hay forma de reducir la latencia de inclusión sin MCP”.

Ambos tienen razón en términos técnicos; están midiendo cosas distintas.

MCP reduce la latencia de inclusión y aumenta la latencia de secuencia. No son la misma propiedad, y confundirlas es la fuente de la mayor parte de la confusión del debate actual.

La latencia de secuencia es el tiempo transcurrido desde que se envía una transacción hasta que se ejecuta. Aumenta de forma inherente con MCP, ya que la ronda de atestadores, la ventana de ciclo de 50ms y el paso de ensamblaje de lotes añaden tiempo que no existe en la ruta actual de envío mediante TPU a un líder cooperativo. Es correcta la crítica de que los agentes racionales que envían a varios proponentes consumen más ancho de banda. También es correcto que la ventana de coalescencia añade latencia. Todos son costos reales que deben medirse y presentarse a la comunidad como contrapartida por eliminar la censura dura.

La latencia de inclusión es la ventana temporal garantizada durante la cual se incluirá una transacción válida y competitiva en comisiones. En el modelo actual de líder único, esta garantía es esencialmente ilimitada. Es decir, un líder que quiera retrasar o excluir una transacción determinada puede hacerlo, y no existe ningún mecanismo del protocolo para impedirlo. La latencia que ya experimentan los usuarios incluye toda la fricción causada por la retención, la programación y los juegos temporales, además del ordenamiento selectivo impuesto por los líderes. El contraargumento de que los tiempos de confirmación reales incluyen la latencia de estos juegos y, por tanto, la experiencia neta del usuario podría mejorar, avanza en la dirección correcta bajo este marco y cuenta con el respaldo de los debates de la comunidad que actualmente tienen lugar en X. 

La verdadera pregunta es qué latencia debemos optimizar.

FIFO frente a FCFS frente a FBO

Antes de analizar qué latencia debemos optimizar, conviene entender un debate relacionado que la comunidad ha abordado al mismo tiempo: si MCP es compatible con FIFO.

FIFO (First In, First Out; primero en entrar, primero en salir) es un principio general de ordenamiento según el cual las transacciones se procesan en el orden en que llegan. Umberto argumentó extensamente que la respuesta tiene matices inherentes. MCP puede producir lo que se conoce como “FIFO probabilístico”, pero solo bajo condiciones de infraestructura específicas. En esencia, si un usuario está geográficamente lo bastante cerca de suficientes proponentes como para evitar la censura, y esos proponentes están lo bastante cerca de los atestadores como para alcanzar rápidamente el umbral de atestación del 40 % que garantiza la inclusión, entonces el usuario experimenta en la práctica una inclusión FIFO. Es decir, su transacción se incluye antes de que cualquier competidor tenga tiempo de observarla y reaccionar. La carrera termina en la inclusión, no en la ejecución. En esas condiciones, MCP se aproxima a FIFO como una propiedad emergente, no como una regla del protocolo.

El problema es que la infraestructura actual de Solana no cumple esas condiciones. El stake se concentra en unas pocas regiones, lo que significa que la formación de quórum queda limitada por la necesidad de alcanzar zonas con una alta concentración de stake. Esta concentración crea una ventana en la que un observador con “ventaja geográfica” puede adelantarse a una transacción en tránsito. Que el despliegue de Constellation esté acompañado por la distribución geográfica y la densidad de atestadores que requiere el FIFO probabilístico es tan importante como el propio diseño del protocolo. Un protocolo que garantice resistencia a la censura, pero permita el frontrunning basado en latencia debido a una infraestructura geográficamente dispersa, no ofrecerá la equidad de mercado que promete su whitepaper.

Una pregunta relacionada, pero distinta, es si Constellation podría haber implementado FCFS, pero decidió no hacerlo. Mientras que FIFO es una propiedad emergente de la infraestructura, FCFS (First Come, First Served; primero en llegar, primero en ser atendido) es una regla específica del protocolo que garantiza que la primera transacción en llegar se procese de forma determinista. Cabe señalar que Constellation sí ordena de forma determinista: las transacciones se ordenan por comisión de prioridad dentro de cada lote. Por tanto, la pregunta no es si el protocolo impone el ordenamiento, sino si la hora de llegada debería determinarlo en relación con las comisiones de prioridad.

Un debate reciente ha planteado una objeción más fundamental que la inicial: FCFS podría ser completamente inaplicable en un contexto sin confianza. Los validadores pueden simplemente falsear el orden de llegada de las transacciones sin dejar ningún rastro onchain. Este es el mismo problema de ausencia de pruebas que impide penalizar mediante slashing la manipulación temporal en el sentido tradicional, y podría requerir soluciones más creativas (por ejemplo, el enfoque de detección de patrones estadísticos desarrollado en la subsección sobre slashing). Una regla de protocolo que los validadores honestos seguirían y los deshonestos pueden ignorar en silencio no constituye una garantía significativa. Esto replantea la omisión de FCFS por parte de Constellation: deja de ser una preferencia de diseño que exige una explicación y pasa a reconocer que, con un conjunto de validadores sin permisos, FCFS quizá todavía no pueda implementarse en Solana como una propiedad estricta del protocolo, al menos bajo los supuestos actuales. Si FCFS realmente no puede aplicarse en un conjunto de validadores sin permisos bajo los supuestos actuales, la tarea del SIMD es indicar explícitamente esta limitación y justificar el ordenamiento por comisión de prioridad como la opción de diseño predeterminada correcta. Dejar que la comunidad debata sobre FCFS como si fuera una alternativa viable que Constellation decidió no implementar, en lugar de presentarlo como una propiedad que quizá no pueda implementarse, generará aún más fricción dentro de la comunidad.

El ordenamiento por comisión de prioridad dentro de un periodo fijo no es una solución intermedia novedosa. Se conoce como subasta frecuente por lotes (FBA), un diseño de microestructura de mercado con un respaldo académico considerable. Budish, Cramton y Shim, por ejemplo, sostienen en La carrera armamentista del trading de alta frecuencia: subastas frecuentes por lotes como respuesta de diseño de mercado (2015) que las subastas por lotes en tiempo discreto con precios de liquidación uniformes eliminan la carrera por la velocidad que crean los mercados de tiempo continuo. Esto reemplaza la competencia basada en la latencia por competencia basada en el precio. Constellation parte de esta idea para introducir Fixed Batch Ordering (FBO), basado en comisiones de prioridad. Así, el ciclo de 50 ms de Constellation materializa este enfoque: las transacciones compiten mediante comisiones y no por su hora de llegada dentro de cada lote, y todas las transacciones del mismo lote reciben el mismo tratamiento de ordenamiento. Esta es precisamente la clase de aplicaciones que antes se identificó como inexistente a escala en Solana. 

Los debates sobre FIFO, FCFS y FBO giran en gran medida en torno a la misma preocupación subyacente: quién controla el ordenamiento una vez garantizada la resistencia a la censura, y si la estructura de mercado que Constellation busca crear es realmente justa o solo menos injusta que la actual. Constellation elimina la forma de manipulación más evidente. Lo que la sustituya dependerá de las decisiones que el whitepaper deja para su SIMD.     

Entonces, ¿qué estamos optimizando?

La latencia de secuenciación es lo más importante para las aplicaciones de trading existentes (es decir, AMM, mesas de trading propietario y CLOB). Estas aplicaciones parten del supuesto de que gana quien sea más rápido y competitivo en comisiones, y han construido su infraestructura en consecuencia. El trading solo debería estar limitado por las leyes de la física para ofrecer una experiencia de usuario inigualable en Solana. Para algunos de estos usuarios, Constellation supone un retroceso en la métrica que más les importa. La preocupación es que Solana pueda cometer el mismo error fatal que Ethereum cometió en su momento: priorizar la estructura de mercado sobre el rendimiento, lo que podría hacer que la ejecución abandone la cadena. Es un riesgo legítimo que vale la pena debatir.

Para las aplicaciones financieras que Constellation busca habilitar (es decir, subastas onchain, libros de órdenes con garantías confiables de inclusión y protocolos DeFi resistentes a la censura), la latencia de inclusión es la métrica adecuada. Una orden límite que pueda sufrir frontrunning o retrasarse selectivamente ofrece garantías más débiles que una orden al estilo de un exchange, sin importar cuán rápida sea nominalmente la confirmación. Solana ahora puede admitir aplicaciones de trading con subastas por lotes y precios de liquidación uniformes, donde la secuenciación no debería afectar el precio de ejecución. Esta es una clase de aplicaciones que prácticamente no existe hoy en Solana, precisamente porque no hay garantías de inclusión. Podría decirse que Constellation se enfoca demasiado en un diseño optimizado para usuarios que aún no existen a escala en Solana, a costa de quienes sí existen; un argumento que ya plantean colaboradores principales.   

La preocupación por la latencia de secuenciación debe situarse en el contexto de que Solana está perdiendo terreno importante frente a Hyperliquid en el trading de contratos perpetuos. Hyperliquid es un exchange de perpetuos con secuenciador centralizado y diseñado específicamente para ese fin, que no pretende ser descentralizado, pero ofrece una atractiva experiencia de ejecución inferior a un milisegundo, algo que necesitan los traders y las aplicaciones sofisticados. Hyperliquid decidió deliberadamente crear un producto que los profesionales realmente quieran usar, sacrificando principios fundamentales de lo que hace que las criptomonedas sean “cripto”. El riesgo implícito de Constellation es que añadir sobrecarga de comunicación y rondas de atestación a la ruta de confirmación representa el mismo intercambio que hace Hyperliquid, pero en la dirección equivocada. Los críticos consideran negativo sacrificar cualquier ventaja potencial de rendimiento que actualmente permita a Solana competir con aplicaciones de trading centralizadas, sin contar todavía con las aplicaciones financieras que justifiquen ese intercambio, y lo expresan abiertamente.

Esta preocupación no debería descartarse con tanta facilidad. Podemos replantear nuestra pregunta anterior sobre si deberíamos optimizar la latencia de secuenciación o la de inclusión: ¿puede Solana permitirse ese intercambio, dado el origen de su competencia actual?

Sin embargo, hay un problema más profundo. La comparación con Hyperliquid deja claro que el significado de IBRL podría haber cambiado con el tiempo. La motivación original de Toly y Raj para crear Solana era la resistencia a la censura: “Para permitir que los productos DeFi atraigan a miles de millones de usuarios y dispositivos, necesitamos escalar la resistencia a la censura... Es el problema más importante que debemos resolver y nuestra motivación completa para crear Solana”. IBRL surgió mucho después como la expresión de ingeniería de esa misión: desarrollar una red descentralizada con suficiente velocidad para superar a la infraestructura centralizada en las métricas importantes. Desde entonces, IBRL ha adquirido su propio significado tecnooptimista y se ha vuelto omnipresente en el espíritu cultural de Solana. Es, a partes iguales, mandato de ingeniería, santo y seña cultural y plegaria secular. Para muchos, se ha convertido en el objetivo y no en el medio, con la minimización de la latencia de secuenciación como un fin en sí mismo, desvinculado del objetivo de resistencia a la censura al que debía servir.

Si se ha producido este cambio, como parece ser el caso, Constellation enfrentará una fuerte resistencia cultural. No es una dinámica nueva, dada la negativa de la comunidad ante SIMD-228, una controvertida propuesta para reducir la inflación que no logró aprobarse en la votación de gobernanza. Incluso las propuestas con mayores beneficios generales pueden fracasar cuando entran en conflicto con convicciones arraigadas de la comunidad. Constellation tiene más matices porque sus costos de ancho de banda y latencia son reales, pero su efecto neto sobre la experiencia del usuario no está cuantificado. Es prematuro llegar a conclusiones firmes en cualquier dirección sin datos. Lo que le falta a la comunidad, y lo que Anza deberá aportar para presentar un SIMD convincente, son datos empíricos sobre cómo funciona la ruta de confirmación en condiciones de red realistas. Alpenglow no enfrentó este problema gracias a su alineación con IBRL: una reducción de 100 veces en el tiempo hasta la finalidad de las transacciones y un consenso simplificado. El argumento a favor de Constellation es menos intuitivo, pero no menos real si los futuros benchmarks lo respaldan.

Parece que la comunidad evaluará una actualización resistente a la censura con una métrica de rendimiento que nunca se diseñó para optimizar. La pregunta más productiva es si el intercambio vale la pena. Existe un costo real y medible: cierta latencia de secuenciación y ancho de banda adicionales a cambio de una garantía estricta, impuesta por el protocolo, de que ningún líder pueda excluir selectivamente una transacción. Este es un requisito previo para las aplicaciones financieras que Solana intenta atraer actualmente.

Consideramos que Constellation está alineado con IBRL según la interpretación correcta de lo que IBRL siempre debía lograr. Que la comunidad llegue a la misma conclusión dependerá menos de los méritos técnicos que de la presentación de evidencia empírica y la explicación de las decisiones de diseño.  

Conclusión

Constellation es la primera propuesta formal en el nivel del protocolo para llevar MCP a una blockchain de producción a escala. Resuelve estructuralmente la censura dura, de modo que las transacciones con comisiones competitivas y atestadas por un quórum suficiente no puedan excluirse de un bloque válido. Esta garantía criptográfica cambia lo que puede crearse en Solana. 

Lo que Constellation pospone de forma consciente es igual de importante. El modelo de envío de Constellation mitiga parcialmente el ordenamiento basado en contenido visible, ya que solo el proponente receptor ve el contenido de la transacción. Sin embargo, la superficie de ataque residual crece con la cantidad de proponentes a los que el usuario envía la transacción. La manipulación del tiempo y la latencia sigue siendo el mayor problema sin resolver y actualmente no puede sancionarse con el diseño vigente. Se identifican posibles caminos a seguir (es decir, ejecución asíncrona, slashing y ocultamiento), pero no se especifican, y cada uno introduce sus propias complejidades. El whitepaper de Constellation es honesto sobre estos límites, y su eventual SIMD debería serlo por igual.

La pregunta más difícil que plantea Constellation es si Solana puede permitirse los intercambios que introduce. Existe un costo real y medible en latencia de secuenciación y ancho de banda que aún no se ha cuantificado. Del mismo modo, existe un beneficio real pero no medido en las garantías de inclusión, que todavía no cuentan con una base de aplicaciones que las justifique a escala. Se pide a la comunidad que invierta en infraestructura para aplicaciones financieras que hoy prácticamente no existen en Solana, posiblemente a costa de las aplicaciones de trading que sí existen. Que esto sea visionario o prematuro depende de datos que la comunidad aún no tiene.

El argumento a favor de Constellation dependerá en última instancia de sus futuros benchmarks empíricos en condiciones realistas. La diferencia entre una ruta de confirmación solo con slots de 200 ms y otra con slots de 200 ms bajo Constellation es el dato más importante que Anza puede proporcionar. Hasta entonces, la comunidad debate intercambios que no puede cuantificar.

Consideramos que Constellation representa el siguiente paso correcto en la hoja de ruta del protocolo que Alpenglow ha abierto. Está alineado con IBRL según la interpretación de IBRL para la que Solana se creó originalmente. Sin embargo, esta opinión depende de que el SIMD alcance el rigor que exige un sistema financiero global, tanto en su especificación, despliegue por etapas y pruebas como en la evidencia empírica que presente a la comunidad a la que pide adoptarlo.

Recursos adicionales

• Budish, E., Cramton, P. y Shim, J. (2015). La carrera armamentista del trading de alta frecuencia: subastas frecuentes por lotes como respuesta de diseño de mercado. https://doi.org/10.1093/qje/qjv027
• Daian, P., Goldfeder, S., Kell, T., et al. (2019). Flash Boys 2.0: frontrunning, reordenamiento de transacciones e inestabilidad del consenso en exchanges descentralizados. https://arxiv.org/abs/1904.05234
• Eskandari, S., Moosavi, S. y Clark, J. (2019). SoK: deshonestidad transparente: ataques de frontrunning en blockchain. https://arxiv.org/abs/1902.05164
• Garimidi, P., Neu, J. y Resnick, M. (2025). Múltiples proponentes simultáneos: por qué y cómo. https://arxiv.org/abs/2509.23984
• Kniep, Q., Resnick, M., Sliwinski, J. y Wattenhofer, R. (2026). Solana Constellation: mercados de capitales de Internet. https://drive.google.com/file/d/1MiGlZ_OORdnq6znkVQ5LrenBF3kyBIWf/view
• Landers, S. y Marsh, B. (2025). MEV en blockchains con múltiples proponentes simultáneos. https://arxiv.org/abs/2511.13080
• Yakovenko, T. y Gokal, R. Los desarrolladores de blockchain se enfocan en el problema equivocado. CoinDesk, 2020. https://www.coindesk.com/markets/2020/12/30/blockchain-developers-are-focused-on-the-wrong-problem