A Rampa do Modelo Mental Solana
Novos desenvolvedores Solana aprendem mais rápido com ordem fixa de conceitos: contas antes de instructions, instructions antes de transações, depois PDAs, CPIs e compute budgets em Agave 4.1.1. Esta página é a sequência de leitura e exercícios antes de escrever código Anchor 0.32.1 de produção.
Receita
Card de receita de referência rápida - pronto para copiar e colar.
1. Accounts + owners
2. Programs (stateless executables)
3. Instructions + signers
4. Transactions + blockhashes
5. PDAs + seeds + bumps
6. CPIs + account validation
7. Compute units + priority fees
8. Clients (@solana/kit 7.0.0 / CLI)
Quando usar:
- Primeira semana de onboarding antes de feature work.
- Contratações EVM ou Cosmos mudando modelos de execução.
- Engenheiros frontend que lerão IDLs de programa.
- PMs que precisam de vocabulário preciso para specs.
Exemplo Funcional
# Exercise sequence on devnet (Solana CLI 3.0.10)
# 1) See an account
solana account 11111111111111111111111111111111
# 2) Transfer SOL (instruction + signer)
solana transfer <RECIPIENT> 0.01 --allow-unfunded-recipient
# 3) Inspect transaction instructions
solana confirm -v <SIGNATURE>
# 4) Find a PDA from your program's seeds (Anchor logs on devnet deploy)
anchor deploy && anchor run testO que isso demonstra:
- CLI torna contas e instructions tangíveis antes de sintaxe Rust.
- Confirm verboso mostra program IDs e metas de conta.
- Testes Anchor exercitam PDAs e CPIs sem packing manual.
- Erros devnet são baratos - use-os enquanto aprende.
Aprofundamento
Estágio 1 - Contas e Ownership
- Tudo persistente é uma conta (lamports + bytes + owner).
- Programas são contas executáveis mas guardam state mínimo na própria conta de programa.
- Apenas o programa owner pode escrever data de uma conta (salvo exceções de nível system).
Estágio 2 - Instructions e Transações
- Uma instruction nomeia programa, lista de contas e payload de data opaco.
- Uma transação executa atomicamente uma ou mais instructions com um recent blockhash.
- Signers autorizam pagamento de fee e mutações privilegiadas de conta.
Estágio 3 - PDAs
- Program Derived Addresses não têm private key; programas assinam via seeds + bump.
- Seeds são separados por domínio; colisões são inviáveis com construção correta.
- Armazene bump canônico on-chain para evitar caça de bump em runtime (custo CU).
Estágio 4 - CPIs
- Cross-Program Invocation deixa seu programa chamar SPL Token, System ou programas de terceiros.
- Você deve passar toda conta que o callee espera - o runtime não infere.
- Reentrância e escalação de privilégio são foco de revisão.
Estágio 5 - Economia do Runtime
- Compute units (CU) medem execução; exceder budget falha a transação.
- Priority fees influenciam scheduling durante congestionamento.
- Saldos mínimos isentos de rent determinam custos de criação de conta.
Tabela de Caminho de Aprendizado
| Dia | Conceito | Exercício | Link doc |
|---|---|---|---|
| 1 | Contas | solana account | Solana Basics |
| 2 | Instructions | CLI transfer | Transactions Basics |
| 3 | Contas Anchor | #[derive(Accounts)] | Accounts struct |
| 4 | PDAs | constraint seeds | Seção PDAs |
| 5 | CPI | anchor_spl::token | CPI Anchor |
| 6 | CU/fees | simulate + budget ix | Priority fees |
| 7 | Client | kit read/write | kit Basics |
Erros Comuns
- Pensar que contratos guardam storage - EVM mapeia mal. Correção: repita "state vive em contas."
- Pular regras de signer - leva a exploits mainnet. Correção: diagrama signers por instruction cedo.
- PDA como pessoa - PDAs são endereços, não wallets com keys. Correção: pratique
invoke_signed. - Ignorar CU até prod - surpresas perto do launch. Correção: simule CU em testes semana 1.
- Aprender clients antes de contas - erros confusos. Correção: siga ordem da rampa estritamente.
Alternativas
| Alternativa | Use Quando | Não Use Quando |
|---|---|---|
| Pular para tutorial Anchor | Dev impaciente com buddy | Self-serve sem revisão |
| Apenas doc comparação EVM | Solidity experiente | Caminho primário de aprendizado |
| Curso só em vídeo | Suplemento | Material único de onboarding |
| Mainnet "aprender fazendo" | Nunca | Onboarding |
FAQs
Quanto tempo por estágio?
Meio dia por linha na tabela para a maioria dos engenheiros.
Anchor antes de nativo?
Sim para ramp - Anchor revela PDAs/CPIs com guardrails.
Profundidade dev frontend?
Estágios 1-2 e 5-6 profundamente; 3-4 conceitualmente com exemplos IDL.
Quiz?
Buddy pergunta: quem assina, quem paga rent, onde state é armazenado.
Mudanças Alpenglow?
Modelo mental para contas/programas permanece; docs de confirmação evoluem separadamente.
Foco em token?
Adicione dia SPL Token após estágio 2 se produto é DeFi/NFT.
Local vs devnet?
Local para loops rápidos; devnet para fees e comportamento RPC realistas.
Papel do LiteSVM?
Reforce estágios 3-5 com testes unitários em Rust.
Bloqueios comuns?
Borrow checker + lifetimes de conta - pair com hora buddy Rust.
Após ramp?
Prossiga para projeto guiado First Program & dApp.
Relacionado
- Checklist de Onboarding de Devs - checklist completo
- Solana Basics - fundamentos
- O Modelo Mental Solana vs. EVM - comparação
- Noções Básicas de Programas - runtime
Versões do stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0 e LiteSVM 0.6.x.