Pipelining de Transações da Solana: Pipeline de 4 Estágios da TPU

Este guia técnico explica o pipeline de 4 estágios da TPU no pipelining de transações da Solana e como ele suporta o processamento paralelo.

A Solana produz um novo bloco aproximadamente a cada 400 milissegundos. A maioria das blockchains processa transações uma de cada vez, esperando que cada uma seja concluída antes de iniciar a próxima. A Solana não faz isso.

O pipelining de transações da Solana é o método pelo qual a Unidade de Processamento de Transações da Solana move as transações recebidas através de quatro estágios sequenciais: Fetch, SigVerify, Banking e Writing. Múltiplos lotes de transações passam por esses estágios simultaneamente, de modo que, enquanto um lote está sendo gravado no ledger, o próximo já está sendo validado e um terceiro já está sendo buscado. Esse processamento paralelo é o que permite que a Solana (SOL), o ativo nativo da blockchain Solana (o ledger distribuído no qual todas as transações são registradas), atinja números de rendimento que excedem em muito a maioria das redes Layer-1.

A Solana foi construída por Anatoly Yakovenko, um ex-engenheiro da Qualcomm que publicou o whitepaper do Proof of History em 2017, introduzindo o mecanismo de relógio criptográfico que torna possível a velocidade do pipeline. A Solana Labs, organização com sede em San Francisco que desenvolveu o protocolo, implementou o pipelining como um recurso central do cliente validador. O resultado é uma rede que se tornou uma plataforma líder para aplicações de finanças descentralizadas (DeFi), incluindo exchanges descentralizadas, protocolos de empréstimo e mercados de derivativos on-chain que exigem finalidade de transação em menos de um segundo.

O amplamente citado Trilema da blockchain sustenta que as blockchains podem priorizar apenas duas das três propriedades: escalabilidade, segurança e descentralização. O pipelining de transações da Solana é sua resposta arquitetônica à dimensão da escalabilidade. Este artigo aborda o que é o pipelining, como os quatro estágios da TPU funcionam mecanicamente, como o Proof of History permite o pipeline, como o Gulf Stream e o Turbine envolvem a entrada e a saída do pipeline, como o Sealevel estende o princípio de pipelining para a execução de contratos inteligentes, como a Solana se compara à Ethereum arquitetonicamente e onde residem os compromissos e limites documentados do pipeline.

Sumário

1. O que é o Pipelining de Transações da Solana? (E por que ele importa para SOL)
2. Como funciona o pipeline da TPU da Solana: Os quatro estágios explicados
3. Proof of History: O relógio criptográfico que torna o pipelining possível
4. Gulf Stream: Como as transações entram no pipeline antes dele estar pronto
5. A analogia do pipeline de CPU: Por que a arquitetura da Solana deve soar familiar para engenheiros
6. Turbine: Como a saída do pipeline alcança a rede
7. Sealevel: Pipelining estendido à execução de Smart Contract
8. Solana vs. Ethereum: Uma comparação da arquitetura de pipeline
9. Limitações, congestionamento e os compromissos honestos da arquitetura de pipeline da Solana
10. Perguntas frequentes sobre o Pipelining de Transações da Solana
11. O Pipelining de Transações da Solana e a tese de investimento em SOL

O que é o Pipelining de Transações da Solana? (E por que ele importa para SOL)

O pipelining de transações da Solana é a técnica de dividir o processamento de transações em estágios distintos e executar esses estágios simultaneamente em vários lotes de transações, para que nenhuma peça de hardware do validador fique ociosa esperando a conclusão de outro estágio. Pense nisso como uma linha de montagem de carros: diferentes veículos estão em diferentes estações simultaneamente, e a linha nunca para para que um carro seja totalmente concluído antes que o próximo entre.

A Solana pegou essa ideia emprestada dos processadores de computador. As CPUs modernas alcançam um alto rendimento por meio do pipelining no nível da instrução: enquanto uma instrução está sendo executada, a próxima está sendo decodificada e a posterior já está sendo buscada. A Solana aplica a mesma lógica às transações no nível do validador. O mapeamento completo dos estágios da CPU para os estágios da TPU da Solana é abordado na seção de analogia da CPU abaixo, mas o princípio central é idêntico: manter todos os estágios ocupados o tempo todo.

A maioria das blockchains processa transações sequencialmente, o que significa que um validador deve concluir todo o processamento de uma transação (ou lote) antes de iniciar a próxima. Esse modelo sequencial cria um teto de rendimento determinado inteiramente pela rapidez com que uma única cadeia de operações pode ser executada. O pipelining quebra esse teto ao executar várias operações em paralelo em componentes de hardware dedicados, reduzindo a latência de confirmação (o tempo entre o envio de uma transação e o recebimento da finalização) sem exigir que cada estágio individual seja executado mais rápido.

