La finalidad más rápida de Solana ya está activa: ¿qué cambia para los usuarios?

Solana ha estado ejecutando Alpenglow en la mainnet desde el 21 de octubre, reemplazando un sistema de votación que podía tardar varios segundos en finalizar un bloque por uno diseñado para terminar en una fracción de segundo. La Fundación Solana registra el cambio en la época 1064, después de que 446 de 654 validadores certificaran un bloque génesis.

Un usuario que envía SOL podría ver un pago aparecer casi de inmediato y preguntarse qué mejoró la actualización. Una billetera puede mostrar que una transacción fue procesada antes de que la red la haya hecho final. Alpenglow comprime la espera para la garantía más fuerte, pero la aplicación todavía tiene que enviar el pago, recibir la respuesta de un nodo y decidir cuándo cambiar su propia visualización. Un exchange puede imponer otra espera antes de acreditar una cuenta.

El registro de la actualización de la Fundación dice que los formatos de transacción, los programas y las comisiones no cambiaron. Los desarrolladores que solo envían pagos y leen saldos de cuentas no necesitan un nuevo formato de transacción. Quienes manejan flujos de bloques tienen más trabajo, porque la ruta desde un bloque propuesto hasta uno acordado es diferente. La pregunta práctica ahora es qué servicios transmiten esa finalidad más rápida a los clientes y cuáles continúan usando sus antiguos calendarios de confirmación.

El cambio ha ocurrido, pero 150 milisegundos es un objetivo

Alpenglow reemplazó a TowerBFT, el antiguo proceso de consenso de Solana, el 21 de octubre. En el antiguo sistema los validadores ponían transacciones de voto en la cadena y un bloque reunía suficientes votos a lo largo de slots posteriores para volverse final. Votor, la parte activa de Alpenglow, transporta los votos directamente entre validadores y los combina en certificados. Un bloque puede finalizarse en una o dos rondas de votación.

La Fundación usa 12,8 segundos como referencia para la antigua finalidad y aproximadamente 150 milisegundos como el nuevo objetivo. Esos números describen una comparación de protocolos, no dos mediciones tomadas desde la misma billetera en condiciones idénticas. El informe de preparación del 21 de octubre advirtió que los nodos RPC sin stake podrían enterarse de la finalidad más tarde que los validadores participantes, a veces después de que se produzca otro bloque. La latencia de Internet y el nodo elegido por una aplicación se suman a lo que ve el usuario.

Una medición externa publicada el 23 de octubre situó la finalidad mediana en 404 milisegundos durante las 24 horas anteriores, con un percentil 90 de 579 milisegundos y un percentil 99 de 765 milisegundos. Su referencia anterior era de aproximadamente siete segundos bajo TowerBFT. Con esas cifras la mediana mejoró unas 17 veces, calculado dividiendo siete segundos entre 0,404 segundos. La metodología y el punto de observación difieren de la línea base de 12,8 segundos de la Fundación y del objetivo de diseño de 150 milisegundos.

El panel en vivo de la Fundación muestra una lectura cambiante de la última finalidad observada y tendencias en varias ventanas temporales. Un valor más reciente no debería promoverse como una experiencia típica del cliente. La serie útil incluye la latencia mediana y de cola, las interrupciones y el tiempo que tardan distintos proveedores en informar el mismo bloque finalizado. Un único slot especialmente rápido demuestra que el protocolo puede alcanzar esa velocidad una vez; dice poco sobre el pago de un comerciante durante una hora de mucho tráfico.

La distinción entre objetivo y medición fue central en la cuestión de la preparación de los validadores antes de la activación. Desde entonces, la mainnet ha proporcionado un certificado y varios días de bloques medibles. Una pregunta ha sido respondida: los validadores sí coordinaron el cambio. Si el cliente típico de RPC ve algo cercano al objetivo anunciado es ahora una pregunta diferente, porque la fundación y los monitores externos inician sus relojes en puntos distintos. Informar ambas cifras con esos puntos de partida permite a los lectores comparar el rendimiento real sin tratar la observación más lenta como evidencia de que el diseño del consenso falló.

