Arquitetura Solana: 8 Inovações Por Trás da Velocidade da SOL

Nota de precisão: O desempenho da rede, contagem de validadores, taxas, funcionalidades do protocolo, suporte de carteira e integrações de terceiros mudam ao longo do tempo. Trate cifras datadas como instantâneos históricos e verifique a documentação primária atualizada.

A arquitetura Solana é frequentemente explicada através de oito ideias de design dos seus materiais técnicos iniciais. Algumas permanecem centrais, enquanto outras são propostas históricas ou evoluíram, pelo que este artigo distingue o modelo original das afirmações de desempenho atuais.

Os materiais iniciais da Solana agruparam a arquitetura em oito ideias destinadas a suportar a execução de alto rendimento. O desempenho atual, a propriedade da implementação, os componentes de software e os papéis organizacionais evoluem, pelo que este artigo trata a estrutura das "oito inovações" como um modelo explicativo histórico, em vez de uma especificação completa e atual.

Principais Conclusões

A arquitetura da Solana é construída sobre oito pilares, cada um resolvendo um gargalo de desempenho específico:

1. Proof of History (PoH) - O Motor de Marcação de Tempo da Solana: relógio criptográfico que marca eventos antes da execução do consenso
2. Tower BFT - Mecanismo de Consenso da Solana: mecanismo de consenso que utiliza marcações de tempo PoH na votação
3. Turbine - Propagação de Blocos em Escala: propagação de blocos que divide os blocos em pacotes mais pequenos
4. Gulf Stream - Reencaminhamento de Transações Sem Mempool: reencaminhamento de transações baseado em líderes agendados
5. Sealevel - Execução Paralela de Smart Contract: runtime de execução paralela de smart contract
6. Pipelining - Validação de Transações como uma Linha de Montagem: processamento de transações por estágios
7. Cloudbreak - Base de Dados de Contas Escalada Horizontalmente: base de dados de contas concebida para acesso concorrente

Nota de desempenho: Taxas de transações (TPS) teóricas históricas, tempo de slot alvo, confirmação, finalidade, taxas base e taxas de prioridade são medições diferentes. Verifique métricas atuais e datadas e a metodologia subjacente.

Compromisso honesto: A Solana tem sofrido interrupções de rede documentadas desde o lançamento da mainnet em março de 2020, e os seus requisitos de hardware de validador (128+ GB de RAM recomendados) criam pressão de centralização. Estes são compromissos arquitetónicos conhecidos, não problemas acidentais.

O Problema Que a Solana Foi Construída Para Resolver

As blockchains tradicionalmente enfrentam uma restrição fundamental: o trilema da blockchain, um conceito popularizado por Vitalik Buterin, afirma que uma rede pode simultaneamente atingir, no máximo, duas de três propriedades. Essas propriedades são escalabilidade (alto rendimento), segurança (resistência a ataques) e descentralização (controlo distribuído). Pense nisso como um triângulo onde empurrar um canto mais para longe sempre puxa os outros dois para dentro. O Bitcoin processa ~7 TPS com tempos de bloco de 10 minutos, priorizando segurança e descentralização ao custo de rendimento. O Ethereum processava ~15–30 TPS na sua camada base antes de as soluções de escalabilidade serem adicionadas, também priorizando segurança e descentralização.

Anatoly Yakovenko, um antigo engenheiro de sistemas distribuídos na Qualcomm, abordou esta restrição de forma diferente. Em novembro de 2017, publicou um whitepaper intitulado Proof of History: A Clock for Blockchain, descrevendo um mecanismo criptográfico de marcação de tempo que poderia reduzir drasticamente a sobrecarga de comunicação nos algoritmos de consenso. Greg Fitzgerald juntou-se como cofundador e CTO, e juntos construíram o protocolo que se tornou a Solana. A Solana Labs, a empresa com fins lucrativos que cofundaram, lidera o desenvolvimento do protocolo principal. A Solana Foundation, uma entidade separada sem fins lucrativos sediada em Genebra, financia subsídios para o ecossistema, programas de descentralização de validadores e iniciativas de educação.

A arquitetura de oito pilares da Solana foi concebida para empurrar o limite de escalabilidade o máximo possível dentro dessas restrições do trilema. O design aceita deliberadamente requisitos de hardware de validador mais elevados como custo desse rendimento. A Solana não resolve o trilema; ocupa uma posição invulgarmente agressiva no eixo da escalabilidade. Esses compromissos têm custos reais, examinados na secção de compromissos arquitetónicos abaixo.

Os Oito Pilares Arquitetónicos da Solana: Uma Visão Geral

A estrutura histórica de oito partes abrange Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak e Archivers. Nem todos os itens devem ser considerados como subsistemas implementados separadamente, particularmente a proposta Archivers.