O TPS teórico da Solana, conforme a documentação técnica da Solana, é de aproximadamente 65.000 transações por segundo. Isso representa o máximo do pipeline sob condições ideais. O TPS real sem votos (non-vote) é substancialmente menor, variando normalmente de 2.000 a 4.000 TPS, dependendo da carga da rede e da composição da transação. A Solana conta as transações de voto dos validadores separadamente das transações sem voto geradas pelo usuário; a contagem total de TPS incluindo votos é maior, mas menos significativa como uma métrica de rendimento voltada para o usuário. Para comparação, a Ethereum processa aproximadamente 15 a 30 transações por segundo na Layer-1, e o Bitcoin processa aproximadamente 7 transações por segundo.

Estatísticas Principais

O pipeline TPU da Solana produz um novo bloco a cada ~400ms, aproximadamente 30x mais rápido do que o tempo de bloco de ~12 segundos da Ethereum. TPS teórico: ~65.000. TPS real sem votos: ~2.000-4.000 (varia com a carga da rede).

Nota sobre a metodologia de TPS: O valor de ~65.000 é o máximo teórico da documentação técnica da Solana. O rendimento real sem votos varia de acordo com as condições da rede. As transações de voto são excluídas do valor de 2.000-4.000. Os números da Ethereum representam o rendimento da Layer-1 e excluem soluções de Layer-2.

O mecanismo que torna isso possível é a Unidade de Processamento de Transações (TPU) da Solana, um pipeline de quatro estágios que funciona dentro de cada validador líder. A próxima seção explica como esse pipeline opera mecanicamente.

Como funciona o pipeline da TPU da Solana: Os quatro estágios explicados

O mecanismo por trás da velocidade da Solana é um pipeline de quatro estágios alojado na Unidade de Processamento de Transações (TPU), que funciona dentro do validador líder de cada slot, processando vários lotes de transações simultaneamente por meio de hardware dedicado em cada estágio.

O que é a Unidade de Processamento de Transações (TPU)?

Na Solana, a Unidade de Processamento de Transações (TPU) é o motor do pipeline dentro de cada nó validador que executa fisicamente o processamento das transações. Este é um termo específico do domínio da Solana e não tem relação com a Unidade de Processamento de Tensor do Google usada em aprendizado de máquina.

O TPU é executado exclusivamente no validador líder para cada slot de aproximadamente 400ms. Validadores não líderes executam a Transaction Validation Unit (TVU), que reproduz e verifica blocos produzidos pelo líder. Solana determina qual validador atua como líder através de um Cronograma de Líderes determinístico, publicado antecipadamente para cada época (aproximadamente 2 a 3 dias), que atribui os slots de líder de cada validador com base em seu peso em staking. Este cronograma é o que torna o pré-roteamento de transações do Gulf Stream possível, como discutido na seção Gulf Stream abaixo.

Para detalhes técnicos sobre a arquitetura da TPU, veja a documentação oficial da TPU da Solana) e a documentação do tempo de slot da Solana.

As Quatro Fases do Pipeline da TPU da Solana

O pipeline da TPU processa transações através de quatro fases sequenciais, cada uma gerenciada por hardware dedicado, cada uma passando sua saída para a próxima fase enquanto simultaneamente recebe nova entrada da fase anterior.

1. Fetch: A pilha de rede recebe pacotes de transação brutos via QUIC (um protocolo de transporte moderno que substituiu a conexão UDP original para controle de congestionamento aprimorado). A fase Fetch é o cais de entrada do pipeline. Ela puxa transações do buffer pré-carregado que o Gulf Stream já preencheu antes do início do slot, e passa pacotes verificados para o SigVerify.

2. SigVerify: A GPU verifica as assinaturas criptográficas nas transações recebidas. Cada transação Solana inclui uma ou mais assinaturas digitais que devem ser validadas antes que qualquer alteração de estado possa ocorrer. A aceleração por GPU permite que milhares de verificações de assinatura sejam executadas em paralelo dentro desta única fase. SigVerify é o checkpoint de autenticação: transações que passam vão para o Banking; transações que falham são descartadas.

3. Banking: A CPU aplica as transações validadas ao estado do ledger, executando débitos e créditos de contas e processando alterações de estado do Smart Contract. Banking é o departamento de contabilidade do pipeline e a fase mais intensiva em termos de computação. É também o gargalo principal sob alta carga: quando o volume de transações excede a capacidade de processamento do Banking, o pipeline começa a descartar transações em vez de colocá-las em fila.

4. Writing: NVMe SSDs gravam entradas de ledger confirmadas em disco, e a fase transmite os dados do bloco resultante para o resto da rede via Turbine. Writing é a fase de despacho e registro: uma vez concluída, o bloco existe na blockchain e a propagação começa.

