Pipeline de Transações Solana: Pipeline de 4 Fases da TPU

Este guia técnico explica o pipeline de transações Solana, o pipeline de 4 fases da TPU e como 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 o faz.

O pipeline de transações Solana é o método pelo qual a Unidade de Processamento de Transações da Solana move as transações recebidas através de quatro fases sequenciais: Fetch (Busca), SigVerify (Verificação de Assinatura), Banking (Contabilidade) e Writing (Escrita). Múltiplos lotes de transações passam por estas fases simultaneamente, de modo que, enquanto um lote está a ser escrito no ledger, o próximo já está a ser validado e um terceiro já está a ser buscado. Este processamento paralelo é o que permite que a Solana (SOL), o ativo nativo da blockchain Solana (o ledger distribuído onde todas as transações são registadas), alcance figuras de taxa de transferência que excedem em muito a maioria das redes de Camada 1.

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

O amplamente citado Blockchain Trilema defende que as blockchains podem priorizar apenas duas de três propriedades: escalabilidade, segurança e descentralização. O pipeline de transações da Solana é a sua resposta arquitetónica à dimensão da escalabilidade. Este artigo cobre o que é o pipeline, como as quatro fases da TPU funcionam mecanicamente, como a Prova de História possibilita o pipeline, como Gulf Stream e Turbine envolvem a entrada e saída do pipeline, como Sealevel estende o princípio do pipeline à execução de contratos inteligentes, como a Solana se compara à Ethereum arquiteturalmente, e quais são as trocas e limites documentados do pipeline.

Conteúdos

1. O que é o Pipeline de Transações Solana? (E porque é importante para SOL)
2. Como funciona o Pipeline TPU da Solana: As Quatro Fases Explicadas
3. Prova de História: O Relógio Criptográfico que Torna o Pipeline Possível
4. Gulf Stream: Como as Transações Entram no Pipeline Antes de Estar Pronto
5. A Analogia do Pipeline de CPU: Porque a Arquitetura da Solana Deve Parecer Familiar aos Engenheiros
6. Turbine: Como a Saída do Pipeline Atinge a Rede
7. Sealevel: Pipeline Estendido para a Execução de Smart Contract
8. Solana vs. Ethereum: Uma Comparação da Arquitetura de Pipeline
9. Limitações, Congestionamento e as Trocas Honestas da Arquitetura de Pipeline da Solana
10. Perguntas Frequentes sobre o Pipeline de Transações Solana
11. Pipeline de Transações Solana e a Tese de Investimento SOL

O que é o Pipeline de Transações Solana? (E porque é importante para SOL)

O pipeline de transações Solana é a técnica de dividir o processamento de transações em fases distintas e executar essas fases em simultâneo em vários lotes de transações, de modo que nenhuma peça de hardware do validador permaneça ociosa à espera que outra fase termine. Pense nisso como uma linha de montagem de automóveis: veículos diferentes estão em diferentes estações simultaneamente, e a linha nunca para para que um carro seja completamente concluído antes que o próximo entre.

A Solana inspirou-se nos processadores de computador. As CPUs modernas alcançam alta taxa de transferência através do pipeline a nível de instrução: enquanto uma instrução está a ser executada, a próxima está a ser decodificada e a seguinte já está a ser buscada. A Solana aplica a mesma lógica às transações ao nível do validador. O mapeamento completo das fases da CPU para as fases da TPU da Solana é coberto na secção de analogia da CPU abaixo, mas o princípio central é idêntico: manter todas as fases ocupadas em todos os momentos.

A maioria das blockchains processa transações sequencialmente, o que significa que um validador deve completar todo o processamento de uma transação (ou lote) antes de iniciar a próxima. Este modelo sequencial cria um teto de taxa de transferência determinado inteiramente pela velocidade com que uma única cadeia de operações pode ser executada. O pipeline quebra esse teto executando várias operações em paralelo através de 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 rapidamente.

