Vencendo o jogo dos milissegundos: shreds, LaserStream e a vantagem na Solana

O que são shreds?

Os shreds são a unidade fundamental que viabiliza a propagação de dados de alto desempenho da Solana, oferecendo acesso antecipado às mudanças de estado on-chain.

A Solana foi projetada para oferecer velocidade e throughput máximos. Para isso, ela não pode transmitir blocos pela rede como uma única unidade de grande porte. Em vez disso, os blocos são divididos em pacotes menores conhecidos como shreds — as unidades atômicas de propagação de dados na Solana. 

Esses shreds representam partes dos dados das transações antes de serem montados em um bloco. Cada shred tem aproximadamente 1,2 KB e é otimizado para caber na Unidade Máxima de Transmissão (MTU) dos pacotes de rede padrão, garantindo uma entrega extremamente rápida e sem fragmentação. 

Há dois tipos de shreds:

Shreds de dados

Os shreds de dados encapsulam os dados essenciais das transações de um bloco, divididos em partes de tamanho fixo. Eles incluem lotes de entradas serializadas, que são grupos de transações prefixados por uma contagem para permitir um processamento eficiente.

Shreds de codificação

Os shreds de codificação oferecem redundância usando codificação de apagamento Reed-Solomon, uma técnica de correção antecipada de erros que gera dados de paridade. Isso permite reconstruir shreds ausentes ou corrompidos. Os shreds de codificação são organizados em conjuntos de Correção Antecipada de Erros (FEC) junto com os shreds de dados, normalmente em proporções equilibradas (por exemplo, 32 shreds de dados para 32 shreds de codificação), para tolerar até 50% de perda de pacotes. Os líderes podem ajustar essa proporção de acordo com as condições da rede para manter uma alta confiabilidade.

Como os shreds são propagados na Solana?

O processo começa com o líder (ou seja, o validador atualmente responsável por produzir blocos) agrupando e serializando transações em entradas. Essas entradas são então divididas, ou fragmentadas, em segmentos menores chamados shreds. Todos os shreds são assinados pelo líder usando um sistema legado (ou seja, assinando cada shred individualmente) ou um esquema baseado em Merkle (ou seja, assinando a raiz de Merkle de todo o conjunto FEC), conforme definido pela especificação de shreds da Solana. Isso garante a autenticidade e a integridade dos dados. 

Os shreds são enviados a outros validadores por meio do Turbine, o sistema de propagação multicamada e baseado em distribuição em leque da Solana. No Turbine, o líder transmite os shreds para um node raiz, que os distribui às camadas seguintes de validadores em uma estrutura semelhante a uma árvore. Cada camada encaminha os dados para a próxima, com uma distribuição em leque de 200 nodes por camada, normalmente percorrendo de 2 a 3 saltos, dependendo do número de validadores ativos. Essa estrutura em árvore minimiza o uso de largura de banda e, ao mesmo tempo, distribui as transações por toda a rede em milissegundos.

O embaralhamento ponderado por stake prioriza a entrega aos validadores com mais stake. Primeiro, o Turbine classifica os validadores pela quantidade de stake que possuem (ou seja, pelo peso do stake). Validadores com mais stake aparecem antes nessa lista e, após um embaralhamento determinístico, tendem a ficar nas primeiras camadas da árvore, mais próximos do líder. Portanto, menos saltos significam menor latência. Assim, validadores com mais stake recebem os shreds mais cedo.   

Observação: no futuro, o Turbine será substituído pelo Rotor quando o Alpenglow for implementado. Mesmo com essas mudanças, o stake de um validador continuará influenciando para quais peers os validadores transmitirão.

Como os shreds são remontados em blocos?

Depois de recebidos por um validador, os shreds são remontados. Primeiro, suas assinaturas são verificadas para confirmar a autenticidade. Em seguida, a codificação de apagamento Reed-Solomon é usada para reconstruir shreds de dados ausentes ou corrompidos a partir dos shreds de codificação disponíveis no conjunto FEC. 

Depois, os shreds de dados reconstruídos são desfragmentados. Ou seja, seus payloads são concatenados em ordem usando os índices dos shreds para recompor os lotes de entradas serializadas. 

Esses lotes são então desserializados em transações e entradas individuais, que podem ser reunidas em um bloco completo.

Por que os shreds são importantes? 

Os shreds são importantes porque reduzem a janela de reação em uma rede na qual o tempo é crucial. 

