SLV conclui o suporte ao Solana v4 com XDP e BLS preparado para o Alpenglow

A ELSOUL LABO B.V. (Sede: Amsterdã, Países Baixos; CEO: Fumitake Kawasaki) e a Validators DAO têm o prazer de anunciar que o SLV, a ferramenta de operação de Solana de código aberto, concluiu o suporte ao Solana v4 (Agave 4.x).

Com esta atualização, as otimizações em que se apoiam os validadores Solana de maior desempenho — a aceleração da retransmissão do Turbine via XDP, da Anza, e o fluxo de registro de chave pública BLS preparado para o Alpenglow definido na SIMD-0387 — agora podem ser executadas por qualquer operador através da mesma receita operacional comprovada, por meio de conversas com um agente de IA ou da operação direta pela CLI. O ajuste avançado que antes exigia profundo conhecimento de Linux e de Solana está consolidado no SLV, de modo que mesmo operadores sem essa formação especializada conseguem reproduzi-lo apenas conversando.

Site oficial do SLV: https://slv.dev/pt SLV no GitHub: https://github.com/validatorsDAO/slv

Democratizando a operação de validadores de primeira linha — otimização de classe mundial, reproduzível por qualquer um

O SLV é uma iniciativa de código aberto para operar validadores Solana junto com agentes de IA, oferecendo a mais alta qualidade de manutenção a baixo custo, em qualquer lugar do mundo.

Na Solana, a distância entre o desempenho bruto de um validador e o conhecimento operacional que o sustenta vem aumentando. Rede de baixa latência, ajuste de kernel e de NIC, preparação cuidadosa para upgrades de protocolo — as operações que levam ao desempenho de validadores de primeira linha exigem profundo conhecimento especializado de Linux e de Solana, além de trabalho manual contínuo. Como resultado, os níveis mais altos de operação tendiam a permanecer acessíveis apenas a um grupo limitado de operadores com essa expertise.

O SLV existe para fechar essa lacuna. Ao consolidar o conhecimento operacional acumulado por operações de validadores de classe mundial em habilidades para um agente de IA, qualquer pessoa pode reproduzir a mesma receita operacional apenas conversando. Este suporte ao Solana v4 leva essa ideia diretamente às otimizações mais recentes: XDP e BLS, as próprias tecnologias que os validadores de maior desempenho estão adotando, ficam agora disponíveis a todo operador que usa o SLV — sem abrir mão da sua própria escolha de cliente ou de ambiente.

O que o suporte ao Solana v4 traz — XDP, BLS e segurança de reinício, tudo cuidado por você

O Solana v4 (Agave 4.x) é a geração mais recente do cliente validador, recomendada pela Anza para a mainnet, e eleva o desempenho central ao mesmo tempo que prepara a rede para blocos maiores e para o próximo upgrade de consenso, o Alpenglow. O suporte do SLV ao v4 cobre as três áreas mais relevantes para os operadores que migram para esse novo patamar.

Aceleração da retransmissão do Turbine via XDP — habilitação turn-key do caminho de rede de alto desempenho que acelera a propagação de blocos.
Registro de chave pública BLS preparado para o Alpenglow (SIMD-0387) — preparando o fluxo de registro com antecedência, para que os validadores estejam prontos para registrar assim que o feature gate do Alpenglow for ativado.
Segurança de reinício para Agave 4.1+ — ajustando a faixa de portas e restringindo as flags exclusivas de reinício de cluster, para que a migração ao novo cliente não introduza falhas de inicialização evitáveis.

Cada um desses pontos é tratado pelo mesmo fluxo do SLV — conversa com o agente de IA ou CLI — de modo que a migração para o Solana v4 não se torne um projeto manual e propenso a erros. A versão mais recente do SLV carrega tudo o que foi descrito acima como parte da série v2026.6.6 — BLS, XDP e as correções de segurança de reinício saindo primeiro, com a robustez do Firedancer e do RPC vindo em seguida na mesma série.

O que é o XDP — um caminho rápido do kernel Linux que acelera o Turbine

O XDP (eXpress Data Path) é uma tecnologia do kernel Linux que permite a um código de rede de alto desempenho contornar grande parte do caminho usual de tratamento de pacotes do kernel. Ao reduzir cópias de dados e trocas de contexto, ele processa pacotes com muito menos sobrecarga do que a pilha de rede padrão.

