¿Qué cambia exactamente?
Solana reduce el tiempo objetivo de producción de bloque (slot time) en la mainnet de 400 milisegundos a 350 milisegundos. Según el reportaje de CryptoSlate, este cambio se activó al inicio de la época 1019, pero debido al llamado retraso de una época (one-epoch delay) la red conserva los parámetros actuales y el nuevo objetivo de 350 ms empezará a regir de hecho a partir de la época 1020.
Solo para aclarar los conceptos: el slot time es el intervalo objetivo en el que debe producirse un bloque. La época es una ventana de tiempo más larga compuesta por muchos slots, tras la cual se aplican algunos cambios de parámetros. Las compute units (unidades de cómputo) son la medida de cuánto cómputo puede contener un bloque.
¿Por qué se baja al mismo tiempo el límite de cómputo por bloque?
Este es el núcleo de toda la historia. Según CryptoSlate, los bloques reciben un intervalo objetivo de producción más corto, pero no reciben un mayor volumen de cómputo permitido por segundo. En la práctica esto significa que, cuando los bloques se producen con más frecuencia, cada bloque individual debe ser más "ligero", para que la carga total sobre la red y los validadores por unidad de tiempo se mantenga aproximadamente constante.
La lógica es sencilla: acelerar los bloques sin ajustar el límite de cómputo supondría más cómputo por segundo, lo que podría sobrecargar a los validadores y comprometer la estabilidad de la red. Reducir el límite por bloque es, por tanto, un seguro, no un efecto secundario.
¿Qué tan avanzadas están las redes de prueba?
Según CryptoSlate, el despliegue está más adelantado en otras redes que en la mainnet:
| Red | Estado del tiempo objetivo de bloque |
|---|---|
| Mainnet | transición de 400 ms a 350 ms (de hecho desde la época 1020) |
| Testnet | objetivo efectivo de 200 ms |
| Devnet | objetivo de 300 ms, gate de 250 ms activado, pero aún no efectivo |
Testnet y Devnet sirven, por tanto, como etapa previa donde se prueban valores más agresivos antes de que lleguen a la mainnet.
¿De dónde viene este cambio?
CryptoSlate remite al changelog de Solana del 6 de agosto, donde se describen estos parámetros. La reducción gradual del tiempo de bloque forma parte de un esfuerzo más amplio y a largo plazo de Solana por lograr una menor latencia de red.
¿Qué todavía no está claro?
De la fuente disponible no se desprende la fecha exacta en el calendario en la que ocurrirá la época 1020, ni el valor numérico concreto de cuánto exactamente se reduce el límite de cómputo por bloque. Tampoco queda documentado en esta fuente qué impacto real tendrá el cambio en la latencia de las transacciones, las comisiones o la estabilidad de la red para los usuarios finales. Eso se verá según el comportamiento de la mainnet tras la época 1020.
¿A qué prestar atención en este tipo de cambios?
En los ajustes de parámetros del blockchain a nivel de protocolo es útil vigilar tres cosas: si el cambio realmente se activa en la época anunciada, si no se producen caídas imprevistas o ralentización en la producción de bloques, y si el rendimiento (número de transacciones por segundo) cambia realmente o se mantiene estable. Precisamente porque aquí Solana mantiene deliberadamente constante el cómputo por segundo, la métrica principal a verificar es más bien la latencia y la estabilidad que el rendimiento bruto.
charliedesk anota este cambio para poder compararlo más adelante con lo que realmente ocurra en la red tras la época 1020.