Os shreds são essenciais para aproveitar as vantagens de alto desempenho da Solana, especialmente em aplicações sensíveis à latência, como trading de alta frequência, mesas de solicitação de cotação (RFQ), mecanismos de liquidação e atualizações de oráculos. 

Os shreds oferecem a visibilidade mais antecipada possível de eventos on-chain emergentes. Isso é diferente da maioria das outras blockchains, nas quais as aplicações precisam aguardar a produção e a confirmação completas do bloco, o que pode adicionar atrasos de centenas de milissegundos a vários segundos. 

Trabalhar com shreds brutos pode ser complicado, pois o receptor precisa verificar sua autenticidade, reconstruir shreds de dados ausentes, desfragmentá-los e desserializá-los em transações e entradas e, por fim, analisá-los em busca de eventos acionáveis, como swaps ou alterações em contas.

Se você quer a vantagem de latência dos shreds sem precisar criar esse pipeline, o Preprocessed Transactions os desfragmenta para você e transmite as transações assinadas por WebSocket até 8ms antes do nível de compromisso processed.

No entanto, essa “prévia” de transações pendentes e atualizações de contas oferece uma vantagem incomparável, traduzida diretamente em taxas de sucesso maiores em cenários competitivos.

Por exemplo, um bot de liquidação que monitora índices de garantia poderia detectar e agir sobre uma posição vulnerável usando shreds muito antes de concorrentes que utilizam métodos mais lentos, como WebSockets, e assim vencer a liquidação. 

Da mesma forma, traders de arbitragem que identificam ineficiências de mercado e agregadores de DEX de baixa latência que fornecem cotações podem se beneficiar dessa vantagem, pois milissegundos determinam a rentabilidade.

A hierarquia de latência dos shreds

É importante observar que a latência dos shreds não é uniforme entre todas as fontes.

Validadores com muito stake

Validadores com uma quantidade significativa de stake recebem a maior prioridade na árvore de propagação do Turbine. Eles geralmente recebem shreds diretamente do líder ou nas primeiras camadas de distribuição em leque, beneficiando-se da Qualidade de Serviço Ponderada por Stake (SWQoS).

Validadores com stake

Validadores com uma quantidade modesta de stake enfrentam atrasos moderados devido à prioridade mais baixa na fila de propagação, pois os shreds precisam percorrer saltos adicionais. A participação deles no consenso garante acesso confiável, embora a latência possa variar um pouco de acordo com a posição na rede e a distribuição atual de stake. Em comparação com validadores com muito stake, validadores com pouco stake não são ideais para operações ultracompetitivas e sensíveis ao tempo.

Validadores sem stake

Validadores sem stake não contam com as vantagens de qualidade de serviço dos nodes com stake e não são adequados para transmitir dados da Solana em tempo real em operações críticas de latência. Eles são os últimos a receber shreds na distribuição em leque do Turbine.

Quanto mais cedo você estiver na árvore, mais tempo terá para reagir antes que o restante da rede o alcance. 

Variabilidade global 

É importante destacar que o Turbine não depende da localização. A propagação global pode ampliar a variabilidade da latência, pois a distância física e as condições da rede introduzem atrasos além dos saltos do Turbine. 

Por exemplo, shreds que viajam entre regiões (como de um líder nos EUA para validadores na região Ásia-Pacífico) podem sofrer atrasos devido ao roteamento entre continentes, retransmissões de pacotes ou até problemas de peering — mesmo para validadores com muito stake nas primeiras camadas do Turbine.

Essa distribuição geográfica cria oportunidades de otimização. Embora um único validador com muito stake possa se destacar localmente, ele pode apresentar atraso globalmente se não estiver em uma posição ideal. Isso pode ser mitigado por uma rede distribuída de shreds que agregue os shreds mais rápidos possíveis de várias fontes, reduzindo a variação e alcançando velocidades de ingestão consistentes. Em cenários globais, um sistema desse tipo poderia superar de forma consistente um validador com stake de ponta.

Acessar shreds de forma confiável a partir de fontes otimizadas é essencial para manter a vantagem competitiva de desenvolvedores que criam sistemas críticos de latência. No entanto, isso exige uma infraestrutura robusta para lidar de forma eficaz com recuperação, verificação e distribuição global. Além disso, a maioria das ferramentas populares de streaming de dados em tempo real da Solana ainda não utiliza shreds.

Streaming de dados na Solana

