Gulf Stream da Solana: mais mempool, mais problemas

Insights práticos

• O termo "Gulf Stream" pode ser definido, de forma ampla, como o processo que ocorre desde o momento em que um node recebe uma transação na rede até ela chegar ao líder do slot atual e ser recebida pelo Fetch Stage da TPU (Unidade de Processamento de Transações).
• A Solana se destaca porque foi projetada desde o início para operar sem mempool. Ao contrário de blockchains mais tradicionais, que usam protocolos gossip para propagar transações amplamente pela rede, a Solana encaminha todas as transações para um validator líder predeterminado, conhecido como líder, em cada slot. O líder muda a cada 4 slots, e o cronograma de líderes é conhecido antecipadamente por todos os nodes ativos da rede, garantindo o encaminhamento eficiente das transações.
• Por padrão, as transações da Solana precisam incluir um blockhash recente, que os desenvolvedores podem solicitar facilmente por meio de uma simples chamada de API. Um blockhash recente é válido por até 150 slots, aproximadamente 1 minuto. Após esse período, ele expira, e as transações que fazem referência a ele são descartadas pela rede. Isso garante que transações não processadas não permaneçam indefinidamente. Blockhashes recentes também ajudam na desduplicação de transações. Os desenvolvedores ainda podem usar métodos para adicionar nonces duráveis.
• As transações no Gulf Stream são codificadas e enviadas ao líder por streams QUIC. A adoção do QUIC no fim de 2022 foi uma atualização significativa da rede, substituindo as conexões UDP usadas anteriormente. O principal motivo dessa mudança foi melhorar a capacidade da rede de filtrar spam. No entanto, a migração para QUIC gerou algumas controvérsias, já que a Solana registrou níveis de atividade sem precedentes ao longo de 2024.
• A introdução da Qualidade de Serviço Ponderada por Stake (SWQoS) no início de 2024 marcou uma mudança profunda na forma como as transações chegam ao líder pelo Gulf Stream. Agora, os líderes priorizam mensagens de transação encaminhadas por outros validators com stake. Especificamente, 80% da capacidade de um líder (2.000 conexões) é reservada para pares com stake, enquanto os 20% restantes (500 conexões) são destinados a mensagens de transação de nodes sem stake.
• Atualmente, mais de 80% do stake na Solana está alocado a validators que executam o cliente Jito-Solana em vez do cliente Agave original. A Jito introduz um leilão de espaço em bloco fora do protocolo, aumentando ainda mais a complexidade de como as transações chegam ao líder. Especificamente, o relayer da Jito adiciona uma “lombada” de 200 milissegundos para desacelerar o fluxo de mensagens de transação recebidas, dando aos buscadores tempo suficiente para enviar bundles.

Introdução

O termo "Gulf Stream" surgiu em uma série de publicações introdutórias escritas pela equipe fundadora da Solana em 2019, nas quais muitos dos mecanismos mais inovadores da Solana receberam nomes inspirados na aviação. Nessas publicações, Gulf Stream foi definido como o “protocolo de encaminhamento de transações sem mempool” da Solana. No entanto, hoje uma busca pelo termo “Gulf Stream” na base de código da Solana retorna apenas uma menção trivial.

No contexto mais amplo do ciclo de vida das transações da Solana, “Gulf Stream” pode ser entendido como todo o processo que ocorre desde o momento em que uma transação é recebida por um node da rede, normalmente um RPC, até chegar ao líder do slot atual, ou seja, quando é recebida pelo “fetch stage” da TPU. Também podemos conceituar o Gulf Stream como a imagem espelhada do Turbine, o mecanismo de propagação de blocos da Solana, pois o Gulf Stream define como as transações chegam ao líder, enquanto o Turbine define como as transações processadas saem dele.

Primeiro, pode ser útil definir os nodes RPC (Chamada de Procedimento Remoto) no contexto da Solana. Esses nodes podem ser vistos como gateways para interagir com a rede e ler seus dados. Eles atuam como intermediários entre os usuários e os validators da Solana. Os RPCs executam o mesmo software que os validators completos, mas com configurações diferentes, o que permite simular transações com precisão e manter uma visão atualizada do estado atual, o bank. No entanto, os nodes RPC não têm stake e, portanto, não participam do consenso. Sem stake, eles não podem votar nem criar blocos. Essa configuração é diferente da encontrada em muitas outras blockchains, nas quais validators e nodes RPC normalmente são os mesmos. Em relação ao Gulf Stream, podemos resumir o papel do RPC da seguinte forma: receber transações por HTTP, convertê-las para QUIC — falaremos mais sobre isso adiante —, consultar o endereço e as informações de porta do líder atual usando o cronograma de líderes e encaminhar a transação aos líderes atual e seguinte.

