Turbine: propagação de blocos na Solana

Sobre o que é este artigo?

A disponibilidade de dados é crucial para blockchains. Ela garante que todas as informações necessárias estejam prontamente acessíveis aos nós para fins de validação, preservando a integridade e a segurança da rede. No entanto, garantir a disponibilidade dos dados e, ao mesmo tempo, manter um alto nível de desempenho é um desafio significativo, especialmente à medida que as redes crescem.

A Solana superou esse desafio com um design arquitetônico exclusivo que facilita a criação e a propagação contínuas de blocos. Isso é possível graças a diversas inovações importantes, como a seleção de líderes, o Gulf Stream (que elimina a necessidade de uma mempool) e o Turbine (mecanismo de propagação de blocos).

A natureza contínua da Solana exige um sistema eficiente para garantir que todos os validadores recebam rapidamente o estado mais atualizado. Em uma abordagem simplista, o líder transmitiria todos os blocos diretamente a cada um dos outros validadores. Porém, devido ao alto throughput da Solana, esse método aumentaria significativamente os requisitos de largura de banda e de outros recursos, além de prejudicar a descentralização.

A largura de banda é um recurso escasso, e o Turbine é a solução engenhosa da Solana para otimizar a propagação de informações do líder de um determinado bloco para o restante da rede. O Turbine foi projetado especificamente para reduzir a pressão do tráfego de saída (envio de dados) do líder para a rede.

Neste artigo, vamos explorar como o Turbine funciona e seu papel fundamental no contexto mais amplo da inclusão de transações na Solana. Também compararemos o Turbine a outras soluções de disponibilidade de dados e discutiremos linhas de pesquisa em aberto nessa área.

O que é o Turbine?

O Turbine é um mecanismo multicamadas de propagação de blocos usado por um cluster da Solana para transmitir entradas do ledger a todos os nós. As ideias centrais por trás do Turbine estão na mente dos acadêmicos há muitos anos, como demonstram este artigo publicado em 2004 e trabalhos mais recentes.

Diferentemente das blockchains tradicionais, nas quais um bloco é enviado a todos os nós de forma sequencial ou por inundação, o Turbine adota uma abordagem mais estruturada para minimizar a sobrecarga de comunicação e reduzir a carga sobre cada nó. Em linhas gerais, o Turbine divide um bloco em partes menores e as dissemina por uma hierarquia de nós. Assim, um nó individual não precisa estar em contato com todos os outros nós e só precisa se comunicar com alguns deles. Isso se torna cada vez mais importante à medida que a rede cresce, pois os métodos tradicionais de propagação se tornariam inviáveis devido ao enorme volume de comunicações necessárias. Dessa forma, o Turbine garante a disseminação rápida e eficiente de dados pela Solana. A velocidade com que os blocos são propagados e verificados é crucial para manter o alto throughput e a segurança da rede Solana.

Além disso, o Turbine aborda a questão da disponibilidade de dados, garantindo que todos os nós possam acessar com eficiência os dados necessários para validar transações. Isso é feito sem exigir uma quantidade enorme de largura de banda, um gargalo comum em outras redes blockchain.

O Turbine contribui significativamente para a capacidade da Solana de processar grandes volumes de transações e manter uma estrutura de rede enxuta e eficiente, reduzindo o gargalo de largura de banda e garantindo a rápida propagação de blocos. Esse protocolo inovador é um dos pilares que permitem à Solana cumprir sua promessa de ser uma rede rápida, segura e escalável.

Agora, vamos analisar em mais detalhes a mecânica do Turbine e como ele propaga blocos pela rede Solana.

Como o Turbine propaga blocos?

Antes de um bloco ser propagado (ou seja, transmitido a outros validadores da rede), o líder constrói e ordena o bloco com base no fluxo de transações recebidas. Depois de construído, o bloco está pronto para ser enviado pelo Turbine ao restante da rede. Esse processo é chamado de propagação de blocos. Em seguida, mensagens de voto são transmitidas entre os validadores e encapsuladas nos dados do bloco para que ele atinja o status de compromisso “confirmed” ou “finalized”. Um bloco confirmado é um bloco que recebeu uma supermaioria de votos do ledger, enquanto um bloco finalizado é um bloco que foi confirmado e tem mais de 31 blocos confirmados construídos sobre o bloco-alvo. A diferença entre os status de compromisso é explicada em mais detalhes aqui. Essa parte do consenso será explorada em uma publicação futura.