1. Proof of History: uma cadeia sequencial de hash SHA-256 que cria um registo verificável de marcação de tempo antes da execução do consenso
2. Tower BFT: um mecanismo de consenso Byzantine Fault Tolerant (Tolerante a Falhas Bizantinas) aprimorado por PoH que utiliza marcações de tempo PoH para votar eficientemente
3. Turbine: um protocolo de propagação de blocos inspirado no BitTorrent que divide os blocos em pequenos pacotes com codificação de eliminação chamados 'shreds'
4. Gulf Stream: um protocolo de reencaminhamento de transações sem mempool que direciona as transações diretamente para os próximos líderes validadores
5. Sealevel: um runtime de execução paralela de smart contract que executa milhares de programas não conflituantes simultaneamente
6. Pipelining: um sistema de Otimização de Validação de Transações (TVO) que processa transações através de quatro estágios de hardware concorrentes
7. Cloudbreak: uma base de dados de contas escalada horizontalmente que utiliza ficheiros mapeados em memória para suportar leituras e escritas concorrentes
8. Archivers: uma proposta histórica para armazenamento de ledger distribuído utilizando conceitos de prova de replicação

Cada pilar é abordado em profundidade nas secções abaixo.

Proof of History (PoH): O Motor de Marcação de Tempo da Solana

Proof of History (PoH) é uma cadeia sequencial de hash SHA-256 que cria um registo verificável e ordenado no tempo de eventos antes da execução do consenso, atuando como um relógio criptográfico partilhado para toda a rede. PoH não é o mecanismo de consenso da Solana; esse papel pertence ao Tower BFT. PoH é a camada de marcação de tempo que torna o Tower BFT rápido.

Pense no PoH como um cronómetro criptográfico que prova quanto tempo passou entre eventos, sem exigir que cada validador na rede verifique primeiro os relógios uns dos outros. Nas redes blockchain tradicionais, os validadores devem trocar mensagens de marcação de tempo entre si durante cada ronda de consenso, adicionando sobrecarga de comunicação que cresce com o tamanho do conjunto de validadores. O PoH elimina completamente essa troca.

Tecnicamente, PoH é uma cadeia sequencial de hash SHA-256 onde cada saída se torna a entrada para a próxima computação. Como o SHA-256 não pode ser paralelizado nesta forma encadeada, o comprimento da cadeia é um registo inviolável do tempo decorrido. Um validador que produz uma cadeia de N hashes demonstrou ter gasto o tempo necessário para computar N operações de hash sequenciais. Não existe atalho. Anatoly Yakovenko descreveu pela primeira vez este mecanismo no seu whitepaper de novembro de 2017, Proof of History: A Clock for Blockchain.

A PoH funciona como uma Verifiable Delay Function (VDF): uma computação que demora uma quantidade de tempo previsível e sequencial a calcular, mas que pode ser verificada quase instantaneamente. Esta assimetria entre o tempo de computação e o tempo de verificação é o que torna a PoH prática. Os validadores podem transmitir o output da PoH e qualquer observador pode verificar a sua autenticidade em microssegundos, embora a sua produção tenha exigido tempo real decorrido. Esta é a propriedade que os investigadores académicos e analistas de protocolos reconhecerão como a base teórica das propriedades de segurança da PoH.

Ao estabelecer uma referência de ordenação verificável, a PoH pode reduzir alguma coordenação de temporização. Não remove as mensagens de consenso nem garante diretamente um determinado slot, confirmação ou tempo de finalização.

Uma clarificação crítica: a Solana é por vezes descrita como uma "Blockchain de Proof of History", sugerindo que a PoH substitui o Proof of Stake (PoS). Isto está incorreto. A Solana é uma blockchain de Proof of Stake na sua camada de segurança económica. Os validadores investem SOL em staking como colateral e enfrentam o slashing por comportamento desonesto. A PoH é o relógio criptográfico que torna o consenso PoS da Solana, implementado através do Tower BFT, mais rápido e eficiente. Ambas as camadas são necessárias; nenhuma substitui a outra.

Tower BFT: O Mecanismo de consenso da Solana

O Tower BFT é o Mecanismo de consenso da Solana: uma variante da Practical Byzantine Fault Tolerance (pBFT) otimizada pela PoH que utiliza o registo de carimbo temporal da PoH como um relógio partilhado, permitindo que os validadores votem no estado do livro-razão sem trocar mensagens de sincronização de relógio.

A Byzantine Fault Tolerance (BFT) descreve a propriedade de um sistema distribuído que lhe permite alcançar o consenso corretamente mesmo quando alguns participantes se comportam de forma maliciosa ou imprevisível, nomeada em homenagem ao problema dos Generais Bizantinos em computação distribuída. Os algoritmos pBFT tradicionais exigem a passagem extensiva de mensagens entre nós para estabelecer uma visão comum do tempo, o que os torna pouco práticos à escala. O Tower BFT substitui essa passagem de mensagens pelo registo de PoH. Os validadores já partilham o relógio de PoH; não precisam de negociar carimbos temporais.

Os validadores são participantes da rede que investem SOL em staking, validam transações, produzem blocos quando selecionados como líderes e votam no estado do livro-razão. Eles lançam votos com bloqueio temporal (time-locked) que crescem exponencialmente em Forks. Quanto mais tempo um validador votar num Fork específico, mais SOL corre o risco de perder através do slashing (o mecanismo de penalização que remove tokens em staking por comportamento desonesto ou inconsistente) se esse Fork for abandonado. Este mecanismo de bloqueio de voto cria fortes incentivos económicos para a participação honesta sem exigir rondas de comunicação adicionais.