Desde o lançamento da rede, o Gulf Stream passou por pelo menos duas grandes atualizações: QUIC e QoS Ponderada por Stake, que serão abordadas em detalhes mais adiante neste artigo. Essa também é, possivelmente, a parte do protocolo principal que mais sofreu pressão nos últimos anos devido ao volume sem precedentes de tráfego na rede Solana. Para contextualizar, quando um validator se torna líder, ele pode esperar um pico no tráfego de entrada, que ultrapassa um gigabyte por segundo conforme toda a rede direciona pacotes para ele. Lidar com volumes tão intensos de entrada de dados é um enorme desafio de engenharia.

Mais mempool, mais problemas

A definição original de Gulf Stream feita pela equipe fundadora enfatiza a ausência de uma mempool. Podemos definir uma mempool — literalmente, um “pool de memória” — como um conjunto de transações enviadas por usuários que aguardam processamento pela rede. Em geral, essas transações não são criptografadas nem protegidas enquanto aguardam publicamente. Elas são propagadas por toda a rede usando um protocolo gossip. Dependendo da rede, transações assinadas podem permanecer na mempool por tempo indeterminado até que as condições para sua execução sejam atendidas. Isso ocorre especialmente com transações que definiram uma taxa de transação — preço por unidade de computação — muito abaixo da faixa normal de preços do mercado. Em casos extremos, essas transações podem levar dias ou semanas para serem executadas se as condições da rede não favorecerem sua inclusão em um bloco.

Esse cenário não é possível na Solana, que não só não possui um conceito nativo de mempool, como também exige que todas as mensagens de transação incluam um blockhash recente. Os desenvolvedores podem solicitar facilmente blockhashes recentes por meio de uma chamada à API JSON RPC usando o método getLatestBlockhash. Esse blockhash é incorporado à mensagem de transação e permanece válido por até 150 slots, aproximadamente 1 minuto, considerando que cada slot tem um tempo-alvo de 400 milissegundos. Após 150 slots, o blockhash expira, e as transações que fazem referência a ele são descartadas pela rede. Por padrão, os RPCs tentam encaminhar as transações a cada 2 segundos, mas, assim que o blockhash recente expira, a transação é descartada, garantindo que nunca seja executada on-chain.

O blockhash recente também é uma forma de detectar e remover transações duplicadas, algo que, em outras redes, seria feito exigindo a inclusão de um nonce, um número usado apenas uma vez. Embora existam métodos que permitem aos desenvolvedores adicionar nonces duráveis às transações da Solana em cenários específicos, não é obrigatório incluir nonces em uma transação padrão da Solana.

O sistema Gulf Stream da Solana é viável porque todos os nodes ativos sempre conhecem antecipadamente o cronograma de líderes. Os nodes atualizam seus cronogramas de líderes sempre que a altura do slot cruza o limite de uma época, aproximadamente a cada 2 dias. O cronograma de líderes de uma época é calculado a partir do estado do ledger no início da época anterior. O processo algorítmico para gerar esse cronograma é o seguinte:

• Usar periodicamente a altura de tick da prova de história (PoH), ou seja, um contador monotonicamente crescente, como seed para um algoritmo pseudoaleatório estável.
• Nessa altura, coletar uma amostra do bank com todas as contas que têm stake e identidades de líder que votaram dentro de uma quantidade de ticks configurada pelo cluster. Essa amostra é chamada de conjunto ativo.
• Ordenar o conjunto ativo pelo peso do stake.
• Usar uma seed aleatória para selecionar nodes ponderados por stake e criar uma ordenação ponderada por stake.
• Essa ordenação se torna válida após uma quantidade de ticks configurada pelo cluster.

Fonte: documentação oficial da Solana

A ponderação por stake garante que nodes confiáveis com stakes maiores tenham mais chances de serem escolhidos como líder com maior frequência, enquanto nodes com stakes menores sejam escolhidos com menos frequência ou nem sejam escolhidos. 