A taxa de transferência teórica da Solana (TPS), de acordo com a documentação técnica da Solana, é de aproximadamente 65.000 transações por segundo. Isso representa o máximo do pipeline em condições ideais. O TPS real de transações não de votação é substancialmente inferior, geralmente variando entre 2.000 e 4.000 TPS, dependendo da carga da rede e da composição das transações. A Solana conta as transações de votação do validador separadamente das transações de não votação geradas pelo utilizador; o número total de TPS, incluindo votações, é maior, mas menos significativo como métrica de taxa de transferência voltada para o utilizador. Para comparação, o Ethereum processa aproximadamente 15 a 30 transações por segundo na Camada 1, e o Bitcoin processa aproximadamente 7 transações por segundo.

Estatísticas Chave

O pipeline TPU da Solana produz um novo bloco a cada ~400ms, aproximadamente 30x mais rápido que o tempo de bloco de ~12 segundos do Ethereum. TPS Teórico: ~65.000. TPS real de não votação: ~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. A taxa de transferência real de não votação varia com as condições da rede. As transações de votação são excluídas do valor de 2.000-4.000. Os valores do Ethereum representam a taxa de transferência da Camada 1 e excluem soluções da Camada 2.

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

Como funciona o Pipeline TPU da Solana: As Quatro Fases Explicadas

O mecanismo por trás da velocidade da Solana é um pipeline de quatro fases alojado na Unidade de Processamento de Transações (TPU), que é executado dentro do validador líder para cada slot, processando múltiplos lotes de transações simultaneamente através de hardware dedicado em cada fase.

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 de transações. Este é um termo específico da Solana e não está relacionado com a Unidade de Processamento Tensorial do Google usada em machine learning.

A TPU corre exclusivamente no validador líder de cada slot de ~400ms. Os validadores não-líderes correm a Unidade de Validação de Transações (TVU), que reproduz e verifica os blocos produzidos pelo líder. A Solana determina qual o validador que atua como líder através de um Programa de Líderes determinístico, publicado antecipadamente para cada época (aproximadamente 2 a 3 dias), que atribui os slots de liderança de cada validador com base no seu peso de staking (staked weight). Este programa é o que torna possível o pré-encaminhamento de transações do Gulf Stream, conforme discutido na secção Gulf Stream abaixo.

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

As Quatro Etapas da Pipeline da TPU da Solana

A pipeline da TPU processa transações através de quatro etapas sequenciais, cada uma gerida por hardware dedicado, cada uma passando a sua produção para a etapa seguinte enquanto recebe simultaneamente novos dados da etapa anterior.

1. Fetch (Recolha): A stack de rede recebe pacotes de transações em bruto via QUIC (um protocolo de transporte moderno que substituiu a ligação UDP original para um melhor controlo de congestionamento). A etapa Fetch é a doca de entrada da pipeline. Esta retira transações do buffer pré-carregado que o Gulf Stream já preencheu (filled) antes do slot começar, e passa os pacotes verificados para a SigVerify.

2. SigVerify (Verificação de Assinatura): O 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 assinaturas sejam executadas em paralelo dentro desta única etapa. A SigVerify é o ponto de verificação de autenticação: as transações que passam movem-se para a Banking; as transações que falham são descartadas.

3. Banking (Operações Bancárias): O CPU aplica as transações validadas ao estado do livro-razão (ledger state), executando débitos e créditos de conta e processando alterações de estado de Smart Contract. A Banking é o departamento de contabilidade da pipeline e a etapa computacionalmente mais intensiva. É também o principal gargalo sob carga elevada: quando o volume de transações excede a capacidade de processamento da Banking, a pipeline começa a descartar transações em vez de as colocar em fila.

4. Writing (Escrita): Os SSDs NVMe escrevem as entradas confirmadas do livro-razão no disco, e a etapa transmite os dados do bloco resultante para o resto da rede via Turbine. A Writing é a etapa de despacho e registos: assim que termina, o bloco existe na blockchain e a propagação começa.

A mecânica central da pipeline opera nas quatro etapas simultaneamente. Enquanto o lote N está na Banking, o lote N-1 já está na Writing, e o lote N+1 já está na SigVerify. Nenhuma etapa espera que outra termine o seu lote atual antes de iniciar o próximo. É assim que a pipeline alcança o rendimento (throughput) paralelo: cada peça de hardware está ocupada em cada momento do slot.

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