O Tower BFT tolera que até um terço do conjunto de validadores tenha um comportamento Bizantino. Se menos de um terço dos validadores agir de forma maliciosa, a rede alcança o consenso correto. Este limiar deriva dos requisitos matemáticos do problema dos Generais Bizantinos, originalmente formalizado por Lamport, Shostak e Pease em 1982. A linhagem de consenso para investigadores: o pBFT (Castro e Liskov, 1999) estabeleceu o algoritmo fundamental; as variantes subsequentes, incluindo o HotStuff e o Tendermint, melhoraram-no; o Tower BFT (2017) dá o passo adicional de eliminar a sobrecarga de sincronização de relógio através da PoH.

Um tempo de slot alvo não deve ser apresentado como uma garantia de finalização. As aplicações devem distinguir entre os níveis de compromisso processado, confirmado e finalizado, e selecionar as regras de confirmação com base no seu modelo de risco.

Turbine: Propagação de Blocos à Escala

Transmitir um bloco completo para todos os validadores a uns teóricos 65.000 TPS criaria um estrangulamento de largura de banda que cresce linearmente com o tamanho da rede. O Turbine resolve isto da mesma forma que o BitTorrent resolve a distribuição de ficheiros grandes: dividindo os dados em pequenos pedaços e espalhando a carga de propagação por toda a rede.

O Turbine é o protocolo de propagação de blocos da Solana, inspirado no modelo de distribuição baseada em partes do BitTorrent. Em vez de um líder transmitir um bloco completo para todos os validadores simultaneamente, o Turbine divide os blocos em pequenos pacotes com código de eliminação (erasure-coded) chamados shreds e distribui-os através de uma rede de validadores estruturada em árvore.

Os shreds são codificados com erasure coding para redundância. Cada nó na árvore de propagação recebe um subconjunto de shreds, retransmite-os para a camada seguinte e reconstrói o bloco completo a partir do subconjunto que recebe. A codificação por eliminação significa que, mesmo que alguns shreds se percam na transmissão, o bloco ainda pode ser reconstruído a partir dos pacotes restantes. Os requisitos de largura de banda escalam logaritmicamente em vez de linearmente com o tamanho da rede, porque cada validador lida apenas com uma fração do total de dados do bloco.

A expansão do conjunto de validadores não aumenta proporcionalmente os requisitos de largura de banda por nó. Uma rede com 2.000 validadores não exige que cada validador lide com 2.000 vezes a largura de banda de um sistema Centralizada. A árvore de propagação distribui a carga. A estrutura de shreds do Turbine é relevante para os operadores de validadores ao planearem a capacidade de receção de dados e reconstrução de blocos.

Gulf Stream: Encaminhamento de Transações sem Mempool

O Gulf Stream utiliza encaminhamento consciente do líder em vez de um mempool global partilhado convencional. Isto altera o modelo de enfileiramento, mas não elimina o congestionamento ou os incentivos de ordenação de transações.

Na Ethereum, as transações não confirmadas aguardam no mempool: o pool partilhado de transações não confirmadas à espera de serem incluídas num bloco. Durante períodos de elevada procura, este pool torna-se uma fonte de congestionamento, escalada de taxas e Valor Máximo Extraível (MEV), o lucro extraído ao reordenar, inserir ou censurar transações dentro do mempool antes de serem finalizadas. Os utilizadores da Ethereum fazem um Bid (compra) de taxas de gas mais elevadas para priorizar as suas transações, razão pela qual as taxas historicamente atingiram os 5 a 50+ dólares durante os picos de utilização.

O design utiliza o calendário de líderes conhecido da Solana para encaminhar transações para os próximos líderes, em vez de as transmitir para um pool global convencional. Os validadores podem preparar transações antes da sua vez de produzir blocos, o que pode reduzir a latência de enfileiramento, mantendo o congestionamento, a competição de taxas, as falhas e o MEV como preocupações separadas.

O encaminhamento de transações consciente do líder altera a forma como as transações chegam aos líderes programados, mas não elimina o congestionamento, a competição por taxas de prioridade, o MEV, as transações perdidas ou a pressão sobre os recursos dos validadores. As taxas base e de prioridade atuais devem ser medidas diretamente em vez de serem convertidas num valor fixo em USD.

A ausência de um mempool altera os padrões de submissão de transações para os programadores que constroem na Solana. As transações têm um caminho de encaminhamento previsível, permitindo uma confirmação otimista antes da finalização total. A área de superfície de MEV na Solana é substancialmente menor do que na Ethereum, embora não seja nula; a ordenação de transações ponderada pelo Stake cria a sua própria dinâmica que os designers de dApps devem estudar antes de construir.

Sealevel: Execução Paralela de Smart Contract

