A Rampa do Modelo Mental Solana

Novos desenvolvedores Solana aprendem mais rápido com uma ordem fixa de conceitos: contas antes de instruções, instruções antes de transações, depois PDAs, CPIs e orçamentos de computação no 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 referência rápida - pronto para copiar e colar.

1. Contas + proprietários
2. Programas (executáveis sem estado)
3. Instruções + signers
4. Transações + blockhashes
5. PDAs + seeds + bumps
6. CPIs + validação de conta
7. Unidades de computação + taxas de prioridade
8. Clientes (@solana/kit 7.0.0 / CLI)

Quando usar isto:

Primeira semana de onboarding antes do trabalho em funcionalidades.
Contratações de EVM ou Cosmos mudando modelos de execução.
Engenheiros frontend que lerão IDLs de programa.
Gerentes de produto que precisam de vocabulário preciso para especificações.

Exemplo Funcional

# Sequência de exercícios em devnet (Solana CLI 3.0.10)
 
# 1) Ver uma conta
solana account 11111111111111111111111111111111
 
# 2) Transferir SOL (instrução + signer)
solana transfer <RECIPIENT> 0.01 --allow-unfunded-recipient
 
# 3) Inspecionar instruções da transação
solana confirm -v <SIGNATURE>
 
# 4) Encontrar um PDA a partir das seeds do seu programa (logs do Anchor na implantação devnet)
anchor deploy && anchor run test

O que isso demonstra:

A CLI torna contas e instruções tangíveis antes da sintaxe Rust.
O comando confirm verboso mostra IDs de programa e metadados de conta.
Testes do Anchor exercitam PDAs e CPIs sem empacotamento manual.
Erros em devnet são baratos - use-os enquanto aprende.

Aprofundamento

Estágio 1 - Contas e Propriedade

Tudo o que é persistente é uma conta (lamports + bytes + proprietário).
Programas são contas executáveis, mas mantêm estado mínimo na própria conta do programa.
Apenas o programa proprietário pode escrever os dados de uma conta (exceto exceções de nível de sistema).

Estágio 2 - Instruções e Transações

Uma instrução nomeia um programa, uma lista de contas e uma carga de dados opaca.
Uma transação executa atomicamente uma ou mais instruções com um único blockhash recente.
Signers autorizam o pagamento de taxas e mutações privilegiadas de conta.

Estágio 3 - PDAs

Program Derived Addresses não possuem chave privada; programas assinam via seeds + bump.
As seeds são separadas por domínio; colisões são inviáveis com construção correta.
Armazene o bump canônico on-chain para evitar a busca de bump em tempo de execução (custo de CU).

Estágio 4 - CPIs

Cross-Program Invocation permite que seu programa chame programas SPL Token, System ou de terceiros.
Você deve passar todas as contas que o programa chamado espera - o runtime não infere.
Reentrância e escalada de privilégio são áreas de foco na revisão.

Estágio 5 - Economia do Runtime

Unidades de computação (CU) medem a execução; exceder o orçamento falha a transação.
Taxas de prioridade influenciam o agendamento durante congestionamentos.
Saldo mínimo isento de aluguel determina os custos de criação de conta.

Tabela do Caminho de Aprendizagem

Dia	Conceito	Exercício	Link da documentação
1	Contas	`solana account`	Solana Basics
2	Instruções	Transferência CLI	Transactions Basics
3	Contas Anchor	`#[derive(Accounts)]`	Accounts struct
4	PDAs	Restrição `seeds`	Seção PDAs
5	CPI	`anchor_spl::token`	CPI Anchor
6	CU/taxas	simular + ix de orçamento	Priority fees
7	Cliente	`kit` ler/escrever	kit Basics

Armadilhas

Pensar que contratos guardam armazenamento - EVM mapeia mal. Correção: repita "o estado vive em contas."
Ignorar regras de signer - leva a exploits na mainnet. Correção: diagramar signers por instrução desde o início.
PDA como pessoa - PDAs são endereços, não carteiras com chaves. Correção: pratique invoke_signed.
Ignorar CU até a produção - surpresas perto do lançamento. Correção: simular CU nos testes da primeira semana.
Aprender clientes antes de contas - erros confusos. Correção: siga a ordem da rampa estritamente.

Alternativas

Alternativa	Use Quando	Não Use Quando
Pular para o tutorial Anchor	Dev impaciente com um colega	Autoatendimento sem revisão
Apenas o documento de comparação EVM	Desenvolvedor Solidity experiente	Caminho de aprendizado principal
Curso apenas 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 do nativo?

Sim para a rampa - Anchor revela PDAs/CPIs com salvaguardas.

Profundidade para dev frontend?

Estágios 1-2 e 5-6 profundamente; 3-4 conceitualmente com exemplos de IDL.

Quiz?

O colega pergunta: quem assina, quem paga o aluguel, onde o estado é armazenado.

Mudanças no Alpenglow?

O modelo mental para contas/programas permanece; os documentos de confirmação evoluem separadamente.

Foco em Token?

Adicione um dia de SPL Token após o estágio 2 se o produto for DeFi/NFT.

Local vs. devnet?

Local para loops rápidos; devnet para taxas realistas e comportamento de RPC.

Papel do LiteSVM?

Reforce os estágios 3-5 com testes unitários em Rust.

Bloqueios comuns?

Borrow checker + tempos de vida de conta - emparelhe com uma hora de colega Rust.

Após a rampa?

Prossiga para o projeto guiado First Program & dApp.

Relacionado