Na Solana, desenvolvedores que buscam transmitir dados em tempo real têm algumas opções, cada uma com seus próprios compromissos em termos de latência, confiabilidade e complexidade:

Webhooks

Webhooks permitem atualizações orientadas a eventos, enviando dados à sua aplicação quando ocorrem alterações em uma conta ou programa específico. Eles são fáceis de integrar via programação e podem até ser configurados sem escrever código diretamente no painel da Helius. Os desenvolvedores podem transmitir dados legíveis e analisados para tipos específicos de transações, payloads brutos de transações e até enviar essas atualizações diretamente a um canal específico do Discord como uma mensagem formatada.

Embora os webhooks sejam altamente confiáveis e usados por muitas empresas de destaque na Solana, eles enviam notificações depois que uma transação é confirmada. Isso significa que os webhooks podem ficar centenas de milissegundos atrás dos dados no nível dos shreds, tornando-os lentos demais para operações críticas de latência, como trading de alta frequência ou liquidações.

WebSockets padrão

A API JSON RPC da Solana oferece suporte a assinaturas de WebSocket, como accountSubscribe para alterações em contas, logSubscribe para logs de transações e programSubscribe para eventos de programas. WebSockets mantêm uma conexão persistente entre um cliente e um provedor de RPC, transmitindo atualizações assim que as transações e alterações em contas são processadas. WebSockets são bidirecionais e adequados para monitorar contas ou eventos específicos em tempo real, reduzindo a sobrecarga de polling.

No entanto, assim como os webhooks, os WebSockets entregam dados após a remontagem dos shreds (ou seja, nos níveis de compromisso processed, confirmed ou finalized), adicionando de 400ms a 30s de latência, dependendo do nível de compromisso. 

WebSockets também são considerados um tipo de conexão frágil, o que significa que as conexões podem cair por diversos problemas e exigir uma lógica de novas tentativas personalizada. As desconexões podem causar perda permanente de dados, a menos que sejam complementadas por polling, o que prejudica a confiabilidade em tempo real. 

Enhanced WebSockets

Os Enhanced WebSockets representam uma melhoria significativa em relação aos WebSockets padrão, oferecendo várias otimizações de desempenho e recursos avançados de filtragem. Mais especificamente, a análise aprimorada de eventos e a redução de ruído facilitam o uso pelos desenvolvedores em produção.

Os Enhanced WebSockets podem reduzir a latência em comparação com os WebSockets padrão e são excelentes para aplicações gerais de streaming. Por exemplo, há uma diferença perceptível de desempenho ao transmitir dados do Pump AMM com Enhanced WebSockets em comparação tanto com WebSockets padrão quanto com webhooks. 

No entanto, os Enhanced WebSockets ainda entregam fundamentalmente os dados após a remontagem dos shreds. Novamente, isso limita sua utilidade para aplicações nas quais cada milissegundo conta. Além disso, apesar das melhorias, eles não oferecem replay nem failover automáticos, exigindo o tratamento manual de lacunas. 

Yellowstone gRPC

O Yellowstone gRPC é um protocolo de streaming de baixa latência entre validador e cliente que pode oferecer acesso a dados no nível dos shreds. Isso o torna significativamente mais rápido que WebSockets e webhooks, pois ele pode entregar atualizações mais rapidamente no respectivo nível de compromisso. 

O Yellowstone oferece streaming bidirecional com criação e cancelamento imediatos de assinaturas, além de recursos avançados de filtragem para controlar com precisão quais dados você recebe em resposta a atualizações específicas de transações, contas ou programas.

O Yellowstone é ideal para usuários que não querem limites de taxa nem créditos e precisam de hardware isolado garantido para configurações de nodes personalizadas. No entanto, há vários compromissos importantes:

1. Sobrecarga de infraestrutura

Você precisa ter seu próprio node dedicado para aproveitar todo o potencial do Yellowstone gRPC. Isso exige acesso a hardware, configuração adequada, gerenciamento contínuo desse hardware e conhecimento especializado para depurar problemas relacionados a ele.

2. Variabilidade da latência

O fato de o Yellowstone gRPC poder entregar dados no nível dos shreds não significa que isso acontecerá da forma mais otimizada. A latência pode variar de acordo com o provedor e com o pareamento do seu node dedicado com fontes otimizadas para shreds (ou seja, validadores com muito stake). O pareamento com validadores de stake baixo a moderado significa que eles não ficarão de forma consistente na primeira camada do Turbine. Assim, você ainda estará em uma posição posterior no fluxo de muitos shreds.