O Sealevel é o runtime de execução paralela de contratos inteligentes da Solana, o motor que corre programas On-Chain (o termo da Solana para o que a Ethereum chama de contratos inteligentes). Ao contrário da EVM da Ethereum, que executa contratos sequencialmente um de cada vez, o Sealevel executa milhares de programas não conflituosos simultaneamente através dos núcleos de GPU e CPU disponíveis.

A EVM da Ethereum processa contratos inteligentes como uma única fila de caixa num supermercado: uma transação de cada vez, com cada cliente à espera atrás do anterior. O Sealevel abre vinte filas de caixa simultaneamente, processando transações não conflituosas em paralelo. Esta é a principal razão arquitetónica pela qual o rendimento da Solana excede o da Ethereum na camada base.

O paralelismo é possível porque o modelo de programação da Solana exige que cada transação declare, no momento da submissão, quais contas (os objetos de estado que armazenam dados na Solana) irá ler e escrever. O Sealevel analisa estas listas de acesso a contas para identificar transações não conflituantes: aquelas que tocam contas completamente diferentes podem ser executadas simultaneamente sem produzir alterações de estado conflitantes. As transações que partilham contas devem ser executadas sequencialmente. O runtime do Sealevel utiliza esta declaração para agendar a execução paralela ou sequencial em todos os núcleos de hardware disponíveis.

Os programas na blockchain são escritos principalmente em Rust, compilados para bytecode Berkeley Packet Filter (BPF) e executados pelo runtime Sealevel. A execução paralela em núcleos de GPU e CPU é o que torna os 65.000 TPS teóricos fisicamente alcançáveis ao nível do hardware.

O Que Isto Significa Para os Desenvolvedores

Quando implementa um programa na Solana, tem de declarar todas as contas que o seu programa irá ler e escrever no momento da submissão da transação. Esta lista de acesso a contas não é opcional; é o mecanismo que o Sealevel utiliza para agendar a execução paralela. Omitir ou declarar incorretamente as contas causa falhas nas transações.

Programas que partilham estado com outros programas (escrevendo nas mesmas contas) não podem beneficiar do paralelismo e serão sempre executados sequencialmente. Desenhe a estrutura de contas do seu programa para minimizar o estado partilhado sempre que possível. Programas com padrões de acesso a contas estreitos e sem sobreposição extraem o máximo benefício do agendador paralelo do Sealevel.

O framework Anchor, um kit de ferramentas baseado em Rust que fornece macros e abstrações que simplificam padrões de programas comuns, é o kit de ferramentas de desenvolvimento mais amplamente utilizado para programas Solana. Para documentação completa sobre o modelo de contas, endereços derivados de programas e o runtime Sealevel, consulte a documentação para desenvolvedores da Solana.)

Pipelining: Validação de Transações Como Uma Linha de Montagem

Uma linha de montagem de automóveis não constrói um carro completamente antes de começar o próximo. Cada estação (soldadura, pintura, montagem interior) trabalha num carro diferente simultaneamente. A Solana aplica esta mesma lógica à validação de transações através da Otimização da Validação de Transações (TVO - Transaction Validation Optimization).

O pipelining na Solana refere-se à TVO, uma aplicação da arquitetura de pipeline de CPU ao processamento de transações blockchain. O processo de validação de transações é dividido em quatro etapas discretas, cada uma tratada por uma unidade de hardware separada a operar em simultâneo. Enquanto um lote de transações se move através de uma etapa, o lote seguinte já está na etapa precedente.

As quatro etapas são:

1. Fetch (Obtenção): uma unidade em espaço de kernel recupera os dados da transação recebida da rede
2. Verificação de Assinatura (SigVerify): a GPU verifica assinaturas criptográficas em todo o lote em paralelo
3. Banking: a CPU processa a lógica da transação, verifica saldos de contas e atualiza o estado das contas
4. Confirmação de Escrita: o disco escreve as alterações de estado finalizadas

Enquanto o lote A está no Banking, o lote B está no SigVerify e o lote C está a ser obtido. Nenhum hardware fica ocioso à espera que o lote anterior termine. Esta staging contínua elimina o tempo ocioso da CPU entre as fases de processamento que, de outra forma, limitariam o débito.

O pipelining é um dos três pilares, juntamente com o Sealevel e o Gulf Stream, que juntos produzem a capacidade total de processamento de transações da Solana. A Solana extrai mais débito do mesmo hardware, mantendo todos os componentes de processamento a trabalhar a tempo inteiro, em vez de permitir que qualquer etapa fique ociosa entre lotes.

Cloudbreak: Base de Dados de Contas Escalada Horizontalmente

Cloudbreak é o sistema de ficheiros que permite aos processadores paralelos da Solana ler e escrever dados de contas simultaneamente sem filas. Sem ele, a camada de armazenamento serializaria todas as leituras e escritas de contas, e os ganhos de paralelismo do Sealevel evaporar-se-iam na fronteira da base de dados.

Cloudbreak é a base de dados de contas escalada horizontalmente da Solana: a estrutura de dados que armazena o estado de cada conta na rede. Utiliza ficheiros mapeados em memória e estruturas de dados otimizadas para SSD para suportar leituras e escritas simultâneas em múltiplos threads.