A mecânica central de pipeline opera em todas as quatro fases simultaneamente. Enquanto o lote N está no Banking, o lote N-1 já está no Writing, e o lote N+1 já está no SigVerify. Nenhuma fase espera que outra fase termine seu lote atual antes de iniciar o próximo. É assim que o pipeline atinge throughput paralelo: cada peça de hardware está ocupada em cada momento do slot.

[DIAGRAMA NECESSÁRIO: DIAGRAMA-01] Pipeline de quatro fases mostrando os lotes A, B, C, D em diferentes fases simultaneamente. Lote A: Writing (NVMe SSD). Lote B: Banking (CPU). Lote C: SigVerify (GPU). Lote D: Fetch (rede). Setas mostrando a progressão de cada lote através das fases E a operação simultânea em todas as quatro fases.

Quem Executa o Pipeline? Validadores e o Cronograma de Líderes

Validadores Solana são os operadores de nó que executam fisicamente o pipeline da TPU. Cada validador é um servidor dedicado executando o software Solana, responsável por produzir blocos (se for o líder atual) ou por verificar e reproduzir blocos produzidos pelo líder (usando a TVU).

O Cronograma de Líderes atribui qual validador executa a TPU para cada slot de aproximadamente 400ms. O cronograma é computado de forma determinística a partir do conjunto de validadores ponderado pelo stake no início de cada época, para que os validadores saibam seus próximos slots de líder com dias de antecedência. Essa previsibilidade permite que o Gulf Stream pré-roteie transações para o próximo líder antes que seu slot comece, garantindo que o buffer da fase Fetch esteja cheio quando o slot iniciar.

Executar o pipeline da TPU exige hardware de nível empresarial: uma GPU dedicada para a fase SigVerify, uma CPU com alta contagem de núcleos para a fase Banking, SSDs NVMe empresariais para a fase Writing e rede de alta largura de banda para a fase Fetch. Esses requisitos são substancialmente maiores do que os limiares de hardware de validador da Ethereum, o que cria um trade-off de centralização abordado na seção de limitações. Para especificações de hardware de validador atuais, veja a documentação de requisitos de validador da Solana.

Proof of History: O Relógio Criptográfico Que Torna o Pipelining Possível

Proof of History (PoH) é o mecanismo criptográfico que permite que o pipeline da Solana execute na velocidade máxima do hardware, sem exigir que os validadores se comuniquem entre si para concordar sobre o tempo de cada lote de transações antes de avançar para a próxima fase.

O mecanismo funciona da seguinte forma. PoH produz uma sequência contínua de hashes SHA-256, onde cada hash usa o hash anterior como entrada. Como a computação SHA-256 leva uma quantidade mensurável e verificável de tempo, a sequência de hashes resultante constitui uma prova criptográfica de que uma quantidade específica de tempo passou entre quaisquer dois eventos registrados na cadeia. Cada validador pode verificar independentemente essa sequência sem contatar outros validadores.

A conexão com o pipelining é direta. Sem PoH, o pipeline precisaria pausar em cada fase e esperar que a rede alcançasse consenso sobre a ordem do lote de transações atual antes que a próxima fase pudesse começar. Essa viagem de ida e volta de comunicação inter-nós seria o fator de latência dominante, tornando os tempos de slot de 400ms impossíveis na escala da rede. PoH elimina essa espera, fornecendo um relógio compartilhado e verificável que todos os validadores podem verificar localmente. O pipeline avança com base no relógio PoH, não em viagens de ida e volta de mensagens de rede.

Anatoly Yakovenko introduziu o Proof of History no whitepaper do Proof of History) publicado em 2017, com base em sua experiência em sistemas distribuídos de seu tempo na Qualcomm.

PoH não é Proof of Stake.

Proof of History NÃO é o mecanismo de consenso da Solana. É um relógio criptográfico que sequencia eventos e prova o tempo decorrido. Solana usa Proof of Stake (especificamente Tower BFT, sua implementação de Practical Byzantine Fault Tolerance) para consenso, que determina quais validadores são economicamente elegíveis para participar e qual lidera cada slot. PoH fornece ordenação e tempo. Proof of Stake fornece segurança econômica e resistência a Sybil. Estas são funções distintas.

Para uma explicação completa de como o Proof of History funciona, incluindo sua construção criptográfica e sua relação com o mecanismo de consenso da Solana, veja nosso [explicador dedicado de Proof of History].

PoH fornece o relógio. Gulf Stream garante que a caixa de entrada do pipeline esteja sempre cheia.

Gulf Stream: Como as Transações Entram no Pipeline Antes que Ele Esteja Pronto