La producción de bloques de Solana se aceleró mediante otro programa que redujo el tiempo de slot objetivo de 400 a 200 milisegundos en octubre. Esa medida se refiere a la frecuencia con la que un líder produce un bloque. La finalidad se refiere a cuándo la red acuerda que un bloque particular no puede revertirse bajo sus reglas. Slots más rápidos y finalidad más rápida pueden ambos ayudar a un usuario, pero las dos cifras no deben sumarse ni tratarse como el mismo reloj.

La cifra anunciada depende de qué participantes reciben un bloque propuesto a tiempo para votar. Una ruta rápida puede certificar un bloque con prontitud, mientras que una ruta de respaldo acomoda una comunicación más lenta. Una ronda lenta no implica por sí misma una actualización fallida: el consenso debe seguir acordando cuándo un validador pierde un mensaje o la propuesta de un líder compite con otra. La mediana puede mejorar drásticamente mientras un pequeño número de slots tarda más. Los servicios que manejan transferencias grandes se preocuparán por la cola lenta tanto como por el objetivo principal.

Un observador público debería preguntar dónde comienza un temporizador de finalidad. Comenzar cuando un validador recibe un bloque propuesto excluye el tiempo que una billetera pasó difundiendo su transacción. Comenzar cuando un comerciante pulsa "cobrar" incluye a un humano y varios sistemas de software. Comenzar cuando un servidor RPC ve un certificado incluye el retraso entre los validadores y el servidor. Cada reloj responde a una pregunta diferente. La medición externa del 23 de octubre es útil porque su método y distribución pueden examinarse por separado de la afirmación de diseño de la Fundación.

Una billetera tiene más de un reloj

Imagina pagar un café con una billetera de Solana. El usuario primero aprueba una transacción localmente. La billetera la envía a través de un servicio RPC, la red la incluye en un bloque candidato y los validadores certifican ese bloque. El sistema del comerciante recibe una actualización de estado y decide si entregar el café. Alpenglow cambia la etapa de certificación, no el tiempo que se tarda en abrir la billetera ni la política propia del comerciante.

Muchas aplicaciones ya mostraban un mensaje de éxito antes de la finalidad de TowerBFT. Estaban usando un nivel de compromiso menos final porque la mayoría de los pagos minoristas no esperan la garantía de consenso más fuerte antes de cambiar la pantalla. Un estado finalizado más rápido podría permitir que una aplicación ofrezca una garantía más fuerte aproximadamente a la velocidad de su estado temprano anterior. La mejora será visible solo si el servicio actualiza su regla de espera y su proveedor entrega el resultado con prontitud.

Un depósito en un exchange ilustra el límite. Una transferencia puede ser final en Solana mientras el exchange aún verifica al remitente, asocia la dirección con una cuenta, examina el riesgo y aplica una política interna de acreditación. El nuevo tiempo de finalidad de la cadena no puede obligar al exchange a liberar un saldo de inmediato. Un puente necesita un relé de mensajes, ejecución en la cadena de destino y a menudo sus propias salvaguardas. La liquidación entre dos sistemas, por lo tanto, sigue siendo más lenta que la finalidad de la cadena de origen por sí sola.

La cuenta de la testnet de septiembre estableció la distinción antes del lanzamiento. Describía un nuevo proceso de votación, no una nueva forma de firmar pagos ordinarios. Ahora hay un registro en mainnet que verificar. Los proveedores pueden comparar el momento en que un cliente envía una transacción, el momento en que un validador la certifica y el momento en que su API informa la finalidad. Sin esas marcas de tiempo separadas, una afirmación de un pago de usuario de 150 milisegundos oculta las partes que no se midieron.

La palabra "instantáneo" seguirá siendo tentadora en el marketing. Un cliente de pie en un mostrador se preocupa de si el comerciante recibe una aceptación confiable antes de dar la espalda, lo cual es una medida de servicio de extremo a extremo. Un trader se preocupa de si un mercado actualiza los saldos antes de la siguiente oportunidad de mercado. Ambos pueden beneficiarse incluso si la billetera nunca muestra un estado de finalidad explícito. A ninguno se le debería prometer que cada interacción se completa en 150 milisegundos.