Quem corre a Pipeline? Validadores e o Programa de Líderes

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

O Programa de Líderes atribui qual o validador que corre a TPU para cada slot de ~400ms. O programa é calculado de forma determinística a partir do conjunto de validadores ponderado por stake no início de cada época, para que os validadores conheçam os seus próximos slots de liderança com dias de antecedência. Esta previsibilidade permite ao Gulf Stream pré-encaminhar transações para o próximo líder antes do seu slot começar, garantindo que o buffer da etapa Fetch está cheio quando o slot se inicia.

Correr a pipeline da TPU exige hardware de classe empresarial: um GPU dedicado para a etapa SigVerify, um CPU com elevado número de núcleos para a etapa Banking, SSDs NVMe empresariais para a etapa Writing e rede de alta largura de banda para a etapa Fetch. Estes requisitos são substancialmente mais elevados do que os limites de hardware para validadores de Ethereum, o que cria um compromisso de centralização abordado na secção de limitações. Para as especificações atuais de hardware para validadores, consulte a documentação de requisitos de validador da Solana.

Proof of History: O Relógio Criptográfico que Torna a Pipeline Possível

Proof of History (PoH) é o mecanismo criptográfico que permite que a pipeline da Solana corra tão rápido quanto o hardware permitir, sem exigir que os validadores comuniquem entre si para concordar com o timing de cada lote de transações antes de avançar para a etapa seguinte.

O mecanismo funciona da seguinte forma: o PoH produz uma sequência contínua de hashes SHA-256, onde cada hash utiliza o hash anterior como entrada. Como a computação SHA-256 demora um tempo mensurável e verificável, a sequência de hashes resultante constitui uma prova criptográfica de que passou um determinado período de tempo entre quaisquer dois eventos registados na cadeia. Cada validador pode verificar independentemente esta sequência sem contactar outros validadores.

A ligação à pipeline é direta. Sem o PoH, a pipeline precisaria de fazer uma pausa em cada etapa e esperar que a rede chegasse a consenso sobre a ordenação do lote de transações atual antes que a etapa seguinte pudesse começar. Essa ida e volta de comunicação entre nós seria o fator de latência dominante, tornando impossíveis os tempos de slot de 400ms à escala da rede. O PoH elimina esta espera ao fornecer um relógio partilhado e verificável que todos os validadores podem consultar localmente. A pipeline avança com base no relógio PoH, e não em comunicações de rede.

Anatoly Yakovenko introduziu a Proof of History no Whitepaper da Proof of History publicado em 2017, baseando-se na sua experiência em sistemas distribuídos durante o 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. A Solana utiliza Proof of Stake (especificamente Tower BFT, a sua implementação de Practical Byzantine Fault Tolerance) para o consenso, que determina quais os validadores que são economicamente elegíveis para participar e qual deles lidera cada slot. O PoH fornece a ordenação e o timing. O Proof of Stake fornece a segurança económica e a resistência a ataques Sybil. Estas são funções distintas.

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

O PoH fornece o relógio. O Gulf Stream garante que a caixa de entrada da pipeline está sempre cheia.

Gulf Stream: Como as Transações Entram na Pipeline Antes de Estar Pronta

O Gulf Stream é o protocolo de encaminhamento de transações da Solana, e é o que garante que a etapa Fetch da pipeline nunca esteja inativa à espera que as transações cheguem. A maioria das blockchains mantém as transações não confirmadas num mempool global, onde estas esperam que qualquer validador as recolha. A Solana não tem um mempool global. O Gulf Stream substitui este modelo pelo pré-encaminhamento determinístico.

O mecanismo funciona em quatro passos:

1. O Programa de Líderes da Solana publica, antecipadamente, qual o validador que irá liderar cada slot de ~400ms seguinte.
2. Quando um utilizador ou aplicação submete uma transação, o Gulf Stream encaminha-a diretamente para o validador que irá liderar o próximo slot relevante, e não para um pool partilhado.
3. No momento em que o slot de liderança desse validador começa, o buffer da sua etapa Fetch já está pré-carregado com transações.
4. A etapa Fetch retira transações deste 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 passam menos tempo à espera, elimina a sobrecarga de memória que as mempools globais impõem a cada validador e reduz substancialmente os requisitos de memória por validador.