Gulf Stream é o protocolo de encaminhamento de transações da Solana, e é o que garante que a fase Fetch do pipeline nunca fique ociosa esperando que as transações cheguem. A maioria das blockchains mantém transações não confirmadas em uma mempool global, onde esperam que qualquer validador as colete. Solana não tem uma mempool global. Gulf Stream substitui este modelo por pré-roteamento determinístico.

O mecanismo funciona em quatro etapas:

1. O Cronograma de Líderes da Solana publica antecipadamente qual validador liderará cada slot de aproximadamente 400ms.
2. Quando um usuário ou aplicativo envia uma transação, Gulf Stream a roteia diretamente para o validador que liderará o próximo slot relevante, não para um pool compartilhado.
3. Quando o slot de líder desse validador começa, seu buffer da fase Fetch já está pré-carregado com transações.
4. A fase Fetch puxa desse buffer pré-carregado em vez de esperar que as transações cheguem durante o slot.

Este design sem mempool produz três benefícios mensuráveis: reduz a latência de confirmação porque as transações esperam menos tempo, elimina a sobrecarga de memória que mempools globais impõem a cada validador e reduz substancialmente os requisitos de memória por validador.

A contrapartida é significativa: como não há um buffer de transação persistente, transações que não são captadas rapidamente são descartadas em vez de enfileiradas. Usuários recebem um erro de "transação expirada" e precisam reenviar. Sob alta carga de rede, esse comportamento é um dos mecanismos que contribui para eventos de congestionamento, conforme discutido na seção de limitações.

Gulf Stream conecta diretamente ao estágio Fetch.

Gulf Stream pré-roteia transações para o líder seguinte usando o Cronograma Determinístico de Líderes. Quando o estágio TPU Fetch de um validador é ativado, ele puxa de um buffer pré-carregado, não de um mempool global. É por isso que o pipeline do Solana raramente espera por entrada no estágio Fetch em condições normais.

Se Gulf Stream é o mecanismo de entrada do pipeline, Turbine é o mecanismo de saída.

A Analogia do Pipeline da CPU: Por Que a Arquitetura do Solana Deve Parecer Familiar aos Engenheiros

O pipeline de transações do Solana utiliza o mesmo princípio arquitetônico que torna as CPUs modernas rápidas: o pipeline de nível de instrução. Isso não é uma metáfora. O design é arquiteturalmente inspirado na mesma técnica de vazão descrita no texto fundamental de Patterson e Hennessy, Computer Organization and Design.

Um pipeline de instrução de CPU funciona da seguinte maneira. Em vez de esperar que uma instrução conclua todas as fases de processamento antes de buscar a próxima, uma CPU divide a execução em fases sequenciais (Fetch, Decode, Execute, Write-back) e executa essas fases simultaneamente em diferentes instruções. Enquanto a instrução N está sendo executada, a instrução N+1 está sendo decodificada e a instrução N+2 já está sendo buscada. O resultado é que a vazão aumenta em proporção ao número de estágios do pipeline, sem exigir que nenhum estágio individual funcione mais rápido.

O pipeline TPU do Solana aplica este mesmo princípio às transações. O mapeamento estágio por estágio é direto:

[DIAGRAMA NECESSÁRIO: DIAGRAM-02] Diagrama de comparação lado a lado. Lado esquerdo: Pipeline de instrução de CPU com os estágios Fetch, Decode, Execute, Write-back e setas onduladas mostrando processamento concorrente de instruções. Lado direito: Pipeline TPU do Solana com os estágios Fetch, SigVerify, Banking, Writing e setas onduladas mostrando processamento de lote concorrente. Linhas de mapeamento entre estágios análogos.

Onde a analogia se mantém: Ambas as arquiteturas alcançam ganhos de vazão mantendo todos os estágios ocupados simultaneamente. Nenhuma espera que um item seja concluído antes de iniciar o próximo. Ambas processam itens em ondas, com múltiplos itens em diferentes estágios em qualquer momento. A percepção fundamental é idêntica: o processamento sequencial desperdiça a capacidade do hardware; o paralelismo de pipeline elimina esse desperdício.

Onde a analogia falha: Três diferenças importantes distinguem o pipeline do Solana de um pipeline de CPU.

Primeiro, o pipeline do Solana opera em componentes de hardware distribuídos conectados por uma rede, não dentro de um único chip. As condições de rede afetam o desempenho do pipeline de maneiras que não têm análogo na CPU. Segundo, os modos de falha são diferentes.

Segundo, os modos de falha diferem. Os perigos do pipeline da CPU incluem dependências de dados (uma instrução precisa da saída de uma instrução anterior que ainda não foi concluída) e predições incorretas de branch (o processador buscou instruções pelo caminho errado). Os perigos do pipeline do Solana são diferentes em tipo: spam de transação atua como um perigo estrutural ao sobrecarregar o estágio Banking além de sua capacidade de processamento, e congestionamento de rede atua como uma condição de stall que retarda os estágios Fetch e Writing. Estes são perigos externos, impulsionados pela demanda, em vez de perigos internos de dependência de dados.

