ERPC lança Solana Stream SDK v4.0.0 com processamento de Shreds UDP e reconexão gRPC mais rápidos

ERPC lança Solana Stream SDK v4.0.0 com processamento de Shreds UDP e reconexão gRPC mais rápidos

ERPC lança Solana Stream SDK v4.0.0 com processamento de Shreds UDP e reconexão gRPC mais rápidos
ELSOUL LABO B.V. e Validators DAO lançaram oficialmente o Solana Stream SDK v4.0.0 em 6 de novembro de 2026. Trata-se de um SDK de código aberto para lidar com dados de streaming da Solana. Benchmarks locais mediram um processamento interno de Shreds UDP em Rust cerca de 108 vezes mais rápido e uma taxa de processamento da fila de eventos TypeScript cerca de 4 vezes maior. O Geyser gRPC também retoma a recepção de atualizações mais rapidamente após uma desconexão. O SDK é gratuito, com exemplos em Rust e TypeScript para ajudar os desenvolvedores a começar.
Aproveitar a entrega de dados de baixa latência em uma aplicação também depende da rapidez com que os dados recebidos são processados. A versão 4.0.0 torna mais eficiente o processamento interno após a chegada dos dados e melhora o restabelecimento da conexão após desconexões. Seu uso com o ERPC Shreds UDP Forwarding Premium permite aos desenvolvedores melhorar tanto o caminho de entrega quanto a implementação da recepção em suas aplicações Solana.

Melhorias de processamento e recuperação medidas em três testes

Comparação do processamento interno UDP em Rust, da fila de eventos TypeScript e da reconexão gRPC no Solana Stream SDK v4.0.0
No caminho de recepção UDP em Rust, a v4 acelera a decodificação dos datagramas, a inserção em um buffer interno e o deshredding, que reconstrói os dados a partir dos Shreds. Ela reduz a sobrecarga de processamento ao revisar a limpeza do estado interno e as leituras do relógio que eram repetidas para cada pacote, preservando os períodos de retenção dos dados. Na comparação, o tempo de processamento interno por datagrama caiu de 94.236 ns para 855–881 ns, uma aceleração de aproximadamente 108 vezes.
O benchmark foi executado em um Mac com chip Apple da série M, processando 403.200 datagramas distribuídos por 300 slots em cada execução. Os resultados comparam as medianas de cinco execuções. A medição abrange o caminho interno decode→insert→deshred. Ela exclui o tempo de entrega pela rede e o processamento posterior na aplicação do usuário. Reduzir o trabalho necessário para reconstruir os Shreds recebidos ajuda os desenvolvedores a destinar mais recursos computacionais à lógica da aplicação.
Os exemplos e projetos iniciais de Geyser gRPC em TypeScript reduzem a espera enquanto ainda há eventos na fila, permitindo extrair os dados recebidos de forma mais eficiente. Em um teste restrito à fila, que processou dois milhões de eventos no Node.js 24, a taxa de processamento aumentou de 5,7–7,4 milhões para 24,8–29,4 milhões de eventos por segundo, uma melhoria de aproximadamente 4 vezes.
No Geyser gRPC, foram atualizados o cliente que gerencia a reconexão e o intervalo antes da primeira nova tentativa. Em um teste que provocou 20 desconexões em um servidor tonic local, a mediana do intervalo entre as atualizações recebidas antes e depois de cada desconexão caiu de 552 ms com o runner 3.0 para 103 ms com o runner 4.0. Essa medição representa o intervalo até a retomada das atualizações no ambiente de teste local.
Esses três resultados vêm de testes diferentes, com escopos e condições distintos. Eles mostram, respectivamente, as melhorias no processamento interno em Rust, na fila de eventos TypeScript e na reconexão gRPC. Os detalhes da implementação e as condições dos testes estão disponíveis na PR #129, indicada nos links relacionados.

Suporte ao Alpenglow mantido e clientes atualizados