3. Riscos de falha

Depender de um único node dedicado cria um ponto único de falha, agravado pelo fato de que o Yellowstone gRPC não oferece recursos nativos de replay.

4. Exigências de recursos

Sobrecarregar um node dedicado com chamadas RPC intensivas enquanto transmite dados pelo Yellowstone pode prejudicar o desempenho. 

Por muito tempo e para muitas equipes, o Yellowstone gRPC foi o principal serviço de streaming de dados em tempo real na Solana. Ele é rápido e adequado para usuários avançados, mas é difícil operacionalizá-lo para obter uma cobertura global, consistente e de baixa latência sem acesso a uma frota de nodes dedicados ao redor do mundo.

LaserStream

O LaserStream combina a velocidade da ingestão no nível dos shreds com a confiabilidade e o alcance de um serviço distribuído globalmente, sem o custo nem a dor de cabeça operacional de executar vários nodes dedicados. 

O LaserStream consegue isso por meio de:

• Ingestão de várias fontes: o LaserStream ingere os shreds de menor latência, superando de forma consistente os concorrentes no mundo todo.
• Cobertura global: o LaserStream está disponível em várias regiões do mundo, permitindo que os desenvolvedores usem o endpoint mais próximo da própria infraestrutura. Cada região executa vários servidores para oferecer redundância, com failover automático.
• Zero lacunas: o replay histórico do LaserStream permite que os desenvolvedores reproduzam dados recentes da blockchain de até 48 horas atrás. Isso é útil para lidar com desconexões e garantir a continuidade dos dados. 
• Uma experiência otimizada para desenvolvedores: o LaserStream substitui diretamente o Yellowstone gRPC — sem migrações, sem nova sintaxe e sem dores de cabeça.

Em resumo, o LaserStream é uma evolução escalável, de baixa latência e tolerante a falhas do Yellowstone gRPC e dos WebSockets. Ele disponibiliza eventos on-chain de forma consistente assim que acontecem na rede, sem exigir milhões em stake nem que você opere uma infraestrutura de alto desempenho por conta própria. 

O LaserStream é a forma mais fácil de aproveitar o poder dos shreds para streaming de dados com latência ultrabaixa na Solana.

Clientes e desempenho

O LaserStream tem clientes disponíveis em Go, Rust e JavaScript/TypeScript. Esses clientes realizam replay automático após desconexões, pois acompanham continuamente qual slot foi transmitido. Se ocorrer uma desconexão por qualquer motivo, o cliente se reconectará automaticamente e retomará o streaming no último slot processado.

O cliente JavaScript do LaserStream é particularmente interessante porque usa bindings nativos do Rust. Por isso, o cliente alcança um throughput de 1,3 GB/s. Isso representa uma melhoria de 40 vezes em relação ao cliente JavaScript atual do Yellowstone gRPC, que atinge no máximo 30 MB/s. 

À medida que a Solana continua crescendo, o cliente JavaScript do Yellowstone gRPC terá dificuldade para acompanhar. A margem de desempenho do cliente JavaScript do LaserStream garante que sua aplicação possa escalar com segurança junto com a rede à medida que a demanda aumenta. 

Resultados no mundo real

A DFlow, um agregador de DEX de baixa latência, integrou recentemente o LaserStream para alimentar seu mecanismo de preços. A decisão de fazer a integração se baseou na capacidade de escalar globalmente sem precisar se preocupar com nodes dedicados e de economizar recursos de engenharia para se concentrar no roteamento e no código de negócios. 

Desde a integração, a DFlow teria economizado mais de oito horas de trabalho recorrente de engenharia, mantido 100% de uptime com streaming de dados ininterrupto e melhorado a velocidade das cotações com confirmações de transações mais rápidas. 

Streaming mais rápido, hoje.

Milissegundos não representam apenas latência — representam oportunidades. Com o LaserStream, você não apenas acompanha a rede. Você fica à frente dela. 

Quer dados em menos de um segundo para trading, liquidações ou oráculos? Use o LaserStream e acesse os dados mais rápidos disponíveis da Solana. 

Como alternativa, se você é um usuário avançado e tem interesse na entrega de shreds brutos, entre em contato conosco preenchendo este formulário.

Outros recursos

• LaserStream
• Módulo de shreds do Agave
• Especificação de shreds da Solana