Requisitos del validador de Solana: hardware y costes

Nota de revisión de la fuente: Las especificaciones de hardware, los costes de alojamiento, los criterios del SFDP y el staking APY cambian con el tiempo. Verifique todas las especificaciones actuales antes del aprovisionamiento.

Requisitos del validador de Solana: por qué son importantes

Los requisitos del validador de Solana abarcan la capacidad de hardware, los costes operativos, la financiación de cuentas, el software y la monitorización continua. Un validador de Solana (SOL) es un nodo de la red que vota sobre la validez de los bloques de transacciones, gana recompensas de la emisión inflacionista de SOL y de las comisiones de transacción, y constituye el núcleo del consenso descentralizado de la Mainnet-beta de Solana (la red de producción en vivo de Solana, donde la designación "beta" es un nombre heredado y no indica inestabilidad). Para una introducción más amplia, consulte qué es un validador de Solana. Los validadores también son la columna vertebral de la infraestructura del ecosistema DeFi de Solana: cuando los validadores rinden por debajo de lo esperado, cada aplicación de la red sufre las consecuencias.

En la estimación de la fuente, la Mainnet-beta de Solana tiene aproximadamente entre 1.500 y 1.800 validadores activos (Fuente: validators.app

Esta guía cubre las tres dimensiones que todo posible operador de validador necesita evaluar: especificaciones de hardware, economía (incluidas las comisiones de voto y el análisis del punto de equilibrio) y los criterios de elegibilidad del Programa de Delegación de la Fundación Solana (SFDP) que determina si la Fundación impulsará su participación.

A quién va dirigida esta guía. Esta guía está dirigida a ingenieros de DevOps, operadores de infraestructura y gestores de nodos experimentados que evalúan su participación como validadores de Solana. Si ya gestiona validadores en Ethereum, Cosmos u otras redes y está evaluando Solana, las secciones de hardware y economía contienen los datos específicos de Solana que necesita. Los usuarios de cripto principiantes deberían familiarizarse con el staking en Solana antes de evaluar la operación de un validador.

Contenidos:

1. Requisitos del validador de Solana: por qué son importantes
2. Cómo funcionan los validadores de Solana
3. Requisitos de hardware del validador de Solana
4. Software del validador: elección de su cliente
5. Requisitos de SOL: cuentas, participación y comisiones de voto
6. ¿Cuánto cuesta gestionar un validador de Solana?
7. Cómo funcionan las recompensas de los validadores de Solana
8. Programa de Delegación de la Fundación Solana (SFDP): cómo cumplir los criterios
9. Validador de Solana frente a validador de Ethereum: comparación de requisitos
10. Monitorización de su validador de Solana: herramientas y métricas de rendimiento
11. Cómo convertirse en validador de Solana: resumen de la configuración
12. Preguntas frecuentes sobre los requisitos del validador de Solana
13. ¿Es adecuado para usted gestionar un validador de Solana? Un marco de decisión

Cómo funcionan los validadores de Solana

Solana es una blockchain de Prueba de Participación (Proof of Stake), lo que significa que los validadores participan en staking con SOL como garantía económica para participar en la validación de bloques y ganar recompensas proporcionales a su participación delegada. Solana amplía el Proof of Stake (PoS) estándar con dos innovaciones arquitectónicas que son el origen directo de sus elevadas demandas de hardware: Prueba de Historia (Proof of History) y Tower BFT.

Prueba de Historia: El reloj criptográfico de Solana

Proof of History (PoH) es el reloj criptográfico de Solana. Genera una secuencia de hashes SHA-256 actualizada continuamente que marca el tiempo de cada evento en la red. Los validadores deben procesar y verificar esta secuencia de PoH en tiempo real. No pueden agrupar ni aplazar este trabajo. Ese cálculo continuo de SHA-256 es la razón principal por la que Solana requiere un alto rendimiento de CPU de un solo núcleo y un almacenamiento NVMe (memoria no volátil Express) rápido que otros validadores de Capa 1 pueden operar sin ellos. PoH no es un mecanismo de consenso independiente; es una función de retardo verificable que proporciona la línea de tiempo compartida que Tower BFT utiliza para votar.

Tower BFT y transacciones de voto

Tower BFT es el algoritmo de consenso de Solana, concretamente una versión modificada de la Tolerancia Práctica a Faltas Bizantinas (PBFT) que utiliza la línea de tiempo de PoH como un reloj compartido para emitir votos. A diferencia de la PBFT estándar o Tendermint BFT (utilizada por Cosmos), el mecanismo de bloqueo optimista de Tower BFT reduce la sobrecarga de mensajería, permitiendo el alto rendimiento de validadores de Solana. Cada voto que emite un validador es una transacción enviada On-Chain. Esas transacciones de voto suman aproximadamente 1 SOL al día en comisiones en la Mainnet-beta. Ese coste continuo es un gasto operativo fijo independientemente de cuánta participación delegada posea.

Épocas y tiempos de recompensa

Una época es el periodo contable fundamental de Solana: aproximadamente 2 días (432.000 slots a unos 400 ms por slot). En cada límite de época, se distribuyen las recompensas de los validadores, la nueva participación delegada se activa y se publica el calendario de líderes para la siguiente época. Esto conlleva dos implicaciones prácticas: primero, planifique su flujo de efectivo en un ciclo de recompensas de aproximadamente 2 días; segundo, la nueva participación delegada tarda una época completa en activarse y comenzar a generar recompensas, por lo que los nuevos validadores se enfrentan a un periodo de retraso antes de alcanzar la elegibilidad total para las recompensas.

Requisitos de hardware del validador de Solana

Los validadores de Solana requieren un hardware significativamente más potente que la mayoría de las otras redes de Capa 1 porque el procesamiento de Prueba de Historia exige un cálculo continuo de SHA-256 de alto rendimiento, y los validadores deben reproducir el libro mayor completo en tiempo real a la cadencia de slots de 400 ms de Solana.

La siguiente tabla refleja las especificaciones obtenidas de la documentación de configuración del validador de Solana

Requisitos de hardware del validador de Solana. Nota de revisión de la fuente: Fuente: docs.solanalabs.com/operations/setup-a-validator. Verifique los requisitos actuales antes del aprovisionamiento. Los mínimos de hardware de Solana han aumentado con el tiempo a medida que crece el estado de la red.

Advertencia: Los SSD SATA son motivo de descalificación. Los SSD SATA estándar no pueden cumplir con los requisitos de rendimiento de E/S de la base de datos de cuentas y el ledger de Solana. Solo las unidades NVMe PCIe Gen3 cumplen con el mínimo; PCIe Gen4 NVMe es el estándar de producción. Un validador que utilice almacenamiento SATA perderá votos y acumulará una tasa de omisión (skip rate) elevada.

Selección de CPU

Una velocidad de reloj de núcleo único elevada impulsa el rendimiento de Proof of History más que el número de núcleos. La secuencia de hash SHA-256 que sustenta PoH es de un solo hilo en su ruta crítica. Un servidor de 24 núcleos que funcione a 3,5 GHz supera a un servidor de 48 núcleos que funcione a 2,0 GHz para el procesamiento de PoH. Las plataformas AMD EPYC serie 7003 (Milan) e Intel Xeon Ice Lake o Sapphire Rapids alcanzan el perfil de rendimiento requerido. Deben evitarse las CPU virtuales en la nube: las vCPU de núcleos compartidos introducen variabilidad en el reloj que provoca retrasos en el procesamiento de PoH y pérdida de votos.

La RAM y la base de datos de cuentas

128 GB de RAM son suficientes para sobrevivir, pero tienen un coste. Los validadores que funcionan al mínimo desbordan la caché hacia la unidad NVMe de cuentas durante los periodos de gran volumen, y ese exceso de E/S se manifiesta como una tasa de omisión creciente. Con 256 GB, la base de datos de cuentas cabe sustancialmente en la memoria. Se requiere RAM ECC (Error-Correcting Code) porque los errores de memoria en un entorno de validador activo causan una corrupción de estado silenciosa que degrada la participación en el consenso.

Arquitectura de almacenamiento NVMe

La configuración recomendada utiliza dos unidades NVMe independientes: una para el SO y los datos del ledger, y otra dedicada a la base de datos de cuentas. Esta separación evita que las escrituras del ledger compitan con las lecturas de la base de datos de cuentas durante los periodos de alta carga. PCIe Gen3 es el mínimo; PCIe Gen4 duplica el ancho de banda disponible y es el estándar de producción. Dos unidades también proporcionan una ruta de configuración para redundancia basada en RAID o snapshots.

Conectividad de red

Una conexión simétrica de 1 Gbps es el mínimo funcional, pero los validadores de la Mainnet de producción suelen necesitar 10 Gbps durante los periodos de mucho tráfico. La ubicación geográfica en relación con los validadores con alta participación en staking es importante: una menor latencia de red hacia la supermayoría del clúster reduce los retrasos en la propagación de votos y mejora su tasa de participación en las votaciones. Las conexiones a internet residenciales carecen de la consistencia de subida que requiere la cadencia de emisión de votos de Solana.

Servidores dedicados (Bare Metal) frente a la nube para validadores de Solana

El alojamiento en servidores dedicados (bare-metal) es el estándar de producción para los validadores de la Mainnet de Solana. Los servidores dedicados proporcionan IOPS de NVMe constantes sin la contienda del hipervisor, núcleos de CPU dedicados sin efectos de "vecino ruidoso" en el hashing PoH de SHA-256 y ancho de banda de red dedicado sin las limitaciones de la tenencia compartida. Las instancias de VPS en la nube que ejecutan almacenamiento virtualizado causan cuellos de botella en la E/S de la base de datos de cuentas que se traducen directamente en votos perdidos y un deterioro de la tasa de omisión.

Si está probando la configuración en testnet o devnet, un VPS en la nube es un entorno aceptable y rentable. Para la producción en mainnet-beta, los servidores dedicados bare-metal son la elección de infraestructura correcta.

Software del validador: elección del cliente

Solana admite tres implementaciones de clientes de validador relevantes para la producción, y la que elija afectará tanto a sus ingresos potenciales como a su complejidad operativa desde el primer día. La arquitectura multicliente de Solana es una decisión deliberada para la salud de la red: distribuir el software del validador a través de implementaciones independientes reduce el riesgo de que un error en un solo cliente afecte a toda la red.

Agave (anteriormente el cliente validador de Solana Labs)

El cliente Agave (anteriormente el cliente validador de Solana Labs) es la implementación de referencia para los validadores de Solana, mantenida por Anza, una escisión de ingeniería de Solana Labs. Escrito en Rust, Agave es el cliente más probado en batalla y mejor documentado de la red. Los nuevos validadores deberían empezar con Agave: cuenta con el mayor apoyo de la comunidad y el comportamiento más predecible bajo presión. Las instrucciones de instalación y los indicadores de configuración de inicio se encuentran en el repositorio de GitHub del cliente Agave

Jito-Solana: Acceso a ingresos por propinas MEV

El cliente Jito-Solana es un fork de Agave que integra la infraestructura de validador de Jito

Firedancer: Cliente independiente de alto rendimiento

Firedancer es un cliente validador independiente de Solana desarrollado por Jump Crypto (la división cripto de Jump Trading), escrito en C/C++ para obtener el máximo rendimiento. Está diseñado para aumentar la capacidad de rendimiento general de la red de Solana y mejorar la diversidad de clientes. En la estimación original, Firedancer está disponible en una capacidad de producción limitada. Consulte el estado actual del despliegue en el repositorio de GitHub de Firedancer

Requisitos del SO: Los validadores de Solana se ejecutan en Linux. Ubuntu 22.04 LTS es el sistema operativo recomendado. El ajuste necesario del kernel incluye la modificación del tamaño de los búferes de red y la configuración del regulador de la CPU. La documentación oficial especifica los parámetros exactos.

Se requieren conocimientos de Linux. Ejecutar un validador de Solana requiere sentirse cómodo con el acceso SSH, la gestión de servicios systemd, la configuración de cortafuegos UFW o iptables y la supervisión de registros. Si aún no tiene este nivel, testnet es el entorno de inicio correcto. Allí podrá familiarizarse con las operaciones sin riesgo financiero.

Requisitos de SOL: cuentas, participación en staking y comisiones por voto

Solana no impone un mínimo de SOL para participar en staking a nivel de protocolo para ejecutar un validador, pero las comisiones de las transacciones de voto y los costes del servidor crean un mínimo económico práctico: su participación en staking delegada debe generar suficientes ingresos por comisiones para cubrir sus gastos operativos mensuales.

¿Cuántos SOL se necesitan para ejecutar un validador de Solana?

No existe un mínimo de SOL para participar en staking impuesto por el protocolo. Cualquier validador puede participar en el consenso con una pequeña participación en staking propia. El mínimo práctico viene determinado por el cálculo del umbral de rentabilidad: su participación en staking delegada debe generar ingresos por comisiones suficientes para cubrir los costes mensuales del servidor más aproximadamente 30 SOL al mes en comisiones por transacciones de voto. Para la mayoría de los operadores, esto significa atraer entre 50.000 y más de 100.000 SOL en participación en staking delegada antes de alcanzar la rentabilidad, o cumplir los requisitos para el Programa de Delegación de la Fundación Solana (SFDP) para impulsar la participación en staking en el ínterin.

La cuenta de voto y la cuenta de identidad

Cada validador de Solana mantiene dos cuentas On-Chain distintas con un Balance de SOL independiente.

Cuenta de identidad: El par de claves de autenticación del validador, que firma los votos e identifica el nodo validador en la red. Este par de claves reside en el servidor porque es necesario para la firma activa. Los requisitos de financiación son mínimos; necesita suficientes SOL para pagar transacciones ocasionales.

Cuenta de voto: Una cuenta On-Chain especial utilizada para registrar los votos del validador en cada época. La cuenta de voto requiere un Balance de SOL exento de alquiler de aproximadamente 0,02685 SOL para permanecer activa (verifique la cifra actual en los comandos de creación de cuentas de voto

Crítico: Financia tu cuenta de votación antes de entrar en funcionamiento. Las comisiones de voto rondan 1 SOL al día en Mainnet-beta, independientemente del Stake que poseas. Si la cuenta de votación se queda sin SOL, tu validador dejará de votar y pasará a ser moroso (un validador que ha dejado de participar en el consenso, lo que resulta en la pérdida de recompensas y en una reducción de la puntuación de rendimiento). Financia 30 días de comisiones antes del lanzamiento y, a continuación, supervisa el Balance diariamente. Los operadores que necesiten SOL para este margen pueden utilizar Spot Bybit SOL/USDT, donde esté disponible, antes de transferirlo cuidadosamente a la dirección correcta de Solana.

Stake delegado y elegibilidad para recompensas

Los titulares de SOL crean cuentas de Stake y las delegan en el validador que prefieran. Tu Stake delegado total determina tu parte proporcional de las recompensas por inflación del epoch y tu número de turnos de líder asignados. Al evaluar un validador, los delegadores suelen fijarse en el tipo de comisión, la tasa de omisión y la puntuación de rendimiento del SFDP de forma conjunta. Entender cómo funcionan el Staking y la delegación de SOL es fundamental para modelar los ingresos de los validadores: los delegadores evalúan si tu validador tendrá un buen rendimiento y protegerá sus recompensas, por lo que la relación entre la calidad de tu hardware y tu Stake delegado es directa. El nuevo Stake delegado tarda un epoch completo (aproximadamente 2 días) en activarse y empezar a generar recompensas.

El mínimo económico: ¿Qué Stake necesitas realmente?

El cálculo de rentabilidad de la siguiente sección proporciona la fórmula exacta. Con un APY de Staking anual del 7 % y un tipo de comisión del 10 %, un validador necesita aproximadamente entre 50.000 y 100.000 SOL en Stake delegado para generar unos ingresos por comisiones que superen los costes típicos de servidor y comisiones de voto. Por debajo de ese umbral, los validadores suelen operar con pérdidas. La sección del SFDP explica cómo la Fundación salva esa diferencia para los operadores que cumplen los requisitos.

¿Cuánto cuesta gestionar un validador de Solana?

Gestionar un validador de Solana en Mainnet-beta implica dos categorías de costes distintas: un gasto mensual fijo de servidor para hardware bare-metal y un coste variable continuo en forma de comisiones por transacciones de voto denominadas en SOL.

Desglose de los costes mensuales de explotación

Todos los precios son aproximados en la estimación de origen. Verifique los precios actuales directamente con cada proveedor antes de comprometerse. Para la mayoría de los operadores, el hardware bare-metal de Latitude.sh o OVHcloud en el rango de 150 a 500 dólares al mes es el punto de partida práctico para una configuración con capacidad para Mainnet.

Nota sobre la política de Hetzner. En la estimación de origen, Hetzner ha restringido las cargas de trabajo de los validadores de Solana en partes de su infraestructura. Verifica la política actual directamente con Hetzner antes de aprovisionar un servidor para su uso como validador en Mainnet-beta.

¿Es rentable gestionar un validador de Solana?

La rentabilidad aumenta con el Stake delegado. Un validador con 20.000 SOL delegados pierde dinero en la mayoría de los niveles de precio de SOL. Un validador con 150.000 SOL delegados alcanza la rentabilidad en condiciones típicas de APY y comisiones. La siguiente fórmula muestra la relación con precisión.

La fórmula de rentabilidad

Beneficio mensual neto = (SOL delegado x APY anual / 12 x Tipo de comisión) - Coste mensual del servidor - (Comisiones de voto por día x 30)

Ejemplo práctico (ilustrativo; verifique todos los datos con cifras actuales):

• SOL delegado: 100.000 SOL
• APY anual: aproximadamente 6,5 % (en la estimación de origen, fuente: validators.app; verifique la tasa actual)
• Tipo de comisión: 10 %
• Coste mensual del servidor: $350
• Comisiones de voto: aproximadamente 1 SOL/día x 30 días = 30 SOL/mes

Ingresos mensuales por comisiones: 100.000 x 0,065 / 12 x 0,10 = aproximadamente 54 SOL/mes

Coste total mensual: $350 de servidor + (30 SOL x precio actual de SOL)

Con SOL = $150: el coste mensual total es de aproximadamente $350 + $4.500 = $4.850. Ingresos mensuales por comisiones de 54 SOL x $150 = $8.100. Neto: aproximadamente +$3.250/mes.

Nota: Las estimaciones de costes, las proyecciones de rentabilidad y los cálculos de ganancias anteriores son ejemplos ilustrativos basados en variables (precio de SOL, APY de Staking, costes de servidor) que cambian con el tiempo. No constituyen asesoramiento financiero, recomendaciones de inversión ni garantías de rendimientos futuros. Verifique todas las cifras con los datos actuales del mercado antes de tomar decisiones financieras.

Distribución geográfica y puntuación SFDP

La ubicación del centro de datos afecta a la elegibilidad para el SFDP. La puntuación de la Fundación Solana penaliza a los validadores concentrados en regiones de centros de datos ya saturadas, en particular Ashburn, VA, que alberga una parte desproporcionada de validadores de Solana. El alojamiento en los principales proveedores de nube (AWS, GCP, Azure) recibe puntuaciones de descentralización más bajas. El alojamiento bare-metal en regiones geográficas poco representadas obtiene mejores puntuaciones en cuanto a diversidad de centros de datos.

Cómo funcionan las recompensas de los validadores de Solana

Las recompensas de los validadores de Solana proceden de dos fuentes: la emisión de SOL Inflacionista distribuida proporcionalmente a la cuota de cada validador sobre el Stake total activo en cada epoch, y los ingresos por comisiones de transacción de los bloques que el validador produce durante sus turnos de líder asignados. Los validadores que ejecutan el cliente Jito-Solana obtienen acceso a una tercera vía de ingresos: las distribuciones de propinas MEV del motor de bloques de Jito.

Recompensas inflacionistas y la fórmula de recompensa

La fórmula básica de recompensa:

Recompensa bruta del validador por epoch = (Stake delegado total del validador / Stake activo total en la red) x Fondo de recompensa por inflación del epoch

El calendario de inflación de Solana comenzó con una emisión anual del 8 % y disminuye un 15 % anual, con un suelo a Largo plazo del 1,5 %. El APY de Staking anual actual refleja la posición de la red en ese calendario (verifique el APY actual en validators.app antes de realizar el modelado).

En cada epoch, Solana publica un calendario de líderes: una rotación predeterminada que asigna a cada validador turnos específicos durante los cuales es responsable de producir bloques. Un mayor Stake delegado significa más turnos de líder, lo que se traduce en más recompensas por producción de bloques además de la recompensa por inflación base.

Ejemplo práctico (ilustrativo): Un validador que posee el 1 % del Stake activo total con una comisión del 10 %, a un APY anual del 6,5 %, gana aproximadamente 1 % x (SOL totales en Staking x 0,065 / 365 x 2 días por epoch) x 10 % de comisión por epoch. Utiliza las cifras actuales de validators.app para calcular tu caso concreto.

Tipo de comisión: lo que conservas frente a lo que transfieres

Tu tipo de comisión es el porcentaje de recompensas de Staking que conservas de las ganancias de tus delegadores. No es una comisión que se cobre por las transacciones. Con un tipo de comisión del 10 %, tú conservas el 10 % de todas las recompensas de los epoch obtenidas por el Stake de tus delegadores, y el 90 % restante va directamente a los delegadores. Establecer una comisión demasiado alta desincentiva a los delegadores a elegir tu validador; establecerla demasiado baja podría no cubrir los costes de explotación.

El rango típico del mercado para los validadores competitivos en la Mainnet-beta de Solana oscila entre el 0% y el 10%. Establecer una comisión del 100% descalifica a su validador para el Programa de Delegación de la Fundación Solana (SFDP). La sección del SFDP a continuación cubre el límite máximo de comisión y cómo interactúa con la puntuación de elegibilidad.

Retraso en la activación del Stake y tiempos de las recompensas

El Stake recién delegado tarda una época completa (aproximadamente 2 días) en activarse tras la delegación. Las recompensas se abonan al final de cada época. Los nuevos validadores deben presupuestar un mínimo de dos épocas completas después del lanzamiento antes de esperar ingresos íntegros por recompensas: una época para la verificación del hardware y la configuración en testnet, y una época para la activación del stake en Mainnet-beta.

El Programa de Delegación de la Fundación Solana (SFDP): Cómo calificar

Sin un stake externo inicial, un nuevo validador de Solana con una delegación orgánica mínima operará con pérdidas durante sus primeros meses en la Mainnet-beta. El Programa de Delegación de la Fundación Solana (SFDP) existe para cerrar esa brecha. La Fundación Solana (la organización sin fines de lucro que apoya el desarrollo y la descentralización de Solana) delega SOL de su tesorería a los validadores de la Mainnet-beta que califiquen, proporcionando un stake inicial para ayudar a los nuevos operadores a alcanzar la viabilidad económica antes de atraer delegadores orgánicos.

¿Qué es el Programa de Delegación de la Fundación Solana?

El SFDP es el programa de la Fundación Solana a través del cual la Fundación delega SOL de su tesorería a validadores cualificados de la Mainnet-beta. Proporciona un stake inicial para ayudar a los nuevos validadores a alcanzar la viabilidad económica antes de atraer delegadores orgánicos. La elegibilidad requiere cumplir con criterios de rendimiento, tasa de comisión y diversidad de centros de datos verificados por la Fundación. El SFDP no es automático. Los validadores deben solicitarlo y mantener la elegibilidad continua para conservar la delegación.

El SFDP cubre el vacío económico entre el lanzamiento y el umbral mínimo de stake delegado para la rentabilidad. Un validador que califica para el SFDP recibe una delegación de la Fundación que genera ingresos por comisiones, reduciendo el tiempo necesario para alcanzar la sostenibilidad operativa.

Requisitos de elegibilidad del SFDP

Los siguientes criterios reflejan los requisitos del programa documentados en solana.org/validators. Verifique cada punto en la página actual del programa antes de realizar la solicitud. La Fundación actualiza estos criterios periódicamente.

• El validador debe estar activo en Mainnet-beta (no en testnet ni devnet)
• Tasa de comisión igual o inferior al límite actual del SFDP (verifique el umbral actual preciso en solana.org/validators; una comisión del 100% es un motivo definitivo de descalificación, y las tasas por encima de las normas de la comunidad afectan a la puntuación)
• Tasa mínima de participación en la votación mantenida por encima del umbral del programa (confirme el umbral actual en la documentación oficial)
• Tasa de omisión (el porcentaje de ranuras de líder asignadas que un validador pierde) por debajo del umbral del programa
• Proveedor de centro de datos que no figure en la lista de sobreconcentración (la concentración en AWS, GCP y Azure penaliza la puntuación)
• Identidad del validador activa y cuenta de voto financiada sin historial reciente de morosidad
• Puntuación de rendimiento que cumpla con los umbrales de la Fundación basados en la calidad de producción de bloques y el tiempo de actividad

Los criterios de elegibilidad del Programa de Delegación de la Fundación Solana y los importes de delegación son determinados por la Fundación Solana a su discreción y pueden cambiar. El cumplimiento de los criterios anteriores no garantiza la delegación del SFDP. Verifique siempre los requisitos actuales del programa directamente en solana.org/validators

¿Cuánto Stake proporciona el SFDP?

El SFDP asigna SOL en niveles basados en las puntuaciones de rendimiento del validador. Los validadores más nuevos sin historial de rendimiento suelen recibir asignaciones iniciales más bajas. A medida que su validador demuestre un tiempo de actividad constante, una tasa de omisión baja y una sólida participación en las votaciones, la asignación puede aumentar. La estructura del programa está sujeta a revisión por parte de la Fundación. Consulte la página oficial del SFDP para conocer las estructuras de niveles y los importes actuales.

1. Confirme que su validador de Mainnet-beta está activo y cumple con los umbrales de rendimiento (compruebe su tasa de omisión y su tasa de participación en las votaciones a través de validators.app
2. Complete el formulario de solicitud en el sitio web de la Fundación Solana en la solicitud del Programa de Delegación de la Fundación Solana
3. Supervise su puntuación de rendimiento a través de validators.app tras la solicitud; la Fundación evalúa los datos de rendimiento On-Chain como parte de su proceso de revisión.

La puntuación del SFDP premia la diversidad geográfica y de proveedores. Los validadores alojados en servidores bare-metal en regiones poco representadas obtienen mejor puntuación que aquellos concentrados en la infraestructura de los principales proveedores de la nube. Si su huella de centro de datos se inclina hacia AWS us-east-1 o zonas de la nube equivalentes, es posible que deba realizar el aprovisionamiento en regiones alternativas o con proveedores alternativos para calificar o maximizar la asignación del SFDP. Esta consideración es particularmente relevante para los operadores institucionales que evalúan despliegues de múltiples validadores.

La delegación del SFDP no es permanente. La Fundación Solana ajusta activamente las asignaciones de delegación basándose en el rendimiento continuo del validador. Los validadores que caigan por debajo de los umbrales de rendimiento debido a la degradación del hardware, una mala configuración o una monitorización descuidada pueden perder el stake del SFDP rápidamente. Construya la economía de su validador a largo plazo en torno al stake delegado orgánico, no al SFDP como una fuente de ingresos permanente.

Validador de Solana frente a validador de Ethereum: Comparación de requisitos

Los operadores que han gestionado validadores de Ethereum a menudo subestiman las demandas de hardware de Solana porque las dos redes imponen cargas computacionales categóricamente diferentes a sus validadores.

Por qué Solana requiere más hardware

Los validadores de Solana deben procesar pruebas de PoH de forma continua, reproducir todo el libro mayor en tiempo real con un rendimiento de más de 50.000 TPS y votar sobre los bloques con una latencia inferior al segundo. Los validadores de Ethereum, por el contrario, atestiguan épocas que duran aproximadamente 6,4 minutos por ciclo y no reproducen un libro mayor de alto rendimiento localmente en tiempo real. La arquitectura de Solana sacrifica requisitos de hardware por rendimiento de transacciones. La arquitectura de Ethereum prioriza barreras de hardware más bajas a cambio de un rendimiento nativo menor.

El mínimo de 32 ETH de Ethereum es una regla estricta del protocolo: no se puede activar un validador de Ethereum sin exactamente 32 ETH en staking. Solana no tiene una restricción de protocolo equivalente. Cualquier validador de Solana puede empezar a votar con un stake mínimo. La barrera es económica: por debajo del umbral de rentabilidad de stake delegado (cubierto en la sección de costes), los costes mensuales del servidor y de las tarifas de voto superan los ingresos por comisiones, produciendo una pérdida neta mensual. Estos son diferentes tipos de barreras de entrada. La de Ethereum es un requisito de inmovilización de capital; la de Solana es un requisito de costes operativos continuos.

Monitorización de su validador de Solana: herramientas y métricas de rendimiento

Las métricas de rendimiento del validador determinan tu puntuación de elegibilidad para el SFDP, tu tasa de omisión y cuánta participación delegada retienes. La monitorización es una función económica directa, no un aspecto operativo secundario.

Herramientas de monitorización utilizadas por los operadores de validadores de Solana:

• validators.app

• Explorador de validadores Solana Beach

• explorer.solana.com: Explorador de bloques oficial de Solana. Utilízalo para la búsqueda de validadores a nivel de bloque por clave pública de identidad, verificación de transacciones e inspección de cuentas On-Chain.

• Grafana + Prometheus (autohospedado): El conjunto de herramientas recomendado para la monitorización de infraestructura en tiempo real. Rastrea la utilización de la CPU, el consumo de RAM, los IOPS de NVMe y el rendimiento de la red a nivel de hardware. Solana Labs publica un JSON de tablero de Grafana de referencia en la documentación oficial.

Métricas clave de rendimiento a vigilar

• Tasa de omisión (Skip rate): El porcentaje de espacios de líder asignados que un validador pierde. El objetivo debe estar muy por debajo del 10%; el SFDP suele requerir un umbral más bajo. Una tasa de omisión creciente es el indicador más temprano de una provisión insuficiente de hardware o problemas de conectividad de red.
• Tasa de participación en votos: El porcentaje de espacios para los que envías un voto con éxito. El objetivo debe ser superior al 95%.
• Balance de SOL de la cuenta de voto: Nunca permitas que este baje de una reserva de comisiones de voto para 1 semana. Monitoriza a diario.
• Estado de sincronización del Ledger (catchup): Después de cualquier reinicio, confirma que tu validador ha vuelto al extremo de la cadena antes de esperar la participación en votos.
• Utilización de IOPS de NVMe: Los cuellos de botella de almacenamiento aparecen como un aumento de la tasa de omisión bajo un alto volumen de transacciones. Monitoriza los tiempos de espera de E/S en ambas unidades NVMe.

Configura Alertas. Configura PagerDuty, OpsGenie o alertas equivalentes sobre el Balance de SOL de tu cuenta de voto. Establece el umbral de alerta en 7 días restantes de comisiones de voto. Una cuenta de voto con fondos insuficientes entra en estado de delincuencia sin ninguna advertencia On-Chain. Para cuando los delegadores noten tu degradación del rendimiento, ya habrás perdido participación en staking.

Cómo convertirse en validador de Solana: Resumen de la configuración

Esta sección traza los diez pasos secuenciales desde la provisión de hardware hasta la solicitud del SFDP. Las instrucciones de configuración comando por comando listas para producción, los indicadores exactos de la CLI y las plantillas de archivos de configuración se encuentran en la documentación de configuración del validador de Solana)

1. Hardware provisionado y verificado. Adquiere un servidor bare-metal que cumpla con las especificaciones de la sección de Requisitos de Hardware. Confirma la configuración de la unidad NVMe, la capacidad de la RAM y la conectividad de red antes de continuar.

2. Ubuntu 22.04 LTS instalado y con el kernel optimizado. Instala el sistema operativo. Aplica la configuración del tamaño del búfer de red y del regulador de la CPU especificados en la documentación de Solana. Estos parámetros del kernel no son opcionales; omitirlos provoca una degradación del rendimiento bajo una carga sostenida.

3. Herramientas de CLI de Solana instaladas y configuradas para testnet. Instala el conjunto de herramientas de CLI de Solana. Configura el clúster de destino a testnet (no a mainnet-beta) para todo el trabajo de configuración inicial. Testnet utiliza SOL sin valor, lo que permite realizar pruebas sin exposición financiera.

4. Par de claves de identidad y de cuenta de voto generados; autoridad de retiro asegurada. Genera tu par de claves de identidad del validador y tu par de claves de cuenta de voto utilizando la CLI de Solana. Asigna la autoridad de retiro a un par de claves en almacenamiento en frío (una billetera de hardware o una máquina aislada). Estas son cuentas separadas (consulta la nota de seguridad más abajo).

5. Cuenta de voto financiada con al menos 30 días de comisiones de voto. Financia la cuenta de voto con aproximadamente 0,02685 SOL para el Balance exento de alquiler, más un mínimo de 30 SOL como reserva para comisiones de voto antes de entrar en funcionamiento. Este es el paso que más se suele omitir y el que tiene las consecuencias más graves.

6. Proceso del validador Agave (o Jito-Solana) configurado e iniciado. Configura tu script de inicio del validador utilizando los indicadores de la documentación oficial. Inicia el cliente Agave (anteriormente el cliente validador de Solana Labs) como base recomendada. Jito-Solana es una opción después de haber logrado operaciones estables.

7. Sincronización del Ledger (catchup) monitorizada y confirmada. Ejecuta el comando de sincronización mencionado en la documentación oficial para monitorizar el progreso de tu validador al reproducir el ledger. No esperes participar en la votación hasta que el validador alcance el extremo actual de la cadena.

8. Estabilidad de testnet verificada durante al menos un epoch completo. Ejecuta tu validador en testnet durante un mínimo de un epoch completo (aproximadamente 2 días) antes de migrar a mainnet-beta. Confirma que la tasa de omisión, la tasa de participación en votos y las métricas de hardware se encuentren dentro de rangos aceptables.

9. Configuración migrada a mainnet-beta; cuenta de voto financiada. Cambia la configuración de tu clúster a mainnet-beta (la red de producción en vivo de Solana). Financia tu cuenta de voto de Mainnet. Registra tu validador en validators.app para que tu rendimiento sea visible para los delegadores.

10. Solicitud de SFDP enviada y estrategia de tasa de comisión establecida. Revisa los requisitos de elegibilidad del SFDP y solicita tu participación si cumples los criterios. Establece tu tasa de comisión, equilibrando las limitaciones de los topes del SFDP con el posicionamiento competitivo frente a los delegadores orgánicos.

Primero en Testnet: Por qué es importante la red de pruebas

El clúster de testnet de Solana refleja operativamente a mainnet-beta, pero utiliza SOL sin valor monetario, disponible en el grifo (faucet) de testnet. Los errores de configuración en testnet no cuestan nada. Los mismos errores en mainnet-beta cuestan SOL real en comisiones de voto mientras tu validador rinde por debajo de lo esperado y pierde participaciones en staking delegadas. La Solana Foundation recomienda al menos un epoch completo de funcionamiento estable en testnet antes del despliegue en Mainnet. Testnet es independiente de devnet: devnet es un entorno de desarrollo para pruebas de aplicaciones y no es un entorno de práctica adecuado para validadores.

Tu par de claves de identidad puede y debe residir en el servidor: firma cada transacción de voto que el validador emite, por lo que necesita ser accesible para el proceso del validador en ejecución. Tu par de claves de autoridad de retiro nunca debe estar en el servidor. La autoridad de retiro controla los retiros de fondos de tu cuenta de voto. Si un atacante la obtiene, puede vaciar todo el SOL de la cuenta de voto y tus fondos en staking. Utiliza una billetera de hardware (Ledger, Trezor) o una máquina aislada como autoridad de retiro. Esta separación de claves es la práctica de seguridad más importante para los validadores de Solana.

Preguntas frecuentes sobre los requisitos del validador de Solana

Estas preguntas representan las búsquedas más frecuentes de los posibles operadores de validadores de Solana. Cada respuesta es independiente.

¿Cuánto SOL se necesita para ejecutar un validador de Solana?

No existe un mínimo de participación en staking de SOL impuesto por el protocolo. El mínimo práctico viene determinado por el cálculo del punto de equilibrio: tu participación delegada debe generar suficientes ingresos por comisiones para cubrir los costes mensuales del servidor más aproximadamente 30 SOL en comisiones de voto. Para la mayoría de los operadores con las tasas de APY y de comisión típicas, esto supone entre 50.000 y más de 100.000 SOL en participación delegada, o calificar para el impulso del SFDP mientras se construye la delegación orgánica. Consulta la sección de Economía para ver la fórmula completa de rentabilidad.

Espera un coste de entre 250 y 500 dólares al mes por un servidor bare-metal que cumpla las especificaciones recomendadas por Solana, más aproximadamente 30 SOL al mes en comisiones de transacciones de voto a las tasas actuales de mainnet-beta. El coste mensual total en USD depende del precio actual de SOL) en el momento de la operación. Esta es una variable clave en el modelo de rentabilidad que debes recalcular con los datos actuales del mercado. Consulta la sección de Costes de Infraestructura para ver la tabla comparativa de proveedores de hosting.

Como mínimo: una CPU con 12+ núcleos y alta velocidad de reloj mononúcleo, 128 GB de RAM ECC DDR4, SSD NVMe PCIe Gen3 (unidades separadas para SO/ledger y cuentas), y una conexión de red simétrica de 1 Gbps. Las especificaciones de producción recomendadas son 24+ núcleos de CPU (serie AMD EPYC 7003), 256 GB de RAM ECC, SSD NVMe PCIe Gen4 y redes de 10 Gbps. Los SSD SATA estándar no pueden cumplir los requisitos de E/S de Solana. Consulte la sección Requisitos de hardware para ver la tabla de especificaciones completa.

¿Es rentable ejecutar un validador de Solana?

La rentabilidad depende de cuatro variables: la participación delegada, el precio de SOL, la tasa de comisión y los costos operativos mensuales (servidor más tarifas de voto). Los validadores con más de 50.000 SOL delegados pueden acercarse a la rentabilidad con las tasas típicas de APY y comisiones. Los validadores con menos de 20.000 SOL delegados operarán con pérdidas hasta que la delegación SFDP o el crecimiento orgánico cierren la brecha. No se garantiza la rentabilidad de ningún validador; todos los cálculos de ganancias son estimaciones basadas en condiciones variables de la red. Consulte la tabla de escenarios de rentabilidad en la sección Costos.

¿Qué es el Programa de Delegación de la Fundación Solana?

El SFDP es un programa a través del cual la Fundación Solana asigna participación de SOL de su tesorería a validadores elegibles en mainnet-beta, apoyando la descentralización de la red y ayudando a los nuevos validadores a alcanzar la viabilidad económica antes de atraer delegadores orgánicos. La elegibilidad requiere el cumplimiento de umbrales de rendimiento, límites de tasa de comisión y criterios de diversidad de centros de datos. La delegación SFDP no es automática, no es permanente y está sujeta a la discreción continua de la Fundación. Consulte la sección SFDP para ver la lista de verificación de elegibilidad y el proceso de solicitud.

¿Cuántos validadores tiene Solana?

Solana mainnet-beta tiene aproximadamente entre 1.500 y 1.800 validadores activos según la estimación de la fuente (Fuente: validators.app)

¿Puedo ejecutar un validador de Solana en un servidor en la nube?

Las instancias VPS en la nube son aceptables para la experimentación en testnet y devnet, pero no son adecuadas para la producción en mainnet-beta. El almacenamiento virtualizado en VPS en la nube introduce fluctuaciones de IOPS que provocan votos perdidos y degradan su tasa de omisión y su puntuación de rendimiento SFDP. Los servidores dedicados bare-metal son el estándar de producción. Si está considerando una oferta de "nube bare-metal" (servidores físicos disponibles a través de proveedores de nube), verifique que las características de E/S coincidan con las de bare-metal dedicado antes de aprovisionar para mainnet.

¿Qué es una cuenta de voto en Solana?

Una cuenta de voto es la cuenta On-Chain a través de la cual su validador envía votos de bloques cada época. Está separada de su cuenta de identidad (que identifica y autentica su nodo validador). La cuenta de voto requiere un balance exento de alquiler de aproximadamente 0.02685 SOL y consume aproximadamente 1 SOL por día en tarifas de transacción de voto en mainnet-beta. Quedarse sin SOL en la cuenta de voto provoca que su validador se vuelva moroso: deja de votar, deja de obtener recompensas y pierde la participación delegada a medida que empeoran las puntuaciones de rendimiento.

¿Tiene Solana penalizaciones por slashing para validadores?

En la fecha de revisión de la fuente, Solana no tenía penalizaciones por slashing para validadores. Verifique el estado actual del protocolo antes de basarse en esta declaración. Esto contrasta con los validadores de Ethereum, que enfrentan penalizaciones por slashing por equívoco (firmar bloques conflictivos) y votos envolventes. Para el estado de la fuente fechado y los cambios de protocolo propuestos, consulte Explicación del slashing de validadores de Solana. La ausencia de slashing en Solana significa que los validadores no corren el riesgo de perder SOL en staking debido a errores de software o de configuración que activarían condiciones de slashing en Ethereum. Este es el estado actual del protocolo y está sujeto a cambios con futuras actualizaciones de Solana.

¿Es adecuado para usted ejecutar un validador de Solana? Un marco de decisión

Validador vs. Delegador: una comparación práctica

El artículo fuente duplicado planteó la decisión operativa directamente. La distinción esencial es si desea operar infraestructura o ganar recompensas de participación sin mantener un servidor.

Para los lectores que deciden delegar en su lugar, utilice los criterios en cómo elegir un validador de Solana.

La decisión de seguir adelante o no con la ejecución de un validador de Solana se reduce a cuatro variables: sus habilidades de infraestructura Linux, su presupuesto de hardware, su posición de stake de SOL y su tolerancia a un período de adaptación de 3 a 6 meses antes de que los ingresos por comisión cubran consistentemente los costos operativos mensuales.

Ejecute un validador si:

• Tiene habilidades de aprovisionamiento y gestión de servidores Linux (SSH, systemd, configuración de firewall, monitorización de logs)
• Puede aprovisionar o alquilar hardware que cumpla con las especificaciones recomendadas (250 a 500 $/mes o más)
• Tiene suficientes SOL para cubrir las tarifas de voto durante el período de adaptación antes de que la delegación SFDP u orgánica alcance el punto de equilibrio
• Puede comprometerse con disponibilidad de servidor 24/7 y monitorización diaria de métricas de rendimiento
• Desea participación activa en la infraestructura de la red Solana más allá de la participación pasiva

Delegue en su lugar si:

• Su objetivo es obtener ingresos de participación de SOL sin gestionar la infraestructura
• Sus habilidades de Linux aún no están al nivel de administración de servidores requerido
• Sus tenencias totales de SOL caen por debajo del umbral de participación delegada de punto de equilibrio con las tasas actuales de APY
• No puede comprometerse con la monitorización continua y la disponibilidad de guardia para su validador

Próximos pasos para los operadores que deciden continuar:

1. Aprovisione hardware según la sección Requisitos de hardware
2. Practique en testnet durante al menos una época completa antes de tocar mainnet-beta
3. Revise la lista de verificación de elegibilidad SFDP antes de su fecha de lanzamiento en mainnet
4. Configure alertas de monitorización de Grafana + Prometheus y de balance de cuenta de voto desde el primer día de operación en mainnet
5. Marque la documentación de configuración del validador de Solana

Con un aprovisionamiento de hardware preciso, una cuenta de voto financiada y un cronograma realista de participación a rentabilidad, la operación de un validador de Solana puede ser una contribución duradera y basada en comisiones a una de las redes de mayor rendimiento de la industria.