Embora os líderes construam e proponham blocos inteiros, os dados propriamente ditos são enviados como shreds (blocos parciais) aos outros validadores da rede. Shreds são as unidades atômicas enviadas entre validadores.

Em linhas gerais, o Turbine recebe shreds e os envia a um conjunto predeterminado de validadores, que então retransmitem esses shreds a um novo conjunto de validadores. O diagrama a seguir descreve o processo contínuo de propagação de shreds:

Neste exemplo, o Validador 1 é o líder designado do slot. Durante seu slot (os validadores são designados líderes por 4 slots consecutivos), o Validador 1 constrói e propõe um bloco. Primeiro, o Validador 1 divide o bloco em sub-blocos chamados shreds por meio de um processo chamado shredding. O shredding divide os dados do bloco em data shreds do tamanho de Unidades Máximas de Transmissão (MTU) — a quantidade máxima de dados que pode ser enviada de um nó para o próximo sem ser fragmentada em unidades menores — e gera os recovery shreds correspondentes por meio do esquema de codificação de apagamento Reed-Solomon. Esse esquema auxilia na recuperação dos dados e garante sua integridade durante a transmissão, o que é crucial para manter a segurança e a confiabilidade da rede.

Esse processo de shredding e propagação garante uma distribuição rápida e eficiente dos dados de blocos pela Solana, mantendo o alto throughput e a segurança da rede.

Codificação de apagamento

Antes de serem propagados pela Árvore Turbine, os shreds são codificados usando a codificação de apagamento Reed-Solomon, um esquema de detecção e correção de erros baseado em polinômios. A codificação de apagamento é usada como método de proteção de dados para que os dados originais possam ser recuperados mesmo que algumas partes sejam perdidas ou corrompidas durante a transmissão. A codificação de apagamento Reed-Solomon é um tipo específico de algoritmo de Correção Antecipada de Erros (FEC).

Como o Turbine depende fundamentalmente de uma série de retransmissões de pacotes por validadores posteriores, esses validadores podem agir de forma maliciosa (nós bizantinos adversários), optando por retransmitir dados incorretos, ou receber dados incompletos (perda de pacotes de rede). Devido à estrutura em árvore de retransmissão do Turbine, qualquer perda de pacotes em toda a rede se acumula, e a probabilidade de o pacote não chegar ao destino aumenta a cada salto.

Em linhas gerais, se o líder transmitir 33% dos pacotes do bloco como códigos de apagamento, a rede poderá perder quaisquer 33% dos pacotes sem perder o bloco. Os líderes podem ajustar dinamicamente esse número (taxa de FEC) com base nas condições da rede, considerando variáveis como a perda de pacotes observada recentemente em toda a rede e a profundidade da árvore.

Para simplificar, vamos analisar um grupo de shreds com uma taxa de FEC de 4:4.

Os data shreds são blocos parciais do bloco original construído pelo líder, enquanto os recovery shreds são os blocos com codificação de apagamento gerados pelo Reed-Solomon.

Os blocos na Solana normalmente utilizam uma FEC de 32:32 (32 de 64 pacotes podem ser perdidos sem necessidade de retransmissão). Conforme descrito na documentação da Solana, estas são as premissas conservadoras sobre a rede:

• Taxa de perda de pacotes de 15%
• 50 mil TPS gerando 6.400 shreds por segundo

Uma taxa de FEC de 32:32 resulta em uma taxa de sucesso de blocos de ~99%. Além disso, os líderes podem aumentar a taxa de FEC se quiserem elevar a probabilidade de sucesso do bloco.

Atualmente, o Turbine usa UDP para a propagação de blocos, proporcionando enormes benefícios de latência. Segundo um operador de validador, transmitir 6 MB + o volume de dados da codificação de apagamento de us-east-1 para eu-north-1 usando UDP leva 100 ms, enquanto com TCP leva 900 ms.

Árvore Turbine

Uma Árvore Turbine é uma topologia de rede estruturada usada pela Solana para facilitar a propagação eficiente de shreds (dados de blocos codificados) entre validadores. Depois que os shreds são devidamente codificados em seus respectivos grupos, eles estão prontos para ser disseminados pela Árvore Turbine e informar aos outros validadores da rede qual é o estado mais atualizado.

Cada grupo de shreds é enviado por meio de um pacote de rede a um nó raiz especial, que gerencia quais validadores fazem parte da primeira camada (a 1 salto de distância). Em seguida, estas etapas são executadas:

