Stellar presentó el 28 de octubre Project Thruput con una cifra que incomoda al discurso dominante sobre el rendimiento en Solana: 7,02 millones de pagos por segundo. El dato sale de un benchmark reproducible sobre ocho máquinas y ha bastado para reabrir una discusión que parecía cerrada: quién procesa más y, sobre todo, qué significa exactamente procesar.
Qué ha presentado Stellar y qué mide de verdad
La Stellar Development Foundation lo presentó como una vista previa tecnológica. El código es abierto, los benchmarks reproducibles y todo corre sobre FutureNet, la red de pruebas de la fundación. En las pruebas reportadas, la capacidad de ejecución de un solo validador pasó de 1,18 millones de pagos por segundo en una máquina a 7,02 millones en ocho. Casi seis veces más sin tocar el código.
Aquí conviene detenerse, porque el matiz separa un titular de una realidad operativa. La fundación advierte de que es una medición de componente en entorno controlado, con un conjunto limitado de cuentas, y de que no representa el rendimiento de extremo a extremo de una red pública. Lo medido incluye ejecución, firmas y trabajo del motor. Fuera quedan el consenso, la propagación entre nodos independientes, el almacenamiento y el comportamiento adversarial.
El problema que Thruput ataca se explica con una imagen de oficina. Muchos sistemas paralelizan las tareas que no se tocan entre sí, pero ponen en fila india las que afectan al mismo documento. Thruput propone escalar también ese trabajo en disputa añadiendo máquinas. Si el modelo aguanta a escala, golpea uno de los cuellos de botella clásicos de cualquier blockchain.
Hay un segundo ingrediente, tanto o más polémico que la cifra: el modelo no cobra comisiones por ejecución. Cuando la demanda supera la capacidad, las cuentas reciben una cuota de planificación proporcional a su saldo de XLM desbloqueado, con límites computacionales por transacción. Es un diseño alternativo de asignación de recursos, no infraestructura gratis e ilimitada. Y abre dudas razonables sobre equidad y concentración de cuentas.
Merece la pena aclarar qué es un motor de ejecución, porque la expresión aparece en todos los titulares y casi nadie la usa a diario. Es la pieza de software que coge cada transacción y la ejecuta: valida firmas, actualiza saldos, aplica reglas. En Solana se llama Sealevel y permite procesar en paralelo contratos que no comparten estado.
Un benchmark mide lo que el ingeniero decide medir. La red que usa el usuario mide todo lo demás, incluido lo que nadie quiere medir.
Por qué el TPS de Solana no se juega en la misma cancha
Solana no compite con una cifra aislada de ejecución, sino con una pila completa. El Proof of History o PoH es el reloj criptográfico que sella el tiempo de cada transacción antes de votarla, de modo que los validadores no tienen que pactar qué hora es. Turbine reparte los bloques en árbol y Gulf Stream reenvía transacciones sin mempool. Cuando alguien presume de TPS, presume de que todo eso funciona a la vez.
Los paneles públicos permiten separar las dos cifras que se mezclan en las conversaciones. El listado de validadores de Solana Beach muestra picos que, contando los votos, superan con holgura las decenas de miles de transacciones por segundo. Descontados esos votos, el rendimiento útil se mueve en unos pocos miles. Es la misma trampa que un benchmark de componente: la cifra es cierta, pero no significa lo que parece.
De ahí que comparar el rendimiento de Stellar con el Solana TPS que se publicita en redes sociales sea comparar dos cosas distintas. La respuesta de Solana no ha sido un número más alto, sino dejar de depender de un solo programa: Firedancer, el segundo cliente validador, escrito desde cero en C++ por los equipos de Jump Crypto, para que si uno falla el otro sostenga la red. Agave, el cliente en Rust de Anza, ha sido durante años el único sostén operativo.
El cuello de botella se ha movido de sitio
La propia Solana ya vivió esta discusión por dentro. Cuando Sealevel llegó al discurso público, la promesa era la misma que ahora hace Thruput: ejecutar en paralelo y escalar añadiendo máquinas. Entre septiembre de 2021 y febrero de 2022 la red se detuvo varias veces, por saturación y por fallos en la producción de bloques. En alguna de esas paradas el problema no fue la potencia de cálculo, sino la coordinación entre validadores.
Con ese precedente, la lectura prudente del anuncio de Stellar es que un motor seis veces más rápido bajo contención es un avance de ingeniería serio y verificable, pero no reordena el mapa por sí solo. La pregunta que decide el debate no es cuántos pagos por segundo caben en ocho máquinas, sino cuántos operadores independientes, con intereses distintos, y conexiones imperfectas, aceptan coincidir en el mismo orden de bloques. Eso es consenso, no ejecución.
Del lado de Solana, el riesgo no es la velocidad: es la concentración del staking —el mecanismo por el que se delegan SOL a un validador a cambio de recompensas— y la dependencia histórica de un único cliente. Ambos frentes se corrigen, ninguno está resuelto.
Lo que viene es más aburrido y más decisivo que el titular. La hoja de ruta de Thruput pasa por reproducción independiente, cargas más amplias e integración en red pública; hasta entonces, cualquier promesa de comisiones cero es prematura. En Solana, los hitos a vigilar son la cuota de Firedancer en el set de validadores y las propuestas sobre mercados locales de comisiones. La carrera no la gana quien anuncie el número más alto, sino quien demuestre que ese número aguanta cuando la red se pone fea.
