Pontos Principais
As blockchains substituem intermediários de confiança por computação verificável. O Bitcoin provou que isso funciona, mas processa apenas 7 transações por segundo. A Ethereum adicionou programabilidade, mas herdou restrições de execução sequencial, alcançando 15 TPS. A Solana aborda a escalabilidade de forma diferente através de inovação arquitetural: ordena transações primeiro com Proof of History, depois executa transações não-conflitantes em paralelo.
O Proof of History é um relógio criptográfico que cria timestamps verificáveis sem exigir que os nós sincronizem seus relógios. Hashs repetidos de saídas como entradas criam uma sequência que prova que o tempo passou. As transações são hasheadas nessa sequência, estabelecendo sua ordem antes do consenso. A Solana ordena 160.000 eventos por segundo, eliminando o gargalo de ordenação que restringe blockchains sequenciais.
A execução paralela exige que as transações declarem quais contas vão acessar antecipadamente. O runtime constrói grafos de dependência e executa transações não-conflitantes simultaneamente em múltiplos núcleos de CPU. Programas sem estado separam código executável de dados, permitindo execução concorrente quando transações tocam contas diferentes.
Tudo é uma conta na Solana. Contas contêm lamports, dados, um proprietário (owner) e uma flag executável. Sua carteira é uma conta. Programas são contas. Saldos de tokens são contas. Apenas o programa proprietário pode modificar os dados de uma conta. Esse modelo uniforme simplifica a arquitetura e permite processamento paralelo.
Programas processam instruções recebendo contas como parâmetros, validando operações e modificando dados das contas. PDAs (Program Derived Addresses) permitem que programas sejam donos de contas e autorizem transações sem chaves privadas. CPI (Cross-Program Invocation) permite que programas chamem uns aos outros dentro de transações atômicas. Transações agrupam instruções que ou todas são bem-sucedidas ou todas falham juntas.
Essa arquitetura alcança 5.000+ TPS com finalidade sub-segundo. A concessão: validadores precisam de hardware de ponta (12+ núcleos, 256GB RAM), reduzindo o número de validadores potenciais em comparação com Bitcoin ou Ethereum. A Solana mantém mais de 1.000 validadores independentes, priorizando vazão enquanto mantém descentralização suficiente para aplicações onde a performance importa mais.
Usar a Solana exige uma carteira para gerenciar chaves, SOL para taxas de transação (0,000005 SOL por assinatura), e entender que sua seed phrase é a única forma de recuperar fundos. Carteiras como Phantom, Solflare e Backpack gerenciam chaves e assinam transações. Block explorers como Solana Explorer e Solscan mostram todos os dados on-chain. O ecossistema inclui protocolos DeFi, marketplaces de NFT, sistemas de pagamento e ferramentas para desenvolvedores.
As ferramentas existem. A infraestrutura funciona. O ecossistema cresce.
Perguntas Frequentes
O que é Proof of History e por que a Solana precisa dele?
Proof of History é um relógio criptográfico que cria timestamps verificáveis para eventos da blockchain sem exigir que os nós confiem nos relógios uns dos outros. Ele usa uma função de atraso verificável: aplicar SHA-256 repetidamente onde cada saída se torna a próxima entrada. Isso cria uma sequência que prova que o tempo passou porque você não pode pular adiante sem fazer a computação. A Solana gera 160.000 hashes por segundo. Quando as transações chegam, elas são hasheadas nessa sequência, estabelecendo sua ordem criptograficamente. A Solana ordena transações antes do consenso em vez de depois, eliminando o gargalo de ordenação que limita blockchains sequenciais como a Ethereum. Uma vez ordenadas, a Solana executa transações não-conflitantes em paralelo.
Como a Solana alcança 5.000+ transações por segundo?
A Solana alcança alta vazão através de três mecanismos. O Proof of History ordena transações antes do consenso, eliminando gargalos de consenso. A execução paralela exige que transações declarem quais contas vão acessar antecipadamente, o que permite ao runtime construir grafos de dependência e executar transações não-conflitantes simultaneamente em múltiplos núcleos de CPU. Programas sem estado separam código executável de dados, permitindo execução concorrente quando transações tocam contas diferentes. O tempo de bloco de 400 milissegundos e o consenso Tower BFT com Proof of Stake alcançam finalidade em 1-2 segundos. A vazão em produção é de 5.000+ TPS com capacidade teórica excedendo 65.000 TPS.
O que é o modelo de contas da Solana?
Na Solana, tudo é uma conta. Uma conta é uma estrutura de dados contendo lamports (saldo em 1/bilionésimo de SOL), dados (bytes arbitrários até 10MB), um proprietário (o programa que a controla) e uma flag executável. Sua carteira é uma conta de propriedade do System Program. Programas são contas marcadas como executáveis. Dados de programas vivem em contas separadas de propriedade do programa. Saldos de tokens são contas de propriedade do Token Program. Essa uniformidade simplifica o modelo. Apenas o programa proprietário pode modificar os dados de uma conta ou retirar seus lamports. Transações devem declarar quais contas vão acessar, o que permite execução paralela quando transações tocam contas diferentes.
Por que os programas da Solana são sem estado (stateless)?
Os programas da Solana contêm apenas código executável sem estado interno. Os dados vivem em contas separadas de propriedade do programa. Quando um programa executa, ele recebe contas como parâmetros, lê seus dados, processa-os e escreve resultados de volta. Duas transações chamando o mesmo programa com contas de dados diferentes podem executar simultaneamente porque o código do programa é apenas leitura e apenas as contas de dados mudam. Essa separação permite execução paralela, simplifica atualizações de programas sem migração de dados, e permite que qualquer pessoa inspecione dados de contas diretamente sem executar código do programa. O design stateless é fundamental para a alta vazão da Solana.
O que é rent na Solana e como funciona?
Rent é o mecanismo da Solana para manter os custos de armazenamento de contas. Toda conta deve manter um saldo mínimo proporcional ao seu tamanho de dados para permanecer "rent-exempt". A fórmula: rent = (128 + data_size) × 0,00000348 SOL × epochs_per_year. Uma conta típica de 165 bytes exige aproximadamente 0,00114 SOL (cerca de $0,11 a $100/SOL). Esse saldo é um depósito reembolsável. Quando você fecha uma conta, os lamports voltam para você. Criar contas custa SOL em depósitos de rent, mas esses custos são pequenos e totalmente recuperáveis. Aplicações com milhares de contas devem considerar os custos totais de rent em sua economia.
Como começo a usar a Solana?
Instale uma carteira como Phantom, Solflare ou Backpack. Anote sua seed phrase (12 ou 24 palavras) e guarde-a com segurança. Nunca a compartilhe ou salve digitalmente. Sua seed phrase é a única forma de recuperar seus fundos se você perder o acesso. Obtenha SOL em exchanges centralizadas (Coinbase, Binance), exchanges descentralizadas (Jupiter, Raydium) ou on-ramps (Moonpay, Transak). Para testes, use a devnet com o Solana CLI: solana config set --url https://api.devnet.solana.com e solana airdrop 2 para SOL de teste grátis. Transações custam 0,000005 SOL e confirmam em 1-2 segundos. Use block explorers como Solana Explorer ou Solscan para ver transações e dados de contas.
Quais são as concessões da arquitetura da Solana?
A alta performance da Solana exige que validadores rodem servidores dedicados com 12+ núcleos de CPU, 256GB RAM e conexões rápidas de internet. Isso reduz o número de validadores potenciais em comparação com Bitcoin ou Ethereum, onde laptops consumidores podem validar. A Solana mantém mais de 1.000 validadores independentes. Desenvolvedores devem declarar contas antecipadamente nas transações, adicionando complexidade em comparação com o modelo sequencial mais simples da Ethereum. Os altos requisitos de banda da rede desafiam validadores em regiões com infraestrutura limitada. Essas concessões são intencionais. A Solana prioriza vazão e custo enquanto mantém descentralização suficiente para aplicações onde a performance importa mais.