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

Nota de precisão: Desempenho da rede, contagem de validadores, taxas, recursos do protocolo, suporte a carteiras e integrações de terceiros mudam ao longo do tempo. Trate figuras datadas como snapshots históricos e verifique a documentação primária atual.

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

Materiais iniciais da Solana agrupavam a arquitetura em oito ideias destinadas a suportar a execução de alta vazão. O desempenho atual, a propriedade da implementação, os componentes de software e os papéis organizacionais evoluem, portanto este artigo trata a moldura de “oito inovações” como um modelo explicativo histórico, em vez de uma especificação atual completa.

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 Cronometragem da Solana: relógio criptográfico que marca o tempo de eventos antes da execução do consenso
2. Tower BFT - Mecanismo de Consenso da Solana: mecanismo de consenso que usa timestamps PoH na votação
3. Turbine - Propagação de Blocos em Escala: propagação de blocos que divide blocos em pacotes menores
4. Gulf Stream - Encaminhamento de Transações sem Mempool: encaminhamento de transações baseado em líderes agendados
5. Sealevel - Execução Paralela de Smart Contracts: runtime de execução paralela de smart contracts
6. Pipelining - Validação de Transações como Linha de Montagem: processamento de transações por etapas
7. Cloudbreak - Banco de Dados de Contas Escalado Horizontalmente: banco de dados de contas projetado para acesso concorrente
8. Archivers - Uma Proposta Histórica de Armazenamento: uma proposta histórica de armazenamento distribuído

Nota de Desempenho: TPS históricos teóricos, 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 por trás delas.

Trade-off Honesto: Solana experimentou falhas de rede documentadas desde o lançamento da mainnet em março de 2020, e seus requisitos de hardware de validador (128+ GB de RAM recomendados) criam pressão de centralização. Esses são trade-offs arquitetônicos conhecidos, não problemas incidentais.

O Problema que Solana Foi Construída para Resolver

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

Anatoly Yakovenko, um ex-engenheiro de sistemas distribuídos na Qualcomm, abordou essa restrição de forma diferente. Em novembro de 2017, ele publicou um whitepaper intitulado Proof of History: A Clock for Blockchain, descrevendo um mecanismo criptográfico de controle de tempo que poderia reduzir drasticamente a sobrecarga de comunicação em algoritmos de consenso. Greg Fitzgerald juntou-se como cofundador e CTO, e juntos eles construíram o protocolo que se tornou Solana. A Solana Labs, a empresa com fins lucrativos que cofundaram, lidera o desenvolvimento principal do protocolo. 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 educacionais.

A arquitetura de oito pilares da Solana foi projetada para expandir o limite de escalabilidade o máximo possível dentro das restrições desse trilema. O design aceita deliberadamente requisitos de hardware de validador mais elevados como o custo dessa vazão. Solana não resolve o trilema; ocupa uma posição incomumente agressiva no eixo de escalabilidade. Esses trade-offs têm custos reais, examinados na seção de trade-offs arquiteturais abaixo.

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

A moldura histórica de oito partes abrange Proof of History, Tower BFT, Turbine, Gulf Stream, Sealevel, Pipelining, Cloudbreak e Archivers. Nem todo item deve ser considerado um subsistema implementado separadamente e atual, particularmente a proposta Archivers.

1. Proof of History: uma cadeia sequencial de hash SHA-256 que cria um registro de timestamp verificável antes que o consenso seja executado
2. Tower BFT: um mecanismo de consenso Byzantine Fault Tolerant aprimorado por PoH que usa timestamps PoH para votar eficientemente
3. Turbine: um protocolo de propagação de blocos inspirado no BitTorrent que divide blocos em pequenos pacotes com codificação de apagamento chamados shreds
4. Gulf Stream: um protocolo de encaminhamento de transações sem mempool que roteia transações diretamente para os próximos líderes validadores
5. Sealevel: um runtime de execução paralela de smart contracts que executa milhares de programas não conflitantes 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: um banco de dados de contas escalado horizontalmente usando arquivos mapeados em memória para suportar leituras e gravações concorrentes
8. Archivers: uma proposta histórica para armazenamento de ledger distribuído usando conceitos de prova de replicação

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