Un operador de punto de venta toma dos decisiones independientes. Elige cuándo un pago es suficientemente seguro para liberar mercancía, y elige cómo manejar una conexión interrumpida. Un certificado de consenso rápido mejora la primera decisión pero no hace que un terminal sin conexión reciba una respuesta. Un procesador puede enviar un mensaje de éxito provisional y conciliarlo más tarde, o esperar el estado finalizado. Lo que importa en el punto de venta es la política real, incluido cómo aparecen en la pantalla los envíos duplicados y las respuestas retrasadas.

Las aplicaciones financieras tienen otras razones para distinguir la velocidad de la política. Una aplicación de préstamos puede registrar la garantía cuando se procesa una transferencia pero permitir el préstamo solo después de la finalización. Un centro de negociación centralizado puede observar los saldos finalizados mientras aplica su propia retención de retiros. Un puente debe manejar el riesgo de la cadena receptora además del de Solana. Un certificado más rápido crea la oportunidad de acortar la porción dependiente de la cadena de cada flujo de trabajo. Publicar los tiempos de servicio antes y después mostraría dónde los proveedores aprovechan esa oportunidad.

Menos transacciones en el gráfico puede significar la misma cantidad de uso

Bajo TowerBFT, la votación de los validadores formaba parte del flujo de transacciones en cadena. Los validadores de Alpenglow se comunican directamente y colocan la información de certificación en los pies de bloque, por lo que esas transacciones de voto ya no aparecen en el recuento ordinario de transacciones por bloque. Un panel que mostraba todas las transacciones por segundo puede caer después del cambio sin una caída en las transferencias, intercambios o pagos realizados por los usuarios.

El cofundador de Solana, Anatoly Yakovenko, discutió la eliminación de las transacciones de voto poco antes de la activación, cuando el cambio en el TPS principal estaba atrayendo atención. Los analistas que comparen el tráfico del 20 de octubre con el tráfico posterior al 21 de octubre deberían aislar las transacciones que no son de voto en ambos lados. De lo contrario, un cambio contable parece una demanda perdida. El error inverso sería afirmar que el menor tráfico de votos por sí mismo crea un número igual de transacciones de usuario útiles adicionales; la capacidad disponible y el uso real son cosas diferentes.

La aritmética se puede verificar sin inventar una nueva estimación de rendimiento. Si un recuento previo a la actualización combina transacciones de usuario U y votos de validador V, su total es U + V. Después de que los votos salen del bloque, un gráfico similar puede mostrar aproximadamente U incluso cuando los clientes envían la misma cantidad de transferencias. La diferencia V es un cambio en lo que cuenta el gráfico. Calcular el crecimiento real requiere series comparables solo de usuarios, no los totales principales antes y después.

Esto también importa para los comentarios sobre comisiones e ingresos. Las comisiones por transacciones de voto desaparecen, mientras que los validadores en su lugar pagan un Boleto de Admisión de Validador. La mecánica de las comisiones por transacciones de usuario se mantiene en su lugar. Un cambio en los ingresos totales por comisiones vinculado a la categoría de votos perdida no puede presentarse simplemente como un cambio en la disposición del consumidor a realizar transacciones. Una comparación cuidadosa separa los gastos relacionados con votos, las comisiones de admisión y las comisiones que los usuarios pagan por enviar o priorizar sus propias transacciones.

Los exploradores de bloques y los proveedores de datos enfrentan una tarea relacionada. La participación que antes se leía de las instrucciones del programa de votos ahora tiene que leerse de los certificados y de los datos del pie de bloque. Un proveedor que continúe analizando el campo antiguo puede mostrar votos de validador faltantes incluso mientras la red finaliza bloques con normalidad. La documentación de Solana advierte que algunas interfaces de transmisión aún no reenvían cada elemento de los metadatos del certificado, lo que hace que la documentación del proveedor sea parte de cualquier comparación de rendimiento seria.

Un gráfico de transacciones por segundo es vulnerable durante un cambio de protocolo porque a menudo agrega categorías diferentes. Un centro que afirme que la actividad de los usuarios cayó inmediatamente después de la activación necesita el recuento solo de usuarios en ambas fechas, idealmente desglosado en transferencias exitosas, intercambios e intentos fallidos. Las transacciones no son personas únicas ni compras completadas. Un bot puede generar muchas instrucciones, y una instrucción fallida aún puede aparecer en una serie de transacciones enviadas. Una reducción en la votación de validadores no dice nada por sí misma sobre los comerciantes que aceptan Solana.