No Agave, o XDP é aplicado ao Turbine, o protocolo que propaga blocos pela rede de validadores. Os shreds recebidos são tratados por um programa eBPF anexado próximo à placa de interface de rede (NIC) e mapeados para buffers de espaço de usuário via AF_XDP, enquanto os shreds enviados são despachados diretamente usando XDP_TX — eliminando syscalls e cópias no caminho crítico. A Anza introduziu o XDP para o Turbine na série Agave 3.x (a partir da v3.0.9) e o leva adiante para o patamar do Agave 4.0.

Segundo o guia de configuração da Anza, validadores de grande porte podem se aproximar de 150,000 pacotes de saída por segundo com o XDP. A Anza posiciona o XDP como parte da folga que prepara os validadores para blocos de 100M-CU e que faz avançar o roteiro IBRL (Increase Bandwidth, Reduce Latency), e publicou um guia oficial de configuração para os operadores que o adotam.

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

O SLV torna o XDP turn-key — habilite-o com uma conversa e algumas variáveis de inventário

Adotar o XDP manualmente não é trivial. Exige um kernel recente (6.14+ para o driver igb, 6.8+ para os demais), uma NIC com suporte a XDP, as systemd capabilities corretas para o processo do validador e as flags de inicialização adequadas — e a fixação de núcleos de CPU (incluindo o núcleo do PoH) precisa ser escolhida corretamente para que o caminho tenha bom desempenho. É exatamente esse tipo de trabalho especializado que tem mantido a otimização avançada fora do alcance de muitos operadores.

O SLV transforma isso em uma etapa turn-key. A aceleração da retransmissão via XDP é opt-in por meio de variáveis de inventário por host — xdp_enabled, xdp_interface, xdp_cpu_cores, xdp_zero_copy e xdp_poh_pinned_cpu_core. Quando habilitado, o SLV aplica as flags de inicialização XDP apropriadas à versão de Agave/Jito alvo e concede automaticamente as systemd capabilities necessárias (CAP_NET_RAW, CAP_NET_ADMIN, CAP_BPF, CAP_PERFMON). Essas variáveis se aplicam aos validadores Agave e Jito; o Firedancer usa o XDP de forma nativa e não precisa de habilitação à parte. (O XDP amadureceu ao longo das versões do Agave — deixou de ser experimental a partir do Agave 4.1, e os nomes das flags correspondentes mudaram nesse percurso — então o SLV acompanha as flags corretas de cada versão, e os operadores não precisam fazê-lo.)

Do lado do operador, tudo isso pode ser conduzido inteiramente por conversa. Abra o AI Console e diga algo como "Habilite a aceleração da retransmissão XDP neste validador", e o agente de IA seleciona e aplica a configuração necessária. Há também comandos correspondentes para usuários orientados a CLI, de modo que fluxos de trabalho que não envolvem agentes de IA têm suporte completo. A mesma otimização de rede que os validadores de maior desempenho usam torna-se algo que qualquer operador do SLV pode ativar.

Registro de BLS preparado para o Alpenglow — suporte antecipado à SIMD-0387

O Alpenglow é o protocolo de consenso de próxima geração da Solana. Para agregar os votos dos validadores de forma eficiente — por exemplo, para provar de modo conciso que 60% dos validadores votaram por pular um slot — o Alpenglow substitui as assinaturas ed25519 atuais pelo esquema de assinatura agregada BLS (Boneh–Lynn–Shacham) para os votos. A SIMD-0387 define como os validadores registram uma chave pública BLS em sua vote account para ficarem prontos para votar assim que o Alpenglow for habilitado.

Sob a SIMD-0387, o registro de uma chave pública BLS torna-se possível assim que o feature gate da proposta estiver ativo, e cada validador precisa ter uma em sua vote account antes de o Alpenglow entrar em operação para continuar votando. O par de chaves BLS é derivado do par de chaves de vote authority (ou do par de chaves de identity, se aquele não existir), e o registro é realizado on-chain junto com uma Proof of Possession (PoP) — uma prova criptográfica que vincula a chave à vote account e impede ataques de rogue-key. No momento, a SIMD-0387 está em fase de revisão e seu feature gate ainda não está ativo na mainnet (está acompanhado para ativação na devnet), de modo que nenhuma chave BLS pode ser registrada na mainnet ainda; o que importa hoje é ter o fluxo de trabalho pronto para quando o gate abrir.