‍A alocação de recursos ponderada por stake é um tema recorrente em todo o protocolo principal da Solana, incluindo recompensas de votação, árvores Turbine, cronogramas de líderes e a rede gossip*. Até mesmo o Gulf Stream emprega ponderação por stake, como veremos mais adiante neste artigo.

Uma observação sobre QUIC

A primeira grande atualização do Gulf Stream ocorreu no fim de 2022 , com a adoção do protocolo de rede QUIC para transmitir mensagens de transação ao líder. Essa atualização foi motivada pelas interrupções na rede causadas por ataques DDoS e transações de spam que sobrecarregaram a blockchain durante mints de NFT. Após a integração completa do QUIC à Mainnet-Beta na versão 1.13.4, a estabilidade da rede melhorou.

Anteriormente, a Solana usava o protocolo de rede UDP (Protocolo de Datagrama do Usuário) para enviar transações dos nodes RPC ao líder atual. Embora rápido e eficiente, o UDP não estabelece conexões e não oferece controle de fluxo nem confirmações de recebimento. Por isso, não há uma forma eficaz de desestimular ou mitigar comportamentos abusivos. Para controlar o tráfego da rede, o protocolo de ingestão de transações do validator, ou seja, o Fetch Stage da TPU, foi reimplementado com QUIC.

Desenvolvido inicialmente pelo Google em 2012, o QUIC busca oferecer o melhor do TCP e do UDP. Ele possibilita uma comunicação rápida e assíncrona, semelhante ao UDP, mas com as sessões seguras e as estratégias avançadas de controle de fluxo do TCP. Isso permite impor limites a fontes individuais de tráfego para que a rede se concentre no processamento de transações legítimas. O QUIC também possui o conceito de streams separados. Assim, se uma transação for descartada, ela não bloqueará as demais. O Google tem sido o principal impulsionador da adoção do QUIC em toda a Web2. As conexões com os servidores do Google são estabelecidas por QUIC, o que significa que muitos aplicativos do ecossistema Google, como Hangouts, Gmail e YouTube, são baseados em QUIC. Como observação adicional, QUIC não é uma sigla, mas o nome real do protocolo. 

Dito isso, a eficácia da implementação do QUIC na Solana está aberta a debate. Durante picos de tráfego intenso na rede, os validators podem ficar sobrecarregados com handshakes QUIC. É justo dizer que essa não foi a solução definitiva que alguns esperavam originalmente para resolver os problemas de congestionamento no nível da rede. Vale observar que o QUIC tem baixa adoção no setor de blockchain fora da implementação da Solana. Alguns membros da comunidade de validators da Solana criticaram abertamente o protocolo por considerarem que a adoção do QUIC foi um passo em falso.

Qualidade de Serviço Ponderada por Stake (SWQoS)

No início de 2024, a Qualidade de Serviço Ponderada por Stake (SWQoS) foi adotada como um mecanismo para evitar spam e aumentar a resistência a ataques Sybil. Esse sistema permite que os líderes priorizem mensagens de transação roteadas por validators com stake. Validators com stakes maiores recebem uma capacidade proporcionalmente maior para transmitir pacotes de mensagens de transação ao líder, mitigando de forma eficaz ataques Sybil de nodes sem stake ou com pouco stake em toda a rede. Essa segmentação é possível porque os endereços IP podem ser verificados por QUIC, permitindo que os validators priorizem e limitem o tráfego de conexões específicas. 

Com SWQoS, os validators podem alugar sua capacidade ponderada por stake para nodes RPC. Em troca, os nodes RPC obtêm mais largura de banda, o que permite alcançar taxas maiores de inclusão de transações em blocos. Vale destacar que 80% da capacidade de um líder (2.000 conexões) é reservada para a QoS Ponderada por Stake, enquanto os 20% restantes (500 conexões) são destinados a mensagens de transação de outros nodes. Essa estratégia de alocação se assemelha a um sistema de faixas prioritárias em uma rodovia, no qual os motoristas pagam um pedágio para evitar o trânsito.

Atualmente, o volume mínimo de stake necessário para se qualificar como um par com stake é de 0,04% do stake total. No momento da redação deste artigo, o stake total é de 384 milhões de SOL, o que estabelece esse requisito mínimo em 15.360 SOL.‍

