Fundamentos de Solana em Profundidade
O desenvolvimento Solana deixa de parecer uma lista de APIs não relacionadas quando você vê contas, programas, transações, moeda, chaves, clusters e confirmação como um sistema fechado.
Toda outra página desta seção - básicos, unidades, keypairs, clusters, fluxo de transação e contraste EVM - é um zoom em uma face desse sistema, não uma tecnologia separada.
Esta página é o guarda-chuva: como essas peças se encaixam para você raciocinar sobre transferência de carteira, deploy de programa ou chamada RPC com falha com a mesma imagem subjacente.
Resumo
- Solana é uma máquina de contas - programas executam contra contas nomeadas em transações atômicas, precificadas e armazenadas em lamports inteiros, autorizadas por assinaturas Ed25519 (ou PDAs), em cluster específico, até um nível de commitment escolhido dizer que o resultado é durável o suficiente para sua UX.
- Por Que Importa: Modelos mentais fragmentados produzem bugs clássicos - tratar programas como contratos-com-storage, valores SOL em ponto flutuante, RPCs de cluster errado ou UI que trata
processedcomo final - que somem quando as peças compartilham um modelo. - Conceitos-Chave: account, program, instruction, transaction, account meta, Sealevel, lamport, keypair, PDA, cluster, commitment, rent exemption.
- Quando Usar: Primeira orientação antes de escrever clientes ou programas; integrar engenheiros EVM ou Web2; depurar "account not found", transações descartadas ou contenção paralela inesperada.
- Limitações / Trade-offs: Listas explícitas de contas e tamanhos fixos de conta compram paralelismo e custos de storage previsíveis, mas exigem mais trabalho de design que modelos de storage implícitos e tornam "um mapping global gigante" inviável.
- Tópicos Relacionados: Noções Básicas de Solana, SOL e lamports, keypairs e PDAs, clusters, fluxo de transação e modelo mental Solana vs EVM.
Fundamentos
A abstração raiz é a conta.
Toda entidade on-chain é uma: saldo de carteira, bytecode de programa implantado, mint de token, struct de perfil de usuário ou holding temporário do sistema compartilham os mesmos campos estruturais - lamports, buffer de bytes de data, program id owner, flag executable e rent epoch legado.
Nada "mais" vive on-chain fora dessa forma.
Um programa é conta cuja flag executable é true e cujos dados guardam bytecode BPF/SBF que o runtime pode carregar.
Programas são sem estado no sentido de aplicativo: não mantêm saldos de usuário ou mappings dentro da própria conta após deploy como muitos contratos EVM mantêm slots de storage.
Estado mutável de aplicativo vive em contas separadas com owner daquele programa (ou do System Program até ownership ser atribuído).
Apenas o programa owner pode escrever data de uma conta; transferências de lamports e poucas regras de nível de sistema são as principais exceções que você projeta em torno.
Essa separação é por que você projeta layouts de conta em vez de "contract storage", e por que O Modelo Mental da Solana vs. EVM existe como contraste focado mais adiante nesta seção.
Moeda nativa é SOL, mas todo valor on-chain é número inteiro de lamports, onde 1 SOL = 1_000_000_000 lamports.
Clientes e programas tratam saldos, taxas e depósitos de rent como inteiros u64 / bigint - nunca SOL em ponto flutuante na fronteira do protocolo.
Identidade é Ed25519: keypair é chave pública de 32 bytes (o endereço) mais chave secreta usada para assinar.
Program Derived Addresses (PDAs) são endereços válidos de 32 bytes que ficam intencionalmente off da curva Ed25519 para não existir chave privada; programas "assinam" por elas com seeds via invoke_signed, como vaults com owner programa e contas determinísticas por usuário funcionam.
Um cluster (mainnet-beta, devnet, testnet ou seu localnet) é chain totalmente separada com genesis, validadores e conjunto de contas próprios.
Endereço que guarda SOL na devnet não guarda esse saldo na mainnet-beta; URL de RPC, rede da carteira e explorer devem concordar.
Commitment - processed, confirmed, finalized - é o quão longe uma transação progrediu pela execução do líder e votação de validadores antes do client tratá-la como boa o suficiente.
Nenhum desses tópicos é background opcional; são a mesma máquina vista em escalas diferentes.
Mecânica e Interações
Trabalho entra na rede como transação: pacote atômico de uma ou mais instruções, cada uma nomeando program id e contas que a instrução pode tocar.
Cada entrada de conta carrega account metas - se a conta é writable e se deve assinar - para o runtime travar contas e aplicar autorização antes do bytecode rodar.
Se qualquer instrução falha, toda transação falha; sucesso parcial não é resultado de transação Solana.
Sealevel, runtime paralelo em validadores Agave 4.1.1, usa listas declaradas de contas para agendar transações não sobrepostas em paralelo e serializar transações que compartilham conta writable.
Você compra throughput particionando estado entre contas para usuários não relacionados não disputarem uma conta quente.
Conta de dados durável deve guardar pelo menos lamports mínimos isentos de rent para seu tamanho de data (consultados via getMinimumBalanceForRentExemption); contas subfinanciadas não são design sustentável para estado de longa vida.
Taxas são pagas em lamports por fee payer designado; prioridade é expressa com limites e preço de compute unit, sobre taxas base por signature.
O caminho do client à confirmação é um pipeline, não produtos separados "enviar" e "esperar":
Client (wallet / kit / CLI)
| monta instruções + account metas
| assina com keypair(s) Ed25519
v
Nó RPC ---- sendTransaction ---->
|
| Gulf Stream encaminha ao próximo líder
v
Líder (slot atual)
| ordena via PoH, executa via Sealevel
| cada instrução: carrega contas -> roda programa -> escreve
v
Propagação de bloco (Turbine) + votos de validadores
|
| escada de commitment:
| processed -> confirmed -> finalized
v
Client faz poll ou subscribe até commitment escolhido
Lendo esse fluxo com fundamentos em mente: o client está montando quais contas um programa sem estado pode tocar, financiando novas contas com lamports, assinando com keypairs, mirando RPC de um cluster e esperando commitment que combine com o risco da UX.
Como uma Transação Flui aprofunda cada salto; esta página só precisa que você veja que saltos não são segunda arquitetura.
Trabalho cross-program ainda fica dentro de uma transação: programa pode CPI em outro programa, mas toda conta que o callee precisa já deve aparecer na lista de contas da transação com metas corretas.
Composabilidade é fiação explícita, não contexto de chamada ambiente.
Considerações Avançadas e Aplicações
Com o loop central claro, escolhas de design seguem dele em vez de folclore de framework.
Particione estado para Sealevel rodar usuários independentes em paralelo; conta global única que todo usuário deve escrever vira teto de throughput e problema de rent/tamanho.
Prefira PDAs para vaults controlados por programa e layouts determinísticos "uma conta por usuário/entidade"; prefira keypairs ordinários para autoridades humanas e fee payers.
Combine commitment à consequência: dashboards frequentemente usam confirmed; efeitos colaterais off-chain irreversíveis e liquidações de alto valor geralmente esperam finalized.
Mantenha ambientes rigorosos: keypair dev, keypair mainnet e keypair de validador local são identidades diferentes em chains diferentes, mesmo quando strings base58 parecem similares entre clusters só por coincidência de geração, não por estado compartilhado.
Ao portar do EVM, não procure "storage dentro do programa"; procure "quais contas esta instrução declara, quem as possui e quem assina?"
A tabela abaixo comprime os dois modelos de conta sem substituir a página EVM dedicada.
| Aspecto | Contratos estilo EVM | Modelo de contas Solana |
|---|---|---|
| Onde código vive | Bytecode de contrato em endereço | Conta de programa executável (program id) |
| Onde estado vive | Slots de storage no contrato | Contas de dados separadas com owner programa |
| Como callers são identificados | msg.sender implícito | Contas signatárias explícitas na instrução |
| Como mappings funcionam | mapping no storage do contrato | Muitas contas, frequentemente PDAs com seeds de material de chave |
| Paralelismo | Limitado por storage compartilhado do contrato | Sealevel paraleliza locks de conta não sobrepostos |
| Economia de storage | Gas para updates estilo SSTORE | Depósito de lamports isento de rent dimensionado aos bytes da conta |
| Trabalho multi-passo atômico | Uma transação, chamadas sequenciais | Uma transação, multi-instrução explícita + CPI |
Níveis de commitment são outra tabela operacional para internalizar cedo.
| Commitment | Significado aproximado | Uso típico |
|---|---|---|
processed | Líder executou; ainda não fortemente votado | UI otimista, leituras especulativas |
confirmed | Supermaioria votou no bloco | Padrão para muitas ações de app |
finalized | Enraizado / praticamente irreversível em condições normais | Liquidações, saques, callbacks cross-system |
Clusters formam terceiro eixo do mesmo modelo: localnet para CI rápido, devnet para SOL sandbox público e testes compartilhados, testnet para experimentos voltados a validadores, mainnet-beta para valor real.
Clusters e Redes e SOL, Lamports e Unidades detalham operações e precisão; aqui o ponto avançado é simplesmente que matemática de valores, gestão de chaves e política de confirmação só fazem sentido depois de fixar em qual chain você está.
Conceitos Errados Comuns
- "Programas armazenam estado do meu app como smart contract." Programas são executáveis; estado vive em contas que possuem e que toda instrução deve passar explicitamente.
- "Valores SOL podem ser floats no client se eu for cuidadoso." Valores on-chain são lamports inteiros; converta na borda da UI com matemática inteira/
bigint, não floats IEEE, para qualquer coisa que será assinada ou armazenada. - "PDAs são só chaves públicas chiques com chaves secretas que você deriva." PDAs não têm chave privada; só programa que conhece seeds pode autorizar assinaturas PDA pelo runtime.
- "Devnet e mainnet-beta compartilham contas se o endereço coincide." Clusters são ledgers separados; mesmo keypair controla estados de conta diferentes em cada chain, e RPC deve apontar ao cluster que você quer.
- "Se
sendTransactionretorna signature, a transferência é final." Signature significa que o nó aceitou o caminho de submissão; durabilidade depende do nível de commitment que você espera depois. - "Listar menos contas torna transações mais baratas ou simples." Omitir conta exigida falha em runtime; over-lock de contas writable reduz paralelismo - correção precisa do conjunto verdadeiro, performance precisa de design bem particionado.
FAQs
Qual é a versão de uma frase do modelo mental do desenvolvedor Solana?
Tudo é conta; programas executam contra contas nomeadas em transações atômicas, financiadas em lamports, autorizadas por assinaturas ou PDAs, em um cluster, até seu commitment escolhido dizer que pode confiar no resultado.
Por que "tudo é conta" é útil em vez de slogans fofos?
Unifica carteiras, programas, mints e dados sob um modelo de load/store e ownership, então taxas, rent, locks e leituras RPC usam o mesmo vocabulário.
Se programas são contas, como programa difere de conta de dados?
Conta de programa é marcada executable e guarda bytecode que o loader executa; conta de dados guarda bytes de aplicativo interpretados pelo programa owner e não é executada como código.
Quem pode mudar bytes de data de uma conta?
Só o programa que possui a conta pode modificar seus dados (sujeito a regras do runtime); outros programas precisam CPI no owner ou ter lamports/signers para operações que o sistema permite.
O que uma transação realmente garante?
Todas suas instruções têm sucesso ou nenhum de seus efeitos é commitado; não há aplicação parcial da lista de instruções de transação com falha.
Por que toda conta deve ser listada antecipadamente?
O runtime usa a lista para locking, checagens de assinatura e agendamento Sealevel; contas não declaradas não podem ser carregadas no meio do voo como algumas VMs permitem acesso implícito a storage.
Como Sealevel decide o que pode rodar em paralelo?
Transações que não compartilham locks de conta conflitantes - especialmente contas writable sobrepostas - podem executar concorrentemente; conflitantes são ordenadas para writes consistentes.
O que é lamport e por que não usar SOL em todo lugar?
Lamport é unidade inteira base (1 SOL = 1e9 lamports); chain e APIs falam inteiros para valores nunca dependerem de arredondamento de ponto flutuante.
O que é isenção de rent em uma linha?
Saldo mínimo de lamports baseado em tamanho de data que mantém conta viva sem cobrança contínua de rent na economia atual - financie na criação via mínimo isento de rent.
Como keypairs e PDAs cabem na mesma história de identidade?
Keypairs provam autoridade humana ou de servidor com assinaturas Ed25519; PDAs são endereços controlados por programa sem secrets, autorizados só quando programa owner fornece seeds corretas no CPI.
Por que explorer mostra nada quando saldo da CLI parece ok?
Quase sempre mismatch de cluster - CLI na devnet, explorer na mainnet-beta, ou URL RPC apontando rede diferente da carteira.
Qual commitment meu dapp deve esperar por padrão?
Muitas ações de produto usam confirmed para UX responsiva; use finalized antes de efeitos externos irreversíveis e trate processed só como otimista.
Como esta página difere de "O Modelo Mental da Solana vs. EVM"?
Esta página é o modelo completo do builder (contas até confirmação); página EVM é contraste focado de porting para engenheiros que já pensam em contratos-com-storage.
Anchor ou @solana/kit mudam este modelo mental?
Não - Anchor 0.32.1 e @solana/kit 7.0.0 são camadas ergonômicas sobre as mesmas superfícies de contas, instruções, metas e RPC/commitment descritas aqui.
Para onde ir depois desta página?
Passe por Noções Básicas de Solana para exemplos concretos, depois aprofunde moeda, chaves, clusters e fluxo de transação pelos links Relacionados abaixo conforme constrói.
Relacionado
- Noções Básicas de Solana - orientação prática a contas, programas, transações e SOL
- SOL, Lamports e Unidades - denominações inteiras, precisão e valores de taxa/rent
- Keypairs e Endereços - identidade Ed25519, papéis de assinatura e endereços PDA
- O Modelo Mental da Solana vs. EVM - contas-e-programas versus contratos-com-storage
- Como uma Transação Flui - do client ao líder ao commitment em detalhe operacional
- Clusters e Redes - mainnet-beta, devnet, testnet e localnet como chains separadas
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.