Busque em todas as páginas da documentação
Solana não é um conjunto de recursos não relacionados. É um único pipeline de validador de alta vazão: agendar um líder, encaminhar transações antecipadamente, ordená-las com um relógio verificável, executar em paralelo, distribuir o resultado e deixar o restante do cluster reproduzir e votar.
Esta página é o mapa conceitual para os componentes centrais da arquitetura. Use-a para posicionar PoH, Turbine, Gulf Stream, Sealevel, TPU/TVU, Cloudbreak, Gossip e o agendamento de líderes em um único mapa antes de mergulhar em cada subsistema.
Solana visa slots curtos (cerca de 400ms) com um agendamento de líder ponderado por stake. Clientes e RPCs enviam transações para os próximos líderes em vez de esperar em um mempool global clássico. Esse caminho de pré-encaminhamento é o Gulf Stream.
O líder atual executa uma Unidade de Processamento de Transações (TPU): ingestão, verificação de assinatura, processamento bancário e produção. A ordenação é ancorada pelo Proof of History (PoH), uma cadeia de hash sequencial que atua como uma função de atraso verificável e linha do tempo de eventos.
A execução usa Sealevel: as transações declaram todas as contas que tocam, para que bloqueios de conta não conflitantes possam ser executados em paralelo. O estado da conta reside no AccountsDB, projetado para acesso concorrente no estilo Cloudbreak, em vez de um único bloqueio global.
As entradas produzidas são fragmentadas e propagadas com o fanout do Turbine. Outros validadores recebem pelo caminho da Unidade de Validação de Transações (TVU), reproduzem e votam. Gossip carrega informações de associação e contato para que os nós saibam com quem falar.
Para desenvolvedores, a arquitetura se manifesta como taxas de pouso, custos de CU, pontos de acesso de conta e qualidade de RPC. Este é um modelo conceitual, não um manual de operações.
Blockchains devem concordar sobre ordem e estado sob atraso de rede. Designs ingênuos serializam tudo e conversam de todos para todos sobre tempo e associação de transações.
Solana separa preocupações. Tempo e ordem obtêm PoH. Propagação obtém Turbine. Pressão de mempool obtém Gulf Stream. CPU paralela obtém Sealevel e bloqueios de conta explícitos. Concorrência de armazenamento obtém o design no estilo AccountsDB/Cloudbreak. Descoberta de cluster obtém Gossip. Quem produz quando obtém o agendamento de líder.
O tempo é dividido em slots. Cada slot tem um líder designado de um agendamento ponderado por stake computado para uma época.
O líder deve produzir progresso no ledger para essa janela. O tempo alvo do slot é de ~400ms, então a liderança é rotacionada rapidamente. Saber os líderes futuros permite que a rede direcione o trabalho antes que o slot chegue.
PoH é uma sequência verificável de hashes que prova a passagem do tempo entre eventos e fornece uma espinha dorsal de ordenação compartilhada sem sincronização de relógio de todos para todos.
PoH não é consenso por si só. O consenso (historicamente Tower BFT; a evolução continua com o trabalho da era Alpenglow) ainda decide qual fork é canônico. PoH torna a história ordenada barata de verificar e difícil de reescrever sem refazer o trabalho sequencial.
| Peça | Papel no pipeline |
|---|---|
| Agendamento de líder | Quem produz qual slot |
| Gulf Stream | Encaminha txs para líderes futuros (sem mempool em relação aos designs clássicos) |
| TPU | Ingestão, verificação, processamento bancário/execução, produção no lado do líder |
| PoH | Espinha dorsal verificável de ordenação e tempo para entradas |
| Sealevel | Execução paralela de programas via bloqueios de conta declarados |
| Cloudbreak / AccountsDB | Armazenamento concorrente de contas sob carga |
| Turbine | Fanout de blocos/entradas em fragmentos (shreds) para o cluster |
| TVU | Recebimento, reconstrução, reprodução, preparação para voto no lado do validador |
| Gossip | Associação, informações de contato, disseminação do plano de controle |
Pense na vida de uma transação como um pipeline da esquerda para a direita. Os estágios se sobrepõem em muitas transações porque os validadores são máquinas com pipeline, não scripts de thread único.
Cliente / carteira / bot
|
| tx assinada (blockhash recente, metadados da conta, orçamento de CU)
v
+-----------+
| RPC / | pode retransmitir, simular, estimar taxas
| gateway |
+-----------+
|
| Gulf Stream: encaminha para líderes atuais + futuros
v
[ Líder TPU ]
busca / verificação de assinatura / processamento bancário
|
| Tiques PoH + entradas ordenadas
v
[ Execução Sealevel ]
txs paralelas se bloqueios de conta forem disjoints
sequencial quando os bloqueios entram em conflito
|
| Acesso concorrente a contas estilo AccountsDB / Cloudbreak
v
[ Produzir entradas / fragmentos (shreds) ]
|
| Fanout de árvore Turbine (fragmentos pulam peer-to-peer)
v
[ Outros validadores TVU ]
receber fragmentos -> reconstruir -> reproduzir -> votar
|
v
Confirmação do cluster (votos / escolha de fork)Um cliente constrói uma transação que lista todas as contas, marca a intenção de leitura/escrita, inclui um blockhash recente e carrega assinaturas. Instruções de Orçamento de Computação podem definir o limite de CU e o preço da prioridade.
O cliente envia para um RPC ou outra entrada. Esse salto importa: um RPC saudável que entende o agendamento de líder e a topologia melhora as chances de pouso.
O Gulf Stream envia transações não confirmadas para nós que liderarão em breve, em vez de estacionar tudo em um mempool global compartilhado até que um proponente o puxe.
Em relação aos mempools clássicos, o Solana visa ser sem mempool no sentido cotidiano: o trabalho é encaminhado ao longo do caminho do líder em vez de ficar em uma grande fila de leilão aberta em cada nó. Congestionamento, taxas de prioridade e capacidade ainda importam. Pense em "encaminhar para os próximos produtores", não em "fila pública infinita".
No líder, a TPU é o pipeline de produção:
O pipelining significa que o estágio N+1 de um lote pode ser executado enquanto o estágio N trabalha no próximo. É por isso que o Solana enfatiza o pipelining TPU/TVU em vez de uma única função monolítica "processar bloco".
À medida que o líder produz, o PoH continua o hashing. Eventos (transações, tiques) se misturam a essa sequência para que o ledger carregue uma história criptográfica de ordem.
Os validadores verificam a sequência contra as regras do PoH de forma mais barata do que reconstruir o tempo do relógio de todos os carimbos de data/hora de todos para todos. PoH ordena e marca o tempo; votos e escolha de fork finalizam qual branch o cluster segue.
Sealevel é a ideia de runtime paralelo do Solana. Como cada transação declara suas contas e o conjunto gravável antecipadamente, o agendador pode executar transações não conflitantes simultaneamente.
Se duas transações gravam na mesma conta, elas são serializadas. Contas quentes (moedas populares, cofres compartilhados, contadores globais) tornam-se gargalos, mesmo quando o hardware é bom. Unidades de computação medem o trabalho por tx; o paralelismo não apaga sua conta de CU.
As entradas são divididas em fragmentos (shreds) e enviadas através do Turbine. Os peers formam uma árvore de fanout para que o líder não envie o bloco completo por unicast para cada validador. Cada salto retransmite para os filhos, trocando alguma latência de múltiplos saltos por escalonamento de largura de banda.
Fragmentos ausentes são reparados sob demanda. Trate o Turbine como o plano de dados do bloco, distinto do plano de controle do Gossip.
Os não líderes executam o caminho TVU: recebem fragmentos, reconstroem entradas, reproduzem a execução e atualizam o estado local se o bloco for válido.
Após a reprodução, os validadores votam sob as regras de consenso. Os níveis de confirmação do cliente (processed, confirmed, finalized) refletem o progresso do acordo, não apenas que um líder emitiu fragmentos.
Gossip é como os nós aprendem sobre associação, informações de contato e alguns metadados do cluster. Sem esse substrato, as árvores do Turbine e o roteamento do líder não podem se formar.
Cloudbreak (nome histórico da abordagem do Solana para o banco de dados de contas concorrente) e o moderno AccountsDB respondem como armazenar e atualizar milhões de contas sob execução multithread. O paralelismo de execução é inútil se cada toque de conta colidir em um único bloqueio de armazenamento.
Use esta tabela ao depurar "qual camada é o gargalo?" em vez de "o Solana é rápido em abstrato?"
| Subsistema | Alvo principal de otimização | O que não resolve sozinho | Sinal do desenvolvedor |
|---|---|---|---|
| PoH | Ordem verificável / sequenciamento de tempo | Escolha de fork, finalidade econômica | Estrutura de slot; não o design do bloqueio do seu aplicativo |
| Agendamento de líder | Janelas de produção previsíveis | Inclusão justa sob spam | Quem lidera em breve para expectativas de roteamento |
| Gulf Stream | Latência para o líder; reduzir a agitação do mempool | Capacidade infinita | Sensibilidade de pouso a RPC e tempo |
| TPU | Vazão do lado do líder via estágios com pipeline | Custo de reprodução do validador | Limites de verificação de assinatura e processamento bancário sob carga |
| Sealevel | Computação paralela entre contas não sobrepostas | Atualizações de conta única quente | Contenção em graváveis compartilhados |
| Medição de CU | Trabalho por tx limitado | Justiça entre aplicativos | Erros de orçamento excedido; mercados de taxas |
| Cloudbreak / AccountsDB | E/S de conta concorrente | Layout de conta ruim | Crescimento do estado, designs com muitos bloqueios |
| Turbine | Propagação de bloco eficiente em largura de banda | Votos de consenso | Confirmações lentas se a propagação/reparo lutarem |
| TVU | Caminho eficiente de reprodução e validação | Abstrações de UX do cliente | A produção pode superar a reprodução lenta |
| Gossip | Associação e dados do plano de controle | Transferência de bloco em massa | Problemas de topologia/peers (voltado para operações) |
Alta vazão requer todos os três. Otimizar apenas uma dimensão produz platôs surpreendentes.
Um erro comum é classificar um subsistema como "a razão pela qual Solana é rápido" isoladamente. A vazão é multiplicativa em um pipeline.
Líderes rápidos sem Turbine não podem alimentar validadores. Turbine sem Sealevel ainda serializa em conflitos. Sealevel sem armazenamento concorrente deixa os threads famintos. Gulf Stream sem um agendamento de líder não tem para onde enviar trabalho de forma inteligente. PoH sem votos é apenas um candidato a log ordenado, não uma cadeia finalizada.
Conceito Errado: PoH é o consenso do Solana. PoH é um mecanismo verificável de ordenação e atraso. O consenso requer votos e escolha de fork. Uma entrada vinculada ao PoH não é finalidade econômica.
Conceito Errado: Solana não tem mempool, então o congestionamento não pode existir. O Gulf Stream muda onde o trabalho não confirmado espera. Ele não cria inclusão infinita. Os líderes ainda selecionam sob capacidade, taxas e regras de validade.
Conceito Errado: Sealevel significa que cada transação sempre é executada em paralelo. Apenas bloqueios de conta não conflitantes são paralelizados. Uma conta gravável quente pode serializar uma grande fração do tráfego.
Conceito Errado: Turbine é Gossip. Turbine é a propagação de blocos/fragmentos com fanout estruturado. Gossip é associação e comunicação do plano de controle.
Conceito Errado: TPU e TVU são o mesmo pipeline. TPU é a produção do líder. TVU é o recebimento e reprodução do validador. Mesmo estado final quando honesto e sincronizado; papéis e gargalos diferentes.
Conceito Errado: Uma simulateTransaction bem-sucedida significa que a tx pousará.
A simulação verifica a execução contra um snapshot. Ela não reserva capacidade do líder, vence um mercado de taxas ou garante a propagação de fragmentos.
Conceito Errado: O conhecimento da arquitetura é apenas para validadores. Desenvolvedores sentem a arquitetura através do design de contas, CU, taxas, blockhashes e comportamento de RPC.
Conceito Errado: O tempo do slot garante o tempo de confirmação visível para o usuário. Os alvos de slot descrevem a cadência de produção. A confirmação depende de votos, forks, nível de confirmação e saúde da rede.
Um pipeline de líder agendado por stake que pré-encaminha transações, ordena-as com PoH, executa trabalho não conflitante em paralelo, distribui blocos com Turbine, e tem validadores reproduzindo e votando.
Trate PoH como uma sequência verificável que suporta alegações de ordenação e tempo. O consenso ainda depende de votos de validadores e regras de escolha de fork.
Os líderes são designados proporcionalmente ao stake para que os direitos de produção de blocos acompanhem a segurança econômica ao longo do cronograma de uma época, não uma corrida livre a cada slot.
O encaminhamento para líderes futuros é o caminho principal, não um grande mempool global clássico em cada nó. Não significa inclusão ilimitada e gratuita.
TPU é o processamento do lado do líder e produção de blocos. TVU é o recebimento, reconstrução, reprodução e preparação para voto do lado do validador.
As transações declaram todas as contas e quais são graváveis. Conjuntos de bloqueio disjoints são executados concorrentemente; conflitos são serializados.
Conflitos de gravação forçam a serialização no Sealevel. Muitos usuários tocando uma conta global se tornam uma fila única.
Propagação de blocos eficiente em largura de banda via fanout de árvore de fragmentos, para que os líderes não precisem enviar o payload completo por unicast para cada peer.
O Sealevel agenda a execução paralela. O armazenamento no estilo AccountsDB/Cloudbreak serve acesso concorrente a contas por baixo, sem um único bloqueio global.
Associação ao cluster, informações de contato e dados do plano de controle que permitem que líderes, Turbine e peers se encontrem.
Os limites de CU definem o trabalho por transação durante a execução do Sealevel. O paralelismo do cluster e o orçamento da sua tx estão relacionados, mas não são o mesmo controle.
Sua transação ainda precisa entrar no caminho Gulf Stream/TPU a tempo com um blockhash válido. O roteamento e a posição do RPC afetam esse salto.
Não necessariamente. Pipelining é processamento estruturado em estágios dentro de validadores e entre saltos. Os estágios se sobrepõem no tempo como um único pipeline de ledger.
Blockhash expirado ou nunca recebido: ingestão/Gulf Stream/TPU. Problemas de CU ou bloqueio: Sealevel/design do programa. Confirmações lentas: Turbine, reprodução ou votos. Problemas de peers: Gossip/operações.
Não. Este é um guarda-chuva conceitual para desenvolvedores e arquitetos, não um manual de operações.
Versões da pilha: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.
Revisado por Chris St. John·Última atualização: 12 de jul. de 2026