1. Criação da lista: O nó raiz agrega todos os validadores ativos em uma lista, que é então ordenada com base no stake de cada validador na rede. Validadores com maior peso de stake têm prioridade para receber shreds antes, o que permite que respondam mais rapidamente com suas próprias mensagens de voto para o consenso.
2. Embaralhamento da lista: Essa lista é então embaralhada de forma determinística. Isso cria uma “Árvore Turbine” gerada a partir do conjunto de nós validadores para cada shred, usando uma semente derivada do ID do líder do slot, slot, índice do shred e tipo de shred. Uma nova árvore é gerada em tempo de execução para cada grupo de shreds a fim de reduzir possíveis riscos de segurança associados a uma estrutura de árvore estática.
3. Formação das camadas: Os nós são então divididos em camadas, começando pelo topo da lista. A divisão é baseada no valor DATA_PLANE_FANOUT, que determina a largura e a profundidade da Árvore Turbine. Esse valor afeta a rapidez com que os shreds podem ser propagados pela rede. Atualmente, o DATA_PLANE_FANOUT é 200, portanto, a maioria dos validadores está a apenas 2 ou 3 saltos de distância (líder -> raiz -> L1 -> L2).

Como a Árvore Turbine é conhecida por todos, cada validador sabe exatamente para onde deve retransmitir aquele shred. A Árvore Turbine normalmente tem 2 ou 3 saltos (dependendo do número de validadores ativos), considerando o valor atual de 200 para DATA_PLANE_FANOUT.

Além disso, os nós podem recorrer ao gossip e ao reparo caso não recebam shreds suficientes ou se a taxa de perda ultrapassar a taxa de FEC. Na implementação atual, um nó sem shreds suficientes para reconstruir o bloco envia uma solicitação de retransmissão ao líder. Com o Turbine determinístico, qualquer nó que tenha recebido o bloco completo pode enviar os shreds de reparo necessários ao nó solicitante, levando a transmissão de dados às áreas mais abaixo da árvore que estão solicitando os dados.

Comparação da propagação de blocos entre Solana e Ethereum

A propagação de blocos na Solana é diferente da Ethereum. Estas são algumas diferenças gerais:

• Os requisitos ideais de largura de banda da Solana (>1 Gbps) são significativamente maiores que os da Ethereum (o geth recomenda >25 Mbps). Esse requisito maior de largura de banda decorre dos blocos maiores e dos tempos de bloco mais curtos da Solana. O design da Solana permite usar com eficiência toda a largura de banda para acelerar a transmissão de dados e, assim, reduzir a latência. Embora haja picos de largura de banda de até 1 Gbps, esse volume não é usado de forma constante. A arquitetura da Solana foi projetada especificamente para permitir picos na demanda por largura de banda.
• A Solana usa o Turbine para propagar dados de blocos, enquanto a Ethereum utiliza um protocolo gossip padrão. Na Ethereum, a propagação dos dados de blocos ocorre de forma direta: cada nó se comunica com todos os outros nós completos da rede. Quando surge um novo bloco, os clientes o verificam enviando-o a seus pares e aprovando as transações contidas nele. Esse mecanismo é adequado à Ethereum devido aos seus blocos menores e tempos de bloco mais longos em comparação com a Solana. No caso dos dados de rollups L2 da Ethereum (exceto validiums), a propagação também segue o protocolo gossip, com os dados de blocos armazenados no campo “calldata” dos blocos L1 da Ethereum.
• A Ethereum usa TCP (por meio do protocolo DevP2P) para a propagação de blocos, enquanto a Solana usa UDP (com algum apoio da comunidade para migrar para QUIC). Existem alguns trade-offs a considerar entre UDP e QUIC:
• A unidirecionalidade do UDP resulta em menor latência em comparação com o QUIC, que exige streams QUIC. Há discussões em andamento sobre a implementação de streams unidirecionais no QUIC.
• Os defensores do QUIC afirmam que, embora seja possível implementar um fluxo de controle personalizado sobre UDP, isso exige um esforço considerável de engenharia, que o QUIC reduz ao oferecer suporte nativo a esses recursos. O objetivo final é o mesmo, mas o limite superior do desempenho do QUIC (latência, throughput etc.) corresponde ao estado atual do UDP puro.

Essas diferenças destacam as decisões arquitetônicas específicas adotadas pela Solana e pela Ethereum, que contribuem para o desempenho, a escalabilidade e a robustez de rede de cada uma. Para uma análise mais detalhada sobre TCP, UDP e QUIC, confira nosso artigo sobre Solana e QUIC.

Questões para pesquisas futuras

