Requisitos de un validador de Solana: stake, hardware y costos operativos

Validador versus nodo RPC: roles distintos, requisitos distintos

Un validador de Solana vota en la bifurcación y participa en el consenso. Mantiene un par de claves de identidad, una cuenta de voto y una cuenta de stake, y debe estar en línea de forma continua para no perder votos. Un nodo RPC, en cambio, atiende tráfico de lectura como getAccountInfo o getSlot y no vota. Ambos perfiles suelen confundirse, pero su dimensionamiento y prioridades operativas difieren sustancialmente.

Dado que la función de un validador es votar, su rendimiento se mide en créditos de voto, tasa de omisión y estado de delincuencia, no en consultas por segundo. Un validador que no atiende tráfico RPC puede seguir siendo saludable si vota en cada slot. A la inversa, un nodo RPC con un rendimiento excelente puede ser un mal validador si carece de stake o pierde votos.

La documentación de Solana sobre requisitos de validadores plantea el hardware como una base para la participación en el consenso, mientras que los nodos que atienden RPC suelen necesitar memoria y almacenamiento adicionales para la carga de consultas. Si estás dimensionando un nodo RPC, consulta Requisitos de un nodo RPC de Solana.

• Validador: vota en las bifurcaciones, requiere claves de identidad y de voto, se juzga por créditos de voto y tiempo de actividad.
• Nodo RPC: atiende tráfico de lectura, no vota, se juzga por rendimiento de consultas y disponibilidad.
• Una sola máquina puede desempeñar ambos roles, pero los perfiles de recursos y los modos de fallo difieren.

Configuración de identidad y cuenta de voto

Un validador necesita dos pares de claves distintos: un par de claves de identidad que identifica al nodo en la red, y un par de claves de cuenta de voto que controla la votación y la recolección de recompensas. El par de claves de identidad firma los mensajes de consenso; la cuenta de voto contiene los créditos de voto del validador y la configuración de comisión. Mantenerlos separados es un requisito de seguridad, no una comodidad.

Crear una cuenta de voto requiere una tarifa de transacción y un depósito exento de renta. El costo exacto depende de la tasa de renta actual y del tamaño de la cuenta, así que trata cualquier cifra como una instantánea y no como una constante. La documentación de Solana sobre cuentas de voto describe la estructura de la cuenta y el flujo de trabajo solana create-vote-account.

La cuenta de voto también almacena un porcentaje de comisión, que determina cuánto de la recompensa de staking se queda el validador antes de distribuir el resto a los delegadores. La comisión es una decisión de negocio, pero también una señal competitiva: los delegadores comparan la comisión entre validadores al elegir dónde hacer staking.

• Par de claves de identidad: identifica al nodo, firma los mensajes de consenso.
• Par de claves de cuenta de voto: controla la votación, los créditos y la comisión.
• Creación de la cuenta de voto: tarifa de transacción más depósito exento de renta, ambos dependientes de la red.
• Comisión: la parte del validador en las recompensas de staking, configurada por cuenta de voto.

Stake: el umbral económico para el conjunto activo

Un validador necesita stake delegado para estar en el conjunto activo y ganar recompensas. Sin stake suficiente, es posible que el validador no sea seleccionado para votar y sus créditos de voto no se traduzcan en recompensas significativas. Esto hace que los 'requisitos' sean tanto técnicos como económicos: el hardware por sí solo no hace rentable a un validador.

El auto-stake es un arranque común. Un operador financia una cuenta de stake, la delega a su propia cuenta de voto y la usa para entrar en el conjunto activo. Sin embargo, el auto-stake suele ser insuficiente a largo plazo porque la parte de recompensas escala con el stake total, y los validadores más grandes atraen delegadores mediante rendimiento y comisión. Por eso muchos operadores se centran en la delegación en lugar de depender del auto-stake.

El stake mínimo para entrar en el conjunto activo no es un número fijo; depende del stake total en la red y del número de validadores activos. Puedes inspeccionar la distribución actual del stake usando los métodos RPC descritos más adelante en este artículo, y puedes leer más sobre la mecánica de delegación en Lecturas RPC de delegación de cuentas de stake de Solana.