A SWQoS teve um impacto significativo no ecossistema Solana ao elevar os requisitos para encaminhar transações ao líder e reduzir a eficácia de ataques de spam. Essa mudança incentivou aplicativos com tráfego intenso a integrar verticalmente suas operações. Ao executar seus próprios nodes validator, os aplicativos podem garantir acesso privilegiado ao líder e, assim, aprimorar sua capacidade de processamento de transações. Na Helius, temos orgulho de operar um dos principais validators da rede em volume de stake, o que nos permite garantir uma inclusão maior de transações. Saiba mais sobre staking conosco em nosso guia detalhado de staking aqui.

A lombada da Jito

Este artigo estaria incompleto sem mencionar a Jito, já que, no momento da redação, mais de 80% do stake da rede usa o cliente validator da Jito, o que adiciona mais complexidade à forma como as transações normalmente chegam ao líder. O cliente validator Jito-Solana (Github) é um fork do cliente Agave (Github), originalmente o cliente da Solana Labs, que introduz um leilão de espaço em bloco fora do protocolo e permite que validators recebam incentivos econômicos adicionais na forma de gorjetas.

Como uma análise completa do cliente Jito está além do escopo deste artigo, limitaremos nossa análise a como ele afeta o fluxo de transações normais pelo Gulf Stream. As transações têm duas rotas possíveis: elas fluem de um RPC para um validator pareado e, depois, para o líder atual — a rota ponderada por stake — ou são encaminhadas diretamente ao líder — a rota de conexão aberta. Em qualquer um desses cenários, se o líder estiver executando o cliente Jito-Solana, essas transações serão enviadas primeiro ao Jito-Relayer (Github), um software de código aberto que atua como roteador proxy de transações. 

Os outros nodes da rede não têm conhecimento do Jito-Relayer. Eles simplesmente enviam transações para qualquer configuração de endereço e porta que o líder tenha escolhido divulgar pela rede gossip como seu ingress_socket. O relayer atrasa as transações em 200 milissegundos antes de encaminhá-las ao líder. Esse mecanismo de “lombada” desacelera o fluxo de mensagens de transação recebidas e permite leilões eficientes em tempo discreto. Após 200 milissegundos, o relayer libera as transações de forma otimista, independentemente dos resultados do leilão.

Anteriormente, a Jito operava um serviço canônico de mempool fora do protocolo, que agora foi descontinuado. Quando um validator Jito-Solana é o líder, os buscadores ainda podem enviar grupos de transações executadas atomicamente, conhecidos como bundles, para outros tipos de transações de MEV que não dependem da mempool, como transações de arbitragem e liquidações.

Para saber mais, consulte nosso artigo no blog da Helius aqui, que apresenta uma introdução ao MEV na Solana.

Conclusão

Neste artigo, analisamos vários aspectos do Gulf Stream da Solana, incluindo o protocolo de rede QUIC, a QoS Ponderada por Stake e a configuração do validator Jito. Comparamos o Gulf Stream à arquitetura de mempool mais tradicional e descrevemos os benefícios da abordagem da Solana em termos de maior eficiência e menor latência. 

Não há dúvida de que o Gulf Stream continuará evoluindo. O protocolo Solana e seu ecossistema mais amplo avançam rapidamente, com atualizações importantes previstas. Para dar um exemplo, Anatoly Yakovenko, cofundador da Solana, tem defendido fortemente a implementação de vários líderes simultâneos. Vários líderes simultâneos permitiriam que vários nodes no mundo todo sequenciassem simultaneamente as transações dos usuários, reduzindo a latência e eliminando a necessidade de uma viagem global completa de ida e volta no pior caso antes de uma transação ser adicionada à blockchain.

A Solana não ficará parada, e um futuro empolgante aguarda todo o protocolo, incluindo o Gulf Stream. Portanto, os desenvolvedores devem esperar muitas outras atualizações e otimizações.

Se você leu até aqui, agradecemos! Considere entrar em nossa comunidade no Discord, seguir-nos no X ou assinar nossa lista de e-mails abaixo.‍

Agradecemos muito a Jacob Creech e 0xIchigo por revisarem versões anteriores deste artigo.‍

Recursos adicionais

• Gulf Stream: o protocolo de encaminhamento de transações sem mempool da Solana
• QUIC, um transporte multiplexado sobre UDP
• Um guia completo sobre HTTP/3 e QUIC
• Compilação de links sobre SWQoS
• Um guia sobre Qualidade de Serviço Ponderada por Stake na Solana
• Formação para validators da Solana — QoS Ponderada por Stake
• Documentação do Jito Relayer
• Execução assíncrona, arquitetura de estado final

‍