SLV publica una guía oficial con consideraciones críticas para operar validadores de Solana testnet que afectan directamente a la evaluación y la participación
ELSOUL LABO B.V. (sede: Ámsterdam, Países Bajos; CEO: Fumitake Kawasaki) y Validators DAO han publicado dentro de SLV, su plataforma de código abierto para operar nodos de Solana, una guía oficial que expone consideraciones críticas para operar validadores de Solana testnet.
La guía reúne las restricciones operativas y los aspectos que deben comprenderse de antemano cuando la operación en testnet se considera un requisito para la evaluación y la participación, incluida la participación en el Solana Foundation Delegation Program (SFDP) y el uso de BAM Testnet.
Testnet es un entorno en el que se aplican los requisitos previos de evaluación y participación
La testnet de Solana no es una simple red de verificación. En varios programas, incluido SFDP, operar un validador en testnet se considera un requisito previo para participar y ser evaluado.
No se evalúa únicamente que un nodo pueda arrancar, sino que mantenga configuraciones y comportamientos cercanos a la operación real y que no surjan incoherencias durante las actualizaciones o transiciones. Como solo cuentan los resultados observados, con independencia de la intención o el esfuerzo del operador, continuar con configuraciones o decisiones operativas incorrectas puede producir resultados desfavorables.
Requisitos fundamentales para operar validadores de testnet en SFDP
Los validadores que participan en SFDP deben mantener en testnet la misma clase de configuración de cliente que en mainnet. La evaluación no se limita a la disponibilidad funcional, sino que abarca un comportamiento y una estabilidad muy próximos a la operación real.
SLV admite configuraciones de testnet con Agave, Firedancer y BAM. Sin embargo, simplificar una configuración solo porque el entorno sea testnet o mezclar familias de clientes distintas puede afectar a los criterios de evaluación y participación. La guía expone de forma explícita estas consideraciones operativas.
No entender las restricciones específicas de testnet es un riesgo en sí mismo
Los entornos de testnet imponen restricciones que no existen en la red principal. Muchas de estas restricciones no están documentadas con claridad, y comenzar a operar sin comprenderlas puede provocar, de forma involuntaria, la exclusión de la evaluación o el incumplimiento de los requisitos de participación.
La clave es que la buena voluntad o el esfuerzo por sí solos no evitan estos resultados. Operar sin comprender las restricciones y decisiones propias de testnet constituye en sí mismo un riesgo que se refleja en la evaluación.
La realidad de las restricciones geográficas en BAM Testnet
Cuando se utiliza BAM Testnet, se aplican restricciones estrictas de latencia de red. En la actualidad, mantener una latencia de ping estable por debajo de 35 ms hasta los nodos BAM es efectivamente un requisito previo.
Las conexiones desde regiones que no cumplen este requisito a menudo no llegan a establecerse o no pueden mantenerse. Antes de utilizar BAM Testnet, los operadores deben comprobar de antemano la latencia desde la región prevista y no dar por hecho que el servicio será utilizable si no se reúnen las condiciones.
Estado del despliegue de nodos BAM Testnet (enero de 2026)
En enero de 2026, los nodos BAM Testnet disponibles públicamente están desplegados en tres regiones: Dallas, Nueva York y Salt Lake City. Por tanto, las opciones de despliegue realistas para BAM Testnet incluyen esas regiones u otras cercanas de Estados Unidos, como Chicago o Los Ángeles.
Aunque se prevé una expansión a EMEA y Asia, estas regiones no deben considerarse hoy una premisa operativa. La guía presenta estas restricciones como limitaciones temporales, no permanentes.
Por qué publicamos ahora una guía oficial sobre la operación de testnet
Con la transición de Solana hacia la serie v3 y la introducción de BAM, han cambiado las condiciones que rodean la operación de testnet. Configuraciones y elecciones de región que antes no planteaban problemas ahora influyen directamente en la evaluación y la participación.
En vez de depender de consultas individuales o de información compartida de forma fragmentaria, consideramos necesario publicar estas cuestiones para que los operadores entiendan los riesgos de antemano y eviten fallos innecesarios.
El alcance de lo que cubre SLV y qué deben decidir los operadores
SLV proporciona una base para reproducir configuraciones y procedimientos operativos al nivel del sistema operativo. Al mismo tiempo, el operador debe elegir la región de testnet y tomar las decisiones de configuración que dependan de restricciones externas.
La guía delimita con claridad el ámbito que gestiona SLV y las áreas en las que cada operador debe decidir ante restricciones específicas de testnet. Esta separación aclara responsabilidades y facilita decisiones operativas fundamentadas.
El valor del código abierto
La calidad operativa de la red de Solana no se sostiene únicamente con unos pocos nodos de alto rendimiento u operadores muy experimentados. En la práctica, la calidad de ejecución de la cadena surge del conjunto de estándares operativos que aplican a diario numerosos validadores y nodos RPC.
Cuando el conocimiento y las implementaciones operativas se mantienen en sistemas cerrados, la capacidad de operar con alta calidad tiende a concentrarse en un grupo reducido. Esto genera diferencias entre la configuración y el comportamiento de los nodos, que se manifiestan como inestabilidad en la votación o incoherencias de procesamiento. Son problemas estructurales, con independencia de la intención de cada operador.
SLV se publica como código abierto para que cualquiera pueda acceder a las mismas implementaciones y métodos operativos. Al hacer públicos y verificables tanto los detalles como el código, se evitan las cajas negras y los operadores pueden decidir a partir del comportamiento observado y de la implementación cuando surge un problema. Esta transparencia permite que la operación deje de depender de la intuición o de una persona concreta y hace posible una mejora práctica y continua.
Al mismo tiempo, las implementaciones abiertas evitan que las operaciones de alta calidad queden confinadas al conocimiento interno de unas pocas organizaciones y permiten que cualquiera adopte esos métodos. Así se reducen las variaciones en la configuración y el comportamiento de los nodos, y numerosos validadores y nodos RPC pueden operar con niveles de calidad estables.
Elegir el código abierto para SLV permite que la transparencia, la verificabilidad y la reproducibilidad funcionen en entornos operativos reales. Al permitir que cualquiera adopte estándares operativos de primer nivel, Solana puede elevar de forma continua la calidad operativa de toda la cadena.
Posicionamiento de esta guía
Esta guía funciona como lista de comprobación para evitar fallos al operar validadores de Solana testnet que podrían afectar a la evaluación y la participación. Comprender de antemano las restricciones y los puntos de decisión facilita evitar un deterioro innecesario de la evaluación, la pérdida de stake o la descalificación.
Esta guía forma parte de la documentación más reciente de SLV. Para participar en la comunidad de usuarios de SLV y consultar información relacionada, visite el Discord oficial de Validators DAO.
- Guía de notas operativas para validadores de Solana testnet: https://slv.dev/es/doc/testnet-validator/operational-notes/
- Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR
- Sitio web oficial de SLV: https://slv.dev/es