É precisamente aqui que estar pronto cedo faz diferença. Uma vez que o Alpenglow esteja em operação, uma vote account sem uma chave BLS registrada se comportaria como se estivesse unstaked. Ter o fluxo de registro implementado com antecedência, em vez de correr atrás quando o gate abrir, é o que mantém uma operação segura ao longo da transição.

O register:bls do SLV — preparado automaticamente no momento do deploy

O SLV deixa essa preparação pronta para você. O novo comando slv v register:bls é o fluxo de trabalho que registra a chave pública BLS — derivada do par de chaves authorized-voter ou identity — em cada vote account assim que o feature gate estiver ativo. Ele também é executado automaticamente ao final do slv v deploy, de modo que um validador construído ou atualizado por meio do SLV passa por essa etapa como parte do fluxo normal.

A operação foi projetada para ser segura de executar a qualquer momento. Em um cluster onde o feature gate ainda não está habilitado, ela passa com segurança como um no-op; assim que o gate é ativado, o mesmo fluxo de trabalho registra a chave. É idempotente, portanto executá-la cedo não acarreta risco e não há necessidade de cronometrá-la com precisão em relação ao upgrade. Assim como no XDP, a mesma etapa pode ser conduzida por conversa com o agente de IA ou pela CLI. A base que determina se um validador conseguirá continuar votando ao longo da transição para o Alpenglow fica pronta com antecedência, sem gerenciamento manual de chaves.

Segurança de reinício reforçada para Agave 4.1+

Migrar para uma nova geração de cliente pode trazer à tona falhas de inicialização sutis, e o suporte do SLV ao v4 trata disso diretamente. Para Agave 4.1+ (e validadores Jito sobre a mesma base), a faixa de portas dinâmica é ampliada para pelo menos 27 portas (8000–8030 / 8900–8930), resolvendo um caso em que Agave/Jito 4.1.0+ rejeita uma faixa mais estreita na inicialização com "Port range is too small" — uma falha que colocava validadores e nós RPC em crash-loop. A correção abrange todos os scripts de inicialização de validator, RPC e pythnet, junto com os valores padrão de init e de inventário.

Além disso, as flags exclusivas de reinício de cluster passaram a ser restringidas: --wait-for-supermajority e --expected-bank-hash são emitidas apenas quando explicitamente definidas, de modo que um slot ou bank hash desatualizado não possa mais travar um nó, nem causar panic por incompatibilidade de bank-hash, em um reinício comum. São o tipo de detalhe que, tratado manualmente, transforma um upgrade rotineiro em um incidente — e que o SLV agora cuida como parte da receita padrão.

Esse reforço prossegue ao longo da receita. Uma versão subsequente estende a mesma robustez operacional aos caminhos do Firedancer e do RPC — tratamento de versão do Firedancer ciente da rede, uma limpeza de conflito de build do Jito e correções nos scripts de inicialização do RPC — de modo que a migração para o patamar mais recente permaneça tranquila independentemente de qual cliente um operador execute.

Eliminando a reinvenção da roda — consolidando o conhecimento de primeira linha no agente de IA

No ecossistema Solana, muitos projetos gastam tempo com o trabalho compartilhado de operar validadores e nós, à parte do desenvolvimento do seu produto propriamente dito. Construir, fazer deploy, monitorar, atualizar e migrar clientes — para todo projeto, são repetições semelhantes das mesmas tarefas, uma espécie de reinvenção da roda.

A habilitação do XDP e o registro de BLS preparado para o Alpenglow são exemplos perfeitos. São avançados, fáceis de errar, e cada operador, do contrário, teria de pesquisá-los e rederivá-los de forma independente. Ao consolidar esse conhecimento operacional em habilidades do SLV para o agente de IA, a mesma receita comprovada pode ser reproduzida por qualquer um, apenas conversando — e o custo humano da operação cai estruturalmente. Com esta versão, a habilidade de validador do SLV — o conhecimento de que o agente de IA se vale — foi atualizada para BLS (SIMD-0387) e XDP, de modo que o agente aplica o procedimento atual e correto, em vez de um desatualizado. É isso que "a mais alta qualidade de manutenção, a baixo custo" significa na prática.

