¿La finalidad de Solana en 150 milisegundos hará que las carteras también muestren «completado» en 150 milisegundos?
Para los pagos y las aplicaciones on-chain, esperar unos segundos menos puede ser muy valioso, pero la experiencia del usuario también depende de los nodos RPC y de las aplicaciones. Lo interesante de Alpenglow es estudiar cómo llega esta información a los usuarios una vez que se acelera la confirmación del consenso.
La guía actualizada por la Fundación Solana en octubre sitúa el plan de migración de la red principal en la época 1064 y estima que comenzará el 21 de octubre a las 23:00, hora de Pekín. La hora exacta puede variar según avance la época. La página actual sigue indicando que aún no se ha activado en la red principal; unos 150 milisegundos es el objetivo de finalidad, no un resultado medido que pueda atribuirse ya a todas las transacciones.
En esta revisión también verifiqué la documentación de Anza y descubrí que hay distintas vías para recibir los resultados de confirmación. Los validadores que forman parte del conjunto de admisión intercambian directamente mensajes de consenso Votor. Los nodos que quedan fuera del conjunto pueden recibir los mensajes a través de validadores colaboradores; la latencia adicional depende principalmente de la red entre ambas partes. Si solo se lee el certificado de finalidad al final de un bloque posterior, normalmente hay que esperar además un intervalo real de producción de bloques; si se omite un bloque o hay retrasos, puede tardar más.
Esto significa que alcanzar la finalidad por consenso y que un nodo RPC determinado conozca el resultado son dos momentos distintos. En mi opinión, para que las aplicaciones de pago ofrezcan una experiencia perceptiblemente más rápida, no basta con actualizar la red: también importa cómo reciben los nodos el resultado y cómo se lo entregan a la aplicación. A la inversa, si una cartera sigue pareciendo lenta, el retraso también podría deberse a la obtención de datos o a cómo se muestran en la interfaz; no se puede concluir solo por la percepción que la actualización del consenso no haya surtido efecto.
Tras la migración, confirmed y finalized serán equivalentes, mientras que processed seguirá siendo un estado distinto. Según la información oficial, los usuarios habituales no tendrán que cambiar el proceso de firma y envío. Los desarrolladores, por su parte, deberán revisar las estrategias de confirmación cuando la activación sea efectiva, sin aplicar por adelantado las reglas futuras a la red actual.
En los datos de Binance recopilados a las 10:05, el precio spot de SOL/USDT bajó aproximadamente un -0,39 % entre las 09:00 y las 10:00, con un volumen de unos 5,544 millones de dólares, aproximadamente 1,41 veces la media de las cinco horas anteriores. Esto solo aporta contexto de mercado; no demuestra nada sobre la latencia on-chain ni sobre el éxito de la actualización.
El siguiente paso es comprobar primero el estado real de la migración y luego medir por etapas, usando el mismo RPC, el tiempo desde el envío hasta la confirmación final y desde ahí hasta que se muestra en la interfaz. Si se modifica el plan o la experiencia real no mejora, habrá que reevaluar el beneficio para el producto: el objetivo del protocolo no puede sustituir a la experiencia del usuario. $SOL
Para los pagos y las aplicaciones on-chain, esperar unos segundos menos puede ser muy valioso, pero la experiencia del usuario también depende de los nodos RPC y de las aplicaciones. Lo interesante de Alpenglow es estudiar cómo llega esta información a los usuarios una vez que se acelera la confirmación del consenso.
La guía actualizada por la Fundación Solana en octubre sitúa el plan de migración de la red principal en la época 1064 y estima que comenzará el 21 de octubre a las 23:00, hora de Pekín. La hora exacta puede variar según avance la época. La página actual sigue indicando que aún no se ha activado en la red principal; unos 150 milisegundos es el objetivo de finalidad, no un resultado medido que pueda atribuirse ya a todas las transacciones.
En esta revisión también verifiqué la documentación de Anza y descubrí que hay distintas vías para recibir los resultados de confirmación. Los validadores que forman parte del conjunto de admisión intercambian directamente mensajes de consenso Votor. Los nodos que quedan fuera del conjunto pueden recibir los mensajes a través de validadores colaboradores; la latencia adicional depende principalmente de la red entre ambas partes. Si solo se lee el certificado de finalidad al final de un bloque posterior, normalmente hay que esperar además un intervalo real de producción de bloques; si se omite un bloque o hay retrasos, puede tardar más.
Esto significa que alcanzar la finalidad por consenso y que un nodo RPC determinado conozca el resultado son dos momentos distintos. En mi opinión, para que las aplicaciones de pago ofrezcan una experiencia perceptiblemente más rápida, no basta con actualizar la red: también importa cómo reciben los nodos el resultado y cómo se lo entregan a la aplicación. A la inversa, si una cartera sigue pareciendo lenta, el retraso también podría deberse a la obtención de datos o a cómo se muestran en la interfaz; no se puede concluir solo por la percepción que la actualización del consenso no haya surtido efecto.
Tras la migración, confirmed y finalized serán equivalentes, mientras que processed seguirá siendo un estado distinto. Según la información oficial, los usuarios habituales no tendrán que cambiar el proceso de firma y envío. Los desarrolladores, por su parte, deberán revisar las estrategias de confirmación cuando la activación sea efectiva, sin aplicar por adelantado las reglas futuras a la red actual.
En los datos de Binance recopilados a las 10:05, el precio spot de SOL/USDT bajó aproximadamente un -0,39 % entre las 09:00 y las 10:00, con un volumen de unos 5,544 millones de dólares, aproximadamente 1,41 veces la media de las cinco horas anteriores. Esto solo aporta contexto de mercado; no demuestra nada sobre la latencia on-chain ni sobre el éxito de la actualización.
El siguiente paso es comprobar primero el estado real de la migración y luego medir por etapas, usando el mismo RPC, el tiempo desde el envío hasta la confirmación final y desde ahí hasta que se muestra en la interfaz. Si se modifica el plan o la experiencia real no mejora, habrá que reevaluar el beneficio para el producto: el objetivo del protocolo no puede sustituir a la experiencia del usuario. $SOL