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.
//
Busque em todas as páginas da documentação
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 - noções básicas, 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 uma transferência de carteira, um deploy de programa ou uma chamada RPC com falha com a mesma imagem subjacente.
processed como final - que desaparecem assim que as peças compartilham um único modelo.A abstração raiz é a conta.
Toda entidade on-chain é uma: um saldo de carteira, o bytecode de um programa implantado, um mint de token, a struct de perfil de um usuário ou uma conta de espera temporária do sistema compartilham os mesmos campos estruturais - lamports, um buffer de bytes de dados, um ID de programa proprietário, um sinalizador executável e uma época de aluguel herdada.
Nada "mais" vive on-chain fora dessa forma.
Um programa é uma conta cujo sinalizador executable é verdadeiro e cujos dados contêm bytecode BPF/SBF que o runtime pode carregar.
Programas são sem estado no sentido de aplicativo: eles não mantêm saldos de usuário ou mapeamentos dentro de sua própria conta após a implantação, como muitos contratos EVM mantêm slots de armazenamento.
O estado mutável do aplicativo vive em contas separadas pertencentes a esse programa (ou ao System Program até que a propriedade seja atribuída).
Apenas o programa proprietário pode escrever os dados de uma conta; transferências de lamports e algumas regras de nível de sistema são as principais exceções em torno das quais você projeta.
Essa separação é o motivo pelo qual você projeta layouts de conta em vez de "armazenamento de contrato", e por que O Modelo Mental da Solana vs. EVM existe como um contraste focado mais adiante nesta seção.
A moeda nativa é SOL, mas todo valor on-chain é um número inteiro de lamports, onde 1 SOL = 1_000_000_000 lamports.
Clientes e programas tratam saldos, taxas e depósitos de aluguel como inteiros u64 / bigint - nunca como SOL de ponto flutuante na fronteira do protocolo.
A identidade é Ed25519: um keypair é uma chave pública de 32 bytes (o endereço) mais uma chave secreta usada para assinar.
Program Derived Addresses (PDAs) são endereços válidos de 32 bytes que intencionalmente ficam fora da curva Ed25519 para que nenhuma chave privada exista; programas "assinam" por eles com seeds via invoke_signed, que é como funcionam os cofres de propriedade do programa e as contas determinísticas por usuário.
Um cluster (mainnet-beta, devnet, testnet ou seu localnet) é uma cadeia totalmente separada com seu próprio genesis, validadores e conjunto de contas.
Um endereço que detém SOL na devnet não detém esse saldo na mainnet-beta; a URL RPC, a rede da carteira e o explorador devem concordar.
Commitment - processed, confirmed, finalized - indica o quão longe uma transação progrediu através da execução do líder e da votação dos validadores antes que seu cliente a considere boa o suficiente.
Nenhum desses tópicos é um background opcional; eles são a mesma máquina vista em diferentes escalas.
O trabalho entra na rede como uma transação: um pacote atômico de uma ou mais instruções, cada uma nomeando um ID de programa e as contas que essa instrução pode tocar.
Cada entrada de conta carrega metadados da conta - se a conta é gravável e se deve assinar - para que o runtime possa bloquear contas e impor autorização antes que o bytecode seja executado.
Se qualquer instrução falhar, toda a transação falha; sucesso parcial não é um resultado de transação Solana.
Sealevel, o runtime paralelo nos validadores Agave 4.1.1, usa essas listas de contas declaradas para agendar transações não sobrepostas concorrentemente e para serializar transações que compartilham uma conta gravável.
Você compra taxa de transferência particionando o estado entre contas para que usuários não relacionados não disputem uma conta quente.
Uma conta de dados durável deve conter pelo menos o mínimo de lamports isento de aluguel para seu tamanho de dados (consultado via getMinimumBalanceForRentExemption); contas com fundos insuficientes não são um design sustentável para estado de longa duração.
As taxas são pagas em lamports por um pagador de taxa designado; a prioridade é expressa com limites e preço de unidade de computação, sobrepostos às taxas base baseadas em assinatura.
O caminho do cliente à confirmação é um único pipeline, não produtos separados de "enviar" e "esperar":
Cliente (carteira / kit / CLI)
| constrói instruções + metadados de conta
| assina com keypair(s) Ed25519
v
Nó RPC ---- sendTransaction ---->
|
| Gulf Stream encaminha para o próximo líder
v
Líder (slot atual)
| ordena via PoH, executa via Sealevel
| cada instrução: carrega contas -> executa programa -> escreve
v
Propagação de bloco (Turbine) + votos de validadores
|
| escada de commitment:
| processed -> confirmed -> finalized
v
Cliente consulta ou assina até o commitment escolhidoLendo esse fluxo com os fundamentos em mente: o cliente está montando quais contas um programa sem estado pode tocar, financiando novas contas com lamports, assinando com keypairs, direcionando para o RPC de um cluster e esperando um commitment que corresponda ao risco da UX.
Como uma Transação Flui aprofunda cada etapa; esta página só precisa que você veja que as etapas não são uma segunda arquitetura.
O trabalho entre programas ainda está dentro de uma transação: um programa pode fazer CPI para outro programa, mas toda conta que o chamado precisa já deve aparecer na lista de contas da transação com os metadados corretos.
A composabilidade é fiação explícita, não contexto de chamada ambiente.
Uma vez que o loop principal esteja claro, as escolhas de design seguem dele, em vez de folclore de framework.
Particione o estado para que o Sealevel possa executar usuários independentes em paralelo; uma única conta global que todo usuário deve escrever se torna um teto de taxa de transferência e um problema de aluguel/tamanho.
Prefira PDAs para cofres controlados por programa e layouts determinísticos "uma conta por usuário/entidade"; prefira keypairs comuns para autoridades humanas e pagadores de taxas.
Combine o commitment com a consequência: dashboards frequentemente usam confirmed; efeitos colaterais off-chain irreversíveis e liquidações de alto valor geralmente esperam por finalized.
Mantenha ambientes rigorosos: um keypair de desenvolvimento, um keypair de mainnet e um keypair de validador local são identidades diferentes em cadeias diferentes, mesmo quando as strings base58 parecem semelhantes entre clusters apenas por coincidência de geração, não por estado compartilhado.
Ao portar do EVM, não procure por "armazenamento dentro do programa"; procure por "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 dedicada ao EVM.
| Aspecto | Contratos estilo EVM | Modelo de contas Solana |
|---|---|---|
| Onde o código vive | Bytecode do contrato em um endereço | Conta de programa executável (ID do programa) |
| Onde o estado vive | Slots de armazenamento dentro do contrato | Contas de dados separadas pertencentes a um programa |
| Como os chamadores são identificados | msg.sender implícito | Contas signatárias explícitas na instrução |
| Como os mapeamentos funcionam | mapping no armazenamento do contrato | Muitas contas, frequentemente PDAs com seeds de material de chave |
| Paralelismo | Limitado pelo armazenamento compartilhado do contrato | Sealevel paraleliza bloqueios de conta não sobrepostos |
| Economia de armazenamento | Gás para atualizações estilo SSTORE | Depósito de lamports isento de aluguel dimensionado aos bytes da conta |
| Trabalho atômico de várias etapas | Uma transação, chamadas sequenciais | Uma transação, multi-instrução explícita + CPI |
Os níveis de commitment são outra tabela operacional que você deve internalizar cedo.
| Commitment | Significado aproximado | Uso típico |
|---|---|---|
processed | Líder executou; ainda não votado extensivamente | UI otimista, leituras especulativas |
confirmed | Supermaioria votou no bloco | Padrão para muitas ações de aplicativo |
finalized | Enraizado / praticamente irreversível em condições normais | Liquidações, saques, callbacks cross-system |
Clusters formam um 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 a matemática de valores, o gerenciamento de chaves e a política de confirmação só fazem sentido depois que você define em qual cadeia você está.
bigint, não floats IEEE, para qualquer coisa que será assinada ou armazenada.sendTransaction retornar uma assinatura, a transferência é final." Uma assinatura significa que o nó aceitou o caminho de submissão; a durabilidade depende do nível de commitment que você espera depois.Tudo é uma conta; programas executam contra contas nomeadas em transações atômicas, financiadas em lamports, autorizadas por assinaturas ou PDAs, em um cluster, até que seu commitment escolhido diga que você pode confiar no resultado.
Unifica carteiras, programas, mints e dados sob um único modelo de load/store e propriedade, para que taxas, aluguel, bloqueios e leituras RPC usem o mesmo vocabulário.
Uma conta de programa é marcada como executável e contém bytecode que o loader executa; uma conta de dados contém bytes de aplicativo interpretados por seu programa proprietário e não é executada como código.
Apenas o programa que possui a conta pode modificar seus dados (sujeito às regras do runtime); outros programas precisam fazer CPI para o proprietário ou devem deter lamports/signers para operações que o sistema permite.
Todas as suas instruções têm sucesso ou nenhum de seus efeitos é commitado; não há aplicação parcial da lista de instruções de uma transação com falha.
O runtime usa a lista para bloqueio, verificações de assinatura e agendamento do Sealevel; contas não declaradas não podem ser carregadas em pleno voo como algumas VMs permitem acesso implícito ao armazenamento.
Transações que não compartilham bloqueios de conta conflitantes - especialmente contas graváveis sobrepostas - podem ser executadas concorrentemente; as conflitantes são ordenadas para que as gravações permaneçam consistentes.
Um lamport é a unidade inteira base (1 SOL = 1e9 lamports); a cadeia e as APIs usam inteiros para que os valores nunca dependam de arredondamento de ponto flutuante.
Um saldo mínimo de lamports baseado no tamanho dos dados que mantém uma conta viva sem coleta contínua de aluguel na economia atual - financie-a na criação via mínimo isento de aluguel.
Keypairs provam autoridade humana ou de servidor com assinaturas Ed25519; PDAs são endereços controlados por programa sem segredos, autorizados apenas quando o programa proprietário fornece as seeds corretas no momento do CPI.
Quase sempre uma incompatibilidade de cluster - CLI na devnet, explorador na mainnet-beta, ou uma URL RPC apontando para uma rede diferente da carteira.
Muitas ações de produto usam confirmed para uma UX responsiva; use finalized antes de efeitos externos irreversíveis e trate processed apenas como otimista.
Esta página é o modelo completo do construtor (contas até confirmação); a página EVM é um contraste focado para portabilidade para engenheiros que já pensam em contratos-com-armazenamento.
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, metadados e RPC/commitment descritas aqui.
Leia Noções Básicas de Solana para exemplos práticos, depois aprofunde moeda, chaves, clusters e fluxo de transação através dos links Relacionados abaixo enquanto você constrói.
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.
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026