• La pertenencia al conjunto activo depende del stake total delegado, no solo del auto-stake.
• El auto-stake es un arranque; la delegación es la vía de crecimiento a largo plazo.
• La comisión y el rendimiento de voto influyen en la elección del delegador.
• Los umbrales de stake varían con las condiciones de la red y el número de validadores.

Dimensionamiento de hardware: CPU, RAM, almacenamiento y red

La documentación de Solana publica una base de hardware para validadores, pero es un objetivo móvil. A medida que aumenta la carga de la red, la base sube con ella, y cada versión puede revisar la recomendación. Trata cualquier tabla de hardware como un punto de partida que debe revisarse contra la documentación actual antes de comprar.

Los requisitos de CPU vienen determinados por la ingesta de transacciones, la ejecución y la verificación de firmas. El rendimiento de un solo hilo importa porque algunas etapas no son totalmente paralelas, mientras que el número de núcleos importa para la ejecución concurrente y la red. La RAM debe acomodar el estado de las cuentas y el conjunto de trabajo del ledger; una RAM insuficiente provoca swap y votos perdidos.

El almacenamiento debe ser un SSD NVMe rápido y de alta resistencia, porque el ledger se escribe de forma continua y el desgaste es un costo real. Los requisitos de red son alto ancho de banda y baja latencia; un validador que no puede recibir y propagar bloques rápidamente perderá votos. Para una comparación más amplia de roles de nodos, consulta Nodo de archivo vs nodo completo.

• CPU: buen rendimiento de un solo hilo más suficientes núcleos para la ingesta y la ejecución.
• RAM: dimensionada para el estado de las cuentas y el conjunto de trabajo del ledger; evita el swap.
• Almacenamiento: SSD NVMe de alta resistencia para el ledger; planifica el desgaste.
• Red: alto ancho de banda, baja latencia, conectividad estable.

Operaciones: monitoreo de créditos de voto, tasa de omisión y delincuencia

Un validador es un compromiso operativo siempre activo. Las señales clave de salud son los créditos de voto, la tasa de omisión, el estado de delincuencia y el retraso de slot. Los créditos de voto deben aumentar de forma constante; una meseta indica votos perdidos. La tasa de omisión mide con qué frecuencia el validador no vota en un slot para el que era elegible. El estado de delincuencia significa que el validador se ha quedado atrás y no está votando.

El monitoreo debe ser automatizado y las alertas deben dispararse antes de que el validador entre en estado de delincuencia. Las causas comunes de votos perdidos incluyen saturación de CPU, bloqueos de E/S de disco, latencia de red y desviación del reloj. La planificación de failover importa: si el nodo principal falla, un nodo en espera con las mismas claves de identidad y voto puede tomar el relevo, pero solo si las claves están disponibles y el cambio está coordinado para evitar el doble voto.

Puedes inspeccionar los límites de época y slot para entender cuándo se contabilizan los créditos de voto; consulta Calendario de épocas y límites de slot de Solana.

• Créditos de voto: deben aumentar cada época; las mesetas indican votos perdidos.
• Tasa de omisión: proporción de slots elegibles sin voto.
• Indicador de delincuencia: el validador está atrasado y no vota.
• Retraso de slot: distancia desde el slot actual; un retraso creciente precede a la delincuencia.
• Failover: nodo en espera con las mismas claves, coordinado para evitar el doble voto.

Leer correctamente la tabla oficial de hardware

La tabla oficial de hardware es una base, no una garantía. Se actualiza a medida que la red evoluciona, y la CPU, la RAM y el almacenamiento recomendados pueden cambiar entre versiones. Si dimensionas según una tabla antigua, puedes aprovisionar de menos y perder votos bajo carga.

Cuando leas la tabla, anota la fecha y la versión a la que corresponde. Verifícala con la página actual de requisitos de validadores de Solana y con las notas de la versión. Si tu proveedor publica su propia guía, trátala como específica del proveedor y verifícala con la fuente oficial.

Un enfoque práctico es aprovisionar por encima de la base para CPU y almacenamiento, porque son los más difíciles de actualizar rápidamente. La RAM y la red a veces pueden escalarse de forma más elástica, pero un validador que hace swap o pierde paquetes perderá votos independientemente del stake.

