Solana estudia reorganizar el orden de producción de bloques según la proximidad geográfica de sus validadores para reducir los retrasos entre un productor y el siguiente. El planteamiento, sin embargo, se apoya en ubicaciones declaradas por los propios operadores que la red no puede verificar directamente, lo que introduce una variable física no demostrable en una parte crítica del consenso.
La propuesta ha sido elaborada por Roger Wattenhofer, responsable de investigación de Anza y profesor de ETH Zúrich, junto con Quentin Kniep, investigador de Anza y ETH Zúrich. Los cambios se presentaron como solicitudes de modificación el 29 de septiembre y seguían abiertos el 7 de octubre. Por tanto, se trata todavía de reglas propuestas y resultados simulados, no de un sistema geográfico ya desplegado.
Menos latencia sin cambiar las asignaciones
Solana calcula actualmente un calendario de líderes ponderado por participación. Cada validador recibe un determinado número de ventanas de liderazgo, durante las que produce bloques. El diseño planteado no altera esa cantidad: modifica el momento en que aparecen esas ventanas y el validador que las precede.
La segunda fase del algoritmo agruparía las ventanas en grupos pequeños, denominados «bins», a partir de la proximidad geográfica declarada. El objetivo es que los cambios entre líderes se produzcan con más frecuencia entre operadores cercanos. Esto resulta especialmente relevante para la transferencia rápida de bloques prevista por Alpenglow, en la que el líder anterior envía directamente su bloque al siguiente.
Según los autores, un calendario completamente aleatorio beneficia de forma indirecta a los validadores situados cerca de las mayores concentraciones de participación. Esos operadores tienen más posibilidades de estar próximos al líder al que suceden, mientras que los validadores alejados afrontan más saltos de red. Agrupar por ubicación pretende reducir esa desventaja y hacer más atractivo operar fuera de los principales centros, sin redistribuir la participación ni conceder ventanas adicionales.
En una simulación basada en la distribución de participación de la época 1038, con 661 validadores y 108.000 ventanas por época, el retraso medio entre validadores honestos cayó de 36,2 a 17,0 milisegundos al utilizar grupos de tres ventanas. La mediana de todos los cambios considerados pasó de 23,4 a 4,5 milisegundos.
El modelo asignó cada validador al área metropolitana más cercana de RIPE Atlas y estimó la latencia unidireccional como la mitad del tiempo de ida y vuelta mediano. Los cambios dentro de una misma área se contabilizaron como de latencia cero. Esas simplificaciones hacen que las cifras sean una estimación del modelo, no una medición del comportamiento real de la red. Además, la duración de un slot y el tiempo necesario para alcanzar la finalidad son intervalos distintos del retraso de transferencia analizado.
La continuidad del control plantea el principal riesgo
La reorganización geográfica también puede encadenar varias ventanas consecutivas bajo el control de una misma región o de un mismo operador. En el escenario simulado, un atacante con el 5% de la participación, situado en Sídney y sin otros validadores en Oceanía, llegó a acumular seis ventanas seguidas: dos grupos consecutivos de tres.
El umbral propuesto es del 10% de la participación para definir el alcance de cada vecindario. En zonas densamente pobladas, el radio necesario sería menor; en áreas con pocos validadores, mayor. Pero un grupo puede contener menos del 10% de la participación y varias ventanas del mismo operador. El diseño reconoce que una interrupción regional, de red o de jurisdicción podría afectar a líderes consecutivos y provocar más huecos de slots que un calendario aleatorio. También podría facilitar episodios de censura regional durante esas rachas.
Con cuatro slots por ventana y una duración de 200 milisegundos, un grupo de tres ventanas abarcaría idealmente 2,4 segundos. Esa cifra no limita necesariamente la exposición, ya que el control puede prolongarse al enlazar grupos adyacentes.
La red no puede comprobar dónde está cada máquina
La propuesta complementaria, SIMD-0674, permitiría registrar coordenadas declaradas en las cuentas de voto de los validadores. Las actualizaciones estarían firmadas y una comprobación geométrica verificaría que el punto se encuentra cerca de la superficie terrestre, pero ninguna de esas medidas demostraría dónde está físicamente la máquina.
SIMD-0675 confía en que mentir sobre la ubicación resulte normalmente perjudicial para el propio operador: si declara una ciudad lejana, podría quedar detrás de líderes más distantes de su infraestructura real. Las pruebas no eliminan por completo el incentivo a falsear los datos. Un validador situado en Ashburn, por ejemplo, redujo su latencia media modelada de 23,7 a 21,0 milisegundos al declarar São Paulo. Los autores no encontraron otra falsificación no equivalente que mejorase el resultado en más de 0,3 milisegundos, pero el caso limita la eficacia de los incentivos económicos como mecanismo de verificación.
La propuesta también elevaría HANDOVER_COMPENSATION de 25 a 50 milisegundos. No se trata de una remuneración, sino de un ajuste temporal para compensar la producción optimista de bloques antes de ParentReady. La solicitud de cambios del calendario no tenía revisiones registradas, mientras que la de registro de ubicaciones había recibido una aprobación con observaciones y continuaba abierta. Su eventual activación requeriría una modificación del consenso y una activación específica de la red.