O suporte ao Alpenglow foi introduzido na v3.0.0. A versão 4.0.0 mantém a distinção entre os marcadores de bloco, que representam as atualizações de cabeçalho, rodapé e bloco pai, e as entradas, que contêm as transações. As aplicações podem tratar as informações sobre a estrutura dos blocos separadamente das entradas que precisam processar.
A versão 4.0.0 atualiza os clientes para Agave 4.4.1 e Yellowstone gRPC 17.x. Durante a reconexão, um evento Disconnected pode informar dados de identificação do conteúdo recebido parcialmente, juntamente com a posição de retomada. Isso fornece às aplicações as informações necessárias para implementar seu próprio tratamento de dados retransmitidos em duplicidade e de dados recebidos apenas em parte.
A migração da v3 para a v4 preserva as definições protobuf do Geyser, ao mesmo tempo que atualiza os eventos de reconexão e os tipos de mensagens e transações Solana usados em Rust. O guia de migração publicado descreve as mudanças nos manipuladores de eventos e nas versões das dependências.

Rust para UDP, Rust e TypeScript para gRPC

O pacote Rust publicado solana-stream-sdk e o pacote TypeScript @validators-dao/solana-stream-sdk estão disponíveis na v4.0.0. As linguagens de programação compatíveis com cada tipo de conexão estão listadas abaixo.
Tipo de conexãoLinguagens compatíveis
Shreds UDPRust
Geyser gRPCRust e TypeScript
Shreds gRPCRust e TypeScript
Use o cliente Rust para receber Shreds por UDP. O exemplo e o projeto inicial de UDP em Rust usam o SDK v4.0.0 publicado e permitem testar a recepção de dados, a reconstrução de dados a partir dos Shreds e a detecção de instruções de um programa que você deseja monitorar. Altere o programa monitorado e o processamento após a detecção para usar esse material como ponto de partida da sua própria aplicação.
Para desenvolver em TypeScript, você pode usar Geyser gRPC ou Shreds gRPC. As melhorias da fila de eventos desta versão estão incluídas nos exemplos e projetos iniciais de Geyser gRPC. Escolha a implementação publicada que corresponde à sua linguagem e ao método de entrega utilizado.

Aproveitar o Shreds UDP Forwarding Premium

O ERPC Shreds UDP Forwarding Premium conecta vários nós em uma malha dentro de cada região e encaminha a primeira cópia de cada Shred recebida por essa malha. Tanto o momento da chegada pelo caminho de entrega quanto o tempo de reconstrução no SDK após a chegada influenciam a rapidez com que os dados recebidos podem ser utilizados. As melhorias da recepção UDP em Rust podem ser aplicadas, no lado receptor, aos dados entregues pelo Premium.
Na comparação realizada em Frankfurt em 30 de outubro de 2026, Standard e Premium foram capturados simultaneamente durante 120 segundos em uma mesma máquina e com o mesmo relógio. Os payloads UDP de conteúdo idêntico foram pareados a partir da captura pcap. O Premium chegou primeiro em 98% desse conjunto de correspondências, e a mediana da diferença de chegada foi de 1,78 ms. Dos payloads observados no Standard, 93,9% também foram observados no Premium.
Comparação de primeiras chegadas entre Shreds UDP Forwarding Premium e Standard nas mesmas condições em Frankfurt
O gráfico do Premium mostra as diferenças nos tempos de chegada entre os caminhos de entrega, enquanto o gráfico do SDK mostra o processamento interno no receptor e o restabelecimento da conexão. Em uma aplicação real, registrar tanto a chegada dos pacotes quanto o momento em que uma instrução relevante é detectada permite verificar quanto da vantagem na entrega se mantém no resultado do processamento.

Compare no seu ambiente com cobrança por hora e exemplos

O Shreds UDP Forwarding Premium está disponível com cobrança por hora a € 1,39 por hora. Comece a usar o serviço pelo dashboard e verifique a recepção com o projeto inicial de UDP em Rust. Manter a mesma região, o mesmo servidor receptor e a mesma carga de trabalho da aplicação permite avaliar as diferenças nos tempos de chegada separadamente do tempo de processamento após a recepção.
Primeiro, registre seu endereço IPv4 público e sua porta UDP no dashboard e permita o tráfego de entrada das origens indicadas. Depois de verificar a recepção de pacotes e a reconstrução de dados com o projeto inicial de UDP em Rust, inclua na avaliação os programas que deseja monitorar e o processamento real da sua aplicação. Combine os exemplos com o serviço de entrega para medir o tempo da recepção até a detecção no seu próprio ambiente.