A contrapartida é significativa: porque não existe um buffer de transações persistente, as transações que não são recolhidas rapidamente são descartadas em vez de colocadas em fila. Os utilizadores recebem um erro de "transação expirada" e têm de reenviar. Sob carga elevada da rede, este comportamento é um dos mecanismos que contribui para eventos de congestionamento, como discutido na secção de limitações.

Gulf Stream liga-se diretamente à fase Fetch.

O Gulf Stream pré-roteia as transações para o próximo líder utilizando o Agendamento de Líderes determinístico. Quando a fase Fetch de um validador de TPU é ativada, esta recolhe de um buffer pré-carregado, não de uma mempool global. É por isso que o pipeline da Solana raramente espera por entrada na fase Fetch em condições normais.

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

A Analogia do Pipeline da CPU: Porquê a Arquitetura da Solana Deve Parecer Familiar aos Engenheiros

O pipeline de transações da Solana utiliza o mesmo princípio arquitetónico que torna as CPUs modernas rápidas: o pipeline a nível de instrução. Isto não é uma metáfora. O design é arquitetonicamente inspirado pela mesma técnica de débito descrita no texto fundamental de Patterson e Hennessy, Computer Organization and Design.

Um pipeline de instruções de CPU funciona da seguinte forma. Em vez de esperar que uma instrução complete 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 instruções diferentes. Enquanto a instrução N está a ser executada, a instrução N+1 está a ser decodificada e a instrução N+2 já está a ser buscada. O resultado é que o débito aumenta em proporção ao número de fases do pipeline, sem exigir que nenhuma fase individual funcione mais rápido.

O pipeline TPU da Solana aplica este mesmo princípio às transações. O mapeamento fase a fase é direto:

[DIAGRAMA NECESSÁRIO: DIAGRAMA-02] Diagrama de comparação lado a lado. Lado esquerdo: pipeline de instruções da CPU com fases Fetch, Decode, Execute, Write-back e setas onduladas mostrando o processamento simultâneo de instruções. Lado direito: pipeline TPU da Solana com fases Fetch, SigVerify, Banking, Writing e setas onduladas mostrando o processamento simultâneo de lotes. Linhas de mapeamento entre fases análogas.

Onde a analogia se mantém: Ambas as arquiteturas obtêm ganhos de débito mantendo todas as fases ocupadas 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 fases a qualquer momento. A perspetiva fundamental é idêntica: o processamento sequencial desperdiça capacidade de hardware; o paralelismo de pipeline elimina esse desperdício.

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

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

Segundo, os modos de falha diferem. Os perigos do pipeline da CPU incluem dependências de dados (uma instrução necessita da saída de uma instrução anterior que ainda não foi concluída) e predições de ramificação incorretas (o processador buscou instruções pelo caminho errado). Os perigos do pipeline da Solana são de natureza diferente: spam de transações atua como um perigo estrutural ao sobrecarregar a fase Banking para além da sua capacidade de processamento, e o congestionamento da rede atua como uma condição de paragem que retarda as fases Fetch e Writing. Estes são perigos externos, orientados pela procura, em vez de perigos internos de dependência de dados.

Terceiro, o pipeline da Solana não tem um equivalente à execução fora de ordem. O relógio Proof of History impõe uma ordenação rigorosa das transações dentro de cada lote, pelo que o pipeline não pode reordenar transações para evitar conflitos da forma como uma CPU pode reordenar instruções para evitar perigos de dados.

Compreender esta analogia e os seus limites é o que separa o conhecimento superficial da velocidade da Solana da perspetiva arquitetónica genuína.

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

O Turbine é o protocolo de propagação de blocos da Solana e trata do que acontece após a conclusão da fase Writing do pipeline. Se o Gulf Stream garante que o pipeline está sempre alimentado, o Turbine garante que a saída do pipeline chega ao resto da rede da forma mais eficiente possível.

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

