La red cambió de consenso tras una breve ventana de transición
La época 1064 comenzó sobre las 13:36 UTC del 21 oct. El indicador de activación de la red se activó al inicio de la época, pero la red siguió utilizando TowerBFT durante los primeros 5,000 slots. Esa ventana de transición duró unos 18 minutos.
Alpenglow tomó el control hacia las 13:54 UTC desde el slot 459,653,000. Solana informó de que 446 de 654 validadores certificaron el bloque de transición. El retraso estaba previsto y dio a los operadores un punto claro en el que comprobar si el nuevo sistema de consenso había arrancado.
Votor sustituye las transacciones de voto por mensajes directos entre validadores
Según TowerBFT, los validadores emitían votos dentro de transacciones y la finalización de bloques dependía de que los votos se acumularan a lo largo de 32 slots. Alpenglow‘s Votor el sistema envía los votos directamente entre validadores y los combina en certificados. Un bloque puede quedar final tras una o dos rondas de votación.
Las carteras y los programas ordinarios no necesitan un nuevo formato de transacción. La Solana Virtual Machine, las cuentas y el modelo de comisiones se mantienen. El beneficio práctico es una mayor rapidez para tener la certeza de que una transferencia confirmada o una acción dentro de una aplicación no se puede revertir.
El tiempo de slot de 200 milisegundos es un cambio independiente
Solana redujo su tiempo de slot de 400 a 200 milisegundos en una actualización independiente de octubre. El tiempo de slot describe con qué frecuencia la red puede producir un nuevo slot. Alpenglowla cifra de aproximadamente 150 milisegundos describe el tiempo objetivo para finalizar un bloque. Ambas cifras miden partes distintas del sistema.
El objetivo no es un resultado fijo: el tiempo de finalización de un bloque puede variar según las condiciones de la red y la ubicación de los validadores. Los exchanges y las aplicaciones deberían medir el comportamiento real en lugar de tratar los 150 milisegundos como una promesa para cada transferencia.
| Detalle | Información confirmada |
|---|---|
| La época 1064 comenzó | Sobre las 13:36 UTC del 21 oct 2026 |
| El consenso cambió a Alpenglow | Hacia las 13:54 UTC en el slot 459,653,000 |
| Tiempo objetivo para finalizar un bloque | Unos 150 ms, frente a los aproximadamente 12.8 segundos de TowerBFT |
| Actualización independiente del tiempo de slot | 200 ms |
| Clientes de validador compatibles | Agave, Jito-Solana y Harmonic Salsa |
| Validator Admission Ticket | 0.8 SOL por época desde la cuenta de voto |
| Componente futuro | Rotor protocolo de distribución de bloques |
Los servicios de datos deben distinguir varias versiones de un mismo slot
Un slot puede tener temporalmente más de un bloque candidato, lo que Solana denomina bancos candidatos. Un bank_id identifica un candidato dentro de una conexión de datos. Los indexadores deben mantener esas versiones separadas hasta que una quede confirmada. Al comparar datos de distintos proveedores, deberían usar el hash del bloque porque bank_id los valores son locales a cada conexión.
Las transacciones de voto ya no aparecen dentro de los bloques. Por tanto, los paneles que antes contaban esos votos como transacciones pueden mostrar una caída repentina en los TPS incluso cuando la actividad de los usuarios no cambia. Se trata de un cambio contable, no de una prueba de que la red haya perdido tráfico.
Los validadores necesitan software compatible y fondos para la entrada
Los validadores de la mainnet deben ejecutar versiones compatibles de Agave, Jito-Solana o Harmonic Salsa. También necesitan al menos 0.8 SOL por encima del mínimo exento de renta en la cuenta de voto. Ese importe financia la Validator Admission Ticket, identificado en la documentación con la abreviatura inglesa V-A-T, para la próxima época.
El Validator Admission Ticket sustituye el coste recurrente de enviar transacciones de voto. Si la cuenta de voto no puede pagar la entrada, el validador no podrá votar ni producir bloques en la época siguiente. Los operadores pueden dirigir los ingresos futuros por bloques a la cuenta, pero siguen necesitando un colchón inicial.
Rotor se introducirá más adelante
La versión live de la mainnet incluye Votor. Rotor, el sustituto previsto para la distribución de datos de bloque Turbine, llegará más adelante y no tiene fecha de activación confirmada. El cambio de consenso está completo, pero el Alpenglow el plan de red aún no está plenamente desplegado.
Para los usuarios, la mejora inmediata es una confirmación final más rápida. Los exchanges, los exploradores y los proveedores de datos deben ahora gestionar correctamente los bancos candidatos y el recuento revisado de transacciones para que sus servicios muestren con precisión la actividad de la red.
Este artículo es solo informativo y no constituye asesoramiento de inversión.
admin_wcColaborador · World-CryptMás de