• Trata la tabla como una base móvil, no como una especificación fija.
• Vuelve a verificarla en cada versión y antes de actualizaciones importantes de la red.
• Aprovisiona margen para CPU y almacenamiento; son los más difíciles de cambiar rápidamente.
• La guía específica del proveedor está documentada / varía según el proveedor; verifícala con fuentes oficiales.

Calcular el panorama honesto de costos

La economía de un validador está dominada por el stake, no por el hardware. El panorama honesto de costos incluye el costo de oportunidad del auto-stake, la compra o alquiler de hardware, el ancho de banda y el esfuerzo operativo. Frente a eso, comparas tu parte esperada de recompensas, que depende del stake total, la comisión y el rendimiento de voto.

El costo de oportunidad del auto-stake es el rendimiento al que renuncias por bloquear capital en una cuenta de stake en lugar de desplegarlo en otro lugar. El hardware y el ancho de banda son costos recurrentes. El esfuerzo operativo incluye monitoreo, actualizaciones, respuesta a incidentes y el costo de mantener un nodo en espera.

Como la parte de recompensas escala con el stake, un validador con un stake modesto puede no cubrir sus costos incluso con un tiempo de actividad perfecto. Por eso muchos operadores delegan stake en lugar de depender del auto-stake, y por eso algunos eligen ejecutar infraestructura RPC. Para opciones de servicio, consulta Precios de RPC y Servicio de API.

• Costo de oportunidad del auto-stake: rendimiento al que se renuncia por bloquear capital.
• Hardware y ancho de banda: recurrentes y sensibles al crecimiento de la red.
• Esfuerzo operativo: monitoreo, actualizaciones, respuesta a incidentes, nodo en espera.
• Parte de recompensas: impulsada por el stake total, la comisión y el rendimiento de voto.

Ejemplo ejecutable: inspeccionar el estado del validador y de la cuenta de voto vía RPC

Puedes medir la salud de tu validador desde la propia cadena usando Solana JSON-RPC. El siguiente script de Node.js llama a getVoteAccounts para listar los validadores actuales y en estado de delincuencia, y luego imprime los créditos de voto, la comisión y el indicador de delincuencia para una cuenta de voto dada. Reemplaza el endpoint y la clave pública de la cuenta de voto por los tuyos.

La API JSON-RPC de Solana documenta getVoteAccounts y métodos relacionados. Este script es de solo lectura y es seguro ejecutarlo contra cualquier endpoint, incluido uno público, aunque los endpoints públicos pueden aplicar límites de tasa.

Ejecútalo periódicamente y registra la salida. Un recuento de créditos de voto en aumento con una comisión estable y sin indicador de delincuencia es el estado saludable de referencia.

const https = require('https');

const ENDPOINT = 'https://api.mainnet-beta.solana.com';
const VOTE_ACCOUNT = 'YOUR_VOTE_ACCOUNT_PUBKEY';

function rpc(method, params) {
  return new Promise((resolve, reject) => {
    const body = JSON.stringify({ jsonrpc: '2.0', id: 1, method, params });
    const req = https.request(ENDPOINT, {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' }
    }, (res) => {
      let data = '';
      res.on('data', (chunk) => data += chunk);
      res.on('end', () => resolve(JSON.parse(data)));
    });
    req.on('error', reject);
    req.write(body);
    req.end();
  });
}

(async () => {
  const result = await rpc('getVoteAccounts', [{ commitment: 'finalized' }]);
  const all = [...result.result.current, ...result.result.delinquent];
  const match = all.find(v => v.votePubkey === VOTE_ACCOUNT);
  if (!match) {
    console.log('Vote account not found in current or delinquent set.');
    return;
  }
  console.log({
    votePubkey: match.votePubkey,
    nodePubkey: match.nodePubkey,
    activatedStake: match.activatedStake,
    commission: match.commission,
    epochVoteAccount: match.epochVoteAccount,
    epochCredits: match.epochCredits,
    lastVote: match.lastVote,
    delinquent: result.result.delinquent.some(v => v.votePubkey === VOTE_ACCOUNT)
  });
})();

Tabla de resultados reproducibles para tu propio validador

