Las causas ocultas detrás de la lentitud de los validadores en Solana

A medida que los problemas de código de Solana se han ido resolviendo a lo largo de los años, los tiempos de bloque —es decir, el período que la red tarda en generar un nuevo bloque de transacciones— han disminuido, llegando incluso a situarse por debajo del supuesto umbral de 400 ms de Solana.

No obstante, en el último mes se ha detectado una tendencia significativa: la mediana de los tiempos de bloque se ha incrementado notablemente y Solana añade nuevas transacciones a la blockchain más despacio que antes. El origen está en una nueva dinámica entre los validadores de Solana, que ha puesto de manifiesto que producir bloques más lentos puede resultar rentable. Según ha podido saber Blockworks, Anza, Jito y Marinade están evaluando posibles soluciones a este problema.

En junio se disparó la duración de las epochs en Solana. Fuente: Kamino

Cada bloque de Solana cuenta con un validador líder, responsable de recopilar las transacciones, crear el bloque y difundirlo en la red. Los líderes reciben las comisiones de transacción de los bloques que generan. Un mayor flujo de órdenes implica más oportunidades de captación de comisiones, por lo que puede ser más rentable para los validadores gestionar y procesar transacciones durante 500 ms en lugar de 300 ms, por ejemplo.

En la práctica, algunos validadores de Solana parecen esperar al máximo posible para llenar los bloques de transacciones con el objetivo de maximizar sus ingresos, lo que ha provocado un aumento en la duración de las epochs de la red.

Esta situación no es adecuada para una red que aspira a ser tan rápida como el Nasdaq. Además, el hecho de que se generen menos epochs al año reduce las oportunidades de que las recompensas de staking se capitalicen para los usuarios, tal y como indicó Max Kaplan, CTO de Sol Strategies.

Solana incorpora un mecanismo denominado grace ticks, que es un periodo adicional en el que los líderes aún pueden presentar bloques con éxito tras el plazo previsto. Esto evita que los validadores ubicados en regiones remotas sean penalizados injustamente, pero también permite que algunos actúen con retrasos intencionados.

El cliente alternativo de Solana, Frankendancer, también ha lanzado recientemente un planificador orientado a maximizar ingresos, y según Kaplan, los validadores que operan con este cliente parecen agrupar las transacciones en bloques de forma algo más lenta de lo habitual.

Kaplan añadió que el retraso asociado a Frankendancer es mínimo frente a los validadores que incurren en demoras mucho más notables, y que no lo considera negativo. Además, la estrategia de retrasar bloques no es novedosa en blockchains de prueba de participación. No obstante, la actualización de Firedancer podría haber visibilizado estas prácticas en Solana. Jump no respondió inmediatamente a la solicitud de comentarios.

De hecho, Michael McGee, ingeniero de software de Firedancer, expuso este fenómeno en el último episodio del pódcast Lightspeed.

“Hemos observado que con nuestro validador actual... [los validadores] suelen poder generar un bloque más rentable retrasando la ejecución de las transacciones”, apuntó McGee.

Victor Pham, analista de Blockworks Research, señala que los validadores de Solana que incurren en retrasos más notorios suelen utilizar versiones modificadas del cliente Agave-Jito.

Por ejemplo, durante la epoch 802 a mediados de junio, Galaxy y Kiln registraron medianas de tiempo de bloque superiores a 570 ms cada uno. Varios validadores anónimos también mostraron lentitud y, según los datos de Solana Compass, los validadores de Temporal lograron una mediana de 475 ms.

Ernest Oppetit, cofundador de Kiln, admitió que su validador —el sexto mayor por stake de Solana— había estado retrasando slots “durante un tiempo”, pero aseguró que han cesado esa práctica.

“En Kiln nos distinguimos por ofrecer el mejor APY de staking del mercado sin sacrificar la seguridad. Hemos llevado a cabo I+D en distintas partes de la pila, incluyendo estrategias de temporización, y mantenemos diálogo constante con clientes, equipos de desarrollo y la fundación sobre ello. Actualmente cumplimos la especificación y ya no retrasamos bloques, aunque otros actores aún lo hacen. Creemos que el problema de incentivos (una producción rápida de bloques implica menores recompensas) debe resolverse a nivel de protocolo”, afirmó Oppetit.

“No somos la razón por la que se ha dado a conocer este asunto”, señaló Ben Coverston, director de ingeniería de Temporal, cuando fue consultado sobre la posible implicación de su validador en la tendencia de bloques lentos.

“Como proveedor de servicios, apoyamos configuraciones de validadores que priorizan la máxima rentabilidad por staking para nuestros clientes. En Solana, eso puede implicar proponer bloques algo más lentos para garantizar una mayor captación de recompensas. Galaxy también responde a los comentarios de la comunidad y, desde entonces, ha ajustado los tiempos de bloque dentro de un umbral aceptable”, comentó un portavoz de Galaxy.

La comunidad de validadores de Solana no aprueba la ralentización de la red y, actualmente, los validadores lentos reciben críticas públicas.

Pronto podrían enfrentarse a represalias más contundentes. Según ha podido saber Blockworks, Jito planea excluir de su staking pool —el mayor de Solana— a los validadores de bajo rendimiento.

Brian Smith, presidente de la Jito Foundation, ha indicado que la organización está “redactando una propuesta de gobernanza que permitirá a un comité retirar a los rezagados del conjunto de delegados de JitoSOL. Debería estar disponible para discusión comunitaria en los próximos días”.

Michael Repetny, cofundador del tercer mayor staking pool de Marinade, explica que el proveedor está “[valorando] someter a propuesta de gobernanza el debate sobre los pros y contras de introducir [la exclusión de validadores lentos] como norma estricta o infracción dentro de la estrategia de delegación”.

Asimismo, se están preparando soluciones a nivel de protocolo. El repositorio de GitHub de Anza recoge una propuesta para reducir a la mitad el periodo de grace tick en Solana. Además, la actualización del consenso propuesta para Solana apunta a resolver este problema.

“Alpenglow lo solucionará habilitando votos de omisión”, apuntó Brennan Watt, vicepresidente de ingeniería central de Anza.

Watt explicó en un episodio reciente de Lightspeed que Anza espera implementar Alpenglow en la red principal antes de la conferencia Breakpoint de Solana en diciembre.

Nota legal:

1. Este artículo se ha reproducido de [Blockworks]. Todos los derechos de autor pertenecen a su autor original [Jack Kubinec]. Si tiene alguna objeción a esta reproducción, contacte con el equipo de Gate Learn, que lo gestionará a la mayor brevedad.
2. Exención de responsabilidad: Las opiniones expresadas en este artículo son únicamente del autor y no constituyen asesoramiento de inversión.
3. Las traducciones de este artículo a otros idiomas han sido realizadas por el equipo de Gate Learn. Salvo que se indique expresamente, queda prohibida la copia, distribución o plagio de los artículos traducidos.