A propagação de blocos e a disponibilidade de dados continuam sendo áreas de pesquisa em aberto, com várias equipes desenvolvendo suas próprias abordagens. Embora as métricas possam evoluir, queremos apresentar uma visão geral das diferentes abordagens e de seus respectivos trade-offs:

• Algumas discussões surgiram sobre a posição do Turbine como mecanismo de “disponibilidade de dados” (DA). O Turbine funciona como um mecanismo de disponibilidade de dados no sentido de que todos os dados do bloco são publicados e baixados por todos os outros validadores da Solana. No entanto, o Turbine não oferece suporte à amostragem de disponibilidade de dados (DAS), um recurso que ajuda nós leves a verificar o estado com requisitos de hardware menores. Essa é uma área de desenvolvimento ativo para equipes como a Celestia. Assim como o Turbine, a DAS também usa códigos de apagamento, mas com o objetivo explícito de detectar e impedir ataques de retenção de dados.
• Para L2s da Solana Virtual Machine (SVM), como a Eclipse, o Turbine perde relevância, pois não há um conjunto de validadores entre os quais transmitir dados. No caso da Eclipse, os dados de blocos são publicados na Celestia para garantir a disponibilidade de dados — isso permite que observadores externos executem provas de fraude para garantir a execução e as transições de estado corretas. A Eclipse será uma das primeiras implementações da SVM fora da própria rede Solana. A Pyth também criou um fork da SVM para sua própria rede de oráculos chamada “Pythnet” e opera efetivamente como sua própria sidechain.
• Na Solana, os nós completos gerenciam a propagação de blocos e também participam de outros segmentos da stack blockchain integrada, como a ordenação de transações e o consenso. Quais seriam as métricas quantitativas do Turbine se ele operasse como um componente modular em hardware especializado?
• O Turbine prioriza nós com maior peso de stake para que recebam primeiro os dados de blocos. Isso levará a uma maior centralização de MEV ao longo do tempo?
• Como diferentes abordagens de disponibilidade de dados, como EigenDA (retransmissor unicast único e horizontalmente escalável) e Celestia (amostragem de disponibilidade de dados), serão comparadas ao Turbine em produção quanto ao throughput bruto e à minimização da confiança?
• O Firedancer pretende aumentar ainda mais a propagação de dados e é otimizado para uma conexão robusta com largura de banda de 10 Gbps. Como as otimizações no nível do sistema que ele implementou no Turbine funcionarão em produção tanto em hardware de consumo quanto em hardware profissional?
• Atualmente, todos os nós da Solana são nós completos (implementações de clientes leves ainda estão em desenvolvimento). Sreeram Kannan (EigenLayer) descreveu recentemente uma implementação de DAS-S sobre o Turbine. Haverá suporte a uma versão de DAS para o Turbine? É possível implementar clientes leves com DAS para manter um alto throughput de dados enquanto esses clientes leves, com requisitos de recursos muito menores, satisfazem a minimização da confiança?

Conclusão

Parabéns! Neste artigo, analisamos o Turbine e como ele funciona no contexto mais amplo da inclusão de transações na Solana. Comparamos o Turbine a outras soluções de disponibilidade de dados e discutimos as diferentes linhas de pesquisa em aberto nessa área. O protocolo Turbine da Solana demonstra o compromisso da rede em alcançar alto throughput e baixa latência usando uma topologia de rede estruturada para disseminar com eficiência os dados de blocos entre os validadores.

Encontrar formas de melhorar a disponibilidade de dados e tornar a propagação de blocos mais eficiente impulsiona a inovação em toda a comunidade blockchain. A análise comparativa dos mecanismos de propagação de blocos da Solana e da Ethereum revela os pontos fortes e os trade-offs de cada uma, além de inspirar uma discussão mais profunda sobre como soluções blockchain emergentes, como EigenDA, Celestia e Firedancer, poderão moldar esse ecossistema no futuro.

A solução para a propagação eficiente e a disponibilidade de dados está longe de estar completa. No entanto, a abordagem da Solana e seu compromisso firme em otimizar o desempenho da rede sem comprometer a segurança nem a minimização da confiança são muito bem-vindos.

Agradecemos a @dubbel06 e @jon_charb pela revisão e pelos comentários.

Recursos adicionais / Leituras complementares

• Propagação de blocos com o Turbine
• Entendendo a codificação de apagamento
• Blocos da Ethereum
• Atualização Perseus da rede Pyth
• Introdução ao EigenDA: disponibilidade de dados em hiperescala para rollups
• Firedancer