Solana Architecture In Detail
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.
Resumo
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.
Fundamentos
Qual problema o pipeline resolve
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.
Agendamento de líder e slots
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.
Proof of History em uma frase
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.
Funções do pipeline em um relance
| 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 |
Mecânicas
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.
Pipeline ASCII de ponta a ponta
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)
Estágio 1 - Cliente para rede
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.
Estágio 2 - Gulf Stream
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".
Estágio 3 - Líder TPU
No líder, a TPU é o pipeline de produção:
- Ingerir transações da rede.
- Verificar assinaturas (geralmente em lotes paralelos).
- Processamento bancário/execução contra o AccountsDB.
- Confirmar resultados ordenados em entradas vinculadas ao PoH.
- Entregar fragmentos (shreds) para o caminho de broadcast do Turbine.
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".
Estágio 4 - Ordem PoH
À 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.
Estágio 5 - Execução Sealevel
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.
Estágio 6 - Fanout Turbine
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.
Estágio 7 - TVU valida e vota
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.
Onde Gossip e Cloudbreak se encaixam
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.
Implicações para desenvolvedores decorrentes do pipeline
- Contenção de conta - Contas graváveis compartilhadas forçam a execução serial do Sealevel. Particione o estado com PDAs quando precisar de paralelismo.
- Unidades de computação - Programas pesados falham ou pousam mal sob carga. Meça as CUs e defina orçamentos deliberadamente.
- Frescor do blockhash - Blockhashes expirados morrem na fronteira da TPU. Atualize e re-assine prontamente.
- Taxas de prioridade - Durante o congestionamento, os mercados de taxas influenciam quais txs encaminhadas o líder inclui.
- Qualidade do RPC e proximidade do líder - O Gulf Stream só ajuda se sua transação atingir um caminho de líder útil a tempo.
- Simulação vs. pouso - A simulação verifica a execução contra uma visão de estado; não garante inclusão ou propagação sob contenção.
Avançado
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) |
Latência vs largura de banda vs computação paralela
- Caminho sensível à latência: cliente -> Gulf Stream -> ingestão da TPU do líder. Milissegundos e qualidade de roteamento aparecem primeiro aqui.
- Caminho sensível à largura de banda: fanout de fragmentos do Turbine e reparo. O tamanho do bloco e a topologia da rede dominam aqui.
- Caminho sensível à computação paralela: Sealevel + AccountsDB. Bloqueio de conta e CU do programa dominam aqui.
Alta vazão requer todos os três. Otimizar apenas uma dimensão produz platôs surpreendentes.
Como as peças se compõem (não competem)
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.
Conceitos Errôneos Comuns
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.
FAQs
Qual é a descrição mais curta e precisa da arquitetura do Solana?
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.
Proof of History é um relógio ou um algoritmo de consenso?
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.
Por que o agendamento de líder é ponderado por stake?
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 que significa "sem mempool" para o Gulf Stream?
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.
Qual é a diferença entre TPU e TVU?
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.
Como o Sealevel sabe quais transações podem ser executadas em paralelo?
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.
Por que contas quentes prejudicam a vazão?
Conflitos de gravação forçam a serialização no Sealevel. Muitos usuários tocando uma conta global se tornam uma fila única.
O que o Turbine está otimizando?
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.
Onde o Cloudbreak se encaixa se o Sealevel já paraleliza?
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.
Para que serve o Gossip neste modelo mental?
Associação ao cluster, informações de contato e dados do plano de controle que permitem que líderes, Turbine e peers se encontrem.
Como as unidades de computação se relacionam com a arquitetura?
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.
Por que a qualidade do RPC afeta o pouso se a cadeia é descentralizada?
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.
O pipelining significa que os estágios são microsserviços independentes?
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.
Como devo mapear falhas visíveis para o usuário para este modelo?
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.
Esta página é suficiente para operar um validador?
Não. Este é um guarda-chuva conceitual para desenvolvedores e arquitetos, não um manual de operações.
Relacionado
- Visão Geral da Arquitetura - mapa peça por peça da mesma pilha
- Proof of History (PoH) - sequência verificável e papel de ordenação
- Turbine - fanout de fragmentos e propagação de blocos
- Gulf Stream - encaminhamento de transações para líderes
- Sealevel - runtime paralelo e bloqueios de conta
- Pipelining (TPU/TVU) - produção do líder vs caminhos de reprodução do validador
- Agendamento de Líder e Produção de Blocos - slots, líderes e cadência de produção
- Cloudbreak e Accounts DB - armazenamento concorrente de contas
- Gossip e Comunicação de Cluster - associação e plano de controle
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.