SLV completa el soporte para Solana v4 con XDP y BLS listo para Alpenglow

ELSOUL LABO B.V. (Sede: Ámsterdam, Países Bajos; CEO: Fumitake Kawasaki) y Validators DAO se complacen en anunciar que SLV, la herramienta de operación de Solana de código abierto, ha completado el soporte para Solana v4 (Agave 4.x).

Con esta actualización, las optimizaciones en las que confían los validadores de Solana de mayor rendimiento — la aceleración del reenvío de Turbine con XDP de Anza y el flujo de registro de clave pública BLS listo para Alpenglow definido en SIMD-0387 — ahora pueden ser ejecutadas por cualquier operador a través de la misma receta operativa probada, mediante conversaciones con un agente de IA o por operación directa de CLI. El ajuste avanzado que antes requería un profundo conocimiento de Linux y de Solana se consolida en SLV, de modo que incluso los operadores sin esa formación especializada pueden reproducirlo solo mediante la conversación.

Sitio oficial de SLV: https://slv.dev/es SLV en GitHub: https://github.com/validatorsDAO/slv

Democratizar la operación de validadores de primer nivel — Optimización de clase mundial, reproducible por cualquiera

SLV es un esfuerzo de código abierto para operar validadores de Solana junto con agentes de IA, ofreciendo la más alta calidad de mantenimiento a bajo costo, en cualquier parte del mundo.

En Solana, la brecha entre el rendimiento puro de un validador y el saber-hacer operativo que hay detrás se ha ido ampliando. Redes de baja latencia, ajuste del kernel y de la NIC, una preparación cuidadosa para las actualizaciones de protocolo — las operaciones que conducen al rendimiento de un validador de primer nivel han exigido un profundo conocimiento especializado de Linux y de Solana, además de un trabajo manual continuo. Como resultado, los niveles más altos de operación tendían a permanecer accesibles solo para un grupo limitado de operadores con esa experiencia.

SLV existe para cerrar esa brecha. Al consolidar el saber-hacer operativo acumulado por las operaciones de validadores de clase mundial en habilidades para un agente de IA, cualquiera puede reproducir la misma receta operativa solo mediante la conversación. Este soporte para Solana v4 lleva esa idea directamente a las optimizaciones más recientes: XDP y BLS, las mismas tecnologías que están adoptando los validadores de mayor rendimiento, ahora están disponibles para todo operador que use SLV — sin renunciar a su propia elección de cliente o de entorno.

Lo que aporta el soporte para Solana v4 — XDP, BLS y seguridad en el reinicio, todo gestionado por ti

Solana v4 (Agave 4.x) es la última generación del cliente de validador, recomendada por Anza para mainnet, y eleva el rendimiento del núcleo a la vez que prepara la red para bloques más grandes y para la próxima actualización de consenso Alpenglow. El soporte de v4 de SLV cubre las tres áreas que más importan a los operadores que migran a esta base.

Aceleración del reenvío de Turbine con XDP — habilitación llave en mano del camino de red de alto rendimiento que acelera la propagación de bloques.
Registro de clave pública BLS listo para Alpenglow (SIMD-0387) — preparar el flujo de registro con antelación, para que los validadores estén listos para registrar en cuanto se active la feature gate de Alpenglow.
Seguridad en el reinicio para Agave 4.1+ — ajustar el rango de puertos y restringir las banderas exclusivas del reinicio de clúster, de modo que pasar al nuevo cliente no introduzca fallos de arranque evitables.

Cada una de ellas se gestiona a través del mismo flujo de SLV — conversación con el agente de IA o CLI — de modo que la migración a Solana v4 no se convierte en un proyecto manual y propenso a errores. La última versión de SLV incorpora todo lo anterior como parte de la serie v2026.6.6 — BLS, XDP y las correcciones de seguridad en el reinicio llegando primero, con la robustez de Firedancer y RPC siguiendo en la misma serie.

Qué es XDP — Un camino rápido del kernel de Linux que acelera Turbine

XDP (eXpress Data Path) es una tecnología del kernel de Linux que permite a código de red de alto rendimiento eludir gran parte del camino habitual de manejo de paquetes del kernel. Al reducir las copias de datos y los cambios de contexto, procesa paquetes con mucha menos sobrecarga que la pila de red estándar.