As contas são distribuídas por várias estruturas de dados acessíveis em paralelo. O I/O mapeado em memória do sistema operativo permite que o Cloudbreak trate os dados de contas residentes em disco como se estivessem na RAM, eliminando a latência de busca e permitindo acesso simultâneo ao nível do thread. Quando o Sealevel agenda 10.000 transações paralelas, o Cloudbreak serve 10.000 leituras e escritas de contas simultâneas sem serializar os pedidos numa fila.

A arquitetura da base de dados e o runtime de execução são interdependentes: nenhum deles fornece débito sem o outro. Os padrões de I/O do Cloudbreak exigem SSDs NVMe de alto desempenho. Discos rígidos convencionais não conseguem sustentar o débito de leitura/escrita aleatória que o modelo de acesso simultâneo do Cloudbreak exige. Compreender o modelo de contas do Cloudbreak é fundamental para o design de programas Solana: todo o estado reside em objetos de conta discretos, os programas operam de forma stateless sobre essas contas, e as decisões de layout da conta afetam diretamente o desempenho de leitura/escrita em runtime.

Arquivistas: Uma Proposta de Armazenamento Histórico

O conceito Arquivistas aparece em materiais de arquitetura iniciais da Solana, mas não deve ser apresentado como um subsistema de produção atualmente implementado sem evidências de fonte primária atual.

Materiais de design iniciais propuseram Arquivistas, também chamados Replicadores em algumas descrições, como participantes leves que armazenam porções de dados históricos do ledger e provam o armazenamento. Isto explica a abordagem original ao crescimento do ledger, mas não deve ser descrito como uma rede de produção ativa que recompensa sem confirmação atual de fonte primária. A infraestrutura atual de retenção e arquivamento de ledger tem de ser documentada separadamente.

Com os oito pilares arquitetónicos no lugar, o sistema combinado produz benchmarks de desempenho que distinguem a Solana da maioria das outras blockchains públicas, o que a secção seguinte quantifica.

Benchmarks de Desempenho da Solana: TPS, Taxas e Finalidade de Bloco

~65.000 TPS em benchmarks teóricos históricos é o máximo teórico da Solana em condições de laboratório ótimas, não um valor sustentado no mundo real. A distinção importa para quem utiliza estes números em análise de investimento ou design de sistemas.

Utilize fontes primárias atuais e uma metodologia de medição consistente para comparações de desempenho.

O débito da mainnet no mundo real corre abaixo do máximo teórico por várias razões. Nem todos os slots de transação preenchem completamente durante a procura normal. Mecanismos de filtragem de spam rejeitam transações de baixa qualidade antes de chegarem à fase de banking. As condições de rede afetam o tempo de propagação. Aproximar-se do teto teórico requer procura de pico sustentada combinada com utilização total do hardware em todo o conjunto de validadores, condições que ocorrem durante eventos específicos de alto tráfego em vez de continuamente.

O perfil de processamento da Solana provém de várias fontes arquitetónicas que trabalham em conjunto. O PoH fornece uma referência de ordenação verificável que pode reduzir a sobrecarga de coordenação temporal. O Sealevel executa trabalho não conflituante em paralelo. O encaminhamento ciente do líder (leader-aware forwarding) pode preparar transações antes da abertura de um bloco, reduzindo parte do congestionamento convencional na Mempool sem eliminar a latência da rede.

O ecossistema de Camada 2 da Ethereum (incluindo Arbitrum e Optimism) e futuras atualizações de sharding aumentam o processamento efetivo da Ethereum bem para além do valor da sua camada base. Qualquer comparação completa deve ter em conta essa capacidade expandida ao avaliar as duas plataformas para um caso de utilização específico.

Da Arquitetura à Aplicação: Como o Design da Solana Viabiliza Casos de Utilização Reais

As escolhas arquitetónicas da Solana produzem resultados específicos e mensuráveis para as aplicações construídas sobre elas, e não apenas números de desempenho abstratos.

NFTs: As taxas geralmente baixas da Solana e a execução paralela podem suportar a cunhagem (minting) de alto volume, mas as taxas de prioridade, os custos da aplicação, o congestionamento, as falhas e os padrões de ativos continuam a ser importantes. O Gulf Stream não elimina a competição por taxas.

DeFi: O runtime da Solana pode processar transações não conflituantes em paralelo, enquanto as taxas geralmente baixas podem suportar interações frequentes. A latência e o custo reais de um swap incluem o roteamento, Slippage, taxas de prioridade, transações falhadas, computação do programa e condições de mercado. O Gulf Stream não elimina o MEV ou o risco de front-running.

GameFi e microtransações: As taxas geralmente baixas podem suportar ações de pequeno valor, mas os custos totais da aplicação e as transações falhadas continuam a ser relevantes. Os custos da L1 e L2 da Ethereum devem ser comparados separadamente utilizando dados atuais.

Pagamentos: As aplicações de pagamento baseadas na Solana podem visar um Feedback rápido do utilizador, mas a aprovação da carteira, a confirmação otimista, a finalidade enraizada, a tolerância ao risco do comerciante e as operações Fora da blockchain são fases distintas. A autorização de cartões de crédito não é equivalente à Quitação em blockchains públicas.