O design compatível com pipelines é importante aqui: os shreds começam a propagar-se para o resto da rede enquanto o validador líder já está a processar o próximo lote de transações através do pipeline. A propagação de blocos e a produção de blocos funcionam em simultâneo. A disseminação a 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 a Solana atinge uma largura de banda de bloco elevada sem exigir um uplink de nível empresarial em cada nó validador. Apenas o validador líder suporta toda a carga 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 próximo líder antes do início do slot). Turbine: saída do pipeline (distribui dados validados do bloco como shreds através de uma rede de árvores de validadores). Juntos, garantem que o pipeline TPU nunca está inativo em nenhuma das extremidades.

O Turbine trata da saída do pipeline ao nível do bloco. O Sealevel estende o princípio do pipeline mais profundamente, para a camada de execução de contratos inteligentes.

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

O pipeline de transações não para no TPU. O Sealevel estende o mesmo princípio de processamento paralelo à execução de contratos inteligentes, e é uma das vantagens arquitetónicas mais subestimadas da Solana.

O Sealevel é o runtime de contratos inteligentes paralelo da Solana. Permite que milhares de contratos inteligentes (chamados programas na arquitetura da 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 num único thread, o que significa que apenas um contrato pode executar de cada vez por bloco. O 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 na Solana deve declarar antecipadamente as contas de que fará a leitura e nas quais fará a escrita. O Sealevel utiliza estas declarações para ordenar as transações em grupos que não se sobrepõem: as transações que acedem a contas diferentes podem ser executadas simultaneamente sem risco de conflitos de estado, enquanto as transações que partilham contas devem ser processadas sequencialmente para preservar a correção.

Este requisito de declaração antecipada é uma restrição de design que os programadores da Solana devem ter em conta ao arquitetar programas. Os programas devem pré-declarar todas as contas a que acederão, o que difere do modelo de acesso ao estado mais permissivo da Ethereum, onde o acesso ao armazenamento de contratos não é declarado com antecedência.

O paralelo com o pipelining de TPU é direto. Tal como a pipeline da TPU mantém as quatro fases de hardware ocupadas processando simultaneamente diferentes lotes de transações em fases distintas, 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 em todos os momentos é aplicado aqui na camada de execução.

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

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

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

A EVM da Ethereum processa transações numa fila de thread única. Uma transação deve ser concluída antes que a próxima comece. Este design é intencional: a execução sequencial simplifica a gestão do estado, torna o comportamento dos contratos inteligentes mais fácil de fundamentar e permite que os validadores participem com hardware de nível de consumidor, produzindo um conjunto de validadores amplo e relativamente descentralizado. A Ethereum tem atualmente aproximadamente 900.000 ou mais validadores ativos.

Em contrapartida, a pipeline de TPU paralela da Solana processa múltiplos lotes de transações simultaneamente em quatro fases de hardware dedicadas. A GPU acelera a verificação de assinaturas. A CPU aplica alterações de estado simultaneamente em programas não conflitantes através do Sealevel. Os SSDs NVMe gerem as escritas enquanto o Turbine executa a propagação em paralelo. Este design produz um rendimento de Camada 1 substancialmente superior, mas exige significativamente mais hardware e cria um conjunto de validadores mais concentrado, de aproximadamente 2.000 validadores ativos.

Os valores 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. O TPS de Camada 1 da Ethereum é de aproximadamente 15 a 30; o TPS real de não-votação da Solana é de aproximadamente 2.000 a 4.000, dependendo das condições da rede. (A 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 drasticamente o rendimento efetivo da Ethereum para além da sua base de Camada 1, um contexto importante ao comparar valores brutos de Camada 1.

Para uma análise detalhada de como estas arquiteturas se comparam nas dimensões de investimento e desenvolvimento, consulte a nossa full Solana vs. Ethereum architecture comparison.

Nenhuma das arquiteturas é categoricamente superior. Ambas representam compromissos deliberados dentro do amplamente citado Trilema da blockchain. A Ethereum trocou o rendimento pela descentralização e por um rico ecossistema de Camada 2. A Solana trocou a descentralização pelo rendimento da Camada 1. Qual o compromisso que melhor serve uma aplicação ou tese de investimento específica depende dos requisitos específicos.

Limitações, Congestionamento e os Compromissos Honestos da Arquitetura Pipeline da Solana

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

Quando a Pipeline Fica Sobrecarregada: Como Funciona o Congestionamento

O congestionamento da pipeline ocorre quando o volume de transações excede a capacidade de processamento da fase Banking. A sequência de eventos é específica. A fase Banking fica atrás do volume de transações recebidas. Como o design Gulf Stream da Solana, sem Mempool, não mantém um buffer de transações persistente, as transações que não podem ser processadas rapidamente são descartadas em vez de serem colocadas em fila. Os utilizadores recebem erros de "transação expirada" e devem submeter novamente. Em níveis extremos de congestionamento, os validadores podem sair do consenso porque a pipeline não consegue processar as transações de voto com rapidez suficiente em relação ao volume total de transações, causando a paralisação da rede.

A Solana sofreu grandes interrupções de 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 da fase Banking. Noutros, a causa foram campanhas coordenadas de spam de transações, bugs de software ou falhas de consenso não relacionadas com os limites de rendimento da pipeline. Atribuir todas as interrupções da Solana ao pipelining seria impreciso. Os limites de capacidade da pipeline, quando excedidos sob condições específicas, contribuíram para alguns eventos de interrupção, enquanto outras interrupções tiveram causas fundamentais distintas.

Para um histórico documentado dos eventos da rede Solana e das suas causas, consulte o nosso artigo [Solana Network Outages: History and What They Mean for Investors].

Respostas Arquitetónicas da Solana ao Congestionamento

A Solana efetuou várias alterações arquitetónicas desde 2022 para resolver o congestionamento da pipeline:

• Adoção do protocolo QUIC: A Solana substituiu a ligação UDP original na fase Fetch pelo QUIC (um protocolo de transporte moderno que fornece controlo de congestionamento e gestão de ligações que o UDP não possui). O QUIC permite que a fase Fetch gira a ingestão de transações de forma mais inteligente sob carga elevada, reduzindo a eficácia do spam de transações de baixo custo.
• Stake-Weighted Quality of Service (SWQoS): A Solana introduziu a qualidade de serviço ponderada por staking (SWQoS), que prioriza transações encaminhadas de validadores com maior peso de staking. Isto reduz a capacidade de intervenientes com baixo staking inundarem a pipeline com transações de spam que consomem a capacidade da fase Banking em detrimento das transações legítimas dos utilizadores.
• Taxas de prioridade: Os utilizadores podem anexar taxas de prioridade às transações, sinalizando a vontade de pagar por um processamento mais rápido através da pipeline durante períodos de elevada procura.
• Firedancer: O Firedancer, uma implementação independente de cliente validador desenvolvida pela Jump Cripto, está em desenvolvimento e visa aumentar substancialmente o rendimento da pipeline e melhorar a resiliência da rede, fornecendo um cliente alternativo que reduz o risco de implementação única.

O Compromisso da Centralização: Requisitos de Hardware Elevados

Os requisitos de hardware elevados dos validadores da Solana produzem um compromisso de centralização mensurável. Executar o pipeline TPU requer uma GPU empresarial para o estágio SigVerify, uma CPU de alta contagem 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. Estas especificações criam barreiras de custo significativas para validadores domésticos.

O resultado é um conjunto de validadores mais concentrado do que a 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 contra dados atuais da rede). Solana Labs e a Solana Foundation reconheceram explicitamente este compromisso: os requisitos de hardware são uma consequência deliberada da escolha de design com prioridade na taxa de transferência, representando a Posição da Solana no eixo escalabilidade-descentralização do Trilema da blockchain. Se este compromisso é 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 motor do pipeline dentro de um nó validador que processa fisicamente as transações. É o termo da Solana, inteiramente não relacionado com a Tensor Processing Unit do Google usada em machine learning. A TPU executa apenas no validador líder para cada slot de ~400ms e opera através de quatro estágios: Fetch, SigVerify, Banking e Writing. Validadores não líderes executam a TVU (Transaction Validation Unit) para verificar e reproduzir blocos em vez disso.

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

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

O que é Gulf Stream na Solana?

Gulf Stream é o protocolo de encaminhamento de transações da Solana sem mempool. Em vez de reter transações não confirmadas num pool global, o Gulf Stream usa o Horário Determinístico do Líder (Leader Schedule) para encaminhar transações diretamente para o líder iminente antes do início do seu slot. Quando o estágio Fetch do líder é ativado, ele retira de um buffer pré-carregado. Este pré-encaminhamento é a razão pela qual a Solana pode sustentar tempos de slot de ~400ms sem que o estágio Fetch espere pela chegada das transações.

O que é Sealevel?

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

O Pipeline de Transações da Solana causa interrupções na rede?

O congestionamento do pipeline contribuiu para algumas interrupções da Solana, mas não para todas. Quando o volume de transações excede a capacidade do estágio Banking, o design sem mempool faz com que as transações sejam descartadas em vez de colocadas em fila, e em congestionamento extremo, os validadores podem sair do consenso. A Solana também sofreu interrupções causadas por bugs de software, falhas de consenso e spam de transações coordenado não relacionado com limites de taxa de transferência do pipeline. A adoção de QUIC e SWQoS reduziram as falhas impulsionadas pelo congestionamento desde 2022.

Qual é o TPS real da Solana?

O TPS teórico da Solana é de aproximadamente 65.000, representando o máximo do pipeline em condições ideais, de acordo com a documentação técnica da Solana. O TPS real de transações não de voto varia tipicamente entre 2.000 e 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 dos validadores separadamente das transações geradas pelo utilizador; o total, incluindo votos, é superior, mas menos significativo como métrica de desempenho voltada para o utilizador.

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

O pipeline 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 num único thread. O resultado: o tempo de slot da Solana é de aproximadamente 400 milissegundos contra 12 segundos de tempo de bloco 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 compromissos 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 Banking, a Solana descarta transações em vez de as colocar em fila, 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 caso de congestionamento grave, o processamento de transações de voto pode atrasar-se, fazendo com que os validadores saiam do consenso. QUIC e SWQoS reduzem o impacto do congestionamento impulsionado por spam, embora o limite de capacidade subjacente permaneça um compromisso arquitetónico conhecido.

Explore SOL em Bybit

Utilize a página de preços da Solana) para rever os dados atuais do mercado SOL, ou aceda ao mercado SOL/USDT Spot) se o trading Spot corresponder aos seus objetivos. A atividade de negociação Bybit não é a mesma que submeter uma transação na blockchain da Solana; taxas de rede ainda podem ser aplicadas ao depositar ou levantar SOL na rede Solana.