Terceiro, o pipeline do Solana não tem equivalente para execução fora de ordem. O clock Proof of History impõe uma ordem estrita de transações dentro de cada lote, de modo que o pipeline não pode reordenar transações para evitar conflitos da maneira que uma CPU pode reordenar instruções para evitar perigos de dados.

Compreender esta analogia e seus limites é o que separa o conhecimento superficial da velocidade do Solana da verdadeira percepção arquitetônica.

Turbine: Como a Saída do Pipeline Chega à Rede

Turbine é o protocolo de propagação de blocos do Solana, e ele lida com o que acontece após a conclusão do estágio Writing do pipeline. Se Gulf Stream garante que o pipeline esteja sempre alimentado, Turbine garante que a saída do pipeline chegue ao resto da rede o mais eficientemente possível.

Após o estágio Writing confirmar um lote de transações confirmadas no ledger, Turbine divide o bloco resultante em pacotes de dados menores chamados shreds e os propaga por uma rede em árvore de validadores. Em vez de transmitir o bloco completo para todos os validadores simultaneamente (o que exigiria uma enorme largura de banda de uplink do líder), Turbine distribui a carga de propagação pela rede. Cada validador na árvore recebe um subconjunto de shreds e os encaminha para outros validadores mais abaixo na árvore, semelhante em princípio a como o BitTorrent distribui arquivos, tendo múltiplos nós compartilhando a carga de distribuição. (Turbine usa uma árvore estruturada em vez de um enxame peer-to-peer, o que é uma distinção importante para a confiabilidade da rede.)

O design compatível com pipeline é importante aqui: os shreds começam a se propagar para o resto da rede enquanto o validador líder já está processando o próximo lote de transações através do pipeline. A propagação de blocos e a produção de blocos rodam concorrentemente. A disseminação em nível de rede do bloco N não cria uma pausa na produção do bloco N+1.

O benefício de engenharia é que o Solana atinge alta largura de banda de blocos sem exigir uplink de nível empresarial em cada nó validador. Apenas o validador líder suporta a carga total de produção; a propagação é distribuída pela rede.

O invólucro de entrada/saída em torno do pipeline TPU:

Gulf Stream: entrada do pipeline (pré-roteia transações para o líder seguinte antes do início do slot). Turbine: saída do pipeline (distribui dados de bloco validados como shreds por uma rede de árvores de validadores). Juntos, eles garantem que o pipeline TPU nunca fique ocioso em nenhuma das pontas.

Turbine lida com a saída do pipeline no nível do bloco. Sealevel estende o princípio do pipeline mais profundamente, para a camada de execução de contrato inteligente.

Sealevel: Pipeline Estendido para Execução de Smart Contract

O pipeline de transações não para na TPU. Sealevel estende o mesmo princípio de processamento paralelo para a execução de contratos inteligentes, e é uma das vantagens arquiteturais mais subestimadas do Solana.

Sealevel é o runtime paralelo de contratos inteligentes do Solana. Ele permite que milhares de contratos inteligentes (chamados programas na arquitetura do Solana, uma distinção da terminologia do Ethereum que importa para os desenvolvedores) executem simultaneamente em vez de sequencialmente. A EVM (Ethereum Virtual Machine) do Ethereum processa contratos inteligentes em um único thread, significando que apenas um contrato pode executar por vez por bloco. Sealevel usa todos os núcleos de CPU disponíveis para executar múltiplos programas em paralelo.

O mecanismo depende do modelo de conta da Solana. Cada transação da Solana deve declarar antecipadamente de quais contas lerá e escreverá. O Sealevel usa essas declarações para agrupar transações em grupos não sobrepostos: transações que acessam contas diferentes podem ser executadas simultaneamente sem risco de conflitos de estado, enquanto transações que compartilham contas devem ser processadas sequencialmente para preservar a correção.

Este requisito de declaração antecipada é uma restrição de design que os desenvolvedores da Solana devem considerar ao arquitetar programas. Os programas devem pré-declarar todas as contas que acessarão, o que difere do modelo de acesso a estado mais permissivo da Ethereum, onde o acesso ao armazenamento do contrato não é declarado antecipadamente.

O paralelo com o pipeline da TPU é direto. Assim como o pipeline da TPU mantém todos os quatro estágios de hardware ocupados processando diferentes lotes de transações em diferentes estágios simultaneamente, o Sealevel mantém todos os núcleos de CPU disponíveis ocupados executando programas não conflitantes simultaneamente. O princípio de manter todo o hardware ocupado o tempo todo é aplicado aqui na camada de execução.