En Agave, XDP se aplica a Turbine, el protocolo que propaga los bloques a través de la red de validadores. Los shreds entrantes son manejados por un programa eBPF asociado cerca de la tarjeta de interfaz de red (NIC) y mapeados a buffers en el espacio de usuario mediante AF_XDP, mientras que los shreds salientes se envían directamente usando XDP_TX — eliminando syscalls y copias en el camino crítico. Anza introdujo XDP para Turbine en la serie Agave 3.x (desde la v3.0.9) y lo lleva a la base de Agave 4.0.

Según la guía de configuración de Anza, los validadores grandes pueden acercarse a los 150,000 paquetes salientes por segundo con XDP. Anza posiciona XDP como parte del margen que prepara a los validadores para los bloques de 100M-CU y hace avanzar la hoja de ruta de IBRL (Increase Bandwidth, Reduce Latency), y ha publicado una guía oficial de configuración para los operadores que lo adopten.

Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide

SLV hace XDP llave en mano — Actívalo con una conversación y unas pocas variables de inventario

Adoptar XDP a mano no es trivial. Requiere un kernel reciente (6.14+ para el controlador igb, 6.8+ para los demás), una NIC compatible con XDP, las capacidades de systemd adecuadas para el proceso del validador y las banderas de arranque correctas — y la fijación de núcleos de CPU (incluido el núcleo de PoH) debe elegirse correctamente para que el camino rinda. Este es exactamente el tipo de trabajo especializado que ha mantenido la optimización avanzada fuera del alcance de muchos operadores.

SLV convierte esto en un paso llave en mano. La aceleración del reenvío con XDP es opt-in a través de variables de inventario por host — xdp_enabled, xdp_interface, xdp_cpu_cores, xdp_zero_copy y xdp_poh_pinned_cpu_core. Cuando se habilita, SLV aplica las banderas de arranque de XDP apropiadas para la versión de Agave/Jito de destino y otorga automáticamente las capacidades de systemd requeridas (CAP_NET_RAW, CAP_NET_ADMIN, CAP_BPF, CAP_PERFMON). Estas variables se aplican a los validadores Agave y Jito; Firedancer usa XDP de forma nativa y no necesita una habilitación aparte. (XDP ha madurado a lo largo de las versiones de Agave — ya no es experimental a partir de Agave 4.1, y los nombres de las banderas correspondientes cambiaron por el camino — de modo que SLV sigue las banderas correctas para cada versión, y los operadores no tienen que hacerlo.)

Desde el lado del operador, esto puede impulsarse por completo mediante la conversación. Inicia la AI Console y di algo como "Habilita la aceleración del reenvío con XDP en este validador", y el agente de IA selecciona y aplica la configuración necesaria. También se proporcionan comandos equivalentes para los usuarios orientados a la CLI, de modo que los flujos de trabajo que no involucran agentes de IA están plenamente soportados. La misma optimización de red que usan los validadores de mayor rendimiento se convierte en algo que cualquier operador de SLV puede activar.

Registro BLS listo para Alpenglow — Soporte anticipado para SIMD-0387

Alpenglow es el protocolo de consenso de próxima generación de Solana. Para agregar los votos de los validadores de forma eficiente — por ejemplo, para probar de manera sucinta que el 60% de los validadores votaron por omitir un slot — Alpenglow reemplaza las actuales firmas ed25519 por el esquema de firma agregada BLS (Boneh–Lynn–Shacham) para los votos. SIMD-0387 define cómo los validadores registran una clave pública BLS en su vote account para estar listos para votar en cuanto se active Alpenglow.

Bajo SIMD-0387, registrar una clave pública BLS es posible una vez que la feature gate de la propuesta esté activa, y cada validador debe tener una en su vote account antes de que Alpenglow entre en funcionamiento para poder seguir votando. El par de claves BLS se deriva del par de claves de la vote authority (o del par de claves de identidad si no existe), y el registro se realiza on-chain junto con una Proof of Possession (PoP) — una prueba criptográfica que vincula la clave al vote account y que previene los ataques de clave fraudulenta (rogue-key). En la actualidad, SIMD-0387 está en la etapa de revisión y su feature gate aún no está activa en mainnet (su activación está prevista para devnet), por lo que todavía no se puede registrar ninguna clave BLS en mainnet; lo que importa hoy es tener el flujo listo para cuando se abra la gate.

Aquí es precisamente donde importa estar listo con antelación. Una vez que Alpenglow esté en funcionamiento, un vote account sin una clave BLS registrada se comportaría como si estuviera sin stake. Tener el flujo de registro implementado de antemano, en lugar de improvisar cuando se abra la gate, es lo que mantiene una operación segura a través de la transición.