Proof of History (PoH): O Motor de Cronometragem da Solana

Proof of History (PoH) é uma cadeia sequencial de hash SHA-256 que cria um registro verificável e ordenado temporalmente de eventos antes que o consenso seja executado, agindo como um relógio criptográfico compartilhado para toda a rede. PoH não é o mecanismo de consenso da Solana; esse papel pertence ao Tower BFT. PoH é a camada de cronometragem 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 os relógios uns dos outros primeiro. Em redes blockchain tradicionais, os validadores devem trocar mensagens de timestamp entre si durante cada rodada de consenso, adicionando sobrecarga de comunicação que cresce com o tamanho do conjunto de validadores. O PoH elimina essa troca completamente.

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 registro 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 esse mecanismo pela primeira vez em seu whitepaper de novembro de 2017, Proof of History: A Clock for Blockchain.

PoH funciona como uma Função de Atraso Verificável (VDF): um cálculo que leva uma quantidade previsível e sequencial de tempo para ser computado, mas pode ser verificado quase instantaneamente. Essa assimetria entre o tempo de computação e o tempo de verificação é o que torna o PoH prático. Validadores podem transmitir a saída do PoH e qualquer observador pode verificar sua autenticidade em microssegundos, mesmo que produzi-la tenha exigido tempo real decorrido. Esta é a propriedade que pesquisadores acadêmicos e analistas de protocolo reconhecerão como a base teórica para as propriedades de segurança do PoH.

Ao estabelecer uma referência de ordenação verificável, o PoH pode reduzir parte da coordenação de tempo. Ele não remove a troca de mensagens de consenso nem garante diretamente um slot, confirmação ou tempo de finalidade específico.

Um esclarecimento crítico: Solana é por vezes descrita como uma "Blockchain Proof of History", implicando que o PoH substitui Proof of Stake (PoS). Isto está incorreto. Solana é uma Blockchain Proof of Stake em sua camada de segurança econômica. Validadores investem em staking de SOL como colateral e enfrentam slashing por comportamento desonesto. O 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: Mecanismo de consenso da Solana

Tower BFT é o mecanismo de consenso da Solana: uma variante aprimorada por PoH da Practical Byzantine Fault Tolerance (pBFT) que utiliza o registro de carimbo de data/hora do PoH como um relógio compartilhado, permitindo que os validadores votem no estado do ledger sem trocar mensagens de sincronização de relógio.

Byzantine Fault Tolerance (BFT) descreve a propriedade de um sistema distribuído que permite que ele alcance consenso corretamente, mesmo quando alguns participantes se comportam de forma maliciosa ou imprevisível, nomeada após o problema dos Generais Bizantinos na computação distribuída. Algoritmos pBFT tradicionais exigem extensas trocas de mensagens entre nós para estabelecer uma visão comum do tempo, o que os torna impraticáveis em escala. O Tower BFT substitui o registro PoH por essa troca de mensagens. Os validadores já compartilham o relógio PoH; eles não precisam negociar carimbos de data/hora.

Validadores são participantes da rede que investem em staking de SOL, validam transações, produzem blocos quando selecionados como líderes e votam no estado do ledger. Eles lançam votos com tempo bloqueado e crescimento exponencial em forks. Quanto mais tempo um validador vota em um fork particular, mais SOL ele arrisca perder através de slashing (o mecanismo de penalidade que remove tokens investidos por comportamento desonesto ou inconsistente) se esse fork for abandonado. Este mecanismo de bloqueio de votos cria fortes incentivos econômicos para participação honesta sem exigir rodadas de comunicação adicionais.

O Tower BFT tolera até um terço do conjunto de validadores se comportando de maneira bizantina. Se menos de um terço dos validadores agirem maliciosamente, a rede alcança consenso correto. Esse limite decorre dos requisitos matemáticos do problema dos Generais Bizantinos, originalmente formalizado por Lamport, Shostak e Pease em 1982. A linhagem de consenso para pesquisadores: pBFT (Castro e Liskov, 1999) estabeleceu o algoritmo fundamental; variantes subsequentes incluindo HotStuff e Tendermint o aprimoraram; o Tower BFT (2017) dá um passo adicional ao eliminar a sobrecarga de sincronização de relógio através do PoH.

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