Para uma análise mais aprofundada de como as declarações de conta e o modelo de conta da Solana funcionam na prática, consulte nosso artigo [Modelo de Conta da Solana Explicado].

Solana vs. Ethereum: Uma Comparação de Arquitetura de Pipeline

A diferença de desempenho entre Solana e Ethereum remonta a uma escolha arquitetural fundamental: processamento de pipeline paralelo versus execução sequencial de transações.

A EVM da Ethereum processa transações em uma fila single-threaded. Uma transação deve ser concluída antes que a próxima comece. Este design é intencional: a execução sequencial simplifica o gerenciamento de estado, torna o comportamento de contratos inteligentes mais fácil de raciocinar e permite que validadores participem com hardware de nível de consumidor, produzindo um conjunto de validadores amplo e relativamente descentralizado. A Ethereum atualmente possui aproximadamente 900.000 ou mais validadores ativos.

Em contraste, o pipeline de TPU de pipeline paralelo da Solana processa vários lotes de transações simultaneamente em quatro estágios de hardware dedicados. A GPU acelera a verificação de assinatura. A CPU aplica mudanças de estado concorrentemente em programas não conflitantes via Sealevel. SSDs NVMe lidam com escritas enquanto o Turbine executa a propagação em paralelo. Este design produz uma taxa de transferência significativamente maior na Camada 1, mas exige muito mais hardware e cria um conjunto de validadores mais concentrado, com aproximadamente 2.000 validadores ativos.

Os números de desempenho são concretos. O tempo de bloco da Ethereum é de aproximadamente 12 segundos; o tempo de slot da Solana é de aproximadamente 400 milissegundos. A TPS da Camada 1 da Ethereum é de aproximadamente 15 a 30; a TPS real não-voto da Solana é de aproximadamente 2.000 a 4.000, dependendo das condições da rede. (O Bitcoin, para referência de escala, processa aproximadamente 7 transações por segundo.) As soluções de Camada 2 da Ethereum, incluindo Arbitrum e Optimism, aumentam dramaticamente a taxa de transferência efetiva da Ethereum além de sua linha de base da Camada 1, um contexto importante ao comparar cifras brutas da Camada 1.

Para uma análise detalhada de como essas arquiteturas se comparam em dimensões de investimento e desenvolvimento, consulte nossa comparação completa da arquitetura Solana vs. Ethereum.

Nenhuma arquitetura é categoricamente superior. Ambas representam trocas deliberadas dentro do amplamente citado Trilema da blockchain. A Ethereum trocou throughput por descentralização e um rico ecossistema de Camada 2. A Solana trocou descentralização por throughput na Camada 1. Qual troca serve melhor a uma aplicação ou tese de investimento específica depende dos requisitos específicos.

Limitações, Congestionamento e as Trocas Honestas da Arquitetura de Pipeline da Solana

A arquitetura de pipeline da Solana oferece vantagens de desempenho documentadas e carrega trocas documentadas. Compreender ambos é necessário para qualquer avaliação séria da rede, seja para desenvolvimento ou investimento.

Quando o Pipeline Fica Sobrecarregado: Como Funciona o Congestionamento

O congestionamento do pipeline ocorre quando o volume de transações excede a capacidade de processamento do estágio Banking. A sequência de eventos é específica. O estágio Banking fica para trás em relação ao volume de transações recebidas. Como o design Gulf Stream sem mempool da Solana não mantém um buffer de transações persistente, transações que não podem ser processadas rapidamente são descartadas em vez de enfileiradas. Os usuários recebem erros de "transação expirada" e precisam reenviar. Em níveis extremos de congestionamento, os validadores podem sair do consenso porque o pipeline não consegue processar transações de voto rápido o suficiente em relação ao volume total de transações, fazendo com que a rede trave.

A Solana sofreu grandes interrupções na rede em setembro de 2021, janeiro de 2022 e maio de 2022, entre outros períodos. As causas não foram uniformes. Em alguns casos, o volume excessivo de transações sobrecarregou a capacidade do estágio Banking. Em outros, a causa foram campanhas de spam de transações coordenadas, bugs de software ou falhas de consenso não relacionadas aos limites de throughput do pipeline. Atribuir todas as interrupções da Solana ao pipelining seria impreciso. Os limites de capacidade do pipeline, quando excedidos sob condições específicas, contribuíram para alguns eventos de interrupção, enquanto outras interrupções tiveram causas raiz separadas.

Para um histórico documentado dos eventos da rede Solana e suas causas, consulte nosso artigo [Interrupções na Rede Solana: Histórico e o que Elas Significam para Investidores].

A Solana fez várias mudanças arquiteturais desde 2022 para resolver o congestionamento do pipeline:

