El borrador reduce los límites por slot a medida que los slots se acortan, ajustando los traspasos del líder y la temporización en cadena sin aumentar el techo teórico de CU por segundo.
El objetivo de la Mainnet de 350 ms de Solana está configurado para entrar en vigor en el epoch 1020, por debajo del objetivo actual de 400 ms para el tiempo del slot. La funcionalidad activada al inicio del epoch 1019, pero un retraso de un epoch significa que la red mantiene sus parámetros existentes hasta el siguiente epoch. En términos prácticos, los bloques obtienen un intervalo de producción objetivo más corto sin recibir una mayor asignación de cómputo por segundo.
El despliegue ya está más avanzado en otros lugares. Testnet está en un objetivo efectivo de 200ms, mientras que Devnet está en 300ms y ha activado su puerta de 250ms sin haberla hecho efectiva todavía. El changelog del 6 de agosto de Solana había listado solo el paso de 350ms en los dos clústeres de prueba, mostrando qué tan rápido han avanzado las etapas posteriores.
La funcionalidad de 350ms de Mainnet se activó en el slot 440,208,000, el primer slot de la epoch 1019. Bajo el retraso en SIMD-0525, Mainnet permanece en un objetivo efectivo de 400ms durante esa epoch y cambia a 350ms en la epoch 1020.
SIMD-0525 sigue siendo un borrador. La activación de la funcionalidad muestra que un cambio específico de un clúster está avanzando a través de la red, no que el diseño completo de 200ms se haya convertido en un estándar final aceptado. Las cifras también son temporizaciones objetivo, que son distintas de la producción de bloques observada, la latencia de confirmación y la finalización económica.
El changelog del 30 de julio de Solana informó que Mainnet ya había activado un límite máximo de bloques de 100 millones de unidades de cómputo. SIMD-0525 muestra cómo ese máximo de 400ms se combinaría con las etapas de tiempo de slot: 87.5 millones de CUs a 350ms, 75 millones a 300ms, 62.5 millones a 250ms y 50 millones a 200ms.
Ese techo no es un pronóstico de rendimiento transaccional. El uso real depende de la carga de trabajo y las condiciones de la red, y la cifra de 100 millones es un ejemplo de composición para CUs máximas de bloques, más que una línea base universal para cada límite.
La temporización por epoch también se comprime. SIMD-0525 mantiene cada epoch en 432,000 slots, por lo que la duración nominal baja de aproximadamente 48 horas a 400ms a 24 horas a 200ms. La cantidad de slots se mantiene fija, pero su significado en tiempo de reloj cambia.
El mismo problema de compatibilidad se extiende a software fuera del validador. Algunas constantes de SDK y supuestos fuera de la cadena siguen ligados a 400ms, así que una aplicación que estima el tiempo transcurrido multiplicando un conteo de slots por 400ms puede no coincidir con el clúster cuando una etapa más rápida se vuelve efectiva.
Los clientes RPC, los exploradores y otros servicios fuera de la cadena pueden usar la distancia de slots para estimar la frescura o el tiempo transcurrido. La dirección de más largo plazo de la propuesta es que el software obtenga parámetros de temporización efectivos del clúster en lugar de tratar una constante en tiempo de compilación como permanente.
El Ticket de Admisión del Validador de Alpenglow ilustra la versión económica de esa falta de coincidencia. El escalado en SIMD-0525 solo aplica si el mecanismo de Alpenglow VAT dependiente está activo. En ese caso, el cargo propuesto pasa de 1.6 SOL por epoch en 400ms a 0.8 SOL por epoch en 200ms, conservando un objetivo diario aproximado de 0.8 SOL. La evidencia disponible no establece que la recolección de VAT esté activa en ningún clúster.