Turbine: Propagação de Blocos em Escala

Transmitir um bloco completo para todos os validadores a 65.000 TPS teóricos criaria um gargalo de largura de banda que cresce linearmente com o tamanho da rede. O Turbine resolve isso da mesma forma que o BitTorrent resolve a distribuição de arquivos grandes: quebrando os dados em pequenas partes e espalhando a carga de propagação pela rede.

Turbine é o protocolo de propagação de blocos da Solana, inspirado no modelo de distribuição baseado em peças do BitTorrent. Em vez de um líder transmitir um bloco completo para todos os validadores simultaneamente, o Turbine quebra os blocos em pequenos pacotes com codificação de apagamento (erasure-coded) chamados shreds e os distribui através de uma rede de validadores estruturada em árvore.

Shreds são codificados com apagamento para redundância. Cada nó na árvore de propagação recebe um subconjunto de shreds, retransmite para a próxima camada e reconstrói o bloco completo a partir do subconjunto que recebe. A codificação de apagamento significa que, mesmo que alguns shreds sejam perdidos 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 dos dados totais do bloco.

Expandir o 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 planejar a capacidade de recepção de dados e reconstrução de blocos.

Gulf Stream: Encaminhamento de Transações sem Mempool

O Gulf Stream usa encaminhamento ciente do líder em vez de um mempool global compartilhado convencional. Isso muda o modelo de filas, mas não elimina congestionamento ou incentivos de ordenação de transações.

No Ethereum, transações não confirmadas esperam no mempool: o pool compartilhado de transações não confirmadas esperando para serem incluídas em um bloco. Durante períodos de alta demanda, esse pool se torna uma fonte de congestionamento, escalada de taxas e Valor Máximo Extraível (MEV), o lucro extraído pela reordenação, inserção ou censura de transações no mempool antes que sejam finalizadas. Usuários do Ethereum dão lances de taxas de gás mais altas para priorizar suas transações, é por isso que as taxas historicamente atingiram US$ 5–50+ durante o pico de uso. Bid (compra) mais alta prioriza transações.

O design utiliza o cronograma de líderes conhecido da Solana para encaminhar transações em direção a líderes futuros em vez de transmiti-las para um pool global convencional. Validadores podem preparar transações antes de sua vez de produzir blocos, o que pode reduzir a latência de filas, deixando congestionamento, competição de taxas, quedas e MEV como preocupações separadas.

O encaminhamento de transações ciente do líder muda como as transações chegam aos líderes agendados, mas não elimina congestionamento, competição por taxas de prioridade, MEV, transações descartadas ou pressão sobre os recursos do validador. As taxas base e de prioridade atuais devem ser medidas diretamente em vez de convertidas em um valor fixo em USD.

A ausência de um mempool muda os padrões de submissão de transações para desenvolvedores que constroem na Solana. As transações têm um caminho de encaminhamento previsível, permitindo confirmação otimista antes da finalidade completa. A área de superfície de MEV na Solana é substancialmente menor do que no Ethereum, embora não zero; a ordenação de transações ponderada por stake cria sua própria dinâmica que os designers de dApp devem estudar antes de construir.

Sealevel: Execução Paralela de Smart Contract

Sealevel é o runtime de execução paralela de contratos inteligentes da Solana, o motor que executa programas na blockchain (o termo da Solana para o que o Ethereum chama de contratos inteligentes). Ao contrário da EVM do Ethereum, que executa contratos sequencialmente, um de cada vez, o Sealevel executa milhares de programas não conflitantes simultaneamente em núcleos de GPU e CPU disponíveis.

A EVM do Ethereum processa contratos inteligentes como uma única fila de checkout em um supermercado: uma transação por vez, cada comprador esperando atrás do anterior. O Sealevel abre vinte filas de checkout simultaneamente, executando transações não conflitantes em paralelo. Esta é a principal razão arquitetônica pela qual a taxa de transferência da Solana excede a do Ethereum na camada base.