• Adoção do protocolo QUIC: A Solana substituiu a conexão UDP original no estágio Fetch pelo QUIC (um protocolo de transporte moderno que fornece controle de congestionamento e gerenciamento de conexão que o UDP não possui). O QUIC permite que o estágio Fetch gerencie a ingestão de transações de forma mais inteligente sob alta carga, reduzindo a eficácia do spam de transações de baixo custo.
• Qualidade de Serviço Ponderada pelo Stake (SWQoS): A Solana introduziu a qualidade de serviço ponderada pelo stake (SWQoS), que prioriza transações encaminhadas de validadores com maior peso de stake. Isso reduz a capacidade de atores de baixo stake de inundar o pipeline com transações de spam que consomem a capacidade do estágio Banking às custas de transações de usuários legítimos.
• Taxas de prioridade: Os usuários podem anexar taxas de prioridade às transações, sinalizando a disposição de pagar por processamento mais rápido através do pipeline durante períodos de alta demanda.
• Firedancer: Firedancer, uma implementação independente de cliente validador desenvolvida pela Jump Crypto, está em desenvolvimento e visa aumentar substancialmente o throughput do pipeline e melhorar a resiliência da rede, fornecendo um cliente alternativo que reduz o risco de implementação única.

A Troca da Centralização: Altos Requisitos de Hardware

Os altos requisitos de hardware para validadores da Solana produzem uma compensação de centralização mensurável. A execução do pipeline de TPU requer uma GPU empresarial para o estágio SigVerify, uma CPU com alto número de núcleos para o estágio Banking, SSDs NVMe empresariais para o estágio Writing e rede de alta largura de banda para Fetch e Turbine. Essas especificações criam barreiras de custo significativas para validadores domésticos.

O resultado é um conjunto de validadores mais concentrado do que o da Ethereum. A Solana tem aproximadamente 2.000 validadores ativos; a Ethereum tem aproximadamente 900.000 ou mais (ambos os números flutuam e devem ser verificados em relação aos dados atuais da rede). A Solana Labs e a Solana Foundation reconheceram explicitamente essa compensação: os requisitos de hardware são uma consequência deliberada da escolha de design focada em rendimento, representando a posição da Solana no eixo escalabilidade-descentralização do Trilema da blockchain. Se essa compensação é aceitável depende do que o avaliador prioriza.

Perguntas Frequentes: Pipeline de Transações da Solana

O que é a Unidade de Processamento de Transações (TPU) da Solana?

A Unidade de Processamento de Transações (TPU) da Solana é o mecanismo de pipeline dentro de um nó validador que processa fisicamente as transações. É um termo da Solana, totalmente não relacionado à Unidade de Processamento de Tensor (TPU) do Google usada em aprendizado de máquina. A TPU é executada apenas no validador líder para cada slot de ~400ms e opera através de quatro estágios: Fetch, SigVerify, Banking e Writing. Validadores que não são líderes executam a TVU (Transaction Validation Unit) para verificar e repetir blocos em vez disso.

O que é Proof of History e como ele se relaciona com o pipeline?

Proof of History (PoH) é um relógio criptográfico que produz uma sequência de hashes SHA-256 verificável e ordenada no tempo. O PoH permite o pipeline ao eliminar a necessidade de os validadores se comunicarem e concordarem com a ordenação das transações antes de avançar em cada estágio do pipeline. Sem o PoH, os atrasos na comunicação entre nós seriam o gargalo dominante; com o PoH, o pipeline avança com base em um relógio compartilhado e verificável localmente que não exige ida e volta na rede.

O que é Gulf Stream na Solana?

Gulf Stream é o protocolo de encaminhamento de transações sem mempool da Solana. Em vez de manter transações não confirmadas em um pool global, o Gulf Stream usa o Cronograma de Líder determinístico para rotear transações diretamente para o próximo validador líder antes do início de seu slot. Quando o estágio Fetch do líder é ativado, ele puxa de um buffer pré-carregado. Esse pré-roteamento é o motivo pelo qual a Solana pode sustentar tempos de slot de ~400ms sem que o estágio Fetch espere pelas transações chegarem.

O que é Sealevel?

Sealevel é o tempo de execução de Smart Contract paralelo da Solana. Ele permite que milhares de Smart Contracts (chamados de programas na arquitetura da Solana) sejam executados simultaneamente, exigindo que cada transação declare antecipadamente quais contas lerá e escreverá. O Sealevel identifica transações que não se sobrepõem e as executa em paralelo em todos os núcleos de CPU disponíveis, estendendo o mesmo princípio de processamento paralelo do pipeline de TPU para a camada de execução de Smart Contract.

