Solana quiere recortar su latencia en milisegundos, no en segundos. Un estudio sobre la propuesta SIMD-0675 plantea reordenar el calendario de líderes de la red para que los validadores que producen bloques consecutivos estén físicamente más cerca entre sí. La idea no cambia cuántos bloques produce cada uno: cambia el orden en que le toca hacerlo.
Conviene fijar dos conceptos. Las SIMD (Solana Improvement Documents) son el mecanismo formal con el que la comunidad propone cambios técnicos, recogidos en el repositorio público de SIMD. El leader schedule es el calendario que decide qué validador produce cada slot, la ventana de tiempo en la que se emite un bloque.
Hoy ese calendario se asigna por peso de stake —los SOL delegados a cada operador— y por criterios de equidad, sin mirar dónde está el servidor. La SIMD-0675 explora lo contrario: mantener intacta la cuota de cada validador y reordenar las ventanas para que el siguiente de la cola esté, probablemente, en la misma zona horaria.
Qué propone la SIMD-0675 y qué no cambia
El matiz importa: es fácil leer la propuesta como un reparto de poder y no lo es. Ningún validador recibe más slots de los que le corresponden por stake. Lo único que se mueve es el orden de la cola.
La lógica es de física básica: si el validador A emite un bloque en Fráncfort y el B, que produce el siguiente, está en Singapur, la información tarda más en llegar que si está en Ámsterdam. Ese intervalo es la latencia de handover, uno de los pocos sumideros de tiempo que le quedan a una red que ya finaliza transacciones en segundos.
Ganar 29 milisegundos no suena a revolución hasta que se recuerda que toda la arquitectura de Solana está construida para que el tiempo no se pierda en consensos.
Para medirlo, el equipo construyó 6.250 redes sintéticas a partir de las 124 ubicaciones de validadores que ya existen en la cadena. La geografía de partida es la real. En la configuración que los autores destacan, el aplazamiento medio del relevo baja alrededor de 29 milisegundos.
El precio: concentración regional y geografía declarada
Ahí llega la fricción. Agrupar líderes por proximidad significa que la red puede quedarse más tiempo produciendo bloques desde una sola región. Si esa región sufre un corte de fibra o un apagón, el hueco es más largo de lo que sería con un reparto aleatorio. La dispersión geográfica es una póliza de seguro que se paga, precisamente, con latencia.
Puesto en contexto, el ahorro equivale a algo más del 7% de los 400 milisegundos que dura un slot. No es un cambio de escala, pero en una red donde el tiempo se acumula bloque a bloque, deja de ser anecdótico.
El segundo problema es más difícil de vigilar: las ubicaciones son declaradas, no verificadas criptográficamente. Si el calendario premia estar cerca, aparece un incentivo directo a mentir sobre dónde está el servidor. Un operador podría declarar la ubicación que le beneficie sin mover una sola máquina.
Los autores identifican un rango de agrupación relativamente modesto como posible equilibrio: suficiente para rascar milisegundos, lo bastante estrecho como para no romper la dispersión. Y dejan claro que esto sigue siendo investigación, no un sistema activo en mainnet.
Por qué el milisegundo se ha convertido en el nuevo campo de batalla de Solana
Solana lleva años vendiendo velocidad, pero la velocidad ya no se consigue con marketing. La red ha ido recortando la duración de sus slots y exprimiendo a sus clientes validadores; ahora el debate se desplaza a la topología, a dónde están las máquinas y en qué orden hablan entre sí.
Merece la pena recordar el precedente. En 2021 y 2022, Solana sufrió varias paradas de red que congelaron la producción de bloques durante horas, con la inundación de transacciones como cuello de botella. La solución llegó por ingeniería: mejores mecanismos de fees y, sobre todo, Firedancer, el segundo cliente validador desarrollado por Jump Crypto, que rompe la dependencia de un único software.
Ahí el trade-off de la SIMD-0675 funciona como recordatorio de cómo se decide en esta red: cada milisegundo tiene un precio en otro sitio. La aleatoriedad del calendario no existe por capricho, reparte el riesgo entre operadores y regiones. Tocar ese equilibrio exige demostrar que la ganancia compensa la pérdida de diversidad geográfica.
Hay un tercer elemento que conviene vigilar: la concentración real del stake. Buena parte del peso de la red descansa en un puñado de operadores profesionales que corren sus nodos en los mismos proveedores de nube, un detalle que puede seguirse en el panel de validadores de Solana Beach. Cualquier ordenación geográfica que ignore ese dato optimiza sobre un mapa que no refleja la infraestructura real.
Para el inversor, la lectura es menos épica de lo que suena. No hay token nuevo, ni activación inminente, ni fecha en el calendario. Hay una línea de investigación que dice en alto algo que el ecosistema tiende a esquivar: que las mejoras de rendimiento se han vuelto marginales y, por tanto, políticamente delicadas.
Quien opera un validador recibe una señal distinta. La ubicación del servidor, hasta hoy una decisión de coste eléctrico y ancho de banda, empieza a ser una variable de diseño de red.
La pregunta abierta es si la comunidad aceptará un compromiso modesto o preferirá dejarlo en el cajón. Por ahora hay un estudio. El día que se convierta en propuesta formal y se vote, sabremos si Solana está dispuesta a cambiar algo de azar por unos cuantos milisegundos.