O paralelismo é possível porque o modelo de programação da Solana exige que cada transação declare, no momento do envio, quais contas (os objetos de estado que armazenam dados na Solana) ela irá ler e gravar. O Sealevel analisa essas listas de acesso a contas para identificar transações que não conflitam: aquelas que tocam em contas completamente diferentes podem ser executadas simultaneamente sem produzir mudanças de estado conflitantes. Transações que compartilham contas devem ser executadas sequencialmente. O runtime do Sealevel utiliza essa declaração para programar a execução paralela ou sequencial entre os núcleos de hardware disponíveis.

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

O que isso significa para os construtores

Ao implantar um programa na Solana, você deve declarar todas as contas que seu programa lerá e gravará no momento do envio da transação. Esta lista de acesso à conta não é opcional; é o mecanismo que o Sealevel utiliza para programar a execução paralela. Omitir ou declarar contas incorretamente causa falhas nas transações.

Programas que compartilham estado com outros programas (gravando nas mesmas contas) não podem se beneficiar do paralelismo e sempre serão executados sequencialmente. Projete a estrutura de contas do seu programa para minimizar o estado compartilhado sempre que possível. Programas com padrões de acesso a contas estreitos e que não se sobrepõem extraem o maior benefício do escalonador paralelo do Sealevel.

O framework Anchor, um kit de ferramentas baseado em Rust que fornece macros e abstrações que simplificam padrões comuns de programas, é 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 do Sealevel, consulte a documentação do desenvolvedor Solana.

Pipelining: A 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 iniciar o próximo. Cada estação (soldagem, pintura, ajuste interno) trabalha em um carro diferente simultaneamente. A Solana aplica essa mesma lógica à validação de transações por meio da Otimização de Validação de Transações (TVO).

O Pipelining na Solana refere-se à TVO, uma aplicação da arquitetura de pipeline de CPU ao processamento de transações em blockchain. O processo de validação de transações é dividido em quatro estágios distintos, cada um operado por uma unidade de hardware separada funcionando simultaneamente. Enquanto um lote de transações passa por um estágio, o próximo lote já está no estágio anterior.

Os quatro estágios são:

1. Fetch (Busca): uma unidade de kernel-space recupera os dados das transações recebidas da rede
2. Signature Verification (SigVerify - Verificação de Assinatura): a GPU verifica as assinaturas criptográficas em todo o lote em paralelo
3. Banking (Bancário): a CPU processa a lógica da transação, verifica os saldos das contas e atualiza o estado das contas
4. Write Confirmation (Confirmação de Gravação): o disco grava as alterações de estado finalizadas

Enquanto o lote A está no Banking, o lote B está no SigVerify e o lote C está sendo buscado. Nenhum hardware fica ocioso esperando o lote anterior terminar. Este escalonamento contínuo elimina o tempo de inatividade da CPU entre os estágios de processamento que, de outra forma, limitaria a taxa de transferência.

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 taxa de transferência do mesmo hardware, mantendo cada componente de processamento trabalhando o tempo todo, em vez de deixar qualquer estágio ocioso entre os lotes.

Cloudbreak: Banco de dados de contas com escala horizontal

Cloudbreak é o sistema de arquivos que permite que os processadores paralelos da Solana leiam e gravem dados de contas simultaneamente sem filas. Sem ele, a camada de armazenamento serializaria todas as leituras e gravações de contas, e os ganhos de paralelismo do Sealevel evaporariam no limite do banco de dados.

Cloudbreak é o banco de dados de contas com escala horizontal da Solana: a estrutura de dados que armazena o estado de cada conta na rede. Ele usa arquivos mapeados em memória e estruturas de dados otimizadas para SSD para suportar leituras e gravações simultâneas em múltiplas threads ao mesmo tempo.

As contas são distribuídas em múltiplas estruturas de dados acessíveis em paralelo. O I/O mapeado em memória do sistema operacional permite que o Cloudbreak trate os dados das contas residentes no disco como se estivessem na RAM, eliminando a latência de busca e permitindo o acesso simultâneo no nível da thread. Quando o Sealevel agenda 10.000 transações paralelas, o Cloudbreak atende a 10.000 leituras e gravações simultâneas de contas sem serializar as solicitações em uma fila.