O TPS teórico da Solana é de aproximadamente 65.000, representando o máximo do pipeline sob condições ideais, de acordo com a documentação técnica da Solana. O TPS real de não-voto normalmente varia de 2.000 a 4.000, dependendo da carga da rede, da composição do tipo de transação e do desempenho do validador. A Solana conta as transações de voto do validador separadamente das transações geradas pelo usuário; o total, incluindo votos, é maior, mas menos significativo como métrica de desempenho voltada para o usuário.

Como a Solana é mais rápida que a Ethereum?

O pipeline de TPU paralelo de quatro estágios da Solana processa vários lotes de transações simultaneamente, enquanto a EVM da Ethereum processa transações sequencialmente em um único thread. O resultado: o tempo de slot da Solana é de aproximadamente 400 milissegundos contra o tempo de bloco de ~12 segundos da Ethereum, e o TPS de Camada 1 da Solana é de aproximadamente 2.000 a 4.000 contra ~15 a 30 da Ethereum. Ambas as arquiteturas representam escolhas de design deliberadas com diferentes compensações no Trilema da blockchain.

O que acontece quando o pipeline da Solana fica congestionado?

Quando o volume de transações excede a capacidade de processamento do estágio bancário (Banking), a Solana descarta transações em vez de enfileirá-las, porque o design Gulf Stream sem mempool não mantém um buffer persistente. As transações afetadas retornam um erro de "transação expirada" e devem ser reenviadas. Em congestionamentos graves, o processamento de transações de voto pode atrasar, fazendo com que os validadores percam o consenso. QUIC e SWQoS reduzem o impacto do congestionamento impulsionado por spam, embora o limite de capacidade subjacente continue sendo uma compensação arquitetônica conhecida.

Explore SOL na Bybit

Use a página de preços da Solana para analisar os dados atuais do mercado de SOL, ou acesse o mercado de Spot Trading SOL/USDT se o trading spot corresponder aos seus objetivos. A atividade de trading na Bybit não é o mesmo que enviar uma transação Solana on-chain; taxas de rede ainda podem ser aplicadas ao depositar ou sacar SOL na rede Solana.

Traders experientes de derivativos também podem revisar o mercado perpétuo SOLUSDT.. Derivativos envolvem riscos adicionais e não fornecem a propriedade de SOL em spot.

Pipeline de Transações da Solana e a Tese de Investimento em SOL

O pipeline de transações da Solana é uma inovação arquitetônica real, não uma afirmação de marketing. O pipeline de TPU de quatro estágios representa uma abordagem de engenharia coerente para o rendimento da Camada 1. O Proof of History fornece o relógio criptográfico que permite que o pipeline avance sem atrasos de consenso da rede. O Gulf Stream pré-carrega a entrada do pipeline. O Turbine distribui a saída do pipeline. O Sealevel leva o mesmo princípio de paralelismo para a execução de Smart Contract.

Para investidores que possuem ou avaliam a Solana (SOL), entender o pipeline significa entender a base técnica da diferenciação de desempenho da Solana. A vantagem de velocidade da arquitetura é estrutural, não incidental. Ela deriva de escolhas específicas de engenharia sobre como aplicar princípios de processamento paralelo em cada camada do ciclo de vida da transação.

Essas escolhas de engenharia trazem compensações genuínas. Os eventos de congestionamento de 2021 e 2022 demonstraram que o design sem mempool e o teto de rendimento do estágio bancário são restrições reais sob condições de carga adversa ou extrema. Os altos requisitos de hardware para validadores produzem um conjunto de validadores mais concentrado do que o da Ethereum, representando uma posição deliberada no eixo escalabilidade-descentralização do Trilema da blockchain. A evolução arquitetônica contínua da Solana, incluindo a adoção do QUIC, a implementação do SWQoS e o cliente Firedancer em desenvolvimento pela Jump Crypto, reflete um protocolo que trabalha ativamente para elevar esses limites. Estes representam trajetórias de desenvolvimento, não problemas resolvidos.

O rendimento do pipeline da Solana tornou-a uma plataforma significativa para aplicações DeFi que exigem finalização de transação em menos de um segundo. A Ethereum continua sendo uma escolha arquitetônica válida com prioridades diferentes: descentralização mais ampla, um ecossistema de Camada 2 maduro e uma base de desenvolvedores maior. Ambas as redes ocupam posições distintas entre as blockchains de produção.

Aviso Legal: Este artigo é apenas para fins educacionais e não constitui aconselhamento de investimento, financeiro, comercial ou qualquer outra forma de aconselhamento. Solana (SOL) é uma Criptomoeda. Criptomoedas são ativos altamente voláteis e carregam um risco significativo de perda. Sempre realize sua própria pesquisa e consulte um consultor financeiro qualificado antes de tomar decisões de investimento.

Leitura relacionada deste grupo de tópicos:

• Solana vs. Ethereum: Comparação Completa de Arquitetura: comparação completa de arquitetura Solana vs. Ethereum