ERPC adiciona HTTPS aos endpoints compartilhados de Solana Shreds e Geyser gRPC — HTTPS ou HTTP, conforme o caso de uso
A ELSOUL LABO B.V. (sede: Amsterdã, Países Baixos; CEO: Fumitake Kawasaki) e a Validators DAO, operadoras da ERPC, adicionaram suporte a HTTPS aos endpoints compartilhados de Shreds gRPC e Geyser gRPC. Junto com o transporte HTTP que sempre oferecemos, agora é possível escolher entre HTTPS e HTTP.
Isso se aplica ao Direct Shreds Connect e ao Direct Shreds Turbo, do lado do Shreds gRPC, e aos planos Standard, Premium e Burst do Stream Geyser gRPC compartilhado.
É possível optar por um endpoint HTTPS criptografado e seguro, ou por um endpoint HTTP que não envolve nenhum processamento TLS. Na terminologia gRPC, o primeiro corresponde a gRPC sobre TLS e o segundo a HTTP/2 em texto claro (plaintext). Isso cobre uma gama muito mais ampla de casos de uso — desde cargas de trabalho em que só a latência importa até cargas em que a confidencialidade do que se assina é o que mais importa.
O hostname do endpoint não muda. Apenas o scheme e a porta são diferentes: HTTPS usa a porta 443 e HTTP usa a porta 80. A troca entre os dois é feita no ERPC Web Dashboard.
HTTPS é a novidade — o HTTP existente continua sem alterações
Até agora, os endpoints de stream compartilhados da ERPC eram servidos por HTTP.
O que foi adicionado é o lado HTTPS. As conexões HTTP existentes não mudam nem em especificação nem em comportamento, e podem continuar a ser usadas exatamente como antes. Os clientes que já se conectam por HTTP não precisam fazer nada.
Não há planos de descontinuar o HTTP. Ele permanece disponível como a opção para cargas de trabalho em que a latência vem primeiro.
HTTPS — conexões criptografadas e seguras
Em um endpoint HTTPS, toda a troca entre o cliente e a ERPC é criptografada com TLS.
Tanto o conteúdo da requisição de assinatura quanto os dados de stream retornados são criptografados com TLS, de modo que normalmente o conteúdo do payload não pode ser lido ao longo do caminho. No ERPC Web Dashboard, o HTTPS é o transporte selecionado por padrão.
O handshake TLS ocorre principalmente no momento em que a conexão é estabelecida. A criptografia e a descriptografia dos dados de stream continuam depois disso, mas um stream gRPC mantido aberto por muito tempo não paga esse custo de handshake repetidamente.
HTTP — a opção de baixa latência, sem processamento TLS
Em um endpoint HTTP, não existe handshake TLS nem qualquer trabalho de criptografia ou descriptografia.
No processamento em tempo real da Solana, cada etapa de trabalho no caminho entre onde os dados são produzidos e onde a aplicação os recebe afeta a latência. Por não exigir criptografia nem descriptografia TLS, o HTTP se adequa a cargas de trabalho de baixa latência que buscam reduzir ao máximo o processamento no caminho.
O HTTP leva vantagem em configurações que restabelecem conexões com frequência, ou em configurações que não toleram nenhuma sobrecarga no caminho.
Quando a forma de um filtro de assinatura carrega significado
O HTTP é a opção de menor latência, mas, dependendo de como um projeto o utiliza, o grupo de endereços solicitado fica exposto ao longo do caminho — e, para alguns projetos, isso é um problema.
Os dados na blockchain são públicos em si. Ainda assim, quando o agrupamento fica exposto, ele pode carregar um significado que nenhum item isolado carregava sozinho.
Suponha que um projeto queira filtrar e monitorar todas as carteiras de seus clientes. A lista de endereços dessa requisição de assinatura pode ser, por si só, uma informação sensível para esse projeto. Mesmo que cada endereço individual seja público, saber qual conjunto de endereços é monitorado como um único grupo pode oferecer pistas sobre a base de clientes do projeto, sobre o que ele acompanha e sobre onde estão seus interesses de negócio.
É exatamente aqui que o endpoint HTTPS ajuda. Em troca do trabalho de criptografia e descriptografia que o TLS exige, os payloads tanto da requisição de assinatura quanto dos dados de stream são criptografados.
Latência em primeiro lugar, ou confidencialidade da assinatura em primeiro lugar? Essa decisão varia de projeto para projeto. A ERPC agora deixa essa escolha nas mãos do cliente, para ser feita conforme o próprio caso de uso.
Escopo: endpoints compartilhados
O suporte a HTTPS cobre os seguintes endpoints compartilhados:
- Direct Shreds Connect
- Direct Shreds Turbo
- Stream Geyser gRPC compartilhado — Standard
- Stream Geyser gRPC compartilhado — Premium
- Stream Geyser gRPC compartilhado — Burst
O HTTPS está habilitado nos endpoints de stream compartilhados de todas as regiões, e os endpoints HTTP existentes foram mantidos como estavam. Os endpoints compartilhados incluídos no Shreds Bundle e no ERPC Bundle também podem usar HTTPS.
Os endpoints dedicados não fazem parte desta mudança. O Geyser gRPC dedicado e os produtos Shreds dedicados mantêm seu método de conexão atual, sem alterações.
Troque no dashboard — a lista de IPs autorizados é a mesma
A troca de transporte é feita a partir da exibição do endpoint no ERPC Web Dashboard.
Alterne entre HTTPS e HTTP; a URL do endpoint correspondente ao transporte selecionado é exibida. Configure o cliente com a URL exatamente como exibida.
Os dois transportes usam a mesma lista de IPs autorizados registrados. A autenticação continua baseada no endereço IP registrado, portanto não é necessário registrar os IPs novamente para migrar para HTTPS, nem adicionar token ou cabeçalho Authorization.
Produtos Shreds compartilhados da ERPC continuam após o fim do Jito ShredStream
O Jito ShredStream encerra o serviço em 5 de setembro de 2026. Já os produtos Shreds compartilhados da ERPC continuam após essa data.
Direct Shreds Connect e Direct Shreds Turbo — ambos contemplados por este suporte a HTTPS —, junto com os planos multi-IP do Shreds Bundle e o Direct Shreds Connect incluído no ERPC Bundle, permanecem todos disponíveis depois de 5 de setembro.
Para deixar claro: o encerramento de serviço em 5 de setembro, anunciado em 21 de agosto de 2026, se aplica aos produtos Shredstream dedicados e ao Stream Bundle. Os produtos Shreds compartilhados não estão incluídos nele. A orientação de migração para os clientes de planos dedicados continua sendo tratada individualmente, como antes.
Para os projetos que estão revisando a forma como recebem Shreds, este é um momento natural para avaliar as opções. Ficaremos felizes se quiserem testá-las.
Teste com cobrança por hora, a partir de uma hora
Os endpoints compartilhados da ERPC estão disponíveis a partir de uma hora, com cobrança por hora.
Sem se comprometer com um plano mensal, é possível testar HTTPS e HTTP na carga de trabalho real e verificar, no próprio ambiente, como latência e confidencialidade se equilibram.
Comece com uma avaliação curta e escolha o plano com base no que for medido.
Um produto UDP Forwarding renovado chega em breve
Para o UDP Forwarding — que simplifica o próprio caminho de entrega dos Shreds —, um produto renovado chega em breve.
O objetivo é um lineup em que se possa escolher o método de entrega adequado à tarefa: UDP para cargas de trabalho que colocam a baixa latência acima de tudo, e Shreds gRPC para assinatura de stream pela interface gRPC existente.
As regiões suportadas, o preço, as especificações detalhadas e a data oficial de lançamento serão anunciados assim que estiverem prontos.
Uma infraestrutura que se escolhe conforme a tarefa
A ERPC não avalia o desempenho da infraestrutura Solana apenas pelas especificações do servidor. A proximidade com a fonte de dados, o caminho de rede, o hardware, o OS e o kernel, e o método final de entrega ao usuário são projetados em conjunto, como um único sistema de baixa latência.
Este suporte a HTTPS amplia a escolha dentro desse método final de entrega. Não existe uma única opção mais rápida que sirva a todos os projetos; o peso dado à latência em relação à confidencialidade depende da natureza do produto.
Em caso de dúvidas, entre em contato pelo chat de suporte no ERPC Web Dashboard.