A arquitetura do banco de dados e o tempo de execução (runtime) são interdependentes: nenhum entrega taxa de transferência sem o outro. Os padrões de I/O do Cloudbreak exigem SSDs NVMe de alto desempenho. Os discos rígidos giratórios padrão não conseguem sustentar a taxa de transferência de leitura/gravação aleatória que o modelo de acesso simultâneo do Cloudbreak exige. Compreender o modelo de conta do Cloudbreak é fundamental para o design de programas na Solana: todo o estado reside em objetos de conta discretos, os programas operam de forma apátrida (stateless) nessas contas e as decisões de layout da conta afetam diretamente o desempenho de leitura/gravação em tempo de execução.

Archivers: Uma proposta de armazenamento histórico

O conceito de Archivers aparece em materiais iniciais da arquitetura da Solana, mas não deve ser apresentado como um subsistema de produção atualmente implantado sem evidências atuais de fontes primárias.

Materiais de design iniciais propuseram os Archivers, também chamados de Replicators em algumas descrições, como participantes leves que armazenam partes dos dados históricos do ledger e comprovam o armazenamento. Isso explica a abordagem original para o crescimento do ledger, mas não deve ser descrito como uma rede de produção ativa com recompensas sem confirmação atual de fonte primária. A infraestrutura atual de retenção e arquivamento do ledger deve ser documentada separadamente.

Com todos os oito pilares arquitetônicos em vigor, o sistema combinado produz benchmarks de desempenho que separam a Solana da maioria das outras blockchains públicas, os quais a próxima seção quantifica.

Benchmarks de desempenho da Solana: TPS, taxas e finalização de bloco

~65.000 TPS em benchmarks teóricos históricos é o máximo teórico da Solana sob condições ideais de laboratório, não um valor sustentado do mundo real. A distinção é importante para qualquer pessoa que use esses números em análises de investimento ou design de sistemas.

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

A taxa de transferência real na Mainnet opera abaixo do máximo teórico por vários motivos. Nem todos os slots de transação são preenchidos completamente durante a demanda normal. Mecanismos de filtragem de spam rejeitam transações de baixa qualidade antes que alcancem o estágio bancário. As condições da rede afetam o tempo de propagação. Aproximar-se do teto teórico requer uma demanda de pico sustentada combinada com a 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 rendimento 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 de tempo. O Sealevel executa trabalhos não conflitantes em paralelo. O encaminhamento ciente do líder pode organizar as transações antes que uma vaga de bloco seja aberta, reduzindo parte do enfileiramento convencional no 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 rendimento efetivo da Ethereum muito além dos números da sua camada base. Qualquer comparação completa deve considerar essa capacidade expandida ao avaliar as duas plataformas para um caso de uso específico.

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

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

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

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

GameFi e microtransações: Taxas geralmente baixas podem suportar ações de pequeno valor, mas os custos totais da aplicação e as transações falhas ainda importam. Os custos da L1 e L2 da Ethereum devem ser comparados separadamente usando dados atuais.

Pagamentos: Aplicações de pagamento baseadas na Solana podem focar em Feedback rápido para o usuário, mas a aprovação da carteira, confirmação otimista, finalização enraizada, tolerância ao risco do comerciante e operações fora da blockchain são etapas separadas. A autorização de cartão de crédito não é equivalente à quitação em uma blockchain pública.

As mesmas escolhas arquitetônicas que permitem essas aplicações também trazem compromissos documentados, que a próxima seção examina sem rodeios.

Compromissos Arquitetônicos: Confiabilidade 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 Bot que sobrecarregaram a memória dos validadores e fizeram com que eles saíssem do consenso.

Interrupções de Rede

O design de alto rendimento da Solana processa transações com filtragem prévia 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 paralisações no consenso. As principais interrupções documentadas incluem uma em setembro de 2021, que durou 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 a transações duplicadas excessivas de validadores. Outras interrupções mais curtas ocorreram em 2022 e 2023.