Usa la tabla a continuación para registrar lo que observas desde tu propio endpoint y compararlo con las bases documentadas. Rellena la columna 'Valor observado' con la salida RPC, la columna 'Base documentada' con la documentación oficial de hardware y cuentas de voto, y las columnas 'Veredicto' y 'Acción' según tus propios umbrales.

Este método lo verifica el lector: los números provienen de tu endpoint y tu validador, no de un benchmark de proveedor. Vuelve a ejecutarlo después de cada versión y de cualquier cambio de hardware.

• Dimensión: créditos de voto por época | Valor observado: | Base documentada: en aumento cada época | Veredicto: | Acción:
• Dimensión: tasa de omisión | Valor observado: | Base documentada: cercana a cero | Veredicto: | Acción:
• Dimensión: indicador de delincuencia | Valor observado: | Base documentada: false | Veredicto: | Acción:
• Dimensión: retraso de slot | Valor observado: | Base documentada: pequeño y estable | Veredicto: | Acción:
• Dimensión: utilización de CPU | Valor observado: | Base documentada: por debajo de la saturación | Veredicto: | Acción:
• Dimensión: uso de RAM y swap | Valor observado: | Base documentada: sin swap | Veredicto: | Acción:
• Dimensión: latencia de E/S de disco | Valor observado: | Base documentada: baja y estable | Veredicto: | Acción:
• Dimensión: latencia de red al clúster | Valor observado: | Base documentada: baja | Veredicto: | Acción:

Solución de problemas comunes de salud del validador

Los votos perdidos son el síntoma más común. Si los créditos de voto se estancan, revisa primero la saturación de CPU, los bloqueos de E/S de disco y la latencia de red. Un validador que hace swap o espera al disco perderá slots incluso si el stake es suficiente.

El estado de delincuencia suele significar que el validador se ha quedado atrás respecto al clúster. Comprueba si el nodo está sincronizado, si las claves de identidad y voto son correctas y si el nodo puede alcanzar el clúster. Si ejecutas un nodo en espera, verifica que solo un nodo esté votando con la misma cuenta de voto a la vez.

Los cambios de comisión y stake también pueden afectar las recompensas. Si tu comisión es alta en relación con la de tus pares, los delegadores pueden irse, reduciendo tu stake y tu parte de recompensas. Monitorea juntos la delegación de la cuenta de stake y la comisión de la cuenta de voto.

• Meseta de créditos de voto: revisa CPU, E/S de disco, latencia de red.
• Delincuencia: verifica sincronización, claves y conectividad con el clúster.
• Riesgo de doble voto: asegúrate de que solo un nodo vote por cuenta de voto.
• Caída de recompensas: revisa cambios en la comisión y el stake delegado.

Limitaciones, compensaciones y próximos pasos

La economía de un validador está dominada por el stake, no por el hardware. Un nodo perfectamente aprovisionado con poco stake no ganará recompensas significativas. La guía de hardware cambia entre versiones, por lo que cualquier decisión de dimensionamiento debe revisarse periódicamente. Ejecutar un validador es un compromiso operativo siempre activo, y los requisitos de un validador nunca deben confundirse con el dimensionamiento de un nodo RPC.

Si tu objetivo es atender tráfico de lectura en lugar de votar, considera un nodo RPC o un servicio gestionado. OnFinality ofrece endpoints RPC de Solana e información de red en Redes de Solana. Para una ruta de aprendizaje más amplia, empieza en el centro de aprendizaje de OnFinality.

Próximos pasos: ejecuta el script RPC anterior contra tu endpoint, rellena la tabla de resultados y compárala con la documentación oficial de requisitos de validadores de Solana y cuentas de voto. Vuelve a verificarla después de cada versión y revisa tu estrategia de stake y comisión a medida que cambian las condiciones de la red.

• El stake domina la economía; el hardware es necesario pero no suficiente.
• Las bases de hardware cambian; vuelve a verificarlas en cada versión.
• El validador está siempre activo; planifica monitoreo y failover.
• No confundas el dimensionamiento de un validador con el de un nodo RPC.
• Siguiente: mide con RPC, rellena la tabla, compara con la documentación oficial.