O SLV continuará a resolver, um a um, os encargos operacionais comuns aos projetos Solana, junto com a SLV AI — para que cada projeto possa se concentrar no desenvolvimento essencial do seu próprio produto.

Tanto CLI quanto agente de IA — a estabilidade sustenta ambos

O SLV opera de forma estável não só como agente de IA, mas também como CLI. Para usuários que preferem não depender de agentes de IA, ou que querem integrar o SLV a fluxos de automação por scripts, o SLV continua sendo uma base operacional prática.

Essa estabilidade no nível da CLI é precisamente o que sustenta a confiabilidade da operação por agente de IA. Todo recurso do SLV é compatível com MCP (Model Context Protocol), e o agente de IA invoca, via MCP, as mesmas interfaces que a CLI invoca. Quando a CLI é estável, o agente de IA é estável — este princípio de design sustenta a confiabilidade da operação por agente de IA do SLV. A habilitação do XDP e o register:bls também podem ser tratados da mesma forma tanto pela CLI quanto pelo agente de IA, sobre a mesma base MCP.

Uma base operacional que respalda um compromisso com o desempenho — o validador da Epics DAO alcançou o 3º lugar mundial

O validador da Epics DAO, operado como origem do endpoint SWQoS do ERPC e dos Epic Shreds, alcançou o 3º lugar mundial (pontuação 99.93) no Shinobi Performance Pool entre todos os validadores Solana, com pontuações relacionadas a voto acima de 99%.

Esse resultado é o desfecho cumulativo de múltiplas melhorias: seleção de hardware, otimização de parâmetros do kernel, ajuste da pilha de rede, ajuste de afinidade de IRQ, a adoção do DoubleZero e otimizações de rede exatamente do tipo que o XDP representa. O SLV consolida esse conhecimento operacional no agente de IA e o entrega de uma forma que qualquer um pode reproduzir como a mesma receita operacional. As otimizações descritas aqui não são teóricas — vêm de uma operação que chegou ao topo da rede.

Em combinação com a plataforma ERPC

O suporte do SLV ao Solana v4 funciona em qualquer ambiente, e combina especialmente bem com a plataforma ERPC. A ELSOUL LABO opera um data center dedicado à Solana sob seu próprio ASN (AS200261), concedido pela RIPE NCC, como parte da plataforma ERPC — e lá você pode usar as otimizações do v4, a automação de operação do SLV e a plataforma ERPC em conjunto.

A ERPC suprime a latência induzida pela distância já na etapa de design, posicionando validadores de origem, endpoints de recepção e nós de processamento dentro de data centers premium onde os validadores Solana estão densamente concentrados. Solana RPC, WebSocket, Solana Geyser gRPC, Solana Shredstream, Direct UDP Stream (Raw Shreds), VPS, servidores bare metal, SWQoS, a Price API compatível com Pyth e Jet Analytics & Indexed RPC podem todos ser combinados na mesma plataforma. Executar um validador v4 construído com o SLV na plataforma ERPC permite combinar as otimizações do SLV com a velocidade no nível de design do ERPC, no mesmo ambiente.

Site oficial do ERPC: https://erpc.global/pt

Comece agora com os tokens da SLV AI

O agente de IA do SLV funciona com os tokens da SLV AI. Você pode começar gratuitamente — uma autorização de EUR 5 fornece 100,000 tokens, volume suficiente para experimentar habilitar o XDP, preparar o registro de BLS e operar um validador Solana v4 por meio de conversas com o agente de IA.

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

Também há suporte para conexões via tokens de API do ChatGPT e do Claude, de modo que você pode executar a SLV AI com suas próprias chaves de API.

Seu feedback molda o SLV

O SLV evolui todos os dias por meio do seu feedback. Este suporte ao Solana v4 também tomou forma a partir das vozes compartilhadas no Discord oficial da Validators DAO e da operação de validadores no topo da rede. Por favor, experimente e compartilhe conosco suas opiniões e solicitações no Discord oficial da Validators DAO.

Obrigado, como sempre. Agradecemos seu apoio contínuo ao SLV e ao ERPC.

Contato

Para dúvidas sobre o SLV e o ERPC, por favor abra um ticket de suporte no Discord oficial da Validators DAO.

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

SLV conclui o suporte ao Solana v4 — aceleração do Turbine via XDP e registro de BLS preparado para o Alpenglow, reproduzíveis por qualquer validador através de conversas com um agente de IA