Conceptos básicos de validadores
7 ejemplos para empezar con las operaciones de validadores: 4 básicos y 3 intermedios. Cubre votación, participación en consenso, roles de RPC vs. validador y staking en Agave 4.1.1.
Prerrequisitos
- Solana CLI 3.0.10 para consultas de clúster.
- Servidor que cumpla las directrices de hardware de Solana para la validación en mainnet (consulte Hardware y redes).
solana --version
solana validators --url mainnet-beta | headEjemplos básicos
1. Consultar el conjunto de validadores
Los validadores publican cuentas de votación en la cadena.
solana validators --url mainnet-beta --output json-compact | head -c 2000- Cada validador tiene una cuenta de votación y un par de claves de identidad.
- Los pesos de stake determinan la influencia en el programa de líderes.
- El indicador
delinquentmarca los umbrales de votación perdidos.
Relacionado: Cuentas de votación y staking
2. Distinguir el nodo validador vs. RPC
No todos los servidores RPC son validadores de staking.
# El validador ejecuta agave-validator con --vote-account
# Solo RPC puede ejecutar agave-validator sin votar o con un plugin RPC dedicado- Los validadores votan en el consenso BFT de la torre.
- Los nodos RPC sirven
getBlock,sendTransactiona las aplicaciones. - Muchos operadores ejecutan una flota RPC separada del validador de votación.
Relacionado: Cliente Agave
3. Comprobar la versión del clúster
Los validadores deben permanecer en versiones compatibles de Agave.
solana cluster-version --url mainnet-beta- Las actualizaciones de red se coordinan a través de canales de lanzamiento (ecosistema Agave 4.1.1).
- Las versiones atrasadas corren el riesgo de incumplimiento o incompatibilidad de bifurcación.
- Supervise los anuncios de
#validator-operatorsantes de las actualizaciones.
4. Leer información de la época
Las recompensas de stake y el programa de líderes rotan por época.
solana epoch-info --url mainnet-beta- Duración de la época en slots (aprox. 2 días en mainnet).
slotIndexrastrea el progreso dentro de la época.- Planifique ventanas de mantenimiento en torno a los límites de época siempre que sea posible.
Relacionado: Monitorización y operaciones de época
Ejemplos intermedios
5. Identidad vs. clave de votación
Los operadores protegen roles de clave distintos.
Par de claves de identidad: paga las transacciones de votación, recibe propinas de tarifa de prioridad (dependiente de la configuración)
Cuenta de votación: objetivo de delegación de stake en la cadena- Almacene las claves en módulos de hardware o HSM para producción.
- Rote la identidad con cuidado: actualice los registros en la cadena.
6. Conciencia de QoS ponderada por stake
Los validadores con stake reciben una mejor programación de transacciones (SWQoS).
solana stakes <VOTE_ACCOUNT> --url mainnet-beta- Más stake mejora la inclusión bajo congestión.
- Jito-Solana añade rutas de bundles/MEV (Jito-Solana).
Relacionado: QoS ponderada por stake
7. Selección de cliente
Agave es el predeterminado; Firedancer/Frankendancer y Jito-Solana son alternativas.
| Cliente | Perfil del operador |
|---|---|
| Agave 4.1.1 | Propósito general, línea principal de Anza |
| Frankendancer | Híbrido centrado en el rendimiento |
| Jito-Solana | Validación habilitada para MEV |
Relacionado: Firedancer / Frankendancer
Versiones de la pila: Esta página se escribió para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 y LiteSVM 0.6.x.