La distinción también importa para la economía de la red. La desaparición de las comisiones por votos reduce un tipo de pago en cadena por parte de los validadores. El boleto de admisión se quema desde otra cuenta en un calendario diferente. Las comisiones de usuario dependen de lo que envían los clientes y de la prioridad que pagan. Combinar los tres en una sola tendencia de ingresos ocultaría si la demanda cambió o si la contabilidad se movió. Categorías consistentes en ambos lados del 21 de octubre ofrecen una base más sólida para interpretar un gráfico de comisiones.

Los servicios de datos tienen que seguir el bloque ganador

Una decisión de votación rápida no hace que cada bloque propuesto sea el ganador. Los flujos de datos actualizados de Solana pueden exponer más de un banco candidato para una ranura, y Agave 4.3 etiqueta los eventos con un bank_id para que los clientes puedan mantener los candidatos separados. Un indexador que agrupe todos los datos bajo un número de ranura puede mezclar accidentalmente transacciones de candidatos competidores en un registro de un bloque que nunca existió de esa forma.

La Fundación indica a los consumidores de transmisiones que almacenen en búfer por el par de identificador de ranura y banco y retengan el banco que alcanza la confirmación. Si fusionan fuentes de diferentes proveedores, el identificador solo tiene sentido dentro de cada conexión; el hash del bloque es la referencia entre proveedores. Parte del comportamiento más frecuente de múltiples bancos se espera en Agave 4.4, así que hay tiempo para ajustarse antes de que se vuelva común, pero las aplicaciones que manejan flujos de bloques actuales deberían prepararse ahora.

La mayoría de los usuarios de billeteras nunca verán un identificador bancario. Una aplicación de portafolio o un exchange que reconstruye depósitos a partir de una fuente defectuosa podría mostrar un pago demasiado pronto, omitir uno o adjuntar una transferencia al candidato de bloque equivocado. Un sistema de trading que reacciona a eventos tempranos del flujo tiene que saber si pertenecían al bloque final. El protocolo puede finalizar rápidamente mientras los errores de un indexador aún retrasan o distorsionan lo que la gente ve.

Las notas de migración a la mainnet de la Fundación dicen que los niveles de compromiso confirmado y finalizado ahora describen el mismo estado, aunque el primero sigue disponible por el momento y se eliminará en una versión posterior. Se aconseja a los desarrolladores que orienten el trabajo nuevo hacia finalizado y que revisen la configuración de timeout o reintento ajustada a la antigua espera. Un servicio que espera 12 segundos por costumbre puede seguir siendo lento a pesar de una cadena mucho más rápida.

Los flujos de datos tienen otros cambios. La Proof of History ya no marca el ritmo de la producción de bloques de la misma manera, por lo que las entradas de tick salen del flujo de shreds. Un programa que lee la marca de tiempo del Clock puede ver una fuente diferente a la anterior. Estos detalles no son señales de que las transacciones de los usuarios hayan cambiado su formato. Son puntos donde el software construido en torno a la antigua sincronización del ledger puede necesitar trabajo antes de que la nueva velocidad de la red llegue a la pantalla.

Para un indexador, el problema es más que un nuevo nombre de campo. Puede recibir el mismo slot a través de dos conexiones y procesar transacciones en orden de llegada. Si los flujos llevan eventos de bancos competidores y su base de datos indexa los registros solo por slot, los registros posteriores pueden sobrescribir los anteriores o crear una mezcla imposible. La clave de slot y banco de la guía de migración evita esto dentro de un flujo; el hash del bloque ganador final reconcilia a los proveedores. Los clientes notan este trabajo solo cuando un saldo o un historial de operaciones se vuelve más fiable.

La lógica de reintento merece otra mirada. Un cliente que consulta una vez por segundo puede perder la mayor parte del beneficio de una mejora de consenso de unos pocos cientos de milisegundos. Otro puede enviar el mismo pago de nuevo porque una respuesta llega después de su timeout. Los clientes bien diseñados distinguen una respuesta lenta de una transacción no procesada y conservan los identificadores entre reintentos. Los operadores necesitan probar esos comportamientos con el nuevo flujo de compromiso antes de prometer un tiempo de pago fijo.

Los validadores tienen una nueva factura recurrente