A Solana Labs implementou duas mitigações arquitetônicas principais. O protocolo de rede QUIC substituiu o UDP para a ingestão de transações, fornecendo controle de fluxo no nível da conexão que limita quantas transações qualquer fonte única pode enviar. A Qualidade de Serviço (QoS) ponderada por Stake prioriza o encaminhamento de transações de validadores com maiores participações em SOL, tornando a inundação de spam por fontes de baixo stake 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 de interrupções diminuiu desde que essas mitigações foram implantadas. O histórico de interrupções continua sendo 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 de 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, pois os requisitos evoluem com as atualizações do protocolo. Esses requisitos excedem substancialmente o que os validadores de Ethereum precisam para participar do consenso PoS.

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

Posicionamento no Trilema da blockchain Blockchain

A Solana não elimina o Trilema da blockchain. Sua arquitetura representa uma escolha deliberada de priorizar a escalabilidade e manter a segurança, aceitando requisitos de hardware de validador mais altos que criam pressão sobre a descentralização. A Ethereum prioriza a descentralização e a segurança, abordando a escalabilidade por meio de soluções de Camada 2. O Bitcoin prioriza a segurança e a descentralização ao custo de um rendimento mínimo. Cada rede ocupa uma posição de engenharia diferente dentro do mesmo trilema, e não existe uma 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 dados materiais para qualquer avaliação técnica rigorosa da rede Solana.

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

Benchmarks históricos dão à Solana um perfil de rendimento de camada base superior ao da Mainnet da Ethereum, mas as medições não são comparáveis de forma direta. O PoH fornece ordenação pré-consenso, o Sealevel executa trabalhos não conflitantes simultaneamente e o encaminhamento ciente do líder altera o roteamento das transações. Os números 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.

Rendimento e modelo de execução

A EVM da Ethereum executa contratos sequencialmente, um de cada vez por bloco. O Sealevel executa milhares de contratos não conflitantes simultaneamente. Esta é a principal fonte da lacuna de TPS. A Ethereum aborda o rendimento por meio do escalonamento de Camada 2: Rollups, incluindo Arbitrum e Optimism, processam transações fora da blockchain e fazem a quitação de lotes compactados 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 desenvolvedores e usuários.

Comparação de plataformas de desenvolvedores

O ecossistema de desenvolvedores da Ethereum (Solidity, ferramentas EVM, protocolos DeFi estabelecidos com anos de código auditado) é maior e mais maduro que o da Solana. O modelo Rust e Sealevel da Solana oferece maior rendimento na camada base 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 possui equivalente direto na Ethereum. Aplicações onde o rendimento e o custo das taxas são as restrições principais se ajustam bem à arquitetura da Solana. Aplicações que priorizam a compatibilidade com EVM, o maior pool de talentos de desenvolvedores ou a descentralização máxima da camada base se ajustam melhor à camada base da Ethereum ou ao seu ecossistema L2.

Bitcoin como o terceiro ponto de referência

A arquitetura do Bitcoin prioriza a segurança e a descentralização acima do rendimento. Com ~7 TPS e tempos de bloco de 10 minutos, o Bitcoin não foi projetado para aplicações de alta frequência. Seu consenso de Proof of Work é intensivo em computação por design: segurança através do gasto de energia em vez de Staking econômico. Tanto a Solana quanto a Ethereum oferecem plataformas de Smart Contract programáveis que o Bitcoin não suporta nativamente. A posição arquitetônica do Bitcoin o torna uma categoria diferente de sistema, em vez de um concorrente direto para a implantação de aplicações.

Para a comparação completa de dados entre as cinco dimensões, veja a tabela de benchmarks de desempenho acima.

Perguntas Frequentes Sobre a Arquitetura Solana

O que é Proof of History na Solana?

Proof of History (PoH) é uma cadeia sequencial de hashes SHA-256 que cria um registro verificável e ordenado cronologicamente de eventos antes da execução do consenso. Ele atua como um relógio criptográfico compartilhado na rede de validadores, permitindo que os validadores processem transações sem trocar mensagens de carimbo de data/hora. PoH não é o mecanismo de consenso da Solana. O Tower BFT cuida do consenso, usando os carimbos de data/hora do PoH como sua referência de tempo compartilhada.

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. Use dados atuais de fontes primárias e defina o que está sendo contado.

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