Checklist de Onboarding de Desenvolvedores - 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.

Receita

Card de referência rápida - pronto para copiar e colar.

1. Contas + proprietários
2. Programas (executáveis sem estado)
3. Instruções + signers
4. Transações + blockhashes
5. PDAs + seeds + bumps
6. CPIs + validação de conta
7. Unidades de computação + taxas de prioridade
8. Clientes (@solana/kit 7.0.0 / CLI)

Quando usar isto:

Primeira semana de onboarding antes do trabalho em funcionalidades.
Contratações de EVM ou Cosmos mudando modelos de execução.
Engenheiros frontend que lerão IDLs de programa.
Gerentes de produto que precisam de vocabulário preciso para especificações.

Exemplo Funcional

# Sequência de exercícios em devnet (Solana CLI 3.0.10)
 
# 1) Ver uma conta
solana account 11111111111111111111111111111111
 
# 2) Transferir SOL (instrução + signer)
solana transfer <RECIPIENT> 0.01 --allow-unfunded-recipient
 
# 3) Inspecionar instruções da transação
solana confirm -v <SIGNATURE>
 
# 4) Encontrar um PDA a partir das seeds do seu programa (logs do Anchor na implantação devnet)
anchor deploy && anchor run test

O que isso demonstra:

A CLI torna contas e instruções tangíveis antes da sintaxe Rust.
O comando confirm verboso mostra IDs de programa e metadados de conta.
Testes do Anchor exercitam PDAs e CPIs sem empacotamento manual.
Erros em devnet são baratos - use-os enquanto aprende.

Aprofundamento

Estágio 1 - Contas e Propriedade

Tudo o que é persistente é uma conta (lamports + bytes + proprietário).
Programas são contas executáveis, mas mantêm estado mínimo na própria conta do programa.
Apenas o programa proprietário pode escrever os dados de uma conta (exceto exceções de nível de sistema).

Estágio 2 - Instruções e Transações

Uma instrução nomeia um programa, uma lista de contas e uma carga de dados opaca.
Uma transação executa atomicamente uma ou mais instruções com um único blockhash recente.
Signers autorizam o pagamento de taxas e mutações privilegiadas de conta.

Estágio 3 - PDAs

Program Derived Addresses não possuem chave privada; programas assinam via seeds + bump.
As seeds são separadas por domínio; colisões são inviáveis com construção correta.
Armazene o bump canônico on-chain para evitar a busca de bump em tempo de execução (custo de CU).

Estágio 4 - CPIs

Cross-Program Invocation permite que seu programa chame programas SPL Token, System ou de terceiros.
Você deve passar todas as contas que o programa chamado espera - o runtime não infere.
Reentrância e escalada de privilégio são áreas de foco na revisão.

Estágio 5 - Economia do Runtime

Unidades de computação (CU) medem a execução; exceder o orçamento falha a transação.
Taxas de prioridade influenciam o agendamento durante congestionamentos.
Saldo mínimo isento de aluguel determina os custos de criação de conta.

Tabela do Caminho de Aprendizagem

Dia	Conceito	Exercício	Link da documentação
1	Contas	`solana account`	Solana Basics
2	Instruções	Transferência CLI	Transactions Basics
3	Contas Anchor	`#[derive(Accounts)]`	Accounts struct
4	PDAs	Restrição `seeds`	Seção PDAs
5	CPI	`anchor_spl::token`	CPI Anchor
6	CU/taxas	simular + ix de orçamento	Priority fees
7	Cliente	`kit` ler/escrever	kit Basics

Armadilhas

Pensar que contratos guardam armazenamento - EVM mapeia mal. Correção: repita "o estado vive em contas."
Ignorar regras de signer - leva a exploits na mainnet. Correção: diagramar signers por instrução desde o início.
PDA como pessoa - PDAs são endereços, não carteiras com chaves. Correção: pratique invoke_signed.
Ignorar CU até a produção - surpresas perto do lançamento. Correção: simular CU nos testes da primeira semana.
Aprender clientes antes de contas - erros confusos. Correção: siga a ordem da rampa estritamente.

Alternativas

Alternativa	Use Quando	Não Use Quando
Pular para o tutorial Anchor	Dev impaciente com um colega	Autoatendimento sem revisão
Apenas o documento de comparação EVM	Desenvolvedor Solidity experiente	Caminho de aprendizado principal
Curso apenas 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 do nativo?

Sim para a rampa - Anchor revela PDAs/CPIs com salvaguardas.

Profundidade para dev frontend?

Estágios 1-2 e 5-6 profundamente; 3-4 conceitualmente com exemplos de IDL.

Quiz?

O colega pergunta: quem assina, quem paga o aluguel, onde o estado é armazenado.

Mudanças no Alpenglow?

O modelo mental para contas/programas permanece; os documentos de confirmação evoluem separadamente.

Foco em Token?

Adicione um dia de SPL Token após o estágio 2 se o produto for DeFi/NFT.

Local vs. devnet?

Local para loops rápidos; devnet para taxas realistas e comportamento de RPC.

Papel do LiteSVM?

Reforce os estágios 3-5 com testes unitários em Rust.

Bloqueios comuns?

Borrow checker + tempos de vida de conta - emparelhe com uma hora de colega Rust.

Após a rampa?

Prossiga para o projeto guiado First Program & dApp.

Relacionado

Checklist de Onboarding de Desenvolvedores - 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.

A Rampa do Modelo Mental Solana

Buscar na documentação

A Rampa do Modelo Mental Solana