Eliminar las transacciones de voto en la cadena altera los costos de los validadores. La Fundación Solana dice que votar costaba anteriormente alrededor de 1 SOL por época en comisiones de transacción, pagado desde la cuenta de identidad de un validador. El nuevo Validator Admission Ticket quema 0.8 SOL por época desde su cuenta de voto, además del mínimo exento de renta. El ticket comprado al inicio de una época admite al validador para la siguiente.

Un validador que no mantiene suficiente SOL en la cuenta correcta no puede votar ni producir bloques en la época siguiente y pierde la oportunidad de ganar sus recompensas allí. Enviar el monto a la antigua cuenta de identidad no pagará la nueva tarifa. Los operadores pueden dirigir los ingresos por bloques a la cuenta de voto, aunque la Fundación dice que ese cambio tarda dos épocas y los ingresos por comisión pueden ser insuficientes en un límite determinado.

La comparación entre aproximadamente 1 SOL y 0.8 SOL no es un ahorro neto universal. Los ingresos, el stake, los costos de software, las comisiones y el momento de cada cargo difieren entre validadores. El hecho fiable es qué cuenta paga, cuánto es la tarifa plana de admisión y qué sucede si se omite. La concentración a largo plazo dependerá de si los operadores más pequeños pueden sostener los requisitos operativos y financieros mientras siguen siendo competitivos.

El lanzamiento requería Agave 4.3.2 o clientes compatibles Jito-Solana o Harmonic Salsa. Firedancer y Frankendancer no eran compatibles para la migración, según la página de operadores de la Fundación. La activación de Alpenglow prueba que la red podía cambiar con los validadores participantes; no muestra que todos los clientes de validador alternativos estuvieran listos para el mismo día. La diversidad de clientes sigue siendo una cuestión de resiliencia aparte.

La aprobación de la gobernanza llegó antes de la migración.El plan de despliegue anterior describía el código en Agave 4.2 durante las pruebas, pero la instalación por sí sola nunca fue el cambio de mainnet. El certificado de génesis y el inicio del consenso en el slot 459,653,000 son la evidencia de la activación. Los 446 firmantes del primer certificado representaron un evento de coordinación concreto, no una promesa sobre la asistencia o el rendimiento de los 654 validadores cada hora después.

El ticket plano cambia la economía de los validadores de manera diferente según el tamaño. Un operador grande y uno pequeño pagan los mismos 0.8 SOL por la entrada, por lo que el cargo consume una mayor fracción de las recompensas brutas de un operador pequeño. Si eso ahuyenta a alguien depende del stake delegado, la comisión, los costos operativos y otros ingresos. La guía para operadores establece la mecánica de pago; no pronostica cuántos validadores se irán. Un seguimiento útil compararía operadores independientes activos y la concentración de stake a lo largo de múltiples épocas.

El cambio de cuenta puede crear una interrupción evitable incluso para una operación saludable. El ticket proviene de la cuenta de voto por adelantado, mientras que los operadores financiaban las antiguas tarifas de voto desde la cuenta de identidad a medida que se enviaban los votos. Un validador con suficiente SOL en total pero con una asignación incorrecta entre cuentas puede perder la admisión. Los informes de tiempo de actividad deberían distinguir ese problema de migración de una falla en el nuevo protocolo de votación. Son fallas operativas separadas con remedios diferentes.

La actualización resuelve un problema más acotado que las aplicaciones de pago

El argumento de Solana a favor de Alpenglow es poderoso: si la finalidad llega mucho antes, los servicios que necesitan liquidación irreversible pueden dejar de esperar varios segundos de incertidumbre. Las mediciones externas del 23 de octubre respaldan una mejora material en la mainnet aunque su mediana de 404 milisegundos fue más lenta que el objetivo de diseño. Los comerciantes y los exchanges pueden optar por confiar en ese estado más sólido y rápido.

Un servicio aún puede mantener un margen de seguridad. Podría usar varios proveedores de RPC, exigir un cribado antifraude o acreditar a un cliente solo después de que su propio libro contable concilie los depósitos. Un pago de bajo valor podría liberarse con un estado procesado, haciendo que Alpenglow sea casi invisible en su interfaz actual. Una transferencia grande podría usar el estado finalizado y ganar varios segundos. La actualización no hace irracional a un servicio cauteloso; le da al servicio una señal de red más rápida para incluir en su decisión.