register:bls de SLV — Preparado automáticamente en el momento del despliegue

SLV implementa esta preparación por ti. El nuevo comando slv v register:bls es el flujo que registra la clave pública BLS — derivada del par de claves de authorized-voter o de identidad — en cada vote account una vez que la feature gate esté activa. También se ejecuta automáticamente al final de slv v deploy, de modo que un validador construido o actualizado a través de SLV atraviesa este paso como parte del flujo normal.

La operación está diseñada para ser segura de ejecutar en cualquier momento. En un clúster donde la feature gate aún no esté habilitada, pasa de forma segura como un no-op; una vez que la gate se active, el mismo flujo registra la clave. Es idempotente, así que ejecutarlo con antelación no conlleva ningún riesgo y no hay necesidad de cronometrarlo con precisión respecto a la actualización. Al igual que con XDP, el mismo paso puede impulsarse mediante la conversación con el agente de IA o a través de la CLI. La base que determina si un validador puede seguir votando a través de la transición a Alpenglow queda implementada de antemano, sin gestión manual de claves.

Seguridad en el reinicio reforzada para Agave 4.1+

Migrar a una nueva generación de cliente puede sacar a la luz fallos de arranque sutiles, y el soporte de v4 de SLV los aborda directamente. Para Agave 4.1+ (y los validadores Jito sobre la misma base), el dynamic_port_range se amplía a al menos 27 puertos (8000–8030 / 8900–8930), resolviendo un caso en el que Agave/Jito 4.1.0+ rechaza un rango más estrecho en el arranque con "Port range is too small" — un fallo que dejaba a validadores y nodos RPC en un bucle de caída (crash-loop). La corrección cubre todos los scripts de arranque de validator, RPC y pythnet, junto con los valores predeterminados de init e inventario.

Además, las banderas exclusivas del reinicio de clúster ahora están restringidas: --wait-for-supermajority y --expected-bank-hash solo se emiten cuando se establecen explícitamente, de modo que un slot o bank hash obsoleto ya no puede colgar un nodo, ni provocar un panic por discordancia de bank-hash, en un reinicio ordinario. Estos son el tipo de detalles que, gestionados a mano, convierten una actualización rutinaria en un incidente — y de los que SLV ahora se ocupa como parte de la receta estándar.

Este endurecimiento continúa a lo largo de la receta. Una versión posterior extiende la misma robustez operativa a los caminos de Firedancer y RPC — manejo de la versión de Firedancer consciente de la red, una limpieza de conflictos de compilación de Jito y correcciones en los scripts de arranque de RPC — de modo que la migración a la última base se mantenga fluida sin importar qué cliente ejecute un operador.

Eliminar la reinvención de la rueda — Consolidar el saber-hacer de primer nivel en el agente de IA

En el ecosistema de Solana, muchos proyectos dedican tiempo al trabajo compartido de operar validadores y nodos, separado del desarrollo de su producto real. Construir, desplegar, monitorear, actualizar y migrar clientes — para cada proyecto, son repeticiones similares de las mismas tareas, una especie de reinvención de la rueda.

La habilitación de XDP y el registro BLS listo para Alpenglow son ejemplos perfectos. Son avanzados, fáciles de equivocar, y de lo contrario cada operador tiene que investigarlos y re-derivarlos de forma independiente. Al consolidar este saber-hacer operativo en habilidades de SLV para el agente de IA, la misma receta probada puede ser reproducida por cualquiera, solo mediante la conversación — y el costo humano de la operación baja de forma estructural. Con esta versión, la habilidad de validador de SLV — el conocimiento del que se nutre el agente de IA — se ha actualizado para BLS (SIMD-0387) y XDP, de modo que el agente aplica el procedimiento actual y correcto en lugar de uno obsoleto. Esto es lo que significa en la práctica "la más alta calidad de mantenimiento, a bajo costo".

SLV seguirá resolviendo, uno a uno, los pesos operativos comunes a los proyectos de Solana, junto con SLV AI — para que cada proyecto pueda concentrarse en el desarrollo esencial de su propio producto.

CLI y agente de IA — La estabilidad sostiene a ambos

SLV opera de forma estable no solo como agente de IA, sino también como CLI. Para los usuarios que prefieren no depender de agentes de IA, o que quieren integrar SLV en flujos de automatización con scripts, SLV sigue siendo una base operativa práctica.