As mesmas escolhas arquitetónicas que viabilizam estas aplicações também trazem compromissos documentados, que a secção seguinte examina sem reservas.

Compromissos Arquitetónicos: Fiabilidade da Rede, Descentralização e Velocidade

A Solana sofreu interrupções de rede documentadas desde o lançamento da Mainnet em março de 2020, causadas principalmente por inundações de transações geradas por Bots que sobrecarregaram a memória dos validadores e fizeram com que estes perdessem o consenso.

Interrupções de Rede

O design de alto processamento da Solana processa transações com uma pré-filtragem mínima, o que cria uma vulnerabilidade específica. Quando Bots inundam a rede com transações de spam, os validadores podem esgotar a memória disponível antes que as transações cheguem à fase de filtragem, causando paragens no consenso. As principais interrupções documentadas incluem uma interrupção em setembro de 2021 com a duração de aproximadamente 17 horas, desencadeada por um surto no volume de transações de um evento de IDO impulsionado por Bots, e uma interrupção em janeiro de 2022 relacionada com o excesso de transações duplicadas de validadores. Ocorreram interrupções curtas adicionais em 2022 e 2023.

A Solana Labs implementou duas mitigações arquitetónicas primárias. O protocolo de rede QUIC substituiu o UDP para a ingestão de transações, fornecendo um controlo de fluxo ao nível da ligação que limita o número de transações que uma única fonte pode submeter. O Quality of Service (QoS) ponderado por Staking prioriza o encaminhamento de transações de validadores com maiores quantidades de SOL a Investir em staking, tornando a inundação de spam por fontes com pouco Staking menos eficaz. Os mercados de taxas para unidades de computação criam fricção económica contra o spam em volumes elevados. A frequência das interrupções diminuiu desde que estas mitigações foram implementadas. O histórico de interrupções continua a ser um fator de risco conhecido para aplicações que exigem alta disponibilidade contínua.

Preocupações com a Centralização de Validadores

Os validadores da Solana exigem hardware significativo. De acordo com a documentação para validadores da Solana Foundation,), a especificação recomendada inclui mais de 128 GB de RAM, um SSD NVMe de alto desempenho e conectividade de internet de alta largura de banda. Verifique as especificações atuais no momento da leitura, uma vez que os requisitos evoluem com as atualizações do protocolo. Estes requisitos excedem substancialmente o que os validadores de Ethereum necessitam para participar no consenso PoS.

A barreira de hardware reduz o conjunto potencial de validadores a operadores com investimento de capital significativo. Os requisitos de hardware servem um propósito de engenharia real: são aquilo de que dependem as metas atuais de processamento. São também uma barreira genuína a uma participação mais ampla de validadores. A Solana Foundation financia programas de descentralização de validadores e subsídios para pequenos operadores, mas a tensão entre as metas de desempenho e os custos de hardware é uma característica estrutural do design, não um problema de política incidental.

Posicionamento no Trilema da blockchain

A Solana não elimina o Trilema da blockchain. A sua arquitetura representa uma escolha deliberada de priorizar a escalabilidade e manter a segurança, aceitando requisitos de hardware de validadores mais elevados que criam pressão sobre a descentralização. A Ethereum prioriza a descentralização e a segurança, abordando a escalabilidade através de soluções de Camada 2. A Bitcoin prioriza a segurança e a descentralização à custa de um processamento mínimo. Cada rede ocupa uma Posição de engenharia diferente dentro do mesmo trilema, e não existe nenhuma configuração que maximize as três dimensões simultaneamente.

O histórico de interrupções, as pressões de centralização decorrentes dos requisitos de hardware dos validadores e o posicionamento no trilema são contributos materiais para qualquer avaliação técnica rigorosa da rede Solana.

Solana vs. Ethereum vs. Bitcoin: Comparação de Arquiteturas

Os benchmarks históricos conferem à Solana um perfil de processamento de camada base superior ao da Mainnet da Ethereum, mas as medições não são comparáveis diretamente. O PoH fornece ordenação pré-consenso, o Sealevel executa trabalho não conflituante simultaneamente e o encaminhamento ciente do líder altera o roteamento das transações. Os valores frequentemente citados de ~65.000 e ~15–30 TPS são pontos de referência datados e dependentes da metodologia, e não propriedades permanentes da rede.

Modelo de processamento e execução

A EVM da Ethereum executa contratos sequencialmente, um de cada vez por bloco. O Sealevel executa milhares de contratos não conflituantes simultaneamente. Esta é a fonte primária da diferença de TPS. A Ethereum aborda o processamento através do escalonamento em Camada 2: Rollups, incluindo Arbitrum e Optimism, processam transações Fora da blockchain e efetuam a Quitação de lotes comprimidos na camada base da Ethereum, aumentando substancialmente a capacidade efetiva. A abordagem da Solana é o escalonamento horizontal na Camada 1, evitando a complexidade adicional que as arquiteturas de Camada 2 introduzem para programadores e utilizadores.

Comparação da plataforma de desenvolvimento