El primer cambio medible puede ser la confiabilidad de la promesa detrás de una confirmación en lugar de una animación espectacular en una billetera. Los usuarios que ya veían una confirmación rápida no necesariamente sabían si era reversible. Los proveedores ahora pueden decidir si mostrar o exigir una finalidad más fuerte en esa misma ventana. Publicar el tiempo desde la aprobación del cliente hasta la aceptación del comerciante resolvería la afirmación de cara al usuario con más claridad que anunciar solo el número de consenso.

La segunda parte de Alpenglow, Rotor, todavía está planificada para una versión posterior sin fecha de activación. Votor cambió la votación y la finalidad; la distribución de bloques sigue usando el antiguo enfoque Turbine. El nombre del paquete puede dar la impresión de que todos los componentes propuestos llegaron juntos. La tabla de estado actual de la Fundación deja clara la separación. Cualquier ganancia de rendimiento atribuida a Rotor en los datos actuales de la mainnet tendría la cronología equivocada.

La distribución de bloques sigue siendo relevante cuando los datos viajan de manera desigual por la red. Una votación más rápida no puede ayudar a un validador a certificar una propuesta que no ha recibido. El componente Rotor planificado abordaría una etapa diferente de los certificados de Votor. Por ahora, las observaciones lentas pueden reflejar propagación, votación, entrega de RPC pública o varias a la vez. Registrar cada etapa le diría a un operador si su próxima mejora pertenece al software del validador, a la distribución de datos o a la infraestructura del cliente.

El lanzamiento inicial es una muestra breve de rendimiento. Las versiones de los clientes, el trabajo de migración de los proveedores y la asistencia de los validadores definen las condiciones actuales. Las versiones posteriores pueden cambiar la consistencia con la que los servicios externos se enteran de los certificados incluso sin otro cambio de consenso. Una semana móvil de observaciones en varios proveedores de RPC independientes, incluidos los períodos de máxima actividad, sería más valiosa para un comerciante que una sola demostración rápida.

Lo que queda por medir

No hay un único número de finalidad que capture la espera de cada usuario. Los certificados de los validadores, las observaciones de RPC públicas, el estado de la billetera y los tiempos de acreditación de los exchanges miden pasos diferentes. El panel de la Fundación proporciona lecturas de red en vivo, mientras que los monitores externos observan desde sus propios nodos. La concordancia entre métodos y proveedores durante varios días mostraría si los resultados rápidos se mantienen más allá de la semana de lanzamiento y con qué frecuencia aparece la cola lenta.

El registro de la mainnet ya es más sólido que una promesa de testnet. Alpenglow está activo, las transacciones de voto han abandonado los bloques y los desarrolladores han publicado los cambios de integración. Todavía es demasiado pronto para atribuir a la actualización de consenso más usuarios de aplicaciones, precios de tokens más altos o una mejora determinada en cada pago. Tales afirmaciones necesitan cohortes de transacciones, mediciones de servicio antes y después y datos comparables solo de usuarios.

Para una billetera o un proveedor de pagos, la siguiente decisión es concreta: utilizar la señal finalizada con prontitud, publicar cuando el usuario la vea y mantener las comprobaciones adicionales que su producto requiera. La cadena ha alterado un paso. La gente lo notará cuando el software que la rodea cambie el resto del recorrido.

Qué observar

• Finalidad observada: Compare las lecturas de la mediana móvil y del percentil más lento en el panel de la Fundación y en nodos independientes, con los puntos de observación indicados.
• Tiempos de billeteras y exchanges: Mida el intervalo desde la aprobación del cliente hasta la confirmación visible o el saldo acreditado, no solo el certificado del validador.
• Tráfico comparable: Realice un seguimiento de las transacciones de usuarios que no son votos antes y después del 21 de octubre para que las transacciones de voto eliminadas no distorsionen la tendencia.
• Errores de streaming: Compruebe si los proveedores de RPC e indexadores admiten la reconstrucción de bloques con conocimiento de bancos y un estado finalizado oportuno.
• Admisión de validadores: Vigile la financiación de cuentas de voto, los validadores activos y la diversidad de clientes admitidos, ya que la tarifa de 0,8 SOL se repite en cada época.

Preguntas frecuentes