Várias camadas arquitetônicas contribuem para a diferença de desempenho. O PoH fornece uma referência de ordenação verificável que pode reduzir alguma sobrecarga de coordenação, o Sealevel executa trabalhos não conflitantes em paralelo e o encaminhamento ciente do líder muda a forma como as transações chegam aos validadores agendados. Os dados 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. Esta é uma estrutura explicativa histórica, não prova de que cada item nomeado — especialmente Archivers — permanece um subsistema implantado separado hoje.

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

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

Sealevel é o runtime de execução paralela de smart contract da Solana. Ao contrário da EVM da Ethereum, que executa contratos um de cada vez, Sealevel executa milhares de programas não conflitantes simultaneamente em núcleos de CPU e GPU disponíveis. O paralelismo é habilitado exigindo que cada transação declare quais contas acessará no momento da submissão, para que o runtime possa identificar operações não conflitantes e agendá-las concorrentemente.

Sim. Solana usa Proof of Stake (PoS) como sua camada de segurança econômica. Validadores investem SOL como garantia e enfrentam penalidades de slashing por comportamento desonesto ou inconsistente. Proof of History é um mecanismo de cronometragem criptográfico separado que torna o mecanismo de consenso PoS da Solana mais rápido. O PoH não substitui o PoS; ele aprimora a eficiência do Tower BFT, o mecanismo de consenso baseado em PoS.

As falhas de rede 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 eles 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 o networking QUIC e o QoS ponderado por stake como mitigações arquitetônicas que reduziram a frequência de falhas. Veja a seção de trade-offs 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), roteamento de transações (Gulf Stream sem mempool vs. mempool global), linguagem de programação (Rust vs. Solidity) e throughput da camada base (~65.000 TPS teóricos vs. ~15-30 TPS). Bot blockchains usam Proof of Stake para segurança econômica. O ecossistema de desenvolvedores maior da Ethereum e as Opções de Camada 2 atendem bem a projetos compatíveis com EVM; o throughput da camada base e a estrutura de taxas da Solana atendem a aplicações onde o volume e o custo das transações são as principais restrições.

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

Os programas na blockchain da Solana são primariamente escritos 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 toolkit baseado em Rust que fornece macros e abstrações que simplificam padrões comuns de programas, é o toolkit de desenvolvimento mais amplamente utilizado. Para ferramentas de ecossistema atuais, consulte a documentação do desenvolvedor da Solana.

O custo da transação Solana inclui uma taxa-base e pode incluir custos de priorização e relacionados à 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. O Gulf Stream não elimina a concorrência de taxas.

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

Explore SOL em Bybit

Os leitores podem revisar as informações de mercado atuais de SOL) ou o mercado spot SOL/USDT.). Esses links fornecem acesso ao mercado e não provam que Solana, uma carteira ou um protocolo de terceiros é adequado para todos os leitores.

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

Para desenvolvedores que escolhem uma plataforma, Solana oferece a maior taxa de transferência de camada base e uma das menores taxas de transação de qualquer blockchain de produção importante. O modelo de contas e o requisito de Rust adicionam complexidade de design em relação ao EVM da Ethereum. O requisito de declaração de acesso à conta muda como você estrutura o estado do programa, e o modelo de execução paralela recompensa designs de programa que minimizam o estado compartilhado.

Para pesquisadores, o Prova de História: Um Relógio para Blockchain original de Anatoly Yakovenko (novembro de 2017) permanece a fonte primária fundamental para o design de PoH. Solana Labs mantém a documentação arquitetônica atualizada em docs.solana.com. A Solana Foundation publica estatísticas da rede de validadores em solana.org/validators. Dados da rede em tempo real estão disponíveis via Solana Beach.

Com um entendimento dos oito pilares arquitetônicos de Solana, você está agora equipado para avaliar as alegações de desempenho da rede, seus trade-offs e sua trajetória long-term em seus próprios termos.

Aviso Legal: Este artigo é apenas para fins informativos e educacionais. Ele não constitui aconselhamento financeiro, aconselhamento de investimento ou uma recomendação para comprar, vender ou manter 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