Os traders de Derivativos experientes também podem rever o mercado perpétuo SOLUSDT.). Os Derivativos envolvem risco adicional e não proporcionam propriedade do SOL Spot.

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

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

Para investidores que detêm ou avaliam Solana (SOL), compreender o pipeline significa compreender a base técnica da diferenciação de desempenho da Solana. A vantagem de velocidade da arquitetura é estrutural, não incidental. Deriva de escolhas de engenharia específicas sobre como aplicar princípios de processamento paralelo em todas as camadas do ciclo de vida da transação.

Essas escolhas de engenharia acarretam compromissos genuínos. Os eventos de congestionamento de 2021 e 2022 demonstraram que o design sem mempool e o teto de taxa de transferência do estágio Banking são restrições reais sob condições de carga adversarial ou extrema. Os requisitos elevados de hardware dos validadores produzem um conjunto de validadores mais concentrado do que a 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 de QUIC, a implementação de SWQoS e o cliente Firedancer em desenvolvimento pela Jump Crypto, reflete um protocolo que trabalha ativamente para elevar esses limites. Estas representam trajetórias de desenvolvimento, não problemas resolvidos.

A taxa de transferência do pipeline da Solana tornou-a uma Plataforma significativa para aplicações DeFi que requerem finalidade de transação inferior a um segundo. A Ethereum continua a ser uma escolha arquitetónica válida com prioridades diferentes: maior descentralização, um ecossistema maduro de Camada-2 e uma base de desenvolvedores maior. Ambas as redes ocupam Posições distintas entre as blockchains de produção.

Perguntas Frequentes: Pipeline de Transações da Solana

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

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

Leitura relacionada deste cluster de tópicos:

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