Esta estabilidad a nivel de CLI es precisamente lo que sostiene la fiabilidad de la operación con el agente de IA. Cada función de SLV es compatible con MCP (Model Context Protocol), y el agente de IA invoca a través de MCP las mismas interfaces que la CLI. Cuando la CLI es estable, el agente de IA es estable — este principio de diseño sostiene la fiabilidad de la operación con el agente de IA de SLV. La habilitación de XDP y register:bls, también, pueden gestionarse de la misma manera tanto desde la CLI como desde el agente de IA, sobre la misma base de MCP.

Una base operativa que respalda un compromiso con el rendimiento — El validador de Epics DAO alcanzó el #3 mundial

El validador de Epics DAO, operado como origen del endpoint SWQoS de ERPC y de Epic Shreds, ha alcanzado el puesto #3 mundial (puntuación 99.93) en el Shinobi Performance Pool entre todos los validadores de Solana, con puntuaciones relacionadas con el voto superiores al 99%.

Este resultado es el desenlace acumulado de múltiples mejoras: selección de hardware, optimización de parámetros del kernel, ajuste de la pila de red, ajuste de la afinidad de IRQ, la adopción de DoubleZero y optimizaciones de red exactamente del tipo que representa XDP. SLV consolida ese saber-hacer operativo en el agente de IA y lo entrega en una forma que cualquiera puede reproducir como la misma receta operativa. Las optimizaciones descritas aquí no son teóricas — provienen de una operación que ha alcanzado la cima de la red.

En combinación con la plataforma ERPC

El soporte de Solana v4 de SLV funciona en cualquier entorno, y se complementa especialmente bien con la plataforma ERPC. ELSOUL LABO opera un centro de datos dedicado a Solana bajo su propio ASN (AS200261), otorgado por RIPE NCC, como parte de la plataforma ERPC — y allí puedes usar las optimizaciones de v4, la automatización de operación de SLV y la plataforma ERPC en conjunto.

ERPC suprime la latencia inducida por la distancia en la etapa de diseño al colocar los validadores de origen, los endpoints de recepción y los nodos de procesamiento dentro de centros de datos premium donde los validadores de Solana se concentran de forma densa. Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, servidores bare metal, SWQoS, la Price API compatible con Pyth, y Jet Analytics & Indexed RPC pueden combinarse todos en la misma plataforma. Ejecutar un validador v4 construido con SLV en la plataforma ERPC te permite combinar las optimizaciones de SLV con la velocidad a nivel de diseño de ERPC, en el mismo entorno.

Sitio oficial de ERPC: https://erpc.global/es

Empieza ahora con los tokens SLV AI

El agente de IA de SLV funciona con tokens SLV AI. Puedes empezar gratis — una autorización de EUR 5 proporciona 100,000 tokens, un volumen suficiente para experimentar la habilitación de XDP, la preparación del registro BLS y la operación de un validador de Solana v4 mediante conversaciones con el agente de IA.

ERPC SLV AI Plans: https://erpc.global/es/price/

También se admiten las conexiones mediante tokens de API de ChatGPT y Claude, de modo que puedes ejecutar SLV AI con tus propias claves de API.

Tu feedback da forma a SLV

SLV evoluciona cada día gracias a tu feedback. Este soporte para Solana v4, también, tomó forma a través de las voces compartidas en el Discord oficial de Validators DAO y a través de la operación de validadores en la cima de la red. Pruébalo y comparte tus opiniones y solicitudes con nosotros en el Discord oficial de Validators DAO.

Gracias, como siempre. Agradecemos tu continuo apoyo a SLV y ERPC.

Contacto

Para consultas sobre SLV y ERPC, abre un ticket de soporte en el Discord oficial de Validators DAO.

Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR

Enlaces

Sitio oficial de SLV: https://slv.dev/es
SLV Getting Started: https://slv.dev/es/doc/general/getting-started/
SLV en GitHub: https://github.com/validatorsDAO/slv
Anza Agave XDP Setup Guide: https://www.anza.xyz/blog/agave-xdp-setup-guide
SIMD-0387 (BLS Pubkey Management in Vote Account): https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0387-bls-pubkey-management-in-vote-account.md
Sitio oficial de ERPC: https://erpc.global/es
ERPC SLV AI Plans: https://erpc.global/es/price/
Sitio oficial de Epics DAO: https://epics.dev/es
Discord oficial de Validators DAO: https://discord.gg/C7ZQSrCkYR

SLV completa el soporte para Solana v4 — Aceleración de Turbine con XDP y registro BLS listo para Alpenglow, reproducible por cualquier validador mediante conversaciones con un agente de IA