O ecossistema de programadores da Ethereum (Solidity, ferramentas EVM, protocolos DeFi estabelecidos com anos de código auditado) é maior e mais maduro do que o da Solana. O modelo Rust e Sealevel da Solana oferece um processamento de camada base mais elevado e taxas mais baixas, mas exige a compreensão do modelo de contas e do requisito de declaração de acesso a contas, que não tem equivalente direto na Ethereum. As aplicações onde o processamento e o custo das taxas são os fatores limitantes ajustam-se bem à arquitetura da Solana. As aplicações que priorizam a compatibilidade com EVM, o maior conjunto de talentos de programadores ou a descentralização máxima da camada base ajustam-se melhor à camada base da Ethereum ou ao seu ecossistema L2.

Bitcoin como o terceiro ponto de referência

A arquitetura da Bitcoin prioriza a segurança e a descentralização acima do processamento. Com ~7 TPS e tempos de bloco de 10 minutos, a Bitcoin não foi concebida para aplicações de alta frequência. O seu consenso Proof of Work é intensivo em termos computacionais por design: segurança através do gasto de energia em vez de Staking económico. Tanto a Solana como a Ethereum oferecem plataformas de Smart Contract programáveis que a Bitcoin não suporta nativamente. A Posição arquitetónica da Bitcoin torna-a uma categoria de sistema diferente, em vez de um concorrente direto para a implementação de aplicações.

Para a comparação completa dos dados em todas as cinco dimensões, consulte a tabela de benchmarks de desempenho acima.

Perguntas Frequentes Sobre a Arquitetura Solana

O que é Prova de Histórico (Proof of History) na Solana?

Prova de Histórico (PoH) é uma cadeia sequencial de hashes SHA-256 que cria um registo verificável e ordenado temporalmente de eventos antes da execução do consenso. Funciona como um relógio criptográfico partilhado em toda a rede de validadores, permitindo aos validadores processar transações sem trocar mensagens de timestamp. PoH não é o mecanismo de consenso da Solana. Tower BFT gere o consenso, utilizando os timestamps PoH como a sua referência de tempo partilhada.

Materiais históricos citam intervalos teóricos e observados de TPS, mas o throughput em tempo real depende da mistura de transações, contabilidade de votos, filtragem, congestionamento, software do validador e metodologia de medição. Utilize dados atuais de fontes primárias e defina o que está a ser contado.

Solana foi co-fundada por Anatoly Yakovenko e Greg Fitzgerald. Yakovenko, um antigo engenheiro da Qualcomm que trabalhou em sistemas distribuídos e sincronização de relógios, descreveu pela primeira vez o mecanismo Proof of History num whitepaper de novembro de 2017. A Solana Labs, a empresa de desenvolvimento com fins lucrativos que co-fundaram, lidera a engenharia de protocolo. A Solana Foundation, uma organização sem fins lucrativos separada sediada em Genebra, apoia o desenvolvimento do ecossistema.

Várias camadas arquitetónicas contribuem para a diferença de desempenho. PoH fornece uma referência de ordenação verificável que pode reduzir alguma sobrecarga de coordenação, Sealevel executa trabalho não conflituoso em paralelo, e o encaminhamento ciente do líder altera a forma como as transações chegam aos validadores agendados. Os valores históricos de TPS dependem da metodologia e não devem ser tratados como propriedades permanentes de nenhuma das redes.

Materiais iniciais agrupam a arquitetura em Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak e Archivers. Este é um quadro explicativo histórico, não uma prova de que cada item nomeado — especialmente Archivers — permanece um subsistema separado implementado hoje.

Tower BFT é o mecanismo de votação ponderada pelo stake e de escolha de fork da Solana, construído em torno de slots PoH e do aumento dos bloqueios de votos. Não assuma uma implementação específica de slashing automática nem conte os validadores igualmente: os limiares bizantinos são ponderados pelo stake, e as suposições de segurança e vivacidade requerem um tratamento mais preciso.

Gulf Stream descreve o encaminhamento de transações ciente do líder em vez de um mempool global convencional. Pode reduzir alguma fila, mas não elimina a competição por taxas de prioridade, congestionamento, rejeição de transações, MEV ou risco de front-running. O comportamento atual da rede deve ser verificado na documentação de implementação.

Sealevel é o runtime de execução paralela de smart contracts da Solana. Ao contrário da EVM da Ethereum, que executa contratos um de cada vez, Sealevel executa milhares de programas não conflituosos simultaneamente em todos os núcleos de CPU e GPU disponíveis. O paralelismo é possibilitado pela exigência de que cada transação declare quais as contas que irá aceder no momento da submissão, para que o runtime possa identificar operações não conflituosas e agendá-las de forma concorrente.

Sim. Solana utiliza Proof of Stake (PoS) como a sua camada de segurança económica. Os validadores investem em staking SOL como garantia e enfrentam penalidades de slashing por comportamento desonesto ou inconsistente. Proof of History é um mecanismo de contagem de tempo criptográfico separado que torna o consenso PoS da Solana mais rápido. PoH não substitui o PoS; melhora a eficiência da Tower BFT, o mecanismo de consenso baseado em PoS.

