El conteo de transacciones de Solana y, con él, su cifra principal de transacciones por segundo (TPS) cayó cuando la red activó Alpenglow el 21 de octubre. La documentación de actualización de la Solana Foundation llama a la caída "un cambio contable, no una regresión de rendimiento". Esa interpretación aún deja una pregunta para quien lea un gráfico de Solana: ¿disminuyó realmente la actividad o solo el conteo? La respuesta va más allá de un solo día de actualización, porque el TPS es una de las cifras de rendimiento más citadas en la cobertura de blockchain, y el conteo de Solana posterior al 21 de octubre se compila con una definición distinta a la de todos los números publicados antes.

Lo que Alpenglow eliminó de la lista de transacciones

Bajo TowerBFT, el sistema de consenso que Solana usó hasta el 21 de octubre, los validadores emitían sus votos como transacciones ordinarias. Los bloques llevaban cientos de ellas junto con pagos, intercambios y otro tráfico de aplicaciones, y cualquier conteo del total de transacciones incluía ese tráfico de votos. Como esos votos provenían de validadores y no de usuarios, parte de cada cifra de TPS previa a la actualización reflejaba la maquinaria de consenso de la red en lugar de la demanda de sus aplicaciones.

Alpenglow reemplaza ese mecanismo con Votor, un protocolo en el que los validadores intercambian votos directamente y los agrupan en certificados. Los certificados van en el pie de cada bloque y no en su lista de transacciones, por lo que un contador que suma transacciones deja de ver los votos desde el momento del cambio.

Lo que muestran los bloques de transición

Coindoo examinó los bloques a ambos lados del cambio mediante el RPC público de mainnet de Solana, la interfaz que exponen los nodos para leer datos de la cadena, usando su método getBlock. Cada bloque ocupa un slot, una ventana de aproximadamente 400 milisegundos. TowerBFT funcionó durante los primeros 5,000 slots de la época antes de que Alpenglow lo reemplazara.

El último bloque de TowerBFT llegó a las 13:54:00 UTC del 21 de octubre, y el primer bloque de Alpenglow siguió a las 13:54:03, sin que se produjeran bloques en los ocho slots intermedios. Aproximadamente tres de cada cinco transacciones en el último bloque de TowerBFT, 649 en total, eran votos de validadores; un bloque después, no había ninguna. Aun así, el bloque de Alpenglow fue el más grande de los dos. Un solo par de bloques no puede mostrar si la actividad de la red subió o bajó; muestra el mecanismo. Medir una tendencia requiere miles de bloques.

Los votos no son el único ruido en el conteo

Las fallas añaden una segunda capa. Leyendo el campo de error en los metadatos de cada transacción, Coindoo encontró que 844 de las 1,701 transacciones del primer bloque de Alpenglow sufrieron un error de ejecución, dejando 857 exitosas. Una transacción fallida igual paga una comisión y sigue en el bloque, pero no completó ningún pago ni intercambio. La interpretación del cambio contable cubre solo la capa de votos, así que incluso un conteo sin votos necesita un filtro por campo de error antes de describir trabajo que realmente se completó.

Las transacciones exitosas tampoco se corresponden con personas. Una cuenta de trading automatizado puede enviar transacciones en grandes cantidades, y una sola transacción puede contener varias instrucciones. Contar lo que las transacciones lograron realmente, como intercambios completados o transferencias de tokens, se acerca más al uso real que cualquier total bruto de transacciones.

Dónde viven los datos de comparación

El método getRecentPerformanceSamples de Solana informa, para cada muestra, el conteo total de transacciones, el conteo sin votos y la duración de la muestra en segundos. Dividir un conteo por la duración da una tasa promedio para esa ventana.

El método devuelve como máximo 720 muestras de alrededor de un minuto cada una, aproximadamente las últimas 12 horas. Una consulta hecha más de medio día después de la transición ya no llega hasta TowerBFT, por lo que el lado previo a la actualización de cualquier comparación debe provenir de muestras almacenadas antes o de bloques históricos.

Tres filtros, aplicados de forma idéntica antes y después del cambio, hacen significativa la comparación:

1. Eliminar los votos de validadores. Alpenglow lo hace en el lado nuevo; el lado antiguo requiere hacerlo a mano.
2. Eliminar las transacciones fallidas usando el campo de error de cada transacción. El conteo sin votos de la API todavía las incluye.
3. Comparar ventanas de tiempo iguales: promedios de un minuto contra promedios de un minuto, nunca un pico de un panel contra un total diario.

Las herramientas que leen votos necesitan reconfigurarse

Las transacciones de voto hacían más que inflar el TPS. Las herramientas de monitoreo leen instrucciones del programa Vote en la lista de transacciones para rastrear qué validadores participaban. Con Alpenglow esa entrada desaparece, y la Foundation dirige esas herramientas a los certificados de voto en los pies de bloque. Un rastreador que siga leyendo la fuente antigua mostraría validadores en silenc mientras siguen votando.

Para las cifras de uso de Solana, el número útil llegará cuando varios días de transacciones exitosas sin votos puedan compararse con datos almacenados previos a la actualización que cubran las mismas horas. Hasta entonces, cualquier gráfico principal de TPS que abarque el 21 de octubre mezcla el cambio contable con cambios reales en el uso.

Fuente: Coindoo