As falhas documentadas da Solana foram causadas principalmente por inundações de transações geradas por bots que sobrecarregam a memória dos validadores, fazendo com que estes saiam do consenso. O design de alto throughput da arquitetura processa transações com filtragem mínima, criando uma vulnerabilidade a ataques de spam em volume. A Solana Labs implementou a rede QUIC e QoS ponderada pelo stake como mitigações arquitetónicas que reduziram a frequência de falhas. Consulte a secção de compromissos arquitetónicos para eventos documentados específicos.

As principais diferenças arquitetónicas são o modelo de execução (Sealevel paralelo vs. EVM sequencial), o encaminhamento de transações (Gulf Stream sem mempool vs. mempool global), a linguagem de programação (Rust vs. Solidity), e o throughput da camada base (~65.000 TPS teóricos vs. ~15–30 TPS). As blockchains utilizam Proof of Stake para segurança económica. O ecossistema de programadores mais vasto da Ethereum e as opções de Layer-2 servem bem os projetos compatíveis com EVM; o throughput da camada base e a estrutura de taxas da Solana servem aplicações onde o volume de transações e o custo são as principais restrições. Bot

Não existe uma solução completa para o trilema; a Solana faz compromissos em vez disso. A arquitetura prioriza a escalabilidade e mantém a segurança, ao mesmo tempo que aceita requisitos de hardware de validador mais elevados que criam pressão mensurável sobre a descentralização. Esta é uma posição de engenharia específica dentro do trilema, não uma eliminação do mesmo. A posição da Solana é invulgarmente agressiva no eixo da escalabilidade em comparação com outras blockchains importantes.

Os programas em blockchain da Solana são escritos principalmente em Rust, compilados para bytecode Berkeley Packet Filter (BPF) e executados pelo runtime Sealevel. C e C++ também são suportados. O framework Anchor, um kit de ferramentas baseado em Rust que fornece macros e abstrações que simplificam padrões de programas comuns, é o kit de ferramentas de desenvolvimento mais amplamente utilizado. Para as ferramentas atuais do ecossistema, consulte a documentação para programadores da Solana.

O custo de uma transação Solana inclui uma taxa-base e pode incluir custos de priorização e relacionados com computação. O valor em USD muda com o preço do SOL, enquanto o congestionamento e o comportamento da aplicação afetam o custo total de execução. Gulf Stream não elimina a competição por taxas.

À data de redação, a Solana tem mais de 1.000 validadores ativos. Verifique a contagem e distribuição atuais através das estatísticas de validadores da Solana Foundation.). Os validadores requerem um investimento significativo em hardware, incluindo 128+ GB de RAM e SSDs NVMe de alto desempenho, o que cria uma barreira de entrada mais elevada do que a maioria das outras cadeias Proof of Stake e é a principal fonte de preocupações contínuas com a descentralização.

Explore o SOL em Bybit

Os leitores podem rever as informações atuais do mercado SOL) ou o mercado spot SOL/USDT.). Estes links fornecem acesso ao mercado e não provam que a Solana, uma carteira ou um protocolo de terceiros sejam adequados para todos os leitores.

A arquitetura da Solana combina várias decisões de design interligadas. PoH fornece uma referência de ordenação, Sealevel paraleliza a execução não conflituosa, o encaminhamento ciente do líder altera o encaminhamento de transações e o pipelining, Cloudbreak e Turbine abordam o processamento, armazenamento e propagação. O histórico documentado de falhas e os requisitos de recursos do validador pertencem à mesma avaliação técnica que os benefícios de desempenho.

Para programadores que escolhem uma plataforma, Solana oferece o maior débito da camada base e uma das taxas de transação mais baixas de qualquer blockchain de produção importante. O modelo de contas e o requisito de Rust adicionam complexidade de design em relação à EVM do Ethereum. O requisito de declaração de acesso à conta muda a forma como estrutura o estado do programa, e o modelo de execução paralela recompensa designs de programa que minimizam o estado partilhado.

Para investigadores, o Proof of History original de Anatoly Yakovenko: Um Relógio para Blockchain (novembro de 2017) continua a ser a fonte primária fundamental para o design de PoH. A Solana Labs mantém a documentação arquitetónica atual em docs.solana.com. A Solana Foundation publica estatísticas da rede de validadores em solana.org/validators. Dados de rede em tempo real estão disponíveis através do Solana Beach.

Com um entendimento dos oito pilares arquitetónicos de Solana, está agora equipado para avaliar as afirmações de desempenho da rede, os seus compromissos e a sua trajetória de longo prazo nos seus próprios termos.

Aviso: Este artigo destina-se apenas a fins informativos e educacionais. Não constitui aconselhamento financeiro, aconselhamento de investimento ou uma recomendação para comprar, vender ou deter SOL ou qualquer outra criptomoeda. Todos os números de desempenho estão sujeitos a alterações. Consulte um consultor financeiro qualificado antes de tomar decisões de investimento.

Leitura Relacionada

• Solana Proof of History
• Mecanismo de consenso Solana
• SolanaVM
• Solana Speed